Overview

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:

A customer call comes into the system via a Media Gateway. The Media Gateway is configured to route the call to CUCM.
CUCM routes the call through a configured SIP trunk that points to Genesys SIP Server.
SIP Server can accept SIP messages from any SIP trunk.
Genesys SIP Server routes the call one of two ways:
- Invoke URS and the business logic in the strategy to determine the destination to route the call.
  OR
- Directly route the call to the destination, based on its own configuration.
SIP Server sends the necessary SIP messages via a SIP trunk to CUCM.
SIP Server routes the call to the destination endpoint.
Depending on configuration, SIP Server may choose a SIP trunk based on a round-robin fashion or may use one SIP trunk as primary and other as backup if the primary is down.
The call is answered manually (Cisco phones do not support BroadSoft extensions to answer calls).
Genesys recommends that the phones be set to Auto-Answer. If that is not possible, then the call must first be accepted on the Genesys Desktop and then answered manually.
Genesys T-Library–based desktop can be used to control the call from that point.
All T-Library functionality, such as transfer, conferences, supervisor features, and so on, are supported. SIP Server processes a T-Library request and sends necessary SIP signaling messages to CUCM via the configured SIP trunk.
The call is ultimately disconnected 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 (including 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

SIP Server supports subscription for the presence of the SIP endpoints that are registered at third-party SIP platforms. Presence information is mapped to the agent/device state in the Genesys T-Library model. The underlying SIP platform must be able to provide presence based on SIP SUBSCRIBE and NOTIFY messages, as outlined in SIP RFC 3856.

SIP Server subscribes for the presence of a SIP endpoint. The SIP platform where the SIP endpoint is registered acknowledges and subsequently sends the NOTIFY messages when the state of the device changes. SIP Server uses the initial NOTIFY message to generate EventAgentLogin and EventAgentNotReady messages.

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

When a presence notification with the basic status Open is received:
- 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.
When a 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).

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.

Cisco IP Communicator Support

SIP Server supports Cisco IP Communicator in the same way as a Cisco hard phone. IP communicator must be configured in the Genesys Configuration Layer as a DN of type Extension. SIP Server provides usual T-Library messaging regarding this Extension while executing a T-Library request by a third-party SIP call control.

SIP Server emulates a proper agent state during private calls based on the presence message. When IP communicator starts, CUCM sends NOTIFY with the Open state, 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.

Integration Task Summary

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