how to handle extensions with variable lenghth on UC500

[Michael Hamann]

Hello everybody,

we have a small project for a customer with a uc560 and about 60 Cisco IP Phones. We did several cucme and uc500 projects so far but in this project we have the problem that this special customers has variable length internal extensions which are overlapping. This was no problem with his old Siemens PBX but so far I can´t see a way to implement this with a cisco UC500.

So for example we have the existing und widely known extensions10 and 105.

Creating the ephone-dn´s is no problem dialing the numbers

from onhook state is also no problem. But transfering and dialing offhook always leads the phone to dial

the extension 10 instead of 105.

Is there any chance to get this szenario working instead of explaining the customer that he has to change extensions with his new pbx ?

Any help is greatly appreciated...

Thanks a lot in advance

best regards Michael

[Marcos Hernandez]

You really do not want to have overlapping dialplans in UC500/CME. It leads to a number of problems and feature interaction issues. Please persuade your customer to use different and unique extensions.

Here is something that would help you make your extensions unique, by adding a trailing "*" at the end, which still needs to be dialed. This was proposed as an alternative to those deployments that needed no access code in PBX mode, but it can be adapted to solve your problem. But again, the extra digit will have to be dialed.

https://supportforums.cisco.com/docs/DOC-9787

Marcos

[David Trad · Accepted solution]

Hi Michael,

I have to strongly agree with Marcos on this one, you really should be looking to persuade your client to move to a more user/system friendly extension range. If it is only for a 60 handset deployment then having them in the XXX range is good, if it is going to go much more over that, then a XXXX range would be more suitable. If they are running DID's then you have each extension match the last 3 or 4 digits of the DID number, this way it is easily manageable and identifiable as well

Doing some funky prefixes is only going to create more problems for you down the track, you will come to regret it and it wont be just the client cursing the system, it will be you as well, even though it is not the systems fault.

The first thing I tell clients before deployments is that certain things will change, there will be a learning curve that needs to be accounted for and also factored into staff training/usage, you have to make this clear to them before the system even arrives onsite, otherwise you end up in a pickle jar

Cheers,

David.

[Michael Hamann]

Thank you guys for your support. I was expecting an answer like this and will

now talk to our customer.

Thank you anyway for your hints...

best regards

Michael