Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Voice Translation issue

Got a strange issue here.
Calls going through a CUBE router with a translation rule that strips the 9 off of the number
Here is the translation rule
voice translation-rule 15
 rule 1 /^9\(.*\)/ /\1/
 
voice translation-profile xlate-Outgoing-Centurylink
 translate called 15
 
Here is the dial-peer that it goes through
 
dial-peer voice 1203 voip
 description Outbound Calls to CenturyLink-SIP
 translation-profile outgoing xlate-Outgoing-Centurylink
 call-block translation-profile incoming callednumber_block3
 destination-pattern 91[2-9]..[2-9]......
 session protocol sipv2
 session target sip-server
 dtmf-relay rtp-nte digit-drop
 codec g711ulaw
 no vad
 
If any area code besides 916 is dialed it works.  The 9 is stripped off and all is good.  But if 916 is dialed the 9 is not stripped off and the number with the 9 is sent along to the sip carrier.
I have confirmed that the same dial-peer is used.  However, debug voice translation does not show that the number is getting translated.
 
Any ideas?
 
Thanks
Von
1 ACCEPTED SOLUTION

Accepted Solutions
VIP Super Bronze

My bad I wasn't looking at

My bad I wasn't looking at the right call..

This looks like an issue with the inbound dial-peer that is  matched for this call. The dial-peer that is mathed is 919191..which has a service ringtone configured..

The working call matched inbound dial-peer 10000

06393: *Nov 11 11:34:33.586 PST: //-1/361C13800001/CCAPI/cc_api_display_ie_subfields:
   cc_api_call_setup_ind_common:
   cisco-username=9166313777
   ----- ccCallInfo IE subfields -----
   cisco-ani=9166313777
   cisco-anitype=0
   cisco-aniplan=0
   cisco-anipi=0
   cisco-anisi=1
   dest=919167532125
   cisco-desttype=0
   cisco-destplan=0
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=0
   cisco-rdnplan=0
   cisco-rdnpi=-1
   cisco-rdnsi=-1
   cisco-redirectreason=-1   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

006394: *Nov 11 11:34:33.586 PST: //-1/361C13800001/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x2444EF08, Call Info(
   Calling Number=9166313777,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
   Called Number=919167532125(TON=Unknown, NPI=Unknown),
   Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=91919191
  
  
  dial-peer voice 91919191 voip
 description CVP SIP ringtone dial-peer
 service ringtone
 incoming called-number 9191T
 voice-class sip rel1xx disable
 dtmf-relay rtp-nte h245-signal h245-alphanumeric
 codec g711ulaw
 no vad

NB: this dial-peer is configured for h323 and your call comes in as SIP..So that's why CUBE is not sending it to the outbound leg

 

I observed that you do not have any inbound dial-peer configured. This is best practice. You should have inbound dial-peer configured to macth the incoming leg..

eg

dial-per xxx voip

incoming called number .

session protocol sipv2

voice class codec xx

dtmf-relay rtp-nte

no vad

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
5 REPLIES
VIP Super Bronze

Von,Very strange indeed. Can

Von,

Very strange indeed. Can you send us a debug VoIP ccapi input and a sh run

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Here it is.The called number

Here it is.

The called number is 919167532125.

The call is not disconnected.  It just rings.  But in the SIP debug you can see the invite coming into the CUBE from CUCM but not going out.  When the call us hung up we get a normal disconnect. 

VIP Super Bronze

Von,Your translation rule is

Von,

Your translation rule is definitely working. You can see the final called number has the 9 stripped. Your issue lies else where..Please send me the debug ccsip mesages

006434: *Nov 11 11:34:35.882 PST: //63607/374D40800001/CCAPI/cc_api_display_ie_subfields:
   ccCallSetupRequest:
   cisco-username=5104040152
   ----- ccCallInfo IE subfields -----
   cisco-ani=5104040152
   cisco-anitype=0
   cisco-aniplan=0
   cisco-anipi=0
   cisco-anisi=1
   dest=16504852895
   cisco-desttype=0
   cisco-destplan=0
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=0
   cisco-rdnplan=0
   cisco-rdnpi=-1
   cisco-rdnsi=-1
   cisco-redirectreason=-1   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

006435: *Nov 11 11:34:35.882 PST: //63607/374D40800001/CCAPI/ccIFCallSetupRequestPrivate:
   Interface=0x2444EF08, Interface Type=3, Destination=, Mode=0x0,
   Call Params(Calling Number=5104040152,(Calling Name=Open)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
   Called Number=16504852895(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
   Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=1203, Call Count On=FALSE,
 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

I agree that it is working

I agree that it is working for most calls.  But for some reason it is not working for area code 916 if you see below. SIP mess debug attached.

006393: *Nov 11 11:34:33.586 PST: //-1/361C13800001/CCAPI/cc_api_display_ie_subfields:
   cc_api_call_setup_ind_common:
   cisco-username=9166313777
   ----- ccCallInfo IE subfields -----
   cisco-ani=9166313777
   cisco-anitype=0
   cisco-aniplan=0
   cisco-anipi=0
   cisco-anisi=1
   dest=919167532125
   cisco-desttype=0
   cisco-destplan=0
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=0
   cisco-rdnplan=0
   cisco-rdnpi=-1
   cisco-rdnsi=-1
   cisco-redirectreason=-1   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

006394: *Nov 11 11:34:33.586 PST: //-1/361C13800001/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x2444EF08, Call Info(
   Calling Number=9166313777,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
   Called Number=919167532125(TON=Unknown, NPI=Unknown),
   Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=91919191, Progress Indication=NULL(0), Calling IE Present=TRUE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=63604
006395: *Nov 11 11:34:33.586 PST: //-1/361C13800001/CCAPI/ccCheckClipClir:
   In: Calling Number=9166313777(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
006396: *Nov 11 11:34:33.586 PST: //-1/361C13800001/CCAPI/ccCheckClipClir:
   Out: Calling Number=9166313777(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)

VIP Super Bronze

My bad I wasn't looking at

My bad I wasn't looking at the right call..

This looks like an issue with the inbound dial-peer that is  matched for this call. The dial-peer that is mathed is 919191..which has a service ringtone configured..

The working call matched inbound dial-peer 10000

06393: *Nov 11 11:34:33.586 PST: //-1/361C13800001/CCAPI/cc_api_display_ie_subfields:
   cc_api_call_setup_ind_common:
   cisco-username=9166313777
   ----- ccCallInfo IE subfields -----
   cisco-ani=9166313777
   cisco-anitype=0
   cisco-aniplan=0
   cisco-anipi=0
   cisco-anisi=1
   dest=919167532125
   cisco-desttype=0
   cisco-destplan=0
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=0
   cisco-rdnplan=0
   cisco-rdnpi=-1
   cisco-rdnsi=-1
   cisco-redirectreason=-1   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

006394: *Nov 11 11:34:33.586 PST: //-1/361C13800001/CCAPI/cc_api_call_setup_ind_common:
   Interface=0x2444EF08, Call Info(
   Calling Number=9166313777,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
   Called Number=919167532125(TON=Unknown, NPI=Unknown),
   Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
   Incoming Dial-peer=91919191
  
  
  dial-peer voice 91919191 voip
 description CVP SIP ringtone dial-peer
 service ringtone
 incoming called-number 9191T
 voice-class sip rel1xx disable
 dtmf-relay rtp-nte h245-signal h245-alphanumeric
 codec g711ulaw
 no vad

NB: this dial-peer is configured for h323 and your call comes in as SIP..So that's why CUBE is not sending it to the outbound leg

 

I observed that you do not have any inbound dial-peer configured. This is best practice. You should have inbound dial-peer configured to macth the incoming leg..

eg

dial-per xxx voip

incoming called number .

session protocol sipv2

voice class codec xx

dtmf-relay rtp-nte

no vad

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
143
Views
0
Helpful
5
Replies