Hi All, Apologies for the simple question but I can't find the answer anywhere in the books, wiki, or our friend google. If somebody calls us, FS does an ORIGINATE_CANCEL after 60s but the follow-me scheme we have configured is100s. How can I increase the default call_timeout of 60s to 100s? Or maybe I am just doing something wrong! I have tried leg_timeouts, originate_timeouts both on the transfer and the bridge as well to no avail? Would be very grateful for any help or advise. Regards, Steve Some Details: - External call comes in on external profile from our voip provider. - Dialplan in the public context does a transfer to a follow-me extension 7777 in context creche-babys <action application="transfer" data="7777 XML creche-babys "/> - The 7777 extension is as follows and the call hangs up part way through the third step if nobody picks up (after 60s total). <extension name="creche-fm"> <condition field="destination_number" expression="^7777$"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="ringback=${nl-ring}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/21@${domain_name},user/20@${domain_name}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/22@${domain_name}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data={ignore_early_media=true}user/23@${domain_name},user/24@${domain_name},user/26@${domain_name},user/27@${domain_name},user/28@${domain_name}"/> <action application="set" data="ringback=${nl-ring}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}sofia/gateway/3120 ...voipprovidergateway/06 ...mobile number"/> </condition> </extension>
I'm not sure if this will help, but try setting the following before each bridge. It might be that they get reset to defaults after the first bridge attempt. <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> On Fri, Mar 22, 2013 at 8:32 AM, Stephen Thwaites < stephen.thwaites@callstera.com> wrote:
Hi All, Apologies for the simple question but I can't find the answer anywhere in the books, wiki, or our friend google.
If somebody calls us, FS does an ORIGINATE_CANCEL after 60s but the follow-me scheme we have configured is100s. How can I increase the default call_timeout of 60s to 100s? Or maybe I am just doing something wrong!
I have tried leg_timeouts, originate_timeouts both on the transfer and the bridge as well to no avail?
Would be very grateful for any help or advise.
Regards, Steve
Some Details: - External call comes in on external profile from our voip provider. - Dialplan in the public context does a transfer to a follow-me extension 7777 in context creche-babys <action application="transfer" data="7777 XML creche-babys "/> - The 7777 extension is as follows and the call hangs up part way through the third step if nobody picks up (after 60s total).
<extension name="creche-fm"> <condition field="destination_number" expression="^7777$"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="ringback=${nl-ring}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/21@${domain_name},user/20@ ${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/22@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data={ignore_early_media=true}user/23@${domain_name},user/24@ ${domain_name},user/26@${domain_name},user/27@${domain_name},user/28@ ${domain_name}"/>
<action application="set" data="ringback=${nl-ring}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}sofia/gateway/3120 ...voipprovidergateway/06 ...mobile number"/>
</condition> </extension>
_________________________________________________________________________ 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
Try "export" instead of "set" on your call_timeout=25 lines. -MC On Fri, Mar 22, 2013 at 8:32 AM, Stephen Thwaites < stephen.thwaites@callstera.com> wrote:
Hi All, Apologies for the simple question but I can't find the answer anywhere in the books, wiki, or our friend google.
If somebody calls us, FS does an ORIGINATE_CANCEL after 60s but the follow-me scheme we have configured is100s. How can I increase the default call_timeout of 60s to 100s? Or maybe I am just doing something wrong!
I have tried leg_timeouts, originate_timeouts both on the transfer and the bridge as well to no avail?
Would be very grateful for any help or advise.
Regards, Steve
Some Details: - External call comes in on external profile from our voip provider. - Dialplan in the public context does a transfer to a follow-me extension 7777 in context creche-babys <action application="transfer" data="7777 XML creche-babys "/> - The 7777 extension is as follows and the call hangs up part way through the third step if nobody picks up (after 60s total).
<extension name="creche-fm"> <condition field="destination_number" expression="^7777$"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="ringback=${nl-ring}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/21@${domain_name},user/20@ ${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/22@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data={ignore_early_media=true}user/23@${domain_name},user/24@ ${domain_name},user/26@${domain_name},user/27@${domain_name},user/28@ ${domain_name}"/>
<action application="set" data="ringback=${nl-ring}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}sofia/gateway/3120 ...voipprovidergateway/06 ...mobile number"/>
</condition> </extension>
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
Nick, Michael, Thanks for the advise, will give these a try and feed back to the list. Regards, Steve. On Mon, Mar 25, 2013 at 11:21 PM, Michael Collins <msc@freeswitch.org> wrote:
Try "export" instead of "set" on your call_timeout=25 lines. -MC
On Fri, Mar 22, 2013 at 8:32 AM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Hi All, Apologies for the simple question but I can't find the answer anywhere in the books, wiki, or our friend google.
If somebody calls us, FS does an ORIGINATE_CANCEL after 60s but the follow-me scheme we have configured is100s. How can I increase the default call_timeout of 60s to 100s? Or maybe I am just doing something wrong!
I have tried leg_timeouts, originate_timeouts both on the transfer and the bridge as well to no avail?
Would be very grateful for any help or advise.
Regards, Steve
Some Details: - External call comes in on external profile from our voip provider. - Dialplan in the public context does a transfer to a follow-me extension 7777 in context creche-babys <action application="transfer" data="7777 XML creche-babys "/> - The 7777 extension is as follows and the call hangs up part way through the third step if nobody picks up (after 60s total).
<extension name="creche-fm"> <condition field="destination_number" expression="^7777$"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="ringback=${nl-ring}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge"
data="{ignore_early_media=true}user/21@${domain_name},user/20@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/22@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge"
data={ignore_early_media=true}user/23@${domain_name},user/24@${domain_name},user/26@${domain_name},user/27@${domain_name},user/28@${domain_name}"/>
<action application="set" data="ringback=${nl-ring}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}sofia/gateway/3120 ...voipprovidergateway/06 ...mobile number"/>
</condition> </extension>
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ 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
Hello, I have setup this scenario now with a test case and have tried using the 'export' application instead of 'set' for the call_timeout=25. Sadly the same behavior. Similarly no change when using hangup_after_bridge=true and continue_on_fail=true before each bridge as suggested. Further I have tried using originate_timeout=25 and also experimented with leg_timeouts. I then wondered if the voip provider set a timeout on the incoming call and they do, but this is set to 120s. I all tests I get an ORIGINATOR_CANCEL after 60s. I then did a sip trace and log level 6 from the fs_cli. Here is the (I think) the relevant bit that shows that FS is sending a CANCEL to the telephones. Any further help would be appreciated! Regards, Steve. 2013-03-29 15:41:55.117929 [NOTICE] sofia.c:6379 Hangup sofia/external/0610884128@91.195.160.3 [CS_EXECUTE] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1000@192.168.1.113:45060 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1001@192.168.1.112:35160 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1002@192.168.1.10:49535 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [INFO] mod_dptools.c:3052 Originate Failed. Cause: ORIGINATOR_CANCEL 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9911 (sofia/external/0610884128@91.195.160.3) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/external/0610884128@91.195.160.3 [CS_DESTROY] 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9917 (sofia/internal/sip:1000@192.168.1.113:45060) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1000@192.168.1.113:45060 [CS_DESTROY] send 429 bytes to udp/[80.101.42.120]:52292 at 14:43:27.409611: ------------------------------------------------------------------------ CANCEL sip:1000@192.168.1.113:45060 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK5H6X2DKX8Dj1N Route: <sip:1000@80.101.42.120:52292> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=1rv4jNU086aaQ To: <sip:1000@192.168.1.113:45060> Call-ID: d6322816-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0 ------------------------------------------------------------------------ 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9918 (sofia/internal/sip:1001@192.168.1.112:35160) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1001@192.168.1.112:35160 [CS_DESTROY] send 429 bytes to udp/[80.101.42.120]:42328 at 14:43:27.410670: ------------------------------------------------------------------------ CANCEL sip:1001@192.168.1.112:35160 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK6tZp48305p8KH Route: <sip:1001@80.101.42.120:42328> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=21NXmgc45F1vj To: <sip:1001@192.168.1.112:35160> Call-ID: d6335070-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0 ------------------------------------------------------------------------ 2013-03-29 15:41:55.127924 [NOTICE] switch_core_session.c:1505 Session 9919 (sofia/internal/sip:1002@192.168.1.10:49535) Ended 2013-03-29 15:41:55.127924 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1002@192.168.1.10:49535 [CS_DESTROY] send 427 bytes to udp/[80.101.42.120]:50175 at 14:43:27.413100: ------------------------------------------------------------------------ CANCEL sip:1002@192.168.1.10:49535 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK73rF63m42Zy6c Route: <sip:1002@80.101.42.120:50175> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535> Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0 ------------------------------------------------------------------------ recv 531 bytes from udp/[80.101.42.120]:50175 at 14:43:27.440064: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 94.100.113.237;rport=5060;branch=z9hG4bK73rF63m42Zy6c From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Contact: <sip:1002@192.168.1.10:49535> Supported: replaces, path, timer, eventlist User-Agent: Grandstream GXP2200 1.0.1.40 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 ------------------------------------------------------------------------ recv 507 bytes from udp/[80.101.42.120]:50175 at 14:43:27.445183: ------------------------------------------------------------------------ SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP 94.100.113.237;rport=5060;branch=z9hG4bK73rF63m42Zy6c From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 INVITE Supported: replaces, path, timer, eventlist User-Agent: Grandstream GXP2200 1.0.1.40 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 ------------------------------------------------------------------------ send 387 bytes to udp/[80.101.42.120]:50175 at 14:43:27.445316: ------------------------------------------------------------------------ ACK sip:1002@192.168.1.10:49535 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK73rF63m42Zy6c Route: <sip:1002@80.101.42.120:50175> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 ACK Content-Length: 0 etc... On Tue, Mar 26, 2013 at 12:22 AM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Nick, Michael, Thanks for the advise, will give these a try and feed back to the list.
Regards, Steve.
On Mon, Mar 25, 2013 at 11:21 PM, Michael Collins <msc@freeswitch.org> wrote:
Try "export" instead of "set" on your call_timeout=25 lines. -MC
On Fri, Mar 22, 2013 at 8:32 AM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Hi All, Apologies for the simple question but I can't find the answer anywhere in the books, wiki, or our friend google.
If somebody calls us, FS does an ORIGINATE_CANCEL after 60s but the follow-me scheme we have configured is100s. How can I increase the default call_timeout of 60s to 100s? Or maybe I am just doing something wrong!
I have tried leg_timeouts, originate_timeouts both on the transfer and the bridge as well to no avail?
Would be very grateful for any help or advise.
Regards, Steve
Some Details: - External call comes in on external profile from our voip provider. - Dialplan in the public context does a transfer to a follow-me extension 7777 in context creche-babys <action application="transfer" data="7777 XML creche-babys "/> - The 7777 extension is as follows and the call hangs up part way through the third step if nobody picks up (after 60s total).
<extension name="creche-fm"> <condition field="destination_number" expression="^7777$"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="ringback=${nl-ring}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge"
data="{ignore_early_media=true}user/21@${domain_name},user/20@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/22@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge"
data={ignore_early_media=true}user/23@${domain_name},user/24@${domain_name},user/26@${domain_name},user/27@${domain_name},user/28@${domain_name}"/>
<action application="set" data="ringback=${nl-ring}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}sofia/gateway/3120 ...voipprovidergateway/06 ...mobile number"/>
</condition> </extension>
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ 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
Hello all, I still haven't managed to solve this one. Any further tips would be greatly appreciated. I feel that I am experimenting with various parameters without a full understanding of what the behavior should be. The A leg (caller) hits the dialplan in public, the public dialplan finds a match and transfers to the appropriate dialplan in corresponding context, this extension then uses 'set' or 'export' on the call_timeout variable and attempts a bridge. Does this 'set' set a timeout for the A leg or B leg? If I use 'export' does it set the timeout for both legs? Last of all does setting or exporting the call_timeout override the default bridge timeout of 60s? Many thanks. Regards, Steve. On Fri, Mar 29, 2013 at 4:50 PM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Hello, I have setup this scenario now with a test case and have tried using the 'export' application instead of 'set' for the call_timeout=25. Sadly the same behavior. Similarly no change when using hangup_after_bridge=true and continue_on_fail=true before each bridge as suggested. Further I have tried using originate_timeout=25 and also experimented with leg_timeouts. I then wondered if the voip provider set a timeout on the incoming call and they do, but this is set to 120s. I all tests I get an ORIGINATOR_CANCEL after 60s.
I then did a sip trace and log level 6 from the fs_cli. Here is the (I think) the relevant bit that shows that FS is sending a CANCEL to the telephones.
Any further help would be appreciated!
Regards, Steve.
2013-03-29 15:41:55.117929 [NOTICE] sofia.c:6379 Hangup sofia/external/0610884128@91.195.160.3 [CS_EXECUTE] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1000@192.168.1.113:45060 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1001@192.168.1.112:35160 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1002@192.168.1.10:49535 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [INFO] mod_dptools.c:3052 Originate Failed. Cause: ORIGINATOR_CANCEL 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9911 (sofia/external/0610884128@91.195.160.3) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/external/0610884128@91.195.160.3 [CS_DESTROY] 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9917 (sofia/internal/sip:1000@192.168.1.113:45060) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1000@192.168.1.113:45060 [CS_DESTROY] send 429 bytes to udp/[80.101.42.120]:52292 at 14:43:27.409611: ------------------------------------------------------------------------ CANCEL sip:1000@192.168.1.113:45060 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK5H6X2DKX8Dj1N Route: <sip:1000@80.101.42.120:52292> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=1rv4jNU086aaQ To: <sip:1000@192.168.1.113:45060> Call-ID: d6322816-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0
------------------------------------------------------------------------ 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9918 (sofia/internal/sip:1001@192.168.1.112:35160) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1001@192.168.1.112:35160 [CS_DESTROY] send 429 bytes to udp/[80.101.42.120]:42328 at 14:43:27.410670: ------------------------------------------------------------------------ CANCEL sip:1001@192.168.1.112:35160 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK6tZp48305p8KH Route: <sip:1001@80.101.42.120:42328> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=21NXmgc45F1vj To: <sip:1001@192.168.1.112:35160> Call-ID: d6335070-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0
------------------------------------------------------------------------ 2013-03-29 15:41:55.127924 [NOTICE] switch_core_session.c:1505 Session 9919 (sofia/internal/sip:1002@192.168.1.10:49535) Ended 2013-03-29 15:41:55.127924 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1002@192.168.1.10:49535 [CS_DESTROY] send 427 bytes to udp/[80.101.42.120]:50175 at 14:43:27.413100: ------------------------------------------------------------------------ CANCEL sip:1002@192.168.1.10:49535 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK73rF63m42Zy6c Route: <sip:1002@80.101.42.120:50175> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535> Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0
------------------------------------------------------------------------ recv 531 bytes from udp/[80.101.42.120]:50175 at 14:43:27.440064: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 94.100.113.237;rport=5060;branch=z9hG4bK73rF63m42Zy6c From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Contact: <sip:1002@192.168.1.10:49535> Supported: replaces, path, timer, eventlist User-Agent: Grandstream GXP2200 1.0.1.40 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0
------------------------------------------------------------------------ recv 507 bytes from udp/[80.101.42.120]:50175 at 14:43:27.445183: ------------------------------------------------------------------------ SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP 94.100.113.237;rport=5060;branch=z9hG4bK73rF63m42Zy6c From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 INVITE Supported: replaces, path, timer, eventlist User-Agent: Grandstream GXP2200 1.0.1.40 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0
------------------------------------------------------------------------ send 387 bytes to udp/[80.101.42.120]:50175 at 14:43:27.445316: ------------------------------------------------------------------------ ACK sip:1002@192.168.1.10:49535 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK73rF63m42Zy6c Route: <sip:1002@80.101.42.120:50175> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 ACK Content-Length: 0
etc...
On Tue, Mar 26, 2013 at 12:22 AM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Nick, Michael, Thanks for the advise, will give these a try and feed back to the list.
Regards, Steve.
On Mon, Mar 25, 2013 at 11:21 PM, Michael Collins <msc@freeswitch.org> wrote:
Try "export" instead of "set" on your call_timeout=25 lines. -MC
On Fri, Mar 22, 2013 at 8:32 AM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Hi All, Apologies for the simple question but I can't find the answer anywhere in the books, wiki, or our friend google.
If somebody calls us, FS does an ORIGINATE_CANCEL after 60s but the follow-me scheme we have configured is100s. How can I increase the default call_timeout of 60s to 100s? Or maybe I am just doing something wrong!
I have tried leg_timeouts, originate_timeouts both on the transfer and the bridge as well to no avail?
Would be very grateful for any help or advise.
Regards, Steve
Some Details: - External call comes in on external profile from our voip provider. - Dialplan in the public context does a transfer to a follow-me extension 7777 in context creche-babys <action application="transfer" data="7777 XML creche-babys "/> - The 7777 extension is as follows and the call hangs up part way through the third step if nobody picks up (after 60s total).
<extension name="creche-fm"> <condition field="destination_number" expression="^7777$"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="ringback=${nl-ring}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge"
data="{ignore_early_media=true}user/21@${domain_name},user/20@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/22@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge"
data={ignore_early_media=true}user/23@${domain_name},user/24@${domain_name},user/26@${domain_name},user/27@${domain_name},user/28@${domain_name}"/>
<action application="set" data="ringback=${nl-ring}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}sofia/gateway/3120 ...voipprovidergateway/06 ...mobile number"/>
</condition> </extension>
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ 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
Hello, Just to close this down. It seems that most of the telco companies in the Netherlands cancel the origination after 60s. This is the issue and nothing to do with FS. When working within the 60s the call_timeout parameter works perfectly. Regards, Steve. On Wed, Apr 10, 2013 at 6:03 PM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Hello all, I still haven't managed to solve this one. Any further tips would be greatly appreciated.
I feel that I am experimenting with various parameters without a full understanding of what the behavior should be. The A leg (caller) hits the dialplan in public, the public dialplan finds a match and transfers to the appropriate dialplan in corresponding context, this extension then uses 'set' or 'export' on the call_timeout variable and attempts a bridge. Does this 'set' set a timeout for the A leg or B leg? If I use 'export' does it set the timeout for both legs? Last of all does setting or exporting the call_timeout override the default bridge timeout of 60s?
Many thanks.
Regards, Steve.
On Fri, Mar 29, 2013 at 4:50 PM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Hello, I have setup this scenario now with a test case and have tried using the 'export' application instead of 'set' for the call_timeout=25. Sadly the same behavior. Similarly no change when using hangup_after_bridge=true and continue_on_fail=true before each bridge as suggested. Further I have tried using originate_timeout=25 and also experimented with leg_timeouts. I then wondered if the voip provider set a timeout on the incoming call and they do, but this is set to 120s. I all tests I get an ORIGINATOR_CANCEL after 60s.
I then did a sip trace and log level 6 from the fs_cli. Here is the (I think) the relevant bit that shows that FS is sending a CANCEL to the telephones.
Any further help would be appreciated!
Regards, Steve.
2013-03-29 15:41:55.117929 [NOTICE] sofia.c:6379 Hangup sofia/external/0610884128@91.195.160.3 [CS_EXECUTE] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1000@192.168.1.113:45060 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1001@192.168.1.112:35160 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [NOTICE] switch_ivr_originate.c:3349 Hangup sofia/internal/sip:1002@192.168.1.10:49535 [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL] 2013-03-29 15:41:55.117929 [INFO] mod_dptools.c:3052 Originate Failed. Cause: ORIGINATOR_CANCEL 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9911 (sofia/external/0610884128@91.195.160.3) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/external/0610884128@91.195.160.3 [CS_DESTROY] 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9917 (sofia/internal/sip:1000@192.168.1.113:45060) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1000@192.168.1.113:45060 [CS_DESTROY] send 429 bytes to udp/[80.101.42.120]:52292 at 14:43:27.409611: ------------------------------------------------------------------------ CANCEL sip:1000@192.168.1.113:45060 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK5H6X2DKX8Dj1N Route: <sip:1000@80.101.42.120:52292> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=1rv4jNU086aaQ To: <sip:1000@192.168.1.113:45060> Call-ID: d6322816-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0
------------------------------------------------------------------------ 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1505 Session 9918 (sofia/internal/sip:1001@192.168.1.112:35160) Ended 2013-03-29 15:41:55.117929 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1001@192.168.1.112:35160 [CS_DESTROY] send 429 bytes to udp/[80.101.42.120]:42328 at 14:43:27.410670: ------------------------------------------------------------------------ CANCEL sip:1001@192.168.1.112:35160 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK6tZp48305p8KH Route: <sip:1001@80.101.42.120:42328> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=21NXmgc45F1vj To: <sip:1001@192.168.1.112:35160> Call-ID: d6335070-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0
------------------------------------------------------------------------ 2013-03-29 15:41:55.127924 [NOTICE] switch_core_session.c:1505 Session 9919 (sofia/internal/sip:1002@192.168.1.10:49535) Ended 2013-03-29 15:41:55.127924 [NOTICE] switch_core_session.c:1509 Close Channel sofia/internal/sip:1002@192.168.1.10:49535 [CS_DESTROY] send 427 bytes to udp/[80.101.42.120]:50175 at 14:43:27.413100: ------------------------------------------------------------------------ CANCEL sip:1002@192.168.1.10:49535 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK73rF63m42Zy6c Route: <sip:1002@80.101.42.120:50175> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535> Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Reason: SIP;cause=487;text="ORIGINATOR_CANCEL" Content-Length: 0
------------------------------------------------------------------------ recv 531 bytes from udp/[80.101.42.120]:50175 at 14:43:27.440064: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 94.100.113.237;rport=5060;branch=z9hG4bK73rF63m42Zy6c From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 CANCEL Contact: <sip:1002@192.168.1.10:49535> Supported: replaces, path, timer, eventlist User-Agent: Grandstream GXP2200 1.0.1.40 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0
------------------------------------------------------------------------ recv 507 bytes from udp/[80.101.42.120]:50175 at 14:43:27.445183: ------------------------------------------------------------------------ SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP 94.100.113.237;rport=5060;branch=z9hG4bK73rF63m42Zy6c From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 INVITE Supported: replaces, path, timer, eventlist User-Agent: Grandstream GXP2200 1.0.1.40 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0
------------------------------------------------------------------------ send 387 bytes to udp/[80.101.42.120]:50175 at 14:43:27.445316: ------------------------------------------------------------------------ ACK sip:1002@192.168.1.10:49535 SIP/2.0 Via: SIP/2.0/UDP 94.100.113.237;rport;branch=z9hG4bK73rF63m42Zy6c Route: <sip:1002@80.101.42.120:50175> Max-Forwards: 67 From: "Thwaites, Stephen" <sip:0610884128@voiptest.callstera.com>;tag=3aFppBX72rQFe To: <sip:1002@192.168.1.10:49535>;tag=942234751 Call-ID: d634a26a-1321-1231-80a7-fa163e468f82 CSeq: 41948035 ACK Content-Length: 0
etc...
On Tue, Mar 26, 2013 at 12:22 AM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Nick, Michael, Thanks for the advise, will give these a try and feed back to the list.
Regards, Steve.
On Mon, Mar 25, 2013 at 11:21 PM, Michael Collins <msc@freeswitch.org> wrote:
Try "export" instead of "set" on your call_timeout=25 lines. -MC
On Fri, Mar 22, 2013 at 8:32 AM, Stephen Thwaites <stephen.thwaites@callstera.com> wrote:
Hi All, Apologies for the simple question but I can't find the answer anywhere in the books, wiki, or our friend google.
If somebody calls us, FS does an ORIGINATE_CANCEL after 60s but the follow-me scheme we have configured is100s. How can I increase the default call_timeout of 60s to 100s? Or maybe I am just doing something wrong!
I have tried leg_timeouts, originate_timeouts both on the transfer and the bridge as well to no avail?
Would be very grateful for any help or advise.
Regards, Steve
Some Details: - External call comes in on external profile from our voip provider. - Dialplan in the public context does a transfer to a follow-me extension 7777 in context creche-babys <action application="transfer" data="7777 XML creche-babys "/> - The 7777 extension is as follows and the call hangs up part way through the third step if nobody picks up (after 60s total).
<extension name="creche-fm"> <condition field="destination_number" expression="^7777$"> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="ringback=${nl-ring}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge"
data="{ignore_early_media=true}user/21@${domain_name},user/20@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}user/22@${domain_name}"/>
<action application="set" data="call_timeout=25"/> <action application="bridge"
data={ignore_early_media=true}user/23@${domain_name},user/24@${domain_name},user/26@${domain_name},user/27@${domain_name},user/28@${domain_name}"/>
<action application="set" data="ringback=${nl-ring}"/> <action application="set" data="call_timeout=25"/> <action application="bridge" data="{ignore_early_media=true}sofia/gateway/3120 ...voipprovidergateway/06 ...mobile number"/>
</condition> </extension>
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ 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 (3)
-
Michael Collins
-
Nick Vines
-
Stephen Thwaites