Dial Plan Expansion

[wpetilli]

I'm sure there are various ways of doing this, but if I was expanding my dial plan to 5 digits would the ASA feature within import 'change extension operation' be a viable method?

I know you can script this using ossi and perhaps using AES as the place to run it, but the ASA interface looks pretty intuitive. I've used the export data and import feature to bulk add a new location aar table and such, but wasn't sure the appetite for a dplan expansion.

 

[kyle555]

I'd almost say build another CM. look in change dialplan analysis - if you have say 41 length 4 ext and then 42 length 4 ext, you're allowed extensions in the 4100s and 4200s

If the leading new digit is a 4, you'd have to have 441 len 5 etc and the system would usually wait for a digit timeout to see if you're dialing 4100 or 44100

You'd need that in there to even start building out stations in that range

And if you're migrating stations you've got, you have to remove them to readd them. Which means turning MWI off, which is a voicemail topic of that's going to be accommodated.

And if you got SIP phones, they depend on dialplan analysis amongst other things as a foundation for PPM, so any change to dialplan analysis = init sync in smgr = no sip feature admin until that's done.

Are they H323? SIP?

 

[wpetilli]

I have 4 regions and the plan was to insert a new region digit in front of the 4 digit number. US - 1xxxx UK 2xxxx etc.. all separate CM's and mostly h.323. Some SIP stations. In the US case I would have thought my only pitfall was any extension currently in the 1xxx range. You're saying I would not be able to have an entry in the dialplan analysis table for 1 length of 4 and 1 length of 5? If that's the case I'd have to remove all the 1xxx extensions first, change the dial plan analysis and then re-add those back as 5 digits? Is there a way to get those remotely logged back in.. perhaps using IP-hoteling where I'd know the mac address? The cha extension station command does flip the extension and it stays logged in. I use that from time to time.

 

[kyle555]

You might be able to, but even if you could have extn 1000 and 11000, buddy dialing 1000 needs to wait the long interdigit timeout.

"The cha extension station command does flip the extension and it stays logged in. I use that from time to time."

That's actually awesome! I did not know that. I'm not sure if it can be trusted based on the warning in the form.

So, presume you have 5 PBXs all with extensions in the 2000 range and you need a leading 2,3,4,5,6
You could just say in UDP that 2 of length 5 is a UDP number that hits AAR and hits a route to the CM at the other end and delete 1 digit in the route pattern to get there.
If you had entries for 2xxxx,3xxxx,4xxxx,5xxxx in UDP in each CM and all picked AAR to a route that dropped 1 digit, you'd route between CMs.
Then in the CM that's now '2xxxx' if its UDP were to say "match 2xxxx, delete 1, net-->ext" then it would convert back down to the 4 digit local extension

Is there a way of avoiding changing extensions? I read you as "the 4 CMs are staying in place".

change extension-station 7878647 Page 1 of 1

CHANGE STATION EXTENSION

Station Name: Kyle Port: S02377

FROM EXTENSION TO EXTENSION
-------------- ------------
Station: 8647
Message Lamp: 8644
Emergency Location Ext: 8647 8647







WARNING: Submtting this form does not update the extension stored
in the station itself. After submitting this command, be sure to
reprogram the station with the new extension.

 

[lopes1211]

You can do it but you'll likely need to reenter the ext on the h323 phones regardless the method. You can pick one available extension...say 1999, and change the dialplan to make 1999xxxx an 8 digit extension range. Use excel and the change ext import to move all of the existing extensions from xxxx to 1999xxxx. You can now clean up misc extensions, then change the dialplan to 5 digits for 1xxxx, 2xxxx, 3xxxx, etc... Then reimport another change ext to change the 1999xxxx numbers to their new xxxxx extensions. Definitely get some good backups 1st in case you hose it.

-CL

 

[bankingguy]

I would suggest to get this in full E164 so you wont be having problems expanding in the future. Provision will do the trick but that one requires extra cost and Avaya's help.

You need to enable the special application feature called calltype analysis location table.
create a new range of extension (say 11 digits? "+1 866-xxx-xxx" without the +)
enable short code dialing to preserve your dialing format
enable display-parameter to make sure same extension length will be seen by the users but on the backend its full E164.

If you have a chance to build another CM core do it, then just re-route the registration.

 

[wpetilli]

@Kyle - Your idea preserves the 4 digit number remaining the same, but my limitation there is Voicemail (non Avaya system). Also, voicemail is one global system for all the CM's. Guess that's good and bad. The VM subscriber number is not a variable number and can only be 4 digits. There is a PBX extension field, which can be a variable length. To take advantage of the expansion... each region being able to assign 10,000 extensions Voicemail has to be extended to the 5 digit length.

When you reference building another CM how does that work with regards to the physical phones remaining logged in? We have thousands, along with remote offices. Those going into discover or floating at a login prompt would probably have me banned from the industry.

 

[kyle555]

When you restore from a backup when your PBX dies - or cause you upgraded - or when you fall to LSP and go back to the main, the extension and security code are cached in the phone.

The phone would only flush them if a call server replied with "that's the wrong password!"

Let's say you scale up voicemail to 5 digit and it has a SIP trunk to SM and from SM to each CM.

So, a MWI ON to 21234 is extension 1234 in NY and to 31234 is for extension 1234 in LA, you can handle that as an adaptation or on the inward trunk treatment.
And, on the way out of each CM to voicemail, you could prepend 2 for NY so it sends "from" 21234 and so on.

All to say, you're not the first person to have this problem and I'm sure many people have added a 5th digit to an enterprise dial plan across many systems while still leaving those systems as 4 digit. And then I'm sure a subset of those people did it all over again to add a sixth

Full e164 is nice - if everyone has a DID - and there's little tweaks to let them dial inside their own location in CM as 4 digit too.

What happens when you get your 9th or 10th pbx? Then you have to think about people dialing 9 to get out or dialing 91234. And when they call 91234, CM will always wait for a timeout in case you were dialing 91-234-555-1000. And god forbid any sites have extensions in the 1100s cause people will be calling maybe 311,411,611,911, etc.

It's all in how you plan your design out and what scenarios you expect that design to accommodate. Maybe you'll never outgrow a 5 digit dialplan.

Or maybe a 7 digit dialplan makes sense. Like, 8xx-1234. The 8xx can represent 99 offices/locations/systems (no 811!). Then you have an enterprise rule that noone ever use 8xxx within their 4 digit dials. Either you dialed 9 to go out or 8 on-net or 1-2-3-4-5-6-7 on your switch or within your location. You still want to leave lots of room for anything that uses extensions - VDNs, etc if you're heavy on CC on anything.

Then you gotta figure that if you got to 1 voicemail globally, the PBXs might get there too, so accommodating for what a huge single CM might look like would probably be worth the time to think about now if you're already thinking about how to change the enterprise numbering.

Even if they stay as standalone systems, it'd be better to express a vision of what 'good' looks like in an end-state and how you're going to get there. That's what you can use your SM routing for and put a shim in to tweak to the old 4 digit dial plans for now and deal with renumbering the systems on their next upgrade. That way it's a bandaid you rip off once when you're expecting some turbulence and have project management resources around an upgrade anyway. And the whole point of tossing that little curveball into the PBX upgrades is to adhere to the new enterprise standard of "this is how we route