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

[Joshua Colp]

On Wed, Apr 4, 2018, at 8:04 PM, Steve Murphy wrote:
> 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?

Legacy purposes where it's not signaled I'd bet. Specifically, when the busy tone itself is generated locally.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org