cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4860
Views
0
Helpful
8
Replies

ISDN BRI AWAITING_ESTABLISHMENT

Hi,

I have a 2921 MGCP-controlled gateway with 2 BRI (1VIC2-2BRI), with direct inward dial (the two go on two identical NT with same cabling).
One BRI is working as expected (going into MULTIPLE_FRAME_ESTABLISHED) . The other BRI "seems" to work (int bri0/1/1 goes up) but in show isdn status I can see that it never goes on MULTIPLE_FRAME_ESTABLISHED, and when I try to route call through that BRI they are re-routed to the first bri.

that's the configuration of the two bri

interface BRI0/1/0

no ip address

isdn switch-type basic-net3

isdn overlap-receiving

isdn tei-negotiation first-call

isdn point-to-point-setup

isdn incoming-voice voice

isdn bind-l3 ccm-manager service mgcp

isdn static-tei 0

end

interface BRI0/1/1

no ip address

isdn switch-type basic-net3

isdn overlap-receiving

isdn tei-negotiation first-call

isdn point-to-point-setup

isdn incoming-voice voice

isdn bind-l3 ccm-manager service mgcp

isdn static-tei 0

end

#sh isdn status

Global ISDN Switchtype = primary-net5

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may not apply

ISDN BRI0/1/0 interface

        dsl 4, interface ISDN Switchtype = basic-net3

        L2 Protocol = Q.921 0x0000  L3 Protocol(s) = CCM MANAGER 0x0003

    Layer 1 Status:

        ACTIVE

    Layer 2 Status:

        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

    Layer 3 Status:

        0 Active Layer 3 Call(s)

    Active dsl 4 CCBs = 0

    The Free Channel Mask:  0x80000003

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 5. Layer 3 output may not apply

ISDN BRI0/1/1 interface

        dsl 5, interface ISDN Switchtype = basic-net3

        L2 Protocol = Q.921 0x0000  L3 Protocol(s) = CCM MANAGER 0x0003

    Layer 1 Status:

        ACTIVE

    Layer 2 Status:

        TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED

    Layer 3 Status:

        0 Active Layer 3 Call(s)

    Active dsl 5 CCBs = 0

    The Free Channel Mask:  0x80000003


and that's the output of
debug isdn q921

Jan 28 06:52:54.113: ISDN BR0/1/1 Q921: L2_EstablishDataLink: sending SABME

Jan 28 06:52:54.113: ISDN BR0/1/1 Q921: User TX -> SABMEp sapi=0 tei=0

Jan 28 06:52:55.113: ISDN BR0/1/1 Q921: User TX -> SABMEp sapi=0 tei=0

Jan 28 06:52:56.113: ISDN BR0/1/1 Q921: User TX -> SABMEp sapi=0 tei=0

Jan 28 06:52:56.441: ISDN BR0/1/0 Q921: User TX -> RRp sapi=0 tei=0 nr=31

Jan 28 06:52:56.453: ISDN BR0/1/0 Q921: User RX <- RRf sapi=0 tei=0 nr=17

Jan 28 06:52:57.113: ISDN BR0/1/1 Q921: User TX -> SABMEp sapi=0 tei=0

Jan 28 06:52:58.113: ISDN BR0/1/1 Q921: User TX -> IDVER ri=0 ai=0

Any help will be greatly appreciated..Thanks a lot

gianstefano

8 Replies 8

to update the case, here's the output of
debug isdn error:

debug isdn error interface bri0/1/1

mgw01#

Jan 28 09:43:50.484: ISDN BR0/1/1 SERROR: L2_Go: at bailout DLCB is NULL

        L2: sapi 0 tei 0 ces 1 ev 0x630

Jan 28 09:44:03.008: ISDN BR0/1/1 SERROR: L2_Go: at bailout DLCB is NULL

        L2: sapi 63 tei 127 ces 0 ev 0x650

Jan 28 09:44:13.024: ISDN BR0/1/1 SERROR: L2_Go: at bailout DLCB is NULL

        L2: sapi 63 tei 127 ces 0 ev 0x650

Jan 28 09:44:23.028: ISDN BR0/1/1 SERROR: L2_Go: at bailout DLCB is NULL

        L2: sapi 63 tei 127 ces 0 ev 0x650

Swap cables, and see if the problem stays with interface, or with the circuit.

Note in any case, for best results, you should be using H.323, not MGCP, because the latter has too many bugs and limtiationj

thanks, I know about H323 and MGCP but we're using the BRIs with DID only for a temporary solution: in a couple of weeks we'll have a full PRI on the gateway, and MGCP has no problems with our PRI configuration :-)

Anyway, monday we have scheduled some tests on the case, I've found that the "broken" NT1 is nor responding: it does not send any message, the isdn layer 1 comes up but the NT1 does not acknoledge or send anything...

thanks 4 your help

g

H.323 or SIP is better anyway, with BRI or PRI.

I see, but for our purposes MGCP is enough, at least for PRI :-).
Anyway, after the tests on BRI links, if we'll see that the problem is the protocol we'll manage to setup a H.323 gateway to control the 3 temporary BRI

Even if "enough", you would still be using an inferior solution.

Please remember to rate useful posts clicking on the stars below.

Imho what qualifies a solution is the satisfaction of design specification (in the simplest manner) and of the customer requirements: in our setup, MGCP is absolutely satisifying them, at least for PRI channels, so we're not going to change them for some other protocol.
I'm not going to argue about superiority or inferiority of H.323 or SIP, we have MGCP and it works as expected. If we'll see that the bri problem is due to MGCP (I don't think so, but we'll check tomorrow) then we'll implement SIP or H.323 for temporary BRI channels.

Just to update the case: the problem was due to the two NT1 state: after the local provider (Telecom ITalia)  resetted the NT, the BRIs came up, and work as expected.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: