BRI ISDN Advice...

[VLT06]

Ok, the short and sweet of it all….

Converting 2911 with BRI from MGCP to SIP trunk and all works fine (both in/out calls) however I have observed that when in an idle state, Layer 1 is DEACTIVATED??? When a call establishes, layer 1 becomes ACTIVE and I get the normal MULTIPLE_FRAME_ESTABLISHED for layer 2.

When the calls disconnects, MULTIPLE_FRAME_ESTABLISHED drops off after about 5 seconds, then Layer 1 goes back to DEACTIVATED about 10 seconds after that. Even though calls work, is this normal behaviour for a BRI behind SIP to CUCM?

Current config

 voice-port 0/2/0

 disc_pi_off

 compand-type a-law

 cptone AU

 timeouts interdigit 3

 timeouts call-disconnect 3

 timeouts wait-release 5

 description VNM BRI-ISDN-2

 bearer-cap Speech

I have also tried adding the following with no change

- isdn static-tei 0

- isdn tei-negotiation first-call

- isdn tei-negotiation preserve

2911 with IOS Version 15.4(3)M2, RELEASE SOFTWARE (fc2)

Any thoughts?

[Mohammed al Baqari]

Nope this isn't normal behavior for BRI. Can you share the output of deb
isd q921 after the call is completed.

[VLT06]

Hi Mohammed, sure, please see below with an inbound tast call;

Sep 27 14:40:52.497 aest: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to priority 1
Sep 27 14:40:52.497 aest: ISDN BR0/2/0 Q921: L2_EstablishDataLink: sending SABME
Sep 27 14:40:52.501 aest: ISDN BR0/2/0 Q921: User TX -> SABMEp sapi=0 tei=86
Sep 27 14:40:52.513 aest: ISDN BR0/2/0 Q921: User RX <- UAf sapi=0 tei=86
Sep 27 14:40:52.549 aest: %LINK-3-UPDOWN: Interface BRI0/2/0, changed state to up
Sep 27 14:40:52.701 aest: ISDN BR0/2/0 Q921: User RX <- UI sapi=0 tei=127
Sep 27 14:40:52.713 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=0 nr=0
Sep 27 14:40:52.729 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=1
Sep 27 14:40:52.857 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=1 nr=0
Sep 27 14:40:52.873 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=2
Sep 27 14:40:59.789 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=2 nr=0
Sep 27 14:40:59.805 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=3
Sep 27 14:40:59.849 aest: ISDN BR0/2/0 Q921: User RX <- INFO sapi=0 tei=86, ns=0 nr=3-----------------> Call Answered
Sep 27 14:40:59.849 aest: ISDN BR0/2/0 Q921: User TX -> RR sapi=0 tei=86 nr=1
Sep 27 14:41:09.849 aest: ISDN BR0/2/0 Q921: User TX -> RRp sapi=0 tei=86 nr=1
Sep 27 14:41:09.861 aest: ISDN BR0/2/0 Q921: User RX <- RRf sapi=0 tei=86 nr=3
Sep 27 14:41:14.269 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=3 nr=1-----------------> Call Hung Up
Sep 27 14:41:14.285 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=4
Sep 27 14:41:14.369 aest: ISDN BR0/2/0 Q921: User RX <- INFO sapi=0 tei=86, ns=1 nr=4
Sep 27 14:41:14.369 aest: ISDN BR0/2/0 Q921: User TX -> RR sapi=0 tei=86 nr=2
Sep 27 14:41:14.373 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=4 nr=2
Sep 27 14:41:14.389 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=5
Sep 27 14:41:24.389 aest: ISDN BR0/2/0 Q921: User TX -> RRp sapi=0 tei=86 nr=2
Sep 27 14:41:24.393 aest: ISDN BR0/2/0 Q921: User RX <- RRp sapi=0 tei=86 nr=5
Sep 27 14:41:24.393 aest: ISDN BR0/2/0 Q921: User TX -> RRf sapi=0 tei=86 nr=2
Sep 27 14:41:24.401 aest: ISDN BR0/2/0 Q921: User RX <- RRf sapi=0 tei=86 nr=5
Sep 27 14:41:29.381 aest: ISDN BR0/2/0 Q921: User RX <- DISCp sapi=0 tei=86---------------------------> MULTIPLE_FRAME_ESTABLISHED Drops
Sep 27 14:41:29.381 aest: ISDN BR0/2/0 Q921: User TX -> UAf sapi=0 tei=86
Sep 27 14:41:59.965 aest: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10
Sep 27 14:42:00.017 aest: %LINK-3-UPDOWN: Interface BRI0/2/0, changed state to down-------------------> Layer 1 change to DEACTIVATED

[Mohammed al Baqari]

Open a ticket with your provider. Seems they are dropping the link. The
message is RX

[VLT06]

Thanks, yeah I guess I will give it a go. The only thing is that if I change the protocol to MGCP, it says up fine...???

[Mohammed al Baqari]

No, it should be fine. Please remember to rate useful posts

[VLT06]

Yeah, still the same. Carrier advised all good from their end (which i suspected as this has no issue with MGCP)...