The Cisco Unified Mobile Agent feature enables an agent using any PSTN phone and a broadband VPN connection (for agent desktop communications) to function just like a Unified CCE agent sitting in a formal call center and using a Cisco IP Phone monitored and controlled by Cisco Unified Communications Manager JTAPI.
Cisco Unified Mobile Agent uses a pair of CTI ports that function as proxies for the mobile agent phone (or endpoint) and the caller phone (or endpoint). Two CTI ports (local and remote) are required for every logged-in mobile agent, and the two CTI ports take the place of the Cisco IP Phone
monitored and controlled by Unified CM JTAPI. The local CTI port DN is used by the agent at login and is where callers are routed when this agent is selected. The remote CTI port calls the agent either at login for a nailed connection or upon being selected for a call-by-call connection. Then,
by using media redirection, the CTI ports signal for the two VoIP endpoints to stream RTP packets directly, with no further involvement from the CTI ports until further call control (transfer, conference, hold, retrieve, or release) is required. Any subsequent call control must be performed
from the agent desktop application. The PG transmits the necessary subsequent call control via JTAPI to Unified CM for the two CTI ports to do whatever is needed to the media of the call (see the figure below).
Figure 1. Cisco Unified Mobile Agent Architecture
The two CTI ports (local and remote) are logically and statically linked within the PG software by using the documented naming convention required. The CTI Ports are registered at PG initialization. Call observers are added for these two CTI Ports when a mobile agent logs in using these CTI
Ports. Call control for the CTI Ports (and thus the call) is provided by the PG. As mentioned earlier, the voice path is between the two Voice Gateways.
When a mobile agent is in the office, the agent can log in as a non-mobile agent from a JTAPI monitored and controlled phone, using the same agent ID. (This document refers to these non-mobile agents as local agents.) Historical call reporting does not distinguish between calls handled as a
mobile agent and those handled as a local agent.
Queuing calls to mobile agents is supported with both Unified CVP and Cisco Unified IP IVR.
With Cisco Unified Mobile Agent, administrators can configure agents to use either call-by-call dialing or a nailed connection, or the administrator can configure agents to choose the connection mode at login time.
In call-by-call dialing, the agent’s remote phone is dialed for each incoming call. When the call ends, the agent’s phone is disconnected before the agent is made ready for the next call.
A basic call flow for this type of dialing is as follows:
At login, a mobile agent specifies their login name or agent ID, password, a local CTI port DN as the instrument (CTI OS) or extension (Cisco Agent Desktop), and a phone number at which to call them. This CTI port DN must be selected carefully by an administrator based on the
A customer call arrives in the system and is queued for a skill group or an agent through normal Unified CCE configuration and scripting. This processing is the same as for local agents.
When an agent is selected for the call, and if the agent happens to be a mobile agent, then the new processing for mobile agent begins. The Unified CCE CallRouter uses the directory number for the agent’s local CTI port as the routing label.
The incoming call rings at the agent's local CTI port. The Agent PG is notified that the local CTI port is ringing but does not answer the call immediately. The caller will hear ringing at this point.
Simultaneously, a call to the agent is initiated from the remote CTI port for the selected agent. This process might take a while to complete, depending on connection time. If the agent does not answer within the configured time, RONA processing is initiated.
When the agent answers their phone by going off-hook, this second call is temporarily placed on hold. At that time, the original customer call is answered and directed to the agent call media address. The agent call is then taken off hold and directed to the customer call media
address. The result is an RTP stream directly between the two VoIP endpoints.
When the call ends, both connections are disconnected and the agent is set to ready, not ready, or wrap-up, depending on agent configuration and agent desktop input.
If the agent phone is configured with voicemail, disable voicemail to allow RONA call processing to occur.
With call-by-call connection, an agent must answer the phone by going off hook. The Answer button on the agent desktop will not be enabled.
Auto-answer is not possible with call-by-call connections because there is no call control mechanism to make the mobile agent phone go off hook.
In nailed connection mode, the agent is called once at login, and the line stays connected through multiple customer calls.
A basic call flow for this type of connection is as follows:
At login, a mobile agent specifies their agent ID, password, a local CTI port DN as the instrument (CTI OS) or extension, and a phone number at which to call them. The administrator must preselect the CTI port DN based on the agent's location.
The remote CTI port statically associated with the local CTI port used at login initiates a call to the phone number supplied at mobile agent login. When the agent answers, the call is immediately placed on hold. The agent is not considered logged in and ready until this process completes.
A customer call arrives in the system and is queued for a skill group or an agent through normal Unified CCE configuration and scripting. This process is the same as for local agents.
When an agent is selected for the call, and if the agent is a mobile agent, the new processing for a mobile agent begins.
The incoming call rings at the local CTI port that the agent uses at login. The JTAPI gateway detects that the CTI port is ringing, but does not immediately answer the call. The caller hears ringing at this point.
The agent's desktop indicates that a call is ringing, but the agent phone does not ring because it is already off hook. If the agent does not answer within the configured time, RONA processing is initiated.
When the agent presses the Answer button to accept the call, the customer call is answered and directed to the agent call media address. The agent call is then taken off hold and directed to the customer call media address.
When the call ends, the customer connection disconnects and the agent connection is placed back on hold. The agent is set to ready, not ready, or wrap-up, depending on agent configuration and agent desktop input.
A nailed connection mobile agent can log off by using the desktop or by just hanging up the phone.
Auto-answer is allowed with a nailed connection.
The following two Unified Communications Manager timers can terminate a mobile agent nailed connection call:
Maximum Call Duration timer (the default value is 720 minutes)
Maximum Call Hold timer (the default value is 360 minutes)
This termination can log out a nailed connection mobile agent. To keep the mobile agent logged in, set the values for both of these timers to 0 so these timers never expire. To configure these timers, use the Unified Communications Manager Administration web page for service parameters using Unified Communications Service.
In a deployment with a firewall, if an agent in a nailed connection mode is idle longer than the firewall idle timeout value, the firewall can block the media stream when the firewall idle timeout expires. To prevent the firewall from blocking the media stream, increase the firewall idle timeout value.
Mobile Agent Connect Tone for Nailed Connection Mobile Agent
The Cisco Unified Mobile Agent connect tone provides an audible indication when a call is delivered to the nailed connection mobile agent. The connection tone is two beeps, which the nailed connection mobile agent will hear upon answering a call. This feature is turned off by default; for information about how to enable the Mobile Agent connect tone, see the Cisco Unified Contact
Center Enterprise Features Guide
Supported Mobile Agent and Caller VoIP Endpoints
Cisco Unified Mobile Agents can log in to Unified CCE using any PSTN phone that gets routed to a Cisco Voice Gateway. You can register that Voice Gateway with the same cluster as the associated Agent PG or with another cluster. In addition to using a
phone, a Cisco Unified Mobile Agent must use an agent desktop application.
Any Voice Gateway supported by Unified CM and Unified CCE is supported for mobile agents. You can configure caller (ingress) and mobile agent (egress) Voice Gateways with either H.323, MGCP, or SIP. A combination of Voice Gateway types is also supported. If supervisory Silent Monitoring is not required, the ingress and egress Voice
Gateways can be the same Voice Gateway.
Cisco Unified Mobile Agents can also log in using a Cisco IP Phone. The IP Phone can be configured for SIP or SCCP, and a mixture is also allowed. You can register this IP Phone with the same cluster as the associated Agent PG or with another cluster. Calls to mobile agents can also originate from SIP or SCCP IP Phones.
For improved Unified Communications Manager performance, configure agents with IP Phones on the same cluster as the associated Agent PG to use Extension Mobility instead of the Unified Mobile Agent feature. Because the IP Phone device is associated with
the JTAPI user, there is a small performance hit on Unified Communications Manager for making that association.
In the following figure, Voice Gateways 1A and 1B both register with cluster 1, and Voice Gateway 2 registers with cluster 2. The call arrives into ingress Voice Gateway 1A and can be routed to any of the four agents. Mobile agent 4’s IP phone (not monitored and controlled by JTAPI) registers with
cluster 2, and there is no PG for cluster 2. If Silent Monitoring of mobile agent 3 is required, then a Silent Monitoring server must be deployed for agents connecting through Voice Gateway 2.
Figure 2. Mobile Agent Call Scenarios
Consider the following factors when designing an Unified Mobile Agent solution:
If you use SIP trunks, configure Media Termination Points (MTPs). This requirement also applies if you use TDM trunks to interface with service providers. For detailed information, see Cisco Unified Contact Center Features.
Enabling the use of an MTP on a trunk affects all calls that traverse that trunk, even noncontact-center calls. Ensure that the number of available MTPs can support the number of calls traversing the trunk.
The pair of CTI ports being used by a mobile agent must be configured in Unified CM with the same location as the agent’s VoIP endpoint. Because a CTI Port is a virtual type of endpoint, it can be located anywhere. System administrators need to be careful to set the proper location for
the mobile agent CTI ports. Call center supervisors also must ensure that the CTI port pair assigned to a mobile agent is in the same location with the Voice Gateway (or VoIP endpoint) that will call the agent. If the location for the CTI ports is set incorrectly or if a mobile agent is
assigned a CTI port pair with a different location than the Voice Gateway that will call the mobile agent, then call admission will not be accounted for correctly.
For example, assume Mobile Agent 3 in Figure 1 wants to be called at 972-2003, and the dial plans for Unified CM clusters 1 and 2 are configured to route calls to 972-2003 through Voice Gateway 2. Under
normal operations, Agent 3 must log in using a CTI Port pair configured with the same location as the inter-cluster trunk from Cluster 1 to Cluster 2. This configuration would allow for call admission control to properly account for calls to this mobile agent across VoIP WAN 2. If Agent
3 were to log in using a CTI Port pair with the same location as Voice Gateway 1B, then call admission control would incorrectly assume that the call was traversing VoIP WAN 1 instead of VoIP WAN 2.
Call admission control sees this mobile agent call as two completely separate calls. Call leg 1 is the call from the caller to the agent’s local CTI port, and call leg 2 is the call from the remote CTI port to the agent. Because the CTI ports are in the same location as the agent
endpoint, call admission control counts only the call from the caller location to the agent location (just like a normal call). This is why it is important for an agent to use CTI ports for their current location.
From the perspective of call admission control locations for the mobile agent CTI ports, there are three deployment scenarios. In the indicated figure, Agent 1 needs to use CTI ports configured in the same location as
the egress Voice Gateway (Voice Gateway 1B) that will call the agent. Agent 2 needs to use CTI ports configured in the same location as the ingress Voice Gateway (Voice Gateway 1A). Agents 3 and 4 both need to use CTI ports in the same location as the inter-cluster trunk from Cluster 1
to Cluster 2. For each location possibly used by mobile agents, there must be a pool of local and remote CTI ports. The three pools of CTI ports shown in the indicated figure are co-located with the VoIP
endpoint type for the agent (Voice Gateway or IP phone).
Callers and agents can also use VoIP endpoints on another Unified CM cluster. As shown in the indicated figure, this configuration would allow agents in remote locations to be called from local Voice Gateways that are
associated with a different Unified CM cluster. However, a monitoring server is required at the remote site with the agent (egress) Voice Gateway if Silent Monitoring were required.
As mentioned in the previous section, the Unified CM dial plan must be configured in such a way to ensure that, when the remote CTI port calls the phone number supplied by the mobile agent at login, it routes to a Voice Gateway in the same location as the mobile agent CTI ports.
Otherwise, call admission control accounting will not work correctly.
Another possible design for the Unified CM dial plan is to configure it so that all calls from the CTI ports go through a specific gateway regardless of what phone number is being called. This configuration is desirable if you want a dedicated gateway for mobile agents to use. It is more
easily managed, but it is not necessarily the most efficient configuration from the perspective of PSTN trunk utilization.
If you want a caller to hear music when a mobile agent places the caller on hold, assign Music on Hold (MoH) resources to the ingress Voice Gateway or trunk that is connected to the caller, as you would do with traditional agents. The user or network audio source is specified on the local
CTI port configuration. Likewise, if you want a mobile agent to hear music when the agent is put on hold, assign MoH resources to the egress Voice Gateway or trunk that is connected to the mobile agent. In that case, the user or network audio source is specified on the remote CTI port
Do not assign MoH resources to local and remote CTI ports because it is unnecessary and might have some performance impact on the system.
A Mobile Agent remote call over a nailed connection is put on hold when there is no active call to the agent. In general, enable MoH to the mobile agent phone for nailed connection calls. If MoH resources are an issue, consider multicast MoH services.
If MoH is disabled for the nailed connection mobile agent remote phone device associated to the call, it is possible that hold tone is played to the agent phone during the hold time, depending on the call processing agent that controls the mobile agent remote phone. For Unified CM, the
hold tone is enabled by default and is very similar to the Mobile Agent connect tone. With the Unified CM hold tone enabled, it is very difficult for the agent to identify if a call has arrived by listening for the Mobile Agent connect tone. Therefore, disable the hold tone for Unified
CM by changing the setting of the Tone on Hold Timer service parameter on Unified CM. For details on setting this parameter, see the Unified CM product documentation available at cisco.com.
Media streams between the ingress and egress Voice Gateways can be g.711 or g.729, but not a mix, because all CTI ports for a PG must advertise the same codec type. This requirement could result in g.711 (instead of g.729) calls being sent across the WAN. If most calls are routed to
agents in the same location as the ingress Voice Gateway, then sending a few g.711 calls over the WAN might not be an issue. The alternative is to make all mobile agent calls be g.729. If a very large portion of all Unified CCE calls will always cross a WAN segment, then it probably
makes sense to have all CTI ports configured for g.729. However, it is not possible to have g.711 for some mobile agent calls and g.729 for others. A dedicated region is required for the CTI ports to ensure that all calls to and from this region will use the same encoding format.
From the perspective of Silent Monitoring, the CTI OS Supervisor Desktop can silently monitor g.711 or g.729. All mobile agents would have to use the same codec, but local agents on the supervisor's team could use a mix of codecs.
For additional information about codec design considerations, see the media resources information in the Cisco Unified Communications SRND.
MTP resources might be required for mobile agents who is consulting an IVR or other network component that requires DTMF to navigate. The Mobile Agent feature relies on Cisco Unified CM CTI ports, which do not support in-band DTMF (RFC 2833). If the endpoints being used by mobile agents supports only in-band DTMF (or if they are configured to use in-band DTMF per RFC 2833), then Unified CM automatically inserts MTP resources because of the capabilities mismatch. If the mobile agent call flow requires in-band DTMF (RFC 2833), make a sufficient amount of MTP resources available.
Cisco Unified Border Element Considerations with Mobile Agent
Some SIP devices such as the Cisco Unified Border Element or other Session Border Controllers could dynamically change the media port during the call. In this case, if the Mobile Agent feature is used, MTP resources are required on the SIP trunk connecting to the agent endpoint.
Cisco Unified Mobile Agent Interfaces
IP Phone Agent (IPPA) is not an applicable agent interface for mobile agents. IPPA is available only from JTAPI monitored and controlled phones that support XML applications.
The latest release of Cisco Agent Desktop supports mobile agents. At agent login, if the mobile agent mode is selected, the mobile agent login dialog box is presented to the agent. The mobile agent must provide the local CTI port extension, a call mode, and a dialable phone number.
Figure 3. Mobile Agent Login
The phone number supplied must route to a VoIP endpoint (Voice Gateway, IP phone, or inter-cluster trunk) in the same location as the CTI port pair used by the agent. Otherwise, call admission control will not work correctly.
A supervisor using Cisco Supervisor Desktop (CSD) can view the state and real-time statistics for a mobile agent using Cisco Agent Desktop (CAD). A supervisor using Cisco Supervisor Desktop can also barge-in and intercept calls of mobile agents using Cisco Agent Desktop. A supervisor using
CSD cannot manage agents (view statistics, Silent Monitor, record, barge-in, or intercept) using CTI-OS Toolkit applications.
Cisco Agent Desktop Silent Monitoring and Recording
The latest release of Cisco Supervisor Desktop (CSD) can silently monitor and record mobile agents using Cisco Agent Desktop SPAN Port Monitoring of the mobile agent Voice Gateway. However, Cisco Unified Mobile Agent does not support the use of Unified Communications Manager Silent Monitoring.
The Cisco Agent Desktop SPAN port monitor server provides a mechanism to access an agent’s RTP stream when desktop monitoring is not possible (primarily for Cisco Agent Desktop mobile agents, Cisco Agent Desktop IP Phone Agents, or agents using lower-end IP phones without a data port for connection to the agent workstation). When a
supervisor clicks the Silent Monitor button on the CSD application, the CSD application requests the SPAN port monitor server for that agent to forward a copy of both RTP streams for that agent to the CSD application. The CSD application then blends the two RTP streams and plays the
resulting audio stream to the supervisor through the supervisor workstation speakers. Silent Monitoring uses two one-way RTP streams flowing from the SPAN port monitor server to the CSD workstation.
If the supervisor using CSD wants to record an agent using Cisco Agent Desktop, then the supervisor clicks the record button and the CSD application requests the recording server to request the appropriate SPAN port monitor server to forward a copy of both RTP streams to the Cisco Agent Desktop recording server to be
saved onto disk. An agent can also request for a call to be recorded by clicking the Record button (if enabled) on their Cisco Agent Desktop application. Clicking this button also sends a request to the recording server to request the appropriate SPAN port monitor server to forward a copy of both RTP
streams to the recording server to be saved onto disk. When recording, there are two one-way RTP streams flowing from the SPAN port monitor server to the CAD recording server.
Cisco Agent Desktop SPAN Port Monitoring of the agent Voice Gateway is somewhat different than Cisco Agent Desktop SPAN Port Monitoring of local agent Cisco IP Phones. When SPANning a LAN segment with JTAPI monitored and controlled Cisco IP Phones being used by Unified CCE local agents, the Cisco Agent Desktop SPAN Port Monitoring
software is searching for RTP packets with the MAC address of the local agent’s Cisco IP Phone. When SPANning a LAN segment with mobile agent Voice Gateways, the Cisco Agent Desktop SPAN Port Monitoring software is searching for RTP packets to and from the agent Voice Gateway IP address and port.
A single Cisco Agent Desktop SPAN port monitor server can SPAN a network segment with both local agent Cisco IP Phones and multiple mobile agent Voice Gateways. The Cisco Agent Desktop SPAN port monitor server is intelligent enough to find an agent’s RTP stream, whether it is a local agent using a Cisco IP Phone or a
mobile agent connected through an agent Voice Gateway. With Cisco Agent Desktop, a single deployment for a PG instance can support up to five Cisco Agent Desktop SPAN port monitor servers. Voice gateways are statically mapped to a specific SPAN port monitor server, and multiple agent Voice Gateways can be mapped to
the same SPAN port monitor server (assuming the network SPAN is set up accordingly). Unlike local Cisco Agent Desktop agents (which are statically associated in Cisco Agent Desktop administration to a SPAN port monitor server), mobile Cisco Agent Desktop agents are not mapped to a specific SPAN Port Monitoring server. Therefore, when
a Cisco Agent Desktop agent (who is not using desktop monitoring) is a local agent, they must be using an IP phone on the appropriate LAN segment that is being SPANned by their associated SPAN port monitor server. However, when that same agent is logging in as a mobile agent, there is no need to worry
about which Voice Gateway or SPAN port monitor server is used to gain access to the RTP streams.
The Cisco Agent Desktop SPAN port monitor server must run separately from the agent PG, and one virtual NIC must be connected to the SPAN port of a Cisco Catalyst switch to capture the RTP streams. A second virtual NIC interface on the SPAN port monitor server is also required to communicate with other Unified CCE
components such as the CSD and the Cisco Agent Desktop recording server. There is no redundancy for SPAN port monitor servers.
Virtualization of Cisco Agent Desktop Silent Monitoring was tested only on UCS-C series servers.
The Cisco Agent Desktop SPAN port monitor server supports both g.711 and g.729 RTP streams, but it cannot support encrypted RTP streams.
Cisco Agent Desktop SPAN Port Monitoring of the ingress (or customer) Voice Gateway is not supported. Cisco Agent Desktop SPAN Port Monitoring of mobile agents using Cisco IP Phones is also not supported. For SPAN Port Monitoring to work, calls must pass through an egress (or agent) Voice Gateway, and the egress Voice
Gateway must be a different Voice Gateway than the ingress Voice Gateway.
The latest CTI OS releases support mobile agents. To use the Mobile Agent feature, the system administrator must enable the mobile agent while running the CTI OS setup program during or after installation. The CTI OS agent desktop will contain the Mobile Agent checkbox only after the mobile
agent is enabled.
At agent login, if the mobile agent mode is selected, the CTI login dialog box is presented to the agent. The mobile agent must provide the local CTI port extension as the instrument, select a call mode, and provide a dialable phone number.
Figure 4. CTI OS Login
The phone number supplied must route to a VoIP endpoint (Voice Gateway, IP phone, or inter-cluster trunk) in the same location as the CTI port pair used by the agent. Otherwise, call admission control will not work correctly.
A supervisor using the CTI OS supervisor desktop can view the state and real-time statistics for a mobile agent using CTI OS agent desktop. A supervisor using the CTI OS supervisor desktop can also barge-in, intercept, and Silent Monitor calls of mobile agents using the CTI OS agent desktop.
CTI OS does not provide agent call recording.
Supervisors can use
silent monitoring on mobile agents with CTI OS desktops. The CTI OS Silent
Monitoring service runs on a separate virtual machine for performance reasons.
The virtual machine requires a dedicated virtual NIC connection to a SPAN port
on a Cisco Catalyst switch and a second virtual NIC connection to carry the
Unified CCE public network traffic. The Catalyst switch can SPAN a VLAN segment
with either multiple ingress Voice Gateways (VG) or multiple egress VGs. The
VLAN segment cannot include both types of VGs. A second virtual machine runs
the CTI OS Server with the standard two virtual NICs, one for the Unified CCE
public network and the other for the Unified CCE private network.
CTI OS provides a
method for a supervisor to silently monitor a mobile agent using the CTI OS
agent desktop. CTI OS includes a Silent Monitoring service that runs on a
separate VM. The Silent Monitoring service for mobile agents requires a NIC
interface on the physical CTI OS Silent Monitor server to be connected to a
SPAN port on a Cisco Catalyst switch. The Catalyst switch can SPAN a VLAN
segment with multiple ingress or egress Voice Gateways, but not both. For more
information about SPAN-based Silent Monitoring for CTI OS, see the
CTI OS System Manager Guide
for Cisco Unified ICM/Contact Center Enterprise & Hosted.
Most Cisco Catalyst
switches allow the destination port of a SPAN configuration to act as a normal
network connection. However, some Cisco Catalyst switches do not support
network traffic on the SPAN destination port. On those switches, because the
server NIC interface connected to the SPAN port cannot be used for
communications with supervisor desktops and other Unified CCE components, a NIC
interface must be dedicated for connection to the SPAN port. In redundant
Unified CCE installations, the second server NIC interface is used for the
private WAN connection and thus is not available for Silent Monitoring.
Therefore, in redundant Unified CCE installations and as shown in
Figure 1, a separate VM must be deployed
with the Silent Monitor service running. One NIC interface communicates with
supervisor desktops, and the other NIC interface is used to connect to the SPAN
port on the Cisco Catalyst switch.
about the Cisco Catalyst switch types that do not support outgoing traffic on a
SPAN destination port, see the
Restrictions" section in this tech note.
A Silent Monitoring
service can monitor multiple ingress or egress Voice Gateways (but not both),
and a CTI OS instance may have only two monitoring services. However, a Unified
CM cluster can support multiple PGs if more monitoring servers are needed.
Mobile agents using
IP phones can use desktop monitoring to obtain the RTP stream.
The CTI OS
supervisor desktop supports Silent Monitoring of both g.711 and g.729 media
streams. The supervisor desktop is sent copies of whichever encoding format is
used by the agent call. Note that there are two unidirectional media streams
from the monitoring server to the supervisor desktop, which represent the
bidirectional media streams of the agent call. The supervisor desktop blends
those media streams and plays the resulting blended media stream through the
sound resources on the supervisor workstation.
The CTI OS
supervisor desktop enables a supervisor to silently monitor mobile CTI OS
agents connected to any Voice Gateway that is being SPANned by a CTI OS Silent
Monitoring service on the same CTI OS instance. The CTI OS supervisor desktop
also allows a supervisor to silently monitor local CTI OS agents by using
Unlike CAD SPAN Port
Monitoring, CTI OS SPAN Port Monitoring does not statically associate an agent
with a specific SPAN Port Monitoring service.
On the Finesse sign-in page, if you select the mobile agent check box, the mobile agent options are presented to the agent. The mobile agent must provide the local CTI port extension in the Extension field, select a mode (Call by Call or Nailed Connection), and provide a dial number for the
Figure 6. Cisco Finesse Mobile Agent Sign-In
The phone number the agent supplies must route to a VoIP endpoint (Voice Gateway, IP phone, or inter-cluster trunk) in the same location as the CTI port pair used by the agent for call admission control to work properly.
A Finesse mobile supervisor can perform all of the functions that a non-mobile supervisor can perform, except for Silent Monitoring.
Cisco Finesse does not support Silent Monitoring of mobile agents.
Customer Relationship Management Integrations
Customer Relationship Management (CRM) applications can be integrated with Unified CCE via CTI OS to allow an agent to log in through their CRM application, and they can be enhanced to allow an agent to have a mobile agent checkbox option and to supply a call mode and phone number.
However, those integrated CRM interfaces must be enhanced to support using mobile agents. It is likely that a mobile agent could log in through the CTI OS agent desktop and then continue to use the integrated CRM agent interface as usual for call control and any further agent state
control. However, this capability would have to be verified for each CRM integrated offering.
Mobile agents can participate in outbound campaigns, but they must use nailed connection mode for all outbound dialing modes.
The call flow for predictive or progressive dialing is as follows:
Mobile agents log in using the local CTI port DN as their agent phone number.
Without knowing whether the agents to be selected are local or mobile agents, the dialer process continually monitors peripheral skill group statistics from the CTI server for an available agent. Concurrently, the campaign manager monitors the database for customer records and
forwards active records to the dialer. When the dialer identifies an available agent for use in an outbound campaign, it sends a route request to the media routing (MR) PIM.
The MR PIM forwards the route request to the Unified ICM/CCE/CCH CallRouter.
The Unified ICM/CCE/CCH CallRouter executes a routing script, selects an available agent, reserves that agent, and then returns a routing label (phone extension) identifying the reserved agent.
The MR PG returns the label (local CTI port DN) for an available agent to the dialer.
The dialer then places a reservation phone call to the local CTI port DN. The dialer auto-answers this reservation call for the agent via the CTI Server and then automatically places that reservation call on hold. At this point, a mobile agent has been reserved by having the
dialer port call the local CTI port, and the CTI port has placed that call on hold.
The dialer initiates customer calls through Unified Communications Manager at whatever rate is configured for the campaign.
When a live answer is detected, the dialer immediately initiates a transfer of the call (along with call context for screen pop) to the next reserved agent extension from the list maintained by the dialer. If a mobile agent is selected, then that agent extension is the local CTI
port used by that mobile agent at login.
The dialer auto-answers the transferred call for the agent through the CTI server so that the voice path between the customer and the agent can be established quickly, thus releasing the dialer port used to call the customer. The dialer then hangs up the reservation call to this
agent. The dialer also updates the Campaign Manager to indicate a live answer was detected for this call. After the agent completes handling the outbound call, the agent can be reserved for another outbound call via the same message flow.
Because the RTP stream for a mobile agent call is between the ingress and egress Voice Gateways, a failure of Unified CM or Unified CCE does not impact call survivability. However, subsequent call control (transfer, conference, or hold) may not be possible after a fail-over. A mobile
agent is notified of a fail-over on their agent desktop, but they must log in again after a Unified CM or Unified CCE fail-over occurs. For more details on Unified CM and Unified CCE fail-overs, see Design
Considerations for High Availability.
Unified Mobile Agent Sizing
Mobile agent call processing uses significantly more server resources and therefore reduces the maximum number of supported agents on both Unified Communications Manager and the Agent PG. Unified Mobile Agent uses conference bridge resources for Agent Greeting. Be sure to use the sizing calculator, but indicate a
conference on every call in place of agent greeting for each of the Mobile Agents.