Best practice - dial plan question

[Clutz5250]

I'm currently studying the CLCOR and trying to digest stuff relative to the environment I'm familiar with. So I'd like to do what i can to ensure I'm not crossing any wires.

Question:

+ dialing across the board seems like the desirable approach for dial plans, and normalizing at the gateway. Where I get confused is the matter of access code norms, so prefixing 9 for outbound (NANP) for example. Access code numbers sounds like the preferred paradigm? If that is the case, should the best practice be transforming + prefix to access codes at the CUCM (if there's no onnet matches), then let the gateway further normalize and strip the access code? Why couldn't you just keep it all + dialing (outbound) and remove the need for the numerical access code? Testing the waters because the latter seems like the way. 

[b.winter]

My 2 cents:
Normalization from an end users perspective, should be done already in CUCM.
From external, CUBE / GW should do it, and send +E.164 to CUCM, and should also receive it.

Access codes are "needed" because that's the old dialing habit from ISDN. There was no "+".
Technically, you could just have everything in +E.164, but then you have to teach your users.

[Roger Kallberg]

To add to what @b.winter so correctly wrote. You should not transform + numbers to access codes, you should do the opposite, ie transform access codes into + numbers, then you route the call to either an on-net or off-net party depending on where the number resides.

[Clutz5250]

So this is my frame of reference: user dial habit is 11 digits (no access code, just 11 digit extensions, where the first digit is the country code). If onnet, it will match in the onnet partition. If it doesn't it will hit a generic translation pattern and prefix a 9. digit lookup will reprocess and find the route pattern in the offnet partition because the route patterns have a 9. this references the local route list then the device pool configured route group, then onto the gateway.

If the user dial habit requires a 9 for offnet, I would see that as inviting more potential for hairpinning off the gateway if the number actually lives onnet, and said route patterns live in the offnet partition. It doesn't seem like a good dial habit unless there's some translation patterns catching those.

So between what you and b.winter are saying, normalizing for inbound outgoing dial peer toward CUCM should have translation profile that prefixes a +.
the internal incoming dial peer is still curious though because b.winter said normalization should happen at CUCM. I'm thinking he meant if there was any access codes being pressed, those should be normalized to +, which aligns with what you said. If that's the case it would mean the internal incoming dial peer facing CUCM would match +, then the outgoing dial peer towards the ISP would strip the +

please correct me if I'm wrong.

[Roger Kallberg]

Answering from my mobile, so somewhat condensed answer. Will give you a more comprehensive tomorrow when I’m back in front of a computer.

Inbound calls to the gateway from CM should typically use information in the VIA header to match the inbound dial peer. The same is true for calls coming in from a ITSP over a SIP trunk.

When it comes to on-net calls and translations, you’d want these to egress into a CSS after the translations that has visibility over all internal directory numbers and the relevant route patterns for sending calls to the PSTN. With that you’ll keep the on-net calls on-prem and if not found internally it will send the call to PSTN.

On calling without access code, that’s not typically a viable option in a corporate system landscape. You’d either dial in +E.164 and/or access code that you transform into +E.164 before send onwards to an egress gateway.

[Clutz5250]

---

@Roger Kallberg wrote:

Answering from my mobile, so somewhat condensed answer. Will give you a more comprehensive tomorrow when I’m back in front of a computer.

Inbound calls to the gateway from CM should typically use information in the VIA header to match the inbound dial peer. The same is true for calls coming in from a ITSP over a SIP trunk.

When it comes to on-net calls and translations, you’d want these to egress into a CSS after the translations that has visibility over all internal directory numbers and the relevant route patterns for sending calls to the PSTN. With that you’ll keep the on-net calls on-prem and if not found internally it will send the call to PSTN.

On calling without access code, that’s not typically a viable option in a corporate system landscape. You’d either dial in +E.164 and/or access code that you transform into +E.164 before send onwards to an egress gateway.

So it seems like in part we are confirming the same thing on this: sending +E.164 patterns to the gateway and let it strip at the gateway, which makes sense. 

Just to rehash, correct me if I'm off anywhere in this logic:
Lets say an environment is all +e.164 DNs. users are taught to use + before dialing anything. The CSS they have assigned has the onnet number partition and an offnet partition with route patterns to go out. We know that when the user dials a +e.164 pattern, the most specific pattern is matched during digit analysis in that CSS, so if they dial onnet it will get matched and if not, may hit a the generic route pattern. the route pattern doesn't need to prefix an access code; its already been matched and knows where to go. so no need for transform/translation just go to the offnet gateway. So we send the +e.164 pattern toward the gateway. it eventually matches an outgoing dial peer with a +T pattern pointing to the ITSP and has a translation profile to strip the + (normalizing for carrier - if needed). 

No access codes in this scenario. just + dialing. This seems pretty efficient.

[Roger Kallberg]

Absolutely not disagreeing with you on this in regards to +E.164 dialing, but that is not related to what you stated in your previous answer where you wrote this “user dial habit is 11 digits (no access code, just 11 digit extensions, where the first digit is the country code)”. That is what I referred to as not being a typical viable option for a corporate calling solution.

[Clutz5250]

ah. so i did say after that: "If onnet, it will match in the onnet partition. If it doesn't it will hit a generic translation pattern and prefix a 9. " 

Anyway, i think I moved closer to some clarity now. Thanks!

[Roger Kallberg]

---

@Clutz5250 wrote:

ah. so i did say after that: "If onnet, it will match in the onnet partition. If it doesn't it will hit a generic translation pattern and prefix a 9. "

---

Absolutely, but again this is not commonly a viable option in a corporate calling solution as there would be no deterministic way to differentiate between when the whole number is entered in the first step, so you’ll get a delay in call proceeding as it would wait for inter digit timeout. This is caused by that there are variable length in extension numbers in various part of the world. With an access code the system would know that it’s not an on-net call and therefore you can have a deterministic analysis of when the whole on-net extension number is entered.

For someone asking for advice on best practices you seem to have a very predetermined opinion on how to do this. Maybe you should consider being open to others advice, otherwise what’s your intention with asking for guidance on this?

[Clutz5250]

---

@Roger Kallberg wrote:

Absolutely, but again this is not commonly a viable option in a corporate calling solution as there would be no deterministic way to differentiate between when the whole number is entered in the first step, so you’ll get a delay in call proceeding as it would wait for inter digit timeout. This is caused by that there are variable length in extension numbers in various part of the world. With an access code the system would know that it’s not an on-net call and therefore you can have a deterministic analysis of when the whole on-net extension number is entered.

For someone asking for advice on best practices you seem to have a very predetermined opinion on how to do this. Maybe you should consider being open to others advice, otherwise what’s your intention with asking for guidance on this?

---

My intention is for preparing for the CLCOR, as prefaced in my first post in this thread.

When I post here, it is sometime to test my own understanding and hear about how other people do things.

I'd figure it's pretty self evident that I'm putting myself out there for advice - by virtue of me posting a thread, explaining what I'm use to, and stating the confusion I have. So i don't know what you are even talking about when it comes to being open.

If you think that I need to sound a certain way - maybe you are right. I admit, I can have an ego and perhaps that gets woven into what I'm trying to present. I apologize if how i came across offended you. 

All that said, I'm thinking this isn't the first time I've run across you on this board - if memory serves me correct. Seems that we may simply have difficulty understanding each other. Perhaps we can each extend some grace with each other. I can start with your point, that if you think I sound really opinionated, maybe that's something i can try to work on with future posts.

Cheers.

[Maren Mahoney]

I have taught CLCOR and will say that the common practice for Globalized Call Routing is that you will globalize on ingress (at the SIP CUBE for PSTN inbound, or using translation patterns for calls coming into a phone) meaning that whatever the digits presented will be turned into E164 format - either before entering CUCM or immediately upon entering CUCM. Then CUCM will use route patterns (which should be in the form of \+! unless you have a specific country like \+44! or something) to path calls that do not match an internal DN or other internal pattern.

If your users generally dial 9+<number>, for Globalized Call Routing as described in CLCOR (and as commonly deployed), the users will dial 'normally' but their CSS will not have access to route patterns (and route patterns will not start with a 9). Rather their CSS will have access to the Translation Patterns that will globalize what they dial. (Take the 11-digits they dial and turn it into E164 format.)

Access codes can be handled a couple of ways. Either by adding an Enterprise Alternate Pattern to the DN (which becomes an alias for the DN), or by adding additional Translation Patterns that capture the access-code-style dialing and again turn the number into E164.

Does that help?

Maren

[Clutz5250]

Thank you for responding.

A few questions if you don't mind:

1. Is it fair to say + dialing reduces the use case/need for access codes?

2. You said:

---

@Maren Mahoney wrote:

...

If your users generally dial 9+<number>, for Globalized Call Routing as described in CLCOR (and as commonly deployed), the users will dial 'normally' but their CSS will not have access to route patterns (and route patterns will not start with a 9). Rather their CSS will have access to the Translation Patterns that will globalize what they dial. (Take the 11-digits they dial and turn it into E164 format.)

...

---

So the device/line CSS will not have any route patterns? Not even a route pattern like \+! for when it does the next digit analysis in the CSS? Or perhaps the next digit analysis is moved to another CSS with \+ route patterns?

3. Is globalizing/normalizing closer at the source, like on a gateway, perhaps the better practice? I'm curious if there is any big argument for doing either on CUCM instead? 

[Maren Mahoney]

1. Not really. Folks still want to do some form of abbreviated dialing for in-building or on-site targets. Also, for other in-house targets that won't be abbreviated dialing it's all but impossible to dial a + from a phone. So use of EANs or translation patterns for site-code dialing, and also a translation pattern to allow 10-digit dialing for internal but non-local numbers.

2. With Globalized Call Routing, the device CSS will be one that has access to the \+! route patterns (in a "System" partition) and that device CSS will be generic across most if not all devices. Lobby phones or other vanity phones may be configured differently. Then, the Line CSS will provide access to the partitions for things (translation patterns, for instance) that folks actually dial. Think about it in terms of Extension Mobility where the Line CSS will come along with the user wherever they log in. So Bob in Miami travels to Berlin and logs in with Extension Mobility. Bob can dial 'normally' as if he were in Miami and the translation patterns that what he dials matches will turn whatever he dials into E164 format. Now, because the Device CSS uses route patterns with Local Route Group configured, and because the Device Pool of the phone in Germany will point the LRG to the Berlin PSTN GW. On the egress GWs and trunks the outgoing transformation calling search space will take the E164 numbers (whether dialed by Bob or by Hans who is always in Berlin) and modify them to match what the PSTN service provider in Berlin wants to see from a digit standpoint. Similarly, if Hans travels to Miami same thing but modifying the numbers sent to the Miami service provider in NANP format. If you use mobile clients like Jabber, the Device Mobility feature provides the same sort of behavior. (This is the 'globalize on ingress, localize on egress' thing.)

3. Globalizing/normalizing at the source is the thing. If you use SIP Trunks you will want to normalize on the CUBE prior to sending the call to CUCM because CUCM would have to use inbound translation patterns (which gets messy) to modify inbound on a SIP Trunk. For MGCP and H323, the inbound PSTN calls are globalized on the GW configuration page in CUCM by common practice. For calls inbound from a phone, the globalizing/normalizing is done via translation pattern as the first thing matched when a user dials a number.

Here is a post by Meddane (who is amazing) that described Globalized Call Routing in some detail that you might find helpful:

Globalized Call Routing and how it Simplifies Some Features 

Let us know what additional questions you have!

Maren

[Clutz5250]

That was quite the info load to think through. Thank you for taking the time to explain! I went through that article some and bookmarked. 

Here are my thoughts on your points:

1. Makes sense
2. So in an ideal globalized dial plan, the device css should have the offnet PT with a \+! route pattern, and the line should have translations like globalizing patterns, cluster DNs, blocked patterns?
3. So, between your question and reading the link you provided, i have a further query concerning outbound. One of the examples in the article transformed a globalized pattern call back with the 9011 prefix after call routing was done (so gateway transform). Per the article:

[======================================]

The resulting of the Transformation Pattern is:

The system strips the “+” sign because the Discard Digits PreDot from the number +441519988776, we get 441519988776, then the System prefix 9011 because the Prefix Digits 9011.

The resulting is 9011441519988776.

That’s magic, the user dials 9011441519988776 then the System Globalizes the dialed digits using the Translation Pattern to obtain +441519988776, the resulting pattern will match our magic Route Pattern \+!, then select the local gateway and the

Transformation Pattern will transform this number to the origin dialed digits so that the call can be routed through PSTN.

"
[======================================]

I guess this is just harkening to the classic way of things, because if the gateway can recognize a \+, why not send it that way and be without the transform hoops in CUCM? The transforms instead could happen at the outgoing dial peer towards the provider, where it strips the + and prefixes whatever it needs to. 

[Maren Mahoney]

1. Excellent

2. Yes

3. There are two parts to the call. The caller dialed 9011441519988776 and the translation pattern strips the 9011 and adds the +. Then, CUCM chooses an egress gateway. If the (presumably US-based) provider wants 9011 prefixed to international calls, the outbound transform will modify the number to strip the + and prefix the 9011 before sending to the GW. But consider if Bob now flies to England (where the country code is 44) and logs in with his EM profile. He still dials 901144441519988776 and the translation pattern still globalizes the number to +441519988776. But now the egress gateway that CUCM chooses is the one in London. THAT PSTN provider wants the call presented with the national number (without the 44) but with the 0 prefix indicating that it is long distance inside of England. So the outgoing transform would strip off +44 and add 0 so the PSTN would get 0441519988776. 

The idea is that Bob could go to London, Nairobi, the South Pole, or to the Moon and dial how he normally dials like he is back home in Miami regardless of where he happens to be sitting at the moment. CUCM will globalize the number to E164 format upon dialing, again regardless of where Bob is sitting. Next, CUCM will select the "best" gateway for egressing the call. But the PSTN in each of the four locations wants the numbers presented a different way. So the outbound transformation CSS on the egress GW/Trunk config page will provide the transforms necessary to localize the number for THAT egress point. Which means that Hans from Berlin could be traveling with Bob and dial however Hans dials normally and CUCM would do the exact same thing - globalizing as Hans dials, and the localizing based on the needs of the provider at the egress point chosen.

In the example you are referencing, both the source and the egress are in the US (again, presumably). So 9011 is dialed/stripped and 9011 is prefixed at egress. But that's because the US gateway is the 'best' egress in that case. That passage is meant to describe why we bother stripping/prefixing if both the source and egress are in the US. It's because that scenario is not always guaranteed.

Maren