Running FS 1.2.12 in the following environment: FS Ext <---> FS SBC <---> FS Int I can successfully make calls in both directions. If the caller hangs up, the other end correctly hangs up. However, if the callee hangs up, the caller session remains active until the RTP timeout kicks in. Here's a snippet from the FS log where this occurs (1004 is the caller and 2010 is the callee) [NOTICE] sofia.c:716 Hangup sofia/internal/2010@10.1.1.206:5061[CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_ivr_bridge.c:1109 Hangup sofia/internal/1004@10.1.1.204[CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_core_session.c:1560 Session 4 (sofia/internal/ 2010@10.1.1.206:5061) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/ 2010@10.1.1.206:5061 [CS_DESTROY] [NOTICE] switch_core_session.c:1560 Session 3 (sofia/internal/ 1004@10.1.1.104) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/ 1004@10.1.1.104 [CS_DESTROY] I've tried setting hangup_after_bridge=true in the dialplan on FS Ext. I wasn't 100% sure whether it should go on FS Ext or FS SBC, so I tried both and it made no difference. What else should I be checking? Thanks Peter
Check out sip trace.. sounds like a BYE is not getting somewhere. On Aug 19, 2013, at 2:02 AM, Peter <eidevm5@gmail.com> wrote:
Running FS 1.2.12 in the following environment:
FS Ext <---> FS SBC <---> FS Int
I can successfully make calls in both directions.
If the caller hangs up, the other end correctly hangs up.
However, if the callee hangs up, the caller session remains active until the RTP timeout kicks in.
Here's a snippet from the FS log where this occurs (1004 is the caller and 2010 is the callee)
[NOTICE] sofia.c:716 Hangup sofia/internal/2010@10.1.1.206:5061 [CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_ivr_bridge.c:1109 Hangup sofia/internal/1004@10.1.1.204 [CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_core_session.c:1560 Session 4 (sofia/internal/2010@10.1.1.206:5061) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/2010@10.1.1.206:5061 [CS_DESTROY] [NOTICE] switch_core_session.c:1560 Session 3 (sofia/internal/1004@10.1.1.104) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/1004@10.1.1.104 [CS_DESTROY]
I've tried setting hangup_after_bridge=true in the dialplan on FS Ext. I wasn't 100% sure whether it should go on FS Ext or FS SBC, so I tried both and it made no difference.
What else should I be checking?
It appears the BYE is getting through on both ends (although I'm not 100% familiar with the full SIP handshake). Here's the SIP trace for the caller (ie: the end that isn't hanging up) http://pastebin.freeswitch.org/21328 and here's the SIP trace for the callee (ie: the end the call is hung up) http://pastebin.freeswitch.org/21329 I'm not sure if having TLS and inbound-bypass-media set on FS1 are having any affect on this problem or not. On Tue, Aug 20, 2013 at 1:51 AM, Michael Jerris <mike@jerris.com> wrote:
Check out sip trace.. sounds like a BYE is not getting somewhere.
On Aug 19, 2013, at 2:02 AM, Peter <eidevm5@gmail.com> wrote:
Running FS 1.2.12 in the following environment:
FS Ext <---> FS SBC <---> FS Int
I can successfully make calls in both directions.
If the caller hangs up, the other end correctly hangs up.
However, if the callee hangs up, the caller session remains active until the RTP timeout kicks in.
Here's a snippet from the FS log where this occurs (1004 is the caller and 2010 is the callee)
[NOTICE] sofia.c:716 Hangup sofia/internal/2010@10.1.1.206:5061[CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_ivr_bridge.c:1109 Hangup sofia/internal/1004@10.1.1.204[CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_core_session.c:1560 Session 4 (sofia/internal/ 2010@10.1.1.206:5061) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/ 2010@10.1.1.206:5061 [CS_DESTROY] [NOTICE] switch_core_session.c:1560 Session 3 (sofia/internal/ 1004@10.1.1.104) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/ 1004@10.1.1.104 [CS_DESTROY]
I've tried setting hangup_after_bridge=true in the dialplan on FS Ext. I wasn't 100% sure whether it should go on FS Ext or FS SBC, so I tried both and it made no difference.
What else should I be checking?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Also just noticed that I'm getting the message: nua_server.c:155 nua_stack_process_request() nua(0x7fe54c054880): strange ACK from <sip:1004@10.1.1.204> Not sure what that means. On Tue, Aug 20, 2013 at 10:47 AM, Peter <eidevm5@gmail.com> wrote:
It appears the BYE is getting through on both ends (although I'm not 100% familiar with the full SIP handshake).
Here's the SIP trace for the caller (ie: the end that isn't hanging up)
http://pastebin.freeswitch.org/21328
and here's the SIP trace for the callee (ie: the end the call is hung up)
http://pastebin.freeswitch.org/21329
I'm not sure if having TLS and inbound-bypass-media set on FS1 are having any affect on this problem or not.
On Tue, Aug 20, 2013 at 1:51 AM, Michael Jerris <mike@jerris.com> wrote:
Check out sip trace.. sounds like a BYE is not getting somewhere.
On Aug 19, 2013, at 2:02 AM, Peter <eidevm5@gmail.com> wrote:
Running FS 1.2.12 in the following environment:
FS Ext <---> FS SBC <---> FS Int
I can successfully make calls in both directions.
If the caller hangs up, the other end correctly hangs up.
However, if the callee hangs up, the caller session remains active until the RTP timeout kicks in.
Here's a snippet from the FS log where this occurs (1004 is the caller and 2010 is the callee)
[NOTICE] sofia.c:716 Hangup sofia/internal/2010@10.1.1.206:5061[CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_ivr_bridge.c:1109 Hangup sofia/internal/1004@10.1.1.204[CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_core_session.c:1560 Session 4 (sofia/internal/ 2010@10.1.1.206:5061) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/ 2010@10.1.1.206:5061 [CS_DESTROY] [NOTICE] switch_core_session.c:1560 Session 3 (sofia/internal/ 1004@10.1.1.104) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/ 1004@10.1.1.104 [CS_DESTROY]
I've tried setting hangup_after_bridge=true in the dialplan on FS Ext. I wasn't 100% sure whether it should go on FS Ext or FS SBC, so I tried both and it made no difference.
What else should I be checking?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Turns out that it looks like the version of Linphone I was using was not handling the hangup correctly. I compiled the latest Linphone version on another phone and the signalling works fine. On Tue, Aug 20, 2013 at 10:56 AM, Peter <eidevm5@gmail.com> wrote:
Also just noticed that I'm getting the message:
nua_server.c:155 nua_stack_process_request() nua(0x7fe54c054880): strange ACK from <sip:1004@10.1.1.204>
Not sure what that means.
On Tue, Aug 20, 2013 at 10:47 AM, Peter <eidevm5@gmail.com> wrote:
It appears the BYE is getting through on both ends (although I'm not 100% familiar with the full SIP handshake).
Here's the SIP trace for the caller (ie: the end that isn't hanging up)
http://pastebin.freeswitch.org/21328
and here's the SIP trace for the callee (ie: the end the call is hung up)
http://pastebin.freeswitch.org/21329
I'm not sure if having TLS and inbound-bypass-media set on FS1 are having any affect on this problem or not.
On Tue, Aug 20, 2013 at 1:51 AM, Michael Jerris <mike@jerris.com> wrote:
Check out sip trace.. sounds like a BYE is not getting somewhere.
On Aug 19, 2013, at 2:02 AM, Peter <eidevm5@gmail.com> wrote:
Running FS 1.2.12 in the following environment:
FS Ext <---> FS SBC <---> FS Int
I can successfully make calls in both directions.
If the caller hangs up, the other end correctly hangs up.
However, if the callee hangs up, the caller session remains active until the RTP timeout kicks in.
Here's a snippet from the FS log where this occurs (1004 is the caller and 2010 is the callee)
[NOTICE] sofia.c:716 Hangup sofia/internal/2010@10.1.1.206:5061[CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_ivr_bridge.c:1109 Hangup sofia/internal/1004@10.1.1.204[CS_HIBERNATE] [NORMAL_CLEARING] [NOTICE] switch_core_session.c:1560 Session 4 (sofia/internal/ 2010@10.1.1.206:5061) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/ 2010@10.1.1.206:5061 [CS_DESTROY] [NOTICE] switch_core_session.c:1560 Session 3 (sofia/internal/ 1004@10.1.1.104) Ended [NOTICE] switch_core_session.c:1564 Close Channel sofia/internal/ 1004@10.1.1.104 [CS_DESTROY]
I've tried setting hangup_after_bridge=true in the dialplan on FS Ext. I wasn't 100% sure whether it should go on FS Ext or FS SBC, so I tried both and it made no difference.
What else should I be checking?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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 (2)
-
Michael Jerris
-
Peter