Need to know IPCC enterprise and ipcc system difference

Unanswered Question
Oct 1st, 2008

Hello Experts. Can any body give the answer to this question in detail

what is the differences between IPCC Enterprise and System IPCC when deployed with ICM software


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
rbua Wed, 10/01/2008 - 02:03

Hi Gem,

System IPCC is an easy to deploy solution with a specific set of boundaries in terms of setup and deployment model(basically it is in some way a trim down version) of the IPCC Enterprise solution.



esa786_2 Wed, 10/01/2008 - 02:14

Hi Riccardo. Thank you for your quick reply.if you do not mind, can you explain little more. when i should use SYSTEM IPCC and when should i use IPCC Enterprise.Both are having same features? Or it is based on number of users supported? or it is based on more feature in IPCC Enterprise? if so can u tell me little more. It will be useful for many people like me.



rbua Wed, 10/01/2008 - 02:42

Hi Gem,

system IPCC specification are available here:

In any normal scenario unless you need specific call flows you would go for System IPCC, for the scenarios involving complexity, specific call flows and so on you would pick IPCC Enteprise, by example if you have a mixed environment TDM/ACD and CUCM or if you are using CVP.

Possible reason to use system PG is if you are looking to deploy a parent/child PG.

A typical Enterprise customer would use Parent/Child for two reasons:

1. Scale - to scale a single contact center design beyond the "limits" of a "classic" UCCE deployment

2. Local survivability - to be able to install a local or nodal UCCE instance that is not dependant on equipment at any other site or location but can be integrated into the larger virtual contact center context with ICM and CVP. This also gives some "like-for-like" value of having an isolated ACD the way a more traditional legacy ACD would be deployed as well.

In this model, the "child" is a complete UCCE with a Call Router/Logger (deployed as a Rogger) and also has its own System PG to control the local UC Manager and IP-IVR. The ICM Parent connects to the "child" System PG using a Gateway PG -- collecting "auto config" and event data to be used for routing and reporting at the Parent ICM.

This model allows the Parent ICM to support multiple UCCE Child (and UCCX as well) connections via the Gateway PGs-- each Child having one (and only one) System PG and UC Manager cluster and local queue points. However, each UCCE child is limited to 2,000 agents (with CTI OS/no mobile agent nor outbound), and the Parent ICM is limited to the number agents and PGs it can support based on the hardware deployed.

An outsourcer who wants to use UCCE to provide services to their clients might opt to build out a "classic" UCCE but use the System PG model to allow their clients to connect a PG from their ICM to the platform to look like any other ACD in their ICM environment. This changes the way the UCCE would operate for the outsourcer, having them queue calls for the client company on the System PG's dedicated IP-IVR rather than at a centralized CVP controlled by the "classic" UCCE.

To the client company of the outsourcer, the System PG is connected via a Gateway PG, which makes it look like a "child" to the client's Parent ICM. The Parent ICM can be configured to collect "auto config" data (or not) and will get event data from the System PG for routing and reporting.

In this model, the outsourcer can have multiple System PGs connected to the "classic" UCCE Call Router -- up to the limits of the scale of the UCCE model.

In both cases, where an ICM Parent is defined to connect to the "child" System PG--the limit of the number of "child instances" that can be connected is bounded by the number of agents the ICM platform can support and the number of PGs that would take within the limits of the system.

For example, if a customer wanted to build out a design with 20,000 agents -- they would use Parent/Child. The Child systems would be built with up to 2,000 agents per "child" (as per the design guide/sizing) and that would take 10 Gateway PGs on the Parent to support that. If the Child systems have other features (outbound, mobile agents, etc.) that reduce the capacity of the child, we would be able to increase the number of PGs to support the additional required child systems.



esa786_2 Wed, 10/01/2008 - 03:41

Riccardo. Thank you for your reply with the link. It is very useful.




This Discussion