CUCMOverview

SIP Server is integrated with Cisco Unified Communications Manager (CUCM) via SIP trunks. Here is a sample call flow:

• A customer call comes into the system via Media Gateway.

• 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 could invoke URS and business logic in the strategy would then determine the destination to route the call. Alternatively, SIP Server could directly route the call to the destination based on its own configuration.

• SIP Server sends necessary SIP messages via SIP trunk to CUCM. The call is finally routed to the destination endpoint. Depending on configuration SIP Server may choose SIP Trunk based on round robin fashion or may use one SIP Trunk as primary and other as back up if primary is down. For simplicity all pictures further in this document will contain only single SIP Trunk shown.

• Call is answered manually (Cisco phones do not support BroadSoft extensions to answer calls). It is recommended that the phones be set to Auto-Answer. If phones cannot be configured to Auto-Answer for some reason then the call would have to be first accepted on Genesys Desktop and subsequently manually answered on the phone.

• Genesys T-Library-based desktop can be used to control the call from that point. All Tlib functionality like transfer, conferences, supervisor features etc are supported. SIP Server processes TLib request and sends necessary SIP signaling messages to CUCM via the configured SIP trunk.

• Call is ultimately disconnected when the caller or the agent hangs up.

Call Flows

Genesys SIP Server integration with CUCM relies on the SUBSCRIBE/NOTIFY feature that is supported by CUCM. SIP Server subscribes for the state of a device and CUCM provides notifications about the status change notifications.

SIP Server then does not have to be in signaling path of every call.

Private Calls=

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

The following figure illustrates the processing of private calls.

Private Call Processing

Contact Center Calls

In the same way that you can set up an CUCM dialing plan to bypass SIP Server for private calls, you can write rules so that CUCM connects contact center calls (typically, calls to the service number of the company) to SIP Server. After that, 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 generate 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 (besides the answer call operation). This includes, but is not limited to, hold, transfer, and conference requests.

The following figure illustrates the processing of contact center calls.

Contact Center Call Processing

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. Only difference in that case is that there is only one call leg in CUCM.

Conferences

SIP Server supports conferences for agents on CUCM. Conference are 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 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 on a call between customer and agent (conference) and signals Media Server to either keep the supervisor media leg open for two-way media (sendrecv - BargeIn) 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 obtained as a result of this functionality is mapped to the agent/device state in the Genesys model. The underlying SIP Platform must be able to expose presence based on SIP SUBSCRIBE and NOTIFY as outlined in SIP RFC 3856.

SIP Server subscribes for the presence of a SIP endpoint. The SIP platform at which 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 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 an 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).