BLF, directory extension format and attendant console

[gpworld]

Ok so I have a question.

For several years the push to globalized/normalized dial-plans has been pushed and recommended.  This includes the population of directory numbers on the extension itself within CUCM.   However, in the infamous wisdom of those who program many features such as BLF, they have MISSED the target big time.  I have yet to see in my many years a directory populated with a full e164 number or ten digit number in North America that is formatted like this +14035551212.  However, i have seen various versions ... +1 (403) 555-1212, +1 403 555 1212, +1.403.555.1212 etc. 

So my question is this why on earth do we have to make the directory field in CUCM (which gets synced to CUxAC) match the +14035551212 format?  It seems absolutely ludicrous that we are forced into a formatting that NO ONE uses!

In previous versions even as late as CUEAC 8.6 and CUCM 8.6 Cisco TAC had a fix that allowed both the operator to have a + in the extension and for the directory to use the format +1.403.555.1212.  Upgrading to 9.1 on either application BREAKS this completely.

Anyone have a fix that does NOT involve screwing with a proper e164 dial-plan?

Thanks in advance ...

[Jonathan Schulenberg]

However, in the infamous wisdom of those who program many features such as BLF, they have MISSED the target big time

What native CUCM feature doesn't work with +E.164? The only one I can think of off hand is park slots.

North America that is formatted like this +14035551212.  However, i have seen various versions

There is a standard called ITU-T E.123 (no, really) that states the proper format is +1403 555 1212. Any other countries outside of NANP just put a space between each section (e.g. +22 607 123 4567). Personally, I have been leaving it all in one whitespace-free string as you mentioned above since it cuts out a potential problem for Jabber. Any whitespace needs to be predictable across all numbers in LDAP, which introduces human error factor, and then a number mask built in the jabber-config.xml file.

why on earth do we have to make the directory field in CUCM (which gets synced to CUxAC) match the +14035551212 format?

Having an +E.164 formatted value is considered best practice because it's the globally unique format and should be dialable without ambiguity. You can put a NANP-localized 10-digit value in the directory if you want; however, then you'll need a translation pattern to accept this style of input. This will in turn typically lead to T.302 digit overlap issues.

So now we're at your CUxAC problem and I can't quite make out what it is. Can you expand on it further?

Please remember to rate helpful responses and identify helpful or correct answers.

[gpworld]

Hi Jonathan, thanks for your reply and first off, who knew? LOL

I just had a quick read through of the doc but still does not explain why at minimum white spaces are not acceptable in the directory for a telephone numbers presentation.  When anything other then spaces was used to logically separate a number for presentation puproses, BLF for lists breaks.  In conjunction with this, in CUxAC if the directory field for the telephone number does not match exactly the line extension (I.e., Directory = +14035551212 vs. +1 403 555 1212 or any other format) BLF does not work.

I may be naive but would think a simple regex type field that takes the directory number and simply ignores special characters (other then the +) would make it MUCH more functional.  Additional, the BLF feature in CUCM should do the same thing thus normalizing any presentation of the number to the application for resolution of BLF state.

Additionally, CUxAC does not support + on the operator extension in v9.x nor does it / or ever has supported it on the CTI RP or CTI ports (much like UCCX which is a whole other conversation we could have). 

I do understand that we cant put everything into every application version, but seems to me that someone missed the mark big time when it comes to support for e164 in Cisco apps.  Simple things like MWI still do not support the + nor do the voice mail ports.

Feature parity across applications needs to be a focus.  As this is where Cisco missed the mark with Jabber and is 2 years too late when the product finally has teeth.