[Asterisk-Dev] PRI/T1-Signaling

[Alfred R. Nurnberger]

-----Original Message-----
From: asterisk-dev-admin at lists.digium.com
[mailto:asterisk-dev-admin at lists.digium.com]On Behalf Of John Todd
Sent: Friday, January 09, 2004 4:39 PM
To: asterisk-dev at lists.digium.com
Subject: RE: [Asterisk-Dev] PRI/T1-Signaling


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
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

JT.

I think it should be possible to emulate the behavoir of "Number changesd,
Call Barred"
by doing Playtones() without answering the line first. As Steven mentioned
the PRI cards are
able to transmit audio before answer. Even a recorded message "This number
has been disconnected ..."
should be possible to play to the remote party without answer and call
charges.


-Alfred.