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

[Richard Mudgett]

On Thu, Jul 10, 2014 at 2:33 PM, Justin Killen <
jkillen at allamericanasphalt.com> wrote:

>    On Thu, Jul 10, 2014 at 12:36 PM, Justin Killen <
> 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.


>
>
>
>
> 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.


>
>
>
>
> 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.


>
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140710/a2211a62/attachment-0001.html>