Some Call drop after 32S

[JeanJean]

Hi,

I have little problem with my 3cx test.

We have a freepbx with SIP Trunk connect to the provider directly with IPVPN.

All call are OK

Same test with 3cx::

Some Call are Ok and other drop after 32Sec.

My provider say it is a 3cx problem. For the sip provider, the problem is 3cx provide no reponse to the reinvite request. Freepbx yes.

Possible that 3cx are not compatible but Freepbx yes ?

thanks for the help

 

[Alphabetic]

You could try the "supports re-invite" option in the SIP trunk

 

[leejor]

The "32 second " issue is usually a no ACK problem. The 3CX Activity Log will confirm this. Run the 3CX Firewall Checker and make certain all ports are open/forwarded. Interesting that it does not occur on every call...timing issue?

 

[JeanJean]

Hi thanks for your answer.

The problem is that 3cx use the defaut route to go on internet and a different route to the TRUNK.

This route have no Firewall. Direct acces to the provider for the SIP.

 

[JeanJean]

For example in Freepbx i have use this parameter:

externip=192.168.0.10 (Ip of the Freepbx)
nat=no

 

[JeanJean]

Ps: Reinvite is checked and same problem

FreePBX V15 and 3Cx last Version

 

[JeanJean]

I have compared FreePBX:


<--- SIP read from UDP:SIPIPPROVIDER:5060 --->
ACK sip:[email protected]:5160 SIP/2.0
Via: SIP/2.0/UDP SIPIPPROVIDER:5060;branch=z9hG4bKl6nabm1050ao0vvb7hh0.1
From: <sip:[email protected]:5060>;tag=SDabdc899-483446182-1608639325611
To: <sip:[email protected]:5160>;tag=as2cda6ba1
Call-ID: [email protected]:5160
CSeq: 87036226 ACK
Contact: <sip:+33xxxx@SIPIPPROVIDER:5060;transport=udp>
Max-Forwards: 68
Content-Length: 0

Via: SIP/2.0/UDP SIPIPPROVIDER:5060;branch=z9hG4bK6351fs102ov903somsm0sb50c2111.1;received=SIPIPPROVIDER
From: <sip:[email protected]:5060>;tag=SDabdc899-483446182-1608639325611
To: <sip:[email protected]:5160>;tag=as2cda6ba1
Call-ID: [email protected]:5160
CSeq: 87036226 INVITE

And 3cx:

from <sip:[email protected]:5060>;tag=SD7l31199-669323163-1608858821137 to "xxxxxxxx"<sip:[email protected]:5060>

--------------------------------

The From: comme from the provider with @sip.provider.fr for the FreePBX and 3Cx

But the TO: is different. In freepbx is the IP of my Freepbx but not in 3cx ?

Possible that the problem comme from that ?

 

[ivan.antic]

JeanJean,

Try with

SIP Trunks => Name of the trunk => Options => Advanced => Select Put Public IP in SIP VIA Header

 

[JeanJean]

Hi
Thanks for the answer.

But same result:

from <sip:[email protected]:5060 to "xxxxxxxx"<sip:[email protected]:5060>

sip.provider.fr stay on the to.

And i see also this in the log

25-12-2020 21:40:25:018 | 9 | L:110.2[Line:10000>>+33xxxx] Sending: OnSendResp Send 200/CANCEL from 0.0.0.0:0 tid=t730tl2010s18ntguic0sbd0kjlr2.1 Call-ID=v3npZvlhXUDkBHPLivUW2Q..:
SIP/2.0 200 OK
Via: SIP/2.0/UDP sipip:5060;branch=z9hG4bKt730tl2010s18ntguic0sbd0kjlr2.1
Contact: <sip:+3300000@ip3cx:5060>
To: "+33xxxxx"<sip:[email protected]:5060>;tag=43030576
From: <sip:[email protected]:5060>;tag=SDfesmd99-592015543-1608928769987
Call-ID: v3npZvlhXUDkBHPLivUW2Q..
CSeq: 231758263 CANCEL
Content-Length: 0

 

[ivan.antic]

Alright JJ,

To and From headers are less important in your case.

The Contact and Via header you need to look into.

Path that the original INVITE uses to get to the destination can be different then the ACK.

Provider doesn't know you received an 200 OK until it gets an ACK.

200 OK will be re-transimtted after .. 30sec., 1sec., 2sec., 4sec, 4sec. ... and finally at 32sec. call will end with RTP still going on.

The reason why call is happening in the first place, for failed calls, is that the 200 OK+SDP packet found it's way to destination, both caller and callee agreed to how to make a call, but eventuly will fail after 32sec. as there is no ACK. So callee doesn't know that the caller knows what he knows

1. Make sure you have you provider's IP DNS combo in 3cx's /etc/hosts

2. Change the routes other way around, default route will be provider's gateway and internet connection different interface.

3. Try installing and run an application called "sngrep" on 3cx host and catch failed call. There, you will be able to compare good vs. bad calls. Where is 200 you need an ACK after.

Hint: Take a look at the IP address in Contact header from last 200 OK + SDP. An ACK response will use that IP address to get other party.

I hope this helps you a bit.

 

[JeanJean]

Thanks for your answer.

First test:

Working call

- INVITE
-> ACK.


Not working call:

- invite
-> ACK
-> Invite
-> Trying
-> Cancel


Header seems to be the same...

 

[JeanJean]

Only think I found who is différent:

Failed on 3X

m=audio 13956 RTP/AVP 8 101
b=AS:29
b=RS:362
b=RR:1087
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

OK

m=audio 13958 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20

FreePBX

b=AS:29
b=RS:362
b=RR:1087
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=ptime:20
a=sendrecv



On the Failed they have not a=ptime:20

 

[leejor]

Here is a link to a description of that parameter.
https://nickvsnetworking.com/sip-sdp-ptime/

...and a VERY old 3CX thread.

https://www.3cx.com/community/threads/how-to-change-ptime-on-3cx-server.4124/

 

[JeanJean]

Thanks.

But I thinks that 3cx have compatibilty issue with my provider and Freepbx not

 

[JeanJean]

Just to see the difference:

FreePBX:



3Cx:



3Cx say 100 Tryning and after Cancel From Provider.

 

[ivan.antic]

JJ,

Try with something else to do 3cx ssh. ... those "q" suppose to be "-".

Looking into this SIP transactions... initial INVITE goes well. (INVITE then 200 OK+SDP and ACK).

The second INVITE is an RE-INVITE (in-dialog) from a provider.

CANCEL closes the session that has not received a final response. This means that the provider never received your 200 OK + SDP). And by looking into 3cx transactions there isn't any you sent .

200 OK without SDP just after CANCEL is a response to CANCEL, not to re-INVITE.

BYE is used to close already established session. Therefore, BYE you're sending is closing the INVITE.

if you haven't done already, enable both Supports Re-Invite and Support Replaces under Advanced options for trunk.

 

[JeanJean]

Hi,

Thanks for the answer!

I have take a look into the SIP:

100 trying (Send by Freepbx/3cx) after the provider reinvite:

Freepbx vs 3Cx: there is a big difference:

Into the header of Freepbx:

----------------------------------
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

Supported: replaces, timer

Contact: <sip:[email protected]:5160>

------------------------------------------------

Not present in 3CX....?

 

[JeanJean]

In comparaison it is the only difference that I see.

When Freepbx send this after they send also the reinvite OK

But 3Cx receved directly cancel from provider after the 100 Trying.

 

[NickD_3CX]

Hi there! So the problem seems to be after the re-INVITE arrives.

May I ask, you said this happens some times but not all of the times with 3CX?

Also, on 3CX, where do calls to thos number go? A Queue, Ring Group, Extension?
Just a hunch, but could you try changing the destination of the Inbound Rule?

 

[ivan.antic]

JJ,

Seems like 100 Trying has reached the destination, as provider didn't sent another re-INVITE.
100 Trying is used to say to the other party we received an INVITE stop sending it again.

It's you who didn't sent 200 OK + SDP on re-INVITE.

Can you share the details of your Inbound route from 3cx?, UA who is suppose to answers the calls on re-INVITE. ( is it custom web client or predictive dialer app, or deskphone etc..).

Depending on what you are doing with this call, it might be that it's not the 3cx issue at all, but UA behind 3cx.
You need the other leg of a call, from 3cx to UA.

UA who created initial INVITE is not sending 200 OK + SDP to 3cx on re-INVITE in order to 3cx relay it to provider.