Orphaned calls left on FS after redirect off of FS
I am using the API to manage calls as they arrive at FS from a trunk I have a very simple Dial plan rule that parks the incoming call. <extension name="Trunk_02031701648"> <condition field="destination_number" expression="^02031701648$"> <action application="park" /> </condition> </extension> Once the call is parked via the API I first send a ringing (to keep the originator happy) sendmsg <uuid> call-command: execute execute-app-name: respond execute-app-arg: 180 Via the API I then redirect the call on to another PSTN number back through the same gateway sendmsg <UUID> call-command: execute execute-app-name: redirect execute-app-arg: sip:<destination>@194.0.147.16 The redirection works well and the originator and destination are connected correctly. But after the call has left FS I'm still left with some call debris which I cannot clear down using sendmsg <UUID> call-command: execute execute-app-name: hangup execute-app-arg: <cause code> Using command "api show channels" I find the following held on FS The only way I've found to remove these calls is "api hupall" ------------------------- uuid,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,appl ication,application_data,dialplan,context,read_codec,read_rate,write_cod ec,write_rate 132a3362-3bb2-8e46-a11b-9bd46ab2d706,2009-06-24 15:10:15,1245852615,sofia/TrunkExternal/0203196599@194.0.147.16:5060,CS_ EXECUTE,0203196599,0203196599, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 c2b40d55-0b5f-ff45-9541-cdcecc451e2c,2009-06-24 15:18:00,1245853080,sofia/TrunkExternal/0203196598@194.0.147.16:5060,CS_ EXECUTE,0203196598,0203196598, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 b03fa6b3-a436-db4b-add5-dfd0658b8867,2009-06-24 15:22:53,1245853373,sofia/TrunkExternal/0203196599@194.0.147.16:5060,CS_ EXECUTE,0203196599,0203196599, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 57ce0f01-a84d-6e49-a66d-0d771849ebb4,2009-06-24 15:40:30,1245854430,sofia/TrunkExternal/0189728400@194.0.147.16:5060,CS_ EXECUTE,0189728400,0189728400, 194.0.147.16,02031701648,redirect,sip:0701137881@194.0.147.16,XML,Public ,PCMA,8000,PCMA,8000 4 total. ------------------- The SIP signalling is correct with an outgoing "302 moved temporarily" [with the new destination in the contact] which is then Ack'ed by the switch. From a SIP point of view the call no longer on FS. The only way I've found to remove these phantom calls is either "api hupall", or restart the Sip profile. Any suggestions on how I can remove these phantom calls without recourse to "api hupall". "api hupall" kills any incoming calls as well as the stuck calls. Regards Richard Lamkin richard.lamkin@mettoni.com ************************************************************************* Please consider the environment before printing this e-mail ************************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN *************************************************************************
I have also observed that the cpu load goes up to 100% when only a couple of orphaned calls are left without being cleared by "api hupall". Richard Lamkin richard.lamkin@mettoni.com From: Richard Lamkin Sent: 24 June 2009 16:30 To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] Orphaned calls left on FS after redirect off of FS I am using the API to manage calls as they arrive at FS from a trunk I have a very simple Dial plan rule that parks the incoming call. <extension name="Trunk_02031701648"> <condition field="destination_number" expression="^02031701648$"> <action application="park" /> </condition> </extension> Once the call is parked via the API I first send a ringing (to keep the originator happy) sendmsg <uuid> call-command: execute execute-app-name: respond execute-app-arg: 180 Via the API I then redirect the call on to another PSTN number back through the same gateway sendmsg <UUID> call-command: execute execute-app-name: redirect execute-app-arg: sip:<destination>@194.0.147.16 The redirection works well and the originator and destination are connected correctly. But after the call has left FS I'm still left with some call debris which I cannot clear down using sendmsg <UUID> call-command: execute execute-app-name: hangup execute-app-arg: <cause code> Using command "api show channels" I find the following held on FS The only way I've found to remove these calls is "api hupall" ------------------------- uuid,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,appl ication,application_data,dialplan,context,read_codec,read_rate,write_cod ec,write_rate 132a3362-3bb2-8e46-a11b-9bd46ab2d706,2009-06-24 15:10:15,1245852615,sofia/TrunkExternal/0203196599@194.0.147.16:5060,CS_ EXECUTE,0203196599,0203196599, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 c2b40d55-0b5f-ff45-9541-cdcecc451e2c,2009-06-24 15:18:00,1245853080,sofia/TrunkExternal/0203196598@194.0.147.16:5060,CS_ EXECUTE,0203196598,0203196598, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 b03fa6b3-a436-db4b-add5-dfd0658b8867,2009-06-24 15:22:53,1245853373,sofia/TrunkExternal/0203196599@194.0.147.16:5060,CS_ EXECUTE,0203196599,0203196599, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 57ce0f01-a84d-6e49-a66d-0d771849ebb4,2009-06-24 15:40:30,1245854430,sofia/TrunkExternal/0189728400@194.0.147.16:5060,CS_ EXECUTE,0189728400,0189728400, 194.0.147.16,02031701648,redirect,sip:0701137881@194.0.147.16,XML,Public ,PCMA,8000,PCMA,8000 4 total. ------------------- The SIP signalling is correct with an outgoing "302 moved temporarily" [with the new destination in the contact] which is then Ack'ed by the switch. From a SIP point of view the call no longer on FS. The only way I've found to remove these phantom calls is either "api hupall", or restart the Sip profile. Any suggestions on how I can remove these phantom calls without recourse to "api hupall". "api hupall" kills any incoming calls as well as the stuck calls. Regards Richard Lamkin richard.lamkin@mettoni.com ************************************************************************ * Please consider the environment before printing this e-mail ************************************************************************ * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN ************************************************************************ * ************************************************************************* Please consider the environment before printing this e-mail ************************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN *************************************************************************
can do the following: 1) "make current" or do a fresh checkout to make sure you build is clean. 2) try executing the app "ring_ready" with no args in place of respond 180 and see if it makes any difference. 3) clear out your logfile by stopping FS and deleting /usr/local/freeswitch/log/freeswitch.log and reproduce. Then send me the log along with the list of channels you still see stuck. report the findings to jira http://jira.freeswitch.org and let me know the ticket number. make sure all your attachments have a .txt extensions when they are text files as jira has a bug of it's own with attachments and file types. On Wed, Jun 24, 2009 at 11:54 AM, Richard Lamkin <Richard.Lamkin@mettoni.com
wrote:
I have also observed that the cpu load goes up to 100% when only a couple of orphaned calls are left without being cleared by “api hupall”.
Richard Lamkin
richard.lamkin@mettoni.com
*From:* Richard Lamkin *Sent:* 24 June 2009 16:30 *To:* freeswitch-users@lists.freeswitch.org *Subject:* [Freeswitch-users] Orphaned calls left on FS after redirect off of FS
I am using the API to manage calls as they arrive at FS from a trunk
I have a very simple Dial plan rule that parks the incoming call.
<extension name="Trunk_02031701648">
<condition field="destination_number" expression="^02031701648$">
<action application="park" />
</condition>
</extension>
Once the call is parked via the API I first send a ringing (to keep the originator happy)
sendmsg <uuid>
call-command: execute
execute-app-name: respond
execute-app-arg: 180
Via the API I then redirect the call on to another PSTN number back through the same gateway
sendmsg <UUID>
call-command: execute
execute-app-name: redirect
execute-app-arg: sip:<destination>@194.0.147.16
The redirection works well and the originator and destination are connected correctly.
But after the call has left FS I’m still left with some call debris which I cannot clear down using
sendmsg <UUID>
call-command: execute
execute-app-name: hangup
execute-app-arg: <cause code>
Using command “api show channels” I find the following held on FS The only way I’ve found to remove these calls is “api hupall”
-------------------------
uuid,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,dialplan,context,read_codec,read_rate,write_codec,write_rate
132a3362-3bb2-8e46-a11b-9bd46ab2d706,2009-06-24 15:10:15,1245852615,sofia/TrunkExternal/0203196599@194.0.147.16:5060 ,CS_EXECUTE,0203196599,0203196599,
194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16<sip%3A0189728420@194.0.147.16> ,XML,Public,PCMU,8000,PCMU,8000
c2b40d55-0b5f-ff45-9541-cdcecc451e2c,2009-06-24 15:18:00,1245853080,sofia/TrunkExternal/0203196598@194.0.147.16:5060 ,CS_EXECUTE,0203196598,0203196598,
194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16<sip%3A0189728420@194.0.147.16> ,XML,Public,PCMU,8000,PCMU,8000
b03fa6b3-a436-db4b-add5-dfd0658b8867,2009-06-24 15:22:53,1245853373,sofia/TrunkExternal/0203196599@194.0.147.16:5060 ,CS_EXECUTE,0203196599,0203196599,
194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16<sip%3A0189728420@194.0.147.16> ,XML,Public,PCMU,8000,PCMU,8000
57ce0f01-a84d-6e49-a66d-0d771849ebb4,2009-06-24 15:40:30,1245854430,sofia/TrunkExternal/0189728400@194.0.147.16:5060 ,CS_EXECUTE,0189728400,0189728400,
194.0.147.16,02031701648,redirect,sip:0701137881@194.0.147.16<sip%3A0701137881@194.0.147.16> ,XML,Public,PCMA,8000,PCMA,8000
4 total.
-------------------
The SIP signalling is correct with an outgoing “302 moved temporarily” [with the new destination in the contact] which is then Ack’ed by the switch. From a SIP point of view the call no longer on FS.
The only way I’ve found to remove these phantom calls is either “api hupall”, or restart the Sip profile.
Any suggestions on how I can remove these phantom calls without recourse to “api hupall”. “api hupall” kills any incoming calls as well as the stuck calls.
Regards
Richard Lamkin
richard.lamkin@mettoni.com
*************************************************************************
Please consider the environment before printing this e-mail
*************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager. http://www.mettoni.com
Mettoni Ltd
Registered in England and Wales: 4485956
9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN
*************************************************************************
************************************************************************* Please consider the environment before printing this e-mail ************************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com
Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN *************************************************************************
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
I have tried to reproduce this issue but haven't been able too... What SVN Rev are you on? /b On Jun 24, 2009, at 10:29 AM, Richard Lamkin wrote:
I am using the API to manage calls as they arrive at FS from a trunk
I have a very simple Dial plan rule that parks the incoming call.
<extension name="Trunk_02031701648"> <condition field="destination_number" expression="^02031701648$"> <action application="park" /> </condition> </extension>
Once the call is parked via the API I first send a ringing (to keep the originator happy)
sendmsg <uuid> call-command: execute execute-app-name: respond execute-app-arg: 180
Via the API I then redirect the call on to another PSTN number back through the same gateway
sendmsg <UUID> call-command: execute execute-app-name: redirect execute-app-arg: sip:<destination>@194.0.147.16
The redirection works well and the originator and destination are connected correctly.
But after the call has left FS I’m still left with some call debris which I cannot clear down using
sendmsg <UUID> call-command: execute execute-app-name: hangup execute-app-arg: <cause code>
Using command “api show channels” I find the following held on FS The only way I’ve found to remove these calls is “api hupall”
------------------------- uuid ,created ,created_epoch ,name ,state ,cid_name ,cid_num ,ip_addr ,dest ,application ,application_data ,dialplan,context,read_codec,read_rate,write_codec,write_rate 132a3362-3bb2-8e46-a11b-9bd46ab2d706,2009-06-24 15:10:15,1245852615,sofia/TrunkExternal/0203196599@194.0.147.16 :5060,CS_EXECUTE,0203196599,0203196599, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public,PCMU,8000,PCMU,8000 c2b40d55-0b5f-ff45-9541-cdcecc451e2c,2009-06-24 15:18:00,1245853080,sofia/TrunkExternal/0203196598@194.0.147.16 :5060,CS_EXECUTE,0203196598,0203196598, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public,PCMU,8000,PCMU,8000 b03fa6b3-a436-db4b-add5-dfd0658b8867,2009-06-24 15:22:53,1245853373,sofia/TrunkExternal/0203196599@194.0.147.16 :5060,CS_EXECUTE,0203196599,0203196599, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public,PCMU,8000,PCMU,8000 57ce0f01-a84d-6e49-a66d-0d771849ebb4,2009-06-24 15:40:30,1245854430,sofia/TrunkExternal/0189728400@194.0.147.16 :5060,CS_EXECUTE,0189728400,0189728400, 194.0.147.16,02031701648,redirect,sip:0701137881@194.0.147.16,XML,Public,PCMA,8000,PCMA,8000
4 total. -------------------
The SIP signalling is correct with an outgoing “302 moved temporarily” [with the new destination in the contact] which is then Ack’ed by the switch. From a SIP point of view the call no longer on FS. The only way I’ve found to remove these phantom calls is either “api hupall”, or restart the Sip profile.
Any suggestions on how I can remove these phantom calls without recourse to “api hupall”. “api hupall” kills any incoming calls as well as the stuck calls.
Regards
Richard Lamkin richard.lamkin@mettoni.com
************************************************************************* Please consider the environment before printing this e-mail ************************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com
Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN ************************************************************************* _______________________________________________ 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
Brian West brian@freeswitch.org -- Meet us at ClueCon! http://www.cluecon.com
Dear Anthony and Brian, Firstly please accept my apologies for wasting your time. Brian's request for the SVN number prompted me to realise I was running with an out of date version of FS. When I synced up to the head of the trunk and reran my tests the scenario I described below worked perfectly with no stuck calls. Therefore the sequence Park, Ringing (ring back), Redirect using the event API has provided me with the automated redirection I was seeking. Thank you for your advice earlier this week and prompt turnaround of fixes for the problems I encountered with bridged and deflected calls. Regards Richard Lamkin Richard.lamkin@mettoni.com From: Brian West [mailto:brian@freeswitch.org] Sent: 24 June 2009 19:21 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Orphaned calls left on FS after redirect offof FS I have tried to reproduce this issue but haven't been able too... What SVN Rev are you on? /b On Jun 24, 2009, at 10:29 AM, Richard Lamkin wrote: I am using the API to manage calls as they arrive at FS from a trunk I have a very simple Dial plan rule that parks the incoming call. <extension name="Trunk_02031701648"> <condition field="destination_number" expression="^02031701648$"> <action application="park" /> </condition> </extension> Once the call is parked via the API I first send a ringing (to keep the originator happy) sendmsg <uuid> call-command: execute execute-app-name: respond execute-app-arg: 180 Via the API I then redirect the call on to another PSTN number back through the same gateway sendmsg <UUID> call-command: execute execute-app-name: redirect execute-app-arg: sip:<destination>@194.0.147.16 The redirection works well and the originator and destination are connected correctly. But after the call has left FS I'm still left with some call debris which I cannot clear down using sendmsg <UUID> call-command: execute execute-app-name: hangup execute-app-arg: <cause code> Using command "api show channels" I find the following held on FS The only way I've found to remove these calls is "api hupall" ------------------------- uuid,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,appl ication,application_data,dialplan,context,read_codec,read_rate,write_cod ec,write_rate 132a3362-3bb2-8e46-a11b-9bd46ab2d706,2009-06-24 15:10:15,1245852615,sofia/TrunkExternal/0203196599@194.0.147.16:5060,CS_ EXECUTE,0203196599,0203196599, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 c2b40d55-0b5f-ff45-9541-cdcecc451e2c,2009-06-24 15:18:00,1245853080,sofia/TrunkExternal/0203196598@194.0.147.16:5060,CS_ EXECUTE,0203196598,0203196598, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 b03fa6b3-a436-db4b-add5-dfd0658b8867,2009-06-24 15:22:53,1245853373,sofia/TrunkExternal/0203196599@194.0.147.16:5060,CS_ EXECUTE,0203196599,0203196599, 194.0.147.16,02031701648,redirect,sip:0189728420@194.0.147.16,XML,Public ,PCMU,8000,PCMU,8000 57ce0f01-a84d-6e49-a66d-0d771849ebb4,2009-06-24 15:40:30,1245854430,sofia/TrunkExternal/0189728400@194.0.147.16:5060,CS_ EXECUTE,0189728400,0189728400, 194.0.147.16,02031701648,redirect,sip:0701137881@194.0.147.16,XML,Public ,PCMA,8000,PCMA,8000 4 total. ------------------- The SIP signalling is correct with an outgoing "302 moved temporarily" [with the new destination in the contact] which is then Ack'ed by the switch. From a SIP point of view the call no longer on FS. The only way I've found to remove these phantom calls is either "api hupall", or restart the Sip profile. Any suggestions on how I can remove these phantom calls without recourse to "api hupall". "api hupall" kills any incoming calls as well as the stuck calls. Regards Richard Lamkin richard.lamkin@mettoni.com ************************************************************************ * Please consider the environment before printing this e-mail ************************************************************************ * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN ************************************************************************ * _______________________________________________ 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 Brian West brian@freeswitch.org -- Meet us at ClueCon! http://www.cluecon.com <http://www.cluecon.com/> ************************************************************************* Please consider the environment before printing this e-mail ************************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN *************************************************************************
participants (3)
-
Anthony Minessale
-
Brian West
-
Richard Lamkin