[asterisk-dev] Looking for definitive answer for Busy() vs. Hangup() when used on a non-answered PRI channel

[Justin Killen]

Okay, that makes sense.  So then, how does the answer()'d status affect that?  From my (admittedly limited) experience, it seems that playing in-band tones only works if the call has been answered?

Here's the setup I'm using, maybe it will help if I give an example of what I'm trying to figure out:


Phone A <-sip-> asterisk site A <-PRI-> PTSN <-PRI-> asterisk site B


If then I have a dialplan at site B for the dialed DID that looks like this:

Playtone(busy)
Busy(20)

And given that I'm using default in-band tones, what is the expected resulting sound coming out of Phone A?
Justin
________________________________
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Richard Mudgett
Sent: Thursday, July 10, 2014 10:21 AM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Looking for definitive answer for Busy() vs. Hangup() when used on a non-answered PRI channel



On Thu, Jul 10, 2014 at 10:57 AM, Justin Killen <jkillen at allamericanasphalt.com<mailto:jkillen at allamericanasphalt.com>> wrote:
Hi,

I'm using freepbx, and I've gotten myself into a bit of an argument (http://issues.freepbx.org/browse/FREEPBX-7706) about when to use Busy() vs. Hangup(17).  The conversation boils down to the fact that in a certain condition within the freepbx dialplan, an incoming PRI call runs the application Playtone(busy) followed by Busy(20).  My issue here is that PRI_CAUSE never gets set, so the calling phone doesn't ever ring busy, it just rings normally.  I should note that this call is never Answer()'d.  The stance of the freepbx team member is that calling Busy() should be all that an application needs to do - they shouldn't have to worry about writing special code depending on the type of the underlying channel.  I can't say that I disagree with that, especially after viewing the official docs, which describe Busy() as:

"This application will indicate the busy condition to the calling channel."

This to me implies that calling Busy() on a PRI channel should internally set PRI_CAUSE = 17.

What I'm really looking for here is a definitive answer as to what should change here, either:
a)       Dialplans be required to check channel status and run playtones/busy on answered channels or hangup(17) on non-answered channels
or
b)      Busy(), when called on a non-answered channel, should set the PRI_CAUSE (or whatever other appropriate variable for the channel)


Lastly, I should mention that I've posted this to the users group, and although I have gotten workarounds, I have not been able to get a definitive answer on how this actually should work, only on how it does work and how to work around it.

The Hangup(), Busy(), and Congestion() applications are not equivalent
in their behaviours even though some channel drivers treat Busy() as
Hangup(17) and Congestion() as Hangup(34).  The Hangup() application
always sets the cause code and immediately begins hangup
procedures.  The Busy() and Congestion() applications send a control
frame to the channel driver to handle as it sees fit and then the
application waits with optional timeout for the far end to hangup the call.
For chan_dahdi PRI, this behaviour is configurable in chan_dahdi.conf to
work either way when the Busy()/Congestion() applications are used.
The default is to send the inband busy/congestion tone rather than send
the cause code 17/34 so a caller can hear the tone and hangup.

Excerpt from chan_dahdi.conf.sample file:

; PRI Out of band indications.
; Enable this to report Busy and Congestion on a PRI using out-of-band
; notification. Inband indication, as used by Asterisk doesn't seem to work
; with all telcos.
;
; outofband:      Signal Busy/Congestion out of band with RELEASE/DISCONNECT
; inband:         Signal Busy/Congestion using in-band tones (default)
;
; priindication cannot be changed on a reload.
;
;priindication = outofband

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140710/cee98bf5/attachment-0001.html>