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@public.ip.removed entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 (sofia/internal/1006@public.ip.removed) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@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@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@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@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@public.ip.removed) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@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@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 (sofia/internal/1006@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@public.ip.removed) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 (sofia/internal/1006@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@public.ip.removed) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 (sofia/internal/1006@public.ip.removed) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 (sofia/internal/1006@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@public.ip.removed) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@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@public.ip.removed Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1006@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@mralston.co.uk www.mralston.com
My two cents worth... I have fixed this in the past by setting up a STUND server to help with the SIP data. I had the same problem as you, 30 seconds on the dot the call would drop. After pointing my sip devices to a stun server everything is solved. (for me anyway :) HTH Matt On 22 June 2011 22:38, Matthew Ralston <freeswitch@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@public.ip.removed entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 (sofia/internal/1006@public.ip.removed) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@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@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@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@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@public.ip.removed) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@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@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 (sofia/internal/1006@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@public.ip.removed) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 (sofia/internal/1006@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@public.ip.removed) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 (sofia/internal/1006@public.ip.removed) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 (sofia/internal/1006@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@public.ip.removed) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@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@public.ip.removed Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1006@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@public.ip.removed entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 (sofia/internal/1006@public.ip.removed) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@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@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@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@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@public.ip.removed) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@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@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 (sofia/internal/1006@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@public.ip.removed) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 (sofia/internal/1006@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@public.ip.removed) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 (sofia/internal/1006@public.ip.removed) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 (sofia/internal/1006@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@public.ip.removed) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@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@public.ip.removed Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1006@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@public.ip.removed entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 (sofia/internal/1006@public.ip.removed) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@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@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@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@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@public.ip.removed) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@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@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 (sofia/internal/1006@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@public.ip.removed) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 (sofia/internal/1006@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@public.ip.removed) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 (sofia/internal/1006@public.ip.removed) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 (sofia/internal/1006@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@public.ip.removed) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@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@public.ip.removed Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1006@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@public.ip.removed entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 ( sofia/internal/1006@public.ip.removed) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@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@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@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@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@public.ip.removed) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@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@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 ( sofia/internal/1006@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@public.ip.removed) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 ( sofia/internal/1006@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@public.ip.removed) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 ( sofia/internal/1006@public.ip.removed) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 ( sofia/internal/1006@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@public.ip.removed) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@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@public.ip.removed Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 ( sofia/internal/1006@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@public.ip.removed entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 (sofia/internal/1006@public.ip.removed) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@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@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@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@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@public.ip.removed) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@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@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 (sofia/internal/1006@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@public.ip.removed) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 (sofia/internal/1006@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@public.ip.removed) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 (sofia/internal/1006@public.ip.removed) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 (sofia/internal/1006@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@public.ip.removed) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@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@public.ip.removed Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1006@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@public.ip.removed entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 ( sofia/internal/1006@public.ip.removed) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@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@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@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@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@public.ip.removed) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@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@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 ( sofia/internal/1006@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@public.ip.removed) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 ( sofia/internal/1006@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@public.ip.removed) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 ( sofia/internal/1006@public.ip.removed) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 ( sofia/internal/1006@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@public.ip.removed) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@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@public.ip.removed Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 ( sofia/internal/1006@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@public.ip.removed entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 ( sofia/internal/1006@public.ip.removed) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@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@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@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@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@public.ip.removed) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@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@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 ( sofia/internal/1006@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@public.ip.removed) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@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@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@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@public.ip.removed [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 (sofia/internal/1006@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@public.ip.removed) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 ( sofia/internal/1006@public.ip.removed) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 ( sofia/internal/1006@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@public.ip.removed) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@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@public.ip.removed Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 ( sofia/internal/1006@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@mralston.com <mailto:freeswitch@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@mralston.co.uk <mailto:matt@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@mralston.com <mailto:freeswitch@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@mralston.co.uk <mailto:matt@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@mralston.com <mailto:freeswitch@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@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed> entering state [terminating][0] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2641 (sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed>) Callstate Change ACTIVE -> HANGUP 2011-06-22 13:33:50.514941 [NOTICE] sofia.c:5508 Hangup sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed> [CS_EXECUTE] [NORMAL_UNSPECIFIED] 2011-06-22 13:33:50.514941 [DEBUG] switch_channel.c:2657 Send signal sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed> [KILL] 2011-06-22 13:33:50.514941 [DEBUG] switch_core_session.c:1118 Send signal sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed>) State HANGUP 2011-06-22 13:33:50.727027 [DEBUG] mod_sofia.c:458 Channel sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed> [BREAK] 2011-06-22 13:33:50.727027 [DEBUG] switch_core_state_machine.c:325 (sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed>) State REPORTING 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:53 sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed> [BREAK] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_session.c:1290 Session 5 (sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed>) Ended 2011-06-22 13:33:50.740064 [NOTICE] switch_core_session.c:1310 Close Channel sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed> [CS_DESTROY] 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:454 (sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed>) Callstate Change HANGUP -> DOWN 2011-06-22 13:33:50.740064 [DEBUG] switch_core_state_machine.c:457 (sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed>) State DESTROY 2011-06-22 13:33:50.740064 [DEBUG] mod_sofia.c:363 sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@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@public.ip.removed <mailto:sofia/internal/1006@public.ip.removed> Standard DESTROY 2011-06-22 13:33:50.840070 [DEBUG] switch_core_state_machine.c:467 (sofia/internal/1006@public.ip.removed <mailto:sofia/internal/1006@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@mralston.co.uk <mailto:matt@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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@lists.freeswitch.org <mailto:FreeSWITCH-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (6)
-
Chris Chen
-
Jack
-
Matt Paine
-
Matthew Ralston
-
Michael Collins
-
Nandy Dagondon