[cisco-voip] Dealing with + in destination patterns

[Michael Thompson]

Awesome, glad it worked.

 

  _____  

From: Ryan West [mailto:rwest at zyedge.com] 
Sent: Sunday, September 21, 2008 4:35 PM
To: Michael Thompson; 'Wes Sisk'
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] Dealing with + in destination patterns

 

Michael,

 

I went with a combination of your second example below and the reference
that Terry gave early.  We use something similar for expanding out long
distance calls.  The end result was a mix to present 11 digits as the called
number and 10 digits as the calling.

 

voice translation-rule 5

 rule 1 /^\+1\(.*\)/ /\1/

!

voice translation-rule 6

 rule 1 /\+/ //

!

voice translation-profile e164-in

 translate calling 5

 translate called 6

!

test voice translation-rule 6 +12145551212

Matched with rule 1

Original number: +12145551212   Translated number: 12145551212

 

test voice translation-rule 5 +12145551212

Matched with rule 1

Original number: +12145551212   Translated number: 2145551212

 

Thanks again for the responses.

 

-ryan

 

From: Michael Thompson [mailto:mthompson729 at gmail.com] 
Sent: Sunday, September 21, 2008 1:26 PM
To: 'Wes Sisk'; Ryan West
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] Dealing with + in destination patterns

 

Shouldn't you be able to use something akin to 'rule 1 /^.*/ /.../' 

 

Another way I'm thinking may work is using the \ to ignore the special
meaning of the +, something like 'rule 1 /\+/ //' could match the + char
only and replace it with a null, leaving the 10 digit number.  See
translation character rule below (assuming it comes through clearly).

 

Granted a little simplistic, but the first captures any number of digits and
then the output is 10 digits.  Only thing I don't know without research is
whether the + is a 'captured' character.

 

Excerpt from:
http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_exampl
e09186a00803f818a.shtml

 

The voice translation rules use characters similar to Regular Expression
Syntax (regexp). But, there are some minor differences and limitations. Most
of the limitations are of no real concern since only digit manipulation is
performed. 


Voice Translation Rule Character

Description


^ 

Match the expression at the start of a line. 


$ 

Match the expression at the end of the line. 


/ 

Delimiter that marks the start and end of both the matching and replacement
strings. 


\ 

Escape the special meaning of the next character. 


- 

Indicates a range when not in the first/last position. Used with the'[' and
']'.


[list] 

Match a single character in a list. 


[^list] 

Do not match a single character specified in the list. 


. 

Match any single character. 


* 

Repeat the previous regexp zero or more times. 


+ 

Repeat the previous regular expression one or more times. 


? 

Repeat the previous regular expression zero or one time (use CTRL-V in order
to enter in IOS). 


() 

Groups regular expressions. 

 

  _____  

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Wes Sisk
Sent: Friday, September 19, 2008 5:48 PM
To: Ryan West
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Dealing with + in destination patterns

 

maybe use 'forward-digits' command to use only the last 10 digits?

On 9/19/2008 5:31 PM, Ryan West wrote: 

What's the best way to deal with a full e.164 number coming from a SIP
provider.  I am receiving +1 with the remaining 10 digits following.  The
only dial-peer that seems to match is the catchall .T.  I have tried
creating a translation-profile to rewrite the number, but the + symbol is
not permitted.

 

Thanks guys,

 

-ryan

 
 
 
 
 





  _____  



 
 
 
 
 
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20080921/9f2cbf1f/attachment-0001.html>