Implementing E.164 called and calling party transformations
By using cluster-wide E.164 route patterns, number localization is no longer done on the route pattern. Instead, localization must occur prior to sending the call to the gateway or trunk device. This is accomplished with called and calling party transformations.
Getting ready
In this recipe we assume you already have the necessary partitions and calling search spaces for called and calling party transformations created. Refer to the There's more... section for an example partition and calling search space scheme.
How to do it...
To implement called and calling party transformation on either a gateway or trunk device, perform the following:
- Add the calling party transformation pattern (Call Routing | Transformation | Transformation Pattern | Calling Party Transformation Pattern).
- Add the transformation pattern appropriate to your environment and location:
- Prefix any necessary digits and select the appropriate digit discard field. In the case of the previous example, Discard Digits is set to PreDot with no digits being prefixed.
- Add the called party transformation pattern (Call Routing | Transformation | Transformation Pattern | Called Party Transformation Pattern).
- Add the appropriate transformation pattern and any prefix digits necessary. In this case, we again choose PreDot for Discard Digits and set Prefix Digits to 9. Refer to the There's more... section for further explanation if required.
- Navigate to the configuration page for the port or device.
- On a MGCP controlled gateway, transformations are configured on a per port basis. The configuration page for the port is found by navigating to the configuration page for the gateway, then selecting the appropriate T1 port under the Configured Slots, VICs and Endpoints section as indicated in the following screenshot:
- This is configured at the device level for trunks and gateways.
- Next we apply the transformations to our trunks or gateways. Calling party transformations are configured under the section titled Incoming Calling Party Settings.
- Select the Calling Search Space that contains the partitions you assigned to the called and calling party transformation patterns and apply it to all applicable fields:
The previous screenshot is for an SIP trunk. Here we uncheck Use Device Pool CSS as we are not using the device pool for number transformation.
- Finally, called party transformations are configured under different sections depending on the type of device.
On the gateways configuration page, this section is called Call Routing Information - Outbound Calls, and Outbound Calls for trunks.
Again, we are not using the device pool for number transformation, so we uncheck boxes for both calling and called device pool transformations.
How it works...
When a call enters through a gateway or trunk device, the calling and called party transformations are applied depending on transformation patterns available to the calling search space used:
- Calling party transformation patterns: In the example from the recipe you see a calling party transformation pattern using
\+1.!. As we explain in the example, we discard digits PreDot. We do this to normalize the number users see when their phone is ringing and connected, as users in the United States may not be accustomed to seeing +1 before the number.Alternatively, say we have an office in San Francisco where users are accustomed to seeing only seven digits for local calls and ten for everything else. We still use the
\+1.!PreDot pattern to remove the +1 for calls but we add another pattern to strip the area code off. In this case that pattern would be\+1415.!, stripping PreDot with a partition of PT-SFO-Inbound-ANI, or something similar. By doing this, calls from 415 numbers will show as seven digits on the display when ringing and connected. - Called party transformation patterns: Prior to local route groups and called party transformations, you would prepare the dialed number to be sent to the gateway or route list on the route pattern itself. Called party transformation patterns would then be used to prepare the dialed digits to be accepted by the gateway, trunk, or PSTN. In many cases this involves stripping the plus sign and prefixing an access code before sending it out to the gateway or trunk to route the call to the PSTN.
How we modify the number depends on the type of gateways or trunks we are using. With MGCP gateways, we format the number so that it can be sent across to the PSTN. In some cases this means removing the plus, and appending or removing digits depending on what the carrier expects. For instance, if the carrier expects seven digits for local calls and 1 + 10 digits for long distance calls, we might strip the +1 and area code for local calls and strip only the plus for all other calls.
For gateways and trunks, access codes are typically configured to inform the gateway or trunk to send the call to the PSTN. Typically these are 9, or 91. In this situation we would strip the necessary digits and prefix the access code appropriate to the call. For example, say our carrier requires seven digits for local and eleven digits for long distance calls; assuming we require an access code of 9 for local and 91 for long distance calls, we might implement the following called party transformations:
- \+1.!
Partition: PT-SFO-Outbound-DNIS
Prefix digits: 91
- \+1415.!
Partition: PT-SFO-Outbound-DNIS
Prefix digits: 9
Now, when a call is made to +1 415 555 1234, for example, the transformation pattern will remove +1415 and append a 9, sending the call to the gateway or trunk as 95551234 where it would match a dial peer before being sent out to the PSTN. While it is possible to do these transformations on the gateway themselves, managing them in UCM provides a central point for configuration and can help reduce dial plan maintenance.
- \+1.!
There's more...
Calling and called party transformations are primarily used to localize the ANI displayed for calls entering the system and localizing calls for the gateway before sending it out to the PSTN.
In this recipe you will see a few partitions and calling search spaces that may not immediately make sense. In order to accomplish these transformations on a per location basis we have six partitions and three calling search spaces.
The partitions and calling search spaces we use are:
If you have no need to localize the ANI on a per location basis you might have a single calling search space and partition instead:
These are only some suggestions; make sure you apply the appropriate calling search spaces and partitions for your cluster.