cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1191
Views
0
Helpful
4
Replies

D channel in E1 says 2=Outofservice

mangesh-bhende
Level 1
Level 1

Hi,

I have two 2821 CME's connected back to back using cross serial and cross E1 cable, configured E1 for ISDN call and Serial for VOIP call. This setup works very well for Serial WAN link but unable to establish call over E1. E1 controller is up, ISDN L1, L2 is up but still dont know why i am unable to establish calls over PRI link. I also saw that 16th channel is out of service using show isdn service command.Kindly help me to troubleshoot this issue. For your reference i have attached running config of both CME's.

=========================================================================

CME-1  (Configured as network side ISDN)

=========================================================================
network-clock-participate wic 0
!
isdn switch-type primary-net5
!
voice-card 0
no dspfarm
!
voice-card 1
no dspfarm
!
controller E1 0/0/0
clock source internal
pri-group timeslots 1-31
!
interface Serial0/0/0:15
no ip address
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice voice
!
interface Serial0/1/0
ip address 192.168.1.1 255.255.255.252
clockrate 2000000
!
voice-port 0/0/0:15
!
dial-peer voice 1 voip
preference 5
destination-pattern 6564......
session target ipv4:192.168.1.2
!
dial-peer voice 3 pots
preference 2
destination-pattern 65........
no digit-strip
port 0/0/0:15
!

CME-1#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0/0:15 interface
        ******* Network side configuration *******
        dsl 0, interface ISDN Switchtype = primary-net5
    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 0 CCBs = 0
    The Free Channel Mask:  0xFFFF7FFF
    Number of L2 Discards = 0, L2 Session ID = 1
    Total Allocated ISDN CCBs = 0

CME-1#show controllers e1 0/0/0
E1 0/0/0 is up.
  Applique type is Channelized E1 - balanced
  No alarms detected.
  alarm-trigger is not set
  Version info Firmware: 20041023, FPGA: 16, spm_count = 0
  Framing is CRC4, Line Code is HDB3, Clock Source is Internal.
  CRC Threshold is 320. Reported from firmware  is 320.
  Data in current interval (337 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 1:
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 2:
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 3:
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 4:
     1 Line Code Violations, 4 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins
     2 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Total Data (last 4 15 minute intervals):
     1 Line Code Violations, 4 Path Code Violations,
     0 Slip Secs, 0 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins,
     2 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

CME-1#show isdn service
PRI Channel Statistics:
ISDN Se0/0/0:15, Channel [1-31]
  Configured Isdn Interface (dsl) 0
   Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart 5=Maint_Pend)
    Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   Service State (0=Inservice 1=Maint 2=Outofservice 8=MaintPend 9=OOSPend)
    Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    State   :    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

===============================================================

CME-2

================================================================

network-clock-participate wic 0
isdn switch-type primary-net5
!
voice-card 0
no dspfarm
!
voice-card 1
no dspfarm
!
controller E1 0/0/0
pri-group timeslots 1-31
!
interface Serial0/0/0:15
no ip address
isdn switch-type primary-net5
isdn incoming-voice voice
!
interface Serial0/1/0
ip address 192.168.1.2 255.255.255.252
!
voice-port 0/0/0:15
!
dial-peer voice 1 voip
preference 5
destination-pattern 91..........
session target ipv4:192.168.1.1
!
dial-peer voice 3 pots
preference 2
destination-pattern 9...........
no digit-strip
port 0/0/0:15
!


CME-1#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0/0:15 interface
        dsl 0, interface ISDN Switchtype = primary-net5
    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 0 CCBs = 0
    The Free Channel Mask:  0xFFFF7FFF
    Number of L2 Discards = 0, L2 Session ID = 0
    Total Allocated ISDN CCBs = 0

CME-2#show controllers e1 0/0/0
E1 0/0/0 is up.
  Applique type is Channelized E1 - balanced
  No alarms detected.
  alarm-trigger is not set
  Version info Firmware: 20041023, FPGA: 16, spm_count = 0
  Framing is CRC4, Line Code is HDB3, Clock Source is Line.
  CRC Threshold is 320. Reported from firmware  is 320.
  Data in current interval (833 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     125 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     125 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 1:
     0 Line Code Violations, 0 Path Code Violations
     135 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     135 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 2:
     0 Line Code Violations, 0 Path Code Violations
     135 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     135 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 3:
     0 Line Code Violations, 0 Path Code Violations
     134 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     134 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 4:
     0 Line Code Violations, 0 Path Code Violations
     136 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     136 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Data in Interval 5:
     137 Line Code Violations, 3881 Path Code Violations
     128 Slip Secs, 0 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins
     129 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 33 Unavail Secs
  Total Data (last 5 15 minute intervals):
     137 Line Code Violations, 3881 Path Code Violations,
     668 Slip Secs, 0 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins,
     669 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 33 Unavail Secs

CME-2#show isdn service
PRI Channel Statistics:
ISDN Se0/0/0:15, Channel [1-31]
  Configured Isdn Interface (dsl) 0
   Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart 5=Maint_Pend)
    Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   Service State (0=Inservice 1=Maint 2=Outofservice 8=MaintPend 9=OOSPend)
    Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    State   :    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

2 Accepted Solutions

Accepted Solutions

Felipe Garrido
Cisco Employee
Cisco Employee

I just checked my lab setup and see the same thing for the D channel. I don't think that's what's causing the calls to fail.  The pots dial-peers are missing  "direct-inward-dial." If you are just hearing dial-tone, after already have dialed the number, then that's the problem. Add the command and test.

-Felipe

View solution in original post

Glad it worked.  The inbound dial-peer will be selected based on the following criteria,

1. Incoming called-number

2. Answer-address

3. destination-pattern

4. port

Preference will only be used if there are two dial-peers that have the same configuration. Also, the most explicit match will take precendence over more generic matches.

So, "91...." will be matched over "9....."

The reason why the call is taking so long to be made is probably due to the interdigit timeout. if you have a pattern that ends in "T" then the gateway will wait the 10 -15 seconds, depending on the timer setting, before processing the call after the last digit.

For more information,

http://www.cisco.com/en/US/customer/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml#topic1

View solution in original post

4 Replies 4

Felipe Garrido
Cisco Employee
Cisco Employee

I just checked my lab setup and see the same thing for the D channel. I don't think that's what's causing the calls to fail.  The pots dial-peers are missing  "direct-inward-dial." If you are just hearing dial-tone, after already have dialed the number, then that's the problem. Add the command and test.

-Felipe

Dear Felipe,

excellent, it worked for me. Thank you very much. one more small querry that

1) when i dial with both links up why the dial peer always chooses voip dialpeer whoose preference is 5 and why not with POTS whose preference is 2?.

2) Why pots takes some time to dial out? its like almost 15 seconds?

Regards

Mangesh Bhende

Glad it worked.  The inbound dial-peer will be selected based on the following criteria,

1. Incoming called-number

2. Answer-address

3. destination-pattern

4. port

Preference will only be used if there are two dial-peers that have the same configuration. Also, the most explicit match will take precendence over more generic matches.

So, "91...." will be matched over "9....."

The reason why the call is taking so long to be made is probably due to the interdigit timeout. if you have a pattern that ends in "T" then the gateway will wait the 10 -15 seconds, depending on the timer setting, before processing the call after the last digit.

For more information,

http://www.cisco.com/en/US/customer/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml#topic1

Thanks mate,

This has really resolved my problem.

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: