[Home]

Summary:ASTERISK-00198: Fails to send Busy or Congestion to PRI
Reporter:fhedberg (fhedberg)Labels:
Date Opened:2003-08-30 12:12:11Date Closed:2004-09-25 02:49:15
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Asterisk fails to send Busy or Congestion to a incomming call on a PRI, the call just keeps on ringing.

Otherwise the PRI works fine both incoming and outgoing. The setup is an E1 with a E400P.

****** ADDITIONAL INFORMATION ******

extensions.conf

[in same context specified in zapata.conf]

exten => 462760010,1,Congestion

< [02 01 60 f8 08 02 00 c7 05 a1 04 03 80 90 a3 18 03 a1 83 8f 6c 0b 21 83 37 30 33 33 32 33 30 33 33 70 0a c1 34 36 32 37 36 30 30 31 30 ]
< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
< N(S): 048   0: 0
< N(R): 124   P: 0
< 41 bytes of data
-- ACKing all packets from 123 to (but not including) 124
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
< Protocol Discriminator: Q.931 (8)  len=41
< Call Ref: len= 2 (reference 199/0xC7) (Originator)
< Message type: SETUP (5)
< Sending Complete (len= 4)
< Bearer Capability (len= 3) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                              Ext: 1  User information layer 1: A-Law (35)
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 15 ]
< Calling Number (len=13) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation allowed of network provided number (3) '703323033' ]
< Called Number (len=12) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '462760010' ]
Sending Receiver Ready (49)

> [02 01 01 62 ]
> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 049 P/F: 0
> 0 bytes of data
   -- Executing Congestion("Zap/15-1", "") in new stack
   -- Accepting call from '703323033' to '462760010' on channel 15, span 1

> [00 01 f8 62 08 02 80 c7 02 18 03 a9 83 8f ]
> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 124   0: 0
> N(R): 049   P: 0
> 10 bytes of data
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=10
> Call Ref: len= 2 (reference 32967/0x80C7) (Terminator)
> Message type: CALL PROCEEDING (2)
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 15 ]

> [00 01 fa 62 08 02 80 c7 01 18 03 a9 83 8f 1e 02 81 88 ]
> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 125   0: 0
> N(R): 049   P: 0
> 14 bytes of data
T_200 timer already going (1)
> Protocol Discriminator: Q.931 (8)  len=14
> Call Ref: len= 2 (reference 32967/0x80C7) (Terminator)
> Message type: ALERTING (1)
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 15 ]
> Progress Indicator (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]

< [00 01 01 fa ]
< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 125 P/F: 0
< 0 bytes of data
-- ACKing all packets from 123 to (but not including) 125
-- ACKing packet 124, new txqueue is 125 (-1 means empty)
-- Something left to transmit (125), restarting T200 counter

< [00 01 01 fc ]
< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 126 P/F: 0
< 0 bytes of data
-- ACKing all packets from 124 to (but not including) 126
-- ACKing packet 125, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Nothing left, starting T203 counter
Comments:By: Mark Spencer (markster) 2003-09-01 11:12:17

By convention, we send the Busy/Conestion in-band, as opposed to trying to signal it at the PRI layer.  Perhaps an option to digitally signal such call control would be good?
By: fhedberg (fhedberg) 2003-09-01 14:20:30

We did this with a older CVS.

When asterisk executed a Congestion on a call in the context specified in zapata, it played a localized Congestion message from the local CO switch at the remote user side. Wasnt this done with pure pri or was it that our provider interpreted the congestion tone.

If a call was moved into another context or added a prefix or anything, and then executed the Congestion, it wouldnt work just as I described above.

But with a recent CVS, the Congestion doesnt work as described above. Also, should it accually be required to execute a Answer before Congestion or Busy?
By: fhedberg (fhedberg) 2003-09-01 14:21:05

Sorry, dont have a PRI debug from the time that the Congestion message accually worked.
By: x martinp (martinp) 2003-09-04 15:26:54

The congestion or busy is done inband ... we don't have to answer the line we send audio onhook. We could try to introduce the PRI_CAUSE local variable and you could set it up as PRI_CAUSE=1 for example and then call Hangup and asterisk could disconnect with cause PRI_CAUSE. How does that sound ?
By: John Todd (jtodd) 2003-09-06 02:50:05

I think that a digitally signalled version of this would be a Good Thing, so upstream switches can re-route calls appropriately if they are so configured.  Are there multiple possible values for what you're thinking for PRI_CAUSE?  Also, would Hangup work if a channel hasn't been answered yet?

It would seem reasonable that if "PRI_CAUSE" was set to anything non-zero, AND the channel had not yet been picked up, then calling the "Busy" or "Congestion" app would automatically send the code out to the PRI.  If the call was already off-hook, I don't think that Congestion or Busy signals (non-in-band) are valid at that point.  I could be wrong on that; I don't remember much of my q.931 learning these days...

Why use Hangup when there are two apps already "custom-made" for the two error conditions that are being requested?
By: x martinp (martinp) 2003-09-06 10:23:14

If you wouldn't set up PRI_CAUSE with SetVar then it simply wouldn't exit as a variable. Also it does work before the channels get answered. As for Busy and Congestion we don't know how the switch that sent the call will behave when we DISCONNECT or RELEASE the call. That's why those two applications only generate the fast-busy tone and the user that hears that should hang up. That's the purpose of that. Calling Hangup would disconnect the call and when PRI_CAUSE variable is set to any number the cause would be returend with DISCONNECT/RELEASE message.
By: fhedberg (fhedberg) 2003-09-14 08:56:52

The channel should not be required to be offhook before a Congestion/Busy is made as it is now on PRI (at least for me ;) How is it handled with analog FXO's?

Doing only a _X.,1,Busy or Congestion on a zap channel (on a PRI) should result in a PRI message accordingly.

I didnt really understand the point of having the PRI_CAUSE thing. It should be handled auto by the the channels in conjuction with Hangup, Busy, and Congestion.

Could take a look at it if anybody have some pointers to some q.931 specs...

edited on: 10-01-03 15:06
By: John Todd (jtodd) 2003-10-16 04:54:50

You wanted pri specifications:

http://www.loligo.com/asterisk/misc/pri-tr41459_99.pdf

There's the Bellcore spec document, at least, one of them.
By: x martinp (martinp) 2003-11-03 16:09:16.000-0600

Use this syntax:

exten => busy,1,SetVar(PRI_CAUSE=17)
exten => busy,2,Hangup()

Unless someone wants to implement it diffrent way (patches are welcome)
By: Paul Cadach (pcadach) 2003-11-03 21:04:24.000-0600

Reminder sent to martinp

May be better to use this syntax:
Hangup([<release code>])

If optional argument to application Hangup() isn't specified, Hangup() will get release code from PRI_CAUSE variable, otherwise - just argument value will show required release code.

Also, because H.323 uses Q.931 signalling too, theoretically you can send any valid Q.931 release code to H.323 channels too.
By: John Todd (jtodd) 2003-11-05 02:27:32.000-0600

OK, before this gets resolved, I'm uncertain where PRI_CAUSE is referenced in the code.  I can only find specific PRI_CAUSE_blah  results in any of the source code, and no specific reference to a variable called PRI_CAUSE.

Martin, can you please direct me to the file that takes the variable PRI_CAUSE and turns it into something that gets sent out to the PRI?
By: x martinp (martinp) 2003-11-05 10:23:07.000-0600

Well I was looking for it and couldn't find it either so I added it to CVS.