[Freeswitch-users] Call drops after 30 seconds

Fri Jun 24 02:38:55 MSD 2011

matt,

i also encountered the same problem, even bridging internal endpoints. i
traced some RTCP packets using wireshark. i tried to enable the
"rtcp-audio-interval-msec=5000" in the internal sip profile. it solved the
problem momentarily.

-nandy

On Fri, Jun 24, 2011 at 2:32 AM, Michael Collins <msc at freeswitch.org> wrote:

> Matthew,
>
> Did you get resolution on this one? I think you can go to the sip profile
> and work with these lines:
>     <param name="ext-rtp-ip" value="auto-nat"/>
>     <param name="ext-sip-ip" value="auto-nat"/>
>
> You can put an IP address in those and try it out. Let us know what
> happens.
> -MC
>
> On Wed, Jun 22, 2011 at 8:26 AM, Matthew Ralston <freeswitch at mralston.com>wrote:
>
>> Hi Chris,
>>
>> The FreeSWITCH box does indeed have a private IP address. The Cisco
>> Linksys WAG160N router in front of it has UPnP enabled, not that I
>> particularly trust it.
>>
>> So maybe it's worth hard coding the public IP into the Sofia config.
>>
>> Where is the best place to put the public IP? The internal.xml and
>> external.xml files both refer to $${local_ip_v4} although I don't see where
>> this comes from. Does FreeSWITCH figure this out itself in some way?
>>
>> As I have internal SIP phones, an external SIP provider and (whilst
>> debugging) some external SIP phones (which use the internal profile!!). I'm
>> concerned that if I hard code the public IP address in to the wrong place it
>> will cause problems for the internal SIP phones.
>>
>>
>> Kind regards,
>>
>> Matthew Ralston
>> Web Developer & IT Consultant
>>
>> matt at mralston.co.uk
>> www.mralston.com
>>
>> On 22 Jun 2011, at 16:11, Chris Chen wrote:
>>
>> Hi Matthew, continue my last reply here
>>
>> 2) Is your FS server using private IP address?  you have to setup your FS
>> external SIP/RTP IP address to the proper public IP address, by either using
>> UPNP enabled router, STUN, or hardcoded public IP address in sofia profiles.
>>
>> Please check that.
>>
>> Thanks,
>> Chris
>>
>>
>> On Wed, Jun 22, 2011 at 10:49 AM, Matthew Ralston <
>> freeswitch at mralston.com> wrote:
>>
>>> Hi Chris,
>>>
>>> Thanks for the quick reply!
>>>
>>> The FreeSWITCH box is in the DMZ of a Cisco Linksys WAG160N. Best I can
>>> tell, the DMZ is doing its job and allowing all ports through, inbound and
>>> outbound, TCP & UDP.
>>>
>>> The external SIP phones are a Cisco SPA504G and Bria on the iPhone. These
>>> are behind behind a Cisco ASA5505, which has policy inspection for SIP
>>> switched on, i.e. ALG. I have also tested with Bria going over 3G (so it's
>>> not behind the Cisco ASA) and had the same problem.
>>>
>>> The other scenario we have is some Yealink T20P SIP phones on the same
>>> LAN segment as the FreeSWITCH box. These can make A-leg only calls into
>>> FreeSWITCH (like calling voicemail) and also calls to other internal SIP
>>> phones fine. However when they make an outbound call the problem happens
>>> again. In this case the b-leg of the calls are sent to an external SIP
>>> provider and get cut after 30 seconds. Incidentally, we also use the same
>>> SIP provider from an Asterisk box in our data centre and that doesn't have a
>>> problem, so I believe the SIP provider is fine.
>>>
>>> Kind regards,
>>>
>>>
>>> Matthew Ralston
>>> Web Developer & IT Consultant
>>>
>>> matt at mralston.co.uk
>>> www.mralston.com
>>>
>>> On 22 Jun 2011, at 14:21, Chris Chen wrote:
>>>
>>> Hi Matthew, this is typical behavior for the setup of SIP behind NAT.
>>>
>>>     1) Please provide the exact setup of remote SIP phones, what's the
>>> router model, does it have SIP ALG enabled, what kind  of SIP phones
>>>     2)
>>>
>>>
>>> On Wed, Jun 22, 2011 at 8:38 AM, Matthew Ralston <
>>> freeswitch at mralston.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm having a problem at the moment with calls being successfully set up,
>>>> with two-way audio, being terminated by FreeSWITCH after 30 seconds.
>>>>
>>>> Internal calls (i.e. between SIP phones on the same LAN segment as the
>>>> FreeSWITCH box) work flawlessly.
>>>>
>>>> The problem arises when at least one of the handsets is located
>>>> elsewhere on the Internet. This behaviour is exhibited under the following
>>>> circumstances:
>>>>
>>>> - A-leg only call, e.g. to voicemail when the handset is at another
>>>> location on the Internet
>>>> - A-leg-B-leg call if one or both of the handsets are at another
>>>> location on the Internet
>>>> - Inbound calls from our external SIP provider
>>>> - Outbound calls to our external SIP provider
>>>>
>>>> So it is obvious that the problem is related to the SIP going via the
>>>> Internet, but I'm having trouble understanding why.
>>>>
>>>> Whilst debugging this problem I have placed the FreeSWITCH box is in the
>>>> DMZ on our router, so there should not be any ports blocked. The FreeSWITCH
>>>> box itself is not running a software firewall.
>>>>
>>>> The calls themselves are absolutely fine for the first 30 seconds - each
>>>> party can hear the other talking fine.
>>>>
>>>> The fact that the call is consistently dropped after 30 seconds (give or
>>>> take a second or two for PDD) suggests that some timeout is being triggered.
>>>>
>>>> When FreeSWITCH terminates the call, the following is logged to the
>>>> console:
>>>>
>>>> 2011-06-22 13:33:50.514941 [DEBUG] sofia.c:4787 Channel
>>>> sofia/internal/1006 at public.ip.removed entering state [terminating][0]
>>>> 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 (
>>>> sofia/internal/1006 at public.ip.removed) Callstate Change ACTIVE ->
>>>> HANGUP
>>>> 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup
>>>> sofia/internal/1006 at public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED]
>>>> 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal
>>>> sofia/internal/1006 at public.ip.removed [KILL]
>>>> 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send
>>>> signal sofia/internal/1006 at public.ip.removed [BREAK]
>>>> 2011-06-22 13:33:50.534966 [DEBUG] switch_ivr_play_say.c:1649 done
>>>> playing file
>>>> 2011-06-22 13:33:50.625988 [DEBUG] switch_ivr_play_say.c:244 Handle
>>>> play-file:[voicemail/vm-press.wav] (en:en)
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_session.c:2063
>>>> sofia/internal/1006 at public.ip.removed skip receive message
>>>> [APPLICATION_EXEC_COMPLETE] (channel is hungup already)
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:371 (
>>>> sofia/internal/1006 at public.ip.removed) State EXECUTE going to sleep
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 (
>>>> sofia/internal/1006 at public.ip.removed) Running State Change CS_HANGUP
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:565 (
>>>> sofia/internal/1006 at public.ip.removed) State HANGUP
>>>> 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel
>>>> sofia/internal/1006 at public.ip.removed hanging up, cause:
>>>> NORMAL_UNSPECIFIED
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:46
>>>> sofia/internal/1006 at public.ip.removed Standard HANGUP, cause:
>>>> NORMAL_UNSPECIFIED
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:565 (
>>>> sofia/internal/1006 at public.ip.removed) State HANGUP going to sleep
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:356 (
>>>> sofia/internal/1006 at public.ip.removed) State Change CS_HANGUP ->
>>>> CS_REPORTING
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_session.c:1118 Send
>>>> signal sofia/internal/1006 at public.ip.removed [BREAK]
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 (
>>>> sofia/internal/1006 at public.ip.removed) Running State Change
>>>> CS_REPORTING
>>>> 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:625 (
>>>> sofia/internal/1006 at public.ip.removed) State REPORTING
>>>> 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53
>>>> sofia/internal/1006 at public.ip.removed Standard REPORTING, cause:
>>>> NORMAL_UNSPECIFIED
>>>> 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:625 (
>>>> sofia/internal/1006 at public.ip.removed) State REPORTING going to sleep
>>>> 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:350 (
>>>> sofia/internal/1006 at public.ip.removed) State Change CS_REPORTING ->
>>>> CS_DESTROY
>>>> 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1118 Send
>>>> signal sofia/internal/1006 at public.ip.removed [BREAK]
>>>> 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5
>>>> (sofia/internal/1006 at public.ip.removed) Locked, Waiting on external
>>>> entities
>>>> 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1308 Session 5
>>>> (sofia/internal/1006 at public.ip.removed) Ended
>>>> 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close
>>>> Channel sofia/internal/1006 at public.ip.removed [CS_DESTROY]
>>>> 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 (
>>>> sofia/internal/1006 at public.ip.removed) Callstate Change HANGUP -> DOWN
>>>> 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 (
>>>> sofia/internal/1006 at public.ip.removed) Running State Change CS_DESTROY
>>>> 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:467 (
>>>> sofia/internal/1006 at public.ip.removed) State DESTROY
>>>> 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363
>>>> sofia/internal/1006 at public.ip.removed SOFIA DESTROY
>>>> 2011-06-22 13:33:50.780056 [DEBUG] switch_nat.c:570 unmapped public port
>>>> 31484 protocol UDP to localport 31484
>>>> 2011-06-22 13:33:50.840070 [DEBUG] switch_nat.c:570 unmapped public port
>>>> 31485 protocol UDP to localport 31485
>>>> 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:60
>>>> sofia/internal/1006 at public.ip.removed Standard DESTROY
>>>> 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 (
>>>> sofia/internal/1006 at public.ip.removed) State DESTROY going to sleep
>>>>
>>>> The above example was from an externally situated SIP phone ringing
>>>> voicemail (4000) on FreeSWITCH.
>>>>
>>>> I have experimented changing various timers and timeouts in the config
>>>> of FreeSWITCH (one at a time, being careful to put them back afterwards!)
>>>> but been unable to resolve the issue.
>>>>
>>>> Incidentally, we have no long term intention of running off-site SIP
>>>> phones with the PBX and I'm hoping not to have to leave it in the DMZ
>>>> either, it's just like that for debugging. What is a real issue is the calls
>>>> to our external SIP provider (i.e. outbound calls) being dropped.
>>>>
>>>> Any suggestions would be greatly appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> Matthew Ralston
>>>> Web Developer & IT Consultant
>>>>
>>>> matt at mralston.co.uk
>>>> www.mralston.com
>>>>
>>>>
>>>> _______________________________________________
>>>> Join us at ClueCon 2011, Aug 9-11, Chicago
>>>> http://www.cluecon.com 877-7-4ACLUE
>>>>
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> http://www.freeswitch.org
>>>>
>>>
>>> _______________________________________________
>>> Join us at ClueCon 2011, Aug 9-11, Chicago
>>> http://www.cluecon.com 877-7-4ACLUE
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Join us at ClueCon 2011, Aug 9-11, Chicago
>>> http://www.cluecon.com 877-7-4ACLUE
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>> _______________________________________________
>> Join us at ClueCon 2011, Aug 9-11, Chicago
>> http://www.cluecon.com 877-7-4ACLUE
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>>
>> _______________________________________________
>> Join us at ClueCon 2011, Aug 9-11, Chicago
>> http://www.cluecon.com 877-7-4ACLUE
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
> _______________________________________________
> Join us at ClueCon 2011, Aug 9-11, Chicago
> http://www.cluecon.com 877-7-4ACLUE
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110624/dca7d6c3/attachment-0001.html 