CSS/Partition configuration for UCCX

Unanswered Question
Mar 31st, 2010

The UCCS SRND exlains the call processing well enough:
- a user from a phone dials an application triggger (CTI Route Point)
- UCCX selects an available CTI port and signals its extension to the CM
- CM send the call to that CTI port which kicks off the script and an RTP stream is established betweem user's phone and that CTI port
- script selects an agents and the user is transfered to that agent's phone

What it doesn't explain is the requirements for CSS and partitions for these four call setup participants - user's phone, CTI RP, CTI Port, and agent's phone.
Let's assume they all have different CSSs and partitions:
CSS-User assigned to user's phone and PT-User assigned to user's DN
CSS-CTIRP assigned to CTI RP device and PT-CTIRP assigned to its DN
CSS-CTIPt assigned to CTI Port and PT-CTIPt assigned to its DN
CSS-Agent assigned to agent's phone and PT-Agent assigned to agent's ACD DN

Can some one help me to properly configure CSSs with minimum required partitions?

  - PT-CTIPt (I am guessing tat this is needed for calling the selected CTI port. Is it needed?)
  - PT-Agent (Is it needed?)
  - I have no idea when this CSS is used
  - PT-Agent
  - anything else?
  - I understand that to make outbound calls from the agent's line, we will need some partitions here, but what I am asking here is whether we need any partitions to be able to receive calls.

I received a request from a customer to restrict the users ability to call agents directly and am struggling a bit with CSS/Partition design for that.
At the same time, I would like to get to the bottom of the CSS/Partition relationships for any UCCX setup.

Thanks in advance.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (8 ratings)
Aaron Harrison Thu, 04/01/2010 - 02:50





- PT-CTIPt (Yes - the redirection from the CTIRP to CTI Port is like a take back and transfer in effect. If the origination endpoint can't reach the CTI Port, you get some kind of RouteNotFoundException or something in the MIVR logs and you get busy tone)

- PT-Agent (Not required - the call to the agent is from the CTI Port, so it's like you make a call to someone, who can then transfer you to someone in their CSS which you cannot dial directly)


- Doesn’t seem to matter. Will work without being set. Calls from UCCX in scripts go from the CTI Port.


- PT-Agent (yes)

- anything else (anything else you want to dial - external redirects from scripts, redirects to hunt groups or other extensions, etc, etc)


- If you like, nothing at all.

- They may however want to dial normal things (PSTN/internal/emergency calls) and send calls to other queues etc.


Please rate helpful posts...

Jonathan Schulenberg Fri, 04/02/2010 - 08:10

Here's the way I configure it. This isn't necessarily the best way either; just what makes sense to me and works for my customers.

I create two partitions: CCX_CTI_PT and CCX_Agent_PT.  CCX_CTI_PT contains CTI Route Points and Ports. As Aaron explained, the current CTI behavior requires that the call originator be able to reach the CTI Port the call will eventually be terminated on, not just the CTI Route Point. CCX_Agent_PT includes all of the Agent ICD directory numbers.

I include the CCX_CTI_PT in the appropriate gateway and device CSS so the CCX server can be called. I do not include CCX_Agent_PT in accordance with the SRND recommendation that agent ICD lines cannot be reached directly from outside of the contact center.

Next, I create a CSS for the CTI Route Points and Ports: CCX_CTI_CSS. This contains both the CCX_CTI_PT and the CCX_Agent_PT partitions which allows CCX to reach the agent ICD extensions. Note that I place these two first in the list.  I then include the remaining partitions appropriate to the device-level CSS of the site where the CCX server resides. You may also choose to include block partitions if you want to impose dialing restrictions on the CTI ports of CCX.

Finally, I create a new line-level CSS: CCX_Agent_LCSS. I add the CCX_Agent_PT partition first in this CSS followed by whatever block partitions desired to build the Class of Service for contact center agents (e.g. no international calling). Feel free to create more than one of these if different agents should have different calling privliges. The important point here is that the CCX_agent_PT is first. Doing this allows me to set the ICD directory number to the same number as the user's normal directory number. The advantage to this (in most cases) is that users memorize a single extension for the user. If they dial it from their ICD line, it will remain within the scope of CCX and be properly tracked in Historical Reporting. This has consiquences though. For example, users will not get voice mail or other call forwarding for another contact center user when dialing from their ICD extension; they must manually choose their other line to dial the call. Think this all the way through to ensure it works for your environment before using this trick.

To summarize: There are two partitions (CCX_CTI_PT and CCX_Agent_PT) and two CSSs (CCX_CTI_CSS and CCX_Agent_LCSS).

jsteinberg Wed, 12/08/2010 - 13:34


I like the approach, but this is explicitly listed in the UCCX release notes as an unsupported configuration for agent phones:

  • Two lines on an agent’s phone that have the same extension but exist in different partitions.

from http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_8_0/release/notes/uccx_802_rn.pdf

Have you run into issues with this setup ?

Jonathan Schulenberg Wed, 12/08/2010 - 13:37

Actually this doesn't violate that rule as long as you are doing E.164. The ACD DN is a four-digit DN within UCM while the real DN is the 12-digit (or longer) DN.


  • ACD DN: 2651 in CCX_Agent_PT
  • Real DN: \+16082462651 in Enterprise_PT
jsteinberg Wed, 12/08/2010 - 13:40

light bulb.

Thanks - that makes perfect sense.  I'll think this through, but I like this approach.

Yankovskyi Wed, 08/01/2012 - 02:59

Hi all!

Thanks for your explanation, but I still have one question.

In UCCX 8 in configuration Call Control Group (CTI ports) we have this field Redirect Calling Search Space.

There is three variants: DN CSS; Calling Party; Redirect Party;

I guess that this CSS used in scripts in step Redirect Call.

Can someone explain about Redirect Calling Search Space?


Aaron Harrison Wed, 08/01/2012 - 05:14

Hi Oleksii

It should determine (as you say) the CSS used for the redirect step. In the old world this would use the CSS on the CTI ports.

Now you have choices, that last time I looked were not documented well.


DN CSS - old behaviour, route using CSS on the DN.

Calling Party - use the CSS of the calling device. E.g. you call the script from a phone, use the phone CSS. The call came from a gateway, use the GW CSS. That migth be a problem if (for example) you redirect to an external number, but the GW CSS includes only internal partitions.

Redirect Party - not sure, could be the redirecting or redirected party. Either way, it implies it would be the same as one of the previous two options... unless it refers to the CSS of an intermediate device, e.g. something that forwarded the 'calling party' to the CCX script.

However - I've had reports from others in my team that it doesn't work predictably, i.e. uses Calling Party regardless of what you set. That was on 8.5 SU2 I think...



vincent.morton Fri, 12/28/2012 - 12:35


Thanks for the really helpful post. I've been fighting with this same issue on a 7.1 server. It does look like it is using the inbound gateway CSS regardless of what Redirect Calling Search Space I select. I ended up having to create a partition with a specific route pattern in it and add it to the inbound gateway CSS in order to allow incoming calls to be routed back out to an external number under certain circumstances.

Does anyone know if there is a bugID for this?


This Discussion