|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:10||Date Closed:||2011-06-07 14:02:37|
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 18.104.22.168 (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: 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 22.214.171.124 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
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...
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 - firstname.lastname@example.org. They will be able to help you address this issue.