General
CCXML is supported on VP 4.0 and later.
No. AVP 3.0 does not support the call recording functionality.
Yes, DD 4.0 does support outbound calling through CCXML. The FindADoctorCC CCXML sample application explains how to initiate an outbound call. This sample application comes bundled with Dialog Designer 4.0 installer. The DD 4.0 installer can be downloaded from the http://www.avaya.com/devconnect . The sample application is available in the directory < InstallPath >\Sample Applications\files\DialogDesigner_3.1_SampleApplications\ workspace\FindADoctorCC.
Outbound calling using outcall web service needs Avaya Special Application feature, SA8874, enabled on the Avaya Communication Manager. Use Avaya Communication Manager 3.1 build 369 or later with the Avaya Special Application SA8874 feature. Without this feature, supervised transfers do not have access to call progress information and will behave as blind transfers.
No. The full VoiceXML 2.1 conformance (such as handling all of the possible failure conditions properly) for < data > tag is not supported in Avaya Voice Portal versions prior to 4.0.
Voice Portal 4.x supports only VXML 2.0 compliant applications. Applications designed using Conversant-specific scripting languages (TAS, IRAPI) cannot be migrated to Voice Portal 4.x.
The current version of Voice Portal (version 4.x) only supports IBM and Nuance Speech Recognizers. Additional vendors may be supported in the future.
A Dialog Designer (and Voice Portal) license is required in order to run Dialog Designer applications deployed on a Voice Portal system.
Voice Portal 4.1 (Media Processing Platform) does not support mutual authentication with any application server (for Example: IBM WebSphere Application Server). The certificate provided by an application is used by Media Processing Platform (MPP) to trust an application server. Voice Portal does not provide an authentication certificate for an application server to trust MPP.
For both Avaya Interactive Response (IR) and Avaya Voice Portal, the browser has a default timeout set to 15 seconds.
The procedure to change the default timeout for the Avaya Voice Browser on the Avaya Voice portal (AVP) is shown by the following screenshots.
Save and apply the changes.
Note: Voice Portal does not indicate a separate service pack version number. On installing a service pack, the version number for the software is updated (For example: 4.1.0.1.2707).
Version numbers for Voice Portal components such as Voice Portal Management System (VPMS) and Media Processing Platform (MPP) are listed as shown below.
Log on to Voice Portal Management System (VPMS), as shown below:
The version number for Voice Portal Management System (VPMS) can be found on the VPMS home page or under System Maintenance -> System Monitor -> VPMS details as shown below.
The version number for Media Processing Platform (MPP) can be found under System Maintenance -> System Monitor -> MPP as shown below:
To fix the above issue, the following patches should be installed:
- Voice Portal Service Pack 4.1.0.1-2701.
- MPP hot-fixes wi00089856 and wi00075203
WebLM supports the following combinations of Tomcat and JRE:
- Java - JRE 1.4.2_03 Servlet container - Tomcat 5.0.28
- Java - JRE 1.5.0_02 Servlet container - Tomcat 5.5.9
The session variable available in VXML application has an attribute named channel which returns the port number on which the call resides.
The value in the channel attribute can be accessed by the following methods:
- For a Dialog Designer VXML (speech) application, the channel field (attribute) can be
accessed under
session variable through the project.
variables form as shown below.
- This attribute value can be fetched at runtime by overriding the servlet implementation
method as
shown by the sample code snippet below:
public void servletImplementation(SCESession mySession) { // TODO Auto-generated method stub super.servletImplementation(mySession); IVariableField field = mySession.getVariableField(IProjectVariables.SESSION, IProjectVariables.SESSION_FIELD_CHANNEL); String channel = field.getStringValue(); System.out.println("channel is.."+ channel); }
The getReturnCode() method in LaunchVXML error object can be used to access the return codes in the event of a failure. Place the LaunchVXML code in the try block and in the catch block, catch the exception as LaunchVXMLFault and access the return code by using method getReturnCode() as shown in the code snippet below.
Refer to Voice Portal documentation for a list of return values and associated error messages.
Note: The catch block is executed only when LaunchVXML fails and hence these return codes are obtained only in case of a failure.
try { AppIntfWS_ServiceLocator locator = new appIntfWS_ServiceLocator(config); AppIntfWS_PortType appintfws = locator.getAppIntfWS(new URL( "http://" + vpmsHost + "/axis/services/AppIntfWS")); LaunchVXMLResponse response = appintfws.launchVXML(request); } catch (LaunchVXMLFault e) { int retcode = e.getReturnCode(); System.out.println("Return code is" + retcode); }
Voice Portal does not provide facility to route calls over selected trunks, since it does not have any association with the dial plan. Call routing is typically performed by a telephony switch. For Example: Avaya Communication Manager.
Voice Portal supports the following audio file formats:
- Raw (headerless) 8kHz 8-bit mono mu-law [PCM] single channel. (G.711)
- Raw (headerless) 8kHz 8 bit mono A-law [PCM] single channel. (G.711)
- WAV (RIFF header) 8kHz 8-bit mono mu-law [PCM] single channel.
- WAV (RIFF header) 8kHz 8-bit mono A-law [PCM] single channel.
The above audio file formats are defined in the VXML specification available at http://www.w3.org/TR/voicexml20/#dmlAAudioFormats
A Blind transfer operation uses only one channel or telephony port to perform hold/dial/transfer steps. The channel is released at the end of a call.
A Dialog Designer Speech project has the below URL format:
http://<IP of App_server> :<Port>/<Applicaton_name>/Start.
An example URL for a CCXML project is:
http://<IP of App_server> :< Port>/<Applicaton_name>/<start page>
Note: Application developers can choose any appropriate start page for a CCXML application as shown in the screenshot below.
Voice Portal Application Summary report can be populated by using the Report item in a Dialog Designer application. A Report item is used to track and submit application data that is used to analyze and evaluate application performance in a run-time environment. Drag and drop a Report item in the call flow node and select a variable whose value is to be reported as shown in the screenshot below.
To view a variable and its value on Voice Portal generated reports, login to the Voice Portal web administration page. Browse to Reports -> Application. Select the appropriate Optional Filters for viewing Application Summary Reports and select Summarize by Variable Name under Report Type.
The variable name and its value are displayed in the Application Summary Report.
The AAI data field is supported only if the outbound call is placed by a Voice Portal system through a SIP trunk. Data cannot be passed to another application using AAI in an H.323 configuration.
The call recording functionality is supported in Voice Portal 4.0 and later versions by integrating Voice Portal with a third party call recording solution such as Proactive Contact. Voice Portal does not have any inbuilt functionality for call recording.
Call Classification feature enables a Voice Portal system to detect whether a call is answered by a human voice or answering machine. The 'green feature' SA8874 (Special Applications 8874) should be enabled on Communication Manager to enable the Call Classification feature for 7434ND (Voice Portal) station type. The SA8874 feature is enabled through licensing.
The following databases are supported on Voice Portal 5.0:
- Oracle 9 and later versions.
- PostgreSQL 8.2 and later versions.
- MSSQL.
In order to generate Dialog Designer application reports:
- Configure the web service authentication parameters on a Voice Portal Management System (VPMS).
- Use the report item in the Dialog Designer application to submit application data to Voice Portal. Report items are used to add custom traces to the call flow.
These steps are elaborated below.
1. Configuring the Application Logging web service authentication parameters:
The Application Logging web service is used to log data to a Voice Portal system. The Application Logging web service conforms to all W3C standards and can be accessed through any web service client using the Avaya-provided Web Services Description Language (WSDL) file.
The WSDL file for the web service is located at: http://VPMS-server/axis/services/VPReport4?wsdl
Note: The application logging web service is used internally by Dialog Designer Report item to log information to Voice Portal. Third party applications could use this web service to log information to Voice Portal.
To configure the web service authentication parameters on Voice Portal, follow the steps given below:
- Login to VPMS web interface and select System Configuration -> VPMS Servers. On the VPMS Servers page, click VPMS Settings.
- On the VPMS Settings page, go to the Application Reporting section in the Web Service Authentication group.
- Enter the user name and password for Digest Authentication. This is the same user name and password that must be used when accessing the web service though the WDSL file.
2. Using the Report item in Dialog Designer Applications:
Refer to FAQ - 'How to generate Voice Portal Application Summary reports from a Dialog Designer application' for information on using Dialog Designer report nodes to generate Voice Portal application reports.
In order to change the configurable application variable value on a Voice Portal 5.0 system, login to Voice Portal Management System (VPMS) web interface and browse to System Configuration -> Applications. On the Applications page, go to the desired application and click on the pencil icon in Configurable Application Variables column. Enter desired values for the variables retrieved from the application and save the changes made.
The Voice Portal Application Interface Web Service uses Digest Authentication to authenticate web service client requests. Error "401: Unauthorized" is received if the Application Interface Web Service fails to authenticate a web service client request.
To resolve this error, ensure that the user name and password are included in the web service client request as specified in the outcall section on the VPMS settings page of the Voice Portal Management System.
To configure and verify outcall parameters, follow the steps given below:
- Log in to the Voice Portal Management System (VPMS) web interface with appropriate credentials and browse to System Configuration->VPMS Servers->VPMS Settings. On the VPMS settings page, configure outcall parameters under Web Service Authentication Group.
- Try to access the Application Interface Web Service from web browser by specifying the URL http://VPMS-server/axis/services/AppIntfWS?wsdl where VPMS-server is the domain name or IP address of the system where VPMS software is installed. When prompted enter the username and password as specified in the outcall section on the VPMS settings page. This will open the WSDL file for the Application Interface Web Service.
Refer to the ClickToCall sample application available with Dialog Designer installation CD for information on how to use the Application Interface Web Service.
Yes. Starting from Voice Portal 5.0, reports can be scheduled and delivered as email attachments or via RSS feed.
To schedule report generation, follow the steps given below
- Log in to the Voice Portal Management System web interface with the appropriate credentials and browse to System Configuration ->Reports->Scheduled Reports. Click on the Add button to schedule the generation of reports.
- On clicking the Add button, add scheduled report page is displayed. On this page specify the source report, schedule date and time, report date and time and configure the notification methods and output options. For detailed description of scheduled report page fields refer to Voice Portal documentation library available on http://www.avaya.com/devconnect.
Note: Scheduled reports can optionally be configured to generate notification only when the record count reaches specified minimum value. To configure the record threshold restriction, check the 'Enable Record Threshold restriction' field on the scheduled report page and specify the record count.
LaunchVXML and LaunchCCXML methods of Voice Portal Application Web Interface Service can be used for outbound calling.
LaunchVXML uses the platform's default CCXML page to initiate an outbound call, and start the specified VoiceXML application. There can be only one outbound call per invocation of the 'LaunchVXML' method.
The LaunchCCXML method of Voice Portal Application Web Interface Service can be used for outbound calling by placing the outbound call from the CCXML application. Using LaunchCCXML for outbound calling provides more control as we define what the CCXML application does. For example, a single CCXML application can be used to launch multiple outgoing calls simultaneously.
For more information on LaunchVXML and LaunchCCXML methods, refer to the Voice Portal Documentation Library available at http://www.avaya.com/devconnect.
Note: When launching multiple outgoing calls simultaneously, application should verify the number of available ports on the Media Processing Platform (MPP) so that it does not exceed the outbound resources. Refer to the topic "Best practices" in the Voice Portal Documentation Library while using the Application Interface Web Service methods to launch multiple outgoing calls.
To perform outbound calling with the Application Interface web service, Avaya special application feature SA8874 should be enabled on Avaya Communication Manager. Without the SA8874 feature, the web service has no access to call progress information and may initiate a VoiceXML application before the call is answered.
To check if the SA8874 feature is enabled on Avaya Communication Manager, refer to the FAQ 'How to check whether the SA8874 feature is enabled on the Avaya Communication Manager (CM)?' on http://www.avaya.com/devconnect.
Note: The SA8874 feature can be provisioned on Avaya Communication Manager 3.1 or later versions and requires a separate license before it can be enabled.
A Session Detail report created using the Voice Portal Management System can be used to determine the ASR server name that handles an application session.
To include the ASR server name in the Session Detail report, check the field "AES Server" in the optional filters group on the Session Detail (Filters) page. For information on how to create the Session Detail report, refer to the topic "Creating a Session Detail report" in the Voice Portal Documentation Library available at http://www.avaya.com/devconnect.
Note: Session detail information is stored in the 'sdr' table of the Voice Portal database.
Yes, when deploying the cticonnector.war file and expanding it to a directory a data/logs directory is created.
CTIConnector specific logging can be found at <ConnectorAppLocation>/data/logs/trace.log.
Voice Portal was renamed to Experience Portal for version 6. Therefore, the Voice Portal Management System (VPMS) is now called the Experience Portal Manager (EPM). The Media Processing Platform (MPP) name has not changed. However, a new media platform, the Avaya Media Server is now also supported with Experience Portal ONLY in the Microsoft Windows environment deployment.
Inside the VXML application, insert a prompt with the format: <prompt><audio src="builtin://senddigit/<dtmf_digits" >/></prompt> where <dtmf_digits> is a string of digits to be sent.
Documentation is not available for these messages. The following information is pertinent however:
The data that EPM sends to the syslog server comes from the database table named
csadminauditlog
. Within the EPM web application,
the Audit Log Viewer displays the data from csadminauditlog
, though it chooses
to leave out
some of the uninteresting bits.
For instance, here is sample output on a syslog server where the EPM sends login/logout events.
Dec 13 16:13:09 localhost @2011-12-13 16:13:09,245 PST-PADTL00005:messages.vpmsMsgCode-INFO-Security-VoicePorta l-TP-Processor32-User:mvg-JNDI Login ,1323821589244, , , , -String:1323821589244-String:-String:-String:-String:--malms teen-1234567890#### Dec 13 16:13:25 localhost @2011-12-13 16:13:25,475 PST-PADTL00006:messages.vpmsMsgCode-INFO-Security-VoicePorta l-TP-Processor37-User:mvg-Logoff ,1323821605474, , , , -String:1323821605474-String:-String:-String:-String:--malms teen-1234567890####
Here is how this example breaks down...
Dec 13 16:13:09 - Timestamp from syslog server localhost - Name of host that sent data to syslog server @2011-12-13 16:13:09,245 PST - Timestamp from Experience Portal (Timestamp column of Audit Log Viewer) PADTL00005 - Event code (Action column of Audit Log Viewer) messages.vpmsMsgCode - File that Experience Portal uses to find display string associated with event code (Ignore) INFO - Severity of event (Ignore-Always INFO) Security - Category of event (Category column of Audit Log Viewer) VoicePortal - Program that logged event (Ignore-Always VoicePortal) TP-Processor32 - Thread that logged event (Ignore) User:mvg - User that performed action (User column of Audit Log Viewer) JNDI Login - Action that was performed (Action column of Audit Log Viewer) 1323821589244 - Timestamp in unreadable format , , , , - Values for other parameters logged with event (Columns Component, Property, From, To of Audit Log Viewer) String:1323821589244 - Type and value for parameter Timestamp String: - Type and value for parameter Component String: - Type and value for parameter Property String: - Type and value for parameter From String: - Type and value for parameter To malmsteen - Hostname 1234567890 - Product ID #### - End of message indicator
Notice that the first couple of fields here actually come from the syslog server, rather than Experience Portal.
Also notice that the data values for Audit Log Viewer columns Component, Property, From, and To are included twice. In the first instance they are run together with the event description as one long string. In the second instance, they are split out as separate fields.
Two scenarios, Inbound Calls and Outbound Calls are relevant here.
Inbound Calls:The only call classification done is looking for fax tone. If Experience Portal sees a fax tone and the phone number used is that of a fax machine, the incoming call will be transferred to the fax machine rather than application processing happening as normal.
Outbound Calls:There are essentially three ways to generate an outbound call with Experience Portal:
- CCXML tag {createcall}
- VoiceXML tag {transfer}
- Application Interface web service method LaunchVXML
In all cases, the only call classification done by Experience Portal is to discriminate between calls answered by humans and calls answered by machines. The algorithm used is rather convoluted, but it boils down to looking at the pattern of voice and silence when the call is answered. It is assumed that humans answer with something short (e.g. 'Hello', 'Hello...Hello?...Hello?') while machines answer with something long (e.g. 'Hi, this is Mike; I'm away from my desk; please leave a message; I'll get back to you.')
Experience Portal counts on the underlying telephony server to indicate when the call was answered and at that point, a decision can be made whether there is human or machine at the other end. In a SIP world, this answer notification actually originates with the remote SIP user agent. In an H.323 world, Communication Manager does the answer detection, but Communication Manager can only do the answer detection if special application 8874 (SA8874) is installed.