On Wed, Apr 4, 2018, at 8:04 PM, Steve Murphy wrote: > On Wed, Apr 4, 2018 at 3:20 PM, Matt Fredrickson <cres...@digium.com> wrote: > > > On Mon, Apr 2, 2018 at 9:40 PM, Steve Murphy <m...@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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev