[asterisk-dev] The "Busy" App.... isn't.

[Steve Murphy]

On Wed, Apr 4, 2018 at 3:20 PM, Matt Fredrickson <creslin at digium.com> wrote:

> On Mon, Apr 2, 2018 at 9:40 PM, Steve Murphy <murf at parsetree.com> wrote:
> > Someone complained about errant behavior of the Busy and Hangup apps...
> > and I see some strangenesses that might make them credible.
> >
> ​<snip>
> >
> > I cut off the rest of the debug, but the call lasts the full 15  seconds
> > after busy() is called, and then hangs up. It's interesting to see what
> the
> > trunk provider does on top of all this.
> >
> > So, my question is: Did I do the best thing? It seems to work, but I
> have no
> > idea if I'm creating bugs galore in other usages.
>
> There is an assumption (for asterisk C level applications, like
> Busy()) when using ast_read that if it ever returns NULL that the
> underlying channel has been hung up and the application should quickly
> exit.  Busy() is honoring that assumption.  It looks like in
> sip_indicate() of chan_sip.c, when a AST_CONTROL_BUSY is queued on a
> SIP channel, it sets the soft hangup flag on the channel.  That's why
> you're seeing this behavior.  The timeout from Busy() is invalidated
> if the underlying channel wants to be hung up.
>
> I would be highly concerned about breaking that assumption, as you are
> doing in your proposed patch.  Is there a particular reason you want
> to keep the call up for 15 seconds before releasing the channel?
>

​I was tempted so say:​

​Mainly for the sake of that "Busy Here" SIP message I'd like to see go
back to the
trunk provider. With my patch, it goes out. Without it, nada.

But... incoming calls can come from either of two IP's, and "sip set debug
ip xxxxxx"
can only monitor one. So, what I thought was happening may not be!

But, really.... if the Busy app takes an arg, but never honors it... why
does it take the
argument at all?

murf

-- 

Steve Murphy
✉  murf at parsetree dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180404/4803318c/attachment.html>