| 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 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Hello, 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 1.2.9.1 (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 1.2.9.1 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, Matt. 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. | ||