All calls are hanging up at 9min30

Hi everyone,

We’re using Openip trunk since a few weeks and we have an issue with calls lenght, every call are hanging up at 9min30. We opened a ticket with openip which is looking at it but they asked us to communicate you the issue cause the wazo is sending the bye.

In asterisk cli all we see is :

[2022-02-25 17:59:59.3996]     -- Channel PJSIP/Openip01-00000070 left 'simple_bridge' basic-bridge <617d87b8-09bb-4c40-bfdc-6f20ea471338>
[2022-02-25 17:59:59.3997]     -- Channel PJSIP/59090-0000006f left 'simple_bridge' basic-bridge <617d87b8-09bb-4c40-bfdc-6f20ea471338>
[2022-02-25 17:59:59.3997]   == Spawn extension (outcall, dial, 8) exited non-zero on 'PJSIP/59090-0000006f'

Any idea ?

Please show us the bye data.

And also the bye from the endpoint, Asterisk is a B2BUA.

Here is the bye in the capture

Endpoint :
Frame 117603: 429 bytes on wire (3432 bits), 429 bytes captured (3432 bits)
Ethernet II, Src: AA:BB:CC:DD:EE:FF (AA:BB:CC:DD:EE:FF), Dst: DD:EE:FF:AA:BB:CC (DD:EE:FF:AA:BB:CC)
Internet Protocol Version 4, Src: 10.X.X.X, Dst: 10.Y.Y.Y
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
    Source Port: 5060
    Destination Port: 5060
    Length: 395
    Checksum: 0x13f6 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 9]
    [Timestamps]
        [Time since first frame: 594.292964000 seconds]
        [Time since previous frame: 14.185147000 seconds]
    UDP payload (387 bytes)
Session Initiation Protocol (BYE)
    Request-Line: BYE sip:59090@10.Y.Y.Y:5060 SIP/2.0
        Method: BYE
        Request-URI: sip:59090@10.Y.Y.Y:5060
            Request-URI User Part: 59090
            Request-URI Host Part: 10.Y.Y.Y
            Request-URI Host Port: 5060
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 10.X.X.X:5060;rport;branch=z9hG4bKPj6fa5b709-6ecb-46f0-8079-9a5aab4ee13f
            Transport: UDP
            Sent-by Address: 10.X.X.X
            Sent-by port: 5060
            RPort: rport
            Branch: z9hG4bKPj6fa5b709-6ecb-46f0-8079-9a5aab4ee13f
        From: <sip:0123456789@10.X.X.X>;tag=161840c4-95c3-4cb8-ad46-f70de0037c72
            SIP from address: sip:0123456789@10.X.X.X
                SIP from address User Part: 0123456789
                SIP from address Host Part: 10.X.X.X
            SIP from tag: 161840c4-95c3-4cb8-ad46-f70de0037c72
        To: <sip:59090@10.X.X.X>;tag=2011253459
            SIP to address: sip:59090@10.X.X.X
                SIP to address User Part: 59090
                SIP to address Host Part: 10.X.X.X
            SIP to tag: 2011253459
        Call-ID: 1888698912@10.X.X.X
        [Generated Call-ID: 1888698912@10.X.X.X]
        CSeq: 21836 BYE
            Sequence Number: 21836
            Method: BYE
        Reason: Q.850;cause=16
            Reason protocols: Q.850
            Cause: Normal call clearing (16)
        Max-Forwards: 70
        User-Agent: Wazo PBX
        Content-Length:  0


Wazo :
Frame 117592: 487 bytes on wire (3896 bits), 487 bytes captured (3896 bits)
Ethernet II, Src: AA:BB:CC:DD:EE:FF (AA:BB:CC:DD:EE:FF), Dst: DD:EE:FF:AA:BB:CC (DD:EE:FF:AA:BB:CC)
Internet Protocol Version 4, Src: 10.X.X.X, Dst: 94.143.87.70
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
    Source Port: 5060
    Destination Port: 5060
    Length: 453
    Checksum: 0xc1ef [unverified]
    [Checksum Status: Unverified]
    [Stream index: 14]
    [Timestamps]
        [Time since first frame: 586.202089000 seconds]
        [Time since previous frame: 8.869255000 seconds]
    UDP payload (445 bytes)
Session Initiation Protocol (BYE)
    Request-Line: BYE sip:+33123456789@94.143.87.70:5060;user=phone SIP/2.0
        Method: BYE
        Request-URI: sip:+33123456789@94.143.87.70:5060;user=phone
            Request-URI User Part: +33123456789
            E.164 number (MSISDN): 33123456789
            Request-URI Host Part: 94.143.87.70
            Request-URI Host Port: 5060
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 10.X.X.X:5060;rport;branch=z9hG4bKPjd16b3efa-99cf-4352-af56-f469b4909907
            Transport: UDP
            Sent-by Address: 10.X.X.X
            Sent-by port: 5060
            RPort: rport
            Branch: z9hG4bKPjd16b3efa-99cf-4352-af56-f469b4909907
        From: "474123456" <sip:474123456@voip03.myopenip.fr>;tag=06ab3787-910d-4470-b274-8285eb9e468a
            SIP from display info: "474123456"
            SIP from address: sip:474123456@voip03.myopenip.fr
                SIP from address User Part: 474123456
                SIP from address Host Part: voip03.myopenip.fr
            SIP from tag: 06ab3787-910d-4470-b274-8285eb9e468a
        To: <sip:0123456789@voip03.myopenip.fr>;tag=SDfm00d99-024501a9000129b5
            SIP to address: sip:0123456789@voip03.myopenip.fr
                SIP to address User Part: 0123456789
                SIP to address Host Part: voip03.myopenip.fr
            SIP to tag: SDfm00d99-024501a9000129b5
        Call-ID: f342895b-688a-4808-a499-25446b3545dc
        [Generated Call-ID: f342895b-688a-4808-a499-25446b3545dc]
        CSeq: 14610 BYE
            Sequence Number: 14610
            Method: BYE
        Max-Forwards: 70
        User-Agent: Wazo PBX
        Content-Length:  0

It seems setting up the second trunk on a new transport binded on 5061 resolved our issue. We also made a port forwarding rule and a rule to have static outbound port. Never had to do that before with multi trunk but okay
We also changed a router / Pfsense parameter : Firewall Optimization Options and set it up on conservative mode (Tries to avoid dropping any legitimate idle connections at the expense of increased memory usage and CPU utilization)
Edit : Calls are hanging up at 12min now

It was carrier side.

Hello!
Can you tell how you solved this please? I have exactly the same problem.

By setting timers=no in the Endpoint of the Trunk it doesn’t cut the call anymore after 9m30, but apparently it’s not advised to disable timers because in case of failure the call never ends

Hi, I didn’t it was an issue with our sip provider… Their last message was that their provider made a change and asked us to try again, and it was settled
The name of the provider is OpenIp / dstny

Hello,

i remember there were an issue with session timer / session-expires with OpenIP sip trunks

Is your issue only occurs with outbound call ?

Hi,

in my case it was both ways, in and out

Ok, i ddn’t saw immediatly that your issue was solved.

thanks anyway, maybe it’ll help someone :wink:

hello, I have same problem for months, same carrier, Openip., Support told me that I send a BYE after 9min30. That seems to be true. Do not know what to ask them to resolv this issue. Can it come from Wazo?
@LaChagnasse would you suggest some informations to send them?

Hi, here is the conversation we had with openip for the last part, i skipped some of our response which were not relevant :

Openip : Cela ressemble à un défaut réseau, premièrement nous recevons les requêtes SIP d’enregistrement sur un port choisis aléatoirement par l’interface WAN de votre routeur :

1.2.3.4:60496

Nous conseillons l’utilisation du port 5060 sur un trunk A 5061 sur un trunk B etc… quand il s’agit d’une installation iPBX multi tenant.

Dans l’attente d’un retour nous restons à votre disposition.
Vous pouvez configurer par exemple le port 5060 pour le trunk A et le port 5061 pour le trunk B, ensuite il faut utiliser une règle de NAT sortante qui indique que pour le trafic vers notre serveur de trunk le port doit être “statique” exemple ci-dessous avec un règle sur nos routeurs opios :

US : Bien reçu, nous étions sur la page de wiki http://wiki.openip.fr/doku.php?id=3cx:configuration:start#pare-feu en étude, j’ai appliqué vos paramètres, ca n’est pas encore actualisé sur le dashboard (states cleared sur le parefeu). Nous allons refaire des tests avec le deuxieme trunk celui ci etant pour le moment desactivé. Nous avons pour le moment fait juste la redirection de port 5060, pas de RTP.
Nous avons un autre probleme plutot curieux, les appels sur le trunk coupent tous a 9min30, avez vous deja constaté ce soucis ?

Openip :

Effectivement nous voyons bien le 5060 désormais.

Concernant le défaut d’appel qui coupe à 09min nous supposons qu’il s’agit de cet appel :

4xxxxxxxxxx → 06xxxxxxxxx

Si oui nous voyons bien un défaut sur la trame SIP le distant (06*) envoi une méthode UPDATE que nous ne certifions pas, nous allons voir avec notre transitaire d’appel sortant ce défaut.

Pouvez-vous confirmer que vers un autre numéro cela fonctionne normalement ?

US : Malheureuseument le probleme est présent sur plusieurs operateurs, ici OVH

Openip : Sur cet appel le BYE provient du Wazo : picture
Pouvez-vous ouvrir un ticket chez Wazo en parallèle pour connaitre la raison du BYE ?

US : Nous sommes en version community, je vais faire un sujet sur forum

On another support exchange, after adding a transport on wazo on 5061 and connecting the second trunk on the second transport :

US : Nous avions deja ouvert un ticket que je n’ai pas pu rattacher à celui ci. Nous pensions que le probleme etait réglé suite à la mise en place de vos recommendations firewall et PBX, à savoir mettre le second trunk sur un port different. Nous avons aussi appliqué un parametre pfsense pour garder les states plus longtemps (mode conservative), apres tests les appels ne se raccrochent plus au bout de 10 min d’ou la fermeture du ticket, aujourd’hui nous remarquons que les appels coupent au bout de 12 minutes depuis le changement du mode de firewall. Ci joint capture de trame

Openip : Un cas similaire est en cours d’analyse entre le transitaire et notre infrastructure.
Notre transitaire nous informe avoir effectué une modification pouvez-vous refaire des tests d’appels ?

Then it was solved. I guess if you can show them that you applied their prerequisite they’ll look at it a bit more ?
Hope it’ll help, sorry i didn’t translate

The problem is back again after 5 months without any problem. We did not change anything in our conf. Now . Probably tired with us, Dstny (openip) support ask us to talk directly with our PDBX provider (do they read tickets ?, why not saying “wazo” ?), because they can not do anything.

Another problem has appeared, voip03.openip.net stop working with incoming calls. They asked us to change to voip02.openip.net and calls are incoming again. Voip03.openip.net does not work anymore for us.
Strange.

The 9min28s problem is still here for outgoing calls.

We are now looking for a new provider, because DSTNY support is too bad in resolving issues.

Have you checked a pcap? What the reason and who hangup the call?

In your fist sngrep screenshot, there is a bye from your Wazo, but because it’s a b2bua, we also need the pcap from your endpoint to wazo. What is your endpoint? Have you check on this part, also have you checked on the firewall, is there is SIP inspection or someting like this?

i’ve got a pcap from openip, can I DM to you?

Hello, This is not from openip but the leg from your endpoint (your phone) the pcap I need.