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

armeniki (JIRA) noreply at issues.asterisk.org
Sat Apr 26 23:22:18 CDT 2014


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

armeniki edited comment on PRI-168 at 4/26/14 11:21 PM:
--------------------------------------------------------

Hi Richard,

Yes, you're right, in this case we would be interested in the "sending" aspect of the DISCONNECT process because the Asterisk system in this scenario is the "Telco" for the BCM400.  

If there is indeed a deficiency as you mentioned, it might be worthwhile taking a look into it sometime. I looked at the ETS Euro ISDN standards document (it's very large!) and I think it mentions something similar to what I am referring to at 5.3.4.. not surprisingly as the Telco does this.

Here's the link to the document in case you wanted to have a look:
http://www.etsi.org/deliver/etsi_i_ets/300100_300199/30010201/01_60/ets_30010201e01p.pdf

*But something very interesting* has got my attention:

Nortel has a really handy tool for monitoring their PBX and the PRI connections to it, called BCM Monitor (I'm sure you know of it).  So, I had a look on both the production system connected to the Telco and the test system connected to Asterisk whilst dialling a busy number.

Here's a screen shot of the Telco connection:
http://i1100.photobucket.com/albums/g408/armeniki/telephone/ISDN-telco.png

Here's a screen shot of the Asterisk connection:
http://i1100.photobucket.com/albums/g408/armeniki/telephone/ISDN_asterisk.png

Everything at the beginning was the same (more or less) so I didn't expand anything there... but if you look towards the end, you'll notice with the Telco connection there is an extra transaction there between the "DISCONNECT User Busy" and the "RELEASE_CC" at the end, called "RELEASE User Busy  Recovery on timer expiry".

This particular line does not appear on the Asterisk test system.  It only shows the "DISCONNECT User Busy" and the "RELEASE_CC" and nothing in between.  

This leads me to believe that there might be something interesting here which allows the  relevant PRI message and signal to come through together as I described earlier with Australian telcos.  Just thinking out loud here.


was (Author: armeniki):
Hi Richard,

Yes, you're right, in this case we would be interested in the "sending" aspect of the DISCONNECT process because the Asterisk system in this scenario is the "Telco" for the BCM400.  

If there is indeed a deficiency as you mentioned, it might be worthwhile taking a look into it sometime. I looked at the ETS Euro ISDN standards document (it's very large!) and I think it mentions something similar to what I am referring to at 5.3.4.. not surprisingly as the Telco does this.

Here's the link to the document in case you wanted to have a look:
http://www.etsi.org/deliver/etsi_i_ets/300100_300199/30010201/01_60/ets_30010201e01p.pdf

*But something very interesting* has got my attention:

Nortel has a really handy tool for monitoring their PBX and the PRI connections to it, called BCM Monitor (I'm sure you know of it).  So, I had a look on both the production system connected to the Telco and the test system connected to Asterisk whilst dialling a busy number.

Here's a screen shot of the Telco connection:
http://i1100.photobucket.com/albums/g408/armeniki/telephone/ISDN-telco.png

Here's a screen shot of the Asterisk connection:
http://i1100.photobucket.com/albums/g408/armeniki/telephone/ISDN_asterisk.png

Everything at the beginning was the same (more or less) so I didn't expand anything there... but if you look towards the end, you'll notice with the Telco connection there is an extra transaction there between the "DISCONNECT User Busy" and the "RELEASE_CC" at the end, called "RELEASE User Busy  Recovery on timer expiry".

This particular line does not appear on the Asterisk test system.  It only shows the "DISCONNECT User Busy" and the "RELEASE_CC" and nothing in between.  

This leads me to believe that there might be something interesting here which allows the engaged signal to also come through as I described earlier with Australian telcos.  Just thinking out loud here.

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



More information about the asterisk-bugs mailing list