[asterisk-dev] Looking for definitive answer for Busy() vs. Hangup() when used on a non-answered PRI channel
Justin Killen
jkillen at allamericanasphalt.com
Thu Jul 10 14:33:27 CDT 2014
On Thu, Jul 10, 2014 at 12:36 PM, Justin Killen <jkillen at allamericanasphalt.com<mailto:jkillen at allamericanasphalt.com>> wrote:
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?
Inband tones before answering is known as early media. After answering
it is just a normal audio path that the tones would go over.
Asterisk B in the above situation before answering with the shown dialplan
snippet, the Playtone() would effectively be a NoOp because nothing is shown
that would open a path for early media. (The Progress() application should be
done first to open the path.) Then the Busy() would cause chan_dahdi/sig_pri
to send a PROGRESS message toward Asterisk A if needed to open the media
path and start its own busy tones. From Asterisk B to Phone A there are
several things that could block the early media. The telco network,
Asterisk A configuration, and Phone A itself.
You may need to investigate these options on Asterisk A from sip.conf.sample:
;prematuremedia=no ; Some ISDN links send empty media frames before
; the call is in ringing or progress state. The SIP
; channel will then send 183 indicating early media
; which will be empty - thus users get no ring signal.
; Setting this to "yes" will stop any media before we have
; call progress (meaning the SIP channel will not send 183 Session
; Progress for early media). Default is "yes". Also make sure that
; the SIP peer is configured with progressinband=never.
;
; In order for "noanswer" applications to work, you need to run
; the progress() application in the priority before the app.
;progressinband=never ; If we should generate in-band ringing always
; use 'never' to never use in-band signalling, even in cases
; where some buggy devices might not render it
; Valid values: yes, no, never Default: never
Richard
Okay, so given the default dahdi config value of sending tones in-band, busy() will send an in-band busy tone. If the call hasn't been answer()'d yet, and if we have previously established an early media path via progress(), then the busy tone will be sent in-band via early media.
What happens if progress() has not been called? Will the call to busy() recognize that we haven't answer()'d the call and automatically attempt to establish an early media path? If not, what would be the downside of doing so?
It seems like for busy() to work properly, we must either:
A) Answer() the channel earlier in the dialplan, to allow the tones to be played in-band
B) Progress() the channel earlier in the dialplan, to allow the tones to be played as early media
C) Change the dahdi config to send signals out-of-band (on a side-note, why isn't this the default? Is it broken in a lot of telcos?)
Looking at option B - what (if any) side effects / disadvantages are there to calling progress() on every inbound call?
The behavior I see now is that Phone A rings for about 20 seconds and then times out locally. Meanwhile on site B I can see that it ran busy(), but the signal never got back to A. When I change the dialplan to use hangup(17) instead of busy(20), I get a busy tone on Phone A immediately. How then does the PROGRESS message sent by busy() differ from the output sent via hangup(17)?
-Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140710/f1d67438/attachment-0001.html>
More information about the asterisk-dev
mailing list