Understanding the 5 uses of Calling Party Transformation Pattern in UCM

Full Disclosure: this is not for the faint of heart! And unless you are trying to wrap up your CCIE Collaboration then you are probably not going to be overly interested in this article.

This method of transforming the Calling Number within UCM has rarely been fully understood by candidates pursuing the CCIE Collab certification. The aim of this somewhat lengthy blog is to provide a use case for every possible scenario where the Calling Party Transformation Pattern provides some value. In total there are 5 completely different situations where Calling Party Transformation Pattern comes into play, although I doubt one would ever encounter a real-world situation whereby all the different scenario’s would be in used at the same time.

Before we begin, let me stress two things.

Firstly I am focused on the version of UCM that is currently tested in the CCIE Collaboration Lab exam at the time of writing. This is 9.1(1). Yes I know this is a little old given that version 12 is out and about but c’est la vie. Secondly I am going to have to pull out all of my hair if I have to keep on typing Calling Party Transformation Pattern so please accept my apologies and let me abbreviate this to “CGN”.

Just for clarity we are talking about the following setting in the 5 uses cases below:

Scenario 1: CGN From Phone

This setting is used to translate the Calling Number for calls from a registered phone to any destination. A good example to illustrate the use of this setting can be seen when globalized DNs are being used and the CallerID for internal calls is required to be 4 digit. So for example let’s say we have a phone registered to UCM with the following DN:

When this phone calls another phone the Calling Number is going to be the DN as shown in the screenshot below:

If it is requested that the Calling Numbers should always be in 4 digit format (i.e. 2001 in the example above) then we can apply a Calling Search Space (CSS) under originating phone configuration (UCM Administration > Device). This is also a setting under Device Pool.

In this case the “ANI-FROM-PHONE” CSS contains a partition called “ANI-FROM-PHONE-PT” which is used below.
Now we can add the CGN (UCM Administration > Call Routing > Transformation > Transformation Pattern > Calling Party Transformation Pattern) as shown below:

So lets make that call again- we should see the +14082022001 calling number shortened to 2001 – and this is done by the “CallerID for calls from this phone” setting on the device that makes the call.

Note that this is also the Calling # that is displayed under the Missed and/or Received Call Logs depending on whether the Called Party answers the call or not.

Before we are done with this usage of CGN, it must be mentioned that the setting we are talking about here “CallerID for Calls from this phone” does NOT work with MVA and Remote Destination Profiles. Even if the Device Pool level setting is configured, it is not applied for the Remote Destination Profile/Remote Destination.

Scenario 2: CGN To Phone

The previous example illustrated transformation of the CallerID at the originating device. In this second scenario we are transforming the CallerID at the device which has been called and is in the ringing or connected state or in other words at the destination device.

So at this stage I am going to undo all the configuration used in scenario 1 above. Temporarily put that to bed. We are back at the situation +14082022001 makes a call to another phone and the CallerID is “+14082022001”.

We can go to the destination device (UCM Administration > Device) and modify the “Remote Number CSS” – this setting under phone configuration is just underneath the setting discussed in scenario 1.

This CSS contains a partition called “ANI-TO-PHONE-PT” and the following Calling Party Transformation is placed in this partition:

We have achieved the same thing as we did in scenario 1- the CallerID is now “2001” as opposed to the globalized number.

The critical different is that this transformation is performed at the Called Party (or destination device) as opposed to the Calling Party. We could therefore have a different CallerID displayed when the same phone has called a different destination.

Let’s take a look at a more useful example. I am in San Jose. My DN is +14082022001 (no I am not giving you my real number, please don’t call this number!). If I call somebody in the US I want the CallerID to be 4082022001. Somebody in North America instantly understands this to be a national number. If I call somebody in London – well 4082022001 doesn’t really mean much over on that side of the pond as this is a national number within North America. A CallerID of 0014082022001 would be more useful since this is the way I would dial my number in San Jose from London (“00” being the international prefix and “1” being the country code of NANP). So we could configure the US devices with a “Remote Number CSS” that takes +14082022001 (my DN) and transforms this DN to 4082022001. The London devices would be configured with a “Remote Number CSS” that transforms the DN +14082022001 to 0014082022001. The CallerID differs based on destination.

One final point. The “Remote Number CSS” does not affect the number that is placed in the Missed/Received Call log of the destination / Called Party.

So the phone in the ringing state is:

If the call was not answered and we check the Missed Call Log we see the CallerID that was present at the originating device. The Transformation performed at the destination device does not affect the number in the Call Log. In other words the CallerID that is the result of the transformation of the Remote Number CSS is only active during the call (ringing and connected).

This is in contrast to scenario 1 when transformation at the originating device / Calling Party affects both the Calling number that is seen during the call and also afterwards in the call log.

Scenario 3: Connected Party

This scenario is going to remind you of scenario 2 above. We are going to use the “Remote Number CSS” under phone configuration. But WAIT! We are going to be using this in a completely different context.

Up to now we have been solely focused on Calling Number. When I call you, the number you see. In our examples thus far this has been “From +14082022001” or “From 2001”.

Let me introduce you to the Connected Number (also called Alerting Number). If I call you, this is the number I see. In other words “To 3001” assuming your number was 3001.

The Connected Number is often the same as the Called Number but it could be different.

I will give you an example. My trusted phone calls 3001. Because we are using globalized DNs and the actual DN is +19723033001, we have to transform the Called Number from 3001 to become +19723033001. This is done in a Translation Pattern (3xxx with a Called Number Prefix of +1972303). Note I am talking about Called or Dialed Number here.

Look at the originator of the call or Calling Party- although we dial 3001, we in fact see “To +19723033001”). This is the Connected Number. The Called Number is 3001, the Calling Number is +14082022001 (seen on the dialed phone) and hence this is a situation whereby the Called and Connected Number are different.

This might look and feel weird if you were making that call. We can use the “Remote Number CSS” of the Calling / Originating device to transform “+19723033001” to become “3001”. So the phone that is making the call will have the following phone configuration:

Note that this is the same setting as used in scenario 2 when a device was receiving a call and we wanted to transform the CallerID during the ringing state. So we can’t mix and match- scenario 2 and 3 cannot be used at the same time since it depends on the same setting under phone configuration.

The CONNECTED-NUMBER CSS contains a partition called CONNECTED-NUMBER-PT and the following Calling Party Transformation pattern is placed in this partition:

Now we need to flip a UCM service parameter in order for the “Remote Number CSS” to be used to modify the Connected/Alerting Number. This is an Advanced UCM Service Parameter.

Now if I make that call again – I dial 3001 and this is what I see:

The same number appears in both the Alerting and Connected state (when the Called Party answers). The number 3001 is still globalized by a Translation Pattern so don’t think for a second we are manipulating the Called Number.

Just to recap, this “Remote Number CSS” is used in scenario 2 at the destination device to modify the Calling Number. But in this scenario (after changing a service parameter) the “Remote Number CSS” can be used at the originating device to modify the Alerting/Connected number. Confused? You are not the only one.

Scenario 4: CGN From Provider

This situation is different to the first 3 scenarios as here we are modifying the Calling Number on an incoming gateway or trunk. In other words the call is arriving into UCM from an off-cluster destination. The scenarios discussed thus far have involved transformations on the phone itself.

For clarification the gateway or trunk is the originator of the call (from the perspective of the UCM). The destination is presumably a phone or some other device that is registered to the cluster (otherwise why did it come here).

Let’s look at an example whereby the UCM has received a call from an H323 gateway connected to a T1 PRI.

A quick debug on the H323 gateway shows that the CallerID is 4082223333 with Plan and Type of Number set to Unknown.

In UCM we are using globalized call routing and we would like this number to be transformed to E164 format – in other words +14082223333. So the CallerID seen on the destination phone would be +14082223333.

We are able to make the following change under the gateway configuration in UCM (remember the Number Type of the Calling Number is Unknown):

The ANI-FROM-GATEWAY-CSS contains a partition called ANI-FROM-GATEWAY-PT. In this partition we place the following CGN:

If we look at the Calling Number displayed on the destination phone:

Now the method of transforming the CallerID discussed in scenario 2 might come into play here if you would like the Calling number to appear in localized format whilst the destination phone is ringing/connected. You could configure this phone with a “Remote Number CSS” to shorten the number to a localized format during the ringing and connected state. Remember the Missed Call Log would show the Calling Number at the originating device (after the gateway has globalized the number “+14082223333”). Without performing this localization on the destination phone using “Remote Number CSS” the CallerID is globalized in both the ringing/connected state as well as the Missed/Received Call Log.

This scenario and scenario 2 are closely related when it is desired to used globalized numbers for CallBack but whilst the phones are being alerted a localized CallerID is desired.

Scenario 5: CGN To Provider

The final scenario is again specific to off-cluster calls and is used to transform the CallerID being sent to the provider whether that be a SIP Trunk or traditional Telco gateway. The gateway/Trunk in this case is the destination device (phone making the call is the originating device). In the previous scenario the Gateway/Trunk was the originating device- in other words we are dealing with calls going to an off-cluster destination in this example.

Lets assume our internal DN’s are 4 digit. This is a deviation to the other 4 scenarios whereby we have been using globalized DNs. So our now infamous phone is configured with extension 2001. When this phone calls the PSTN we don’t want to send just 4 digits as the CallerID- this is disallowed as 4 digit CallerID is meaningless in the public network. We want to transform the CallerID from 2001 to 4082022001. And we want to do this regardless of the number we are dialing. So this transformation needs to take place when the user is dialing Emergency, Local, LD or International calls.

The gateway configuration would look like this:

The ANI-TO-GATEWAY-CSS contains the ANI-TO-GATEWAY-PT and the following CGN is placed in this partition:

So when extension 2001 calls a PSTN number such as 911 the following can be seen on the gateway housing the T1 PRI connection:

If it is desired that the CallerID is different depending on the type of call being made (Emergency/Local/LD/International calls all having differing CallerID’s), then this setting cannot be used- instead the CallerID can be modified elsewhere (such as Translation Pattern or Route Pattern/List).

And that’s about it for now. Let me know if you have any interest or preference on the next topic I will blog about. Time is running out for CCIE Collaboration v1 so if you are half way through your studies you had better get moving!

Vik Malhi, CCIE#13890
Facebook: https://www.facebook.com/VikMalhi
Twitter: @vikmalhi
www.collabcert.com