09-16-2010 06:21 AM - edited 03-16-2019 12:49 AM
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
Solved! Go to Solution.
09-16-2010 10:28 AM
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
09-17-2010 06:08 AM
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,
09-16-2010 10:28 AM
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
09-16-2010 05:03 PM
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
09-17-2010 06:08 AM
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,
09-17-2010 06:14 AM
Thanks mate,
This has really resolved my problem.
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: