Jump to: navigation, search

Call Delivery

During regular call processing, external media gateways distribute incoming traffic between the SIP Server Peers. Or optionally, an additional SIP Server or Network SIP Server can be deployed at the network level to provide intelligent pre-routing, or for scaling SIP Server Peers.

Each SIP Server Peer delivers routed calls, internal calls, direct inbound calls, and external calls to a particular agent through the SIP Server instance to which the agent is currently logged on. The agent initiates calls through the SIP Server where they are logged in.

About the Call Forwarding Procedure

In case of a direct call to an agent phone number, Business Continuity takes special measures to make sure that the call is delivered to the DN where the agent's SIP phone is actually registered. Since agents can be registered on either SIP Server Peer site, the party that makes the call does not know the agent's current location, meaning the call can arrive at either SIP Server in the peer group. This SIP Server instance uses an internal call forwarding procedure to determine the location of the call destination (the agent phone number) and deliver the call there. This procedure ensures that the call is delivered to the site where T-Library messaging is linked to the logged in agent (identified as the User or Person), so that proper reporting takes place. The option dr-forward controls the rules for this call forwarding procedure.

The call forwarding procedure typically takes place as follows:

  1. An inbound direct call arrives on SIP Server 1.
  2. SIP Server 1 detects that the agent's phone is registered and accessible, but the agent is not logged in.
  3. SIP Server 1 initiates an Out-of-Signaling-Path (OOSP) transfer--it sends a 302 Moved Temporarily response back to the caller with the address of the DN on its SIP Server Peer.
  4. The media gateway sends the secondary INVITE to SIP Server 2, targeting the same DN number.
  5. SIP Server 2 processes the INVITE and tries to establish the call with the target. To prevent a forwarding loop, because the call has already been processed on SIP Server 1, SIP Server 2 will not forward the call back to that site, even if it turns out that the agent is not logged in on the SIP Server 2 site either.

Call Delivery - SIP Server Peers

The Call Delivery, Direct to SIP Server Peer figure shows a typical call flow for inbound call delivery to an agent, where the call arrives directly at the SIP Server Peer (no network-level SIP Server in the flow).

Call Delivery, Direct to SIP Server Peer

The following steps describe the call flow from media gateway to selected agent:

  1. Media gateways distribute incoming traffic across both sites.
  2. A call arrives at SIP Server on Site 1. SIP Server requests routing instructions from the Universal Routing Server (URS).
  3. Each Stat Server monitors both SIP Server Peers. As such, the Stat Server on Site 1 is able to determine agent availability on both SIP Server Peers--agents can be logged in on either SIP Server Peer.
  4. URS selects the appropriate agent to handle the call. In this example, the selected agent is logged in on the other SIP Server Peer site. URS sends a TRouteRequest to SIP Server, instructing it to route the call to the targeted agent.

Note: To route calls across sites (using Inter Server Call Control (ISCC)), Agent Reservation must be enabled. For more information, see the "Agent Reservation" section in the "T-Server Fundamentals" chapter of the SIP Server Deployment Guide. Also, see the Universal Routing 8.1 Deployment Guide.

  1. As part of its internal Business Continuity Forwarding procedure, SIP Server first determines that the selected agent is not logged in locally. Based on this logic (and related option values that control the procedure), SIP Server then forwards the call to Site 2 through the specially configured inter-site Trunk DN, using ISCC routing.
  2. The SIP Server Peer on Site 2 delivers the call to the agent.

Call Delivery - Network SIP Server

The Call Delivery, Network SIP Server figure shows a typical call flow for inbound call delivery to an agent, where the call first passes through a Network SIP Server.

Call Delivery, Network SIP Server

Note: The Network SIP Server in this architecture could be replaced with a Premise SIP Server instance, installed at the network level. In either case, Genesys recommends configuring default routing.

The following steps describe the call flow from media gateway to selected agent:

  1. The media gateways distribute incoming traffic between Network SIP Server instances at the two sites. Network SIP Server, in conjunction with URS, can provide additional intelligence when deciding to which site to route the call. For example, routing can be configured to send a greater share of calls to whichever site currently has more logged in agents. Network SIP Server can also distribute calls across multiple SIP Server Peer groups, for scaled deployments.
  2. The call arrives at the Network SIP Server on Site 1. URS at Site 1 determines that the call should go to Site 2, which currently has more agents logged in.
  3. Network SIP Server sends a 302 Moved Temporarily message to the media gateway. The media gateway sends a new INVITE to the SIP Server at Site 2.
  4. URS at Site 2 selects the best agent to handle the call. In this example, the selected agent is logged in to Site 2.
  5. URS sends a TRouteRequest to SIP Server, instructing it to route the call to the targeted agent. SIP Server establishes the call with the agent.

Call Delivery - Multi-Site

In cases where the deployment includes an external Genesys location in addition to the SIP Server Peers, the call is delivered to one of the SIP Server Peers, based on how the targeted Trunk is resolved. For example, if the INVITE through Trunk1 arrives at SIP Server on Site 1, but the targeted agent DN is not found at this site, Business Continuity Forwarding is applied, and the call is forwarded to the other SIP Server Peer at Site 2.

For configuration details, see Deploying SIP Business Continuity With a Remote Site.

This page was last edited on September 17, 2015, at 18:08.
Comments or questions about this documentation? Contact us for support!