BRI problems / layer 1 deactivated

Question

Hi there
I could really use some help for this issue. I need to implement a BRI line for voice as backup for a SIP line.
However I cannot make layer 1 come up as active. I know for sure the line is working as attaching a phone to the ISDN2 line makes me able to receive and make calls. So the line is ok from teleprovider side. Must be cable issue, makes a cable according to Cisco doc. "When the ISDN BRI port on the router is configured as an NT port, you must use a "rolled" cable (one with the transmit and receive leads swapped) to connect to a TE interface." But this does not help me still same outcome.
Any help is much appriciated.
Cisco2921 router IOS: 15.0 (1r) with BRI module NT/TE 2gen.
VGW#sh isdn status
Global ISDN Switchtype = basic-net3
ISDN BRI0/0/0 interface
        dsl 0, interface ISDN Switchtype = basic-net3
    Layer 1 Status:
        DEACTIVATED
    Layer 2 Status:
        Layer 2 NOT Activated
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask:  0x80000003
ISDN BRI0/0/1 interface
        dsl 1, interface ISDN Switchtype = basic-net3
    Layer 1 Status:
        DEACTIVATED
    Layer 2 Status:
        Layer 2 NOT Activated
    Layer 3 Status:
        0 Active Layer 3 Call(s)
    Active dsl 1 CCBs = 0
    The Free Channel Mask:  0x80000003
    Total Allocated ISDN CCBs = 0
VGW#sh controllers bri0/0/0
BRI unit 0:
layer 1 operating in LT-T mode.
Layer 1 is DEACTIVATED. (ISDN L1 State F3)
D Channel Information:
idb at 0x294042F4, driver data structure at 0x2941FF40
Infineon Chip Version 0x1
Infineon Registers:
Int. Status Register [ISTA]=0x00, Aux. Int. [AUXI]=0x00
D-channel: Int. Status Reg: [ISTAD]=0x00, Status. Reg: [STARD]=0x40
Mode Reg: [TR_MODE]=0x01
Transceiver Reg: [TR_CONF0]=0x00
Test mode Reg: [TMD]=0x00
IOM Control Reg: [IOM_CR]=0x08
Status Register [STAR]=0x40, Mode Register [MODED]=0xCA
Serial Data Strobe Control Reg: [SDS1_CR]=0x00, [SDS2_CR]=0x00
RX Buffer Descriptor is at 0x30BF37E4, Buffer size 1524
pak=0x3172EF74 data_ptr=0xE1D5FD4 partial_size=0x0
TX Buffer Descriptor is at 0x2940FEBC
pak=0x0 data_ptr=0x0 partial_size=0x0
  0 missed datagrams, 0 overruns
  0 bad datagram encapsulations, 0 memory errors
  0 transmitter underruns  0 d channel collisions
B1 Channel Information:
  0 missed datagrams, 0 overruns
  0 bad datagram encapsulations, 0 memory errors
  0 transmitter underruns  0 d channel collisions
B2 Channel Information:
  0 missed datagrams, 0 overruns
  0 bad datagram encapsulations, 0 memory errors
  0 transmitter underruns  0 d channel collisions
B2 Channel Information:
  0 missed datagrams, 0 overruns
  0 bad datagram encapsulations, 0 memory errors
  0 transmitter underruns  0 d channel collisions
interface BRI0/0/0
no ip address
isdn switch-type basic-net3
isdn overlap-receiving
isdn point-to-point-setup
isdn incoming-voice voice interface BRI0/0/0
no ip address
isdn switch-type basic-net3
isdn overlap-receiving
isdn point-to-point-setup
isdn incoming-voice voice

Answer 1

I had this problem a few months ago and it took several days of investigation and research to figure it out but I got there in the end.  Hopefully this will save someone else a lot of frustration!
In short it was mainly sorted by adding the bearer-cap Speech command to my extra voice-ports.
This command specifies whether the 'call' will initialize for voice or data during the setup and can cause the line to drop/disconnect if it is set incorrectly.
FULL DETAILS
My client was using a UC540W-BRI-K9 with 2 phone lines coming in over a single ISDN device connected to a voice-port.  They had purchased a plug-in 2-port voice-board to allow them to utilize another 4 phone lines via an extra 2 ISDN devices, however the company who installed this had failed to configure the system properly so even after I activated the extra lines they would always fail to dial-out as above.
The first step was to tell the plug-in voice-board to use the network-clock and set the ISDN-connected BRIs to use the network-clock:
network-clock-participate wic 1 
network-clock-participate wic 2 
network-clock-select 1 BRI0/1/0
network-clock-select 2 BRI0/1/1
network-clock-select 3 BRI0/2/0
I spent time investigating the BRI configuration, adding a few bits which I think helped activate the lines, although I still had the outgoing call failures on the new lines:
interface BRI0/1/0
 no ip address
 isdn switch-type basic-net3          <--- Copied this command to the other BRIs
 isdn tei-negotiation first-call   <--- Added this to all the BRIs
 isdn point-to-point-setup
 isdn incoming-voice voice
 isdn sending-complete
 isdn static-tei 0                          <--- Added this to all the BRIs
 trunk-group ALL_BRI 64                <--- Copied this command to the other BRIs
I then found the voice-ports had a separate configuration independent of the BRIs and the newly connected voice-ports required a couple of commands to be copied from the original, working voice-port.  The problem was fixed once I applied the bearer-cap Speech command to the extra voice-ports, along with compand-type a-law (for a European system).
voice-port 0/1/0          <--- The original voice-port connected to the primary ISDN
 compand-type a-law        <--- Copied to the newly-connected voice-ports
 bearer-cap Speech         <--- Copied to the newly-connected voice-ports
voice-port 0/1/1            <--- Connected to 2nd ISDN
 compand-type a-law
 bearer-cap Speech
voice-port 0/2/0            <--- Connected to 3rd ISDN
 compand-type a-law
 bearer-cap Speech
voice-port 0/2/1            <--- Unused
The compand-type command is used to convert signals from analog to digital and is normally compand-type u-law for North America systems and compand-type a-law for European systems, as explained here:
http://www.cisco.com/en/US/docs/ios/12_3/vvf_r/vrg_c4_ps1839_TSD_Products_Command_Reference_Chapter.html#compand-type