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.