<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Apr 2, 2018 at 9:40 PM, Steve Murphy <<a href="mailto:murf@parsetree.com">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>
<div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">​<snip><br></div>
><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>
</div></div>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="HOEnZb"></span></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">​I was tempted so say:​</div><br><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">​Mainly for the sake of that "Busy Here" SIP message I'd like to see go back to the<br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">trunk provider. With my patch, it goes out. Without it, nada.<br><br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">But... incoming calls can come from either of two IP's, and "sip set debug ip xxxxxx"<br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">can only monitor one. So, what I thought was happening may not be!<br><br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">But, really.... if the Busy app takes an arg, but never honors it... why does it take the<br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">argument at all?<br><br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">murf<br><br></div></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Steve Murphy<br>✉  murf at parsetree dot com<br></div></div></div></div></div></div></div></div>
</div></div>