Requesting speech processing resources

Speech applications can request specific resource capabilities. For example, a request for a particular, large grammar that is already loaded. For information on how the VoiceXML application requests resources, see Speech processing with VoiceXML.

In response to application requests, the MRCP client requests specific resources using any of the following techniques:

Configure the session in the initial SIP INVITE request. See Session configuration (session.xml).
Request resources in the initial INVITE request. See the SIP Accept-Contact header.
Request resources. See the SIP OPTIONS request.

Session configuration (session.xml)

Applications use a session.xml file to configure Nuance speech products at the start of each session. For an overview, see Nuance-specific capabilities. For a description of session.xml format and parameters, see Configuring application sessions.

By default, each Speech Server host has access to a single session.xml file shared by all applications using that Speech Server. This is satisfactory when the host runs instances of a single application, but less satisfactory when running multiple applications (because it prevents tuning or customization of individual sessions).

Alternatively, the MRCP client can provide a session.xml at the start of each session. This enables each application to have a different session.xml configuration, but requires implementation in the client. Nuance strongly recommends this implementation. The mechanism works as follows:

The voice platform defines how the application creates a session.xml. Normally, the application developer creates the file and stores it in a location defined by the voice platform. More sophisticated techniques are also possible. For example, the platform could generate a session.xml from configuration details stored in a database.
The voice platform passes the application’s session.xml at the start of each session when it sends the SIP INVITE message. The configuration settings override any default session.xml on the host, and become default values for the duration of the session.

Accept-Contact header

The SIP Accept-Contact header specifies capabilities that the application needs from a speech-processing resource. If those capabilities are not available, the system responds to the INVITE with an error.

In the following example, the client uses the Accept-Contact and Reject-Contact headers in an INVITE request to query the capabilities of the MRCPv2 server. The example is contrived, but illustrates the matching process. For detailed information on the Accept-Contact header, see Caller Preferences for the Session Initiation Protocol (SIP), RFC 3841.

Example

Imagine there are four registered Contacts for sip:user@example.com:

Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.2

Contact: sip:u2@h.example.com;audio="FALSE";methods="INVITE";
	actor="msg-taker";q=0.2

Contact: sip:u3@h.example.com;audio;actor="msg-taker";methods="INVITE";
	video;q=0.3

Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.2

An INVITE sent to sip:user@example.com contained the following caller preferences header fields:

Client->Server:

 INVITE sip:mresources@example.com SIP/2.0

 Max-Forwards:6

 To:MediaServer <sip:mresources@example.com>

 From:sarvi <sip:sarvi@example.com<;tag=3D1928301774

 Call-ID:a84b4c76e66710

 CSeq:314159 INVITE

 Content-Type:application/sdp

 Content-Length:...

 Contact:<sip:sarvi@client.example.com>

    Reject-Contact: *;actor="msg-taker";video

    Accept-Contact: *;audio;require

    Accept-Contact: *;video;explicit

    Accept-Contact: *;methods="BYE";class="business";q=1.0

 v=3D0

 o=3Dsarvi 2890844526 2890842807 IN IP4 192.0.2.4

 s=3DSet up MRCPv2 control and audio

 i=3DInitial contact

 c=3DIN IP4 192.0.2.12

S->C:

 SIP/2.0 200 OK

 To:MediaServer <sip:mresources@example.com<;tag=3D62784

 From:sarvi <sip:sarvi@example.com<;tag=3D1928301774

 Call-ID:a84b4c76e66710

 CSeq:314159 INVITE

 Contact:<sip:mresources@server.example.com>

 Content-Type:application/sdp

 Content-Length:...

 v=3D0

 o=3Dsarvi 2890844526 2890842807 IN IP4 192.0.2.4

 s=3DSet up MRCPv2 control and audio

 i=3DInitial contact

 c=3DIN IP4 192.0.2.11

First, the server processes the Reject-Contact header field, which is an explicit match only for u3. So, u3 gets discarded, and the others remain.

Next, each of the remaining three contacts is compared against each of the three Accept-Contact predicates.

u2 doesn’t match the first predicate. Because that predicate has a require tag, u2 is discarded.
u1 is a match to all three, earning a score of 1.0 for the first two predicates, and 0.5 for the third (the method’s feature tag was present in the contact predicate, but the class tag was not). u1 matches all three Accept-Contact predicates, so its matching set contains all three, with scores of 1, 1, and 0.5.
u4 matches the first predicate, earning a score of 1.0. u4 also matches the second predicate, but since the match is not explicit, the score is set to zero. u4 does not match the third predicate. u4 matches two Accept-Contact predicates, so its matching set contains scores of 1 and 0.5
Next, the two contacts, u1 and u4, are ordered based on their average score values (Qa). u1 has a Qa of 0.83, and u4, a Qa of 0.5. The resulting ordered set of contacts in the target set is u1 followed by u4.

OPTIONS request

Use an OPTIONS request to use SDP (Session Description Protocol) to describe the resources supported by the server. Such an SDP-encoded description, which uses the SDP resource attribute, would overlap with a similar statement encoded as feature parameters of the Contact header.

Resource support can be indicated by both SDP resource attributes and by the feature tags defined in the SDP specification. When a feature tag describes a capability that can also be represented with an SDP resource attribute, an MRCPv2 server must use the resource attribute to describe the capability. Resource capabilities that do not overlap with resource attributes are specified as parameters of the Contact header field of the OPTIONS response.

Requesting speech processing resources

Session configuration (session.xml)

Accept-Contact header

OPTIONS request

Related topics