Introduction
The following document helps to understand the Cisco ICM Parent child deployment model.
What is Parent Child Deployment and what are the objectives of this deployment.
Parent child deployment is like combination different contact centers means parent itself is a contact center and at the same time it will connect to different child contact centers and do the routing of incoming calls and child itself also can do the routing with out parent.
The objectives of this deployment are
1) Site Managing and Survivability :
- Prior to Parent/Child, if a UCCE customer lost their WAN between their central site and local sites all IP call centers with lost connectivity went down
- With Parent/Child each site is its own autonomous call center. If it loses connection to the parent, it keeps functioning (Just like a legacy ACD); if calls aren't carried over their WAN calls can even still be routed to the sites if scripted to do so (just like TDM also)—this could be done by % routing in the Enterprise ICM script for example if it detects the peripheral is off-line
- Parent/Child allows local administration of the call center configurations, etc. without access to the entire enterprise configuration
2) Scalability :
- With Parent/Child, to the parent, the child looks like a TDM ACD, and the child performs its own agent level reporting, not the parent—allowing the parent to scale much higher across the enterprise .
How to configure a Parent Child Deployment model in contact center
Parent child deployment requires system pg in child side and gateway PG (ACMI PG) on parent side.
-> when compare with other PG's system pg has little difference .The System PG combines the VRU peripheral(s) and CM peripheral (by OPC) so all events, requests, etc. appear to come from a single peripheral and have a single consistent PeripheralCallKey (i.e. one CM Peripheral and four VRU
peripherals look like one peripheral to the router, CTI, etc.)
Auto Configuration in parent child
During Startup the Gateway PG (ACMI ) pulls up the configuration from the child and compares it with the parent DB if any differences are there then those changes will be updated to parent DB.
The following configuration will get updated from child to parent.
| Child |
Parent |
Note |
| Agent |
Agent |
|
| Skill group |
Skill group |
|
| Call Type |
Service |
(This is for reporting purpose) see the reporting guide for more information
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_10_0_1/User/Guide/UCCE_BK_RD68866D_00_reporting-guide-icm-cce-hosted/UCCE_BK_RD68866D_00_reporting-guide-icm-cce-hosted_chapter_010100.html#UCCE_RF_C5946D58_00
|
Callflows
In parent child we can do different kind of callflows.some are explained below
1) Parent initiated
2) Child initiated Parent Routed
Parent initiated Callflow :
1) The call comes from the PSTN -> Ingress GW -> Parent CVP -> Parent Router
2) Once it reaches parent router based on the configuration the temporary label will be returned to parent CVP and the permanent label goes to acmi pg
3) From Parent CVP it will goes to Child CUCM
4) And in child side create this label as Dial number and enable PAR (Permit Application Routing)
5) Now the Permanent label will reaches child PG
6) And this is also created as dial number in child system and script will be assigned to this dial number. And call lands on appropriate agent.
Child initiated Parent Routed :
In this callflow call comes into the child environment but for routing decision the call will be redirected to parent system. This can be achived by enabling the PermitApplicationRouting(PAR) for DialNumber in child environment.
1) The Call is transferred from the Child PG -> CTI Serevr ->ACMI PG ->Parent Router
2) The same Dial Number(which is in child) should be configured as dilnumber in parent environment for ACMI
3) Once it reaches parent router based on the configuration it will return the label to ACMI routing client ,which sends back to child
4) In child side create this label as dial number and assign script for this dial number.And calls lands on appropriate agent.
Child Originated and Child Routed :
This callflow is just like enterprise callflow. In this scenario the parent is used for reporting purpose ,parent don't take any routing decisions. The callflow in this is as follows.
1) Callcomes to child router based on the configuration it will return the label to the appropriate routing client and call lands on agent.
parent recevies the event about agent states continuously.so that it won't reserve the same agent for some other call.
Hope this document helps some one to understand about the parent child deployment.
