09-30-2015 01:37 PM - edited 03-17-2019 04:26 AM
The Teleco provider is sending me 5 digits on the 0/0/1 and 0/1/0 interfaces. I have other isdn circuits that are sending only 4 digits, I have created a voice translation-rule as follows:
rule 1 /^.*\(....\)/ /\1/
This rule strips the first digit off the incoming number and is supposed to forward to the CUCM only last 4 digits of an inbound call. When I test this rule it works "test voice translation-rule 1 27000"; output is 7000
However when I attempt to call one of the DID's that are supposed to be on this ISDN/PRI circuit I get a failure, but when I look at the history of the call coming into my gateway router, I see the 27XXX coming in.
What am I missing in this configuration. Do I need to add this to any of the dial-peers?
Here is the voice translation rule as it sits in the gateway now:
voice translation-rule 1
rule 1 /^.*\(....\)/ /\1/
!
!
voice translation-profile SitePrefix
translate called 1
Solved! Go to Solution.
10-02-2015 01:03 AM
I would set the voice translation rule on the voice ports instead as you have it now on the DPs.
voice-port 0/0/1:23
translation-profile incoming SitePrefix
voice-port 0/1/0:23
translation-profile incoming SitePrefix
dial-peer voice 2 pots
no translation-profile incoming SitePrefix
!
dial-peer voice 3 pots
no translation-profile incoming SitePrefix
!
dial-peer voice 202 voip
no translation-profile outgoing SitePrefix
!
dial-peer voice 201 voip
no translation-profile outgoing SitePrefix
!
dial-peer voice 203 voip
no translation-profile outgoing SitePrefix
Sincerely
Roger
09-30-2015 01:46 PM
You need to apply it to the DPs, there's plenty of documentation on the subject on cisco.com
10-01-2015 12:43 PM
I understand how to setup the outbound side of the DP however I'm having issues with inbound DID numbers. This range is coming in as 5 digits, I am using the voice translation rule to remove the first digit as our CUCM is setup for inbound 4 digits from the carrier, someone set this up for 5 (not sure why). I can see the number hits the router (sh isdn hist) after I get the error msg from the carrier. This is the problem I'm having, I can dial out the circuits just fine, just cant dial in even though I can see it has landed at the circuit.
09-30-2015 03:01 PM
Post your full config so we can see if you applied it in proper spot, ideally on the voice-port.
10-01-2015 01:18 PM
Here is the part that I think you needed so you can see whats going on. The DID number comes in on controller t1 0/0/1 and 0/1/0 only.
!
voice translation-rule 1
rule 1 /^.*\(....\)/ /\1/
!
!
voice translation-profile SitePrefix
translate called 1
!
dial-peer voice 2 pots
translation-profile incoming SitePrefix
incoming called-number .
direct-inward-dial
port 0/0/1:23
!
dial-peer voice 3 pots
translation-profile incoming SitePrefix
incoming called-number .
direct-inward-dial
port 0/1/0:23
!
!
!
dial-peer voice 202 voip
translation-profile outgoing SitePrefix
destination-pattern [5-8][0-9][0-9][0-9]
session target ipv4:10.211.110.10
voice-class codec 1
dtmf-relay h245-alphanumeric
fax protocol t38 nse force version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
no vad
!
dial-peer voice 201 voip
translation-profile outgoing SitePrefix
preference 1
destination-pattern [5-8][0-9][0-9][0-9]
session target ipv4:10.211.110.11
voice-class codec 1
dtmf-relay h245-alphanumeric
fax protocol t38 nse force version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
no vad
!
dial-peer voice 203 voip
translation-profile outgoing SitePrefix
destination-pattern [5-8][0-9][0-9][0-9]
session target ipv4:10.211.108.33
voice-class codec 1
dtmf-relay h245-alphanumeric
fax protocol t38 nse force version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
no vad
!
10-01-2015 09:12 PM
Hi,
Can you please share the output of debug isdn q931 and debug voice ccapi inout...
Thanks
10-02-2015 05:48 AM
Here is the debug output for ccapi inout and isdn q931
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.10.02 08:46:26 =~=~=~=~=~=~=~=~=~=~=~=
Oct 2 12:46:32.164: ISDN Se0/0/1:23 Q931: RX <- SETUP pd = 8 callref = 0x0AE6
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x2183, '9047835000'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '27099'
Plan:Unknown, Type:Unknown
Oct 2 12:46:32.168: ISDN Se0/0/1:23 Q931: Received SETUP callref = 0x8AE6 callID = 0x0033 switch = primary-ni interface = User
Oct 2 12:46:32.168: //-1/7139FA65802D/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=
----- ccCallInfo IE subfields -----
cisco-ani=9047835000
cisco-anitype=2
cisco-aniplan=1
cisco-anipi=0
cisco-anisi=3
dest=27099
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
Oct 2 12:46:32.168: //-1/7139FA65802D/CCAPI/cc_api_call_setup_ind_common:
Interface=0x23898B44, Call Info(
Calling Number=9047835000,(Calling Name=)(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed),
Called Number=27099(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
Incoming Dial-peer=1, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=-1
Oct 2 12:46:32.168: //-1/7139FA65802D/CCAPI/ccCheckClipClir:
In: Calling Number=9047835000(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed)
Oct 2 12:46:32.168: //-1/7139FA65802D/CCAPI/ccCheckClipClir:
Out: Calling Number=9047835000(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed)
Oct 2 12:46:32.168: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Oct 2 12:46:32.168: :cc_get_feature_vsa malloc success
Oct 2 12:46:32.168: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Oct 2 12:46:32.168: cc_get_feature_vsa count is 3
Oct 2 12:46:32.168: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Oct 2 12:46:32.168: :FEATURE_VSA attributes are: feature_name:0,feature_time:613814072,feature_id:326
Oct 2 12:46:32.168: //326/7139FA65802D/CCAPI/cc_api_call_setup_ind_common:
Set Up Event Sent;
Call Info(Calling Number=9047835000(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed),
Called Number=27099(TON=Unknown, NPI=Unknown))
Oct 2 12:46:32.168: //326/7139FA65802D/CCAPI/cc_process_call_setup_ind:
Event=0x234474D0
Oct 2 12:46:32.168: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 27099
Oct 2 12:46:32.168: //326/7139FA65802D/CCAPI/ccCallSetContext:
Context=0x24975CE8
Oct 2 12:46:32.168: //326/7139FA65802D/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 326 with tag 1 to app "_ManagedAppProcess_Default"
Oct 2 12:46:32.168: //326/7139FA65802D/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)
Oct 2 12:46:32.172: //326/7139FA65802D/CCAPI/ccCallDisconnect:
Cause Value=1, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Oct 2 12:46:32.172: //326/7139FA65802D/CCAPI/ccCallDisconnect:
Cause Value=1, Call Entry(Responsed=TRUE, Cause Value=1)
Oct 2 12:46:32.172: //326/7139FA65802D/CCAPI/cc_api_get_transfer_info:
Transfer Number=NULL
Oct 2 12:46:32.172: ISDN Se0/0/1:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x8AE6
Channel ID i = 0xA98397
Exclusive, Channel 23
Oct 2 12:46:32.172: ISDN Se0/0/1:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x8AE6
Cause i = 0x8081 - Unallocated/unassigned number
Oct 2 12:46:32.260: ISDN Se0/0/1:23 Q931: RX <- RELEASE pd = 8 callref = 0x0AE6
Oct 2 12:46:32.264: ISDN Se0/0/1:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8AE6
Oct 2 12:46:32.264: //326/7139FA65802D/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x23898B44, Tag=0x0, Call Id=326,
Call Entry(Disconnect Cause=1, Voice Class Cause Code=0, Retry Count=0)
Oct 2 12:46:32.264: //326/7139FA65802D/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
Oct 2 12:46:32.264: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
Oct 2 12:46:32.264: :cc_free_feature_vsa freeing 24960F30
Oct 2 12:46:32.264: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
10-02-2015 05:58 AM
Are you sure you shared the complete 'show run' before?
As per debugs, dial-peer 1 (inbound) is being selected whereas in the configuration you shared before, there was no dial-peer associated with tag 1.
Seems you might have dial-peer 1 in your configuration but no translation profile associated with it hence call is being rejected with cause '1'.
Can you again check and share the full 'show run'....
10-02-2015 06:54 AM
This is why I recommended to put the voice translation on the voice ports. This would be the first thing that is hit for inbound calls, second would be trunk groups if used and then only on third place it's the inbound dial peer. Vivek is absolutely correct that your incoming DP is number 1, that's why your rules on DP 2 and 3 isn't used. In your shared config you have your rule set that strips of the first digit tied in the incoming direction on DP 2-3 and then in the outbound direction on DP 201-203. As abwurtele also already pointed out these outbound DPs will not be hit since you have a destination pattern that matches on 4 digits, not 5.
Please try to have the translation tied to the voice ports as I suggested.
Sincerely
Roger
10-02-2015 09:51 AM
The reason I was putting it on DP2 & 3 was because that is the circuits the call would be inbound on. However I did as you recommended and moved it to the voice translation and everything is working as it should now. Thanks for your assistance.
10-03-2015 12:19 AM
It's a common misconception on how inbound dial peer match works. This article explains it very well.http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/14074-in-dial-peer-match.html
Port is only used if none off the three higher preference matches aren't hit. In your case incoming called number would be used. You don't need to have more than one incoming pots dial peer if it shares all config elements amongst all of them, as is the case for you.
Anyway I'm glad that you got it to work.
Sincerely
Roger
10-02-2015 01:03 AM
I would set the voice translation rule on the voice ports instead as you have it now on the DPs.
voice-port 0/0/1:23
translation-profile incoming SitePrefix
voice-port 0/1/0:23
translation-profile incoming SitePrefix
dial-peer voice 2 pots
no translation-profile incoming SitePrefix
!
dial-peer voice 3 pots
no translation-profile incoming SitePrefix
!
dial-peer voice 202 voip
no translation-profile outgoing SitePrefix
!
dial-peer voice 201 voip
no translation-profile outgoing SitePrefix
!
dial-peer voice 203 voip
no translation-profile outgoing SitePrefix
Sincerely
Roger
10-01-2015 02:05 PM
Mark,
If I am understanding correctly, you have a 4 digit dial plan and you want to strip off the 1st digit of from the telco. 27000 to 7000. However your dial-peers are only matching based on 4 digits
dial-peer voice 202 voip
translation-profile outgoing SitePrefix
destination-pattern [5-8][0-9][0-9][0-9]
session target ipv4:10.211.110.10
voice-class codec 1
dtmf-relay h245-alphanumeric
fax protocol t38 nse force version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
no vad
There is nothing wrong with your translation pattern. You need your dial-peer to match based on the 5 digit number if your translation pattern is going outgoing. But make sure you match the first digit correctly. If your inbound number starts with 2, you will need to add that to your destination pattern. Something like this:
destination-pattern 2....$
Let me know if you have any further questions.
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