[Asterisk-Dev] PRI/T1-Signaling

[John Todd]

At 11:33 AM -0600 1/9/04, Steven Critchfield wrote:
>On Fri, 2004-01-09 at 10:59, Alfred R. Nurnberger wrote:
>>  I am planning to implement an application for PRI signaling enabling to send
>>  PRI messages from the extension level.
>>
>>  i.e.  exten => 555,1,MsgPri (Zap / 2 / Q931_DISCONNECT /
>>  PRI_CAUSE_USER_BUSY);
>>
>>  Comments are welcome.
>
>Simple comment would be that the spaces in the above example may cause
>trouble. Otherwise that is nice.
>
>Of course maybe it might be better to have some of those messages become
>hooks that can call those messages in other drivers too. The
>CAUSE_USER_BUSY would probably be very beneficial to ISDN users too. I
>don't think VoIP users would care much, but PSTN connections would
>benefit if you could do that without answering the line and therefore
>incurring cost.
>
>Some messages I'm sure won't have any other analog to the other drivers,
>and may well be suited to the MsgPRI type command you suggested.
>
>Also as for calling syntax, it would probably already know the channel
>you are referring to as you are already processing the dialplan.
>Something like this.
>
>exten => 555,1,Dial(${Joe})
>exten => 555,102,Busy ; which sends CAUSE_USER_BUSY
>
>or
>
>exten => 555,1,agi(check.pl)
>exten => 555,2,Dial(${Joe})
>exten => 555,102,MsgPri(NOT_INSERVICE)
>
>In the second example, you know the channel you are referring to as it
>is already causing the dialplan to be exercised, but the message is the
>important part. 
>
>>  -----Original Message-----
>>  From: asterisk-dev-admin at lists.digium.com
>>  [mailto:asterisk-dev-admin at lists.digium.com]On Behalf Of Steven
>>  Critchfield
>>  Sent: Friday, January 09, 2004 7:49 AM
>>  To: asterisk-dev at lists.digium.com
>>  Subject: Re: [Asterisk-Dev] PRI/T1-Signaling
>>
>>
>>  On Fri, 2004-01-09 at 09:15, Alfred R. Nurnberger wrote:
>>  > I started looking into * a coouple of weeks ago. I do work on T1/PRI
>>  > interfaces - stacks etc. So I am a bit familiar with their
>>  > capabilities.
>>  >
>>  > 1.) I wonder if it is possible to use the quite extensive signalling
>>  > features of ISDN / PRI with Asterisk.
>>  >
>>  >     i.e. instead of  sending an inband Busy tone - send a DISCONNECT
>>  > with CAUSE Subscriber busy.
>>  >          or trigger USER-USER messages from *
>>  >
>>  > 2.)I haven't played with the T1 boards yet.
>>  >     Does the board support transmission of audio BEFORE answer ?
>>  >     This way * could send call progress tones to the network.
>>  >
>>  >     From the network side audio transmission before answer is
>>  > available on most DID, T1 and PRI lines.
>>  >     We use it here on all 3 trunk types.
>>
>>  It does support audio before answer. For your PRI questions, look to the
>>  libpri library. Libpri implements all the q931 and q921(?) messages.
>>
>>  Remember that since this is all open source, if you see ways of
>>  improving what is done, you are welcome to make suggestions and/or code
>  > it yourself and offer it back to the community.
>  > --
>  > Steven Critchfield  <critch at basesys.com>


Alfred -

   I'd be pleased if this application was created, even if it was a 
hack to message only to Zap (PRI/ISDN) channels.  There are quite a 
few times when I'd like to send back a message that is something 
other than "busy" so the upstream provider can re-transmit the call 
to trunk group that is not otherwise occupied (before our sharp 
reading audiences gets clever and thinks about this too much, yes, I 
have had situations where a trunk should not be 100% full.)  Many 
upstream switches are programmable so that they will take certain 
action based on Q931 reply code, including "try another trunk group", 
which would serve the purpose for some limited load-spreading 
capability.

   Additionally, there are times when I'd like to answer the call but 
with a different code, such as "NUMBER_CHANGED" or 
"INCOMING_CALL_BARRED".  I can't say I know exactly what this does on 
the upstream side, but I assume messages of this type mean that while 
the call might be answered it is not billed, at least if the remote 
side honors those types of message flags from far-end stations.

   Can someone more knowledgeable come up with reasons that this would 
not function as expected?

JT