Summary:ASTERISK-02077: Zaptel or Libpri: PRI protocol error reseting calls
Reporter:acertain (acertain)Labels:
Date Opened:2004-07-21 11:34:01Date Closed:2011-06-07 14:00:42
Versions:Frequency of
Environment:Attachments:( 0) pri-intense-debug.txt
Description:NOTICE[90123]: chan_zap.c:6872 pri_dchannel: PRI got event: 8 on > Primary D-channel of span 1

Eventually all channels go down, a restart of Asterisk is not sufficient and a reload of Zaptel is required.


Not timming or slipping error, not interrupt error, aparently a software or protocol error.

1-Public Switch sends a message that asterisk doesn't understand (PACKAGE TOO LARGE says the PRI-Intense Debug).
2-Asterisk sends a RESTART CHANNEL message to Public Switch
3-Public Switch sends a RESTART ACK message to asterisk (and all calls are dropped)

Currently we are getting the error with a EWSD Siemens and a Fujitsu public switch.
Comments:By: acertain (acertain) 2004-07-21 11:40:31

Sorry, the Zaptel reload is not required in this issue. The B channels restart by themselves.

By: acertain (acertain) 2004-07-21 11:56:40

This bug was already sent to support@digium.com but we only received a little suggestion to remove alaw=1-31 on the zaptel.conf file that doesn't work. The asterisk bussines on our country depends on this issue, we have been working on that for the last 30 days unsuccessfully so we decided to submit a bug.

By: acertain (acertain) 2004-07-21 12:18:19

Using the last CVS (July 21th, 11:57 AM, GTM-5) we get this new line for chan_zap.c:

NOTICE[12300]: chan_zap.c:7001 pri_dchannel: PRI got event: 6 on Primary D-channel of span 1

By: jharragi (jharragi) 2004-07-21 12:56:32

I encounter a similar situation that may be related... it has not been reported as I just recently set up the machine and was still trying to determine if it is a config error. The T is from a T100P to a 100D module on a merlin legend (my current theory is that the Merlin uses some messeges that are un-implemented in libpri). Calling into the merlin initiates the disconnects. The message that proceeds the disconnects is...
chan_zap.c:1891 pri_find_dchan: No D-channels available!  Using Primary on channel anyway 24!
...are you getting something like that?

By: Brian West (bkw918) 2004-07-21 13:35:17

has this always done this? and has the telco checked the line cards on their side to make sure they are not bad?

I'm just asking because we went thru 13 hours of hell with qwest and all we received as bouncing D's and event 6 and 8's all over the place.  Its related to clocking and a bad linecard.  It just magically started working when we disabled the first span and tweaked the clocking.


By: acertain (acertain) 2004-07-21 14:19:06

Hi again, the public side is OK, and as I told you before it's not a timming problem. Our customer have a Panasonic D500 and when they connect the PRI to this one works just fine with the same timing we are using on the Asterisk System.

By: Malcolm Davenport (mdavenport) 2004-07-21 15:59:30

This is a technical support issue.  Please e-mail Digium technical support using e-mail support@digium.com