We're seeing this same exact issue with a number of our phones (specifically CounterPath Bria for iOS and others). Calls placed disconnect after ~1:48 on some NATs, (specifically our wireless data carrier, AT&T 3G). http://lists.freeswitch.org/pipermail/freeswitch-users/2012-March/081317.htm... In freeswitch, the CLI shows: 2012-08-27 00:41:59.471201 [DEBUG] switch_core_session.c:1429 Session 174 (sofia/internal/2000@mydomain.com) Locked, Waiting on external entities 2012-08-27 00:41:59.471201 [NOTICE] switch_core_session.c:1447 Session 174 (sofia/internal/2000@mydomain.com) Ended 2012-08-27 00:41:59.471201 [NOTICE] switch_core_session.c:1449 Close Channel sofia/internal/2000@mydomain.com [CS_DESTROY] 2012-08-27 00:41:59.471201 [DEBUG] switch_core_state_machine.c:514 (sofia/internal/2000@mydomain.com) Callstate Change HANGUP -> DOWN 2012-08-27 00:41:59.471201 [DEBUG] switch_core_state_machine.c:517 (sofia/internal/2000@mydomain.com) Running State Change CS_DESTROY 2012-08-27 00:41:59.471201 [DEBUG] switch_core_state_machine.c:527 (sofia/internal/2000@mydomain.com) State DESTROY 2012-08-27 00:41:59.471201 [DEBUG] mod_sofia.c:374 sofia/internal/2000@mydomain.com SOFIA DESTROY 2012-08-27 00:41:59.471201 [DEBUG] switch_core_state_machine.c:86 sofia/internal/2000@mydomain.com Standard DESTROY 2012-08-27 00:41:59.471201 [DEBUG] switch_core_state_machine.c:527 (sofia/internal/2000@mydomain.com) State DESTROY going to sleep We fixed this by shutting of the "Passive Session Timer" in the "SIP Miscellaneous." However, I'm curious to know if anyone can explain why this happens on some NATs and not others? Is there s problem with disabling the "Passive Session Timer" on our clients? -Rob
On Sun, Aug 26, 2012 at 11:10 PM, R W <wingcomm@hotmail.com> wrote:
We fixed this by shutting of the "Passive Session Timer" in the "SIP Miscellaneous." However, I'm curious to know if anyone can explain why this happens on some NATs and not others? Is there s problem with disabling the "Passive Session Timer" on our clients?
I think you'll find it has less to do with NATing and more to do with the SIP user agent (UA) behind the NAT. If it *does* have to do with NATing, then it's likely the SIP 'helpers' getting in the way. Google ALG-based SIP-capable firewalls. Let us know what you find. Oh, and you'll want to check this at the SIP message level to get it figured out. Good luck! Best, Gabe
participants (2)
-
Gabriel Gunderson
-
R W