Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
Outbound Option Description
Downloads: This chapterpdf (PDF - 1.76MB) The complete bookPDF (PDF - 12.21MB) | The complete bookePub (ePub - 7.08MB) | Feedback

Outbound Option Description

Contents

Outbound Option Description

The Outbound Option Dialer is a software-only process that co-resides on the Unified CM PG. The SIP Dialer process communicates with Voice Gateways, Outbound Option Campaign Manager, CTI Server, and MR PIM. The Dialer process communicates with the Outbound Option Campaign Manager to retrieve outbound customer contact records and to report outbound call disposition (including live answer, answering machine, RNA, and busy). The Dialer process communicates with the Voice Gateway to place outbound customer calls. The Dialer process communicates with the CTI Server to monitor skill group activity and to perform third-party call control for agent phones. The SIP Dialer process communicates with the MR PIM to submit route requests to select an available agent.


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


The SCCP Dialer process has communication sessions with Unified CM, Outbound Option Campaign Manager, CTI Server, and MR PIM. The SCCP Dialer process communicates with the Outbound Option Campaign Manager to retrieve outbound customer contact records and to report outbound call disposition (including live answer, answering machine, RNA, and busy). The SCCP Dialer process communicates with Unified CM to place outbound customer calls and agent reservation calls from the dialer ports and thus has an impact on the Unified CM cluster. The SCCP Dialer process communicates with the CTI Server to monitor skill group activity and to perform third-party call control for agent phones. The SCCP Dialer process communicates with the MR PIM to submit route requests to select an available agent.

The Outbound Option Dialer can dial customers on behalf of all agents located on its peripheral. The Dialer is configured with routing scripts that enable it to run in full blended mode (an agent can handle inbound and outbound calls), in scheduled modes (for example, 8:00 AM to 12:00 PM in inbound mode and 12:01 PM to 5:00 PM in outbound mode), or completely in outbound mode. If blended mode is enabled, the Dialer competes with inbound calls for agents. The Dialer does not reserve more agents than are configured in the administrative script Outbound Percent variable. If all agents are busy, then the Dialer does not attempt to reserve any additional agents.

Multiple Voice Gateways and Unified SIP Proxy Server are used to achieve high-availability for SIP Dialer deployment, while multiple SCCP dialers are used to achieve high-availability for SCCP dialer deployment. The redundancy is also achieved with redundant SIP Dialer. See Designing SIP Dialer for High Availability.

Outbound Option supports Call Progress Analysis configuration on a campaign basis. When this feature is enabled, the SIP Dialer instructs the Voice Gateway to analyze the media stream to determine the nature of the call (such as voice, answering machine, modem, or fax detection).

Campaigns are run as agent-based campaigns or IVR-based campaigns. An IVR is generally configured in an agent-based campaign to allow for handling of overflow calls when all agents are busy. In a transfer to an IVR-based campaign, all of the calls are transferred to an IVR application after the outbound call is answered.

Outbound Option Processes

Outbound Option for Cisco Unified Contact Center Enterprise and Hosted places outbound calls through a Voice Gateway. The Outbound Option Dialer does not require telephony cards to generate tones or to detect tones or voices.

The Outbound Option involves the following processes:
  • Campaign Manager and Import processes manage campaigns.
  • Campaign Manager and Import processes are always installed on the Side-A Logger and service only one customer instance.
  • The Dialer process dials customers and connects them with properly skilled agents or available IVRs. The Dialer process reports the results of all contact attempts back to the Campaign Manager. All Dialer processes are managed by the central Campaign Manager. The Dialer is installed on the same platform as the Agent PG.
  • A Media Routing Peripheral is required for the Dialer to reserve agents for outbound use. It can co-reside on other servers in a Unified CCE deployment. See Sizing Unified CCE Components and Servers.

Note


Precision Routing does not support Outbound Option. Outbound Option campaigns use skill groups. However, an agent involved in an outbound campaign (through an outbound skill group) can be logged into a Precision Queue and handle inbound Precision Routing calls.


Benefits of Cisco Outbound Option

Cisco Outbound Option provides the following benefits:
  • Enterprise-wide dialing, with IP Dialers placed at multiple call center sites. The Campaign Manager server is located at the central site.
  • Centralized management and configuration through the Unified CCE Administration & Data Server.
  • Call-by-call blending of inbound and outbound calls.
  • Flexible outbound mode control. Use the Unified CCE script editor to control the type of outbound mode and percentage of agents within a skill to use for outbound activity.
  • Integrated reporting with outbound specific reporting templates.

Best Practices for Outbound Option

Follow these best practices when implementing Outbound Option:
  • Configure abandon to IVR in agent-based campaigns. This is often required to comply with telemarketing laws (for example, FTC/FCC regulations in the US and OfCom regulations in the UK).
  • Schedule large imports of the contact list and Do-Not-Call list during off-hours because the Campaign Manager runs on the same system as the Side-A Logger.
  • Do not use Cisco IP Communicator soft phone for agents configured for Outbound Option. IP Communicator can introduce an additional delay in transferring customer calls to the agent.

Best Practices for SCCP Dialer


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


Outbound Option enables an agent to participate in outbound campaigns and take inbound calls through a SCCP software dialer.

Follow these best practices when implementing the SCCP Dialer:
  • Use a media routing PG and a media routing PIM for each SCCP Dialer. The Media Routing PG can be configured for multiple PIMs to support multiple SCCP dialers.
  • For high availability, deploy multiple SCCP dialers at a single Unified CM cluster. See Designing SCCP Dialer for High Availability . Deploy SCCP dialers in close proximity to the Unified CM cluster where the SCCP Dialers are registered.
  • Configure the Unified CM node to keep SCCP Dialer traffic localized to one subscriber as much as possible. See SCCP Dialer Throttling Considerations for Unified CM for more details.
  • Configure the same number of ports for SCCP Dialers at a specific peripheral.
  • Ensure proper Unified CM server sizing when installing SCCP Dialers. Unified SCCP Dialer places a large strain on Unified CM. See SCCP Dialer Throttling Considerations for Unified CM for more details.
  • Enable SCCP Dialer call throttling to prevent overloading the Unified CM server. See SCCP Dialer Throttling Considerations for Unified CM.
  • The Unified CM routing and dial plans are used for SCCP Dialer to place outbound calls. This allows calls to be placed using gateways that are deployed to leverage toll-bypass and lower local calling rates.

Note


The SCCP dialer does not support CUBE for all releases of Unified CCE.


Best Practices for SIP Dialer

The Outbound Option enables an agent to participate in outbound campaigns and take inbound calls through a SIP software dialer.

Follow these best practices when implementing the SIP Dialer:
  • Be aware that only T1 PRI and E1 PRI interfaces to the PSTN are supported for Outbound SIP Dialers.
  • Use a media routing PG with one media routing PIM for duplex SIP Dialers. One SIP Dialer is active while another SIP Dialer is in warm standby mode. One MR PIM is for each SIP Dialer. In a duplex MR PG environment, each PG side has only one PIM that connects to the local dialer when the Dialer becomes active.
  • Use the g.711 codec in the dialer peer configuration of the gateway in the cases when the recording is enabled in the campaign configuration in a SIP Dialer deployment.
  • Enable SIP Dialer call throttling to prevent overloading the Voice Gateways. See SIP Dialer Throttling Considerations for Voice Gateway and Cisco Unified SIP Proxy Server.
  • The Voice Gateway dial peers and CUSP routing policies are used for SIP Dialers to place outbound calls. This enables calls to be placed using gateways that are deployed to leverage toll-bypass and lower local calling rates.
  • When the SIP Dialer and Unified CVP share gateways, where the VXML gateway that is selected is the same as the gateway placing the outbound call for transfer to an IVR campaign or abandon to an IVR feature, configure Unified CVP to send the call back to the gateway it comes from to reduce network DSP resource usage and traffic, and to improve media transfer. 

Note


Cisco Finesse Release 9.0(1) supports the Outbound Option for Progressive and Predictive modes only. Cisco Finesse Release 9.1(1) and later supports Progressive, Predictive, and Preview modes.


Differences Between SIP Dialer and SCCP Dialer

The following table shows the differences between the SIP Dialer and the SCCP Dialer.

Table 1 SIP Dialer and SCCP Dialer Differences

SIP Dialer

SCCP Dialer

Use the Voice Gateway dial peers and CUSP routing policies for outbound call routing.

Use the Unified Communications Manager routing and dial plans for outbound call routing.

No need to configure Unified Communications Manager translation pattern to support Campaign ANI.

Need to configure Unified Communications Manager translation pattern to support Campaign ANI.

Perform CPA at gateway DSP resource.

Perform CPA at Unified Communications Manager dialer port.

CPA supports both g.711 and g.729 codecs.

CPA supports only g.711 codec.

No need to configure dialer port on Unified CM.

Need to configure dialer port on Unified Communications Manager.

Call Throttling supports 60 CPS per dialer.

Call Throttling supports 5 CPS per dialer.

Dialer need NOT be in proximity of Voice Gateway.

Dialer needs to be in proximity of Voice Gateway.

Supports 1500 dialer ports.

Supports 120 dialer ports.

Supports warm-standby architecture.

Does not support warm-standby architecture.

Requires one MR PIM for MR PG.

Requires two MR PIMs for duplex SCCP Dialers, and one MR PIM for simplex SCCP Dialer.

Only connected outbound calls, which are transferred to agents or IVR, go through Agent PG and Unified Communications Manager.

All the outbound calls go through Agent PG and Unified Communications Manager.


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


Outbound Dialing Modes

Cisco Outbound Option initiates calls using any of several modes, depending on the skill group:
  • Predictive Mode—Dynamically calculates the number of lines to dial per agent to minimize agent idle time between calls.
  • Progressive Mode—Uses a fixed number of lines per agent, set by the administrator.
  • Preview Mode—Agent manually accepts, rejects, or skips customer calls (through enabled desktop buttons). Dials one line per agent.
  • Direct Preview Mode—Allows the agent to hear the call ring-out from the desktop, similar to having the call placed by the agent directly. Dials one line per agent.
  • Personal Callback Mode — When the person who is called requests to be called back later, the agent can specify that the callback is directed to the same agent. The system then calls the customer back at a pre-arranged time established between the requested agent and the customer.

Call Flow Description—Agent Based Campaign

In an agent-based campaign, completed Dialer calls are routed to a live agent using a Unified IP Phone and desktop. The SCCP Dialer call flow for predictive/progressive dialing proceeds as follows with only one Unified CM PG, Generic PG, or System PG:
Figure 1. SCCP Dialer Call Flow for Agent-Based Campaigns

  1. Import is scheduled and campaign starts. Customer records are delivered to Dialer.
  2. The dialer process continually monitors peripheral skill group statistics from the CTI server for an available agent. Concurrently, the campaign manager monitors the database for customer records and forwards active records to the dialer. When the dialer identifies an available agent for use in an outbound campaign, it sends a route request to the MR PIM.
  3. The MR PIM forwards the route request to the router.
  4. The Unified ICM/CCE/CCH CallRouter executes a routing script, selects an available agent, reserves that agent, and then returns a routing label (phone extension) identifying the reserved agent.
  5. The MR PG returns the label for an available agent to the dialer. The dialer then sends an agent reservation request to the Agent PG. The Agent PG generates a virtual agent reservation call to the agent desktop, and automatically places that virtual reservation call into answered state and then on hold.
  6. The dialer initiates the customer call through Unified CM and the Voice Gateway.
  7. If call progress analysis is configured, the dialer process will analyze the RTP stream to detect a live answer (or answering machine detection). When a live answer is detected, the dialer immediately initiates a transfer of the call (along with call context for screen pop) to the next reserved agent extension from the list maintained by the dialer. Similarly, if answering machine detection is enabled, the call can be transferred to the agent, to an IVR, or dropped.
  8. The dialer auto-answers the transferred call for the agent by way of the CTI server so that the voice path between the customer and the agent can be quickly established. This releases the dialer port used to call the customer. The dialer then hangs up the reservation call to this agent. The dialer also updates the Campaign Manager to indicate a live answer was detected for this call. After the agent completes handling the outbound call, the agent can be reserved for another outbound call using the same message flow.
The figure below shows the SIP Dialer call flow for agent-based campaigns with direct Voice Gateway deployment.
Figure 2. SIP Dialer Call Flow for Agent-Based Campaigns—Direct Voice Gateway Deployment

The SIP Dialer call flow with direct Voice Gateway deployment for predictive/progressive dialing proceeds as follows:
  1. Import is scheduled and the campaign starts. Records are delivered to Dialer.
  2. The dialer process continually monitors peripheral skill group statistics from the CTI server for an available agent. Concurrently the campaign manager monitors the database for customer records and forwards active records to the dialer. When the dialer identifies an available agent for use in an outbound campaign, it sends a route request to the MR PIM.
  3. The MR PIM forwards the route request to the router.
  4. The Unified ICM/CCE/CCH CallRouter executes a routing script, selects an available agent, reserves that agent, and then returns a routing label (phone extension) identifying the reserved agent.
  5. Media Routing PIM notifies the Dialer that the agent is available. The dialer then sends an agent reservation request to the Agent PG. The Agent PG generates a virtual agent reservation call to the agent desktop, and automatically places that virtual reservation call into answered state and then on hold.
  6. Dialer signals the gateway to place outbound calls to the customers by using a SIP INVITE.
  7. The Gateway places outbound calls to the customers, and Dialer is notified the Gateway is trying.
  8. Call Progress Analysis is done at the Gateway. Voice is detected, and Dialer is notified.
  9. The Dialer asks the voice Gateway to transfer the answered outbound call to the reserved agent by its agent extension.
  10. The Gateway directs the answered outbound calls to the agents through Unified CM, using agent extensions and Unified CM host address. The Dialer auto-answers the transferred call for the agent through the CTI server so that the voice path between the customer and the agent can be quickly established.
The following figure shows the SIP Dialer call flow for agent-based campaigns in a Unified SIP Proxy Server deployment.
Figure 3. SIP Dialer Call Flow for Agent-Based Campaigns – Unified SIP Proxy Server Deployment

The SIP Dialer call flow in a Unified SIP Proxy Server deployment for predictive or progressive mode dialing proceeds as follows:
  1. Import is scheduled and the campaign starts. Customer records are delivered to Dialer.
  2. Dialer looks for an available agent by using the Media Routing Interface.
  3. MR PG forwards the request to the Router.
  4. The Routing Script identifies an agent and responds to the MR PG.
  5. Media Routing PIM notifies the Dialer that the agent is available.
  6. Dialer signals the Unified SIP Proxy Server to find a gateway and tell it to place outbound calls to the customers through a SIP INVITE.
  7. The Gateway places outbound calls to the customer.
  8. Call Progress Analysis is done at the gateway. Voice is detected, and Dialer is notified.
  9. The Dialer asks the Voice Gateway to transfer the answered outbound call to the reserved agent by its agent extension.
  10. The Gateway initiates the transfer to the Unified SIP Proxy Server, and the SIP Proxy forwards the invitations onto Unified CM. Unified CM forwards the call invitations to the agent’s phone. The dialer auto-answers the transferred call for the agent via the CTI server so that the voice path between the customer and the agent can be quickly established.

The message flows above describe the flow for predictive or progressive mode dialing. The only difference in these two dialing modes is how the dialer determines its dialing rate (dynamic or fixed). For preview dialing, the agent will receive a customer record screen pop. If the agent wants to place this call, the agent must click the Accept button on the agent desktop. This triggers a CTI event, which causes the dialer to call this customer.

Call Flow Description—Transfer to IVR Campaign

CTI RP is not used for SIP Dialer because the Agent PG is not monitoring outbound calls during transfer to the IVR campaign and because using CTI RP would cause loss of ECC variables. SIP Dialer uses the MR routing interface instead to request a transferred label from the Router.

When using SCCP dialer for a Transfer-to-IVR campaign with IP IVR or Unified CVP, a CTI RP is used to request a transferred label from the Router; however, when using SIP Dialer, CTI RP is not used, but the MR routing interface is used instead.

In an IVR-based campaign, the live call is transferred to an IVR system in an SCCP Dialer deployment according to the following process:
Figure 4. SIP Dialer Call Flow for IVR-Based Campaigns –Unified SIP Proxy Server And IP IVR Deployment

  1. In this example, an unattended IVR campaign starts. Customer records are delivered to the Dialer.
  2. The Dialer initiates a call to the customer.
  3. The RTP stream is analyzed and voice is detected.
  4. The Dialer requests an in-line transfer to a pre-configured route point.
  5. The Unified CM PG requests a translation route for the router.
  6. The router responds.
  7. The response is translated and sent to Unified CM.
  8. Unified CM transfers the call to the IVR.
The SIP Dialer call flow for IVR-based campaigns with a Unified SIP Proxy Server and an IP IVR deployment proceeds as shown in the following figure:
Figure 5. SIP Dialer call flow for IVR-based campaigns with a Unified SIP Proxy Server and an IP IVR deployment

  1. An unattended IVR campaign starts. Customer records are delivered to the Dialer.
  2. The Dialer asks the SIP Proxy to forward an invitation to an available gateway to start a call.
  3. The Gateway places the call.
  4. Voice Gateway does Call Progress Analysis and detects live speech. The Dialer is notified.
  5. The Dialer asks the MR PG where the IVR is.
  6. MR PG forwards the request to the Router.
  7. Routing Script identifies the IVR and notifies the MR PG.
  8. The MR PG forwards the route response to the Dialer.
  9. The Dialer notifies the Voice Gateway to transfer the call to the IVR.
  10. The Gateway initiates the transfer to the SIP Proxy and the SIP Proxy forwards the call invitation to Unified CM.
  11. Unified CM forwards the call invitation to the IP IVR.
  12. Media is set up between the Gateway and the IP IVR.
The SIP Dialer call flow IVR-based campaigns with Unified SIP Proxy Server and Unified CVP deployment proceeds as follows :
Figure 6. SIP Dialer Call Flow for IVR-Based Campaigns –Unified SIP Proxy Server And Unified CVP Deployment

  1. In this example, an unattended IVR campaign starts. Customer records are delivered to the Dialer.
  2. The Dialer asks the SIP Proxy to forward an invitation to an available Voice Gateway to start a call.
  3. The Voice Gateway places the call.
  4. The Voice Gateway does Call Progress Analysis and detects live speech. The Dialer is notified.
  5. The Dialer asks the MR PG where the IVR is.
  6. MR PG forwards the request to the Router.
  7. Routing Script identifies the IVR and notifies the MR PG.
  8. The MR PG forwards the route response to the Dialer.
  9. The Dialer notifies the Voice Gateway to transfer the call to the IVR.
  10. The Voice Gateway sends its invitation to the SIP Proxy, which forwards it to Unified CVP. The transfer is completed and media is set up between Unified CVP and the Voice Gateway.

Outbound Options for Unified Contact Center Enterprise and Hosted Deployments

Enterprise Deployments

Run the Outbound Option on a Windows server that meets the minimum requirements specified in the latest version of the Hardware & System Software Specification (Bill of Materials) for Cisco Unified ICM/​Contact Center Enterprise & Hosted, Release 9.0(x).

 The SIP Dialer is preferred for new deployments due to its high scalability by offloading call process resources and call progress analysis to the gateway. Furthermore, the SIP Dialer has no Unified CM or gateway proximity requirements.

The SIP or SCCP dialer must be on the same server with the MR-PG and Agent PG. Duplex MR-PGs and Agent PGs are required even when a simplex SCCP Dialer is installed.

The duplex Agent PG supports only duplex SIP Dialers; one dialer is active and another dialer is in warm-standby mode. For duplex SIP Dialer installations, each SIP Dialer connects to the MR PIM on the same MR PG side (Side  A or Side  B).

For two SCCP dialers installed for an Agent PG, the two MR PIMs on one MR PG side (Side A or Side B) are active, and one connects to the SCCP Dialer on the same side (Side A) while the other connects to the SCCP Dialer on the other side (Side B).

When there are fewer than 120 dialer ports, installing one or two SCCP dialers for an Agent PG has both pros and cons. The installation with a single SCCP Dialer offers better Predictive/Progressive dialing performance by achieving an agent pooling effect, but it does not provide redundancy. An installation with two SCCP Dialers, with dialer ports split across the two SCCP dialers (one SCCP dialer on PGA and one SCCP dialer on PGB), offers redundancy architecture but worse Predictive/Progressive dialing performance.

There is no upgrade path from the SCCP Dialer to SIP Dialer. Any new configuration and setup have to be created for the SIP Dialer only. It is possible to deploy both the SCCP and SIP Dialers in the same Unified CCE customer instance. The Campaign Manager is able to communicate with both the SCCP and SIP Dialers. However, the Campaign Manager performs only the warm standby feature for the SIP Dialer by knowing the dialer type. You can configure and set up only one dialer type, either SCCP dialer or SIP Dialer, for one Agent PG duplex.

The hybrid deployment model is usually used for upgrading one large customer so that the old SCCP Dialers can be removed and their outbound agents can be gradually added to the new SIP Dialer.


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


Single SCCP Dialer Deployment


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


The figure below shows the installation of a single SCCP dialer. The SCCP Dialer is shown installed on Side A of the duplex PGs. The single SCCP dialer configuration provides capacity for 120 ports. This deployment model is used when scaling and high availability are not factors.

Figure 7. Single SCCP Dialer Deployment

For Cisco Unified Contact Center Enterprise deployments, the SCCP Dialer and Media Routing PG processes run on the same physical Server as the Agent PG. In a deployment with two SCCP dialers on a duplex PG pair, the Media Routing PG has two PIMs because each dialer gets its own Media Routing PIM.

The connection between the SCCP Dialer and the Unified CM cluster consists of multiple Skinny Client Control Protocol (SCCP) sessions, one for each SCCP dialer port. The duplexed PGs (Side A and Side B) shown in Figure 98 are composed of a Generic PG (with Unified CCE PIM and a Unified IP IVR PIM), MR PG, CTI server, and CTI OS server process. The JTAPI links the duplexed PG and the Unified CM cluster.

Multiple SCCP Dialer Deployment


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


The following figure shows the deployment model for two dialers. Each dialer is associated with the Unified CM subscriber on its respective side and has all of its ports in one device pool for that subscriber. The configuration shown in this figure provides 192 dialer ports. To scale upward, you can add more pairs of dialers (PG Sides A and B) and subscribers, for up to four pairs (or eight dialers, PG sides, and subscribers) per Unified CM cluster (see Figure 2). The use of multiple dialers provides high availability for this deployment model. For more details, see Designing SCCP Dialer for High Availability.

Figure 8. Multiple Dialer Deployment (Two Dialers)

Figure 9. Multiple SCCP Dialer Deployment (Eight Dialers)

Single Gateway Deployment for SIP Dialer

The following figure shows the installation of duplex SIP Dialers with a single Gateway. The Dialers are shown to be installed on Side A and Side B of the duplex PGs. The port capacity depends on the type of Cisco Voice Gateway deployed. This deployment model is used when scaling and high availability are not factors.

Figure 10. Single Gateway Deployment for SIP Dialer

The SIP Dialer architecture supports only one active SIP Dialer per peripheral. Only one SIP Dialer needs to be configured. Two Dialers are installed on separate PG platforms, but each Dialer is installed using the same Dialer Name.

For Cisco Unified Contact Center Enterprise deployments, the SIP Dialer and Media Routing PG processes run on the same physical Server as the Agent PG. In a deployment with duplexed SIP dialers on a duplex PG pair, the Media Routing PG has one PIM because each dialer gets its own Media Routing PIM on the same physical server.

With Unified CM in single gateway deployments, the SIP Dialer uses the local static route file to place and transfer outbound calls when Sip Server Type is set to Voice Gateway in the Dialer setup dialog. These outbound calls are transferred to to Unified CVP, IP IVR, or outbound agents. Make sure the SIP Dialer uses the local static route file for single gateway deployments.

With Unified CM in single gateway deployments, the SIP Dialer uses the Unified SIP Proxy Server to place and transfer outbound calls when Sip Server Type is set to CUSP Server in the Dialer setup dialog. These calls are placed or transferred to Unified CVP, IP IVR, or outbound agents.


Note


Codec configuration (g.729 versus g.711) impacts port capacity and CPU utilization of gateways. Configuring g.729 requires more DSP and CPU resources for gateways.


Multiple Gateway Deployment for SIP Dialer

The following figure shows the deployment model for Unified SIP Proxy and eight Voice Gateways. The active Dialer points to the Unified SIP Proxy Server. The proxy handles load balancing and fail-over. The SIP Dialer supports Unified SIP Proxy on the Cisco 3845 Integrated Services Router. For more details, see Designing SIP Dialer for High Availability.

Figure 11. Multiple Gateway Deployment for SIP Dialer

In a multiple gateway deployment, the SIP Dialer requires Server Group and Route Table configurations on Unified SIP Proxy servers to identify the gateways, as well as numbers so that the gateways can determine where to send calls to Unified CVP, IP IVR, or agents when the Dialer asks the gateway to transfer customer calls. Setting the Sip Server Type radio button to SIP Proxy in the Dialer setup dialog is required for multiple gateway deployment.

Clustering Over the WAN

The deployment model for clustering Unified CCE over the WAN allows for improved high availability by deploying redundant components on the other end of the WAN (see Deployments). The Cisco Outbound Option high-availability model differs from the model that is used in clustering over the WAN; therefore, when deploying clustering over the WAN, keep in mind that its benefits are for inbound traffic only.

Distributed Deployments

A distributed deployment model involves a central Unified CCE system and Unified CM located at one site, with the Campaign Manager installed on the logger at this site, and a second site reachable over a WAN, which consists of the dialer, a PG, and a second Unified CM system with Outbound Options.

For SIP Dialer deployment, a Unified SIP Proxy Server is installed for one SIP Dialer on each PG side, and the Side A/Side B Dialer is targeting the same set of Voice Gateways through its own Unified SIP Proxy Server. Multiple Voice Gateways can be installed locally to customer phones, or each Voice Gateway can be installed locally to an area so that tolls are not encountered if leased circuits or IP MPLS WAN circuits are available.

The Campaign Manager sends dialer records over the WAN, and the dialer places calls to local customers. The second site would support inbound agents as well. See IPT: Multisite with Distributed Call Processing.

The following bandwidth options are available between India and the US in customer environments:

  1. Terrestrial P2P leased 2 Mbps circuits
  2. Terrestrial P2P DS3 (44 Mbps) leased circuits
  3. IP MPLS WAN circuits. Varying speeds are available from the service provider depending on customer needs. Typical usage is 44 Mbps.
  4. The service provider hands off PRI (E1) trunks to India. The WAN cloud is usually built on SIP by the service provider. The service provider converts TDM to IP at the ingress/egress point in the United States and converts IP to TDM in India.

Options 1 and 2 above are the most common. Option 3 is becoming more popular with outsourcers because the MPLS cloud can connect to several of their customers. For example, the diagrams in the following sections show that the Outbound Contact Center System is deployed across multiple sites in the United States and India for various agent-based campaigns or transfer to an IVR campaign. The customers are in one country; for example, in the United States.

Distributed Deployment Example for Agent-Based Campaign

In this distributed deployment example for an agent-based campaign:
  • The Voice Gateway and RGRA servers are distributed between two sites (Site 1 and Site 3) in the United States.
  • The Unified CM cluster is located at Site 2 in India along with the Agent PG.
  • The MRPG/Dialer and Agent PGs are locally duplexed at Site 2 in India.
  • The MRPG/Dialer is also installed on the same Agent PG servers.
  • The SIP Dialer uses the Voice Gateways that are located at Site 3 in the United States.
  • The Voice Gateways are included in the diagram with CT3 interface at Site 3 in the United States. These routers provide 1:1 redundancy for Dialer calls.
  • The Unified SIP Proxy servers are locally duplexed at Site 2 to avoid the WAN SIP signaling traffic that is needed to transfer live outbound calls.
  • Each SIP Dialer connects to its own Unified SIP Proxy Server at Site 2.
  • Each Unified SIP Proxy Server controls the set of Voice Gateways at Site 3 in the United States.
  • The Unified SIP Proxy servers provide (N + 1) redundancy.
  • g.711 Codec outbound calls require a WAN bandwidth of 80 kbps per agent call.
  • g.729 Codec outbound calls require a WAN bandwidth of 26 kbps per agent call.
  • If the recording is enabled at the SIP Dialer, an alerting outbound call with a g.711 Codec requires a WAN bandwidth of 80 kbps per agent call. An alerting outbound call with a g.729 Codec requires a WAN bandwidth of 26 kbps per agent call.

The following figure provides an example of a distributed deployment for an agent-based campaign.

Figure 12. Distributed Deployment Example for Agent-Based Campaign

Distributed Deployment Example for Transfer-to-IVR Campaign – Unified -CVP

The Voice Gateway and RGRA servers are distributed between two sites (Site 1 and 3) in the United States.

The MRPG/Dialer and Agent PGs are locally duplexed at the Site 2 in India.

The MRPG/Dialer will also be installed on the same Agent PG servers.

Unified CVP with local redundancy is included at Site 3 (United States). Unified CVP has its own Unified SIP Proxy servers for load balancing and redundancy.

The VRU PGs are locally duplexed at Site 3 (United States).

The SIP Dialer uses the Voice Gateways located at Site 3 (United States).

The Voice Gateways are included in the diagram with CT3 interface at Site 3 (United States). These routers will provide 1:1 redundancy for Dialer calls.

The Unified SIP Proxy servers are locally duplexed at Site 3 to avoid the WAN SIP signaling traffic to transfer live outbound calls.

Each SIP Dialer connects to its own Unified SIP Proxy Server at Site 3. Each Unified SIP Proxy Server controls the set of Voice Gateways at Site 3 (United States).

The Unified SIP Proxy servers provide (N + 1) redundancy.

If recording is enabled at the SIP Dialer, the bandwidth requirements are as follows:
  • An answered outbound call with g.711 Codec requires a WAN bandwidth of 80 kbps for the Call Progress Analysis time period.
  • An answered outbound call with g.729 Codec requires a WAN bandwidth of 26 kbps for the Call Progress Analysis time period.
  • An alerting outbound call with g.711 Codec requires a WAN bandwidth of 80 kbps per agent call, and an alerting outbound call with g.729 Codec needs a WAN bandwidth of 26 kbps per agent call.
  • Outbound calls being queued or self-serviced at Unified IP IVR do not require WAN bandwidth.
Figure 13. Distributed Deployment Example for Transfer-to-IVR Campaign – Unified CVP

Distributed Deployment Example for Transfer-to-IVR Campaign – IP IVR

The Voice Gateway and RGRA servers are distributed between two sites (Site 1 and 3) in the United States.

The Unified CM cluster is located at Site 3 (United States) along with the VRU PG.

The VRU PGs are locally duplexed at Site 3 (United States).

IP IVR is included at Site 3 (United States).

The MRPG/Dialer and Agent PGs are locally duplexed at Site 2.

The MRPG/Dialer will also be installed on the same Agent PG servers.

The SIP Dialer uses the Voice Gateways located at Site 3 (United States).

The Voice Gateways are included in the diagram with CT3 interface at Site 3 (United States). These routers will provide 1:1 redundancy for Dialer calls.

The Unified SIP Proxy servers are locally duplexed at Site 2 to avoid the WAN SIP signaling traffic to transfer live outbound calls.

Each SIP Dialer connects to its own Unified SIP Proxy Server at Site 2. Each Unified SIP Proxy Server controls the set of Voice Gateways at Site 3 (United States).

The Unified SIP Proxy servers provide (N+1) redundancy.

If recording is enabled at the SIP Dialer, the bandwidth requirements are as follows:

  • An answered outbound call with g.711 Codec requires a WAN bandwidth of 80 kbps for the Call Progress Analysis time period.
  • An answered outbound call with g.729 Codec requires a WAN bandwidth of 26 kbps for the Call Progress Analysis time period.
  • An alerting outbound call with g.711 Codec requires a WAN bandwidth of 80 kbps per agent call, and an alerting outbound call with g.729 Codec needs a WAN bandwidth of 26 kbps per agent call.
  • Outbound calls being queued or self-serviced at Unified CVP do not require WAN bandwidth.

The following figure provides an example of a distributed deployment for transfer-to-IVR campaign for IP IVR.

Figure 14. Distributed Deployment Example for Transfer-to-IVR Campaign – IP IVR

See the Bandwidth Provisioning and QoS Considerations chapter for further bandwidth requirements for the Outbound OptionWhere is this chapter – need link.

Voice Gateway Proximity for SCCP Dialer


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


Colocate the SCCP Dialer with the Unified Contact Center Enterprise PG and the Unified Communications Manager cluster (including the Voice Gateway). Because the SCCP Dialer supports only g.711 audio codec for customer calls for answering machine detection, you may need to allocate large blocks of WAN bandwidth. Even though the Dialer does not support g.729 audio codec for customer calls for answering machine detection, it is possible to support g.729 for the customer-to-agent portion of the call. This type of configuration is supported without requiring the use of transcoders.

In this deployment, the SCCP Dialer advertises g.729 capability (although the Dialer does not truly support g.729). This permits completion of the reservation call from the SCCP Dialer to the agent. The call from the SCCP Dialer to the customer must be g.711; however, the customer call is then transferred to the agent, and the call is renegotiated to g.729.

Unified Contact Center Enterprise Hosted Deployments

In Unified Contact Center Enterprise and Hosted environments, only one SIP Dialer can be deployed on each of the Unified ICM Customer instances within a Unified ICM Complex. The Do-Not-Call List or Contact List files can be shared between instances.

See the Outbound Option Guide for Cisco Unified Contact Center Enterprise and Hosted for more information.

Configure Outbound Option for Unified Contact Center Enterprise and Hosted

Outbound Option can run fully-blended campaigns in which agents can handle inbound and outbound calls alternately.

See Sizing Unified CCE Components and Servers for information about the MCS inbound capacity.

When sizing your deployment, do not use the maximum number of outbound agents allowed on a PG without also looking at expected hit rate, lines dialed per agent, and average handle times. An outbound campaign with a 10 second average handle time and dialing 10 lines per agent can support only about 20 agents while fully occupying 240 ports on two SCCP dialers. However, with an average 100 second handle time dialing three lines per agent for a 30% hit rate, 240 ports could handle 100 agents.

For sizing the Outbound Option for SCCP Dialer, use the Cisco Unified Communication Sizing Tool.

SIP Dialer targets the support of 1000 outbound agents for one PIM per PG. (Note that the number is smaller when deploying mobile agents.) To support this number of agents, the deployment must have at least five high-end gateways dedicated to outbound dialing.

SIP Dialer can support 1500 ports and 60 calls per second (cps). To achieve the rate of 60 cps, the SIP Dialer has to support between 1000 and 2000 ports, depending on hit rates and handle times.

Each port is capable of dialing two calls per minute, assuming an average 30 seconds per call attempt, so 30 ports can handle one call per second for the Dialer. If the time to get all ports busy exceeds the average port busy time, then some number of ports will always be idle.

Calculate Number of Dialer Ports

The following formula can be used to calculate the number of dialer ports that are required to achieve targeted call rate:

Number of Ports = [target call rate * average call duration * (1 + hit rate %)]

For example, given an estimated average of 30-seconds per outbound call and given an estimated 20% hit rate, the following table shows the number of ports that are required to achieve targeted outbound call rates:

Table 2 Ports Required to Achieve Targeted Outbound Call Rates

Targeted outbound calls per second

Number of ports required

10

360

20

720

30

1080

40

1440

Voice Gateway Considerations

The most powerful Voice Gateway supports about 12 calls per second, even under the most favorable conditions. Five gateways can support an aggregate spike of up to 60 calls per second when evenly distributed. However, even distribution does not account for occasions when ports are tied up with agent or IVR calls after the transfer. So assuming a 50% transfer rate and using a conservative estimate, eight Voice Gateways are required to support a spike of up to 60 calls per second.

For the most current information about Voice Gateway models and releases that are supported by a Unified CCE SIP Dialer, see the Cisco Unified Contact Center Enterprise Compatibility Matrix at http:/​/​docwiki.cisco.com/​wiki/​Compatibility_​Matrix_​for_​Unified_​CCE.

For gateway sizing considerations, see the published Cisco gateway performance data and Unified CCE sizing tool.

Agent PG Considerations

The Unified Communications Manager PIM can support up to 15 calls per second. The PG can support up to 30 calls per second in a two-PIM deployment, but each dialer is connected to a Peripheral/PIM.

If the voice hit rate for the campaign is 15%, then the PG can sustain dialing at a rate of 100 calls per second.

Unified CM Considerations

The Unified CM subscriber can support a certain number of outbound calls per second. If the Dialer attempts to transfer a large numbers of live outbound calls per second at the agent PG, then it must be distributed across multiple subscribers using a Unified SIP Proxy Server.

Cisco Unified SIP Proxy Considerations

A typical outbound call requires two transactions, if the call is transferred to an agent or IVR. A typical outbound call requires one transaction, if the call is not transferred to an agent or IVR.

The following table shows Unified SIP Proxy Sizing.

Table 3 Unified SIP Proxy Sizing

Hardware Model

Maximum Transaction Rate Per Second

NME-CUSP-522

100

Unified CVP Considerations

Calls can be distributed to Unified CVP using translation routes. Any load balancing across Unified CVPs happens in the routing script. 

Since four SIP Proxy transactions are required for some outbound call scenarios with Unified CVP, give Unified CVP its own Unified SIP Proxy Server in large-scale deployments.

IP IVR Considerations

If the IP IVR is deployed, then all of its calls are front-ended through Unified CM. This deployment results in a higher call load on the Unified CM subscribers. Because the Unified CM subscriber supports only five calls per second, it is likely that calls transferred to agents and the IVR needs to be distributed across multiple subscribers using the Unified SIP Proxy Server.

Unified Mobile Agent Considerations 

The SIP Dialer supports 500 unified mobile agents per Agent PG. With the SIP Dialer solution, the outbound calls have the same impact on Unified Communications Manager as inbound calls. Maintain a 2:1 ratio for number of inbound agents versus outbound agents. Since the SIP Dialer solution supports 1000 outbound regular agents per Agent PG, 500 outbound mobile agents per Agent PG is supported by the SIP Dialer.

For sizing the Cisco Outbound Option for SIP Dialer, use the Cisco Solution Sizing Tool.

SCCP Dialer Throttling Considerations for Unified CM


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


SCCP Dialer Throttling is controlled by the Port Throttle field in the dialer configuration. Port Throttle indicates the number of ports to throttle in one second. For Cisco MCS-7845 and MCS-7835 servers, set Port Throttle = 5. With this setting, the SCCP Dialer will initiate calls on only five ports in one second of the campaign, and then the next five ports for the next one second, and so forth, until all 120 ports are utilized.

Setting the value to Port Throttle = 5 enables dialing at a rate of five calls per second per Dialer, which gives Unified CM sufficient room to allow for other incoming traffic and even allow for some shared resources. It is a setting that works well for most situations. If your deployment requires a higher call rate, ensure that the call rate for all traffic for any one subscriber does not exceed 10 calls per second at any time. Also, make sure that traffic is not shared across subscribers.

Currently, a Unified CM subscriber node running on a dual-processor MCS-7845 server has a maximum capacity at 10 calls per second. Each SCCP Dialer is capable of dialing at a rate of 10 calls per second. If the solution is deployed so that it permits the Unified CM subscribers to become overloaded, then there is a risk of causing dropped customer calls and inefficient dialing.

The throttling mechanism is part of each SCCP Dialer process, and it is not aware that another SCCP Dialer may be sharing Unified CM resources. Therefore, if two SCCP Dialers share the same device pool or trunk, there is a risk of dropped calls and inefficient dialing.

The Unified CM configuration must be designed and implemented to limit all traffic for a given Dialer to a distinct Unified CM subscriber node to prevent two SCCP Dialers from overwhelming any shared resources. This means that each SCCP Dialer requires separate device pools that point to one and only one subscriber. Each SCCP Dialer also needs to have a calling search space, partition, translation pattern, and trunk that are configured on its Unified CM subscriber.

Transferring to Unified CVP Using H.323 and MTP Resources

In cases where the customer is reached but no agents are currently available, or in cases where unattended campaigns are implemented, calls is transferred to an IVR. If the solution design uses Unified CVP 4.x or earlier release with the H.323 protocol, then media termination point (MTP) resources are required when transferring calls to the IVR. To minimize MTP requirements, the trunks configured for calls transferred to Unified CVP must be separate from the trunks used for external gateways. With Unified CVP 7.0 and later releases, an MTP is not required.

SIP Dialer Throttling Considerations for Voice Gateway and Cisco Unified SIP Proxy Server

SIP Dialer Throttling is controlled by the field Port Throttle in the dialer configuration. Port Throttle indicates the number of ports to throttle per second. Setting the value to Port Throttle = 5 will allow SIP Dialer to dial outbound calls at a rate of five calls per second per Dialer.

When the SIP Dialer connects to the Voice Gateway directly in the deployment, limit the dialer port throttle by the maximum dialer call setup rate suggested on the gateway sizing table.

When the SIP Dialer connects through the CUSP in the deployment, the port throttle setting on the dialer must not exceed the total gateway capacity under assumption. Calls is load-balanced through CUSP and each gateway will reach its maximum available capacity. Limit the port throttle by the CUSP maximum transaction. Currently, the dialer maximum throttle setting is 60 calls per second. Under normal transfer rate, calls through CUSP will not exceed maximum CUSP transaction rate given that CUSP is exclusively used by outbound deployments.

In a single or multiple gateway deployment, the SIP Dialer raises an alarm if any gateway is overloaded, and it automatically throttles the dialing rate down to ten percent of the configured port throttle value per 5000 customer attempts until fifty percent of the correction is met. Fifty percent of the correction means the SIP Dialer stops auto--throttling when it reaches fifty percent of the configured port throttle value.

SIP Dialer provides the option to disable the auto--throttle mechanism by setting the value of registry key EnableThrottleDown to 0. The auto--throttle mechanism is enabled by default. SIP Dialer still raises an alarm even though the auto-throttle mechanism is disabled.

Set the port throttle value to 5 for Cisco 2800 Series Integrated Services Routers, set the port throttle value to 15 for Cisco 3800 Series Integrated Services Routers, and set this value to 20 for Cisco Access Servers and Universal Gateways.

Single Gateway Deployment

Use the following formula to calculate the Port Throttle if the gateway is dedicated 100% for outbound campaigns:

Port Throttle = (Value for Gateway)

Use the following formula to calculate the Port Throttle if the gateway is shared by multiple SIP Dialers for outbound campaigns:

Port Throttle = (Value for Gateway) / (Number of SIP Dialers)

Use the following formula to calculate the Port Throttle if the gateway is shared by multiple Unified CCE components (Unified Communications Manager, Unified CVP, and SIP Dialer) for inbound/outbound calls:

Port Throttle = (Value for Gateway) * (Percentage of outbound calls) * (1 – Hit Rate)

Multiple Gateway Deployment

Use the following formula to calculate the Port Throttle if the gateways are dedicated 100% for outbound campaigns:

Port Throttle = Total Values for Gateways

Use the following formula to calculate the Port Throttle if the gateways are shared by multiple SIP Dialers for outbound campaigns:

Port Throttle = (Total Values for Gateways) / (Number of SIP Dialers)

Use the following formula to calculate the Port Throttle, if the gateways are shared by multiple Unified CCE components (Unified CM, Unified CVP, and SIP Dialer) for inbound/outbound calls:

Port Throttle = (Total Values for Gateways) * (Percentage of outbound calls) * (1 – Hit Rate)

The throttling mechanism in the SIP Dialer process is not aware of which gateway the Unified SIP Proxy Server selects to place outbound calls, so the appropriate weight for each gateway in the Server Group configuration of the Unified SIP Proxy Server must be calculated for the load balance.

Weight = (Value for Gateway) / (Port Throttle) * 100

For example, if a Cisco 3800 Series Gateway (192.168.10.3 ) and a Cisco 2800 Series Gateway (192.168.10.4) are used in a multiple gateway deployment, the following configuration allows that 3800 Series gateway in the cucm.example.com server group to receive 75 percent of the traffic and the 2800 Series gateway to receive 25 percent.

netmod(cusp-config)> server-group sip group cucm.example.com enterprise
netmod(cusp-config-sg)> element ip-address 192.168.10.3 5060 tls q-value 1.0 weight 75
netmod(cusp-config-sg)> element ip-address 192.168.10.4 5060 tls q-value 1.0 weight 25
netmod(cusp-config-sg)> lbtype weight
netmod(cusp-config-sg)> end server-group

SIP Dialer Recording

The SIP Dialer can record ("Recording") or enable the recording of Call Progress Analysis by third-party applications ("Media Termination") to be used for CPA troubleshooting. Note that it does not record the full conversation.

There usually is no media stream between the SIP Dialer and the Voice Gateway. But when the recording or media termination is enabled in the Campaign configuration, the SIP Dialer requests the Voice Gateways to send the media stream to the SIP Dialer. The media stream is in g.711 or g.729 codec, depending on the dial peer configuration on the Voice Gateway. The SIP Dialer can record the media stream only with g.711 codec, but it can receive media streams for both g.711 and g.729 codecs to allow a third recording server to perform SPAN-based recording for outbound calls.

When "Recording" is enabled in the Campaign configuration, the SIP Dialer receives media streams, decodes RTP packets in g.711 codec, and writes them into a recording file. The SIP Dialer will send an alarm if the media stream is g.729 codec. The SIP Dialer has been tested to be able to support a maximum of 100 recording sessions per Dialer server due to CPU resource and disk I/O limitations.

When "Media Termination" is enabled in the Campaign configuration, the SIP Dialer will only receive the media stream to allow a third-party recording server to perform SPAN-based recording.

There is a limit for Media Termination Sessions because of a thread resource limitation per process. The SIP Dialer has to create a thread to listen on the media stream. The current limit for Media Termination Sessions is 200.

The SIP Dialer uses the following Registry keys to allow users to manage recording sessions and disk space:
Table 4 SIP Dialer Registry Keys

Name

Data Type

Description

Default Value

MaxRecordingSessions

DWORD

The maximum recording sessions per SIP Dialer, if the recording is enabled in the Campaign configuration.

100

MaxMediaTerminationSessions

DWORD

The maximum media termination sessions per SIP Dialer, if the recording is enabled in the Campaign configuration.

200

MaxAllRecordFiles

DWORD

The maximum recording file size (bytes) per SIP Dialer.

500,000,000

MaxPurgeRecordFiles

DWORD

The maximum recording file size (bytes) that SIP Dialer will delete when the total recording file size, MaxAllRecordFiles, is reached.

100,000,000

Call Transfer Timelines

The length of time required to complete a call transfer of a customer call to an agent is highly dependent on the telephony environment. The following factors can add to transfer times:
  • Improperly configured Cisco Unified Communications infrastructure—Port speed mismatches between servers or inadequate bandwidth.
  • WAN—WAN unreliable or not configured properly.
  • IP Communicator—Media termination running on a desktop does not have the same system priority as software running on its own hardware platform, such as a hard phone (use hard phones instead of soft phones when using Outbound Option).
  • Call Progress Analysis—When you enable Call Progress Analysis for the campaign, it takes approximately half a second to differentiate between voice and an answering machine if the voice quality is good. When calling cell phones, the voice quality is quite often less than optimal, so it might take the dialer or Voice Gateway a bit longer to differentiate.

Design SCCP Dialer for High Availability


Note


The SCCP Dialer is deprecated in Unified CCE release 10.0(1).


The Outbound Option with SCCP Dialer provides high availability through multiple dialers per Unified CM cluster. Calls are distributed evenly among the dialers. If a dialer fails, the calls are re-routed to the other dialers throughout the enterprise that are configured to support the remaining campaign contacts. The calls that were in progress on the failed dialer are marked for retry.


Note


Campaign Manager and Import process components of Outbound Option are simplex components and must be co-located with the Logger (Side A).


It is normal practice to set up IP phones to be able to fail-over to another Unified CM in case of a Unified CM node failure in which phones are distributed across the cluster. The Dialer is not a normal phone, and the ports for a dialer must not be distributed across multiple nodes within the cluster.

The dialer can tax the Unified CM node when starting a campaign or whenever resources are available (agents or IVR ports for transfer to an IVR campaign). If two dialers are configured to share the Unified CM as part of a distribution or node failure, a high-availability attempt can have a negative performance impact on the rest of the system. Each dialer has its own port throttling mechanism, and is not aware that another dialer may be sharing the same Unified CM. With two dialers competing, the subscriber might enter into a code-yellow condition.

The general rule in configuring the dialers for high-availability is to do no harm. As part of this guideline, be aware that dialers significantly affect Unified CM performance.

Design SIP Dialer for High Availability

The Outbound Option with SIP Dialer provides high availability through fault tolerant design in SIP Dialer, Agent PG and Unified SIP Proxy Server. Many components in the Outbound Option with SIP Dialer are duplicated for redundancy.

Campaign Manager and Import

The Campaign Manager and Import process components of Outbound Option are simplex components and must be co-located with the Logger (Side A).

The Campaign Manager supports a single active dialer per peripheral. Only one SIP Dialer needs to be configured. Install two SIP Dialers on separate PG platforms, but install each using the same Dialer Name.

The peripheral setup program allows users to input the dialer name in the setup page for each SIP Dialer.

When the SIP Dialer starts, it will attempt to register with the Campaign Manager. The Campaign Manager checks if the SIP Dialer is configured based on the dialer name from the registration message. It will reject the registration if it cannot find the configured SIP Dialer with that name. A maximum of two SIP Dialers can register with the same name; the Campaign Manager will reject the registration if that limit is exceeded.

The Campaign Manager activates only one SIP Dialer in the ready state from its registered SIP Dialer pool. If the activated SIP Dialer changes state from ready to not ready due to a failed CTI link to CTI Server or a failed heartbeat to SIP Server, the Campaign Manager activates the standby SIP Dialer.

If the Campaign Manager detects that the connection has failed from the activated SIP Dialer, it will activate the standby SIP Dialer. The Campaign Manager marks all outstanding records with an Unknown status and return them to pending status after a certain time-out period.

SIP Dialer

The SIP Dialer is considered in ready state after it has successfully registered with Campaign Manager, has been configured successfully, has established a CTI connection to CTI Server/Agent PG, and has successfully sent a heartbeat to the SIP Server. The SIP Server can be a gateway or Unified SIP Proxy Server to which the SIP Dialer is connected.

In the case of a CTI link or heartbeat failure, the SIP Dialer sends all active and pending customer records to the Campaign Manager (dialer flush), or closes them internally if the link to the Campaign Manager is not available. The SIP Dialer cancels alerting calls, abandons the connected calls that have not yet transferred to outbound agents or IVR , and leaves the outbound calls that were transferred.

The Dialer sends a heartbeat to the gateway in a single gateway deployment or to the Unified SIP Proxy Server in a multiple gateway deployment. The Dialer transitions to the ready state only when the heartbeat is enabled and the initial heartbeat is successful.

The heartbeat can be disabled by setting the Dialer Registry, EnableHeartBeat=0.

If the heartbeat fails in several attempts defined by the Dialer registry HBNumTries, the SIP Dialer changes the state to not ready and updates the status to the Campaign Manager to trigger the warm standby mechanism.

The gateway or Unified SIP Proxy Server does not play any role in warm standby behavior for the SIP Dialer.

An alarm is raised when the SIP Dialer detects SIP Server heartbeat failure.

CTI Server and Agent PG

Both the activated and standby SIP Dialers maintain active connections to the CTI Server at same time.

If the CTI Server or Agent PG fails to cause the CTI link failure, the SIP Dialer changes the state to not ready and updates the status to the Campaign Manager to trigger the warm standby mechanism.

An alarm is raised when the SIP Dialer detects the CTI link failure.

Cisco Unified SIP Proxy Server

The Unified SIP Proxy Server provides weighted load balancing and redundancy in a multiple gateway deployment by configuring each gateway as the element in the Server group configuration. In the following configuration, one gateway of the elements in the cucm.example.com server group receives 50 percent of the traffic and the other two elements receive 25 percent. You can change the weights and q-values to configure a different priority or load-balancing scheme.

server-group sip group cucm.example.com enterprise
element ip-address 192.168.10.4 5060 tls q-value 1.0 weight 50
element ip-address 192.168.10.5 5060 tls q-value 1.0 weight 50
element ip-address 192.168.10.3 5060 tls q-value 1.0 weight 100
fail-over-resp-codes 503lbtype weightpingend server-group

If one of the gateways is overloaded or loses its WAN link to the PSTN network, the Unified SIP Proxy Server receives a SIP 503 response message. The "fail-over-resp-codes 503" configuration in the Server Group allows the Unified SIP Proxy Server to pick the next available gateway to resend an outbound call.

The Unified SIP Proxy Server supports the Hot Swappable Router Protocol (HSRP), which is a way to build redundancy into your network by allowing two Unified SIP Proxy servers to continuously test each other for connectivity and to take over if a Unified SIP Proxy Server fails.

Because the warm standby feature is already built into the Campaign Manager and SIP Dialer, and because configuring HSRP for the Unified SIP Proxy Server adds undesirable complexity for Outbound Option, do not use the HSRP configuration for the Unified SIP Proxy servers dedicated for Outbound Option.

Server Group and Route Table configurations are duplicated for two duplex Unified SIP Proxy servers.

Cisco Unified Mobile Agent

Mobiles agents are supported for outbound campaigns. However, only a nailed connection is supported. For more details regarding Cisco Unified Mobile Agent, see Cisco Unified Mobile Agent.

References

For more information, see the Cisco Outbound Option documentation.