01-27-2012 10:56 PM - last edited on 03-25-2019 08:12 PM by ciscomoderator
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
01-28-2012 01:46 AM
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
01-28-2012 12:26 PM
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
01-28-2012 01:33 PM
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
01-28-2012 02:00 PM
H.323 or SIP is better anyway, with BRI or PRI.
01-28-2012 02:35 PM
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
01-29-2012 01:59 AM
Even if "enough", you would still be using an inferior solution.
Please remember to rate useful posts clicking on the stars below.
01-29-2012 02:16 AM
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.
01-30-2012 06:43 AM
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.
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: