cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2089
Views
15
Helpful
12
Replies

Voice Translation-Rule X

Mark Verwey
Level 1
Level 1

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

 

1 Accepted Solution

Accepted Solutions

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



Response Signature


View solution in original post

12 Replies 12

Jaime Valencia
Cisco Employee
Cisco Employee

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.

Chris Deren
Hall of Fame
Hall of Fame

Post your full config so we can see if you applied it in proper spot, ideally on the voice-port.

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
!

Hi,

Can you please share the output of debug isdn q931 and debug voice ccapi inout...

Thanks

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:
 

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'.... 

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



Response Signature


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.

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



Response Signature


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



Response Signature


Anthony W.
Level 1
Level 1

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.