1. Interdigit Timeout
2. E.164
3. DN Length
4. Localization and Globalization
5. No Device/Line?!

E.164 seems to be a buzzword lately when it comes to dial plan design. Let’s first define E.164.

The ITU-T developed the E.164 recommendation that defines a standard number format. That format is a global standard of up to 15 digits usually prefixed by a +. (Thanks, Wikipedia.) What does that mean for us? It means that we can define every PSTN-dialable number in a consistent, standard format that guarantees each is unique. Here are some examples of E.164 numbers.

• +16515551234
• +441122334455
• +4904511234567

This standard format is good for the majority of folks in IT who have slight OCD tendencies when it comes to naming standards and documentation in general. The unique part of it helps us when designing a dial plan to avoid unwanted behaviors like interdigit timeout. Recall our discussion of interdigit timeout and leading digits or characters. The E.164 recommendation to use the + char as a prefix means these globally unique strings will not overlap with any other internal dialing patterns.

E.164 sounds great as a potential tool to avoid interdigit timeout, but unfortunately Cisco does not fully support the + char in all UC products. Here’s a quick snapshot (to the best of my knowledge as of 7/20/2013 and UC 9.1):

• UCM – Fully Supported.
  • However, in some fields it requires the + to be escaped. E.g. a DN must be in the format \+16515551234. This is moderately acceptable for an administrator except for the fact that it’s very difficult to keep straight which fields require the escape character and which do not when creating bulk load import spreadsheets. This is entirely unacceptable when the UI designers do not catch this distinction and it slips through to an end user facing location in the /ucmuser User Option web page or in the Queue Status app or elsewhere.
• CUC – Fully Supported.
  • In 9.x. Prior to 9.x the + was only supported in Alternate Extension fields and not the Primary Extension field. CUC 9.x supports the + in the Primary Extension field and evaluates a number with or without the + as the same extension. E.g. If I configure one user with the extension +16515551234 and another with the extension 16515551234 the second user creation will fail due to an overlap (assuming both are created in the same Partition).
• UCCX – Not supported for Agent DNs
  • This is a major problem and needs to be fixed. The common workaround is to create a separate partition in UCM for Agent DNs and configure them without the +, then limit the use of that partition to only necessary CSS’s.
• CER – Partial Support
  • CER can dynamically track phones configured with DNs that include a +. It can route calls from these phones no problem.
  • CER cannot create manually configured phones with DNs that include a +.
  • It also cannot search for a phone by Extension if it includes a +.
  • Finally, it does not support ELINs that include a +.
• IM&P/Jabber – Fully supported