[Freeswitch-users] Call drops after 30 seconds

Thu Jun 23 22:32:56 MSD 2011

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110623/2929cbf7/attachment-0001.html 