[asterisk-dev] On PRIs, blocked channels, congestiona and telco technicians

[Matthew Fredrickson]

Edwin Groothuis wrote:
> On Fri, May 30, 2008 at 07:01:26AM -0500, Will wrote:
>> On Thu, May 29, 2008 at 11:22 PM, Edwin Groothuis <edwin at mavetju.org> wrote:
>>> How wrong? He says it happens when the restart message is answered
>>> too late (i.e. before the next restart message) or with the wrong
>>> data (reset of channel 0/1 is completed while reset of channel 0/2
>>> is expected).
>> Just an idea, but maybe this happens when both sides try to reset the
>> channels at the same time, or have overlapping resets.  Have you tried
>> disabling resets on your side since the other side seems to be doing
>> them anyway?  Hopefully the pri debug will show something.
> 
> I found two things:
> 
> First one is that the exchanges of the telco don't like the RESTART
> asterisk is sending:
> 
>> Protocol Discriminator: Q.931 (8)  len=14
>> Call Ref: len= 2 (reference 0/0x0) (Originator)
>> Message type: RESTART (70)
>> [18 04 e9 80 83 8c]
>> Channel ID (len= 6) [ Ext: 1  IntID: Explicit  PRI  Spare: 0  Exclusive  Dchan: 0
>>                        ChanSel: Reserved
>>                       Ext: 1  DS1 Identifier: 0  
>>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>>                       Ext: 1  Channel: 12 ]
>> [79 01 80]
>> Restart Indentifier (len= 3) [ Ext: 1  Spare: 0  Resetting Indicated Channel (0) ]
> 
> < Protocol Discriminator: Q.931 (8)  len=14
> < Call Ref: len= 2 (reference 0/0x0) (Terminator)
> < Message type: STATUS (125)
> < [08 04 82 e4 98 18]
> < Cause (len= 6) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Public network serving the local user (2)
> <                  Ext: 1  Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]
> <              Cause data 1: 98 (152)
> <              Cause data 2: 18 (24)
> < [14 01 00]
> < Call State (len= 3) [ Ext: 0  Coding: CCITT (ITU) standard (0)  Call state: Null (0)
> 
> I will have to figure out what it is telling us here...
> 

There are two things that I would like to see verified.  The first is 
that your switchtype is indeed matching the switch type that the other 
end is using.

I suspect your other problem might be that you have your PRI 
configuration incorrect as well.  It would appear that you are using the 
trunkgroup/spanmap options in zapata.conf to setup your PRI.  You should 
ONLY use these if you are using NFAS.  If you are not, you should simply 
setup your PRI using the implicit D-channel selection logic (comment out 
your span maps and trunk groups, and set just set your channel= lines 
for the bearer channels in the PRI).

The intended affect will be this:

In your Channel ID information element, you currently have a DS1 
Identifier field set.  That field should not be set or present if you do 
not have an NFAS setup.  When you use the trunkgroup/spanmap settings, 
it tells asterisk to set this field, which I think might be causing th e 
other switch to complain about the restarts.


> The other one is that Asterisk is deadlocking in the restart of PRI
> channels: If a channel doesn't return an RESTART ACKNOWLEDGE, it
> will hang there forever. I have written a patch for this (against
> 1.4.19, but it will be easy to use it on further releases. 
> 
> See http://bugs.digium.com/view.php?id=12766 for details.

Try my recommendation above first.  I think fixing your configuration 
might fix this problem.

-- 
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.