New in CCIE-V v.3 part 2- "Called Party Transformation Pattern"

One new enhancement designed to make implementing a dial plan more efficient in UCM 7.x is the Called Number Transformation pattern. Before we can fully understand how this works, we need to take a brief look at the existing method for transforming the Called Number.

Typically some type of transformation needs to take place between the caller dialing digits and the call being routed to the terminating gateway. More often than not, this simply involves stripping the access code such as “9” used for reaching an external number. This transformation of the called number could be done in one of four places:

1. The Route Pattern.
2. The Route List
3. The Terminating Gateway
4. A Translation Pattern

The type of transformation actually used is usually one of three types available to us- Discard Digit Instruction (DDI), Called Party Mask or Prefix. A basic example is a Route Pattern used to route local calls. The pattern is 9.[2-9]XXXXXX and the DDI used is “PREDOT” in order to strip all the digits that occur before the dot (in other words the “9”). This DDI could be invoked at the Route Pattern or Route List level with the latter Route List overriding the Route Pattern transformations.

Having the Called Number format determined by the originating Device Pool is a new feature in UCM 7.x (versus 4.x). This involves a new field called the “Called Party Transformation CSS” in the Device Pool to be used for transformations instead of using one of the four options listed above. Why is this useful? The answer to this question can best be seen with an example.

Take the following scenario- there are two sites (Boston and San Jose). Callers at each site must be able to dial local numbers by entering a “9” followed by 7 more digits. The Telco in Boston must receive the 3 digit area code plus the remaining 7 digts in the Called Number whereas the San Jose Telco must receive 7 digits in the Called Number. In other words, we remove the “9” at both sites but we must also prefix the Boston area code before sending local calls at the Boston site. This must be achieved using single Route Pattern for efficiency.

The fact that we are using a single Route Pattern means that we must be required to use the Local Route Group feature that has been discussed in a previous blog on this site. We add a single Route Pattern pointing to a Route List that contains the “Standard Local Route Group”. The contents of this virtual Route Group is derived from the originating Device Pool settings and is the Boston gateway for the Boston site and the San Jose gateway for the San Jose site.

We cannot satisfy the Called Number transformation requirements by doing anything on the Route Pattern or Route List since this would take effect when a phone at either site makes a local call. We need to send 10 digits to the Boston Telco and 7 digits to the San Jose Telco.

We now create two partitions- PT-SJC-7digit and PT-BOS-10digit and two Calling Search spaces called CSS-SJC-7digit and CSS-BOS-10digit each containing the appropriate partition.

Two new Called Party Transformation Patterns need to be created as detailed below:

-    9.[2-9]XXXXXXX / PT-SJC-7digit, DDI=PREDOT
-    9.[2-9]XXXXXXX / PT-BOS-10digit, DDI=PREDOT + Prefix 617

The Called Transformation Pattern can be accessed from the Call Routing menu from the Administration pages. (Note- you will notice that the same type of thing can be done for the Calling Number using Calling Party Transformations Pattern).

The SJC Device Pool would need to have the Called Party Transformation CSS set to CSS-SJC-7digit and the BOS Device Pool would need to have the Called Party Transformation CSS set to CSS-BOS-10digit.

Both the BOS and SJC gateways would need to have the “Use Device Pool Called Party Transformation CSS” checkbox marked in order for the originating Device Pool to determine the Called Number format.

It must be noted that any Called Number Transformation that is performed on the Route Pattern or Route List would be overridden by the Device Pool Called Party Transformation. Another important point to remember is that the Called Number Transformations and Calling Number Transformation do not replace Translation Patterns which still exist on UCM 7.x. Translation Patterns behave slightly differently in that they effect call routing. Once a Translation Pattern has been processed, the UCM re-attempts digit analysis except the translated number and not the original called number is used for this second attempt at digit analysis. Compare this with Called/Calling Transofrmations which do not affect call routing but only serve the purpose of manipulating the Called/Calling Number before being sent to the pre-defined gateway or trunk.

Print Friendly

Tags: Called Party Transformation Pattern, Calling Party Transformation Pattern, Device pool css