Categories

CUC (6) CUCM (26) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Sunday, 20 October 2013

VCS pre-search transforms, an example

WTF are you talking about Minkmeister? Transforms,  pre-search transforms, very much like translation patterns on CUCM, in the way that they are applied before any call routing occurs.

The pre-search transform function allows you to modify the alias in an incoming search request. The transformation is applied by the VCS before any Call Policy or User Policy is applied, and before any searches take place.
It applies to all incoming search requests received from locally registered endpoints, neighbor, traversal client and traversal server zones, and endpoints on the public internet. It does not apply to requests received from peers (which are configured identically and therefore will have already applied the same transform). Each pre-search transform defines a string against which an alias is compared, and the changes to make to the alias if it matches that string. After the alias has been transformed, it remains changed and all further call processing is applied to the new alias.
Pre-search transforms are not applied to GRQ or RRQ messages <more needed> received from endpoints registering with the VCS; endpoints will be registered with the aliases as presented in these messages. All peers in a cluster should be configured identically, including any pre-search transforms. A VCS in a cluster treats search requests from any of its peers as having come from its own Local Zone, and does not re-apply any pre-search transforms on receipt of the request.

Every incoming alias is compared with each transform in order of priority, starting with that closest to 1. If and when a match is made, the transform is applied to the alias and no further pre-search checks and transformations of the new alias will take place. The new alias is then used for the remainder of the call routing process.


Why do I need pre-search transformation?  Well same reason as why you would use Translation patterns on CUCM.  If you look at Figure 3, you can see that the SIP trunks are configured, using IP addresses not domain names, yet your end points are most likely registered on the VCS under 12345@dogtel.com.au or what ever domain you are using. So some mechanism will need to do the conversion into a domain name, from the CUCM used URI 12345@192.168.1.1 (as an example). Pre-search transformation do just that.

Figure 2 show an example of two search rules (CUCM speak for those is route pattern). One rule that routes all 5 digit call to CUCM and one that routes all 0 prefixed calls (PSTN call most likely in Australia) to CUCM as well.

Fig.2. Search rules configuration
These rules are used for calls that are VCS egress. Pre-search transformations are VCS egress.



Let's assume my MCU is registered on the VCS, as  12345@dogtel.com.au. 
Again, my CUCM will not use a domain name in the SIP URI (Fig.3)


Fig.3. CUCM SIP Trunk pointing to 2 VCS's

As you can see I have set the destination addresses as a redundant VCS pair to point to 192.168.1.1 and 192.168.2.1. This means, that if I make a call to my MCU from a CUCM registered phone, the SIP invite will be sent to 12345@192.168.1.1  or 12345@192.168.2.1 and it will land on the VCS, where it will fail, because it has no 12345@10.2.1.41 end point registered. The VCS does, however, have an endpoint 12345@dogtel.com.au registered, which is our MCU. To cut a long story short, something will need to be put in place to transform the alias from an IP address into a domain name, please note that it is also possible to transform domain names. The example below (Fig.4), depicts this  transform that has been configured on the VCS 


Now my pattern string is (123..|124..)@192.168.1.1(:.*) where the pattern should be exactly what has been send by CUCM in this case, so  (123..|124..)@192.168.1.1(:.*)  and (123..|124..)@192.168.1.1(:.*).

This transform matches all 123.. OR 124.. patterns  and translates into 123..@dogtel.com.au or 124..@dogtel.com.au.


pre-search transform rule VCS
Fig.4 Pre-search transformation configuration on a VCS


Regular expressions

Regular expressions can be used in conjunction with a number of VCS features such as alias transformations, zone transformations, CPL policy and ENUM. The VCS uses POSIX format regular expression syntax. The table below provides a list of commonly used special characters in regular expression syntax. This is only a subset of the full range of expressions available. For a detailed description of regular expression syntax see the publication Regular Expression Pocket Reference.
Character Description Example
. Matches any single character.
\d Matches any decimal digit, i.e. 0-9.
* Matches 0 or more repetitions of the previous character or expression. .* matches against any sequence of characters
+ Matches 1 or more repetitions of the previous character or expression.
? Matches 0 or 1 repetitions of the previous character or expression. 9?123 matches against 9123 and 123
{n} Matches n repetitions of the previous character or expression \d{3} matches 3 digits
{n,m} Matches n to m repetitions of the previous character or expression \d{3,5} matches 3, 4 or 5 digits
[...] Matches a set of specified characters. Each character in the set can be specified individually, or a range can be specified by giving the first character in the range followed by the - character and then the last character in the range.
You cannot use special characters within the [] - they will be taken literally.
[a-z] matches any alphabetical character
[0-9#*] matches against any single E.164 character - the E.164 character set is made up of the digits 0-9 plus the hash key (#) and the asterisk key (*)
[^...] Matches anything except the set of specified characters. Each character in the set can be specified individually, or a range can be specified by giving the first character in the range followed by the - character and then the last character in the range.
You cannot use special characters within the [] - they will be taken literally.
[^a-z] matches any non-alphabetical character
[^0-9#*] matches anything other than the digits 0-9, the hash key (#) and the asterisk key (*)
(...) Groups a set of matching characters together. Groups can then be referenced in order using the characters \1, \2, etc. as part of a replace string. A regular expression can be constructed to transform a URI containing a user’s full name to a URI based on their initials. The regular expression (.).*_(.).*(@example.com) would match against the user john_smith@example.com and with a replace string of \1\2\3 would transform it to js@example.com
| Matches against one expression or an alternate expression. .*@example.(net|com) matches against any URI for the domain example.com or the domain example.net
\ Escapes a regular expression special character.
^ Signifies the start of a line.
When used immediately after an opening brace, negates the character set inside the brace.
[^abc] matches any single character that is NOT one of a, b or c
$ Signifies the end of a line. ^\d\d\d$ matches any string that is exactly 3 digits long
(?!...) Negative lookahead. Defines a subexpression that must not be present. (?!.*@example.com$).* matches any string that does not end with @example.com
(?!alice).* matches any string that does not start with alice
(?<!...) Negative lookbehind. Defines a subexpression that must not be present. .*(?<!net) matches any string that does not end with net
Note that regex comparisons are not case sensitive.



No comments:

Post a Comment