CUCM Digit Manipulation

Before plunging into the world of CUCM digit manipulation, let us learn what an E.164 number is.

What is E.164?

E.164 is an ITU-T recommendation for international PSTN numbering. It is meant to be a way to globalize phone numbers, which means to define and standardize the format of phone numbers around the world. Historically, E.164 evolved from the ITU-T E.163 created in 1997.

E.164 format

E.164 introduces a powerful symbol: the plus sign “+”. If you take a look at the résumé of an international consultant or a Sales Manager who travels frequently, did you notice something special in the phone number section? The plus sign for example, in front of the phone number? That’s what I’m talking about. The phone number of our Sales Manager is written in the E.164 format.

For example, in the US, if you want to dial long distance number 512.555.1234, its E.164 format will be +1.512.555.1234. You won’t dial the dots of course they’re just seperators for easy reading :)

An international number in the E.164 format has the following parts:

• Exit code: the code to exit the current country
• Country code: the code related to the country of the called party
• Subscriber code: identifies the called party in his country

Cisco Call Manager E.164 support

Cisco CUCM supports E.164 in its constructs. Indeed, you can create Translation Patterns, Hunt Pilots, Translation Patterns and Transformation Patterns with the plus sign in them.

Digit Manipulation: Attendant DN

The Attendant DN feature is a digit manipulation technique for inbound calls. To understand it, let’s assume we have an analog trunk port such as FXO port on a voice gateway. When the gateway receives a call on the FXO port, the FXO port becomes in the off-hook state which closes a circuit between the central office and the gateway, like in home phone dialing. CUCM plays a dial tone (instead of the central office) and the FXO port is waiting for the user to dial more digits.
At this point comes the Attendant DN feature. The Attendant DN allows to send a set of digits to the call routing component as soon as the analog port goes off-hook. So instead of waiting for additional digits to be dialed, CUCM dials a new batch of digits (the Attendant DN value) and transmits them to the call routing component.

The Attendant feature is similar to the Prefix Digits where CUCM adds a set of digits before transmitting the call to the call routing component.

Attendant DN configuration

The Attendant DN is configurable on analog ports such as FXO and FXS ports. It is not configurable on digital trunk ports, simply because digital gateway protocols such as MGCP PRI, H323 and SIP trunks use enbloc dialing. So they get the whole dialed number in the inbound call.

Example 1: Attendant DN setting on an analog voice gateway, equipped with a Ground Start FXS port

Example2: Attendant DN setting on an analog voice gateway, equipped with a Loop Start FXO port

Digit Manipulation: Significant Digits

• Useful for inbound calls into the CUCM cluster.
• configured in the CUCM gateway page or the CUCM Trunk page.
• in most implementations, we configure it to 4 or 5. Here is the Significant Digits configuration on a H.323 gateway.

The number of digits to consider “significant” depends on:

• the DID block we purchased from Telco,
• the number of digits the Telco is sending
• the internal numbering plan of the company.

Digit Manipulation: Strip # Sign from Called Party number

In the home lab, I found no difference in dialing behaviour, by enabling or disabling this service parameter.

Digit Manipulation: Discard Digit Instructions

See the Cisco CallManager Discard Digits Instructions DDI article.

We usually have use of DDI in route patterns.

Digit Manipulation: Prefix Digits

“Prefix Digits” is a dialing transformation for both inbound and outbound calls. It allows to prepend the called number or the calling number with a set of digits before sending the call to the next stage of call routing. This next stage can be the call routing component (if the call is inbound) or a gateway/trunk (if the call is outbound).

On one hand, Prefix Digits is a feature that we can apply to the digits received on inbound calls, for the following ports and gateways:
– ports: FXS, FXO, E&M, digital access PRI and BRI
– gateways: H323, H225 trunks
On the other hand, in Calling Party Transformations and Called Party Transformations, Prefix Digits is applied for outbound calls only. That’s why we see the field named  Prefix Digits (Outbound Calls) in CUCM. Since Calling and Called Party Transformations are applied in route patterns, translation patterns and Hunt Pilots, we can say that Prefix Digits in these constructs is applied for outbound calls only.

In Prefix Digits -or Prefix DN- The choice of the digits to prepend is any combination of the following alphanumeric characters: *,#,0-9,+.

Prefix Digits Configuration in CUCM

In CUCM, we can configure the Prefix DN feature on digital gateways and on trunks.

In our lab, I’m going to set the calling party number transformation in the route list detail level with Prefix Digits:

We test:

the PSTN receives the call from HQ in a 10-digit format

Please click on the next page to read the rest of the article.

Digit Manipulation: External Phone Number Mask

We can get a result similar to that with Prefix Digits, by using External Phone Number Mask, which we configure at the calling party line and invoke it at the route pattern.

For example, the Branch1 phones must all be presented to PSTN with the DID number 4048812100. I can do this requirement by setting the External Phone Number Mask, at line 2001, to 4048812100:

Remember to set the Use Calling Party External Phone Number Mask checkbox at the route patterns. Otherwise, the External Phone Number Mask line setting will be ignored.

Here is the result of calling PSTN from Branch1:

Use External Phone Number Mask is set to On at the route pattern and to Default at the Route list detail

In this case we get the same output as in the previous paragraph.

Use External Phone Number Mask is set to On at the route pattern and to On at the Route list detail

We also get the same output as in the previous paragraph.

Use External Phone Number Mask is set to On at the route pattern and to Off at the Route list detail

CUCM does not take the External Phone Number Mask into account, because digit manipulation at the rout list detail trumps the digit manipulation at the route pattern. Branch1 phone calls the PSTN line with a Calling party number of 2001.

Use External Phone Number Mask is not set at the route pattern and to On at the Route list detail

CUCM extends the calling party number to its full format, despite the fact that the route pattern does not use the External Phone Number Mask.

Digit Manipulation: Calling Party Transform Masks

In my home lab, I emulate a branch office that bought a single DID number from Telco; there is no one-to-one mapping between internal DNs and external numbers. All DNs must be mapped to the single DID number 4048812100.

In my home lab, I use Calling Party Transform Mask at Branch1’s Route List detail level. I use it to transform any internal DN to the corporate DID number.

What if we configure the Calling Party Transform Mask at the route pattern level and not at the route list detail level?

setting the Calling Party Transform Mask on the Route Pattern of Branch1

Left the Calling Party Transform Mask blank on the Route List detail

Here is the result of a call to PSTN:

The Calling Party Transform Mask was simply ignored. It seems like the blank Calling Party Transform Mask field in the Route list detail is more powerful that its peer at the route pattern; it’s because digit manipulation at the Route list detail level trumps anything set at the route pattern.

Let’s do the other way around. We clear the setting at the route pattern and make the Calling Party Transform Mask at the Route list detail.

The call now is correctly presented.

Please click on the next page to read the rest of the article.

Digit manipulation: Caller ID DN

Here is something more powerful that route patterns or route list details, when it comes to manipulating the caller ID. We call it Caller ID DN.

Caller ID DN is set at the device level and it trumps any caller ID information that was set higher in the chain.

In the following example, I set Caller ID DN to something unmeaningful just to experience what it will look like.

And I call again:

The Calling Party number was set to the value of Caller ID DN.

Digit manipulation: Called Party Transform Masks

In my home lab, I use the Called Party Transform Mask to change the route pattern for national calls, from a 11-digit pattern to a 10-digit pattern. This transformation occurs after the Discard Digits instruction.

Here is the Called Party Transform Mask on the route pattern on the HQ gateway.

I also used the same construct on the Branch1 gateway.

Please click on the next page to read the rest of the article.

Global transformations: Calling Party Transformation Pattern

Instead of applying the Calling Party Transform Mask directly to the Route list detail level, we can make this transformation independent from any construct, by defining it as a global transformation.

We define the transformation pattern, assign it to a special kind of CSS that we name Transformation CSS. And the CSS is invoked by CUCM whenever we need to transform the Calling or Called party number.

For example, we want to create a transformation pattern that transforms the calling party number of Branch1 phones to the DID number 4048812100:

• We create the transformation pattern partition (Trans_PT) that will serve as a container for the transformation pattern. To create it, we do the same steps as to create a simple partition.

• We create the transformation CSS (Trans_CSS) that will serve as a container for the transformation partition we’ve just created. This CSS will be invoked by the device (gateway or trunk), for outbound call legs in our example.

• We create the global transformation pattern: Call Routing -> Transformation -> Transformation Pattern -> Calling Party Transformation Pattern

• Configure Branch1’s gateway: at the gateway configuration page, in the Call Routing Information – Outbound Calls, unset the checkbox Use Device Pool’s Calling Party Transformation CSS and set the Calling Party Transformation CSS to the Trans_CSS we created

• Reset the gateway and the Route list and make the outbound PSTN call from Branch1.

To make sure that it is really the global transformation that is doing the job, I added a x3002 to another phone in Branch1. Since the DN starts with 3, the global transformation pattern of 2XXX does not apply here. So in the outbound call leg, extension 3002 won’t be translated to anything.

The Calling Party number was not transformed.

Please click on the next page to read the rest of the article.

Global Transformations: Called Party Transformation Pattern

Similarly to the Calling Party transformation pattern, we can define a global transformation pattern in order to apply a Called party transformation independently from other constructs.

Here we will leverage Calling Party transformation pattern for the national PSTN call pattern, at Branch1:

• Eliminate all manipulations previously done at the route pattern level

• create a transformation pattern partition Trans_PT

• create a transformation CSS for called party Trans_CSS
• assign Trans_PT to Trans_CSS

• create a global transformation with the national PSTN call pattern. Set the Called Party Transform Mask to XXXXXXXXXX, so that only the right-most 10 digits remain.
  • At first, I thought the pattern should have been 1[2-9]XX[2-9]XXXXXX. But after running the Dialed Digit Analyzer and debug voip dialpeer at the Branch1 gateway, I found out that the Branch1 gateway was receiving the whole pattern 9.1[2-9]XX[2-9]XXXXXX from the Route list/Route group, and not 1[2-9]XX[2-9]XXXXXX as I thought.

So the transformation pattern should be 9.1[2-9]XX[2-9]XXXXXX

• for the Branch1 gateway, in the Call Routing Information – Outbound Calls, uncheck Use Device Pool Called Party Transformation CSS, and set the Called Party Transformation CSS to the Trans_CSS we created.

• reset the gateway. Make the call.

The Importance of resetting route lists, route groups and gateways

I have been told by one of my Cisco collaboration instructors that it is extremely important to reset route lists, route groups and devices, each time I modify something related to them.

For example, let’s suppose we have an inbound PSTN call to our HQ gateway in Pennsylvania. The inbound call is from a 717xxxxxxx line, located in Pennsylvania too. The telco provider is sending only 7 digits to our gateway:

Without digit manipulation, the result would look like this:

HQ gateway receives only 7 digits from a PSTN subscriber line.

We apply some digit manipulation: we tell the HQ gateway to add a prefix of 9717 to inbound subscriber calls:

Despite that we get the call, nothing happens. That’s because we did not reset the gateway.

We reset the gateway, and look at the result again: