cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2668
Views
5
Helpful
14
Replies

+ sign support for UCCX and Unity Connection

James Hawkins
Level 8
Level 8

Hi,

I am looking at designing a dial plan for a client who has sites in several European countries.

I am toying with the idea of using fully qualified PSTN numbers as directory numbers for phones - e.g. +442081234567

I will be using CUCM 7.1(x) and so should not have any issues doing this for basic phone connectivity but am wondering how other applications will cope with the + sign in the DN.

The apps that will be deployed are Unity Connection 7.1(x) and Unified Contact Center Express 7.0(x).

Can anyone tell me whether these apps support + sign and, if not, what the workarounds are and if such support is roadmapped.

Finally if anyone has any experiences they wish to share with this type of dial plan I would be interested to hear about them.

Thanks

1 Accepted Solution

Accepted Solutions

Jonathan Schulenberg
Hall of Fame
Hall of Fame

CCX does not support E.164 at all according to the BU. Until SR5 introduced CSCtg90305 it worked fine as long as you didn't create E.164-formatted IPCC Extensions. Reporting and CAD display the information properly. You may want to consider this CSS/Partition setup as well: https://supportforums.cisco.com/message/3047257#3047257 I use this combined with E.164 dial plans and it works out well because I can give the user the same extension for both IPCC and normal extensions... or at least they think it's the same which allows returning missed calls and all to work seamlessly.


As for Unity Connections, the limitation is the Extension field which does not support E.164 yet because a user needs to be able to enter the value through DTMF. You can deal with this by assigning the non-E.164 formatted version (e.g. last four digits) and then putting the full E.164 version in the MWI and Alternate Number fields instead.



View solution in original post

14 Replies 14

Jonathan Schulenberg
Hall of Fame
Hall of Fame

CCX does not support E.164 at all according to the BU. Until SR5 introduced CSCtg90305 it worked fine as long as you didn't create E.164-formatted IPCC Extensions. Reporting and CAD display the information properly. You may want to consider this CSS/Partition setup as well: https://supportforums.cisco.com/message/3047257#3047257 I use this combined with E.164 dial plans and it works out well because I can give the user the same extension for both IPCC and normal extensions... or at least they think it's the same which allows returning missed calls and all to work seamlessly.


As for Unity Connections, the limitation is the Extension field which does not support E.164 yet because a user needs to be able to enter the value through DTMF. You can deal with this by assigning the non-E.164 formatted version (e.g. last four digits) and then putting the full E.164 version in the MWI and Alternate Number fields instead.



Jonathan,

Fantastic thanks.

Re. Unity Connection are there ant tricks for getting around overlapping extensions - e.g. where two users have unique E.164 numbers but the same last four digits.

Does +e164 number formatting work for cti ports and route points in version 9.x?, even though you can't really define them on uccx admin.

I'm trying to change it from cucm, cti ports and route point remain registered but i get a jtapi subsystem out of service as soon as i do that.

Have anyone tried this with successfully?

Appreciate your feedback!

Otto

No, its not supported in UCCX 9. Ideally no changes should be done on the CTI ports/route points fromCUCM, it should modified in UCCX.

Please rate useful posts.

Please rate useful posts.

I wonder what the point is to have +E164 CTI Ports if you shouldn't (read: can't) call CTI Ports directly anyway.  The main point of "plus dialing" is to ease the user's interaction with callbacks from the phone directories.  I.e., The CTI Port calls you, then you call it back from your Received call list.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

E.164 to me is also related to simplifying the cucm dialplan (less pt/css, rdps, aar grps, cfur, rp, tp, etc), in addition to what you mention.

My question is related to both cti route points and ports. To me is very convenient having both in a single partition across the board, i.e., no css/pt trickery to reach uccx triggers at least. I was prepared to put agents in a different partitions either way as you dont want them to be directly reachable from anywhere else than uccx scripts.

It seems like they at least thought about supporting it from version 8.5su3 at least. I really thought someone tried with success before. Please check the +sign support slide from cisco live 2012 (BRKUCC-3000) session.

Any comments?

Thanks,

Otto

I have not used UCCX 9x before, so I don't know if you can enter the + in the field for creating CTI Ports.  Good call, and I'd like to see the outcome of that.

My above comment was based on the Cisco Live 2013 Advanced Dial Plan class where the statement is made:

Put non-DIDs (e.g. pick-up numbers) in separate partition and number according to intended dialing habit to  these destinations Why use + to number entities ONLY called as 4XXX?

Granted this is not about CTI Ports, and it mentions Non-DID's; However, that logic suggests you could also ask the question: Why +E164 something if a user is never going to dial it?

I'm still learning, so please feel free to give me feedback on plus dialing.  I claim no expertise in this area.  Thank you.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Alternative: put non
-
DIDs (e.g. pick
-
up numbers) in separate partition and number according to
intended dialing habit to these destinations
“Why use + to number entities ONLY called as 4XXX?”Alternative: put non
-
DIDs (e.g. pick
-
up numbers) in separate partition and number according to
intended dialing habit to these destinations
“Why use + to number entities ONLY called as 4XXX?”

You can definitely not enter +numbers on any uccx configuration screens for uccx 9.0(2)SU1. You can change them in cucm, but it breaks the uccx jtapi subsystem.

To your question, there are some patterns that you definitely want to put on your internal site pt, and only reachable for a single location, in addition there are some patterns that will not support +dialing either way (park, meetme, pickup grps).

However, for cti route points you want them to be global dialable +e164 patterns, same as your cti ports, even though you are "not dialing" directly to them, the device calling needs direct access to the partition where the ctip ports are (so you want to put them where they do not overlap with anything else, i.e., internal global partition in a + dialing format).

It all comes down to ease the cucm configuration and making uccx services globally reachable too. This makes a lot of sense for large cucm clusters with centralized resources.

I guess my only hope is uccx 10.x to come out. Unless someone else has had success making this works (i.e., cti route points and ports in +e164 format)

Thanks,

Otto

Hi,

We have 99% +E164 configuration CUCM clusters running with 1% not being e164, on uccx.
We use e164 translations to the CTI route points which use extensions that are user friendly, non-did according to local internal dialing habits.
The CTI ports also use these non-did extensions.

What bugs me most is the fact that call redirect steps, agent DNs and external phone masks for CTI ports do not support e164. Which requires a lot of css/pt plumbing. Agent dns, because not all 'call centers' are real call centers and adding a second line causes the user not to be busy on their primary line if the agent dn is on a call.

Hoping 10.1 fixes some of these issues. Don't know about 10.0 because that release is already (too) close by.

Regards,
Erik


Sent from Cisco Technical Support iPad App

How do you overcome the fact that internal phones (and general all devices calling uccx) have to have direct access to cti ports PTs without running into overlaps? can you proxy this with a TP? I thought this was not allowed.

I guess you can just put your ports in a range like 10001001 - 10001004 to avoid overlaps.

thanks!

Users do not need access to the CTI port if you configure the CTI RP to be able to call the CTI port. There is a trigger setting in ccx that defines which css is used to redirect to the CTI port.

And what you are suggesting also woks fine; make the port DNs unique by giving them extraordinary long extensions. Assume users have no need to call ports (I usually give them an alerting/display name like 'System' to dis encourage end users to return a missed call.)
And if you really want you can hide these long extensions behind a translation in a user line CSS.

Regards,
Erik

Sent from Cisco Technical Support iPad App

Nice suggestions!,

Thanks!

Just to help others, because I think you brought up a great configuration topic of UCCX (+5 points for that), here is the documentation surrounding this setting, regarding how CTI Ports are "reached": via calling phone, or via CTI Route Point.

Calling Search Space for Redirect

By default, Cisco Unified Communications Manager uses the original calling party's calling search space (CSS) to process the redirected call from a Unified CCX Trigger to a Unified CCX CTI Port. This default behavior requires the partition of the Unified CCX CTI ports to be a member of the original calling party's CSS even if the partition of the CTI Route Point/Unified CCX Trigger is accessible to the calling device's CSS and the CSS of the CTI Route Point/Unified CCX Trigger contains the partition of the Unified CCX CTI Ports.

You can modify this behavior using the drop-down list to instruct Cisco Unified Communications Manager which CSS to use when redirecting the call from the CTI Route Point to the CTI Port.

Calling Search Space for Redirect options:

  • Default Calling Search Space - CSS of the calling device
  • Calling Address Search Space - CSS of the calling device
  • Route Point Address Search Space - CSS of the CTI Route Point (Trigger)

Source: UCCX Administration Guide, Section "Add Unified CM Telephony trigger"

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

Anthony, Erik,

+5 for you guys, this setting makes a lot of sense, I didn't know it was even there, it might have been there for years :). This will ease the uccx deployment on a cucm e164 environment for sure.

Thank you!

Otto

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: