Guest

Support

Cisco Unified Mobile Agent

Hierarchical Navigation

  • Viewing Options

  • PDF (596.5 KB)
  • Feedback
Cisco Unified Mobile Agent

Table Of Contents

Cisco Unified Mobile Agent

What's New in This Chapter

Cisco Unified Mobile Agent Architecture

Connection Modes

Call-by-Call Connection Mode

Nailed Connection Mode

Supported Mobile Agent and Caller VoIP Endpoints

Agent Location and Call Admission Control Design

Dial Plan Design

Music on Hold Design

Codec Design

DTMF Considerations with Mobile Agent

Cisco Unified Border Element Considerations with Mobile Agent

Cisco Unified Mobile Agent Interfaces

Cisco Agent Desktop

CTI OS

Customer Relationship Management (CRM) Integrations

Cisco Unified Mobile Agent With Unified Outbound Option

Cisco Unified Mobile Agent Fault Tolerance

Cisco Unified Mobile Agent Sizing


Cisco Unified Mobile Agent


Last revised on: November 30, 2009

 

Cisco Unified Mobile Agent was introduced in Cisco Unified CCE Release 7.1. It 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 (Unified CM) JTAPI.

What's New in This Chapter

Table 6-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 

Table 6-1 New or Changed Information Since the Previous Release of This Document 

New or Revised Topic
Described in:

Cisco Unified Border Element

Cisco Unified Border Element Considerations with Mobile Agent

DTMF considerations for Mobile Agent

DTMF Considerations with Mobile Agent

Media termination point (MTP) requirements for Mobile Agent call flows

Supported Mobile Agent and Caller VoIP Endpoints

Mobile Agent connect tone

Mobile Agent Connect Tone for Nailed Connection Mobile Agent

Music on Hold Design


Cisco Unified Mobile Agent Architecture

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, via 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 will then transmit 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 Figure 6-1.)

Figure 6-1 Cisco Unified Mobile Agent Architecture

The two CTI ports (local and remote) are logically and statically linked within the PG software via 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.

Unified CCE 7.x and Unified Mobile Agent are supported with Unified CM 4.1(3) and all subsequent Unified CM releases.

Unified Mobile Agent functionality is supported with both the System PG and Generic PG.

Queueing calls to mobile agents is supported with both Cisco Unified IP IVR and Unified CVP.

Connection Modes

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 at login time.

Call-by-Call Connection Mode

In a call-by-call dialing configuration, 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:

1. 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 upon the agent's location. For more information on agent locations, see Agent Location and Call Admission Control Design.

2. A customer call arrives in the system and is queued for a skill group or an agent through normal ICM configuration and scripting. This processing is the same as for local agents.

3. 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 router uses the directory number for the agent's local CTI port as the routing label.

4. The incoming call rings at the agent's local CTI port. The ICM 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.

5. 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 upon connection time. If the agent does not answer within the configured time, RONA processing will be initiated.

6. 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 will be 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.

7. When the call ends, both connections are disconnected and the agent is set to ready, not ready, or wrap-up, depending upon agent configuration and agent desktop input.

If the agent phone is configured with voicemail, the voicemail should be disabled 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.

Nailed Connection Mode

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:

1. At login, a mobile agent specifies their 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 should be preselected by an administrator based upon the agent's location.

2. A call to the phone number supplied at mobile agent login is initiated from the remote CTI port statically associated (by the PG) with the local CTI port used at login. When the agent answers, the call is immediately placed on hold. Until this process completes, the agent is not considered logged in and ready.

3. A customer call arrives in the system and is queued for a skill group or an agent through normal ICM configuration and scripting. This processing is the same as for local agents.

4. 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.

5. The incoming call rings at the local CTI port used by the agent at login. The JTAPI gateway detects that the CTI port is ringing but has not immediately answered the call. The caller will hear ringing at this point.

6. The agent's desktop indicates 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 will be initiated.

7. 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.

8. When the call ends, the customer connection is disconnected and the agent connection is placed back on hold. The agent is set to ready, not ready, or wrap-up, depending upon 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.

With a nailed connection, auto-answer is allowed.

A mobile agent nailed connection call can be terminated by the following two Unified CCM timers, and this termination can log out a nailed connection mobile agent:

Maximum Call Duration timer (the default value is 720 minutes)

Maximum Call Hold timer (the default value is 360 minutes)

To keep the mobile agent logged in, set the values for both these timers to 0, which makes the timer never expire. These timers can be configured from the Unified CCM Administration web page for the service parameters under the Cisco CallManager Service.

In a deployment with a firewall, if an agent in a nailed connection mode is idle longer than the firewall H.323 Timeout value (which is typically 5 minutes), the media stream could be blocked by the firewall when the firewall H.323 timeout expires. To prevent this, increase the firewall H.323 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 on how to enable the Mobile Agent connect tone, refer to the Cisco Unified Contact Center Enterprise Release Notes available at

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/prod_release_notes_list.html

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. That voice gateway may be registered with the same Unified CM cluster as the associated ICM Agent PG or may be registered with another Unified CM 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. Caller (ingress) and mobile agent (egress) voice gateways can be configured with either H.323, MGCP, or SIP, and a combination of voice gateway types is also supported. The ingress and egress voice gateways can be the same voice gateway if supervisory silent monitoring is not required.

Cisco Unified Mobile Agents can also log in using a Cisco IP Phone. The IP Phone could be configured for SIP or SCCP, and a mixture is also allowed. This IP Phone may be registered with the same Unified CM cluster as the associated ICM Agent PG, or it may be registered with another Unified CM cluster. Calls to mobile agents may also originate from SIP or SCCP IP Phones.

If an agent is using an IP Phone on the same cluster as the associated ICM Agent PG, it is advantageous from the perspective of Unified CM performance for the agent to utilize Extension Mobility instead of the Mobile Agent feature. However, that IP Phone device would have to be associated with the ICM JTAPI user, and there is a small performance hit on Unified CM for making that association.

In Figure 6-2, 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 6-2 Mobile Agent Call Scenarios

Consider the following factors when designing a Mobile Agent solution with Unified CCE 7.5(6) and later releases:

A media termination point (MTP) is required to support the Mobile Agent call flow if all of the following conditions apply:

An SCCP IP phone is used as the Mobile Agent device.

The Mobile Agent CTI ports are located on a different cluster than the phone device.

A SIP trunk is used to connect the clusters.

Enabling the use of an MTP on an trunk will affect all calls that traverse that trunk, even non-contact-center calls. Ensure that the number of available MTPs can support the number of calls traversing the trunk.

Consider the following factors when designing a Mobile Agent solution with releases prior to Unified CCE 7.5:

When Unified CVP is involved in the call flow between two Mobile Agents, an MTP is required for the call flow.

For call flows that involve two Mobile Agents in different PIMs, an MTP is required for the call flow.

An MTP is required to support the Mobile Agent call flow if all of the following conditions apply:

An SCCP IP phone is used as the Mobile Agent device.

The Mobile Agent CTI ports are located on a different cluster than the phone device.

A SIP trunk is used to connect the clusters.

Enabling the use of an MTP on an trunk will affect all calls that traverse through that trunk, even non-contact-center calls. Ensure that the number of available MTPs can support the number of calls traversing the trunk.

Agent Location and Call Admission Control Design

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, call admission will not be accounted for correctly.

For example, assume Mobile Agent 3 in Figure 6-2 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 via Voice Gateway 2. Under normal operations, Agent 3 should log in using a CTI Port pair configured with the same location as the intercluster 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 Figure 6-2, 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 intercluster 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 Figure 6-2 are shown to be 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 Figure 6-2, 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 would be required at the remote site with the agent (egress) voice gateway if silent monitoring were required. For more details on silent monitoring, see CTI OS Silent Monitoring.

For additional information on call admission control design, refer to the Call Admission Control chapter in the Cisco Unified Communications SRND, available at

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html

Dial Plan Design

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 would be 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.

For additional information on dial plan design, refer to the Dial Plan chapter in the Cisco Unified Communications SRND, available at

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html

Music on Hold Design

If you want a caller to hear music when a mobile agent places the caller on hold, you should assign 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, you should 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 configuration.


Note Cisco recommends that you 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 will be put on hold when there is no active call to the agent. In general, Cisco recommends enabling MoH to the mobile agent phone for nailed connection calls. If MoH resources are an issue, multicast MoH services should be considered.

If MoH is disabled for the nailed connection mobile agent remote phone device associated to the call, it is possible that hold tone will be 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, Cisco recommends that you disable the hold tone for Unified CM by changing the setting of the Tone on Hold Timer service parameter in Unified CM. For details on setting this parameter, refer to the Unified CM product documentation available at

http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html

Codec Design

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 more details on silent monitoring, see CTI OS Silent Monitoring.

For additional information on codec design considerations, refer to the Media Resources chapter in the Cisco Unified Communications SRND, available at

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list.html

DTMF Considerations with Mobile Agent

MTP resources might be required for mobile agents who will be 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 will automatically insert MTP resources because of the capabilities mismatch. If the mobile agent call flow requires in-band DTMF (RFC 2833), a sufficient amount of MTP resources should be made 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.

Cisco Agent Desktop

Cisco Agent Desktop 7.1 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. (See Figure 6-3.)

Figure 6-3 Mobile Agent Login


Note The phone number supplied must route to a VoIP endpoint (voice gateway, IP phone, or intercluster 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.

CAD Silent Monitoring and Recording

Beginning with CAD 7.1(2), the Cisco Supervisor Desktop (CSD) can silent-monitor and record mobile agents using CAD SPAN port monitoring of the mobile agent voice gateway. However, Cisco Unified Mobile Agent does not support the use of Unified CM silent monitoring introduced with Cisco Unified Communications Manager 6.0.

The CAD SPAN port monitor server provides a mechanism to access an agents RTP stream when desktop monitoring is not possible (primarily for CAD mobile agents, CAD 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 speaker(s). 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 CAD, 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 CAD 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 CAD 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 will be two one-way RTP streams flowing from the SPAN port monitor server to the CAD recording server.

CAD SPAN port monitoring of the agent voice gateway is somewhat different than CAD 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 CAD 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 CAD SPAN port monitoring software is searching for RTP packets to and from the agent voice gateway IP address and port.

A single CAD SPAN port monitor server can SPAN a network segment with both local agent Cisco IP Phones and multiple mobile agent voice gateways. The CAD 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 CAD, a single CAD deployment for a PG instance can support up to five CAD 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 CAD agents (which are statically associated in CAD administration to a SPAN port monitor server), mobile CAD agents are not mapped to a specific SPAN port monitoring server. Therefore, when a CAD 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 will be used to gain access to the RTP streams.

The CAD SPAN port monitor server must run separate from the agent PG, and one NIC must be connected to the SPAN port of a Cisco Catalyst switch in order to capture the RTP streams. A second NIC interface on the SPAN port monitor server is also required to communicate with other Unified CCE components such as the CSD and the CAD recording server. There is no redundancy for SPAN port monitor servers.

The CAD SPAN port monitor server supports both G.711 and G.729 RTP streams, but it cannot support encrypted RTP streams.

CAD SPAN port monitoring of the ingress (or customer) voice gateway is not supported. CAD 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.

For more information on CAD supervisory silent monitoring and recording, see the chapter on Unified Contact Center Enterprise Desktop, page 4-1.

CTI OS

CTI OS 7.1 and later 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 mobile agent 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. (See Figure 6-4.)

Figure 6-4 CTI OS Login


Note The phone number supplied must route to a VoIP endpoint (voice gateway, IP phone, or intercluster 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.

CTI OS Silent Monitoring

CTI OS 7.1 and later releases provide 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 server. 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.

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 duplex Unified CCE installations (which is a requirement for production deployments), the second server NIC interface is used for the private WAN connection and thus is not available for silent monitoring. Therefore, in duplex Unified CCE installations and as shown in Figure 6-2, a separate server 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. 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 were 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 desktop monitoring. For more details on desktop monitoring, see the chapter on Unified Contact Center Enterprise Desktop, page 4-1.

Unlike CAD SPAN port monitoring, CTI OS SPAN port monitoring does not statically associate an agent with a specific SPAN port monitoring service.

Customer Relationship Management (CRM) Integrations

Customer Relationship Management (CRM) applications can be integrated with Unified CCE via CTI OS to allow an agent to log in via their CRM application, and they can be enhanced to allow an agent to have a mobile agent checkbooks option and to supply a call mode and phone number. However, those integrated CRM interfaces must be enhanced in order to support using mobile agents. It is likely that a mobile agent could log in via 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.

For more details on agent desktop options, see the chapter on Unified Contact Center Enterprise Desktop, page 4-1.

Cisco Unified Mobile Agent With Unified Outbound Option


Note 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:

1. Mobile agents log in using the local CTI port DN as their agent phone number.

2. 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.

3. The MR PIM forwards the route request to the router.

4. The ICM router executes a routing script, selects an available agent, reserves that agent, and then returns a routing label (phone extension) identifying the reserved agent.

5. The MR PG returns the label (local CTI port DN) for an available agent to the dialer.

6. 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.

7. The dialer initiates customer calls via Unified CM at whatever rate is configured for the campaign.

8. 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 were selected, then that agent extension would be the local CTI port used by that mobile agent at login.

9. The dialer auto-answers the transferred call for the agent via 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.

For more details on the Unified Outbound Option, see to the chapter on Cisco Unified Outbound Option, page 5-1.

Cisco Unified Mobile Agent Fault Tolerance

Because the RTP stream for a mobile agent call is between the ingress and egress voice gateways, a failure of Unified CM or ICM will not impact call survivability. However, subsequent call control (transfer, conference, or hold) might not be possible after a failover. A mobile agent will be notified of a failover on their agent desktop, but they will have to log in again after a Unified CM or ICM failover has occurred. For more details on Unified CM and ICM failovers, see the chapter on Design Considerations for High Availability, page 3-1.

Cisco Unified Mobile Agent Sizing

Mobile agent call processing uses significantly more server resources and therefore will reduce the maximum number of supported agents on both Unified CM and the ICM Agent PG. The maximum number of supported mobile agents also varies between Unified CM Release 4.x and Release 5.x. For more details on sizing a Unified CCE deployment with mobile agents, see the chapters on Sizing Unified CCE Components and Servers, page 10-1, and Sizing Cisco Unified Communications Manager Servers, page 11-1.