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: [email protected] 
[mailto:[email protected]] 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 
<[email protected]<mailto:[email protected]>> 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
-- 
_____________________________________________________________________
-- 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

Reply via email to