06-15-2015 02:10 AM - edited 03-17-2019 03:20 AM
Hello I have a setup where the two ends of link are routers conencted to PABX
Trunk dialling is required but when then call there is a message "Call Cannot be completed" before the call is actually forwarded and established fine.
Any advise as to how this can be overcome? Let me know if any other relevant information is needed.
the configuration on the E1s are as follows:
A end
!
controller E1 0/0/1
framing NO-CRC4
pri-group timeslots 1-31
description ### PABX MITEL ###
!
!
interface Serial0/0/1:15
no ip address
encapsulation hdlc
isdn switch-type primary-qsig
isdn overlap-receiving T302 2000
isdn incoming-voice voice
isdn send-alerting
isdn bchan-number-order ascending
no cdp enable
!
voice-port 0/0/1:15
cptone GB
timeouts interdigit 5
bearer-cap Speech
!
B end
!
controller E1 0/0/0
framing NO-CRC4
pri-group timeslots 1-31
description ### PABX MITEL ###
!
!
voice-port 0/0/0:15
cptone GB
timeouts interdigit 5
bearer-cap Speech
!
!
interface Serial0/0/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-qsig
isdn overlap-receiving T302 2000
isdn incoming-voice voice
isdn send-alerting
isdn bchan-number-order ascending
no cdp enable
!
Solved! Go to Solution.
06-16-2015 09:00 PM
Hello Kaushik,
I have gone through debug output, and problem is due to some misconfiguration in dial-peers.
So call is routed in two attempts.
- First gateway routes the call using first digit, so there has been no dial-peers for that, so that's why you get that announcement first.
Incoming Dial-peer=4000
Called Number=8(TON=Unknown, NPI=Unknown), Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE, Outgoing Dial-peer=1001, Call Count On=FALSE, Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
Failure observed:
*Jun 15 14:39:49.791: //179/2CFC01BE8037/CCAPI/cc_api_call_disconnected: Cause Value=1, Interface=0x271EB1C, Call Id=179
- After failure to route call with one dial-peer, as per default hunting mechanism it tries to send the call again , with another dial-peer.
Called Number=8268(TON=Unknown, NPI=Unknown), Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE, Outgoing Dial-peer=3001, Call Count On=FALSE, Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=) *Jun 15 14:39:49.803: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
This time call connects. So problem seems to be happened due to these two dial-peers.
dial-peer voice 1000 voip translation-profile outgoing profile1 preference 2 destination-pattern . progress_ind setup enable 3 session target ipv4: dtmf-relay h245-alphanumeric playout-delay nominal 130 playout-delay mode fixed fax-relay ecm disable fax rate 9600 fax nsf 000000 ip qos dscp cs5 media ip qos dscp cs5 signaling clid network-number 441224374190 no vad ! dial-peer voice 1001 voip translation-profile outgoing profile1 preference 1 destination-pattern . progress_ind setup enable 3 session target ipv4: dtmf-relay h245-alphanumeric playout-delay nominal 130 playout-delay mode fixed fax-relay ecm disable fax rate 9600 fax nsf 000000 ip qos dscp cs5 media ip qos dscp cs5 signaling clid network-number 441224374190 no vad !
As they can route the call using only one digits, which is for sure , will be rejected by other end, so you get that announcement.
So to fix this problem, either you can shut these dial-peer if they are not in use, or you can modify the destination-patter, so that it will not match with any random digit.
so destination pattern should look like this:
destination-pattern .T or destination-pattern ....T
Also direct-inward-dial command is not intended for outgoing dial-peers , so you can remove it from POTS dial-peer which are for outgoing.
Thanks,
Amit
06-17-2015 12:21 AM
Thanks a lot for your thoughts Amit
I will amend the dial-peer destination pattern and test once more.
But the 1000 and 1001 voip have been configured and session targets been configured for the E1 0/0/0 on Router A; could it potentially cause issues with the other one as well?
06-17-2015 12:27 AM
Hello Kaushik,
Ideally it should not have an impact, as these are outgoing dial-peers , which should be pointing towards Router B, to send the calls. So we just want to force these dial-peer not to send the call with just 1 digit, so appending T in destination pattern, will cause it to wait unless interdigit timeout is expired.
\ Amit
06-17-2015 12:31 AM
Thanks I will amend the dial-peers and test.
just for a bit of more information the dial-peer 1000 and 1001 does not point to the Router B but points to a CUCM.
Essentially the phones through the E1 0/0/0 and E1 0/0/1 are separate voice lines to act as a backup if one or the other is not working.
06-18-2015 04:32 AM
Thanks changing dial peers 1000 and 1001 to .T fixed it!! thanks a lot for your help,
06-15-2015 05:37 AM
Hello Kaushik,
It seems that router is sending the call to other end , say CUCM even before complete digits are received. It would be great if you can share complete configuration , so that we can have a look in to dial-peer as well.
There could be two remedies , which can be used here:
1 - Configure Mitel PABX not to use Overlap sending, so that it can send all digits in Setup Message.
2. Incoming dial-peer matching with this call, should not have "incoming called-number . " command, as that will force router to send the call to another side, say CUCM, as soon as first digit is received. So call will be failed in that way.
Please do collect below said debugs for more details analysis:
debug isdn q931
debug voip ccapi inout
Thanks,
Amit Kumar
06-15-2015 05:54 AM
Thanks Amit Kumar for your reply.
!
dial-peer voice 4000 pots
tone ringback alert-no-PI
destination-pattern 1...
direct-inward-dial
port 0/0/1:15
forward-digits all
!
Pots config and debug below
*Jun 15 11:44:04.155: %SYS-5-CONFIG_I: Configured from console by vty0 (172.20.45.51)
*Jun 15 11:44:22.099: ISDN Se0/0/1:15 Q931: RX <- SETUP pd = 8 callref = 0x0047
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Facility i = 0x91AA068001008201008B0100A11302017D06042B0C0900300880064578746E2031
Calling Party Number i = 0x4980, '1201'
Plan:Private, Type:Subscriber(local)
Called Party Number i = 0x80, '8'
Plan:Unknown, Type:Unknown
High Layer Compat i = 0x9181
*Jun 15 11:44:22.099: ISDN Se0/0/1:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0x8047
Channel ID i = 0xA98381
Exclusive, Channel 1
*Jun 15 11:44:22.287: ISDN Se0/0/1:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0047
Called Party Number i = 0x80, '2'
Plan:Unknown, Type:Unknown
*Jun 15 11:44:22.539: ISDN Se0/0/1:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0047
Called Party Number i = 0x80, '6'
Plan:Unknown, Type:Unknown
*Jun 15 11:44:22.791: ISDN Se0/0/1:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0047
Called Party Number i = 0x80, '8'
Plan:Unknown, Type:Unknown
*Jun 15 11:44:24.043: ISDN Se0/0/1:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8047
*Jun 15 11:44:24.047: ISDN Se0/0/1:15 Q931: TX -> ALERTING pd = 8 callref = 0x8047
Progress Ind i = 0x8188 - In-band info or appropriate now available
*Jun 15 11:44:32.731: ISDN Se0/0/1:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x0047
Cause i = 0x8090 - Normal call clearing
*Jun 15 11:44:32.731: ISDN Se0/0/1:15 Q931: TX -> RELEASE pd = 8 callref = 0x8047
*Jun 15 11:44:32.743: ISDN Se0/0/1:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0047
06-15-2015 05:59 AM
A end
!
dial-peer voice 3000 voip
destination-pattern 9T
session target ipv4:10.49.54.1
dtmf-relay h245-alphanumeric
playout-delay nominal 130
playout-delay mode fixed
fax-relay ecm disable
fax rate 9600
fax nsf 000000
ip qos dscp cs5 media
ip qos dscp cs5 signaling
no vad
!
dial-peer voice 3001 voip
destination-pattern [2-9]...
session target ipv4:10.49.54.1
dtmf-relay h245-alphanumeric
playout-delay nominal 130
playout-delay mode fixed
fax-relay ecm disable
fax rate 9600
fax nsf 000000
ip qos dscp cs5 media
ip qos dscp cs5 signaling
no vad
!
----------------
B end
----------------
!
dial-peer voice 4000 pots
tone ringback alert-no-PI
destination-pattern 1...
direct-inward-dial
port 0/0/1:15
forward-digits all
!
!
dial-peer voice 4000 pots
destination-pattern 9T
direct-inward-dial
port 0/0/0:15
forward-digits all
!
dial-peer voice 3000 voip
destination-pattern 1...
session target ipv4:172.26.70.241
dtmf-relay h245-alphanumeric
playout-delay nominal 130
playout-delay mode fixed
fax-relay ecm disable
fax rate 9600
fax nsf 000000
ip qos dscp cs5 media
ip qos dscp cs5 signaling
no vad
!
dial-peer voice 4001 pots
destination-pattern [2-9]...
direct-inward-dial
port 0/0/0:15
forward-digits all
!
06-15-2015 10:37 AM
There could be an issue with calling privileges
Rgds,
Andre
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide