[asterisk-bugs] [JIRA] (PRI-168) DISCONNECT with Progress Indicator #8

[Armen Karlozian (JIRA)]

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

Armen Karlozian edited comment on PRI-168 at 5/13/14 12:30 AM:
---------------------------------------------------------------

Hi Richard,

Thanks for your reply, I appreciated it, and thanks for explaining the text formatting! :)  I tried to figure it out but I obviously I wasn't doing it correctly.

Anyway, the reason I chose the {{Proceeding}} application is because I was never going to use it and it was the only application I could call from the Dialplan that was in {{q931.c}}. I guess the hurdle I'm faced with is that I don't know how certain functions are called between Asterisk, DAHDI, and LibPRI, so it's a bit of hit and miss, compile, hit and miss, etc.  I'm by no means a professional programmer but am willing to learn if I can be nudged in the right direction when needed.  If you're recommending that I don't use {{Proceeding}} than I'll take your advice (sigh)... back to the drawing board! :(  So close... haha...

So in my posting on 7 May I did in fact try and workout a way of doing something via {{sig_pri_indicate()}} but it only "half-worked"...  With the changes I made the PBX acted normally (as it does with the Telco connection) and didn't send the RELEASE, instead it kept the channel up so the announcement could come through... the problem in that case was that _Asterisk_ was closing the channel even with the actual line still up.

If resolving this deficiency through the {{sig_pri_hangup()}} and  {{sig_pri_indicate()}} functions is the best way forward then I'll need to focus on those.  If that's the case, then I'll need to create a new app other than {{Busy(_n_)}} or {{Congestion(_n_)}} because currently with only those two options, they call {{sig_pri_indicate()}} and produce a busy and reorder tone only and there's no way of providing an in-band recording or announcement which is insufficient and not to ETS standards... In other words, something like {{Playback()}} must be supported as well.

So maybe I can plan this way:

1) Create a new dial plan cmd, perhaps naming it {{PreHangupPRI(_n_)}} (or something along those lines) where the _n_ would be the cause code.
2) This would send the DISCONNECT with PI#8 and start {{Timer T306}} per the ETS standard.
3) Then we can use {{Playback()}} and send whatever type of announcement is required.
4) Finally, as usual, we use {{Hangup()}} to close the channel.

The way I understand it is that currently {{Busy(_n_)}} and {{Congestion(_n_)}} call {{sig_pri_indicate}} which in turn calls {{Q931_DISCONNECT}}.    *So now the first step (I think) is I need to know _how_ each of these call eachother...* I wish there was some kind of flow chart or diagram... :P



was (Author: armeniki):
Hi Richard,

Thanks for your reply, I appreciated it, and thanks for explaining the text formatting! :)  I tried to figure it out but I obviously I wasn't doing it correctly.

Anyway, the reason I chose the {{Proceeding}} application is because I was never going to use it and it was the only application I could call from the Dialplan that was in {{q931.c}}. I guess the hurdle I'm faced with is that I don't know how certain functions are called between Asterisk, DAHDI, and LibPRI, so it's a bit of hit and miss, compile, hit and miss, etc.  I'm by no means a professional programmer but am willing to learn if I can be nudged in the right direction when needed.  If you're recommending that I don't use {{Proceeding}} than I'll take your advice (sigh)... back to the drawing board! :(  So close... haha...

So in my posting on 7 May I did in fact try and workout a way of doing something via {{sig_pri_indicate()}} but it only "half-worked"...  With the changes I made the PBX acted normally (as it does with the Telco connection) and didn't send the RELEASE, instead it kept the channel up so the announcement could come through... the problem in that case was that _Asterisk_ was closing the channel even with the actual line still up.

If resolving this deficiency through the {{sig_pri_hangup()}} and  {{sig_pri_indicate()}} functions is the best way forward then I'll need to focus on those.  If that's the case, then I'll need to create a new app other than {{Busy(_n_)}} or {{Congestion(_n_)}} because currently with only those two options, they call {{sig_pri_indicate()}} and produce a busy and reorder tone only and there's no way of providing an in-band recording or announcement which is insufficient and not to ETS standards... In other words, something like {{Playback()}} must be supported as well.

So maybe I can plan this way:

1) Create a new dial plan cmd, perhaps naming it {{PreHangupPRI(_n_)}} (or something along those lines) where the _n_ would be the cause code.
2) This would send the DISCONNECT with PI#8 and start {{Timer T306}} per the ETS standard.
3) The user could then use {{Playback()}} and send whatever type of announcement is required.
4) The user would then use {{Hangup()}} as usual to close the channel.

The way I understand it is that currently {{Busy(_n_)}} and {{Congestion(_n_)}} call {{sig_pri_indicate}} which in turn calls {{Q931_DISCONNECT}}.    *So now the first step (I think) is I need to know _how_ each of these call eachother...* I wish there was some kind of flow chart or diagram... :P


> DISCONNECT with Progress Indicator #8
> -------------------------------------
>
>                 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: Armen Karlozian
>            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)