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

[Justin Killen]

On Thu, Jul 10, 2014 at 2:33 PM, Justin Killen <jkillen at allamericanasphalt.com<mailto:jkillen at allamericanasphalt.com>> wrote:
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?

chan_dahdi/sig_pri will recognize that Progress() has not happened yet and
open the early media path itself.  I was just pointing out that the Playtones()
in that dialplan snipet was effectively a NoOp because nothing before it
opened the media path.  Another reason it is a NoOp is chan_dahdi/sig_pri
starts its own busy tones.


That makes sense - thanks for the clarification.



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?)

For your case just do C.  It is really better for trunks anyway.


Okay - I'll make that change and see if that fixes things.  If it really is better for trunks, I'm surprised by the documentation - every example I've seen on setting up a PRI trunk doesn't mention this option.  Would it make sense to have an option for this for 'auto', which would determine what to do based on signaling?  i.e. if signaling is cpe then use out-of-band.



Looking at option B - what (if any) side effects / disadvantages are there to calling progress() on every inbound call?

Calling Progress() without following it with something that generates media
is not a good thing.  SIP phones in particular will have problems because
you may not hear a ringing tone as many phones will ignore the "180 Ringing"
message because it has already seen a "183 Progress" message.

Okay, that makes sense.  Since busy() causes the early media path to be opened it wouldn't be very helpful anyway.



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)?

Since you have shown no logs I cannot say why you don't hear the busy tones.
It could very well be that the phone itself is not letting any early media through
and insists on generating any tones itself.

Anyway, you have a solution.  Just set priindication=outofband in chan_dahdi.conf.

Richard


I haven't included the logs because I've been more interested in figuring out how it is supposed to work, and tracking down if this was a bad dialplan, bug in asterisk, or configuration issue.  It seemed odd to me that such a basic function wasn't working as expected.  I'm going to make the priindication change as you advised.  After that if it is still not working I'll do further diagnostics.

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