Softphones disconnect after 30 seconds from "answer" in FreeSWITCH

[case...@gmail.com]

Hello Everyone again,

I've noticed that when I call into FreeSWITCH with a soft phone, about 30 seconds AFTER the "answer" command is given to the soft phone, the connection is terminated. I don't know if this is happening from FreeSWITCH or from my soft phone. I've tried a number of soft phones from different vendors, including X-Lite and Zoiper, and they all have this problem. I've also tried completely removing my firewalls, etc., and connecting from different networks, but that didn't help either. There are a number of threads out there covering similar issues, but so far I haven't been able to make it work even with disabling inactivity timers like the RTP timer in the soft phones.

I have been able to duplicate this problem using a virgin install of the Kazoo ISO and a simple callflow (any action I choose results in this problem).

I have noted that if I _don't_ send an "answer" response to the soft phone, then it doesn't have this problem. The soft phone of course times out after about a minute or so of not being answered, but it works nonetheless.

I've also noticed that this problem doesn't exist when calls originate from FreeSWITH to a softphone.

I've spent days on this issue without any luck. Has anyone else seen this issue? Any ideas why this might be happening and how to fix it? 

Thanks!

Casey

[Darren Schreiber]

Hi there,

We’ve heard of this problem though I haven’t had time to dig into it. I’m pretty sure the issue is, for simplicity, we tried to route packets via localhost (127.0.0.1) past Kamailio  but this is messing things up.

Please try this fix:

1. In /etc/kazoo/kamailio/dispatcher/dbtext   change the IP address from 127.0.0.1 to your machine’s actual IP

2. In /etc/kazoo/freeswitch/sip_profiles/*.xml change the rtp-ip and sip-ip from 127.0.0.1 to your machine’s actual IP

For sanity, restart both FreeSWITCH and Kamailio.

I think that will fix it, though your FreeSWITCH server is now exposed (although on a non-standard port) to the inter webs.

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[case...@gmail.com]

Exactly what I needed - problem solved. Thanks Darren!

[hpertuz]

Hello,

I did the changes but we have the same problem, about 32 sec the call is terminated. What else could it be?

[Darren Schreiber]

In the softphone itself there is often an option for a session timer. Turn that off.

Otherwise, we’d need logs at this point.

[Humberto Pertuz]

making ngrep it show

U 174.36.47.2:5060 -> 190.146.181.117:56927

BYE sip:user_c2...@190.146.181.117:56927 SIP/2.0.

Via: SIP/2.0/UDP 174.36.47.2;branch=z9hG4bKd3b2.c650e1138bc903273eb07cd9681b2f8b.0.

Via: SIP/2.0/UDP 174.36.47.2:11000;received=174.36.47.2;rport=11000;branch=z9hG4bKDZtrF7BmQZZNa.

Max-Forwards: 50.

From: <sip:10...@1234567890.myserver.co>;tag=jc3954N5F8N1g.

To: <sip:user_c2xreqchde@1234567890. myserver.co >;tag=fcc7fb26.

Call-ID: N2Q4MmNkZGE3YzgyNmViMzU3YTBjNWNiYmJiZmFlNjQ.

CSeq: 83788905 BYE.

Contact: <sip:10...@174.36.47.2:11000;transport=udp>.

User-Agent: 2600hz.

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE.

Supported: path, replaces.

Reason: SIP;cause=408;text="ACK Timeout".

Content-Length: 0.

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/ifQo_duxUlM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Humberto Pertuz
NINGUNO DE NOSOTROS ES TAN BUENO,
COMO TODOS NOSOTROS.

[Darren Schreiber]

This isn’t really enough, but this shows that the ACK was not received from the remote phone. This is likely a NAT issue or still a misconfiguration in Kamailio

[Humberto Pertuz]

I installed a second server but it has the same problem. The calls are terminated in 32 secs.

[Darren Schreiber]

Installing a second server with the exact same configuration issue is likely to have the exact same problem indeed.

I need the full FreeSWITCH SIP logs for the failed call. Not an ngrep.

[Humberto Pertuz]

Thank you for your help. Attached log file.

[Darren Schreiber]

Unfortunately this log file has only the BYE line. Where is the call setup? I need the full transaction from start to finish.

[Humberto Pertuz]

Attached a new file with the call log from start to finish

Thanks

[Darren Schreiber]

The issue is here:

send 1311 bytes to udp/[174.36.47.2]:5060 at 09:51:56.028699:

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

   SIP/2.0 200 OK

   Via: SIP/2.0/UDP 174.36.47.2;branch=z9hG4bK97f4.c22042fd79940118a63a722567e88b00.0

   Via: SIP/2.0/UDP 190.146.181.117:62852;received=190.146.181.117;branch=z9hG4bK-524287-1---2fc7ac2387d9d533;rport=62852

   Record-Route: <sip:174.36.47.2;lr=on;ftag=0c5aee6b>

   From: <sip:user_c2...@1234567890.vzy.co>;tag=0c5aee6b

   To: <sip:10...@1234567890.vzy.co>;tag=2atv2H5NpvB8r

   Call-ID: MDVjN2M5NjZiOWQxNjYzZGM3NWYzZTBjOTI5MzFmMjE

   CSeq: 2 INVITE

   Contact: <sip:10...@174.36.47.2:11000;transport=udp>

   User-Agent: 2600hz

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

   Supported: path, replaces

   Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer

   Content-Type: application/sdp

   Content-Disposition: session

   Content-Length: 287

   Remote-Party-ID: "Beto P." <sip:10...@1234567890.vzy.co>;party=calling;privacy=off;screen=no

There is no ACK back from the phone. What kind of phone is this?  It identifies as Bria iOS 3.4.4? My guess is that something is blocking the replies back to the phone at some point. I’d suggest trying to switch the Bria client’s phone to TCP and see if that makes a difference. The packets look right.

[Humberto Pertuz]

Yes, now it works, changing to TCP.

The phone is iPhone 5S

Thank you very much