<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 4, 2018 at 6:04 PM, Steve Murphy <span dir="ltr"><<a href="mailto:murf@parsetree.com" target="_blank">murf@parsetree.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Apr 4, 2018 at 3:20 PM, Matt Fredrickson <span dir="ltr"><<a href="mailto:creslin@digium.com" target="_blank">creslin@digium.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_1376404053099061821HOEnZb"><div class="m_1376404053099061821h5"><span class="">On Mon, Apr 2, 2018 at 9:40 PM, Steve Murphy <<a href="mailto:murf@parsetree.com" target="_blank">murf@parsetree.com</a>> wrote:<br>
> Someone complained about errant behavior of the Busy and Hangup apps...<br>
> and I see some strangenesses that might make them credible.<br>
><br>
</span><div>​<snip><br></div><span class="">
><br>
> I cut off the rest of the debug, but the call lasts the full 15  seconds<br>
> after busy() is called, and then hangs up. It's interesting to see what the<br>
> trunk provider does on top of all this.<br>
><br>
> So, my question is: Did I do the best thing? It seems to work, but I have no<br>
> idea if I'm creating bugs galore in other usages.<br>
<br>
</span></div></div><span class="">There is an assumption (for asterisk C level applications, like<br>
Busy()) when using ast_read that if it ever returns NULL that the<br>
underlying channel has been hung up and the application should quickly<br>
exit.  Busy() is honoring that assumption.  It looks like in<br>
sip_indicate() of chan_sip.c, when a AST_CONTROL_BUSY is queued on a<br>
SIP channel, it sets the soft hangup flag on the channel.  That's why<br>
you're seeing this behavior.  The timeout from Busy() is invalidated<br>
if the underlying channel wants to be hung up.<br>
<br>
I would be highly concerned about breaking that assumption, as you are<br>
doing in your proposed patch.  Is there a particular reason you want<br>
to keep the call up for 15 seconds before releasing the channel?<br>
<span class="m_1376404053099061821HOEnZb"></span></span></blockquote><div><br><div>​I was tempted so say:​</div><br><div>​Mainly for the sake of that "Busy Here" SIP message I'd like to see go back to the<br></div><div>trunk provider. With my patch, it goes out. Without it, nada.<br><br></div><div>But... incoming calls can come from either of two IP's, and "sip set debug ip xxxxxx"<br></div><div>can only monitor one. So, what I thought was happening may not be!<br><br></div><div>But, really.... if the Busy app takes an arg, but never honors it... why does it take the<br></div><div>argument at all?<br></div></div></div></div></div></blockquote><div><br></div><div>The argument is used when the channel is already answered.  The channel will then send<br></div><div>the busy tone inband for the specified number of seconds and hangup.  The behavior also <br>depends upon the channel driver.<br><br></div><div>exten = _X.,1,NoOp()<br></div><div>same = n,Answer()<br></div><div>same = n,Busy(15)<br></div><div>same = n,Hangup()<br></div><div><br></div><div><br></div><div>Richard<br></div></div><br></div></div>