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

Note: From the Asterisk perspective, the two legs are two completely separate calls. Correlation is performed at the SIP Server level.

By staying in the signaling path, SIP Server detects any change in call status, and can therefore produce 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.

Call Flows

Subscription

At startup, SIP Server sends SUBSCRIBE messages to CUCM, which notifies about changes in the endpoints' status. CUCM sends NOTIFY messages to SIP Server to report the endpoints' status. As soon as the endpoint registers, CUCM sends a NOTIFY message to SIP Server, reporting the status as active.

Inbound Calls to Extensions

Inbound contact center calls, and manual internal first-party call control (1pcc) calls that are directed to extensions, are not visible to SIP Server; as a result, you cannot make third-party call control (3pcc) calls for them. Only inbound calls that are directed to Routing Points on SIP Server, and manual internal calls, which go via Routing Points can be seen by SIP Server; as a result, 3pcc calls can be made for them.

Outbound Calls

An outbound call that is contact-center-related (for example, a call back to a customer) must be performed using 3pcc operations. This ensures that SIP Server creates and controls the SIP dialogs on behalf of the agent endpoint. SIP Server uses the call flow 1 described in RFC 3725 to create a call initiated from the agent's T-Library client using the TMakeCall request.

An agent initiates the outbound call by sending the TMakeCall request from the T-Library client to SIP Server. SIP Server attempts to engage the agent by sending the INVITE message to this agent endpoint (via Asterisk).

Note: If the phone is not configured with auto-answer, the agent must manually answer the call. This is the only manual action that is required for contact center calls.

If Stream Manager is configured to provide treatments, then SIP Server connects the agent to Stream Manager to listen to a ringback tone while establishing a connection to the outbound call destination. See the following figure.

Engaging the Agent Endpoint for an Outbound Call

SIP Server contacts the requested destination number. After the destination answers the call, SIP Server discontinues the ringback tone (by sending the BYE message to Stream Manager) and renegotiates with the agent endpoint (via Asterisk), so that the media stream is connected between the agent and the customer. See the following figure.

Connecting to the Customer

Although disconnection would work if it were initiated directly from the agent endpoint, it is good practice to always use a desktop application to perform any actions related to contact center calls. Therefore, the disconnection is requested by sending the TReleaseCall request to SIP Server.

SIP Server manages two dialogs: one for the agent and another for the customer. It sends the BYE message to both of them, and the call is eventually disconnected. See the following figure.

Outbound Call Disconnection