4 Service Deployment

In order to provide end-to-end connectivity, the media platform or browser that issues requests to the server must be configured properly. Typically, each service is accessed through a specific phone number in the voice and video channel, short code in the text channel, or URL in the Web channel. In this case, the media platform or browser uses a URL pointing to the server that returns the correct markup code (VoiceXML, XHTML, or a USSD markup) for the specific service. The URL mapping can either be specified directly, or a static file can be used to point to the server.

Details on service deployment are provided in the following sections:

· Permanent and Temporary Deployment – describes the two different ways of either permanently or temporarily deploying an application.

· Media Platform Setup – explains how to configure the media platform to connect to the server.

· Service URL Configuration – explains how to pass additional parameters to a service as part of the initial request, and how to make these parameters available in the application.

· Application Defaults – explains how default values for objects used within a service can be set through an XML file.

· Dialog Exit Type – explains the different exit types that are available for leaving a service.

· Connection Test – explains how to test the availability of a service or server.

· Debug Viewer – explains the debug mode functionality and how to use it to test voice, video, text or Web applications when no media platform is available.

· Phone Simulator – explains the phone simulator functionality and how to use it to test and demo applications in the text and Web channel.

Permanent and Temporary Deployment

In addition to permanently deploying an application as a service on a server in the Control Center, VoiceObjects Desktop for Eclipse allows deploying an application temporarily by using the Test Monitor (this option is not available when using Desktop for Web).

Deploy an application permanently

To deploy an application permanently do the following:

1. Create a new Service object and link the object which represents the application you want to call as start object.
i8Note: If you intend to use an existing service replace its start object and redeploy the service in the Control Center. Afterwards proceed with step four.

2. Add the new Service object to the list of hosted services in the Server object you want to use and select Reload Service List from the context menu of the Server object in the Control Center.

3. Start the new service in the Control Center.

4. Point your media platform to the service and call your application. Refer to Media Platform Setup below for more details on how to do this.

For details on how to configure servers and services refer to Chapter 2 – Configuring Servers and Services in the Deployment Guide.

For details on how to manage servers and services in the Control Center refer to Chapter 3 – Managing Servers and Services in the Deployment Guide.

Deploy an application temporarily

To deploy an application temporarily in Desktop for Eclipse do the following:

1. Select the object which represents the application you want to call in the Object Browser, Dialog Designer or Search Result and right-click it. From the context menu select Test Application. The Test Monitor opens up and validates the selected object.

2. Point your media platform to the embedded server. Refer to Connecting to the Media Platform in Chapter 1 – Getting Started with Desktop for Eclipse in the Desktop for Eclipse Guide for a description on how to do this.

3. Call your application by using the Call button in the Test Monitor.
For further details on how to test an application using the Test Monitor refer to Test Application in Chapter 7 – Basic Commands in the Desktop for Eclipse Guide.

Media Platform Setup

There are two possible ways to set up the connection on the media platform or browser.

First, a direct URL connection can be used to point to the server. Second, the server can be called through a static index file.

Desktop for Eclipse also provides a third option to directly include a media platform into Desktop for Eclipse and to call the application from within the Test Monitor. In this case the application is deployed temporarily on the embedded server (see Deploy an application temporarily above). This option should only be used for testing purposes, though.

i8 Note: In case of Web applications built with VoiceObjects, the callers usually need to type the URL into the browser of their mobile device. To avoid lengthy URLs, setup a proxy server with a simple and intuitive URL that redirects requests to the address of VoiceObjects Server.

Direct URL connection

In this case, the media platform uses a URL that points directly to a service hosted on a server. The connection URL should have the following format (assuming the default servlet context is used):

http://server:port/VoiceObjects/DialogMapping?VSN=[VSN]

where

server	denotes the network name or IP address of the physical server running the VoiceObjects Server process. Note that the server machine must be accessible for the media platform, which is especially important if the media platform is located outside the company network. Refer to Connector URL in Chapter 1 – Advanced Configuration of VoiceObjects in the Administration Guide for more details.
port	denotes the connector port for the VoiceObjects Server process. The port is set to 8099 (8070 when connecting to the embedded server in Desktop for Eclipse) by default, but can be modified during installation and configuration. See the Installation Guide for details.
VSN	denotes the unique VoiceObjects Service Name (VSN) that identifies the service when initiating it through an HTTP request from the media platform. Since each service must have a unique VSN, the media platform must be configured in order to map the dialed phone number to the correct VSN. When connecting to the embedded server in Desktop for Eclipse the VSN has to be set to testService.

If a service with the given VSN does not exist, a static failover page will be returned. For more information, refer to Chapter 3 - Managing Servers and Services.

i8 Note: If you deploy a service that supports multiple phone channels, you typically define one default driver in the Service object (for a channel of your choice), and all other platforms need to include the parameter vsDriver in the initial request URL, to start the session for that specific driver. See Service URL Configuration for more information.

VoiceObjects Server also supports the mapping of DNIS (Dialed Number Identification Service) numbers to specific services. To use a DNIS number instead of the VoiceObjects Service Name (VSN) as a mapping to the application, the DNIS must be passed as a parameter in the URL:

http://server:port/VoiceObjects/DialogMapping?DNIS=[DNIS]

where

DNIS

denotes the DNIS on which the incoming call was received.

If no service can be determined for the given DNIS, a static failover page will be returned. For more information, refer to Chapter 3 - Managing Servers and Services.

If both VSN and DNIS are specified, VSN takes precedence.

i8 Note: Initial requests from the media platform that contain neither VSN nor DNIS will normally be rejected by the server. This behavior is configurable, but should typically not be changed.

Static markup

The media platform or browser can also call the server indirectly, i.e. from a static VoiceXML/XHTML/USSD markup file. In this case, the URL has the same format as for a direct URL connection. In voice and video applications, the URL can be called for example in a GOTO statement as shown in the following VoiceXML code:

<?xml version="1.0" encoding="ISO-8859-1"?>

</block>

</form>

</vxml>

This setup can also be used to quickly start playing a welcome prompt to a caller while performing additional background tasks, or to provide a limited amount of failover capability between different server instances. The following VoiceXML code gives an example:

<?xml version="1.0" encoding="ISO-8859-1"?>
<vxml version="2.0" xml:lang="en-US">

    <property name="timeout" value="3s" />
    <property name="fetchtimeout" value="20s" />

    <var name="ANI" expr="session.telephone.ani"/>
    <var name="DNIS" expr="session.telephone.dnis"/>

    <var name="submitURL" expr="'http://
vo-server:8099/VoiceObjects/DialogMapping?VSN=myservice'"/>

As soon as the call comes into the media platform, a jingle is played. In parallel, a new dialog session is initiated on the server running on the machine “vo-server”. Should this fail, an attempt is made to initiate this dialog session on the server running on the machine “backup-server”.

In Web applications, an XHTML page can be prepared that essentially does the same thing: show some welcoming message and provide a button to start the session on VoiceObjects Server. Here is an example:

<?xml version="1.0" encoding="ISO-8859-1"?>

<html>

<body>

<h1>Prime Insurance</h1>

Thanks for calling our service.

<form action="http:// http://voserver:port/VoiceObjects/DialogMapping?VSN=[VSN]"

</form>

</body>

</html>

In text applications, the markup depends on the driver. The following is an example for the Cellicium Cellcube 3.6 USSD browser, which also supports an immediate redirect:

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE pages SYSTEM "cellflash.dtd">

<pages>

</page>

</pages>

The Sicap USSD Menu Browser 3.2 browser uses a small subset of HTML as its markup language, so the code for that platform could look as follows:

<html>

<body>

Prime Insurance.<br/>

Thanks for calling our service.

</body>

</html>

i8 Note: If a media platform or browser applies document caching mechanisms to reduce response times, it might use a cached version of the document rendered by the server in case the URL has the same form as an earlier request. To avoid this add the parameter msec to the request URL with a unique numeric value. This parameter is ignored by the server but prevents the media platform from using a cached document if the value is different on each request.
This is a mechanism that works on all possible platforms, i.e. voice or video platforms, Web and USSD browsers. The following example for voice and video applications shows how to use ECMAScript to generate the value from the timestamp of the server hosting the VoiceXML file:

<?xml version="1.0" encoding="ISO-8859-1"?>

</block>

</form>

</vxml>

Since mobile Web browsers usually do not provide embedded scripting engines, calculating a unique value for the msec parameter is not possible in XHTML for this kind of browsers. Use a CGI script (e.g. JSP) to generate dynamic URLs in this case. The same approach would be required for USSD browsers, due to the same reasons.

Service URL Configuration

A service is usually configured in the Service editor. In addition the service can be (re-)configured at call time by passing configuration parameters to the service in the initial request URL. The supplementary parameters can be passed in the following way, assuming the service is called using the VSN as described in the previous paragraph:

http://server:port/VoiceObjects/DialogMapping?VSN=[ReferenceID]&param=value

The possible parameters are listed in the following table. All parameters are case sensitive and start with the prefix vs for VoiceObjects Service. Variable and layer values can also be passed; they use the var and lay prefix, respectively. Details are also described in the following table.

The legal values for the vsDriver parameter are listed in Appendix A – Media Platform Drivers.

Service URL parameters

Parameter	Description
vsAudioExtension	Overrides the audio file extension specified in the service.
vsBargein	Overrides the default barge-in setting specified in the service. Possible values are true and false.
vsContentType	Overrides the content type specified in the service.
vsDefaultResourcePath	Overrides the default resource path specified in the service.
vsDefaultResourceURI	Overrides the default resource URL specified in the service.
vsDialogTimeout	Overrides the dialog timeout specified in the service. Value is interpreted in seconds.
vsDriver	Overrides the media platform driver specified in the service. In order to activate a specific driver its id or internalName from the configuration file MPDrivers.xml must be provided.
vsExitType	Overrides the dialog exit type specified in the service. Possible values are disconnect, exit, and return.
vsGrammarExtension	Overrides the grammar file extension specified in the service.
vsGrammarControl	Overrides the grammar control setting specified in the service. Possible values are true and false.
vsGrammarMediaType	Overrides the default grammar type specified in the service. Possible values are abnf, gsl, jsgf, srgs_xml, regex, precompiled, and none.
vsGrammarMode	Overrides the default grammar mode specified in the service. Possible values are embedded:external and external:embedded.
vsInputMode	Overrides the default input mode specified in the service. Possible values are voice, dtmf, and voicedtmf.
vsLanguage	Overrides the application language specified in the service.
vsLoggingCategories	Overrides the default logging categories specified in the service. Possible values are comma-separated lists of categories from among info, debug, error, stats, billing.
vsLoggingDestination	Overrides the default logging destination specified in the service. Possible values are db (= Custom DB), file (= Log File), logOSDM (= Log OSDM), sp (= Media Platform), dialogContext (= System DB).
vsOutputMode	Overrides the default output mode specified in the service. Possible values are audio:tts and tts:audio.
vsProxyHost	Overrides the HTTP proxy host specified in the service.
vsProxyPort	Overrides the HTTP proxy port specified in the service.
vsRejectResponse	Overrides the reject response specified in the service. Possible values are overflow and redirect.
vsRecordingScope	Overrides the default recording scope specified in the service. Possible values are all, noMatch, and recognition.
vsRecordUtterances	Overrides the default value of the Record utterances setting specified in the service. Possible values are true and false.
vsRespectUserAgent	Overrides the value of the Respect user-agent in Web channel setting specified in the service. Possible values are true and false.
vsSessionVariables	Overrides the default value of the Session variables setting in the service.
vsStandbyTimeout	Overrides the standby timeout specified in the service. Value is interpreted in seconds.
vsVideoExtension	Overrides the video file extension specified in the service.
varVarID	Overrides the value of the specified variable. VarID must match the reference ID of the variable that should be overwritten with the specified value.
layLayerID	Overrides the initial state of the specified layer. LayerID must match the reference ID of the layer, the default state of which should be overridden with the specified state ID.

The content type of the markup returned to the media platform depends on the selected driver and is set to application/voicexml+xml in most voice and video drivers. To change this value, specify vsContentType as parameter and the required setting as the value in the connection URL.

Variable and collection values can be set by passing the desired value of the variable or collection as the value, and the reference ID of the variable or collection with the prefix var as the parameter name. E.g. to set the value of a variable with the reference ID Status to gold the following parameter/value setting must be appended to the URL:

http://…/DialogMapping/VSN=[VSN]&varStatus=gold

In a similar way, layers can be set to a specific state by passing the ID of the desired state as the value and the reference ID of the layer with the prefix lay as the parameter name. E.g. to set the state of a layer with the reference ID Persona to alice the following parameter/value setting must be appended to the URL:

http://…/DialogMapping/VSN=[VSN]&layPersona=alice

Parameters that cannot be recognized by the prefixes vs, var, or lay will be assumed to be session parameters and are placed into the session context. This includes the parameters ANI, DNIS, RDNIS, MPSID, AAI, CRMID, and GCID. Their values can be retrieved or set using the SESSION() function.

Application Defaults

In addition to passing initial values for objects in the request URL as described above in Service URL Configuration, they can also be provided in an XML file that is referenced within the service definition. Moreover, Variable, Collection and Layer objects can be defined as a parameter in the Expression function APPLYCONFIGURATION(configurationXML).
Note that Resource Locator objects can only be defined through a reference in the service definition.

See Default Parameters in Chapter 2 – Configuring Servers and Services for more information on how to specify the location of this file in a Service object.

@8 Tip: Passing parameters through the initial request URL should be done for all those parameters that are platform-specific, since the request URL is set on the media platform. All those parameters that are application-specific should be defined using the XML file. Note that if an object is defined both in the request URL and in an application defaults file, the request URL takes precedence.

Application defaults are defined using an XML notation. The corresponding XSD file for validation can be found at

...\VoiceObjects\Platform\WEB-INF\schemas\ApplicationConfiguration.xsd

The following code provides a sample configuration:

<?xml version="1.0" encoding="UTF-8"?>

<referenceID>minimumAge</referenceID>

<type>variable</type>

</configuration>

<referenceID>location</referenceID>

<valueURL>http://dataserver/</valueURL>

</configuration>

</configurations>

The entire set of application defaults must be enclosed within a <configurations> element; each individual value assignment must be enclosed within a <configuration> element.

Objects are referenced using their reference ID, which is specified within the <referenceID> element. If a value is specified for a reference ID that does not exist in the application, it is ignored, but a corresponding log message is written to the log file of the server. If the <referenceID> definition is missing altogether in a <configuration> element, deployment fails and a corresponding message is written to the server log file. If more than one entry with the same reference ID exists in the file, the last definition is used and a corresponding log message is written to the server log file.

Optionally, the type of the object can be specified using the <type> element; this is used for validation purposes only. Legal values for the <type> element are variable, collection, layer, and resourceLocator. In case of a mismatch between the specified <type> definition and the actual type of the referenced object, deployment fails and a corresponding message is written to the server log file. Deployment also fails in case of an unknown or misspelled <type> value.

For Variable, Collection, and Layer objects the default value to be assigned is specified using the <value> element.
For Resource Locator objects, the path and URL are defined using the elements <valuePath> and <valueURL>, respectively. If only a <value> definition is present for a resource locator, it is interpreted as <valueURL>. If both <value> and <valueURL> are present, deployment fails and a corresponding error message is written to the server log file.
For Layer objects, the <value> element must hold a valid state ID. If no valid state ID is given, deployment fails as described above.

i8 Note: Leading and trailing blanks are removed if they appear inside <value>, <valueURL>, or <valuePath>. If you need to embed blanks in the value of an object, use the   entity instead.

The file that defines the application defaults is read when the service is started the first time (on server startup, or when adding it to the server's service list and reloading this list), and on each Redeploy or Restore command issued to the service. For more information on these commands, refer to Chapter 3 - Managing Servers and Services.

If a problem occurs during either the reading of the file (e.g. file cannot be found or does not contain valid XML) or the setting of the default values, the Redeploy or Restore fails. In this case, the currently active application remains active (thus, no downtime will occur) and an error message is shown in the tooltip of a yellow triangle icon next to the service in the Control Center, as well as written to the server log file.

Dialog Exit Type

The dialog exit type specifies what happens when the dialog is finished and the call exits the service. This setting is only relevant for voice and video applications. Standard behavior here is “hang up”, which means that the call is terminated and a disconnect VoiceXML is sent to the media platform.

Alternatively, the call can be returned to the calling application. This is usually the case if the call was initiated outside of VoiceObjects. If this dialog exit type was chosen, a VoiceXML with the <return> tag is sent back to the media platform.

Finally, the call can be terminated by using the <exit> tag. This leaves it up to the media platform to decide whether to hang up, or whether to transfer the call to another application or to a human agent.

The behavior in all cases and in call channels is defined by static markup files that are sent to the media platform. The behavior can be modified by adjusting these files, which can be found under

..\VoiceObjects\Platform\Resources\System\VXML\<LanguageCode>\dialogs\VXML\<VoiceXML version>\<Media Platform Provider>\<ProductVersion>\

with the names Disconnect.vxml, Return.vxml, and Exit.vxml.

While they are originally motivated for VoiceXML-based platforms only, they can also be defined in the text and Web channel. The names and extension (.vxml) are the same, though.

i8 Note: This mechanism of using external files is only applied when the dialog finishes because there are no more objects to process or in error cases if there is no error handler defined. It is not applied in case the dialog finishes with an Exit object.

Connection Test

After completing the configuration of the service and setting up connectivity between the media platform and the server, the availability of the server, server instances, and services can be tested. To do this, the following URLs must be loaded e.g. in a Web browser:

http://server:port/VoiceObjects/DialogMapping?ping=server

tests the availability of the server. If a server is available at the specified URL, its reference ID is returned.

http://server:port/VoiceObjects/DialogMapping?ping=instance

tests the availability of a specific server instance. If an instance is available at the specified URL, it returns its current status:

Value	Description
STARTED	The server instance is started and ready to serve requests.
REQUEST_IDLE	The server instance does not accept any new sessions but is still processing currently active sessions.
IDLED	The server instance is idled and does not accept any new sessions.
STOPPED	The server instance is stopped and does not accept any new sessions.

http://server:port/VoiceObjects/DialogMapping?VSN=[ReferenceID]&ping=server

tests the availability of a specific service on the server. Depending on the status of the service, the following values are returned:

Value	Description
UNAVAILABLE	The service is not available, or no service matches the VSN. This may also indicate that the entire server is stopped.
STARTING	The service is currently starting.
STARTED	The service is started and ready to serve requests.
REQUEST_IDLE	The service does not accept any new sessions but is still processing the currently active sessions.
IDLE	The service is idled and does not accept any new sessions.
STOPPING	The service is stopping and aborting all currently active sessions.
STOPPED	The service is stopped and does not accept any new sessions.

Note that in a cluster setup, a service can be in status STARTED yet still not be available on certain server instances since these instances are idled or stopped. To check this, there is the command

http://server:port/VoiceObjects/DialogMapping?VSN=[VSN]&ping=instance

which tests the availability of a specific service on a specific server instance. The result is of the form <Instance status>:<Service status>.
So e.g. in a cluster setup with three instances one of which is idled and the others started, a service that is started on the cluster would produce STARTED:STARTED on the started instances and IDLED:STARTED on the idled instance.

The connection test functionality can be used in combination with a load balancer setup to repeatedly check whether a server running on a specific machine still responds appropriately.

The list of hosts that are allowed to issue ping requests can be restricted using the

setting in the VOServer_Configuration.xml file. The default setting is “*”, which indicates that any host may issue ping requests. It may be set to a comma-separated list of IP addresses or host names, which indicates that only these hosts may issue ping requests. Finally, if left empty then no ping requests are allowed at all.

8 Caution: Note that the old connection test syntax

http://server:port/VoiceObjects/DialogMapping?ping=true

is deprecated.

Debug Viewer

Sometimes it is desirable to test application functionality without having access to a media platform. This can be accomplished by using the Debug Viewer. It is a code viewer that shows the rendered markup for each dialog step and offers ways for the tester to interact with the application. In the voice and video channel, the code is VoiceXML. In the text channel, it is proprietary markup code used by the corresponding platform vendor, whereas in the Web channel it is HTML.

Start a Debug Viewer session

The Debug Viewer is initiated by appending the setting mode=Debug to the initial request URL, which must be called in a Web browser:

http://server:port/VoiceObjects/DialogMapping?VSN=[ReferenceID]&mode=Debug

When using a connector URL (e.g. in case the server is behind a firewall), the externally visible address may not be usable for internal testing. For these cases it is possible to specify a separate address for the debug mode. This is defined using the parameter address in the initial request URL, e.g.

http://…/DialogMapping?VSN=[ReferenceID]&mode=Debug&address=127.0.0.1

All references to the normal server address are replaced by the specified alternative address. All other functionality remains as described above. In addition to the IP address, it is also possible to modify the port by using the notation

http://…/DialogMapping?VSN=[ReferenceID]&mode=Debug&address=127.0.0.1:8097

Note that a Debug Viewer session can also be directly started from within the Control Center using the entry Debug Viewer in a service’s context menu. This entry is only available for started services.

When starting a Debug Viewer session from the Control Center, a dialog box comes up to enter the testing URL to be used for the session. This allows you for example to connect to different server instances within a cluster.

By default, this dialog box contains the testing URL configured in the preferences of this Control Center connection. In Desktop for Web the dialog box contains the testing URL configured in the Server object.

Internally the string DebugviewInfo, the name of the corresponding servlet, is automatically added to the testing URL.

After an IP address and port have been confirmed by clicking OK, the Debug Viewer Configuration window is shown.

In the Parameter(s) field, you may enter additional parameters to be passed to the application, as described in the section on Service URL Configuration. In addition, various parameters such as ANI, DNIS, etc. may be set. The exact list of parameters depends on the media platform that is used. For most of these parameters, default values are provided.

To start the dialog, click the Start Session button. The reply from the server is shown as follows:

The Debug Viewer shows the markup code generated by the server, color-coded and enhanced for HTML display. Blocks of markup code may be expanded and collapsed using the plus [+] and minus [-] buttons. In the voice and video channel, the bottom of the VoiceXML code is displayed first for each dialog step, since this is where the prompts of this step are typically located. Use the scroll bar to move the code up and down, and use the two buttons and to jump to the top or bottom of the code.

Some links in the rendered code are color-coded and clickable. Three different types of active links are available:

Audio files are displayed in red font and can be played in the operating system’s default media player by clicking them.

Grammar files are displayed in blue font and can be viewed in a pop-up window by clicking them.

Requests that go back to the server are displayed in black font and can be activated by clicking them.

How to step through a dialog session

To step through a dialog, either click the black-colored links that lead back to the server, or use the Next Step > button at the top. Additional parameters that you want to include in a request to the server during a dialog session can be added manually in the Parameter(s) text field, if required.
When using the Debug Viewer, do not use the Web browser’s navigation buttons (such as Back), because this will interfere with the navigation logic maintained on the server.
If you want to end a call, click the Hang up button. The last markup page is then rendered, and you can close the window by clicking Close. If you close the Debug Viewer window without hanging up first (using the Close icon on the tab header), the dialog session will remain as an active session on the server until it runs into the dialog timeout.

Hyperlinks in the voice and video channel that lead back to the server can be activated by clicking the black-colored <submit> element associated with a green-colored <link> element.

How to navigate through and interact with an application depends on the object type of the current dialog step.

The following sections describe the interaction with voice and video applications through VoiceXML. In the text and Web channel, corresponding code is shown that also allows interacting with the application.

Output objects

Output objects do not gather any caller input; therefore you can skip them by clicking Next Step >.

Input objects

For Input objects that need to fill slots, input fields are generated below the Parameter(s) field, one for each slot:

To fill the slots, type in the slot values in the format provided by the grammar. Note that you cannot enter real caller utterances in these fields, as there is no parsing of the grammar taking place in the server. Only slot values (i.e. the semantic interpretation) as needed by the Input object are allowed. In a multi-slot example like the above one you can leave out a slot if you want to simulate that only one of several slots has been filled by the caller. If you want to simulate a No Input event in order to auto-advance to the next dialog step, do not click Next Step > with empty slots, but instead click the black-colored <submit> element nested in a <catch event="noinput"> event handler element.

Menu objects

For Menu objects, the server generates <choice> elements that represent the Menu items. To select a Menu item, identify the correct <choice> element by looking at the grammar of that <choice>, and click the black-colored <submit> element located directly above the <choice>.

Confirmation objects

The Confirmation object allows confirming or denying a summary of gathered input items. To confirm, click the <submit> element nested in the <catch event=”summary.yes”> element at the bottom of the VoiceXML code. To deny, click the <submit> element nested in the <catch event=”summary.no”> element.

List objects

The List object allows navigating through a list of items. If you want to use a specific navigation command, enter the required slot value (like nextRow, start, etc.) in the input field called sltNavigation located right below the Parameter(s) field. If you want to simulate a No Input event in order to auto-advance to the next item, click the <submit> element nested in the <catch count="1" event="noinput">.

Pause objects

If the Pause object does not have a redirect object defined, leave the Pause object by clicking Next Step >. If a redirect object is defined, click the <submit> element nested in the <catch event=”noinput”> element with the highest count attribute value, located at the bottom of the VoiceXML code. This value corresponds to the number of reiterations defined in the Pause object, plus 1.

Connector and Script objects

In case a wait loop audio is played while the server is processing a Connector or Script object, simply jump to the next dialog step by clicking Next Step >.

Plug-In objects

Fill any parameters required for a plug-in in the Parameter(s) field and click Next Step >.

Recording objects

Real recordings cannot be simulated with the Debug Viewer. To simply skip a Recording object, click Next Step >.

Transfer objects

Blind transfers will not lead back to the application, instead the platform activates a disconnect.transfer event which will be caught by the server to terminate the dialog session. To simulate a blind transfer, click the black-colored <submit> element below the <catch count="1" event="connection.disconnect.transfer"> event handler which is typically located right above the <transfer> element

i8 Note: If you click Next Step > for a blind transfer, the application continues, which is not the behavior you would get when calling through a media platform.

Bridged transfers do lead back to the application, so simply click Next Step > to simulate a completed transfer.

Exit objects

If an output is defined inside the Exit object, first click Next Step > to leave this dialog step. The Exit object always terminates the session on the server, so the VoiceXML code produced by the Exit object is the last dialog step for an application.

OSDM objects

When using the Debug Viewer in combination with OSDMs, embedded grammar definitions that are passed to the OSDMs in variables cannot be displayed correctly within the Debug Viewer due to the use of masked XML characters. So even though they may look strange in the Debug Viewer output, they are passed correctly into the OSDMs.
Furthermore, if a Variable or Script object as part of an Output object holds XML content that has the structure of a collection (<root> as the top-level element, with <row> and <col> children), it will be read out cell by cell. In the Debug Viewer you will therefore not see the XML structure, but only the text content of the cells. If the XML is of a different structure, the content is fully retained. Note that in this case, the display in the Debug Viewer might be broken if the content holds an XML header (i.e. an XML processing instruction).

Phone Simulator

The Phone Simulator is a graphical tool to simulate calls in the text and Web channels. It can be used to test and demo applications in the text channel when no USSD gateway is available. While the Web channel can easily be tested directly through a browser, Web sessions can also be simulated using this tool. The Phone Simulator shows an image of a mobile phone (offering three different skins) and allows the navigation within an application by entering text or activating hyperlinks.

Start a Phone Simulator session

The Phone Simulator is launched externally by calling the PhoneSimulator servlet in a Web browser:

http://server:port/VoiceObjects/PhoneSimulator?VSN=[ReferenceID]

When using a connector URL (e.g. in case the server is behind a firewall), the externally visible address may not be usable for internal testing. In this case it is possible to specify a separate address for the Phone Simulator. This is defined using the parameter address in the initial request URL, e.g.

http://…/PhoneSimulator?VSN=[ReferenceID]&address=127.0.0.1

All references to the normal server address are replaced by the specified alternative address. All other functionality remains the same. In addition to the IP address, it is also possible to modify the port by using the notation

http://…/PhoneSimulator?VSN=[ReferenceID]&address=127.0.0.1:8097

In addition, the following four parameters can be added to the external request. They will make the configuration page preset the corresponding settings.

Parameter	Description
phoneSimSkin	The desired phone style. This can be one of the three values standard, blackberry, or iphone.
phoneSimHeader	A Boolean parameter with values true (the default) and false. If set to true, the session information will be shown; if set to false, it will not.
phoneSimChannel	The desired phone channel. This can be text (the default) or web.
phoneSimCharLimit	The desired character limit. The default is 182. If the value is not a number or <1, it is set to 182.

A full URL could look like this:

http://localhost:8099/VoiceObjects/PhoneSimulator?VSN=abc&phoneSimSkin=iphone&phoneSimHeader=false&phoneSimChannel=text&phoneSimCharLimit=91

If all four parameters are set, the configuration page is skipped and the dialog is started right away.

Note that a Phone Simulator session can also be directly started from within the Control Center using the entry Phone Simulator in a service’s context menu. This entry is only available for started services. From the upcoming submenu, select the channel you want to test, Text or Web.

When starting a Phone Simulator session from the Control Center, a dialog box comes up that asks for the testing URL to be used for the session. This allows you for example to connect to different server instances within a cluster.

Internally the string PhoneSimulator, the name of the corresponding servlet, is automatically added to the testing URL.

After an IP address and port have been confirmed by clicking OK, the Phone Simulator Configuration window is shown.

To specify the skin, i.e. the image of the phone used during a session, select one of three available skins from the Skin field.
In the Character limit field, specify the character limit to be applied during the session. This can be used in the text channel, to verify whether an output exceeds the allowed number of characters. The default is 182 in non-Unicode USSD deployments. The number of characters is displayed during the session. If an output hits the limit, the number is displayed with red color, otherwise black.
Use the checkbox Show session information during dialog to toggle an info box during a session that shows the following call time details: step number, processing time, current module name, driver, language, and characters used in output.

Navigate in the Phone Simulator

To start the dialog, click the Start Session button in the Phone Simulator Configuration window.

The server opens up the Phone Simulator, showing the information box if selected and the image of the selected phone, and starts the session.

In the text channel, navigation within a session works as follows:

· To reply to a system prompt, first click Reply, either by clicking the link directly, or by clicking the button on the phone right below the link.

· Enter the response by either using the keyboard, or the phone buttons. When clicking a phone button once, the number character is printed on the screen. To get the other available characters on a button, point the mouse to the button, wait for the tool tip to appear, and click the desired character to print it on the screen.

· Send your response by clicking the Send link or the corresponding phone button.

In the Web channel, navigation within a session works as follows:

· To select a hyperlink, radio button, or drop-down entry, simply click it.

· To fill in an input field, enter the text by either using the keyboard or the phone buttons. When clicking a phone button once, the number character is printed on the screen. To get the other available characters on a button, point the mouse to the button, wait for the tool tip to appear, and click the desired character to print it on the screen.

· Send your response by clicking the proceed button.

To end a call, press the red button on the phone. The VoiceObjects logo appears. To close the entire window, press the red button again. To restart the session with the same settings as before, press the green button on the phone.

i8 Note: Font sizes and input fields in the Web channel most likely appear larger in the Phone Simulator than on a real phone. This is due to a technical restriction related to the CSS file used (default.css if no custom file is defined) and can only be changed by manually adjusting the sizes and widths inside the style sheet definition. For demo purposes, a customized CSS file should therefore be deployed, which is optimized for use with the Phone Simulator.