Navigation :

N2IVR (VXML)

Introduction

This section describes a base/typical deployment of the N2IVR product with call control by VoiceXML.

The solution specific applications which must be configured are:

LhoSipApp (SIP in this diagram)
LogicApp (Logic in this diagram)
RtpApp (RTP in this diagram)
RestClientApp (Rest Client in this diagram)
DBApp (DB in this diagram)

The sub-component labelled “IVR” is the n2ivr_vxml.lua script which defines the service logic.

LhoSipApp

The LhoSipApp is responsible for accepting the inbound SIP INVITE request, and handing it off to the LogicApp for call control.

You will need to review and configure the common SIP configuration parameters for this application as described in the Common SIP Configuration page. The default parameters should typically startup and function. Parameter settings are deployment-specific and cannot be generalised here.

In addition, for an IVR deployment of LhoSipApp set the additional parameters:

Parameter rtp_app_name must refer to the name of your RtpApp.
Parameter default_logic_app_name must refer to the name of your LogicApp.

You can only have on LhoSipApp per SIP port number. I.e. you may not use the repeat attribute for this application unless you use multiple SIP ports. The LhoSipApp will communicate with the LogicApp. At the start of the call control it sends the message SCC-HANDLE-ALEG-INBOUND-INVITE. The LhoSipApp will communicate with the RtpApp. When the RTP channel is required it sends the message RTP-ESTABLISH.

LogicApp

Configure a LogicApp as described in the Logic App Configuration page.

Various IVR-specific configuration is required, including application parameters:

The default_lua_lib_path must include the n2sip lua lib path.
The default_rest_app_name should be the name of the RestClientApp for sending HTTP requests to the VoiceXML HTTP server to retrieve VoiceXML documents.

Example:

    <parameters>
        <parameter name="default_lua_lib_path" value="../lua/lib/?.lua;../lua/lib/3rdparty/?.lua;../../n2sip/lua/lib/?.lua"/>
        <parameter name="default_rest_app_name" value="VXML-REST-Client"/>
        ...

The LhoSipApp::LhoSipOutcallLuaAgent and VxmlLuaAgent agents must be configured. The IVR uses the first to do outbound dialling at the end of VoiceXML interaction, and the second to communicate with the RestClientApp application to retrieve VoiceXML documents.

Example:

    <agents>
      <agent module="LhoSipApp::LhoSipOutcallLuaAgent" libs="../../n2sip/apps/lho_sip/lib"/>
      <agent module="VxmlLuaAgent" libs="../../n2sip/apps/vxml_lua_agent/"/>
    </agents>

There must be an LhoSipIncallLuaService configured which handles the SIP incall sequence which begins when the LogicApp receives SCC-HANDLE-ALEG-INBOUND-INVITE:

    <service module="LhoSipApp::LhoSipIncallLuaService" libs="../../n2sip/apps/lho_sip/lib" script_dir="../../n2sip/lua/svc">
        <globals>
            <!-- global configuration for the VXML IVR service -->
        </globals>
        <triggers>
            <!-- Triggers for inbound calls to trigger the service n2ivr_vxml -->
            <trigger called_prefix="64" script_key="n2ivr_vxml"/>
        </triggers>
    </service>

This must have:

At least one trigger entry in triggers which points to the n2ivr_vxml script containing the IVR control logic.
Any <global> configuration for N2IVR VXML globasl configured to override VXML IVR service defaults.

For an example of a configured LhoSipIncallLuaService, see the application configuration page.

The LogicApp may have the “repeat” attribute configured to run multiple instances sharing system load.

The LogicApp will communicate with the LogicApp by responding to the SCC-HANDLE-ALEG-INBOUND-INVITE message and subsequently exchanging messages to control the RTP stream and the SIP call.

RtpApp

The RtpApp should be configured as as described in the RTP App Configuration page.

The RtpApp may have the “repeat” attribute configured to run multiple instances sharing system load, and this is typically required for deployments which are expected to operate more than 100 channels. Refer to the RTP App Configuration page especially for information how RTP port assignment functions when using the “repeat” attribute.

The RtpApp will communicate with the LhoSipApp by responding to the RTP-ESTABLISH message and processing RTP-PLAY/RTP-PLAYED messages.

The RtpApp will communicate with the DBApp by sending DB-REQUEST to fetch audio metadata and audio data from the database.

Note: The RtpApp can also be configured to operate from flat file configuration/audio without using the database.

DBApp

The DBApp should be configured as as described in the DB App Configuration page.

The DBApp may have the “repeat” attribute configured to run multiple instances sharing system load. It may be desirable to run more than one copy of the DBApp in order to reduce set-up latency.

The DBApp for RTP operates in DBI mode.

The DBApp responds to the DB-REQUEST messages received from the RtpApp and returns DB-RESPONSE messages.

RestClientApp

The RestClientApp should be configured as as described in the REST Client App Configuration page.

The RestClientApp may have the “repeat” attribute configured to run multiple instances sharing system load. It may be desirable to run more than one copy of the app in order to reduce single-CPU load.

It is also suggested that the number of concurrent client connections (num_client_connections) is configured to be (in aggregate across the number of repeated app instances) a number in excess of (number of calls per second * estimated max seconds for VoiceXL server to respond) For example, if the VoiceXML server will take at most 3 seconds to respond (e.g. at the 99%-ile), and the max CAPS is anticipated to be 50, then in aggregate the number of client connections should be set to at least 150.

It is suggested that the server_timeout be set to at most the maximum anticipated (and reasonable) time for a VoiceXML server response.