can do the following: <br><br>1) &quot;make current&quot; or do a fresh checkout to make sure you build is clean.<br>2) try executing the app &quot;ring_ready&quot; with no args in place of respond 180 and see if it makes any difference.<br>
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<br>    the list of channels you still see stuck.<br><br>report the findings to jira <a href="http://jira.freeswitch.org">http://jira.freeswitch.org</a> and let me know the ticket number.<br>
make sure all your attachments have a .txt extensions when they are text files as jira has a bug of it&#39;s own with attachments and file types.<br><br><br><br><br><div class="gmail_quote">On Wed, Jun 24, 2009 at 11:54 AM, Richard Lamkin <span dir="ltr">&lt;<a href="mailto:Richard.Lamkin@mettoni.com">Richard.Lamkin@mettoni.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">








<div link="blue" vlink="purple" lang="EN-GB">

<div>

<p><span style="color: rgb(31, 73, 125);">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”.</span></p><div class="im">

<p><span style="color: rgb(31, 73, 125);"> </span></p>

<p><span style="color: rgb(31, 73, 125);">Richard Lamkin</span></p>

<p><span style="color: rgb(31, 73, 125);"> </span></p>

<p><a href="mailto:richard.lamkin@mettoni.com" target="_blank">richard.lamkin@mettoni.com</a></p>

<p><span style="color: rgb(31, 73, 125);"> </span></p>

<p><span style="color: rgb(31, 73, 125);"> </span></p>

</div><div>

<div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">

<p><b><span style="font-size: 10pt;" lang="EN-US">From:</span></b><span style="font-size: 10pt;" lang="EN-US"> Richard Lamkin <br>
<b>Sent:</b> 24 June 2009 16:30<br>
<b>To:</b> <a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a><br>
<b>Subject:</b> [Freeswitch-users] Orphaned calls left on FS after redirect off
of FS</span></p>

</div>

</div><div><div></div><div class="h5">

<p> </p>

<p>I am using the API to manage calls as they arrive at FS from
a trunk</p>

<p> </p>

<p>I have a very simple Dial plan rule that parks the incoming
call.</p>

<p> </p>

<p>  &lt;extension name=&quot;Trunk_02031701648&quot;&gt;</p>

<p>    &lt;condition field=&quot;destination_number&quot;
expression=&quot;^02031701648$&quot;&gt;</p>

<p>        &lt;action
application=&quot;park&quot; /&gt;</p>

<p>    &lt;/condition&gt;</p>

<p>  &lt;/extension&gt;</p>

<p> </p>

<p> </p>

<p>Once the call is parked via the API I first send a ringing
(to keep the originator happy)</p>

<p> </p>

<p>sendmsg  &lt;uuid&gt;</p>

<p>call-command: execute</p>

<p>execute-app-name: respond</p>

<p>execute-app-arg: 180</p>

<p> </p>

<p>Via the API I then redirect the call on to another PSTN
number back through the same gateway</p>

<p> </p>

<p>sendmsg   &lt;UUID&gt;</p>

<p>call-command: execute</p>

<p>execute-app-name: redirect</p>

<p>execute-app-arg: sip:&lt;destination&gt;@<a href="http://194.0.147.16" target="_blank">194.0.147.16</a></p>

<p> </p>

<p>The redirection works well and the originator and
destination are connected correctly.</p>

<p> </p>

<p>But after the call has left FS I’m still left with
some call debris which I cannot clear down using </p>

<p> </p>

<p>sendmsg   &lt;UUID&gt;</p>

<p>call-command: execute</p>

<p>execute-app-name: hangup</p>

<p>execute-app-arg: &lt;cause code&gt;</p>

<p> </p>

<p> </p>

<p>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”</p>

<p> </p>

<p>-------------------------</p>

<p>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</p>

<p>132a3362-3bb2-8e46-a11b-9bd46ab2d706,2009-06-24
15:10:15,1245852615,sofia/TrunkExternal/<a href="http://0203196599@194.0.147.16:5060" target="_blank">0203196599@194.0.147.16:5060</a>,CS_EXECUTE,0203196599,0203196599,</p>

<p>194.0.147.16,02031701648,redirect,<a href="mailto:sip%3A0189728420@194.0.147.16" target="_blank">sip:0189728420@194.0.147.16</a>,XML,Public,PCMU,8000,PCMU,8000</p>

<p>c2b40d55-0b5f-ff45-9541-cdcecc451e2c,2009-06-24
15:18:00,1245853080,sofia/TrunkExternal/<a href="http://0203196598@194.0.147.16:5060" target="_blank">0203196598@194.0.147.16:5060</a>,CS_EXECUTE,0203196598,0203196598,</p>

<p>194.0.147.16,02031701648,redirect,<a href="mailto:sip%3A0189728420@194.0.147.16" target="_blank">sip:0189728420@194.0.147.16</a>,XML,Public,PCMU,8000,PCMU,8000</p>

<p>b03fa6b3-a436-db4b-add5-dfd0658b8867,2009-06-24
15:22:53,1245853373,sofia/TrunkExternal/<a href="http://0203196599@194.0.147.16:5060" target="_blank">0203196599@194.0.147.16:5060</a>,CS_EXECUTE,0203196599,0203196599,</p>

<p>194.0.147.16,02031701648,redirect,<a href="mailto:sip%3A0189728420@194.0.147.16" target="_blank">sip:0189728420@194.0.147.16</a>,XML,Public,PCMU,8000,PCMU,8000</p>

<p>57ce0f01-a84d-6e49-a66d-0d771849ebb4,2009-06-24
15:40:30,1245854430,sofia/TrunkExternal/<a href="http://0189728400@194.0.147.16:5060" target="_blank">0189728400@194.0.147.16:5060</a>,CS_EXECUTE,0189728400,0189728400,</p>

<p>194.0.147.16,02031701648,redirect,<a href="mailto:sip%3A0701137881@194.0.147.16" target="_blank">sip:0701137881@194.0.147.16</a>,XML,Public,PCMA,8000,PCMA,8000</p>

<p> </p>

<p>4 total.</p>

<p>-------------------</p>

<p> </p>

<p>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.</p>

<p>The only way I’ve found to remove these phantom calls
is either “api hupall”,  or restart the Sip profile.</p>

<p> </p>

<p>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.</p>

<p> </p>

<p>Regards</p>

<p> </p>

<p>Richard Lamkin</p>

<p><a href="mailto:richard.lamkin@mettoni.com" target="_blank">richard.lamkin@mettoni.com</a></p>

<p> </p>

<p> </p>

<p> </p>

<p> </p>

<p> </p>

<p> </p>

<p> </p>

<p> </p>

<pre>*************************************************************************</pre><pre>Please consider the environment before printing this e-mail</pre><pre>*************************************************************************</pre>
<pre>This email and any files transmitted with it are confidential and</pre><pre>intended solely for the use of the individual or entity to whom they</pre><pre>are addressed. If you have received this email in error please notify</pre>
<pre>the system manager.  <a href="http://www.mettoni.com" target="_blank">http://www.mettoni.com</a></pre><pre> </pre><pre>Mettoni Ltd</pre><pre>Registered in England and Wales: 4485956</pre><pre>9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN</pre>
<pre>*************************************************************************</pre></div></div></div><div><div></div><div class="h5">

<pre>*************************************************************************
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.  <a href="http://www.mettoni.com" target="_blank">http://www.mettoni.com</a>

Mettoni Ltd
Registered in England and Wales: 4485956
9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN
*************************************************************************
</pre></div></div></div>


<br>_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>