SRND Design question

[tburke100]

Hello,

I have a question about the 7x SRND for Communications Manager concerning the new dial plan approach of 7.x.

In the "Localized Call Ingress on Gateways" of Chapter 10 it says the following about adapting the Called Party number of inbound calls from the PSTN:

"The globalization of the called party number can be implemented through one of the following methods:

• In the gateway configuration, configure Call Routing Information > Inbound Calls, where the quantity of significant digits to be retained from the original called number and the prefix digits to be added to the resulting string are used to globalize the called number. The prefix digits should be used to add the applicable + sign and country, region, and city codes.

• Place translation patterns in partitions referenced by the gateway's calling search space. The translation patterns should be configured to match the called party number form used by the trunks connected to the gateway, and should translate it into the global form. The prefix digits should be used to add the applicable + sign and country, region, and city codes."

End quotes.

Question: Is it really necessary to globalize the inbound called party number to the "+" format?

The two methods themselves are pretty straightforward, but the last sentence for both about the prefixes adding +, country, region, and city codes confuses me. It seems they should be used to convert the incoming called number to the "globalized" (ie unique) internal directory number to ring the appropriate phone. That could be 8-SC-XXXX, XXXX, XXXX/Partition Y, or +164 (but only if the internal DN is actually in this format, which is the Variable Length Dial Plan with Flat Addressing Without Site Codes" discussed in the SRND?).

Bottom line: does translating the incoming called number to "+" format buy you anything if you are NOT using E164 numbers for extensions, as the text implies? May sound like a dumb question, but this is pretty abstract stuff, and sometimes I find myself staring straight at something and not seeing it.

Thanks.

[William Bell · Accepted solution]

I think you have the right ideas. I understand your question and I agree that you don't have to use "+" dialing if you don't need to while still benefiting from the "globalization" features. The high level idea that Cisco is trying to get across is that for calls from an IP phone to the outside world, you would first "globalize" the number to something that could be analyzed ubiquitously across all gateways and then "localize" the dialing pattern to line up with the carrier/country/state/locality/etc. that a particular gateway is sending the call.

On the ingress side, you are doing basically the same thing. You "globalize" the called party so that your dial-plan can analyze the number and pick the appropriate tenant on your system. Then "localize" the calling/called party information for the user sitting at the phone.

Cisco is using the E.164 and International dial plan concept as a platform to demonstrate the usefulness of the dial-plan globalization approach. That being said, you aren't married to "" dialing. Consider it an extra digit that you can analyze in your overall dial plan design if you so choose. It could just as easily be a 8SSS code if you buy into Cisco's "flat addressing". Which, why one wouldn't just go to a 10-digit solution in north America versus 8+SSS is beyond me. Diff topic...

My point is, when you are thinking about using these features in your design, don't dismiss it simply because it involves "+" dialing. Think of it as "normalization" instead of "globalization", if that works for you. Here is an example that may help.

Most of my DP design work has been in the states, so I am used to the NANP. I have always (well, since 4.x) used a 10-digit dial plan. Meaning, I program all phone lines as 10-digit numbers in a flat partition. (Cisco now has a name for this, as you so aptly pointed out). If two phones in NYC are used to calling each other using 4-digits but their phone lines are actually 10-digit DNs. How do we manage this? As I am sure you know, we use translations that take the 4-digits and expand it to 10-digits. Or, put another way, we take the 4-digit "localized dialing" and "normalize" it to 10-digits before making the final decision.

To me, aside from a few corner cases, Cisco's SRND is saying the same thing. Accept the call from the phone/gateway in the "local" format. Normalize or globalize it to something that is universal. Make a decision on this normalized pattern, and give it to the phone user the way they are used to (again, localize it). The cool thing is that now there are more methods available to you to support this type of normalization. Irrespective of whether you need/want to dork around with "" dialing and country codes. Though, being able to program "" and country code on phone DNs is pretty helpful. Especially for international dial plans.

HTH.

Regards,

Bill

[tburke100]

Good answer, Bill. Thanks for taking the time.

I agree. I do in fact see the merit in using + dialing, especially going forward, and the additional flexibility is a positive.

Thanks,

--Tim

[tburke100]

I am a little slow on the uptake on this one, but I think I now know what was confusing me, in case it helps somebody else.

I think the part about globalizing the inbound called party number to +E164 format in the 7.0 SRND was "forward-leaning" to 8.0, where things like CUCIMOC require "+" format for telephone numbers stored in Active Directory to eliminate the need for Application Dial Rules and Directory Lookup Rules on Communications Manager, which were needed to reconcile the differing dial plan formats before.  For this implementation, the instructions in the SRND would make perfect sense.

[James Hawkins]

The new approach does sort of make sense but it seems to stop the use of international dial plans which I have used for the majority of my deployments in the UK as the "National Access" code is not included in E.164 number format. Hopefully the extract from the UK dial plan below will highlight what I mean.

# 0+1[2-69]1+XXXXXXX

P: 0                                  NATIONAL-ACCESS

P: 1[2-69]1                        AREA-CODE

P: XXXXXXX                        SUBSCRIBER

The UK dial plan is pretty messy without a nice structure as found in NANP. If I move away from using the Cisco dial plan with route filters then I either have to configure loads of +44 national dial plans or just do a few and hope the customer does not dial some of the more obscure locations (not really comfortable with that).

Does anyone know of any way of importing a set of route patterns, partitions etc. to CUCM rather than manually configuring them? I think that Cisco Unified Provisioning Manager might be able to do this but I have never used it.

[Aaron Harrison]

Hi

You can import route patterns, partitions etc using the Export/Import feature of BAT; you might find the columns need fiddling in the export if you go between version though...

The other alternative is AXL (which most provisioning software would use) - it's an XML API you can use to generate virtually any type of device/construct in CCM.

Regards

Aaron