[asterisk-bugs] [JIRA] (PRI-168) Alternative Mode of Sending PRI Cause Codes

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/PRI-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217628#comment-217628 ] 

Richard Mudgett commented on PRI-168:
-------------------------------------

The New Feature type is used when a patch is supplied that implements the feature.  Without a patch the issue just clutters the issue tracker with whatever wild ideas people could dream up that would never get implemented.

The main problem with what you want is a deficiency in the API between libpri and chan_dahdi.
# The libpri API doesn't have a way to express the desire to *send* a DISCONNECT with a progress ie indicating inband audio is available on the B channel.  Also libpri doesn't implement the alternate state transitions needed to *send* a DISCONNECT with a progress ie indicating inband audio.  The chan_dahdi/sig_pri sig_pri_indicate() would then need to be changed to use the new API call for busy/congestion.
# The libpri API doesn't have a way to express that a DISCONNECT was *received* with inband audio present.  Anyway, it wouldn't matter if it did because the Asterisk core and other channel drivers don't support the phased hangup needed for a bridged peer to listen to the inband audio and pass the hangup request to the bridged peer.  As a result, the hangup sequence has to be completed independent of what technology the bridge peer is using.

>From your description, you would only care about sending the DISCONNECT with the inband audio and not receiving it.  Asterisk is the entity that would generate the inband audio for busy/congestion.


> Alternative Mode of Sending PRI Cause Codes
> -------------------------------------------
>
>                 Key: PRI-168
>                 URL: https://issues.asterisk.org/jira/browse/PRI-168
>             Project: LibPRI
>          Issue Type: New Feature
>      Security Level: None
>    Affects Versions: 1.4.13
>            Reporter: armeniki
>            Assignee: Richard Mudgett
>            Severity: Minor
>
> Hi everyone,
> As you know, currently when the Hangup() command is used in the Asterisk dial plan, it will tear down both the far and and near end of the call and audio amongst other things.  In addition, there is a way of indicating the PRI Cause Code to the user by entering the code within the parenthesis ie: Hangup(1) or Hangup(16), etc.
> Here is the issue:  We have a PBX connected to an E1/PRI from the Telco.  This is a production system and does not use Asterisk.  On this system, whenever someone dials a number which is busy, for example, the phone's display will show the standard PRI message "user busy" and the user will hear an engaged signal (busy signal).  Likewise, if a wrong number is dialled, the display will show "unallocated num" and another tone or message will be heard.... and so on.
> Currently, we're doing tests on the same type of system connected to Asterisk via an E1/PRI and have found that this does not happen.  Basically, if the user dials a busy number, they will hear a busy signal but they won't see the "user busy" message.  Alternatively, if we change the extension script a bit, we can issue a Hangup(17) to make the phone show "user busy" but then there's no way to play the busy signal because the phone/channel hangs up.
> SO....
> Would it be possible to perhaps create a new function called "SendPRICause()" (kind of like the SendText function for SIP phones) so that we can use that instead of Hangup()?
> This way the use can see the message and hear whatever recording needs to be played to them at the same time.
> An example of its usage could be:
> exten => s-DN_CHANGED,1,Progress()
> exten => s-DN_CHANGED,1,SendPRICause(22)
> exten => s-DN_CHANGED,n,Playback(/var/lib/asterisk/sounds/tel/sorry-number-changed,noanswer)
> exten => s-DN_CHANGED,n,Hangup()
> --------------------------
> Cheers,
> Armen



--
This message was sent by Atlassian JIRA
(v6.2#6252)