Avaya Voice Portal 5.1 Service Pack 3

Release Note (Issue 6)

August 2012

Contents

Introduction

Problems Fixed

Product Information

Installation Notes

Installing the Oracle JDBC driver

Fresh Installs

Upgrades

Known Issues

Compatibility Issues

Installation Issues

System Operation Issues

External System Issues

More Information

Introduction

This document contains Voice Portal 5.1 Service Pack 3 product information that is not included in the product documentation. This document highlights known issues about the Voice Portal product along with workarounds that are available.

Note: Before continuing, check the Avaya support Web site at http://support.avaya.com for an updated version of this document.

Problems Fixed

NumberProblem Description
wi01017432Clicking Logoff link in VPMS does not always log user off
wi01016434MPP sometimes fails to initialize connection to Loquendo Speech Server
wi01014831Speech recognition fails when using Nuance Recognizer 9.0.18 with MRCPv2
wi01013815Need to update apr-utils package
wi01013813Need to update apr package
wi01013811Need to update WebLM
wi01013766VoiceXML Interpreter core dump
wi01012518VoiceXML application sometimes hangs after a consultative transfer
wi01009611Create Avaya Linux based on RHEL 5.8
wi01005906SIP transfer fails if attempted while re-INVITE request is being processed
wi01002521Need to update rpm package in Avaya Linux
wi00997338Script restorempplogs.sh does not work as expected
wi00997289Cannot import security certificates from Auxiliary VPMS
wi00997145Should not send SIP final response (2xx) until required PRACK received
wi00995278Need a way for CCXML applications to determine H.323 station
wi00993064Need to update xorg-x11 packages
wi00993063Need to update util-linux package in Avaya Linux
wi00993061Need to update vixie-cron package in Avaya Linux
wi00993059Need to update initscripts package in Avaya Linux
wi00993058Need to update busybox package in Avaya Linux
wi00993056Need to update sudo package in Avaya Linux
wi00993054Need to update sos package in Avaya Linux
wi00993050Need to update nfs-utils package in Avaya Linux
wi00992969CCXML Interpreter core dump
wi00991159Need to update PostgreSQL
wi00990253CCXML Interpreter core dump
wi00988795Need to update samba package in Avaya Linux
wi00988450Need to update Apache httpd server
wi00984630Need to update libpng package
wi00984621Need to update glibc package in Avaya Linux
wi00983717MPP hangs up when it receives DTMF during hotword recognition
wi00981989SessionManager core dump
wi00978713Configurable application variables are not passed to application if application logging is disabled
wi00977159Need to update openssl package
wi00975735Need to update php package
wi00975731Need to update Apache Tomcat
wi00975727Need to update libxml2 package
wi00971763Script InstallGraphviz.sh fails on Avaya Linux RHE5.7-AV16.0VP5
wi00970538Need to update krb5 package in Avaya Linux
wi00969070Need to update nss package
wi00967133Need to update perl package in Avaya Linux
wi00964784Users can access Axis2 administration page using default password
wi00964223Need to update kernel in Avaya Linux
wi00963899Need to update bind package in Avaya Linux
wi00962738Failover takes too long when a speech server fails
wi00960881Response to SIP OPTIONS request sometimes overrides SDP negotiated codecs
wi00960880SessionManager core dump
wi00958461SIP TLS connection to proxy server does not recover after a failure
wi00954263SIP ports configured as inbound-only do not get redistributed properly when failed MPP comes back up
wi00954044Core dump when using CCXML <merge> tag
wi00953681Need to update Java
wi00953204Need to update freetype package
wi00952837Some CCXML events such as cancel.successful are ignored
wi00951820Single server MPP sometimes starts automatically after a reboot when it should not
wi00949141Upgrade fails on Oracle Linux
wi00944779Poor DTMF recognition in noisy environments
wi00908359Core dump when first audio played by application is beep sound from <record> tag
wi00893403Inbound fax detection incorrectly requires enhanced call classification license

Product Information

The Voice Portal Documentation Library is available on the Voice Portal service pack DVD. To access the Voice Portal Documentation Library, place the service pack DVD into a Windows system and use Internet Explorer to view the file \Documentation\VoicePortalDocLibrary\_StartHere.html. From this page, you can access the following information:

Printable PDF files for most of the above are accessible from the page titled About the Avaya Voice Portal library and from the Print guides section of the table of contents.

Also available from the Print guides section of the table of contents are the white papers listed below:

Note: License agreements for each of the third-party components that ship with Voice Portal can be found in the Voice Portal DVD directory /Licenses.

Installation Notes

Important: Before installing or upgrading Voice Portal, please review the Known Issues section in this document for issues that are not addressed in the product documentation. Several of the issues listed there are related to installation.

Important: Voice Portal 5.1 SP3 requires Red Hat Enterprise Linux Server release 5.6 or later, or Avaya Enterprise Linux version RHE5.7-AV16.0VP5 or later.

Installing the Oracle JDBC driver

The Oracle JDBC driver is no longer shipped with Voice Portal. If you wish to connect your Voice Portal system to an external Oracle database, then you must first obtain the JDBC driver from Oracle.

To download the Oracle JDBC driver:

  1. From a machine with Internet access, open a web browser.
  2. Navigate to the page http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-111060-084321.html.
  3. From section Oracle Database 11g Release 1 (11.1.0.7.0) JDBC Drivers, download the following files:
    4. ojdbc6.jar
    orai18n.jar

    Important: Some web browsers are known to change the file extension of these files to .zip when the files are downloaded. If this happens, rename the files back to ojdbc6.jar and orai18n.jar.

To have the Oracle JDBC driver installed by the Voice Portal install program, complete the steps below after installing or upgrading Linux but before installing or upgrading Voice Portal.

Note: If you do not complete these steps until after installing or upgrading Voice Portal, then in addition to the steps below you will need to run the script InstallOracleJDBC.sh as described in Oracle JDBC driver.

On the Primary VPMS server and each Auxiliary VPMS server:

  1. Log into Linux on the VPMS server using the user account that will be used to install Voice Portal.

    2. Note: Generally the account used is either root or sroot.

  2. Execute the command below to create folder ~/OracleJDBC:
    3. mkdir ~/OracleJDBC
  3. Copy the driver files ojdbc6.jar and orai18n.jar to folder ~/OracleJDBC.

Important: Leave the Oracle JDBC driver files in directory ~/OracleJDBC even after installing or upgrading Voice Portal. These files will be needed again if you ever install or upgrade Voice Portal in the future.

Fresh Installs

This service pack can be used to do a fresh install of a new Voice Portal system. You do not need to install Voice Portal 5.1 before installing this service pack.

For detailed installation procedures, see either Implementing Voice Portal on multiple servers or Implementing Voice Portal on a single server, whichever is appropriate for your installation. These guides also contain important installation worksheets that should be filled out before starting the Voice Portal installation.

Upgrades

Important: Before starting an upgrade, you should back up your Voice Portal database. If the upgrade fails for any reason, you will need this backup to restore your system to its prior state.

Upgrades from Voice Portal 4.1.x or 5.0.x

For detailed upgrade procedures see Upgrading from Voice Portal 4.1 or 5.0 to Release 5.1. The procedure to upgrade a system to this service pack is the same as the procedure to upgrade a system to Voice Portal 5.1. Note that because this service pack requires Red Hat Enterprise Linux version 5.6 or later, or Avaya Enterprise Linux version RHE5.7-AV16.0VP5 or later, you will likely need to upgrade the Linux operating system before upgrading Voice Portal.

Important: Upgrading from Voice Portal 4.1 or 5.0 to Release 5.1 describes multiple methods for installing the Voice Portal software. If possible, you should use the "Automatic upgrade" method that has you run a script called autoupgradevp. This will avoid a known issue that can cause all of your MPPs to go into the Not Responding state if you upgrade your Primary VPMS using the script installvp.

Internal Database

If you are upgrading a Voice Portal system that was originally installed with Voice Portal 4.1 SP3 or earlier, then you need to upgrade the schema of your Voice Portal internal database. This schema upgrade is performed on the Primary VPMS after you upgrade to Voice Portal 5.1.

Note: If you are upgrading a system that was originally installed with Voice Portal 4.1 SP4 or later, then you do not need to perform the procedure below.

To upgrade the schema of your internal database:

  1. Log into Linux on the Primary VPMS server as a user with root privileges.
  2. Execute the command below to stop the vpms service:
    3. /sbin/service vpms stop
  3. Execute the command below to upgrade the database schema:
    Important: All of the text below must be entered on a single line.
    4. sudo -u postgres psql -d VoicePortal -c "alter table sdproperty alter column value type character varying(1024)"
  4. Execute the command below to start the vpms service:
    5. /sbin/service vpms start

Co-resident application server

If you are upgrading a single server Voice Portal system that includes a co-resident application server, then you need to manually delete an unused file from that application server.

To delete unused file from the co-resident application server:

  1. Log into Linux on the Voice Portal server as a user with root privileges.
  2. Execute the command below to delete an unused file:
    3. rm $APPSERVER_HOME/webapps/ROOT/favicon.ico

Upgrades from Voice Portal 5.1.0.0.x and 5.1.0.1.x

For detailed upgrade procedures see Upgrading from Voice Portal 4.1 or 5.0 to Release 5.1. The procedure to upgrade a system to this service pack is the same as the procedure to upgrade a system to Voice Portal 5.1. Note that because this service pack requires Red Hat Enterprise Linux version 5.6 or later, or Avaya Enterprise Linux version RHE5.7-AV16.0VP5 or later, you will likely need to upgrade the Linux operating system before upgrading Voice Portal.

Important: Upgrading from Voice Portal 4.1 or 5.0 to Release 5.1 describes multiple methods for installing the Voice Portal software. If possible, you should use the "Automatic upgrade" method that has you run a script called autoupgradevp. This will avoid a known issue that can cause all of your MPPs to go into the Not Responding state if you upgrade your Primary VPMS using the script installvp.

Important: You cannot use the Software Upgrade web page of the VPMS to upgrade to this service pack.

Co-resident application server

If you are upgrading a single server Voice Portal system that includes a co-resident application server, then you need to manually delete an unused file from that application server.

To delete unused file from the co-resident application server:

  1. Log into Linux on the Voice Portal server as a user with root privileges.
  2. Execute the command below to delete an unused file:
    3. rm $APPSERVER_HOME/webapps/ROOT/favicon.ico

Upgrades from Voice Portal 5.1.0.2.x

This service pack does not require a new version of Linux. However, you should upgrade Linux as part of installing this service pack in order to pick up numerous security fixes in the operating system.

If you are upgrading the operating system on each server as part of installing this service pack, then you should follow the upgrade procedure documented in Upgrading from Voice Portal 4.1 or 5.0 to Release 5.1.

If you are not upgrading the operating system on each server as part of installing this service pack, then you should still follow the upgrade procedure documented in Upgrading from Voice Portal 4.1 or 5.0 to Release 5.1 when upgrading a single server Voice Portal system or when upgrading the Primary VPMS and Auxiliary VPMS servers in a multi-server Voice Portal system. Simply skip the steps in Upgrading from Voice Portal 4.1 or 5.0 to Release 5.1 that relate to upgrading the operating system.

If you are upgrading a multi-server system and you are not upgrading the operating system, then you can upgrade all of your Voice Portal 5.1.0.2.x MPP servers using the Software Upgrade web page of the VPMS. Before doing that, though, you must perform the one time procedure below on each MPP server that you wish to upgrade using the Software Upgrade web page.

Note: This step is not needed if it was already performed as part of an earlier upgrade.

To allow an MPP to be upgraded from the VPMS:

  1. Log into Linux on the MPP server as a user with root privileges.
  2. Execute the command below to download a security certificate from the Primary VPMS.
    3. $AVAYA_IA_HOME/bin/DownloadPK.bash <PrimaryVPMS>

    Note: The <PrimaryVPMS> above is the name or IP address of the Primary VPMS server that manages this MPP.

To upgrade all of your Voice Portal 5.1.0.2.x MPP servers:

  1. After upgrading the Primary VPMS server, log into the VPMS web interface using an account with administrative privileges.
  2. Navigate to the Software Upgrade web page.
  3. Select the checkbox that selects all of the MPP servers listed.
  4. In the New Version selection box, select the file name for this service pack.
  5. Select the Upgrade button.

Note: When you use the Software Upgrade web page to upgrade your MPP servers, each MPP is taken out of service while it is upgraded. MPP servers are upgraded one at a time so that the system can continue to process calls during the upgrade process. Also, if the upgrade of any one MPP fails, then any other MPP servers that are still awaiting upgrade will not be upgraded. This is to avoid the possibility of an upgrade issue causing all MPP servers to go out of service at the same time.

Co-resident application server

If you are upgrading a single server Voice Portal system that includes a co-resident application server, then you need to manually delete an unused file from that application server.

To delete unused file from the co-resident application server:

  1. Log into Linux on the Voice Portal server as a user with root privileges.
  2. Execute the command below to delete an unused file:
    3. rm $APPSERVER_HOME/webapps/ROOT/favicon.ico

Known Issues

Compatibility Issues

Proactive Outreach Manager

Voice Portal 5.1 SP3 cannot be used with Proactive Outreach Manager (POM) version 2.0 SP4 and earlier versions. If you are upgrading a system that includes POM, then you need to upgrade POM to version 2.5 (or later) after you upgrade to Voice Portal 5.1 SP3.

Important: If you are upgrading a system that already includes POM 2.5 to Voice Portal 5.1 SP3, then you need POM patch POM2_Upgrade_patch.zip. You can download this patch and the installation instructions that go with it from the Avaya support Web site at http://support.avaya.com. Note that this hotfix needs to be installed on POM 2.5 before Voice Portal is upgraded to version 5.1 SP3.

Experience Portal

You cannot upgrade a system from Voice Portal 5.1 SP3 to either Experience Portal 6.0 or Experience Portal 6.0 SP1. You will be able to upgrade from Voice Portal 5.1 SP3 to Experience Portal 6.0 SP2, once Experience Portal 6.0 SP2 becomes available.

Oracle JDBC driver

As noted earlier, the Oracle JDBC driver is no longer shipped with Voice Portal. If you follow the procedures in Installing the OracleJDBC driver before installing or upgrading your Primary VPMS server and any Auxiliary VPMS servers, then the Oracle JDBC driver will be installed in the correct directory by the Voice Portal install or upgrade program.

To install the Oracle JDBC driver after you have installed your Voice Portal system, first follow the procedures in Installing the OracleJDBC driver. Then, follow the procedure below.

On the Primary VPMS server and each Auxiliary VPMS server:

  1. Log into Linux on the VPMS server as a user with root privileges.
  2. Execute the command below to stop the vpms service:
    3. /sbin/service vpms stop
  3. Execute the command below to navigate to the appropriate directory:
    4. cd $AVAYA_HOME/Support/Database
  4. Execute the command below to install the JDBC driver:
    5. bash InstallOracleJDBC.sh

    Important: Do not execute InstallOracleJDBC.sh on a server until you have downloaded the Oracle driver and placed it in directory ~/OracleJDBC on that server as described in Installing the OracleJDBC driver.

  5. Execute the command below to start the vpms service:
    6. /sbin/service vpms start

SIP Domain now validated

In Voice Portal 5.1 the SIP domain name received from the SIP proxy on an incoming call is validated against the value of SIP Domain entered on the Add SIP Connection (or Change SIP Connection) page of the VPMS. If the domain names do not match, Voice Portal will not answer the call. Previous versions of Voice Portal did not validate the SIP domain name received from the SIP proxy.

Because of this change, it is possible that an improperly configured system that worked with previous releases of Voice Portal stops working when upgraded to Voice Portal 5.1.

When upgrading a system to Voice Portal 5.1, verify that the SIP domain name configured on Voice Portal matches the SIP domain name configured on any attached SIP proxies.

New CCXML event <start_of_voice>

An enhancement to the call classification code in Voice Portal 5.1 means that CCXML applications that make outcalls may now receive the event <start_of_voice>. This event occurs after an outcall is answered, at the point where Voice Portal starts trying to determine whether the call was answered by a human or an answering machine. Previous versions of Voice Portal did not send the event <start_of_voice>.

Because of this change, CCXML applications that worked with previous releases of Voice Portal may stop working when the system is upgraded to Voice Portal 5.1. Applications that were modeled after the Voice Portal page default.ccxml from previous releases are likely to suffer from this problem. These applications need to be modified to properly handle the event <start_of_voice>.

Note: In most cases applications can simply ignore the event <start_of_voice>. Where problems occur is when an application looks for a certain set of events and aborts if it receives an unexpected event. These applications need to recognize <start_of_voice> as an expected event.

BloominBloomsLite sample

The version of the sample application BloominBloomsLite that shipped with Dialog Designer 5.0 does not work correctly with Voice Portal 5.1. If you use BloominBloomsLite, use the version that ships with Dialog Designer 5.0 SP1, or newer.

Video applications written for Voice Portal 5.0

Video applications written for Voice Portal 5.0 might not operate correctly on Voice Portal 5.0 SP1 and later. In Voice Portal 5.0, if a video is played in parallel with audio that is longer than the video, then at the end of the video the last frame will remain on the screen while the audio finishes. Starting with Voice Portal 5.0 SP1, the screen will go blank when the video finishes playing, unless the application writer specifies a video duration that is longer than the actual length of the video.

Note: Application writers should refer to the version of the sample application BloominBloomsLite that ships with Dialog Designer 5.0 SP1, or newer, for examples of video application best practices.

Installation Issues

Disk Partitions

On a Primary VPMS server, the Voice Portal database might grow to be quite large. The report data generated automatically by Voice Portal causes the database to grow by approximately 4GB for every one million calls processed. If your applications use the Voice Portal application logging feature, the database grows even faster.

By default, the Voice Portal database resides in the directory /var/lib/pgsql/data. If you are a software-only customer, when you install Red Hat Enterprise Linux on your VPMS server you should ensure that the disk partitions you define provide adequate space for the Voice Portal database. Note that the default partition scheme provided by Red Hat Enterprise Linux has proven adequate for most Voice Portal installations. It results in the Voice Portal database residing in a partition that spans most of the hard disk.

On an MPP server, the MPP logs directory might grow to be quite large. This is particularly true if your applications use the VoiceXML <log> tag or CCXML <log> tag to generate application log data.

By default, the MPP logs reside in the directory /opt/Avaya/VoicePortal/MPP/logs. If you are a software-only customer, when you install Red Hat Enterprise Linux on your MPP server you should ensure that the disk partitions you define provide adequate space for the MPP logs. Note that the default partition scheme provided by Red Hat Enterprise Linux has proven adequate for most Voice Portal installations. It results in the MPP logs being in a partition that spans most of the hard disk.

Be aware that the partition scheme provided by Avaya Enterprise Linux results in the MPP logs residing in a relatively small disk partition. If you encounter space problems, see the help topic Administering Voice Portal > Media Processing Platforms > Moving the MPP logs to a different location for instructions on how to change where MPP logs are stored.

Avaya Linux installer hangs

When you boot a server from the Avaya Linux DVD, the first prompt displayed is labeled boot:. Normally, if you do not respond to this prompt, the Avaya Linux installer will automatically proceed. Occasionally, though, the system hangs at this point.

To work around this issue, reboot the server and then press Enter at the boot: prompt.

Red Hat Enterprise Linux Server 5.x installs in text mode

In some instances, when Red Hat Enterprise Linux Server 5.x is installed on a server where the console monitor is connected through a KVM switch the Red Hat install program does not correctly identify the type of monitor connected. One consequence of this is that the Red Hat install program runs in console mode, rather than the typical graphical mode. Another consequence is that after Red Hat Enterprise Linux Server 5.x is installed, it runs in console mode rather than graphical mode.

To configure Red Hat Enterprise Linux Server 5.x to run in graphical mode:

  1. Log into Linux as a user with root privileges.
  2. Execute the command below to start the Display Settings configuration utility:
    3. system-config-display
  3. Within Display Settings, select the Hardware tab.
  4. On the Hardware tab, click the Configure... button next to Monitor Type.
  5. On the Monitor window displayed, select a monitor type that is appropriate for your hardware. For example, LCD Panel 1280x1024.
  6. Click the OK button to close the Monitor window, saving your changes.
  7. Click the OK button on the Display Settings window to close that application.
  8. Open the file /etc/inittab in a text editor.
  9. Find the line that contains id:3:initdefault:.
  10. Change this line to read as follows:
    11. id:5:initdefault:
  11. Save and close the file.
  12. Reboot the server.

Linux console flooded with errors

In some instances, when a Voice Portal 4.x system installed on an installation of Red Hat Enterprise Linux ES4 that does not include a graphical user interface is upgraded to Red Hat Enterprise Linux 5.x, the Linux console gets flooded with errors. This makes it difficult to log into the system.

Note: This problem can occur with both Red Hat Enterprise Linux and the version of Linux provided by Avaya.

To avoid this problem, follow the procedure below before upgrading to Red Hat Enterprise Linux 5.x:

  1. Open the file /etc/inittab in a text editor.
  2. Find the line that contains R0:2345:respawn:bash /sbin/initmgetty -x 4 ttyACM0.
  3. Insert the comment character, #, at the beginning of that line.
  4. Save and close the file.
  5. Reboot the server.

Note: If you do not follow the procedure above before upgrading to Red Hat Enterprise Linux 5.x and you encounter the problem of the console being flooded with errors, you can resolve the issue by logging into the system remotely using an SSH client and then performing the procedure above. Alternatively, you can log into the system remotely and install Voice Portal.

Message "Protocol spec without prior Class and Subclass spec at line 4297"

When upgrading from a prior version of Voice Portal to Voice Portal 5.1 SP3, you will likely need to upgrade the Linux operating system on each server in your Voice Portal system. If you upgrade to Red Hat Enterprise Linux 5.7 or Red Hat Enterprise Linux 5.8, then after you upgrade the operating system you may see the message below displayed on the console approximately every thirty seconds.

Protocol spec without prior Class and Subclass spec at line 4297

Note: This problem can occur with both Red Hat Enterprise Linux and the version of Linux provided by Avaya.

This error will no longer be displayed once you complete the upgrade procedure by installing Voice Portal 5.1 SP3.

Error from cpartition when running vpupgrade.sh

If you are upgrading a system that uses the Avaya provided version of Linux, when you run the Linux upgrade script vpupgrade.sh you may see a message similar to the following:

cpartition: ERROR - boot label Uya1 from "lilo -v -q" output does not equate to / or /root2 in "mount" output

You may safely ignore this message.

Script vpupgrade.sh aborts because MPP is running

If you are upgrading an MPP server that uses the Avaya provided version of Linux, when you run the Linux upgrade script vpupgrade.sh you may see a message similar to the following:

    Error: Detected the MPP process, SessionManager, running.
              Please use the VPMS to stop this MPP and change its
              'Operation Mode' to 'Offline'.

You must take the MPP out of service in order to prevent vpupgrade.sh from aborting. As described in the error message, the best way to take an MPP out of service is to go to the MPP Manager page of the VPMS, stop the MPP, and then set the MPP mode to Offline. However, if the VPMS is reporting the state of the MPP as Not Responding, then that procedure will not work.

If you cannot stop the MPP through the VPMS web interface, then follow the procedure below:

  1. Log into Linux on the MPP server as a user with root privileges.
  2. Execute the command below to stop the mpp service:
    3. /sbin/service mpp stop

Apache httpd prerequisite RPM installation fails during installation or upgrade

During the portion of the install program where prerequisites are installed, a message similar to the following might be displayed:

| |  >>>>>>Starting RPM installation: 'rpm -U --replacepkgs *.rpm'
| |  warning: httpd-2.2.3-53.el5_7.1.i386.rpm: Header V3 DSA signature:
| |    NOKEY, key ID 37017186
| |  error: Failed dependencies:
| |    httpd = 2.2.3-53.el5 is needed by (installed) httpd-manual-2.2.3-53.el5.i386.
| |  >>>>>>RPM Installation failed: Exit Code: 2
| |  ====================================
| |  RPM installation check: Expecting 'Found' >= 'Expected'.
| |  Expected: httpd-2.2.3-53.el5_7.1.i386.rpm
| |           mod_ssl-2.2.3-53.el5_7.1.i386.rpm
| |           openssl-0.9.8e-20.el5.i386.rpm
| |  Found: httpd-2.2.3-53.el5            Out of Date
| |           mod_ssl-2.2.3-53.el5        Out of Date
| |           openssl-0.9.8e-20.el5        Passed

If prerequisite installation fails, the installation will not continue.

To resolve this issue:

  1. Uninstall the httpd-manual RPM using the command:
    2. rpm -e --nodeps httpd-manual
  2. Re-execute the Voice Portal installation.

PHP prerequisite RPM installation fails during installation or upgrade

During the portion of the install program where prerequisites are installed, a message similar to the following might be displayed:

| |  >>>>>>Starting RPM installation: 'rpm -U --replacepkgs *.rpm'
| |  warning: php-4.3.9-3.22.9.i386.rpm: V3 DSA signature: NOKEY, key ID
| |    db42a60e
| |  error: Failed dependencies:
| |    php = 4.3.9-3.22.4 is needed by (installed) php-ldap-4.3.9-3.22.4.i386.
| |  >>>>>>RPM Installation failed: Exit Code: 3
| |  ====================================
| |  RPM installation check: Expecting 'Found' >= 'Expected'.
| |  Expected: php-pear-4.3.9-3.22.9.i386.rpm
| |           php-4.3.9-3.22.9.i386.rpm
| |           php-domxml-4.3.9-3.22.9.i386.rpm
| |  Found: php-pear-4.3.9-3.22.4            Out of Date
| |           php-4.3.9-3.22.4                 Out of Date
| |           php-domxml-4.3.9-3.22.9.i386.rpm  Not Installed

If prerequisite installation fails, the installation will not continue.

To resolve this issue:

  1. Uninstall the php-ldap RPM using the command:
    2. rpm -e --nodeps php-ldap
  2. Re-execute the Voice Portal installation.

Message "avc: granted {setbool} for pid=xxxx comm='setsebool' scontext..."

During the portion of the install program where Voice Portal is actually installed and the install program displays Installation Progress, a message similar to the following might be displayed:

avc: granted {setbool} for pid=xxxx comm='setsebool' scontext...

This message does not indicate that an error has occurred. You may safely ignore this message.

MPPs must be restarted after Primary VPMS is upgraded

After you upgrade your Primary VPMS, all of your MPPs might go into the Restart Needed state. If this happens, the MPPs will continue to process calls normally but will need to be restarted at some point. You can either restart the MPPs immediately after you upgrade the Primary VPMS, or you can wait and restart each MPP after it is upgraded.

Use same Linux account on upgrades

When you install or upgrade the Voice Portal software, the install or upgrade program (installvp or autoupgradevp) must be run as a Linux user with root privileges. Typically, the account used is either root or sroot. When upgrading a system that already has Voice Portal installed, if the upgrade program is run using a different Linux account than was used during the previous install or upgrade, the upgrade may fail.

To work around this issue, always upgrade using the same Linux account that was used during the previous installation.

Auxiliary VPMS stops working after Primary VPMS is upgraded

After you upgrade your Primary VPMS your Auxiliary VPMS will no longer be able to communicate with it. To resolve this issue, upgrade your Auxiliary VPMS to the same release of Voice Portal that your Primary VPMS is running.

Note: While the Auxiliary VPMS is not able to communicate with the Primary VPMS, it will still be able to communicate with the MPP servers. Therefore, outcall requests made through the Application Interface web service on the Auxiliary VPMS will continue to succeed.

Apache httpd server must be restarted after Auxiliary VPMS upgrade

After you upgrade an Auxiliary VPMS (formerly Secondary VPMS) server to Voice Portal 5.1, you must manually restart the Apache httpd server.

To restart the httpd server:

  1. Log into Linux on the Auxiliary VPMS server as a user with root privileges.
  2. Execute the command below to restart the httpd service:
    3. /sbin/service httpd restart

Auxiliary VPMS renamed on upgrade

If you upgrade a system that includes a Secondary VPMS to Voice Portal 5.1, on the VPMS Servers page of the VPMS web application the Secondary VPMS will be renamed VPMS2. This behavior is by design. In Voice Portal 5.1, the term Secondary VPMS has been replaced by Auxiliary VPMS.

Co-resident application server not started automatically

After you upgrade Avaya Linux on a single server system that includes a co-resident application server, the co-resident application server should start automatically but it does not.

To resolve this issue:

  1. After upgrading Avaya Linux, upgrade the Voice Portal software.
  2. Execute the command below to start the co-resident application server:
    3. /sbin/service appserver start

Tomcat user account not created on co-resident application server

On a single server system, the script InstallAppServer.sh can be used to install or upgrade a co-resident application server. This script should create a Tomcat role named manager and a Tomcat user account named voiceportal on the co-resident application server, but it does not. If you wish to use the application Tomcat Manager, then you must manually create the Tomcat role manager and a Tomcat account with that role before you can log into Tomcat Manager.

See the help topic Implementing Voice Portal on a single server > Optional: Installing a Tomcat application server > Adding Tomcat user accounts for instructions on how to create a Tomcat role and a Tomcat user account.

System file /etc/mailcap corrupted

When you install either a Voice Portal Primary VPMS or a Voice Portal Auxiliary VPMS, the system file /etc/mailcap is corrupted. This corruption is caused by the Java Development Kit that is installed by Voice Portal.

Note: The file /etc/mailcap is used by Linux to determine which program should open a particular file based on the file's MIME type.

To resolve this issue:

  1. Log into Linux as a user with root privileges.
  2. Open the file /etc/mailcap in a text editor.
  3. Find the last line in the file, which should look similar to the following:
    4. text/html; /usr/bin/htmlview %s ; copiousoutput\napplication/x-java-jnlp-file; /usr/bin/javaws %s
  4. Replace the \n in the middle of the last line with a line break. The result should look similar to the following two lines.
    5. text/html; /usr/bin/htmlview %s ; copiousoutput
    application/x-java-jnlp-file; /usr/bin/javaws %s
  5. Save and close the file.

System Operation Issues

VPMS root security certificate expires

When you install the Primary VPMS, a root security certificate is generated. Voice Portal 5.1 generates a root certificate that is valid for ten years. However, some previous versions of Voice Portal generated a root certificate that was valid for only one year. If your root certificate is about to expire, you may see a message similar to the following on the VPMS home page:

SIP: The root CA certificate will expire in 30 days.

To generate a new root certificate:

  1. Log into Linux on the Primary VPMS server as a user with root privileges.
  2. Execute the command below to navigate to the appropriate directory:
    3. cd $AVAYA_HOME/Support/VP-Tools
  3. Execute the command below to generate a new certificate:
    4. bash UpdateRootCertificate
  4. When prompted, type Y and press Enter to restart the vpms service.

Important: After generating a new root certificate, you must restart all of your MPPs. Also, if you have installed the Voice Portal root certificate on any other servers, such as on a SIP proxy in order to support a TLS connection, then you must update all of those other servers with the new Voice Portal certificate.

Application delays under heavy load

People calling into applications running on a very heavily loaded MPP may occasionally experience delays of several seconds between prompts. This symptom can be caused by file system latencies within Linux. To address this issue, try one or more of the solutions below:

Or

Or

Or

Accessing media files using HTTPS

If your application refers to a media a file (for example, a .3gp video) using a secure HTTP URL (one that begins with "https"), then you must install the security certificate from the server that holds the media file on your Voice Portal system. To install the security certificate on Voice Portal, go to the Certificates page of the VPMS and select the Trusted Certificates tab.

Portmap service should be disabled

As a matter of security policy, Avaya recommends that the Linux service named portmap be disabled. By default, the portmap service is disabled on Avaya Linux. However, on Red Hat Enterprise Linux 5.x the portmap service is enabled by default.

To disable the portmap service:

  1. Log into Linux as a user with root privileges.
  2. Execute the command below to prevent the portmap service from starting when the system reboots:
    3. chkconfig portmap off
  3. Execute the command below to stop the portmap service:
    4. /sbin/service portmap stop

Note: The Voice Portal backup procedure requires you to have the portmap service enabled. Similarly, you will need to enable the portmap service if you wish to use NFS.

SIP proxy failover

In Voice Portal 5.1 if you have multiple SIP proxies configured and an outcall request fails because the chosen SIP proxy is out of service, Voice Portal will automatically retry the outcall using a different SIP proxy. However, it may take Voice Portal up to thirty seconds to retry the outcall using a different SIP proxy. Writers of applications that request outcalls using either the LaunchVXML method of the Application Interface web service or the CCXML tag <createcall> should consider this failover time when choosing a timeout to specify on the outcall request. If the timeout specified is too short, the outcall request will time out before Voice Portal has found a working SIP proxy.

Note: If a LaunchVXML request times out, it is still possible that Voice Portal will eventually complete the outcall and launch the requested application.

Unanswered outcalls

If your application makes an outcall with call classification enabled in either a SIP environment or an H.323 environment that has Special Application 8874 (also known as "the green feature") enabled, then the call classification timer does not begin until Voice Portal receives an indication from the telephony switch that the far end has answered the call. Therefore, if a call goes unanswered, the application will not receive a call classification timeout. It will receive a connection timeout instead.

In an H.323 environment that does not have Special Application 8874 enabled, on the other hand, Voice Portal does not receive any indication from the telephony switch when the far end has answered the call. In this case, Voice Portal considers the call connected as soon as the call is initiated and Voice Portal immediately starts the call classification timer. If a call goes unanswered, your application will not receive a connection timeout. It will receive a call classification timeout.

Changing server host name or IP address

If the host name or IP address of any Voice Portal server changes, then you must run the utility do_UpdateHost.

If the host name or IP address of a Primary VPMS or Auxiliary VPMS server changes, you must additionally perform the following steps on that server after running do_UpdateHost:

  1. Log into Linux as a user with root privileges.
  2. Execute the command below to stop the vpms service:
    3. /sbin/service vpms stop
  3. Execute the command below to copy a core services configuration file to the correct location:
    4. cp -p /tmp/BootstrapDBResource.dat /opt/coreservices/scc/runtime/
  4. Execute the command below to start the vpms service:
    5. /sbin/service vpms start

Replacing a Primary VPMS server

To replace a Primary VPMS server you must perform several tasks that include: install Linux on the new server, install Voice Portal on the new server, and restore on the new server a Voice Portal database backup taken from the old server. Below are some additional procedures that need to be followed during this process. The first procedure should be performed before you restore the Voice Portal database backup on the new newer. The second procedure should be performed after you restore the database.

Important: These additional procedures are needed any time a database restore is performed after a fresh install of Voice Portal; even if the underlying server hardware has not changed.

Before following the procedure documented in Restoring data backed up from System Backup follow the procedure below.

For each Auxiliary VPMS server:

  1. Log into Linux on the Auxiliary VPMS server as a user with root privileges.
  2. Execute the command below to navigate to the appropriate directory:
    3. cd $AVAYA_HOME/Support/VP-Tools
  3. Execute the command below to retrieve the security certificate from the Primary VPMS:
    4. bash setup_vpms.php <PrimaryVPMS>

    Note: The <PrimaryVPMS> above is the name or IP address of the Primary VPMS server that manages this MPP.

  4. Follow the on-screen prompts to install the security certificate, restart Apache, and configure Network Time Protocol (NTP).

After following the procedure documented in Restoring data backed up from System Backup follow the procedure below.

  1. Log into Linux on the Primary VPMS server as a user with root privileges.
  2. Execute the command below to restart the vpms service:
    3. /sbin/service vpms restart

MPP core dump when speech server configuration changes

Under rare circumstances, a Voice Portal MPP will generate a core dump after you make a change to the network configuration on one of your speech servers. If you make a network configuration change on a speech server, such as changing the server's IP address, reboot the speech server. This should prevent the situation that causes the MPP to core dump.

Stability issues with MRCPv2

Voice Portal communicates with speech servers using either Media Resource Control Protocol version one (MRCPv1) or Media Resource Control Protocol version two (MRCPv2). A variety of issues, including failure to acquire speech resources and long latencies, have occasionally been observed when Voice Portal uses MRCPv2 to communicate with speech servers. If you experience problems using MRCPv2, configure Voice Portal to use MRCPv1 instead.

Note: Problems with MRCPv2 are particularly common when using Loquendo Speech Servers. You should always configure Voice Portal to use MRCPv1 when communicating with Loquendo Speech Servers.

Application logging

If you are running a Dialog Designer application that does application logging, and your Voice Portal system is configured to handle more than 75 simultaneous calls, you must make the following configuration change on your Primary VPMS:

  1. Log into Linux on the Primary VPMS server as a user with root privileges.
  2. Open the file $CATALINA_HOME/conf/server.xml in a text editor.
  3. Find the entry maxThreads="500" under <Connector port="8009".
  4. Change the value from 500 to 1000.
  5. Save and close the file.
  6. Execute the command below to restart the vpms service:
    7. /sbin/service vpms restart

Supporting non-English applications

Application language

When an application runs on the MPP, the VoiceXML Interpreter defaults to the language configured in the Language field on the AVB Settings page of the VPMS. The default value for this field is en-US. If your application uses a language other than the one configured for the system, the application must specify the correct language using the xml:lang attribute. Applications can specify the language either globally on each page, or as part of each individual <grammar> tag and <prompt> tag.

Default event handlers

When the VoiceXML Interpreter or CCXML Interpreter generates an event to a page that does not have a handler defined for that event, the interpreter invokes the appropriate default event handler configured on the Event Handlers page of the VPMS. The default event handlers shipped with Voice Portal play an error prompt spoken in English. If your application uses a language other than English, you must configure a default event handler appropriate for that application.

Note: If you are writing code that will be used as a default event handler and the code refers to prerecorded prompt files, refer to those prompt files by file name as opposed to file path. Voice Portal will automatically search for prompt files in the appropriate directory.

External System Issues

Apache Tomcat

Application logging on Linux application server

If you are running a Dialog Designer application that does application logging, and your VPMS goes out of service, Dialog Designer temporarily stores the application log data on your application server while waiting for the VPMS to come back in service. If your application server is Tomcat running on Linux and the VPMS stays out of service for a long time, Tomcat might crash because the system runs out of file handles.

If you encounter this problem, do one or both of the following on your application server.

Increase the Linux file handle limit on your application server:

  1. Log into Linux on the Tomcat server as a user with root privileges.
  2. Open the file /etc/init.d/tomcat in a text editor.
  3. Find the start() procedure.
  4. Add the following line to the start procedure before Tomcat is started:
    5. ulimit -n 8192
  5. Save and close the file.
  6. Execute the command below to restart the tomcat service:
    7. /sbin/service tomcat restart

Change Tomcat startup options to improve garbage collection on your application server:

  1. Log into Linux on the Tomcat server as a user with root privileges.
  2. Open the file /etc/init.d/tomcat in a text editor.
  3. Find the line that begins with export JAVA_OPTS=.
  4. Change this line to read as follows.
    Important: All of the text below must be entered on a single line.
    5. export JAVA_OPTS="-server -Xmx1024m -XX:MaxNewSize=30m -X:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60-XX:ThreadStackSize=512"
  5. Save and close the file.
  6. Execute the command below to restart the tomcat service:
    7. /sbin/service tomcat restart

Avaya Aura® Session Manager

Installing Voice Portal certificate

In order for Voice Portal to establish a TLS connection to a Session Manager server, you must install the security certificate from Voice Portal on Session Manager.

If your Session Manager is version 6.x, refer to your Session Manager product documentation for instructions on how to install a security certificate on Session Manager. The relevant information can be found in the document Administering Avaya Aura® Session Manager in Chapter 3: Managing Security.

If your Session Manager is version 5.x, please contact Avaya technical support for help with installing the Voice Portal security certificate on Session Manager.

Session Manager certificate URL

In order for Voice Portal to establish a TLS connection to a Session Manager server, you must install the security certificate from Session Manager on Voice Portal. The correct URL to obtain the security certificate from Session Manager is:

https://<Session_Manager_SM-100>:5061

Note: The <Session_Manager_SM-100> above is the name or IP address of the SM-100 asset within your Session Manager server. Depending on your Session Manager configuration, the SM-100 asset may be either hardware or software.

Avaya SIP Enablement Services (SES)

Call distribution not balanced when an MPP is down

When all the MPPs in your system are in service, the SES properly balances the call load among the MPPs. If one MPP is taken out of service, though, all calls originally intended for the out-of-service MPP are rolled over to one of the remaining MPPs rather than being spread evenly among all of the remaining MPPs.

Note: Generally, this load imbalance will not cause any problems with the remaining MPPs taking calls. However, if your application makes any outcalls, such as during a bridged transfer, then it may encounter no-resource errors. These errors will occur if the MPP taking additional load from the out of service MPP has all ports busy.

SES certificate URL

In order for Voice Portal to establish a TLS connection to a SIP Enablement Services (SES) server, you must install the security certificate from SES on Voice Portal. The correct URL to obtain the security certificate from SES is:

https://<SES_Server>:5061

Note: The <SES_Server> above is the name or IP address of your SES server.

Loquendo speech servers

Resources not available error

Under some conditions, an MPP server may consume ASR/TTS resources on a Loquendo speech server even when there are no calls active on that MPP. This can prevent other MPP servers that share the same Loquendo speech server from being able to obtain speech resources when they are processing a call.

To work around this issue:

  1. Log into the VPMS web interface as a user with administrative privileges.
  2. Navigate to the Speech Servers page.
  3. For each Loquendo speech server on the ASR tab:
    1. Navigate to the Change ASR Server page for that Loquendo server.
    2. Set the value of parameter New Connection per Session to No.
    3. Click the Save button.
  4. For each Loquendo speech server on the TTS tab:
    1. Navigate to the Change TTS Server page for that Loquendo server.
    2. Set the value of parameter New Connection per Session to No.
    3. Click the Save button.

Microsoft Internet Explorer

Security problem trying to play utterances

You might see the error "A security problem occurred" from the Windows Media Player while playing an utterance from a Session Detail report. To listen to the utterance, right-click the utterance link and select Save Target As. For more information, see http://support.microsoft.com/default.aspx?scid=kb;en-us;885136.

Cannot view exported file

When you click the Export button on any VPMS page that includes this option, a File Download dialog box containing Open, Save, and Cancel buttons is displayed. If the Internet Explorer security option Do not save encrypted pages to disk is enabled, the Open button will not function properly.

To work around this issue, either:

Or

  1. In Internet Explorer, select Tools > Internet Options.
  2. On the Internet Options page, select the Advanced tab.
  3. On the Advanced tab, disable the Do not save encrypted pages to disk option, which is located in the Security section.

Cannot view report output from e-mail link

While viewing an e-mail that was sent by Voice Portal as the result of a scheduled report running, if you click the link to view the report output you may see either a blank page or the following message:

The requested file is no longer available.

This problem has only been observed when the scheduled report name contains multi-byte characters and the browser used is Internet Explorer 6.0.

To work around this issue, either:

Or

Nuance speech servers

Alarm QMRCP00008 when using MRCPv2

When a Voice Portal MPP starts up it attempts to communicate with each configured speech server. If Voice Portal is configured to communicate with a Nuance speech server using Media Resource Control Protocol version two (MRCPv2), then Voice Portal may erroneously generate alarm QMRCP00008, which indicates that the connection to the speech server has been lost.

To work around this issue you may simply ignore the false alarms. Or, you can configure Voice Portal to communicate with your Nuance speech servers using Media Resource Control Protocol version one (MRCPv1).

Remote DTMF Detection

If you are using Nuance speech servers and you have any applications with the Advanced Parameter Support Remote DTMF Processing set to Yes, then your Nuance speech servers must all be running NSS 5.0.4 or later. This is to prevent <noinput> VoiceXML exceptions from occurring for remote DTMF detection.

Recognition timeout while playing a long prompt

If your application plays a long prompt with barge-in enabled, the Nuance speech server may return a recognition timeout event before the prompt has completed playing. To remedy this problem, increase the session timeout parameter on the Nuance speech server to be longer than your longest application prompt.

For a Nuance Speech Server running on Linux:

  1. On the Nuance server, open the file $NSSSVRSDK/config/NSSserver.cfg in a text editor.
  2. Find the line in the form of the following:
    3. server.mrcp2.sip.sessionTimeout VXIInteger XXXXXX

    Note: The XXXXXX above is the session timeout in milliseconds. For example, for a two minute timeout XXXXXX would be 120000.

  3. Increase the timeout value XXXXXX on the line found above.
  4. Find the line in the form of the following:
    5. server.mrcp1.rtsp.sessionTimeout VXIInteger XXXXXX

    Note: The XXXXXX above is the session timeout in milliseconds. For example, for a two minute timeout XXXXXX would be 120000.

  5. Increase the timeout value XXXXXX on the line found above.
  6. Save and close the file.
  7. Restart the Nuance server.

For a Nuance Speech Server running on Windows:

  1. On the Nuance server, open the file %NSSSVRSDK%\config\NSSserver.cfg in a text editor.
  2. Find the line in the form of the following:
    3. server.mrcp2.sip.sessionTimeout VXIInteger XXXXXX

    Note: The XXXXXX above is the session timeout in milliseconds. For example, for a two minute timeout XXXXXX would be 120000.

  3. Increase the timeout value XXXXXX on the line found above.
  4. Find the line in the form of the following:
    5. server.mrcp1.rtsp.sessionTimeout VXIInteger XXXXXX

    Note: The XXXXXX above is the session timeout in milliseconds. For example, for a two minute timeout XXXXXX would be 120000.

  5. Increase the timeout value XXXXXX on the line found above.
  6. Save and close the file.
  7. Restart the Nuance server.

Getting recognition results on <nomatch> event

If you are using Nuance speech servers in their default configuration, when your application receives a <nomatch> event in response to a recognition request the application variable application.lastresult$ will not be updated with any recognition results. If you want your application to receive recognition results when a <nomatch> event is generated, then your Nuance speech servers must all be running NSS 5.0.7 or later and they must all be running NRec 9.0.11 or later. Additionally, you must perform the procedure below on each of your Nuance speech servers.

For a Nuance Speech Server running on Linux:

  1. On the Nuance server, open the file $NSSSVRSDK/config/NSSserver.cfg in a text editor.
  2. Find the line for parameter server.mrcp2.osrspeechrecog.mrcpdefaults.VSP.server.osrspeechrecog.result.sendnomatch.
  3. Change this line to read as follows.
    Important: All of the text below must be entered on a single line.
    4. server.mrcp2.osrspeechrecog.mrcpdefaults.VSP.server.osrspeechrecog.result.sendnomatch VXIString true

    Note: If present, be sure to remove the # character at the beginning of the above line to uncomment it.

  4. Find the line for parameter server.mrcp1.osrspeechrecog.result.sendnomatch.
  5. Change this line to read as follows.
    Important: All of the text below must be entered on a single line.
    6. server.mrcp1.osrspeechrecog.result.sendnomatch VXIString true

    Note: If present, be sure to remove the # character at the beginning of the above line to uncomment it.

  6. Save and close the file.
  7. Open the file $SWISRSDK/config/Baseline.xml in a text editor.
  8. If using NRec 9.0.11 or 9.0.1.2:
    1. Find the series of lines beginning with the following:
      2. <param name="swisr_result_enable_speech_mode">
    2. Change the series of lines to read as follows:
      3. <param name="swisr_result_enable_speech_mode">
          <value>1</value>
      </param>
  9. If using NRec 9.0.13 or later:
    1. Find the series of lines beginning with the following:
      2. <param name="swirec_result_enable_speech_mode">
    2. Change the series of lines to read as follows:
      3. <param name="swirec_result_enable_speech_mode">
          <value>1</value>
      </param>
  10. Save and close the file.
  11. Restart the Nuance server.

For a Nuance Speech Server running on Windows:

  1. On the Nuance server, open the file %NSSSVRSDK%\config\NSSserver.cfg in a text editor.
  2. Find the line for parameter server.mrcp2.osrspeechrecog.mrcpdefaults.VSP.server.osrspeechrecog.result.sendnomatch.
  3. Change this line to read as follows.
    Important: All of the text below must be entered on a single line.
    4. server.mrcp2.osrspeechrecog.mrcpdefaults.VSP.server.osrspeechrecog.result.sendnomatch VXIString true

    Note: If present, be sure to remove the # character at the beginning of the above line to uncomment it.

  4. Find the line for parameter server.mrcp1.osrspeechrecog.result.sendnomatch.
  5. Change this line to read as follows.
    Important: All of the text below must be entered on a single line.
    6. server.mrcp1.osrspeechrecog.result.sendnomatch VXIString true

    Note: If present, be sure to remove the # character at the beginning of the above line to uncomment it.

  6. Save and close the file.
  7. Open the file %SWISRSDK%\config\Baseline.xml in a text editor.
  8. If using NRec 9.0.11 or 9.0.1.2:
    1. Find the series of lines beginning with the following:
      2. <param name="swisr_result_enable_speech_mode">
    2. Change the series of lines to read as follows:
      3. <param name="swisr_result_enable_speech_mode">
          <value>1</value>
      </param>
  9. If using NRec 9.0.13 or later:
    1. Find the series of lines beginning with the following:
      2. <param name="swirec_result_enable_speech_mode">
    2. Change the series of lines to read as follows:
      3. <param name="swirec_result_enable_speech_mode">
          <value>1</value>
      </param>
  10. Save and close the file.
  11. Restart the Nuance server.

Chinese TTS using Nuance RealSpeak 4.0

In order to generate either Traditional Chinese or Simplified Chinese TTS using Nuance RealSpeak 4.0.10, you must configure RealSpeak correctly and ensure that the application behaves properly.

To generate Traditional Chinese:

  1. In the application, set the xml:lang attribute to zh-CN.
  2. In the application, set the XML encoding attribute to either UTF-16 or cp950.
  3. On the Nuance server, open the file /usr/local/SpeechWorks/MediaServer/server/config/OSSserver.cfg in a text editor.
  4. Find the line in the form of the following:
    5. server.realspeak4.language.XX.ShortName VXIString zh-guoyu

    Note: The XX above is a number.

  5. Change the line to read as follows:
    6. server.realspeak4.language.XX.ShortName VXIString zh-CN

    Note: The XX above is a number.

  6. Save and close the file.
  1. In the application, set the xml:lang attribute to zh-CN.
  2. On the Nuance server, open the file /usr/local/SpeechWorks/MediaServer/server/config/OSSserver.cfg in a text editor.
  3. Find the series of lines beginning with a line in the form of the following:
    4. server.realspeak4.language.XX.ShortName VXIString zh-guoyu

    Note: The XX above is a number.

  4. Change the series of lines to read as follows:
    5. server.realspeak4.language.XX.ShortName VXIString zh-CN
    server.realspeak4.language.XX.FullName VXIString Mandarin Chinese Big5
    server.realspeak4.language.XX.Voice VXIString Mei-Ling
    server.realspeak4.language.XX.Gender VXIString female

    Note: The XX above is a number.

  5. Save and close the file.

To generate Simplified Chinese:

  1. In the application, set the xml:lang attribute to zh-CN.
  2. In the application, set the XML encoding attribute to either UTF-16 or GB2132-80.
  3. On the Nuance server, open the file /usr/local/SpeechWorks/MediaServer/server/config/OSSserver.cfg in a text editor.
  4. Find the line in the form of the following:
    5. server.realspeak4.language.XX.ShortName VXIString zh-guoyu

    Note: The XX above is a number.

  5. Change the line to read as follows:
    6. server.realspeak4.language.XX.ShortName VXIString zh-CN

    Note: The XX above is a number.

  6. Save and close the file.
  1. In the application, set the xml:lang attribute to zh-CN.
  2. On the Nuance server, open the file /usr/local/SpeechWorks/MediaServer/server/config/OSSserver.cfg in a text editor.
  3. Find the series of lines beginning with a line in the form of the following:
    4. server.realspeak4.language.XX.ShortName VXIString zh-guoyu

    Note: The XX above is a number.

  4. Change the series of lines to read as follows:
    5. server.realspeak4.language.XX.ShortName VXIString zh-CN
    server.realspeak4.language.XX.FullName VXIString Mandarin Chinese GB
    server.realspeak4.language.XX.Voice VXIString Mei-Ling
    server.realspeak4.language.XX.Gender VXIString female

    Note: The XX above is a number.

  5. Save and close the file.

Chinese TTS using Nuance Speech Server 5.0

In order to generate either Traditional Chinese or Simplified Chinese TTS using Nuance RealSpeak voice Mei-Ling 4.0.6 with Nuance Speech Server (NSS) 5.0.x, you must configure NSS correctly.

For a Nuance Speech Server running on Linux:

  1. On the Nuance server, open the file $NSSSVRSDK/config/NSSserver.cfg in a text editor.
  2. Find the series of lines below:
    3. server.rsspeechsynth.languageid.zh VXIString Mandarin Chinese
    server.rsspeechsynth.languageid.zh-CN VXIString Mandarin Chinese
    server.rsspeechsynth.languageid.zh-guoyu VXIString Mandarin Chinese
  3. Change the series of lines to read as follows:
    4. server.rsspeechsynth.languageid.zh VXIString Mandarin Chinese
    server.rsspeechsynth.languageid.zh-CN VXIString Mandarin Chinese GB
    server.rsspeechsynth.languageid.zh-guoyu VXIString Mandarin Chinese B5
  4. Save and close the file.
  5. Restart the Nuance server.

For a Nuance Speech Server running on Windows:

  1. On the Nuance server, open the registry editor.
  2. Create or edit registry keys as necessary to match the values shown below:
    3. [HKEY_LOCAL_MACHINE\SOFTWARE\ScanSoft\RealSpeak 4.0\Language Resources\Mandarin Chinese B5 (Mei-Ling)]
    "Gender"="female"
    "LanguageName"="Mandarin Chinese B5"
    "LanguageTag"="zh-guoyu-b5"
    "VoiceName"="Mei-Ling"
    [HKEY_LOCAL_MACHINE\SOFTWARE\ScanSoft\RealSpeak 4.0\Language Resources\Mandarin Chinese GB (Mei-Ling)]
    "Gender"="female"
    "LanguageName"="Mandarin Chinese GB"
    "LanguageTag"="zh-guoyu-gb"
    "VoiceName"="Mei-Ling"
  3. Close the registry editor.
  4. Open the file %NSSSVRSDK%\config\NSSserver.cfg in a text editor.
  5. Find the series of lines below:
    6. server.rsspeechsynth.languageid.zh VXIString Mandarin Chinese
    server.rsspeechsynth.languageid.zh-CN VXIString Mandarin Chinese
    server.rsspeechsynth.languageid.zh-guoyu VXIString Mandarin Chinese
  6. Change the series of lines to read as follows:
    7. server.rsspeechsynth.languageid.zh VXIString Mandarin Chinese
    server.rsspeechsynth.languageid.zh-CN VXIString Mandarin Chinese GB
    server.rsspeechsynth.languageid.zh-guoyu VXIString Mandarin Chinese B5
  7. Save and close the file.
  8. Restart the Nuance server.

More Information

Online: