Globalized Dialplan CSS

[Cameron Whitehead]

I have been using the line/device dial plan for some time now and am wanting to move fully to the Cisco recommended globalized dial plan.  I have most of this in place already with the e164 dialing and calling party translations etc.  The one part I am missing is the CSS.

Do I now just put the "allowed" partitions in the line CSS below the "blocked" partitions, remove the device level CSS and leave it at that? 

[R0g22]

The line/device approach won't change. You would still have your blocked patterns above your allowed patterns or I should say your device CSS will allow calls while your line CSS will block calls (if there are any restrictions in place for certain users).
The only thing that changes with Globalization is that the CSS will now block/allow partitions for your TP's rather than RP's.

[Cameron Whitehead]

In the SRND though there is the following:

"When using the +E.164 dial plan approach explained in the chapter on Dial Plan, all PSTN route patterns are accessible by the line CSS"

which seems to me to say that you no longer need to use the device level CSS.

[R0g22]

Interesting.
The phones (be it device or line) never have direct access to the route patterns. You globalise going through the TP and localise it back when the call leaves CUCM (you can keep it globalised if there is CUBE and/or your ITSP supports +E.164).
Also, going by your statement, it contradicts the line/device approach.

[R0g22]

To add to this, from SRND 12.X -

The main architectural approach used to attain this globalization can be summarized as follows:

• When a call enters the system, the destination number and the calling number are accepted in their local format but are then immediately globalized by the system. For calls originating from endpoints registered with Unified CM, globalization of the dialed destination achieved through dialing normalization translation patterns and globalization of calling party information is either not required in the case of +E.164 directory numbers or is achieved through appropriate calling party transformation addressed through the phone's calling party transformations for calls from this line. For calls inbound on trunks, inbound called and calling party transformations serve the same purpose.
• Once globalized, the called number is used to route the call to its destination through the use of route patterns expressed in the global form. The global form may be a combination of a global internal, enterprise-specific form such as 81001234 and/or a globalized PSTN representation of a DID number, such as the +E.164 form (for example, +12125551234).
• Once a destination has been identified, the calling and called numbers are localized to the form required by the endpoint, the network, or the system to which the call is to be delivered.

Now, when you define CSS at both line and device, the line CSS take precedence (it's more like a concatenation of both CSS partitions). I would always want to have any restriction partitions to be at the line level so that the calls are not allowed in the first place. Allowed partitions go at the Device CSS. This is the line/device approach and should not matter if I have globalisation or not.

Now, you could globalise and route through the RP itself at the same time skipping the TP all together. If you don't have any block patterns, then you can use either line or device CSS (line CSS would be correct since it is closest to the source).

[Cameron Whitehead]

I found what I was looking for.  I knew I had read it somewhere.  From SRND 12:

"As described in the chapter on Dial Plan, the line/device approach has some specific issues, and creating a +E-164 dial plan based on the line/device approach is not recommended. The recommended approach for +E.164 dial plans is to combine class of service selection and dialing normalization on the line CSS and use the Local Route Group feature to address the requirement for site-specific egress gateway selection. In this approach the device CSS on the phone is not used at all."

[R0g22]

Thanks for highlighting that. I was not aware that this is not a recommended approach. Maybe the recommendation changed from previous versions or something.
I looked but could not find this in the SRND. I would be curious to know about the specific issues.

[R0g22]

Just found it. Are you setting up this dial plan keeping in mind mobility ? Because the section that you quoted this from is for Device Mobility dial plan considerations. Here is the complete thing and the reason why line/device approach has issues -

In a line/device dial plan approach, these route patterns would be addressed by the device CSS configured on the endpoint. When roaming but not leaving the device mobility group, the calling endpoint’s device CSS is replaced by the Device Mobility CSS configured on the roaming device pool. If fixed egress gateway selection is required for some calls and the route patterns for those calls are addressed by the device CSS, you have to make sure that roaming devices always roam across device mobility groups. This will guarantee that roaming endpoints always use the device CSS configure on the endpoint.

When using the +E.164 dial plan approach explained in the chapter on Dial Plan, all PSTN route patterns are accessible by the line CSS, which is not changed or updated for roaming devices.

I have highlighted the areas that are relevant.

[Cameron Whitehead]

Yes I know that this excerpt is from the Roaming section but it makes reference to the Dial Plan section saying it describes there issues and why you should no longer use the line/device deployment.  I agree that I cannot find this in the Dial Plan section but it seems to me that the line/device approach is still deprecated.

[R0g22]

You are interpreting it incorrectly. It gives you a reason why it is not recommended in mobility. That in no way means that it is deprecated and needs to be taken into consideration even when mobility is not being deployed.
Dial plan section is correctly referenced here and elsewhere.