Multiple SDP invites

[hhijawi]

Hi
I have an issue when connecting the endpoint with 3G connection. I see multiple SDP invites are sent from the endpoint and this delays the call start signal.
when I connect using WiFi I see only one invite and the call start signal is fast.
Attached sngrep output.

appreciate your help.

 

[atmosphere617]

It looks like freeswitch isn't getting the sip responses. Those packets with the extra ">>>" are retransmission and are sent when requests don't receive the reply the expect. Where are you running the packet capture?

 

[hhijawi]

it is running on the same FreeSWITCH server.
so you think that endpoint sends the INVITE and it does not receive the OK from the server?
could it be related to NAT?

 

[atmosphere617]

Oh I assumed 45.147.* was the fs server b/c of the user-agent header. But yeah in this case it's pretty clear that sip stack isn't getting the response from the invite which is causing all those retransmission. Based on the 3g thing it's most likely network related. You could confirm this by running a pcap on the local network as well.

 

[hhijawi]

I tried another test with WiFi and I see the issue.
it happens if the line is idle for a few seconds.
I tried another test, end the call, and immediately start a new one, in this case, I don't see retransmission.

 

[atmosphere617]

Sounds like a firewall may be closing the port. You most likely need to do some kind of UDP hole punching. Have you made sure "nat-options-ping" is enabled on the profile? I think you can turn it on per extension as well by enabling "Force ping".

If NAT pinging is already on you could also try enabling one of the "NAT hacks". You can turn these on in fusion by changing the value of "SIP force contact". Those set "sip-force-contact=NDLB-connectile-dysfunction" in the user directory. More on that here: https://freeswitch.org/confluence/display/FREESWITCH/NAT+Traversal

Otherwise you really need to get a pcap from the perspective of the UA to determine the root issue. You're really just guessing.

 

[hhijawi]

Thanks alot for your help,
I tried all NAT options, also nat-options-ping and rport are set but still with no luck.
I am developing an android application based on PJSIP, the only workaround which works for me is setting the UDP keepalive to 1 second, I don't think this is good.
I was using Asterisk and I did not see the issue.
I feel it is some configurations in FusionPbx.

 

[DigitalDaz]

Have you tried using TCP? Those SDPs look like they may be big enough to fragment the UDP packet.

 

[hhijawi]

yes, same for TCP.
the packet size is small, does not seem related to fragmentation

 

[DigitalDaz]

What is ip 45.147.66.167?

 

[hhijawi]

it is the client IP