Managing Agents over SIP

Overview of SIP-based Integration for Managing Agents

Genesys SIP Server supports operation as a type of “Application Server.” Effectively, agents will have their telephone service (dial tone) provide by a phone which is part of a Cisco UCM deployment. SIP Server will serve as the application server which manages contact center calls to and from the agents. This integration utilizes a SIP Trunk between the two components, and typically involves an exchange of presence information for each DN. The presence information informs SIP Server when an agent is involved in a non-contact center call, and this status is taken into account when the Genesys URS/ORS routing components select an agent (such as not routing a contact center call to an agent who is already busy).

This SIP-based integration offers several key benefits:

• Standards based integration using the SIP protocol.
• Fewer components—SIP Server is often deployed for purposes of recording or qualification & parking, and extending it to manage agents requires nothing more than configuration updates. This benefit is also valuable in case it is not practical to deploy a dedicated JTAPI-based T-Server (such as when Cisco UCM is geographically distant from the Genesys infrastructure).
• Access to unique features provided by SIP Server—such as full support of Genesys Interaction Recording, Personal Greetings for agents, support of Genesys SIP Voicemail.

The SIP-based integration does have some limitations which will be visible to the agents:

• First-Party Call Control (1PCC) Limitations—Agents are not allowed to use their phone for initiating mid-call changes like hold/retrieve, conference or transfer. These operations must be initiated using the agent desktop application.
• Third-Party Call Control (3PCC) Limitations—SIP Server does not have complete control over the phone, so some 3PCC operations are not supported; the main 3PCC operation which is missing is Click-to-answer (the agent must manually answer each call, or they must set the phone to “auto answer” each incoming call).

Deployment Architecture

SIP Server is integrated with CUCM via SIP trunks.The figure below depicts a sample deployment architecture of SIP Server with CUCM.

This sample call flow describes the steps for an incoming call handled by the CUCM–SIP Server integration solution:

1. Genesys SIP Server is monitoring the status of each agent’s phone.
2. An incoming customer call arrives at CUCM.
3. CUCM delivers the call to SIP Server via a configured SIP Trunk.
4. Genesys SIP Server (typically) uses a routing strategy on URS/ORS which selects a qualified agent who is in the Ready state, or places the call in queue until an agent is available. Direct calls to an agent are also possible if the agent has a Direct Inward Dial (DID) phone number.
5. SIP Server delivers the call to CUCM via a SIP trunk (if multiple SIP trunks are defined, the selection is configurable as round-robin or primary/backup).
6. CUCM delivers the call to the agent’s phone and the agent answers the call.
   The agent will use their desktop application (connected to SIP Server) for all mid-call operations, such as transfer, conference, supervision, recording control, and hold/retrieve.
7. The call disconnects when the caller or the agent hangs up.

Call Flows

Subscription

Genesys SIP Server integration with CUCM relies on the SUBSCRIBE/NOTIFY feature that is supported by CUCM.

• At startup, SIP Server sends subscription messages for a device or a list of configured devices to be notified about the endpoints status change.

• CUCM provides NOTIFY messages to SIP Server according to the endpoints status. As soon as an endpoint registers with CUCM, CUCM sends a NOTIFY message to SIP Server with the status reported as active.

Private Calls

A CUCM dialing plan can be set up in such a way that private calls (direct calls to an agent, for example) are not forwarded to SIP Server. Instead, only the notification about the busy status of the endpoint is passed to SIP Server.

SIP Server uses this status change notification to set the endpoint DN to a busy state (EventAgentNotReady), so that the rest of the Genesys suite will not consider that DN available for the routing of contact center calls. As soon as the call is released at the endpoint, CUCM notifies SIP Server, which then generates an EventAgentReady message. The agent is then considered available for contact center calls.

The mechanism for private outbound call processing is exactly the same. SIP Server receives the NOTIFY messages sent by CUCM.

Contact Center Calls

In the same way that you can set up a CUCM dialing plan to bypass SIP Server for private calls, you can write rules governing how CUCM connects contact center calls (typically, calls to the service number of the company) to SIP Server.

After connection, SIP Server triggers a strategy for Universal Routing Server (URS) to process this type of call. Eventually, an agent DN is selected to handle the customer call and SIP Server initiates a new dialog to CUCM for the selected endpoint.

Finally, CUCM delivers the call to the agent endpoint. This mechanism creates a signaling loop inside SIP Server, which is then in charge of maintaining the inbound leg from CUCM (customer leg) with the outbound leg to CUCM (agent leg).

By staying in the signaling path, SIP Server detects any change in call status, and generates call-related events (EventRinging, EventEstablished, EventReleased, and so on).

Any call control operation from the agent must be performed using a third-party call control (3pcc) procedure. In other words, the agent desktop must be used for any call control operation (except the answer call operation). This includes, but is not limited to, hold, transfer, and conference requests.

If a Network/Media Gateway is directly connected to SIP Server, then contact center calls are first received by SIP Server. The call flow for routing the call is very similar to the flow described above, except that there is only one call leg in CUCM.

Conferences

SIP Server supports conferences for agents on CUCM. A conference is initiated by a T-Library client (for example, Workspace Desktop). SIP Server can be configured to use either Media Server or other third-party MCUs to provide the conferencing feature.

Call Supervision

Supervisor features—such as, Silent-Monitoring and Barge-In—are also supported for this integration with CUCM. Supervisor functionality is supported via a T-Library interface. SIP Server includes a supervisor in a call between a customer and an agent (conference) and signals Media Server to either keep the supervisor media leg open for two-way media (sendrecv - Barge-In) or one way (for Silent Monitoring).

Presence

Genesys needs to be aware of non-contact center calls (and a general phone status), to make the best contact center routing decisions. SIP Server SUBSCRIBEs towards CUCM for presence information per RFC 3856, and CUCM NOTIFYs of the device state. SIP Server maps this presence information to the agent/device state in the Genesys T-Library model.

SIP Server transforms notifications about presence state changes into the Agent State updates, according to the following rules:

• For the initial NOTIFY with a basic status Open:
  • SIP Server uses the initial NOTIFY message to generate EventAgentLogin and EventAgentReady messages.
• For subsequent NOTIFY messages with the basic status Open:
  • SIP Server checks whether an agent is logged in. If not, SIP Server sends an event that the agent has logged in (EventAgentLogin).
  • SIP Server checks whether any activity is indicated in presence notification. If not, and if the agent is in the Not Ready state, SIP Server sends an event that the agent is Ready (EventAgentReady).
  • If an activity is indicated in the presence notification, and if the agent is Ready, SIP Server sends an event that the agent is not Ready (EventAgentNotReady), attaching the activity from the presence notification as a ReasonCode.

• For presence notification with the basic status Closed is received:
  • SIP Server checks whether the agent is logged in. If yes, SIP Server sends an event that the agent has logged out (EventAgentLogout).

In NOTIFY messages from CUCM, when an agent is handling a direct in-dial call, SIP Server expects a SIP NOTIFY message with the basic status Open and activities as "on-the-phone". Note that the Cisco extension must be set to allow for call waiting. If the extension is not configured to allow call waiting, then whenever the agent is handling a direct in-dial call, Cisco will send a SIP NOTIFY message with the basic status Closed and activities as "on-the-phone".

Agent States through SIP Presence and T-Library Interface

While working with CUCM, SIP Server could modify agent states based on two different inputs:

• NOTIFY message within a SUBSCRIBE dialog
• T-Library client requests from the agent desktop

Such dualism could lead to conflict unless some priority rules are applied. SIP Server always considers a message that brings an agent in the Not Ready/Logout state of the higher priority over a message that brings an agent in the Logging/Ready state coming from a different interface.

Endpoint Support

The SIP-based integration between SIP Server and CUCM works for all known endpoints including Cisco IP Communicator and Cisco Hardphones (with a minor disclaimer that only a select few phones were actually tested, but all had positive results). With IP communicator CUCM sends NOTIFY with the Open state when it starts, so SIP Server can set an agent linked to this extension in the Login/Ready state. At proper exit of IP Communicator, CUCM sends NOTIFY with the terminated state, so SIP Server sets an agent in the Logout state.

Supported Versions

For supported CUCM versions, see the Genesys Supported Media Interfaces Guide Supported Infrastructure page.

Integration Task Summary

To integrate SIP Server with CUCM, complete the following procedures:

1. Configure CUCM.
2. Configure DN objects for CUCM.