[Freeswitch-users] Call drops after 30 seconds
Jack
jack at livecall.com
Thu Jul 14 12:28:48 MSD 2011
Michael,
We were having the 30 second drop problem also. We are not behind a NAT.
We changed both values to $${local_ip_v4} and it worked great.
Thanks,
Jack
On 6/23/2011 11:32 AM, Michael Collins 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 <mailto: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 <mailto:matt at mralston.co.uk>
> www.mralston.com <http://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 <mailto: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 <mailto:matt at mralston.co.uk>
>> www.mralston.com <http://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 <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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 <mailto:matt at mralston.co.uk>
>>> www.mralston.com <http://www.mralston.com/>
>>>
>>>
>>> _______________________________________________
>>> Join us at ClueCon 2011, Aug 9-11, Chicago
>>> http://www.cluecon.com <http://www.cluecon.com/>
>>> 877-7-4ACLUE
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> <mailto: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 <http://www.freeswitch.org/>
>>>
>>>
>>> _______________________________________________
>>> Join us at ClueCon 2011, Aug 9-11, Chicago
>>> http://www.cluecon.com <http://www.cluecon.com/> 877-7-4ACLUE
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> <mailto: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 <http://www.freeswitch.org/>
>>
>>
>> _______________________________________________
>> Join us at ClueCon 2011, Aug 9-11, Chicago
>> http://www.cluecon.com <http://www.cluecon.com/> 877-7-4ACLUE
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> <mailto: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 <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
>> <mailto: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
> <mailto: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/20110714/aeed4d02/attachment-0001.html
More information about the FreeSWITCH-users
mailing list