![]() |
In earlier releases of Experience Portal , only a single speech vendor type could be utilized during a call. From Release 7.2.2, customers can select multiple speech recognition vendor types for the same call.
The application in Experience Portal can be assigned to more than one speech recognition vendor. Each speech recognition vendor which is assigned to the application, has individual settings for vendor specific parameters such as Languages, and Acquire and Release control.
Applications such as Orchestration Designer or VXML, must specify the speech recognition vendor that must be used when requesting speech recognition. This is accomplished by defining a new VXML property that must be in the VXML scope wherever recognition grammars are defined. This VXML property instructs Experience Portal to load the grammar on a specific speech recognition vendor, and therefore determines which speech recognition vendor will perform the recognition.
![]() | Note: |
Only one speech recognition vendor can perform recognition at a time.
Applications can specify the speech recognition vendor by using the following VXML property:
<property name=”com.avaya.asr.vendor” value=”” />
The valid values for this property are:
nuance osr
loquendo
googleasr
dialogflowasr
nuancedlgaas
These values are not case-sensitive. However, ensure that you use white spaces wherever present.
The grammars fail to load if there are any invalid or empty values for this property, or if the vendor specified in this property is not assigned to the application.
Speech grammars
For speech recognition, the vendor property must be in scope when the VXML interpreter runs any VXML element that represents a speech grammar.
This includes the <grammar>, <option> and <choice> elements. For the complete list of all possible elements that can represent a voice grammar, see the VXML specification.
DTMF grammars
If remote DTMF processing is enabled on the application, the vendor property must be in scope when the VXML interpreter runs any VXML element that represents a DTMF grammar.
The following are some examples of VXML elements for DTMF. For the complete list of all possible elements that can represent a DTMF grammar, see the VXML specification.
<choice> element
<option> element
<link> element with the dtmf attribute
DTMF <grammar> element
<record> element with the ‘dtmfterm’ attribute set to true
If remote DTMF processing is not enabled on the application, then the vendor property is not required for DTMF grammars. In such cases, Experience Portal internally performs DTMF recognition. A speech recognition vendor is not required.
For applications that are configured with a single speech recognition vendor, you do not need to specify the vendor property in VXML.
![]() | Note: |
|
These guidelines also apply for all OD applications. The property name and valid values are the same as that of VXML applications. In OD applications, the property is created as an external property. |
The following table lists the application design recommendations for developing an application that uses multiple speech recognition vendors.
![]() | Note: |
|
The term grammar refers to a VXML <grammar> element. It also refers to any VXML element that the VXML interpreter translates to a grammar. |
| Type | Description | Design recommendation | ||||
|---|---|---|---|---|---|---|
| VXML scope of vendor property |
The vendor property, that is in the VXML scope at the time the interpreter runs a grammar,
defines which speech recognition vendor the
grammar is be loaded on. It defines which speech
recognition vendor will perform the
recognition.
If multiple vendors are in use within the same VXML document, it is possible to accidentally load two grammars on two speech recognition vendors. This is solely dependent on the scope of both the VXML vendor property and the grammars.
|
The outcome of this design is that all grammars in a VXML document are loaded on a single speech recognition vendor. Defining the property at the form or field level can complicate the design of the application. |
||||
| Application root documents |
If the application is designed with an application root document,
defining grammars in the application root document introduces complications
regarding the following:
|
If the application root document defines grammars which need to
be common across all speech recognition vendors, ensure that these
application root grammars are defined for each speech recognition
vendor that is used by the application.
For example, an application root document defines a common return grammar that allows the user to speak a return command that brings them back to the start of the application. The application uses both Nuance and Loquendo speech recognition in different sections and there is a leaf document per recognition vendor. To load and activate the common return grammar on both Nuance and Loquendo speech recognition vendors, the grammar must be defined twice in the application root document (per vendor). This can be accomplished by defining a <form> per vendor with the document scope in the application root document.
|
||||
| Event handler documents | Like the application root document, defining grammars in the event handler documents can introduce complications. | If the application defines grammars within event handler documents, ensure that the grammar is defined for all required speech recognition vendors. |
![]() | Note: |
|
The multiple speech recognition vendor feature does not support the override of the ASR server or ASR languages in CCXML. |
The speech events in the transcription data of the Session detail record contain the ASR server, where the recognition is performed, and the ASR session ID.
A new event ASRVendorChange is added to Transcriptions to identify when a different speech recognition vendor begins recognition on a session.