Global SIP dial plan sanity check

[Paul Cobley]

Hi,

Have checked out the very detailed recommendations on Cisco Live for global dial plan design but our requirement slightly falls between the cracks & I just wanted to float our design through here for comment.

So, we have a customer with SIP gateways in 3 continents and users can effectivley have a DDI from multiple countries.

I have considered having internal DNs (non e164) and putting an inbound xlation on calls from each SIP trunk to hit the internal DN.

This is working in the lab but I have a doubt that this is a bit old school and not as prescribed in the latest SRND which suggests having e164 DNs in the internal partition.

Intersted in thoughts & real world experience.

thanks

Paul.

[Chris Deren]

There is no fit all dial plan on the planet that works for everyone as there is many ways it can be done for many different reasons, +e164 is definitely what every vendor is leading with these days, however it has flows on Cisco side as there are still apps that don't support it, there are even entities within CUCM that don't support it. With that being said if your organization can benefit from and it can support it, it should be strongly considered. What I typically suggest is to build the DNs in +e164 format, yet allow abbriviated intra-site dialing, i.e. 4 digits as I have yet found a customer who is willing to dial 12-15 digits to call their local co-workers, obviously if the environment is pure softphone i.e. Jabber that does not really matter as you use click to call most of the time anyway. 

Your other approach of translating DIDs into internal DNs, assuming consistency in last X digits is a valid approach as well, though if you are starting fresh I would lead with +e164. In either case if you deploy +e164 you still normalize the dial plan either on the GW or CUCM to prepand the + sign as most telcos will not send it your way.

You did not specify versions and list of your apps, i.e. CUC, UCXN, etc, but you definitely want to be on latest releases for better +e164 support.

I think SRND does a very good job describing this concept and it sounds as if you read it, make sure you understand it fully and lab out as much as possible.

HTH,

Chris

[Paul Cobley]

Chris, as always your advice carries a lot of weight & thanks for the prompt response.

This is a fresh build on CUCM9.0 - there is a Call Recorder (SIP trunk), 3rd party contact center (Zeacom) and SIP trunk to a Vidyo MCU / Unity Connection 9.0.

I'm considering 8 for on-net then a site code (3 digits) and 4 digit employee ID. 9 for an outside line globally (existing customer dialling habit). System numbers can be 8xxxxxxx also.

So, moving forwards we lose the ability to have 4 digit user IDs starting with 8 & 9 which I think is a compromise.

If anyone else has deployed anything similar I'd be very interested to hear.

[Chris Deren]

Why 4 digit employee ID?  Normally you would take the last 4 digits from the DID, if you do not have DID then assign a block per site which would allow you to do 4 digit dialing within site with nice consecutive range.  I have never seen anyone trying to use employee number or whatever random identifier as part of phone number. What if the company grows and then they change the 4 digit employee number to 6 digits or something completely different? 

Chris

[Paul Cobley]

The customer has around 200 users globally and any of these employees will have a DDI from any (or even all) of the 6 countries. So, they have 6 offices and DDI ranges in all of those countries. If a user has 6 x DDIs coming in on any CUBE I cant easily use a +e164 - after all which would I choose & why?

So, it makes sense to have a unique identifier in the internal_dn PTN and translate on each of the 6 trunk CSS inbound. The user ends up with a single DN internally but up to 6 x DDIs which point to it. Wherever the call comes in it will ring that user.

We need to maintain 4 digit dialling across all users regardless of where they are located - its a global firm and people move around a lot. So one day NY next day London. They want to log in & have four digit dialling across the entire organisation.

So, the only unique identifier which is companywide is their own login ID they use on their internal systems. All of these are in the range 1xxx and they want to use this as the 4 digit extension.

To confirm, when I mention "site code" this isn't entirely accurate - its just a histrocial description. All these users are effectively in one site - they all have a site ID based on network VRF (101), so one of my users will be 81011001 and another will be 81011004 despite the fact that one may be in Tokyo and the other in London. In future if they have a different part of the business with a differnet VRF then those users will be 8102xxxx.

It's a peculiar requirement I agree hence posting it up here for discussion.