I am curious about what would be the best approach to the following scenario:
Two geographically different clusters (CUCM,CCX). ACD calls originally destined to cluster 1 should route to cluster 2 and vise versa in a fail-over scenario or during high call volume/high wait time, etc.
My question is, in order to retain some type of reporting that makes it easily distinguishable this has occurred what would need to be done? My basic instinct tells me nothing super crazy but I am having some doubts so I am just throwing it out there to garnish some ideas from the community.
Please rate useful posts and mark answers as correct if applicable.
Gotcha. If you already have HA enabled over LAN / WAN, then you should be covered from a system failover standpoint. If you haven't already, you should enable DRS and schedule regular backups. But, if you wanted to manually redirect callers during a failover scenario, then you could;
1. Login to CUCM Admin
2. Navigate to Device > CTI Route Point > click 'Find' > select Extension(s) > Call Forward settings
3. Enter a Destination and CSS for "Forward All"
Again, this would be used to redirect all inbound calls during the unlikely event UCCX was completely down. In this case, you would pull CDRs from CUCM to determine the call volume. The other option would be "Forward on CTI Failure" but you could inadvertently redirect callers IF the connection fails. Again, you shouldn't worry about another level of redundancy.
As far as redirecting callers based on current queue times, estimated queue times, or agent availability shouldn't be that difficult. You would simply use the Get Reporting Statistics step to determine the Current Wait Time or Expected Wait Time. Same concept for Logged-In Resources or Ready Resources. With these statistics, you can use IF or Switch Statements to alter the path of the call. If there's too many calls in queue, then go this way.
What happens next, well, that really depends on how you want to report this call event. When a call is queued, the call will be counted as 1x presented. You can 1) dequeue the call which is reported by a couple of CSQ based reports. The reports should present this call event as 1x presented, 0x handled, 0x abandoned and 1x dequeued. Or, you can "mark" the call as handled before you redirect the call via Set Contact Info step. This should be reported as 1x presented, 1x handled, 0x abandoned and 0x dequeued. I don't believe you can "mark" a call as handled after you successfully redirect the call but then again, I haven't confirmed that either.
EDIT: You can also set Call Variables and display this data to the "Call Custom Variable Report". It's another way to track where the call came from.
Sucedia que un Supervisor via Finesse necesitaba ingresar a una llamada activa de un Agente, función que se denomina Silent Monitoring, Monitoreo Silencioso.
Cuando queria el Supervisor ingresar por esta funcion salio este error:
Adjunto un documento que muestra a grandes rasgos el procedimiento que le permite a un usuario final acceder al manejo de sus correos de voz usando su Navegador Web.
El componente utilizado fue el Cisco Unity Co...
Luego de un Upgrade de CUCM, version 9.1 a version 11.5, el servicio Extension Mobility Cross Cluster (EMCC) produce falla en IP Phones, ejemplo Cisco 7940.
La falla es que al intentar acceder al servicio de EMCC se ve un mensaje de error en la p...