How speech recognition is configured

As explained below, the plug-in class to be used for any individual recognition attempt is found using RecoService configuration entries, together with RecoDefinitions.

How is the RecoService configuration entry used?

As part of the NodeName configuration entry, you should have a RecoService configuration entry for each plug-in on each operating system platform you use in your WebSphere Voice Response Java and VoiceXML Environment plex. This is simple if you have a homogeneous system, for example, all your voice response nodes run AIX. It is simpler still if you have only one speech recognition technology.

If you do have voice response nodes with different operating systems, the RecoService entries for each one is distinguished by the RecoService=name. The RecoType=name keyword identifies the technology, which should be the same on both (or all) RecoService entries.

MRCP can be configured so that in the event of a configured MRCP resource becoming unavailable, a secondary back-up server can take over so that MRCP activity can continue. The speech recognition session is restored on the backup server to the same state as the primary server prior to the failure. Any grammars, or session variables being used are also reinstated, so that the recovered session functions in the same way as the working primary server. The URI of the back-up server is specified by the second InitSessionString keyword in a RecoService entry in configuration file default.cff.

For more information, and an example of a RecoService entry, see RecoService configuration entry

Each voice response node has a NodeName configuration entry, in which the relevant RecoService entries are identified. For detailed information see NodeName configuration entry.

What is a RecoDefinition?

A RecoDefinition contains two items of information: RecoType and locale identifier. RecoType is a platform-independent name for the speech recognition technology. The locale identifier identifies the languages for which this technology is to be used. The locale identifier can be an asterisk (*), indicating “all locales”. For more information about locale identifiers, see How languages are identified in VoiceXML and Java.

Hint: It is often convenient to configure a plug-in for a language instead of the full locale. For example, if you have a German reco engine and configure it for the "de" locale, applications running in de_DE, de_AT, and de_CH can all use this reco service for speech recognition. If you configure it for "de_DE", applications running in de_AT and de_CH will not be able to access the reco resource.

If you are running VoiceXML applications that use speech recognition, you must include a RecoDefinition for the language-only part of your locale as well as a RecoDefinition for the full locale. For example, to run a VoiceXML application in the en_US locale, you must include the following RecoDefinition entries:

RecoDefinition=en,recoType
RecoDefinition=en_US,recoType

where recoType is the name of your RecoType.

Applications running in an unsupported locale will use the language-only RecoDefinition for default behaviour such as error messages. For example, if you are running a VoiceXML application in New Zealand, with a locale of en_NZ, your RecoDefinitions will be as follows:

RecoDefinition=en,recoType
RecoDefinition=en_NZ,recoType

In the above example, if your application encounters an error which causes it to play the default error message "Sorry, must exit due to processing error", this message will play in the 'en' locale, which is American English. The dialect of the 'en' locale may not be correct for your application, in which case, you should provide your own default behaviour.

In most cases the full locale is compatible with the language-only locale. The exception is Chinese, which has locales of 'zh' (simplified Chinese) and 'zh_HK' (traditional Chinese). If your application uses Chinese you must be careful to use the correct locale because grammars compiled for one locale will not load in an engine designed for the other.

Where should you put the RecoDefinitions?

There are three places where you can put RecoDefinitions. The simplest is to put them in the NodeName configuration entry. These definitions apply to all applications run in the node.

If you need to specify different technologies for different applications, you can override the RecoDefinitions in the NodeName entry, by putting RecoDefinitions in the AppName configuration entry. Read Specifying RecoDefinitions for an application if you need to do this.

The bottom line is: put the definitions in the NodeName entry unless your applications need to use different technologies.