Configuration Guide for Cisco Unified Customer Voice Portal, Release 10.0(1)
Configure High Availability for Unified CVP
Downloads: This chapterpdf (PDF - 1.39MB) The complete bookPDF (PDF - 6.6MB) | The complete bookePub (ePub - 2.17MB) | Feedback

Configure High Availability for Unified CVP

Configure High Availability for Unified CVP

Server Groups

A Server group is a dynamic routing feature that enables the originating endpoint to have knowledge of the status of the destination address before attempting to send the SIP INVITE. Whether the destination is unreachable over the network, or is out of service at the application layer, the originating SIP user agent can have fore-knowledge of the status through a heartbeat mechanism.

The Server Groups add a heartbeat mechanism with endpoints for SIP. This feature enables faster failover on call control by eliminating delays due to failed endpoints.

The following list is a summary of important configuration items:

  • Server Groups are not automatically added to your configuration. You must explicitly configure Server Groups for their deployment and turn on this feature.

  • If you have already configured the local SRV feature and therefore created a srv.xml file, you must run the srvimport.bat command before you configure Server Groups using the Operations Console. Otherwise, your existing definitions will be overwritten. This process is explained in the configuration details that follow.

  • You define Server Groups using the Operations Console. You must always configure at least one Call Server first, because you will not be able to save the Server Groups configuration without assigning it to at least one Call Server.

Configure Server Groups

Complete the following steps to configure Server Groups:

  1. If you have previously created an srv.xml file, after you upgrade your Unified CVP installation, run the batch file srvimport.bat to transfer your prior configuration to the new Server Groups feature.

    The srvimport.bat file is located in the CVP bin directory. This batch file takes your srv.xml file as an argument. Copy this file from your Call Server configuration directory. Running srvimport.bat brings this configuration data into the Operations Console.


    Note


    You must stop the OAMP (Operations Console) service before you run the .bat file.
  2. If you have not defined a Call Server using the Operations Console, refer to Configuring a Call Server in the Operations Console online help.

  3. From the Operations Console, click System > SIP Server Groups > Add New SIP Server Group.

  4. A Server Group consists of one or more destination addresses (endpoints) and is identified by a Server Group domain name. This domain name is also known as the SRV cluster name, or Fully Qualified Domain Name (FQDN). Define the FQDN and add it to the list. Refer to Configuring Server Groups in the Operations Console online help.

  5. Refer to SIP Server Group Configuration Settings in the Operation Console online help to complete the Server Group configuration.

  6. Click the Call Server Deployment tab and select the Call Server(s) that you want to associate with the Server Group(s). The click Save & Deploy .

Server Groups Diagnostics

The CVP log file has traces which show endpoint status events. From the diagnostic servlet, click on the link for dump SIP state machine to display information as shown in the following example:

Figure 1. Server Group Diagnostics



Redundancy and Failover for Unified CVP

This section describes redundancy and failover mechanisms for ASR, TTS, Media, and VXML Servers in the Unified CVP solution.

Redundancy for VXML Server Applications

VXML Server applications rely on the gateway’s configured default for ASR and TTS servers, which allow only a single host name or IP address to be specified for each. This differs from the Unified CVP micro-applications based applications, which support automatic retries to specifically named backup ASR and TTS servers.

Use the following configuration on the gateway if you are using Nuance or Scansoft ASR/TTS servers:

                            ip host asr-en-us 10.10.10.1
                            ip host tts-en-us 10.10.10.2
                        

Use the following configuration on the gateway if you are using Nuance or Scansoft ASR/TTS servers:

                            mrcp client rtpsetup enable
                            ivr asr-server rtsp://asr-en-us/recognizer
                            ivr tts-server rtsp://tts-en-us/synthesizer
                            http client cache memory pool 15000
                            http client cache memory file 500
                            ivr prompt memory 15000
                            ivr prompt streamed none
                            mrcp client timeout connect 5
                            mrcp client timeout message 5
                            rtsp client timeout connect 10
                            rtsp client timeout message 10
                            vxml tree memory 500
                            http client connection idle timeout 10
                            no http client connection persistent
                        

The URL configured by the above ivr commands defines the gateway's default target for ASR and TTS services, and is in effect for all calls handled by that gateway. You can override it dynamically in your VXML Server application by populating the Cisco-proprietary VoiceXML properties com.cisco.asr-server or com.cisco.tts-server.

Redundancy for Micro-App-Based Applications

When ACE is used for ASR or TTS servers, the IVR Service plays a significant role in implementing a failover mechanism for Media Servers, ASR/TTS Servers and micro-app-based applications. Up to two of each such servers are supported, and the IVR Service orchestrates retries and failover between them.


Note


This redundancy mechanism is only available for Unified CVP micro-applications.

Note


For information about setting up the IVR Service to accommodate failover, see the Cisco Unified Customer Voice Portal Administration Guide.

IVR Service Failover Mechanism

The IVR Service failover mechanism applies to:

  • Connections between the IVR Service and the IOS Voice Browser, only.

  • All communication between the IOS Voice Browser and an ASR Server, TTS Server, or Media Server.

  • Media Server, when the ICM Script ECC variable, user.microapp.media_server, is set to mediaserver. When user.microapp.media_server is set to mediaserver, the IVR Service uses the IP Address defined on the gateway as:

    • ip host mediaserver 10.86.129.50

    • ip host mediaserver-backup 10.86.129.51


    Note


    If user.microapp.media_server is configured as the hard-coded IP Address of the media server, then the IVR Service will not perform any failover for the media server.

If the IVR Service receives a Call Result error code value of 9 (MEDIA_FILE_NOT_FOUND), 33 (GENERAL_ASR_TTS), 31 (MEDIA_RESOURCE_ASR) or 32 (MEDIA_RESOURCE_TTS), it does the following:

  • When attempting to connect to a Media Server , the IVR Service:

    • Resends the request the number of times defined in the IVR Service Configuration's Media Server Retry Attempts field.

    • If the connection is not successful after the specified number of attempts, and the IVR Service Configuration's Use Backup Media Servers field is set to Yes (the default), the IVR Service makes the same number of attempts to retrieve the media from a backup media server before failing and generating an error.


      Note


      The backup media server is defined on the gateway as <mediaserver>-backup.
    • Passes the error in a Call State Event to the ICM Service, which then passes it to Unified ICME.

  • When attempting to connect to an ASR/TTS Server, the IVR Service:

    • Resends the request the number of times defined in the IVR Service Configuration's ASR/TTS Server Retry Attempts field.

    • If the connection is not successful after the specified number of attempts, and the IVR Service Configuration's Use Backup ASR/TTS Servers field is set to Yes (the default), the IVR Service makes the same number of attempts to connect to a backup ASR/TTS server before failing and generating an error.


      Note


      The backup ASR and TTS servers are defined on the gateway as asr-<locale>-backup and tts-<locale>-backup.
    • Passes the error in a Call State Event to the ICM Service, which then passes it to Unified ICME.

Each new call attempts to connect to the primary server. If failover occurs, the backup server is used for the duration of the call; the next new call will attempt to connect to the primary server.


Note


This failover mechanism differs from that used in prior releases of Unified CVP software. Legacy releases used a sticky connection. In a sticky connection, if failover occurs to a backup server, subsequent new calls automatically connect to the backup server, rather than attempt to connect with the primary server.

Configure Speech Server

Before You Begin

Install the Remote Operations in the Speech Server before you add the Speech Server to the Operations console.

Procedure
    Step 1   From the Operations Console, select Device Management > Speech Server.
    Step 2   Click Add New to add a new Speech Server or click Use As Template to use an existing template to configure the new Speech Server.
    Step 3   Click the following tabs and configure the settings based on your call flow model:
    1. General tab. For more information, see General Settings.
    2. Device Pool tab. Add the Speech Server to a device pool by moving the device pool from Available pane to the Selected pane. For more information about adding, deleting, and editing device pool, see Add or Remove Device From Device Pool.
    Step 4   Click Save to save the settings in the Operations Server database. Click Save and Deploy to deploy the changes to the Speech Server page later.

    Application Control Engine for Load Balancing in Unified CVP

    For configuration details, refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide.

    ACE provides load-balancing services for HTTP, MRCP and RTSP traffic, but not for call control signaling SIP messages. As a load-balancing device, ACE determines which server in a set of load-balanced servers, should receive the client request for service. Load balancing helps fulfill the client request without overloading either the server or the server farm as a whole. Also, by monitoring the state of each server and transferring a server's load to a working server during a server failure, ACE provides high availability support.

    In this application of ACE, the engine is used primarily to direct initial session requests for a particular type of service. There are four types of services:

    • http prompts

    • ASR/TTS

    • Unified CVP Call Server

    • Unified CVP VXML Server

    The following general approach applies to configuring each Unified CVP component type for use with ACE.

    • Real Servers - One ACE real server is configured for each group of Unified CVP components (Call Servers, VXML Servers, etc.) that need ACE Load balancing. For general step-by-step guidelines for configuring Real Servers, refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide

    • Server Farms - Typically, in data centers, servers are organized into related groups called server farms. Servers within server farms often contain identical content (referred to as mirrored content) so that if one server becomes inoperative, another server can take its place immediately. After you create and name a server farm, you can add existing real servers to it and configure other server-farm parameters, such as the load-balancing predictor, server weight, backup server, health probe, and so on. For general step-by-step guidelines for configuring server farms, refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide

    • Health Monitoring - You can instruct the ACE servers to check the health of servers and server farms by configuring health probes (sometimes referred to as keepalives). After you create a probe, you assign it to a real server or a server farm. A probe can be one of many types, including TCP, ICMP, Telnet, or HTTP. The ACE server sends out probes periodically to determine the status of a load-balanced server, verifies the server response, and checks for other network problems that may prevent a client from reaching a server. For general step-by-step guidelines for configuring probes, refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide

    • Class-Map and Policy Map - The ACE server uses several configuration elements to filter traffic and then to perform various actions on that traffic before making the load-balancing decision. These filtering elements and subsequent actions form the basis of a traffic policy for server load balancing. For general step-by-step guidelines for configuring traffic policies, refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide

    Specific component-type configuration is covered in the following sections.

    In this section, you will configure the probes and other configuration needed for the ACE server to ensure that each server in each server farm is operating properly, so that the ACE server can load balance between all the servers of each type that are usable at any given moment.

    Figure 2. Application Control Engine for Load Balancing in Unified CVP



    General Probes

    In your ACE unit's configuration, create an ICMP probe to check for server connectivity. In the sub topics that follow you associate this probe with each of your real servers.

    probe icmp PROBE_SERVICE_ICMP
    interval 5
    receive 3
    faildetect 1
    passdetect interval 5
    passdetect count 1
    

    Unified CVP Media Servers

    Media Servers are standard web servers that are responsible for serving Unified CVP prompt files to the voice gateway.

    Create an HTTP Probe

    The probe below is used to determine whether the Media Server is operating properly. A simple HTTP request is sent to the Media Server and the probe does a check for HTTP return code 200.

    The Media Server probe sends an HTTP request to /index.html. The request is sent to the default HTTP port (80) and the IP address of the real server associated with the probe.

    In the probe below, the following parameters are set. Set the actual values according to your own requirements. Refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide.

    To create the HTTP probe for the media servers, place the following code in the configuration for the ACE server.

                                probe http PROBE_HTTP
                                interval 5
                                receive 3
                                faildetect 1
                                passdetect interval 5
                                passdetect count 1
                                request method get url /index.html
                                expect status 200 200
                                open 1
                            

    Configure the Physical Servers

    Create a real server for every physical media server you would like to load balance. Associate the ICMP probe with each server by creating a section, as shown in the following example, for each media server in the server farm.

                                rserver host mediaServer1
                                ip address 10.1.1.1
                                probe PROBE_SERVICE_ICMP
                                inservice
                                rserver host mediaServer2
                                ip address 10.1.1.2
                                probe PROBE_SERVICE_ICMP
                                inservice
    
                            

    Group Your Physical (Media) Servers

    In the ACE configuration file, create a server farm and associate servers with this farm. The following example applies the HTTP Probe to the server farm and the ACE server probes each media server in the server farm. However, you can also associate this probe with the physical server.


    Note


    By specifying the port, only connections on this port will be accepted by this server farm.
                                serverfarm host media_server_FARM
                                description Media Server Farm
                                probe PROBE_HTTP
                                rserver mediaServer1 80
                                inservice
                                rserver mediaServer2 80
                                inservice
                            

    Class Map Configuration

    The configuration below defines a Layer 3 and a Layer 7 class-map.

    • The Layer 3 class-map is used to define a Virtual IP and the allowed traffic port. This class map gets applied to the Layer 3/4 policy-map. Traffic sent to the virtual IP is directed by the ACE server to real media servers based on the load balancing policy.

    • The Layer 7 class-map is used to filter traffic based on the URL pattern specified. This class-map is associated with a Layer 7 policy-map, which contains information about which servers to load balance.

    When traffic entering the ACE server matches the class-map L3_Media_Server_VIP, the ACE server applies the actions specified in Media_Server_L7SLB, which is defined below.

                                class-map match-all L3_Media_Server_VIP
                                2 match virtual-address 10.1.1.3 tcp eq www
    
                                class-map type http loadbalance match-all L7_HTTP_CLASS
                                2 match http url .*

    Policy Map Configuration


    Note


    In the code below, the layer 7 class map gets associated with the layer 7 policy map.
                                policy-map type loadbalance first-match Media_Server_L7SLB
                                class L7_HTTP_CLASS
                                serverfarm media_server_FARM
    
                                policy-map multi-match POLICY
                                class L3_Media_Server_VIP
                                loadbalance vip inservice
                                loadbalance policy Media_Server_L7SLB
                                loadbalance vip icmp-reply active
                            

    ASR/TTS Servers

    Probe

    The probe below is used to determine whether the MRCP ASR/ TTS Server is up. The ACE server makes a connection to the MRCP port to validate that the ASR/TTS server is running. In the configuration below, a TCP probe is used. The probe waits for the configured 3 seconds to receive information from the server. The ASR/TTS service is considered down if the ACE server is unable to connect to port 554 for MRCP traffic.

    In the probe below, the parameters are set. Set the actual values according to your own requirements. Refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide.

    The following configuration example is part of the ACE server's configuration.

                                probe tcp PROBE_ASR_TTS
                                port 554
                                interval 5
                                receive 3
                                faildetect 1
                                passdetect interval 5
                                passdetect count 1
                                open 1
                            

    Real Server and Server Farm Configuration

    The following code defines your physical servers and associates them with the ICMP probe.

                                rserver host asrtts1
                                ip address 10.1.1.12
                                probe PROBE_SERVICE_ICMP
                                inservice
                                rserver host asrtts2
                                ip address 10.1.1.13
                                probe PROBE_SERVICE_ICMP
                                inservice
                            

    The following code defines your server farms and associates them with the PROBE_ASR_TTS probe. The servers in the server farm only accept connections on port 554.

                                serverfarm host ASR
                                description ASR Farm
                                probe PROBE_ASR_TTS
                                rserver asrtts1 554
                                inservice
                                rserver asrtts2 554
                                inservice
                                serverfarm host TTS
                                description TTS Farm
                                probe PROBE_ASR_TTS
                                rserver asrtts1 554
                                inservice
                                rserver asrtts2 554
                                inservice
                            

    Class-map Configuration

    Create a class-map that accepts connections only on port 554. (By default, rtsp maps to port 554.)

                                class-map match-all ASR_CLASS_L3
                                2 match virtual-address 10.1.1.14 tcp eq rtsp
    
    
                                class-map match-all TTS_CLASS_L3
                                2 match virtual-address 10.1.1.18 tcp eq rtsp

    Policy-map Configuration

                                policy-map type loadbalance first-match ASR_POLICY_L7
                                class class-default
                                serverfarm ASR
    
                                policy-map type loadbalance first-match TTS_POLICY_L7
                                class class-default
                                serverfarm TTS
                                policy-map multi-match POLICY
                                class ASR_CLASS_L3
                                loadbalance vip inservice
                                loadbalance policy ASR_POLICY_L7
                                loadbalance vip icmp-reply active
                                class TTS_CLASS_L3
                                loadbalance vip inservice
                                loadbalance policy TTS_POLICY_L7
                                loadbalance vip icmp-reply active
                                inspect rtsp
                            

    ASR and TTS Server Location Setup

    Specify an ASR and TTS Server Location Globally on the Gateway

    Media server sessions are created for each call to IVR applications, regardless of whether an application needs to communicate with the media server. Follow these steps to specify an ASR and TTS server location globally on the gateway.

    Procedure
      Step 1   Define the Hostname to IP Address mapping for the ASR and TTS servers.
      ip host asr-en-us 10.78.26.31
      ip host tts-en-us 10.78.26.31
      Step 2   Define the Voice class URI that matches the SIP URI of the ASR Server in the dial-peer.
      voice class uri TTS sip
      pattern tts@10.78.26.31
      Step 3   Define the Voice class URI that matches the SIP URI of TTS server in the dial-peer. Syntax - voice class uri tag sip.
      voice class uri ASR sip
      pattern asr@10.78.26.31
      Step 4   Define the SIP URI of the ASR and TTS Server. Syntax -sip:server-name@host-name | ip-address.
      ivr asr-server sip:asr@10.78.26.31
      ivr tts-server sip:tts@10.78.26.31
      Step 5   Set up a SIP VoIP dial-peer that is an outbound dial-peer when the Gateway initiates an MRCP over SIP session to the ASR server.
      dial-peer voice 5 voip
      session protocol sipv2
      destination uri ASR
      dtmf-relay rtp-nte
      codec g711ulaw
      no vad
      Step 6   Set up a SIP VoIP dial-peer that is an outbound dial-peer when the Gateway initiates an MRCP over SIP session to the TTS server.
      dial-peer voice 6 voip
      session protocol sipv2
      destination uri TTS
      dtmf-relay rtp-nte
      codec g711ulaw
      no vad
      Step 7   Specify the name or IP address of a SIP server; usually a proxy server. You can then configure the dial-peer session target as session target sip-server. Syntax - sip-server {dns:[host-name] |ipv4: ip-addr[:port-num]}.
      sip-ua
      sip-server ipv4:10.78.26.31

      Specify an ASR and TTS Server Location with an Individual VoiceXML Document

      Media server sessions occur for each call to that application. If only a small number of applications require TTS/ASR media sessions, use the <property> extensions within those applications to define the external media server URL in the VoiceXML script.


      Note


      Specifying the URL of media servers in a VoiceXML document takes precedence over the gateway configuration. Any value that is configured on the gateway is ignored if the same attribute is configured with a VoiceXML property.


      com.cisco.tts-server

      The “com.cisco.tts-server” allows the document to specify an external media server for text-to-speech operations. The media server is specified in the form of an URI, and is used in all consecutive ASR operations until the next media server is specified. An external media server specified by a property in the script takes precedence over being specified by a command through the CLI.

      It can be defined for:

      • An entire application or document at the <vxml> level

      • A specific dialog at the form or menu level

      • A specific form item

      You can format the media server URI for Media Resource Control Protocol version 1 (MRCP v1), which uses Real Time Streaming Protocol (RTSP); or MRCP v2, which uses Session Initiation Protocol (SIP), for example:

      <property name="com.cisco.tts-server" value="rtsp://tts-server1/synthesizer" />

      <property name="com.cisco.tts -server" value="sip:mresources@mediaserver.com" />

      com.cisco.asr-server

      The “com.cisco.asr-server” allows a document to specify an external media server for automatic speech recognition operations. The media server is specified in the form of an URI, and is used in all consecutive ASR operations until the next media server is specified. An external media server specified by a property in the script takes precedence over being specified by a command through the CLI.

      The media server's URI can be formatted for Media Resource Control Protocol version 1 (MRCP v1) which uses RTSP or MRCP v2, which uses SIP, for example:

      <property name="com.cisco.asr-server" value="rtsp://asr-server1/synthesizer" />

      <property name="com.cisco.asr -server" value="sip:mresources@mediaserver.com" />

      Set Up the VoiceXML Document Properties
      Procedure
        Step 1   In Unified Call Studio, view the properties for the AgeIdentification.
        Step 2   Specify the VoiceXML document properties at either the root or node level.
        Step 3   Select Properties > General Settings > Language, and specify “en–us” as the language.

        Certain third-party software and hardware are compatible only with US English.


        Example Gateway Configuration for MRCPv2 with Failover

        -----------------Primary Server-----
        ip host asr-en-us 10.78.26.83
        ip host tts-en-us 10.78.26.83
        ivr asr-server sip:asr@asr-en-us
        ivr tts-server sip:tts@tts-en-us
        
        voice class uri ASR sip
        pattern asr@asr-en-us*
        voice class uri TTS sip
        pattern tts@tts-en-us*
        
        dial-peer voice 5 voip
        destination uri ASR
        session target ipv4:10.78.26.83
        session protocol sipv2
        dtmf-relay rtp-nte
        codec g711ulaw
        no vad
        
        dial-peer voice 6 voip
        destination uri TTS
        session target ipv4:10.78.26.83
        session protocol sipv2
        dtmf-relay rtp-nte
        codec g711ulaw
        no vad
        
        -------Backup --------------------
        dial-peer voice 7 voip
        destination uri ASR
        session target ipv4:10.78.26.20
        session protocol sipv2
        dtmf-relay rtp-nte
        codec g711ulaw
        preference 2
        no vad
        
        dial-peer voice 8 voip
        destination uri TTS
        session target ipv4:10.78.26.20
        session protocol sipv2
        dtmf-relay rtp-nte
        codec g711ulaw
        preference 2
        no vad     

        Unified CVP Call Servers


        Note


        Call Server load balancing is only supported on IVR only deployments.

        Probes

        The probe below is used to determine whether the Call Server is up and in service. The probe passes only if the Call Server is In Service. This probe is an HTTP probe using the ACE server.

        The ACE server Call Server probe sends an HTTP request to /cvp/VBServlet?MSG_TYPE=HEARTBEAT&TIMEOUT=0. This probe takes a little more than 4 seconds to send back a response. If the Call Server is In Service, the HTTP 200 OK response returns.

        Refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide.

        To create the Call Server HTTP probe, place the following lines in the configuration for the ACE server:

                                    probe http PROBE_CALLSERVER_HTTP
                                    port 8000
                                    interval 6
                                    faildetect 1
                                    passdetect interval 6
                                    passdetect count 1
                                    receive 5
                                    request method get url /cvp/VBServlet?MSG_TYPE=HEARTBEAT&TIMEOUT=0
                                    open 1
                                    expect status 200 200
                                

        QoS for Unified CVP Call Server

        Quality of Service (QoS) is the measure of transmission quality and service availability of a network (or internetworks).


        Note


        For more information about defining QoS criteria, see the latest Enterprise QoS Solution Reference Network Design Guide.

        For more information to create policy based QOS, see section Create Policy Based QoS.

        Unified CVP VXML Servers

        Real Servers: Configure the Physical Servers

        Create a real server for every physical VXML Server you would like to load balance. Associate the probe with each server by creating a section, as shown in the following example, for each VXML server in the server farm.

                                    rserver host vxml1
                                    probe PROBE_SERVICE_ICMP
                                    ip address 10.1.1.15
                                    inservice
                                    rserver host vxml2
                                    probe PROBE_SERVICE_ICMP
                                    ip address 10.1.1.16
                                    inservice
                                

        HTTP Probe Configuration

        The probe below is used to determine whether the VXML Server is up and in service. The probe passes only if the VXML Server is In Service . To create the VXML Server HTTP probe, place the following lines in the configuration for the ACE server.

        The VXML Server probe sends an HTTP request to /CVP/Server?probe=true. If the VXML Server is up and inservice, HTTP 200 OK is returned. In the HTTP probe below, the http request is made to the port specified in the probe and the IP of the real server that this probe is associated with.

                                    probe http PROBE_VXMLSERVER_HTTP
                                    port 7000
                                    interval 5
                                    receive 3
                                    faildetect 1
                                    passdetect interval 5
                                    passdetect count 1
                                    request method get url /CVP/Server?probe=true
                                    expect status 200 200
                                    open 1
                                

        Note


        In order to get the "?", press CTRL-V before pressing the question mark.

        Server Farm Configuration

                                    serverfarm host vxmlserver
                                    probe PROBE_VXMLSERVER_HTTP
                                    rserver vxml1 7000
                                    inservice
                                    rserver vxml2 7000
                                    inservice
                                

        Sticky Server Farm

        For a VXML Server to preserve HTTP session information, you must ensure that, once the ACE server has chosen a particular VXML Server from the list of servers in a server farm, the ACE server continues to send all traffic for that session to the same VXML Server. To accomplish this, use a sticky group .

        Refer to the Cisco ACE 4700 Series Appliance Server Load-Balancing Configuration Guide.

        The following definitions apply to the settings shown below:

        • http-cookie: Sticky method being used. In this method, when the ACE server examines a request for content, and determines through policy matching that the content is sticky, the ACE server examines any cookie or URL present in the content request. The ACE server uses the information in the cookie or URL to direct the content request to the appropriate server.

        • Cookie insert: The ACE server inserts the cookie on behalf of the VXML Server upon the return request, so that the ACE server can perform cookie stickiness even when the VXML servers are not configured to set cookies. The cookie contains information that the ACE server uses to ensure persistence to a specific real server.

        The following ACE server configuration code accomplishes the sticky function.

                                    sticky http-cookie ACE_COOKIE VXMLServer_HTTP_STICKY
                                    cookie insert
                                    serverfarm vxmlserver
                                

        Class map Configuration

                                    class-map match-all vxmlserver_HTTP_CLASS_L3
                                    2 match virtual-address 10.1.1.17 tcp eq 7000
                                

        Policy map Configuration

                                    policy-map type loadbalance first-match vxmlserver_HTTP_POLICY_L7
                                    class L7_HTTP_CLASS
                                    sticky-serverfarm VXMLServer_HTTP_STICKY
        
                                    policy-map multi-match POLICY
                                    class vxmlserver_HTTP_CLASS_L3
                                    loadbalance vip inservice
                                    loadbalance policy vxmlserver_HTTP_POLICY_L7
                                    loadbalance vip icmp-reply active