[Asterisk-Users] E1 PRI error: "!! Got I-frame while link state 2" and "!! Got a UA, but i'm in state 1" (long)

[steve at daviesfam.org]

On Wed, 19 Oct 2005, Dinesh Nair wrote:

> hey * folk,
> 
> i've got a TE410P (generation 1 firmware) stuck in a box with a single xeon
> 2.8Ghz and 1GB RAM. there's a loopback E1 cable connecting span 1 to span 4
> (zaptel.conf and zapata.conf below). upon starting up asterisk, i see the
> following errors consistently on the screen,
> 
> !! Got I-frame while link state 2
> !! Got a UA, but i'm in state 1
> 

This boils down to "I'm trying to start up the link, but the other side 
seems to think that it IS up".

In an earlier post you showed that you had some spans set for internal 
clocking, some for external.  If you are using loopback cables, I'd 
suggest setting all the spans for internal (X,0,0,ccs,hdb3[,crc4])

Make sure nothing else is connected on the PRI, just the loopback cable.  
And the loopback wiring is the pair on 1/2 crossed over to the pair on 
4/5.

> a snapshot of pri debug span 1, shows:

The part you posted is just where Asterisk is restarting each B-channel.  
More useful would be the part corresponding to the debug messages logged 
above.


> could it be due to a buggy card ? if this is the case, i really wont be
> able to tell as i dont have any spare cards to test with. i've read that
> the newer versions of the drivers may cause similar problems to old cards,
> but since we're on freebsd, we're unable to revert to an old version of the
> driver.

I'm not sure how old your card is, but I routinely run the CVS-HEAD 
zaptel/libpri/asterisk on generation 1, "version 10" cards.

> --- zaptel.conf ---
> bchan=1-15
> dchan=16
> bchan=17-31
> span=1,0,0,ccs,hdb3,crc4
> bchan=32-46
> dchan=47
> bchan=48-62
> span=2,1,0,ccs,hdb3,crc4
> bchan=63-77
> dchan=78
> bchan=79-93
> span=3,0,0,ccs,hdb3,crc4
> bchan=94-108
> dchan=109
> bchan=110-124
> span=4,1,0,ccs,hdb3,crc4
> --- zaptel.conf ---

Unusual order here.  I've always followed the sample and put the span 
definitions at the top and the bchan/dchan following.

Also, see the comment about the "1" for taking clock - rather make it 0 
for loopback tests.

(You've also asked for two primary sync sources, which isn't right).



> 
> --- zapata.conf ---
> [channels]
> signalling=pri_net
> context=default
> group=1
> callgroup=1
> pickupgroup=1
> priindication=outofband
> switchtype=euroisdn
> context=default
> amaflags=default
> busycount=4
> callwaiting=no
> transfer=yes
> useincomingcalleridonzaptransfer=yes
> threewaycalling=yes
> callreturn=yes
> relaxdtmf=no
> busydetect=no
> usecallerid=yes
> hidecallerid=no
> echocancel=yes
> echocancelwhenbridged=no
> echotraining=no
> immediate=no
> channel => 1-15
> channel => 17-31
> 
> signalling=pri_cpe
> context=default
> group=1
> callgroup=1
> pickupgroup=1
> priindication=outofband
> switchtype=euroisdn
> context=default
> amaflags=default
> busycount=4
> callwaiting=no
> transfer=yes
> useincomingcalleridonzaptransfer=yes
> threewaycalling=yes
> callreturn=yes
> relaxdtmf=no
> busydetect=no
> usecallerid=yes
> hidecallerid=no
> echocancel=yes
> echocancelwhenbridged=no
> echotraining=no
> immediate=yes
> channel => 94-108
> channel => 110-124
> --- zapata.conf ---


Did you leave out the other two spans in your zapata.conf?

Its a bit unusual to put both spans in the same group - calls to Zap/g1 
may use any channel on either of the spans.  Is that what you want?
And immediate=yes is probably not what you want for an ISDN link.

Steve