ā02-23-2023 12:30 AM - edited ā02-23-2023 12:32 AM
Hi Team,
i need help on voice translation pattern
Webex Calling >>>LGW(CUBE)>>>ITSP
on Webex calling i did not use dial-plan but instead i use predefined number for external calls(outgoing)
However "Webex Calling" doesn't forward 00 or 0 in front, and the ITSP only recognized 0 for NDD, 00 for IDD.
you help is much appreciated.
Solved! Go to Solution.
ā03-06-2023 07:02 AM
Either remove the ISDN TON "type international international" - which is only relevant when using ISDN - or at least change it to "type any international". The rule isn't matching because of this.
ā03-06-2023 07:16 PM
Hi Mate,
based from the debugs i was able to see that the called number is being analyzed without the ā+ā and the translation rules you provide does not match, & after adding the following configuration below, the issue has been resolved.
rule 5 /\([1-9]\)/ /00\1/
although i did not removed the rule you suggest.
thanks for the solution that you have provided
ā02-23-2023 02:21 AM
Webex Calling uses ITU-T standard +E.164 formatting. You will need to use a translation rule & profile on CUBE to convert to National Significant Numbering if that is what your provider requires.
ā02-27-2023 01:33 AM
Hi Jonathan,
i was able to address the ndd prefix since webex calling is forwarding "called number" with country code digit, but however still failing to prepend for international calls followed the link you provided, below is the configuration.
voice translation-rule 100
rule 1 /^632/ //
rule 2 /^639/ /09/
rule 3 /^63/ /0/
rule 4 /.+[1-9]/ /00&/ type international international
!
voice translation-profile OUTGOING_ITSP
translate called 100
!
dial-peer voice 101 voip
description outgoing_calls_from_lgw_to_SIP:outgoing-LEG2
translation-profile outgoing OUTGOING_ITSP
destination-pattern .T
session protocol sipv2
destination uri ITSP1
voice-class codec 1
no voice-class sip conn-reuse
voice-class sip tenant 11
dtmf-relay rtp-nte
no vad
-----------------------------------------------------
***below is debug logs***
_________Leg1__________
*Feb 23 13:03:08.921: //-1/41149F7D9FA5/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=+(Removed for security reasons)
----- ccCallInfo IE subfields -----
cisco-ani=+(Removed for security reasons)
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=+18882804331
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFFFFFFFFFF
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
!
Interface=0x7FD0AFF348E0, Call Info(
Calling Number=+(Removed for security reasons),(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=+18882804331(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=100, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=78514
!
_________Leg2__________
ccCallSetupRequest:
cisco-username=+(Removed for security reasons)
----- ccCallInfo IE subfields -----
cisco-ani=(Removed for security reasons)
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=18882804331
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFFFFFFFFFF
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
Interface=0x7FD0AFF348E0, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=(Removed for security reasons),(Calling Name=Christian Bryan Delos Santos)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=18882804331(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=101, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
ā02-27-2023 07:11 AM
Your voice translation-rule isn't accounting for the leading plus character. Assuming the DNIS is +18882804331 in the example debug you supplied, rule 4 should be something along the lines of /^\+\([1-9].+\)$/ /00\1/
ā03-05-2023 07:31 PM
Hi Mate,
tried your suggestion but fail below configuration was added
rul 3 /^\+\([1-9].+\)$/ /00\1/ type internationa international
same debug output from previous
ā03-06-2023 07:02 AM
Either remove the ISDN TON "type international international" - which is only relevant when using ISDN - or at least change it to "type any international". The rule isn't matching because of this.
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