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. 

[Clutz5250]

Thanks again for the reply! 

Hopefully you don't mind pressing a bit more with #3; please bear with me. Going back to Bob from the US now in the UK, lets assume this: CUCM -> SIP -> CUBE -> SIP -> ITSP, and no transform being done on CUCM but rather on the CUBE: 

Bob uses his same old dial habit of 9011441519988776 while in the UK -> that globalizes to +441519988776 -> as we would expect there’s no pattern match for onnet during digit analysis and so it hits a generic route pattern in the device CSS ->  goes to local route group -> device pool points to london gateway per the local route group because of mobility group or phone EM -> so goes to london gateway as +441519988776 (again, no transform set in CUCM) -> hits Incoming dial peer matching -> second dial peer lookup then goes to outgoing dial peer to ITSP and it transforms +44 so that the pattern is now 0441519988776 (what the carrier expects).

so is this example fine... or should transforms ideally be set per gateway in CUCM? I get it probably depends on the environment to some degree. 

[Maren Mahoney]

As it happens, you have hit the nail on the head! Meaning: Whatever transforms are done on CUCM prior to egressing the call are intended to 'give to the target' digits in the form desired by the target. So, for instance, if the ITSP in London wants all numbers sent to them in E164 format (and that desire is becoming more common for SIP providers) then not only would CUCM not have to 'localize' the number upon egress, in this case the CUBE would not have to do any manipulation either.

Similarly, if the same ITSP sent to the CUBE (and the CUBE sends to CUCM) all numbers in E164 format then neither the CUBE nor CUCM would need to do manipulation on inbound calls either.

More to your question, if you configured your CUBE to perform all E164/Local digit manipulation then CUCM could simply leave things in E164 format on both inbound and outbound directions.

So, in the end, my favorite answer as an instructor was always, "It depends!" because it always does. Your task as the UC Engineer is to get everything to agree and to work. So it depends on your ITSP, and whether all sites are and will forever be in a single dialing domain, and whether you are using SIP or MGCP/ISDN, and what your internal dialplan is, and so on and so on. There is no 'ideal' because each situation is different.

I will say that "The Cisco Way" with regards to the CLCOR course is for CUCM to do the digit manipulation on MGCP/ISDN (because you have to), and for CUCM to do it for SIP Trunks as well. (Remember we are talking about "the right way, the wrong way, and The Cisco Way". Never let reality get in the way of passing a Cisco exam.)

The good news is that you are thinking all the right things and asking all the right questions. I think you'll do fine.

Maren

[Clutz5250]

Thank you for the encouragement and perspective. I know i can be a bit persistent on things, so thank you for enduring and teaching me.

[Roger Kallberg]

What I'm trying to convey is that adding the access code after it's been through a translation pattern is not commonly a viable option.

[Elliot Dierksen]

Here is my $0.02 on this. Some of it depends on how big your dial plan needs to be. Any internal extensions that begin with 10 or 11 will never overlap with NANP. If you can structure your dial plan that way, no access codes are needed.

I have a personal pet peeve about hair-pinned/tromboned calls - ones that go out to the PSTN to come back in. My dial plan preference is to take what the user dials (meaning stuff with the "+"), and globalize it. Route the calls based on the globalized unambiguous destination, and then localize as needed when it exits via a gateway/trunk. I keep all the inbound translations in in a partition that is also used when dialed numbers are being globalized. That way if a number is internal, it always routes internally. That means you needs to have your gateways/trunks route calls to CUCM in globalized form.

That is as pithy as I can get it.

[Roger Kallberg]

@Elliot Dierksen When you say Globalise what do you mean by that? I’m asking because of this part of your response “My dial plan preference is to take what the user dials (meaning stuff with the "+"), and globalize it.”.  In my view +E.164 is the global number format, so by that what you wrote sounds a little different. Just want to be clear on what globalised format entails for you?

[Elliot Dierksen]

@Roger Kallberg sorry if I wasn't clear. Yes, I mean I use translation patterns to transform dialed digits into +E.164. Frequently the only offnet route patterns I will have are "\+!" and "\!#'. Meaning in my local area where we 10 digit dial numbers, a user would dial 94075551212. That would get translated into +14075551212 and then routed.

[Maren Mahoney]

FWIW: While that is a reasonable way to do thing in the real world, this OP is studying for the CLCOR exam and what you suggest is NOT "The Cisco Way". The Cisco Way is to globalize inbound calls on MGCP/H323 GWs is to configure inbound call routing transforms on the GW config page. And for SIP Trunks to globalize on the CUBE/GW itself prior to sending the call into CUCM.

I only point this out so the OP has the best chance of passing the exam.

Maren

[Roger Kallberg]

I agree with @Maren Mahoney on this, with one small exception. I would treat SIP and H.323 gateways the same, ie do the translation of numbers (calling and called) into globalised format on ingress from the service provider and the opposite in the other direction.

Not related to the CLCOR, but real world I would say in general stay clear of MGCP gateways, it’s not worth the effort and they do not save as much configuration as one would think at first glance.

[Maren Mahoney]

@Roger Kallberg H323 does not support the + so you can't fully globalize the numbers into E164 format on the GW, because H323 can't transmit the + to CUCM. Instead you'd make sure a call has the right TON and use the inbound transform section of the GW config page to finish the globalization based on TON. (Unless something has changed?)

And I agree that both H323 and MGCP should be avoided unless absolutely necessary. Keeping everything SIP (even if one is terminating an ISDN circuit on a GW and then using a SIP Trunk to send the call to CUCM) is the smart play.

Maren

[Roger Kallberg]

You’re probably right on the + not working in H.323, it was years ago since I did anything with it, like 15+ or so. Also as it’s being deprecated in IOS I recommend no one to use it.

[Elliot Dierksen]

Yes, H.323 is dead. I don't know if it is/was a Cisco thing or an H.323 thing, but there as an implicit strip of the '+' character in H.323 that made doing a fully globalized dial plan challenging. Same thing for H.323 gatekeeper. Yes, I actually did things with that long ago!