Summary:ASTERISK-07363: E1 ISDN Won't Start - !! Got a UA, but i'm in state 1
Reporter:Matt King, M.A. Oxon. (kebl0155)Labels:
Date Opened:2006-07-20 03:50:10Date Closed:2011-06-07 14:02:37
Versions:Frequency of

We've been trying to upgrade a customer with a TE406 from Asterisk 1.2.6 (Zap 1.2.5 LibPri 1.2.2) to Asterisk 1.2.10 (Zap 1.2.7 LibPri 1.2.3).  I've also tried Asterisk (Zap 1.2.6 LibPri 1.2.3) and have the same problem - so I'm guessing it's a libpri thing.

When I start the server I get messages like this:

!! Got a UA, but i'm in state 1
 == Primary D-Channel on span 1 down
Jul 20 09:19:24 WARNING[5107]: chan_zap.c:2290 pri_find_dchan: No D-channels available!  Using Primary channel 16 as D-channel anyway!
 == Primary D-Channel on span 1 up

These appear irregularly, but the channels don't then come up and the customer is unable to take calls.  We never used to get the "Got a UA" message with libpri 1.2.2.  I think it might be something to do with if somebody tries to make a call while the spans are starting.

I've done a bug search, googled the lists, made a post to the users list, and asked on the IRC channel, so I guess it's time to post.  This customer really needs to upgrade as they're getting intermittent faults with asterisk 1.2.6 that our other customers don't see.

Can you help me?
Comments:By: Frederic LE FOLL (flefoll) 2006-07-20 05:15:27

Just my 2 cents :

"!! Got a UA, but i'm in state 1" is a Libpri trace because it receives a UA frame while it is not in Q921_AWAITING_ESTABLISH state.
State 1 is Q921_LINK_CONNECTION_ESTABLISHED, thus I guess that the SABME/UA sequence already occurred, and Libpri does not expect a new UA.

"== Primary D-Channel on span 1 down" is an Asterisk chan_zap trace because it received a PRI_EVENT_DCHAN_DOWN event from Libpri. There are several reasons why Libpri may send this event (but getting UA in state 1 alone does not seem to be one of them ...).

Can you reproduce this problem with "pri intense debug span 1" ? Beware, intense really means intense ! Otherwise, you change q921.c so that traces before each call to q921_dchannel_down() are unconditional : there already are traces, but they are activated by PRI_DEBUG_Q921_STATE boolean flag.

They are few changes between Libpri 1.2.2 and 1.2.3 and I see none of them related to Layer 2 (q921.c files even are the same).

By: Matt King, M.A. Oxon. (kebl0155) 2006-07-20 07:08:45

Hello Flefoll,

Thanks so much for the swift response!

This is a production environment, and this bug stops them from taking calls so it's going to be tricky; I'll see if I can reproduce the problem out-of-hours this evening.  Is there any other information needed?

I wonder if there's a way of reproducing the bug without causing zap to take the span down?  Then we could debug without disturbing calls...

Thanks again,


By: Russell Bryant (russell) 2006-07-20 09:58:35

As this is an issue related to the use of Digium hardware, please pursue this issue with Digium technical support - support@digium.com.  They will be able to help you address this issue.