One document matched: draft-ietf-speechsc-mrcpv2-06.txt
Differences from draft-ietf-speechsc-mrcpv2-05.txt
Internet Engineering Task Force Saravanan Shanmugham
Internet-Draft Cisco Systems Inc.
draft-ietf-speechsc-mrcpv2-06 Daniel C. Burnett
Expires: August 20, 2005 Nuance Communications
February 20, 2005
Media Resource Control Protocol Version 2(MRCPv2)
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been
disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt .
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html .
This Internet-Draft will expire on August 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes a proposal for a Media Resource Control
Protocol Version 2 (MRCPv2) and aims to meet the requirements
specified in the SPEECHSC working group requirements document. It is
based on the Media Resource Control Protocol (MRCP), also called
S. Shanmugham, et. al. Page 1
MRCPv2 Protocol February, 2005
MRCPv1 developed jointly by Cisco Systems, Inc., Nuance
Communications, and Speechworks Inc.
The MRCPv2 protocol will control media service resources like speech
synthesizers, recognizers, signal generators, signal detectors, fax
servers etc. over a network. This protocol depends on a session
management protocol such as the Session Initiation Protocol (SIP) to
establish a separate MRCPv2 control session between the client and
the server. It also depends on SIP to establish the media pipe and
associated parameters between the media source or sink and the media
server. Once this is done, the MRCPv2 protocol exchange can happen
over the control session established above allowing the client to
command and control the media processing resources that may exist on
the media server.
Table of Contents
Status of this Memo..............................................1
Copyright Notice.................................................1
Abstract.........................................................1
Table of Contents................................................2
1. Introduction:.............................................4
2. Notational Convention.....................................5
3. Architecture:.............................................6
3.1. Server and Resource Addressing............................8
4. MRCPv2 Protocol Basics....................................8
4.1. Connecting to the Server..................................8
4.2. Managing Resource Control Channels........................9
4.3. Media Streams and RTP Ports..............................15
4.4. MRCPv2 Message Transport.................................16
5. MRCPv2 Specification.....................................17
5.1. Request..................................................18
5.2. Response.................................................19
5.3. Event....................................................20
6. MRCP Generic Features....................................21
6.1. Generic Message Headers..................................21
6.2. SET-PARAMS...............................................30
6.3. GET-PARAMS...............................................31
7. Resource Discovery.......................................31
8. Speech Synthesizer Resource..............................33
8.1. Synthesizer State Machine................................33
8.2. Synthesizer Methods......................................34
8.3. Synthesizer Events.......................................34
8.4. Synthesizer Header Fields................................34
8.5. Synthesizer Message Body.................................41
8.6. SPEAK....................................................43
8.7. STOP.....................................................45
8.8. BARGE-IN-OCCURRED........................................46
8.9. PAUSE....................................................47
8.10. RESUME...................................................48
S Shanmugham IETF-Draft Page 2
MRCPv2 Protocol February, 2005
8.11. CONTROL..................................................50
8.12. SPEAK-COMPLETE...........................................51
8.13. SPEECH-MARKER............................................52
8.14. DEFINE-LEXICON...........................................53
9. Speech Recognizer Resource...............................54
9.1. Recognizer State Machine.................................55
9.2. Recognizer Methods.......................................55
9.3. Recognizer Events........................................56
9.4. Recognizer Header Fields.................................56
9.5. Recognizer Message Body..................................71
9.6. Natural Language Semantic Markup Language................75
9.7. Enrollment Results.......................................83
9.8. DEFINE-GRAMMAR...........................................85
9.9. RECOGNIZE................................................88
9.10. STOP.....................................................91
9.11. GET-RESULT...............................................93
9.12. START-OF-SPEECH..........................................93
9.13. START-INPUT-TIMERS.......................................94
9.14. RECOGNITION-COMPLETE.....................................94
9.15. START-PHRASE-ENROLLMENT..................................96
9.16. ENROLLMENT-ROLLBACK......................................97
9.17. END-PHRASE-ENROLLMENT....................................98
9.18. MODIFY-PHRASE............................................98
9.19. DELETE-PHRASE............................................99
9.20. INTERPRET................................................99
9.21. INTERPRETATION-COMPLETE.................................100
9.22. DTMF Detection..........................................101
10. Recorder Resource.......................................102
10.1. Recorder State Machine..................................102
10.2. Recorder Methods........................................102
10.3. Recorder Events.........................................102
10.4. Recorder Header Fields..................................102
10.5. Recorder Message Body...................................107
10.6. RECORD..................................................107
10.7. STOP....................................................108
10.8. RECORD-COMPLETE.........................................109
10.9. START-INPUT-TIMERS......................................109
11. Speaker Verification and Identification.................111
11.1. Speaker Verification State Machine......................112
11.2. Speaker Verification Methods............................112
11.3. Verification Events.....................................113
11.4. Verification Header Fields..............................113
11.5. Verification Result Elements............................121
11.6. START-SESSION...........................................125
11.7. END-SESSION.............................................126
11.8. QUERY-VOICEPRINT........................................126
11.9. DELETE-VOICEPRINT.......................................127
11.10. VERIFY..................................................128
11.11. VERIFY-FROM-BUFFER......................................128
11.12. VERIFY-ROLLBACK.........................................131
11.13. STOP....................................................132
S Shanmugham IETF-Draft Page 3
MRCPv2 Protocol February, 2005
11.14. START-INPUT-TIMERS......................................133
11.15. VERIFICATION-COMPLETE...................................133
11.16. START-OF-SPEECH.........................................134
11.17. CLEAR-BUFFER............................................134
11.18. GET-INTERMEDIATE-RESULT.................................134
12. Security Considerations.................................135
13. IANA Considerations.....................................135
13.1. New registries..........................................135
13.2. NLSML-related registrations.............................137
13.3. session URL scheme registration.........................139
13.4. SDP parameter registrations.............................140
14. Examples:...............................................141
14.1. Message Flow............................................141
14.2. Recognition Result Examples.............................149
Normative Reference............................................153
Appendix.......................................................155
A.1 ABNF Message Definitions...................................155
A.2 XML Schema and DTD.........................................168
A.2.1 Recognition Results......................................168
A.2.2 Enrollment Results.......................................170
A.2.3 Verification Results.....................................171
Full Copyright Statement.......................................175
Intellectual Property..........................................175
Contributors...................................................176
Acknowledgements...............................................176
Editors' Addresses.............................................177
1. Introduction:
The MRCPv2 protocol is designed for a client device to control media
processing resources on the network allowing to process and
audio/video stream. Some of these media processing resources could
be speech recognition, speech synthesis engines, speaker
verification or speaker identification engines. This allows a vendor
to implement distributed Interactive Voice Response platforms such
as VoiceXML [7] browsers.
The protocol requirements of SPEECHSC require that the protocol
is capable of reaching a media processing server and setting up
communication channels to the media resources, to send/recieve
control messages and media streams to/from the server. The Session
Initiation Protocol (SIP) protocol described in [4] meets these
requirements and is used to setup and tear down media and control
pipes to the server. In addition, the SIP re-INVITE can be used to
change the characteristics of these media and control pipes mid-
session. The MRCPv2 protocol hence is designed to leverage and
build upon a session management protocols such as Session Initiation
Protocol (SIP) and Session Description Protocol (SDP). SDP is used
to describe the parameters of the media pipe associated with that
S Shanmugham IETF-Draft Page 4
MRCPv2 Protocol February, 2005
session. It is mandatory to support SIP as the session level
protocol to ensure interoperability. Other protocols can be used at
the session level by prior agreement.
The MRCPv2 protocol depends on SIP and SDP to create the session,
and setup the media channels to the server. It also depends on SIP
and SDP to establish MRCPv2 control channels between the client and
the server for each media processing resource required for that
session. The MRCPv2 protocol exchange between the client and the
media resource can then happen on that control channel. The MRCPv2
protocol exchange happening on this control channel does not change
the state of the SIP session, the media or other parameters of the
session SIP initiated. It merely controls and affects the state of
the media processing resource associated with that MRCPv2 channel.
The MRCPv2 protocol defines the messages to control the different
media processing resources and the state machines required to guide
their operation. It also describes how these messages are carried
over a transport layer such as TCP, TLS or, in the future, SCTP.
2. Notational Convention
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[9].
Since many of the definitions and syntax are identical to HTTP/1.1,
this specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [1]).
All the mechanisms specified in this document are described in both
prose and an augmented Backus-Naur form (ABNF). It is described in
detail in RFC 2234 [3].
The complete message format in ABNF form is provided in Appendix
section 12.1 and is the normative format definition.
Media Resource
An entity on the MRCP Server that can be controlled through the
MRCP protocol
MRCP Server
Aggregate of one or more "Media Resource" entities on a Server,
exposed through the MRCP protocol.("Server" for short)
MRCP Client
An entity controlling one or more Media Resources through the
MRCP protocol. ("Client" for short)
S Shanmugham IETF-Draft Page 5
MRCPv2 Protocol February, 2005
3. Architecture:
The system consists of a client that requires the generation of
media streams or requires the processing of media streams and a
media resource server that has the resources or engines to process
or generate these streams. The client establishes a session using
SIP and SDP with the server to use its media processing resources. A
SIP URI refers to the MRCPv2 server.
The session management protocol (SIP) will use SDP with the
offer/answer model described RFC 3264 to describe and setup the
MRCPv2 control channels. Separate MRCPv2 control channels are need
for controlling the different media processing resources associated
with that session. Within a SIP session, the individual resource
control channels for the different resources are added or removed
through the SDP offer/answer model and the SIP re-INVITE dialog.
The server, through the SDP exchange, provides the client with a
unique channel identifier and a TCP port number. The client MAY then
open a new TCP connection with the server using this port number.
Multiple MRCPv2 channels can share a TCP connection between the
client and the server. All MRCPv2 messages exchanged between the
client and the server will also carry the specified channel
identifier that MUST be unique among all MRCPv2 control channels
that are active on that server. The client can use this channel to
control the media processing resource associated with that channel.
The session management protocol (SIP) will also establish media
pipes between the client (or source/sink of media) and the MRCP
server using SDP m-lines. A media pipe maybe shared by one or more
media processing resources under that SIP session or each media
processing resource may have its own media pipe.
MRCPv2 client MRCPv2 Media Resource Server
|--------------------| |-----------------------------|
||------------------|| ||---------------------------||
|| Application Layer|| || TTS | ASR | SV | SI ||
||------------------|| ||Engine|Engine|Engine|Engine||
||Media Resource API|| ||---------------------------||
||------------------|| || Media Resource Management ||
|| SIP | MRCPv2 || ||---------------------------||
||Stack | || || SIP | MRCPv2 ||
|| | || || Stack | ||
||------------------|| ||---------------------------||
|| TCP/IP Stack ||----MRCPv2---|| TCP/IP Stack ||
|| || || ||
||------------------||-----SIP-----||---------------------------||
|--------------------| |-----------------------------|
| /
S Shanmugham IETF-Draft Page 6
MRCPv2 Protocol February, 2005
SIP /
| /
|-------------------| RTP
| | /
| Media Source/Sink |-------------/
| |
|-------------------|
Fig 1: Architectural Diagram
MRCPv2 Media Resource Types:
The MRCP server may offer one or more of the following media
processing resources to its clients.
Basic Synthesizer
A speech synthesizer resource with very limited capabilities, that
can be achieved through the playing out concatenated audio file
clips. The speech data is described as SSML data but with limited
support for its elements. It MUST support <speak>, <audio>, <say-as>
and <mark> tags in SSML.
Speech Synthesizer
A full capability speech synthesizer capable of rendering regular
speech and SHOULD have full SSML support.
Recorder
A resource capable of recording audio and saving it to an URI. It
also has some end-pointing capabilities for detecting beginning
speech and silence at the end of recording.
DTMF Recognizer
A limited DTMF only recognizer that is able to recognize DTMF digits
in the input stream to match supplied digit grammar. It could also
do a semantic interpretation based on semantic tags in the grammar.
Speech Recognizer
A full speech recognizer that is capable of receiving audio and
interpreting it to recognition results. It also has a natural
language semantic interpreter to post process the recognized data
according to the semantic data in the grammar and provide semantic
results along with the recognized input. The recognizer may also
S Shanmugham IETF-Draft Page 7
MRCPv2 Protocol February, 2005
support enrolled grammars, where the client can enroll and create
new personal grammars for use in future grammars.
Speaker Verification
A resource capable of verifying the authenticity of a person by
matching his voice to a saved voice-print. This may also involve
matching the callers voice with more than one voice-print, also
called multi-verification or speaker identification.
3.1. Server and Resource Addressing
The MRCPv2 server as a whole is a generic SIP server and addressed
by a specific SIP URL registered by the server.
Example:
sip:mrcpv2@mediaserver.com
4. MRCPv2 Protocol Basics
MRCPv2 requires the use of a connection oriented transport layer
protocol such as TCP or SCTP to guarantee reliable sequencing and
delivery of MRCPv2 control messages between the client and the
server. If security is needed a TLS connection is used to carry
MRCPv2 messages. One or more TCP, TLS or SCTP(in the future)
connections between the client and the server can be shared between
different MRCPv2 channels to the server. The individual messages
carry the channel identifier to differentiate messages on different
channels. The message format for MRCPv2 is text based with
mechanisms to carry embedded binary data. This allows data like
recognition grammars, recognition results, synthesizer speech markup
etc. to be carried in the MRCPv2 message between the client and the
server resource. The protocol does not address session and media
establishment and management and relies of SIP and SDP to do this.
4.1. Connecting to the Server
The MRCPv2 protocol depends on a session establishment and
management protocol such as SIP in conjunction with SDP. The client
finds and reaches a MRCPv2 server across the SIP network using the
INVITE and other SIP dialog exchanges. The SDP offer/answer exchange
model over SIP is used to establish resource control channels for
each resource. The SDP offer/answer exchange is also used to
establish media pipes between the source or sink of audio and the
server.
S Shanmugham IETF-Draft Page 8
MRCPv2 Protocol February, 2005
4.2. Managing Resource Control Channels
The client needs a separate MRCPv2 resource control channel to
control each media processing resource under the SIP session. A
unique channel identifier string identifies these resource control
channels. The channel identifier string consists of a hexadecimal
number specifying the channel ID followed by a string token
specifying the type of resource separated by an "@". The server
generates the hexadecimal channel ID and MUST make sure it does not
clash with any other MRCP channel allocated to that server. MRCPv2
defines the following type of media processing resources. Additional
resource types, their associated methods/events and state machines
can be added by future specification proposing to extend the
capabilities of MRCPv2.
Resource Type Resource Description
speechrecog Speech Recognizer
dtmfrecog DTMF Recognizer
speechsynth Speech Synthesizer
basicsynth Basic Synthesizer
speakverify Speaker Verification
recorder Speech Recorder
The SIP INVITE or re-INVITE dialog exchange and the SDP offer/answer
exchange it carries, will contain m-lines describing the resource
control channel it wants to allocate. There MUST be one SDP m-line
for each MRCPv2 resource that needs to be controlled. This m-line
will have a media type field of "application" and a transport type
field of "TCP/MRCPv2", "TCP/TLS/MRCPv2". The usage of SCTP with
MRCPv2 will be addressed in a separate draft. The port number field
of the m-line MUST contain the discard port of the transport
protocol (say port 9 for TCP) in the SDP offer from the client and
MUST contain the TCP listen port on the server in the SDP answer.
The client may then setup a TCP or TLS connection to that server
port or share an already established connection to that port. The
format field of the m-line is not used and MUST be left empty. The
client must specify the resource type identifier in the resource
attribute associated with the control m-line of the SDP offer. The
server MUST respond with the full Channel-Identifier (which includes
the resource type identifier and an unique hexadecimal identifier),
in the "channel" attribute associated with the control m-line of the
SDP answer.
All servers MUST support TLS, SHOULD support TCP and MAY support
SCTP(in the future) and it is up to the client to choose which mode
of transport it wants to use for an MRCPv2 session. When using TCP,
TLS the m-lines MUST conform to IETF draft[20] which describes the
usage of SDP for connection oriented transport. When using TLS the
SDP m-line for the control pipe MUST conform to the IETF draft[21]
in addition to the IETF draft[20]. IETF draft[21] specifies the
S Shanmugham IETF-Draft Page 9
MRCPv2 Protocol February, 2005
usage of SDP for establishing a secure connection oriented transport
over TLS.
When the client wants to add a media processing resource to the
session, it MUST initiate a re-INVITE dialog. The SDP offer/answer
exchange contained in this SIP dialog will contain an additional
control m-line for the new resource that needs to be allocated. The
server, on seeing the new m-line, will allocate the resource and
respond with a corresponding control m-line in the SDP answer
response.
The a=setup attribute as described in [20] MUST be "active" for the
offer from the client and MUST be "passive" for the answer from the
MRCP server. The a=connection attribute MUST have a value of "new"
on the very first control m-line offer from the client to a MRCP
server. Subsequent control m-lines offers from the client to the
MRCP server MAY contain "new" or "existing", depending on whether
the client wants to share a existing connection oriented pipe. The
value of "existing" tells the server that the client wants to reuse
an existing transport connection between the client and the server.
The server can respond with a value of "existing", if wants to allow
sharing of existing pipes or can reply with a value of "new", in
which case the client MUST initiate new connection oriented pipe.
When the client wants to de-allocate the resource from this session,
it MUST initiate a SIP re-INVITE dialog with the server and MUST
offer the control m-line with a port 0. The server MUST then answer
the control m-line with a response of port 0. This de-allocates the
usage of the associated MRCP identifier and resource. But may not
close the TCP, SCTP or TLS connection if it is currently being
shared among multiple MRCP channels. When all MRCP channels that may
be sharing the connection are released and the associated SIP
connections are closed, the client or server disconnect the shared
connection oriented pipe.
Example 1:
This exchange adds a resource control channel for a synthesizer.
Since a synthesizer would be generating an audio stream, this
interaction also creates a receive-only audio stream for the server
to send audio to.
C->S:
INVITE sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sip:sarvi@cisco.com>
S Shanmugham IETF-Draft Page 10
MRCPv2 Protocol February, 2005
Content-Type: application/sdp
Content-Length: ...
v=0
o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:new
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=recvonly
a=mid:1
S->C:
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=application 32416 TCP/MRCPv2
a=setup:passive
a=connection:new
a=channel:32AECB234338@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 00 96
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
C->S:
ACK sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
S Shanmugham IETF-Draft Page 11
MRCPv2 Protocol February, 2005
CSeq: 314162 ACK
Content-Length: 0
Example 2:
This exchange continues from example 1 and allocates an additional
resource control channel for a recognizer. Since a recognizer would
need to receive an audio stream for recognition, this interaction
also updates the audio stream to sendrecv making it a 2-way audio
stream.
C->S:
INVITE sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:existing
a=resource:speechrecog
a=cmid:1
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
a=mid:1
S->C:
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
S Shanmugham IETF-Draft Page 12
MRCPv2 Protocol February, 2005
CSeq: 314163 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 131
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=application 32416 TCP/MRCPv2
a=setup:passive
a=connection:existing
a=channel:32AECB234338@speechrecog
a=cmid:1
m=application 32416 TCP/MRCPv2
a=setup:passive
a=connection:existing
a=channel:32AECB234339@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
a=mid:1
C->S:
ACK sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314164 ACK
Content-Length: 0
Example 3:
This exchange continues from example 2 and de-allocates recognizer
channel. Since a recognizer would not need to receive an audio
stream any more, this interaction also updates the audio stream to
recvonly.
C->S:
INVITE sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
S Shanmugham IETF-Draft Page 13
MRCPv2 Protocol February, 2005
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=application 0 TCP/MRCPv2
a=resource:speechrecog
a=cmid:1
m=application 9 TCP/MRCPv2
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=recvonly
a=mid:1
S->C:
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 131
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=application 0 TCP/MRCPv2
a=channel:32AECB234338@speechrecog
a=cmid:1
m=application 32416 TCP/MRCPv2
a=channel:32AECB234339@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
C->S:
ACK sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
S Shanmugham IETF-Draft Page 14
MRCPv2 Protocol February, 2005
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314164 ACK
Content-Length: 0
4.3. Media Streams and RTP Ports
The client or the server would need to add audio (or other media)
pipes between the client and the server and associate them with the
resource that would process or generate the media. One or more
resources could be associated with a single media channel or each
resource could be assigned a separate media channel. For example, a
synthesizer and a recognizer could be associated to the same media
pipe(m=audio line), if it is opened in "sendrecv" mode.
Alternatively, the recognizer could have its own "sendonly" audio
pipe and the synthesizer could have its own "recvonly" audio pipe.
The association between control channels and their corresponding
media channels is established through the mid attribute defined in
RFC 3388[20]. If there are more than 1 audio m-line, then each audio
m-line MUST have a "mid" attribute. Each control m-line MUST have a
"cmid" attribute that matches the "mid" attribute of the audio m-
line it is associated with.
cmid-attribute = "a=cmid:" identification-tag
identification-tag = token
A single audio m-line can be associated with multiple resources or
each resource can have its own audio m-line. For example, if the
client wants to allocate a recognizer and a synthesizer and
associate them to a single 2-way audio pipe, the SDP offer should
contain two control m-lines and a single audio m-line with an
attribute of "sendrecv". Each of the control m-lines should have a
"cmid" attribute whose value matches the "mid" of the audio m-line.
If the client wants to allocate a recognizer and a synthesizer each
with its own separate audio pipe, the SDP offer would carry two
control m-lines (one for the recognizer and another for the
synthesizer) and two audio m-lines (one with the attribute
"sendonly" and another with attribute "recvonly"). The "cmid"
attribute of the recognizer control m-line would match the "mid"
value of the "sendonly" audio m-line and the "cmid" attribute of the
synthesizer control m-line would match the "mid" attribute of the
"recvonly" m-line.
When a server receives media(say audio) on a media pipe that is
associated with more than one media processing resource, it is the
responsibility of the server to receive and fork it to the resources
S Shanmugham IETF-Draft Page 15
MRCPv2 Protocol February, 2005
that need it. If the multiple resources in a session are generating
audio (or other media), that needs to be sent on a single associated
media pipe, it is the responsibility of the server to mix the
streams before sending on the media pipe. The media stream in either
direction may contain more than one Synchronized Source (SSRC)
identifier due to multiple sources contributing to the media on the
pipe and the client or server SHOULD be able to deal with it.
If a server does not have the capability to mix or fork media, in
the above cases, then the server SHOULD disallow the client from
associating multiple such resources to a single audio pipe, by
rejecting the SIP INVITE with a SIP 501 "Not Implemented" error.
4.4. MRCPv2 Message Transport
The MRCPv2 resource messages defined in this document are
transported over a TCP, TLS or SCTP(in the future) pipe between the
client and the server. The setting up of this transport pipe and the
resource control channel is discussed in Section 4.2. Multiple
resource control channels between a client and a server that belong
to different SIP sessions can share one or more TLS, TCP or SCTP
pipes between them and the server and client MUST support this
operation. The individual MRCPv2 messages carry the MRCPv2 channel
identifier in their Channel-Identifier header field, which MUST be
used to differentiate MRCPv2 messages from different resource
channels. All MRCPv2 servers MUST support TLS, SHOULD support TCP
and MAY support SCTP(in the future) and it is up to the client to
choose which mode of transport it wants to use for an MRCPv2
session.
Example 1:
C->S: MRCP/2.0 483 SPEAK 543257
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
S Shanmugham IETF-Draft Page 16
MRCPv2 Protocol February, 2005
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C: MRCP/2.0 81 543257 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
S->C: MRCP/2.0 89 SPEAK-COMPLETE 543257 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Most examples from here on show only the MRCPv2 messages and do not
show the SIP messages and headers that may have been used to
establish the MRCPv2 control channel.
5. MRCPv2 Specification
The MRCPv2 PDU is textual using an ISO 10646 character set in the
UTF-8 encoding (RFC 2044) to allow many different languages to be
represented. However, to assist in compact representations, MRCPv2
also allows other character sets such as ISO 8859-1 to be used when
desired. The MRCPv2 protocol headers(the first line of an MRCP
message) and field names use only the US-ASCII subset of UTF-8.
Internationalization only applies to certain fields like grammar,
results, speech markup etc, and not to MRCPv2 as a whole.
Lines are terminated by CRLF. Also, some parameters in the PDU may
contain binary data or a record spanning multiple lines. Such fields
have a length value associated with the parameter, which indicates
the number of octets immediately following the parameter.
All MRCPv2 messages, responses and events MUST carry the Channel-
Identifier header field in it, for the server or client to
differentiate messages from different control channels that may
share the same transport connection.
The MRCPv2 message set consists of requests from the client to the
server, responses from the server to the client and asynchronous
events from the server to the client. All these messages consist of
a start-line, one or more header fields (also known as "headers"),
an empty line (i.e. a line with nothing preceding the CRLF)
indicating the end of the header fields, and an optional message
body.
generic-message = start-line
message-header
CRLF
[ message-body ]
S Shanmugham IETF-Draft Page 17
MRCPv2 Protocol February, 2005
start-line = request-line / response-line / event-line
message-header = 1*(generic-header / resource-header)
resource-header = recognizer-header
/ synthesizer-header
/ recorder-header
/ verifier-header
The message-body contains resource-specific and message-specific
data that needs to be carried between the client and server as a
MIME entity. The information contained here and the actual MIME-
types used to carry the data are specified later when addressing the
specific messages.
If a message contains data in the message body, the header fields
will contain content-headers indicating the MIME-type and encoding
of the data in the message body.
5.1. Request
A MRCPv2 request consists of a Request line followed by message
headers and an optional message body containing data specific to the
request message.
The Request message from a client to the server includes within the
first line the method to be applied, a method tag for that request
and the version of protocol in use.
request-line = mrcp-version SP message-length SP method-name
SP request-id CRLF
The mrcp-version field is the MRCPv2 protocol version that is being
used by the client. Request, response and event messages include the
version of MRCP in use, and follow [H3.1] (with HTTP replaced by
MRCP, and HTTP/1.1 replaced by MRCP/2.0) regarding version ordering,
compliance requirements, and upgrading of version numbers. To be
compliant with this specification, applications sending MRCP
messages MUST include a mrcp-version of "MRCP/2.0".
mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT
The message-length field specifies the length of the message,
including the start-line, and MUST be the 2nd token from the
beginning of the message. This is to make the framing and parsing of
the message simpler to do.
message-length = 1*DIGIT
S Shanmugham IETF-Draft Page 18
MRCPv2 Protocol February, 2005
The request-id field is a unique identifier representable as a
unsigned 32 bit integer created by the client and sent to the
server. The initial value of the request-id is arbitrary.
Consecutive requests within a MRCP session MUST contain strictly
monotonically increasing and contiguous request-id's. The server
resource MUST use this identifier in its response to this request.
If the request does not complete with the response future
asynchronous events associated with this request MUST carry the
request-id.
request-id = 1*DIGIT
The method-name field identifies the specific request that the
client is making to the server. Each resource supports a certain
list of requests or methods that can be issued to it, and will be
addressed in later sections.
method-name = generic-method ; Section 6
/ synthesizer-method
/ recorder-method
/ recognizer-method
/ verifier-method
5.2. Response
After receiving and interpreting the request message, the server
resource responds with an MRCPv2 response message. It consists of a
response line followed by message headers and an optional message
body containing data specific to the response message.
response-line = mrcp-version SP message-length SP request-id
SP status-code SP request-state CRLF
The mrcp-version field used here MUST be the same as the one used in
the Request Line and specifies the version of the MRCPv2 protocol
running on the server.
The request-id used in the response MUST match the one sent in the
corresponding request message.
The status-code field is a 3-digit code representing the success or
failure or other status of the request.
The request-state field indicates if the job initiated by the
Request is PENDING, IN-PROGRESS or COMPLETE. The COMPLETE status
means that the Request was processed to completion and that there
are will be no more events from that resource to the client with
that request-id. The PENDING status means that the job has been
placed on a queue and will be processed in first-in-first-out order.
The IN-PROGRESS status means that the request is being processed and
S Shanmugham IETF-Draft Page 19
MRCPv2 Protocol February, 2005
is not yet complete. A PENDING or IN-PROGRESS status indicates that
further Event messages will be delivered with that request-id.
request-state = "COMPLETE"
/ "IN-PROGRESS"
/ "PENDING"
Status Codes
The status codes are classified under the Success (2XX) codes,
Client Failure(4XX) codes, Server Failure (5XX), and Reserved (9xx).
Success 2xx
200 Success
201 Success with some optional headers ignored.
Client Failure 4xx
401 Method not allowed
402 Method not valid in this state
403 Unsupported Header
404 Illegal Value for Header
405 Resource not allocated for this session or
doesn't exist
406 Mandatory Header Missing
407 Method or Operation Failed(e.g. Grammar compilation
failed in the recognizer. Detailed cause codes MAY BE
available through a resource specific header field.)
408 Unrecognized or unsupported message entity
409 Unsupported Header Value
421-499 Resource specific Failure codes
Server Failure 5xx
501 Server Internal Error
502 Protocol Version not supported
503 Proxy Timeout. The MRCP Proxy did not receive a
response from the MRCP server.
504 Message too large.
Reserved 9xx
900-999 Reserved for experimental use.
5.3. Event
The server resource may need to communicate a change in state or the
occurrence of a certain event to the client. These messages are used
when a request does not complete immediately and the response
S Shanmugham IETF-Draft Page 20
MRCPv2 Protocol February, 2005
returns a status of PENDING or IN-PROGRESS. The intermediate results
and events of the request are indicated to the client through the
event message from the server. The event message consists of an
event header line followed by message headers and an optional
message body containing data specific to the event message. The
header line has the request-id of the request that is in progress
and generating these events and status value. The status value is
COMPLETE if the request is done and this was the last event, else it
is IN-PROGRESS.
event-line = mrcp-version SP message-length SP event-name
SP request-id SP request-state CRLF
The mrcp-version used here is identical to the one used in the
Request/Response Line and indicates the version of MRCPv2 protocol
running on the server.
The request-id used in the event MUST match the one sent in the
request that caused this event.
The request-state indicates if the Request/Command causing this
event is complete or still in progress, and is the same as the one
mentioned in section 5.3. The final event will contain a COMPLETE
status indicating the completion of the request.
The event-name identifies the nature of the event generated by the
media resource. The set of valid event names are dependent on the
resource generating it, and will be addressed in later sections.
event-name = synthesizer-event
/ recognizer-event
/ recorder-event
/ verifier-event
6. MRCP Generic Features
The protocol supports a set of methods, and headers that are common
to all resources and are discussed in this section
generic-method = "SET-PARAMS"
/ "GET-PARAMS"
6.1. Generic Message Headers
MRCPv2 header fields, which include generic-header (section 6.1) and
resource-header (section 8.4 and section 9.4), follow the same
generic format as that given in Section 3.1 of RFC 822 [8]. Each
header field consists of a name followed by a colon (":") and the
field value. Field names are case-insensitive. The field value MAY
be preceded by any amount of LWS, though a single SP is preferred.
S Shanmugham IETF-Draft Page 21
MRCPv2 Protocol February, 2005
Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or HT.
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *LWS field-content *( CRLF 1*LWS field-content)
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message
downstream.
The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of
the message, by appending each subsequent field-value to the first,
each separated by a comma. The order in which header fields with the
same field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST
NOT change the order of these field values when a message is
forwarded.
generic-header = channel-identifier
/ active-request-id-list
/ proxy-sync-id
/ content-id
/ content-type
/ content-length
/ content-base
/ content-location
/ content-encoding
/ cache-control
/ logging-tag
/ set-cookie
/ set-cookie2
/ vendor-specific
S Shanmugham IETF-Draft Page 22
MRCPv2 Protocol February, 2005
Header field where s g A
__________________________________________________________
Channel-Identifier R m m m
Channel-Identifier r m m m
Active-Request-Id-List R - - o
Active-Request-Id-List r - - o
Proxy-Sync-Id R - - o
Content-Id R o o o
Content-Type R o o o
Content-Length R o o o
Content-Base R o o o
Content-Location R o o o
Content-Encoding R o o o
Cache-Control R o o o
Logging-Tag R o o -
Set-Cookie R o o o
Set-Cookie2 R o o o
Vendor-Specific R o o o
Legend: (s) - SET-PARAMS, (g) - GET-PARAMS, (A) - Generic MRCP
message, (o) - Optional to use, but mandatory to implement, (R) -
Request, (m) - Mandatory, (r) - Response. (For all optional header
fields please refer text for further constraints and usage)
All headers in MRCPv2 will be case insensitive consistent with HTTP
and SIP protocol header definitions.
Channel-Identifier
All MRCPv2 methods, responses and events MUST contain the Channel-
Identifier header field. The value of this field is a hexadecimal
string and is allocated by the server when the control channel was
added to the session through a SDP offer/answer exchange. This field
consists of 2 parts separated by the '@' symbol. The first part is a
32 bit hexadecimal integer that is positive, identifying the MRCP
session. The second part is a string token which specifies one of
the media processing resource types listed in Section 3.2. The
hexadecimal digit string MUST BE unique within the server and is
common to all resource channels established through a single SIP
session.
channel-identifier = "Channel-Identifier" ":" channel-id CRLF
Channel-id = 1*HEXDIG "@" 1*VCHAR
Active-Request-Id-List
In a request, this field indicates the list of request-ids that the
request should apply to. This is useful when there are multiple
S Shanmugham IETF-Draft Page 23
MRCPv2 Protocol February, 2005
Requests that are PENDING or IN-PROGRESS and you want this request
to apply to one or more of these specifically.
In a response, this field returns the list of request-ids that the
operation modified or affected. There could be one or more requests
that returned a request-state of PENDING or IN-PROGRESS. When a
method affecting one or more PENDING or IN-PROGRESS requests is sent
from the client to the server, the response MUST contain the list of
request-ids that were affected or modified by this command in its
header field.
The active-request-id-list is only used in requests and responses,
not in events.
For example, if a STOP request with no active-request-id-list is
sent to a synthesizer resource(a wildcard STOP) which has one or
more SPEAK requests in the PENDING or IN-PROGRESS state, all SPEAK
requests MUST be cancelled, including the one IN-PROGRESS and the
response to the STOP request would contain the request-id of all the
SPEAK requests that were terminated in the active-request-id-list.
In this case, no SPEAK-COMPLETE or RECOGNITION-COMPLETE events will
be sent for these terminated requests.
active-request-id-list = "Active-Request-Id-List" ":"
request-id *("," request-id) CRLF
Proxy-Sync-Id
When any server resource generates a barge-in-able event, it will
generate a unique Tag and send it as a header field in an event to
the client. The client then acts as a proxy to the server resource
and sends a BARGE-IN-OCCURRED method to the synthesizer server
resource with the Proxy-Sync-Id it received from the server
resource. When the recognizer and synthesizer resources are part of
the same session, they may choose to work together to achieve
quicker interaction and response. Here the proxy-sync-id helps the
resource receiving the event, proxied by the client, to decide if
this event has been processed through a direct interaction of the
resources.
proxy-sync-id = "Proxy-Sync-Id" ":" 1*VCHAR CRLF
Accept-Charset
See [H14.2]. This specifies the acceptable character set for
entities returned in the response or events associated with this
request. This is useful in specifying the character set to use in
the NLSML results of a RECOGNITION-COMPLETE event.
Content-Type
S Shanmugham IETF-Draft Page 24
MRCPv2 Protocol February, 2005
See [H14.17]. Note that the content types suitable for MRCPv2 are
restricted to speech markup, grammar, recognition results etc. and
are specified later in this document. The multi-part content type
"multi-part/mixed" is supported to communicate multiple of the above
mentioned contents, in which case the body parts cannot contain any
MRCPv2 specific headers.
Content-Id
This field contains an ID or name for the content, by which it can
be referred to. The definition of this field is in full compliance
with RFC 2392 [15] and is needed in multi-part messages. In MRCPv2
whenever the content needs to be stored, by either the client or the
server, it is stored associated with this ID. Such content can be
referenced during the session in URI form using the session: URI
scheme described in a later section.
Content-Base
The content-base entity-header field may be used to specify the base
URI for resolving relative URLs within the entity.
content-base = "Content-Base" ":" absoluteURI CRLF
Note, however, that the base URI of the contents within the entity-
body may be redefined within that entity-body. An example of this
would be a multi-part MIME entity, which in turn can have multiple
entities within it.
Content-Encoding
The content-encoding entity-header field is used as a modifier to
the media-type. When present, its value indicates what additional
content coding have been applied to the entity-body, and thus what
decoding mechanisms must be applied in order to obtain the media-
type referenced by the content-type header field. Content-encoding
is primarily used to allow a document to be compressed without
losing the identity of its underlying media type.
content-encoding = "Content-Encoding" ":"
*WSP content-coding
*(*WSP "," *WSP content-coding *WSP )
CRLF
Content coding is defined in [H3.5]. An example of its use is
Content-Encoding: gzip
If multiple encoding have been applied to an entity, the content
coding MUST be listed in the order in which they were applied.
S Shanmugham IETF-Draft Page 25
MRCPv2 Protocol February, 2005
Content-Location
The content-location entity-header field MAY BE used to supply the
resource location for the entity enclosed in the message when that
entity is accessible from a location separate from the requested
resource's URI. Refer [H14.14]
content-location = "Content-Location" ":"
( absoluteURI / relativeURI ) CRLF
The content-location value is a statement of the location of the
resource corresponding to this particular entity at the time of the
request. The server MAY use this header field to optimize certain
operations. When providing this header field the entity being sent
should not have been modified, from what was retrieved from the
content-location URI.
For example, if the client provided a grammar markup inline, and it
had previously retrieved it from a certain URI, that URI can be
provided as part of the entity, using the content-location header
field. This allows a resource like the recognizer to look into its
cache to see if this grammar was previously retrieved, compiled and
cached. In which case, it might optimize by using the previously
compiled grammar object.
If the content-location is a relative URI, the relative URI is
interpreted relative to the content-base URI.
Content-Length
This field contains the length of the content of the message body
(i.e. after the double CRLF following the last header field). Unlike
HTTP, it MUST be included in all messages that carry content beyond
the header portion of the message. If it is missing, a default value
of zero is assumed. It is interpreted according to [H14.13].
Cache-Control
If the server plans on implementing caching it MUST adhere to the
cache correctness rules of HTTP 1.1 (RFC2616), when accessing and
caching HTTP URI. In particular, the expires and cache-control
headers of the cached URI or document must be honored and will
always take precedence over the Cache-Control defaults set by this
header field. The cache-control directives are used to define the
default caching algorithms on the server for the session or request.
The scope of the directive is based on the method it is sent on. If
the directives are sent on a SET-PARAMS method, it MUST apply for
all requests for external documents the server makes during that
session. If the directives are sent on any other messages they MUST
only apply to external document requests the server makes for that
S Shanmugham IETF-Draft Page 26
MRCPv2 Protocol February, 2005
method. An empty cache-control header on the GET-PARAMS method is a
request for the server to return the current cache-control
directives setting on the server.
cache-control = "Cache-Control" ":" cache-directive
*("," *LWS cache-directive) CRLF
cache-directive = "max-age" "=" delta-seconds
/ "max-stale" [ "=" delta-seconds ]
/ "min-fresh" "=" delta-seconds
delta-seconds = 1*DIGIT
Here delta-seconds is a decimal time value to be specified as the
number of seconds from the time that the message response or data
was received by the server.
These directives allow the server to override the basic expiration
mechanism.
max-age
Indicates that the client is ok with the server using a response
whose age is no greater than the specified time in seconds. Unless a
max-stale directive is also included, the client is not willing to
accept the media server using a stale response.
min-fresh
Indicates that the client is willing to accept the server using a
response whose freshness lifetime is no less than its current age
plus the specified time in seconds. That is, the client wants the
server to use a response that will still be fresh for at least the
specified number of seconds.
max-stale
Indicates that the client is willing to accept the server using a
response or data that has exceeded its expiration time. If max-stale
is assigned a value, then the client is willing to accept the server
using a response that has exceeded its expiration time by no more
than the specified number of seconds. If no value is assigned to
max-stale, then the client is willing to accept the server using a
stale response of any age.
The server cache MAY BE requested to use stale response/data without
validation, but only if this does not conflict with any "MUST"-level
requirements concerning cache validation (e.g., a "must-revalidate"
cache-control directive) in the HTTP 1.1 specification pertaining
the URI.
S Shanmugham IETF-Draft Page 27
MRCPv2 Protocol February, 2005
If both the MRCPv2 cache-control directive and the cached entry on
the server include "max-age" directives, then the lesser of the two
values is used for determining the freshness of the cached entry for
that request.
Logging-Tag
This header field MAY BE sent as part of a SET-PARAMS/GET-PARAMS
method to set the logging tag for logs generated by the server. Once
set, the value persists until a new value is set or the session is
ended. The MRCPv2 server SHOULD provide a mechanism to subset its
output logs so that system administrators can examine or extract
only the log file portion during which the logging tag was set to a
certain value.
MRCPv2 clients using this feature SHOULD take care to ensure that no
two clients specify the same logging tag. In the event that two
clients specify the same logging tag, the effect on the MRCPv2
server's output logs in undefined.
logging-tag = "Logging-Tag" ":" 1*VCHAR CRLF
Set-Cookie and Set-Cookie2:
Since the HTTP client on the MRCP server fetches documents for
processing on behalf of the MRCP client, the cookie store in the
HTTP client of the MRCP server is considered to be an extension of
the cookie store in the HTTP client of the MRCP client. This
requires that the MRCP client and server be able to synchronize
their cookie stores as needed. The MRCP client should be able to
push its stored cookies to the MRCP server and get new cookies that
the MRCPv2 server stored back to the MRCP client. The set-cookie and
set-cookie2 entity-header fields MAY BE included in MRCPv2 requests
to update the cookie store on a server and be returned in final
MRCPv2 responses or events to subsequently update the client's own
cookie store. The stored cookies on the server persist for the
duration of the MRCPv2 session and MUST be destroyed at the end of
the session. Since the type of cookie header is dictated by the HTTP
origin server, MRCPv2 clients and servers SHOULD support both the
set-cookie and set-cookie2 entity header fields.
set-cookie = "Set-Cookie:" cookies CRLF
cookies = cookie *("," *LWS cookie)
cookie = attribute "=" value *(";" cookie-av)
cookie-av = "Comment" "=" value
/ "Domain" "=" value
/ "Max-Age" "=" value
/ "Path" "=" value
/ "Secure"
/ "Version" "=" 1*DIGIT
S Shanmugham IETF-Draft Page 28
MRCPv2 Protocol February, 2005
/ "Age" "=" delta-seconds
set-cookie2 = "Set-Cookie2:" cookies2 CRLF
cookies2 = cookie2 *("," *LWS cookie2)
cookie2 = attribute "=" value *(";" cookie-av2)
cookie-av2 = "Comment" "=" value
/ "CommentURL" "=" <"> http_URL <">
/ "Discard"
/ "Domain" "=" value
/ "Max-Age" "=" value
/ "Path" "=" value
/ "Port" [ "=" <"> portlist <"> ]
/ "Secure"
/ "Version" "=" 1*DIGIT
/ "Age" "=" delta-seconds
portlist = portnum *("," *LWS portnum)
portnum = 1*DIGIT
The set-cookie and set-cookie2 header fields are specified in RFC
2109 and RFC 2965 respectively. The "Age" attribute is introduced in
this specification to indicate the age of the cookie and is
OPTIONAL. An MRCPv2 client or server SHOULD calculate the age of the
cookie according to the age calculation rules in the HTTP/1.1
specification (RFC 2616) and append the "Age" attribute accordingly.
The media client or server MUST supply defaults for the Domain and
Path attributes if omitted by the HTTP origin server as specified in
RFC 2109 (set-cookie) and RFC 2965 (set-cookie2). Note that there
will be no leading dot present in the Domain attribute value in this
case. Although an explicitly specified Domain value received via the
HTTP protocol may be modified to include a leading dot, a media
client or server MUST NOT modify the Domain value when received via
the MRCPv2 protocol.
A media client or server MAY combine multiple cookie header fields
of the same type into a single "field-name: field-value" pair as
described in Section 6.1.
The set-cookie and set-cookie2 headers MAY BE specified in any
request that subsequently results in the server performing an HTTP
access. When a server receives new cookie information from an HTTP
origin server, and assuming the cookie store is modified according
to RFC 2109 or RFC2965, the server MUST return the new cookie
information in the MRCPv2 COMPLETE response or event as appropriate
to allow the client to update its own cookie store.
The SET-PARAMS request MAY specify the set-cookie and set-cookie2
headers to update the cookie store on a server. The GET-PARAMs
request MAY BE used to return the entire cookie store of "Set-
Cookie" or "Set-Cookie2" type cookies to the client.
S Shanmugham IETF-Draft Page 29
MRCPv2 Protocol February, 2005
Vendor Specific Parameters
This set of headers allows for the client to set Vendor Specific
parameters.
vendor-specific = "Vendor-Specific-Parameters" ":"
vendor-specific-av-pair
*[";" vendor-specific-av-pair] CRLF
vendor-specific-av-pair = vendor-av-pair-name "="
vendor-av-pair-value
This header MAY BE sent in the SET-PARAMS/GET-PARAMS method and is
used to set vendor-specific parameters on the server side. The
vendor-av-pair-name follows the reverse Internet Domain Name
convention (see section 13 for syntax and registration information).
The vendor-av-pair-value is the value to set the attribute to and
needs to be quoted.
Example:
com.cisco.paramxyz:256
com.cisco.paramabc:High
com.nuance.paramxyz:Low
When asking the server to get the current value of these parameters,
this header can be sent in the GET-PARAMS method with the list of
vendor-specific attribute names to get separated by a semicolon.
6.2. SET-PARAMS
The SET-PARAMS method, from the client to server, tells the MRCP
resource to define session parameters, like voice characteristics
and prosody on synthesizers or recognition timers on recognizers
etc. If the server accepted and set all parameters it MUST return a
Response-Status of 200. If it chose to ignore some optional headers
that can be safely ignored with affecting operation of the server it
MUST return 201.
If some of the headers being set are unsupported for the resource or
have illegal values, the server MUST reject the request with a 403,
Bad Parameter, and MUST include in the response the header fields
that could not be set. The header specified in SET-PARAMS affect the
session level values. They do not apply for request level scope and
for request that are in-PROGRESS.
Example:
C->S:MRCP/2.0 124 SET-PARAMS 543256
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: female
Voice-category: adult
Voice-variant: 3
S Shanmugham IETF-Draft Page 30
MRCPv2 Protocol February, 2005
S->C:MRCP/2.0 47 543256 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
6.3. GET-PARAMS
The GET-PARAMS method, from the client to server, asks the MRCPv2
resource for its current session parameters, like voice
characteristics and prosody on synthesizers and recognition-timer on
recognizers etc. The client SHOULD send the list of parameters it
wants to read from the server by listing a set of empty header
fields. If a specific list is not specified then the server SHOULD
return all the settable headers including vendor-specific parameters
and their current values. The wild card use can be very intensive as
the number of settable parameters can be large depending on the
vendor. Hence it is RECOMMENDED that the client does not use the
wildcard GET-PARAMS operation very often. Note that the GET-PARAMS
returns header values that have been set for the whol session and do
not return values that have a request level scope.
Example:
C->S:MRCP/2.0 136 GET-PARAMS 543256
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender:
Voice-category:
Voice-variant:
Vendor-Specific-Parameters:com.mycorp.param1;
com.mycorp.param2
S->C:MRCP/2.0 163 543256 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender:female
Voice-category: adult
Voice-variant: 3
Vendor-Specific-Parameters:com.mycorp.param1="Company Name";
com.mycorp.param2="124324234@mycorp.com"
7. Resource Discovery
The list and capability of media resources on a server can be found
using the SIP OPTIONS method requesting the capability of the
server. The server SHOULD respond to such a request with an SDP
description of its capabilities according to RFC 3264. The MRCPv2
capabilities are described by a single m-line containing the media
type "application", transport type "TCP/TLS/MRCPv2", "TCP/MRCPv2".
There should be one "resource" attribute for each media resource
that the server supports with the resource type identifier as its
value.
S Shanmugham IETF-Draft Page 31
MRCPv2 Protocol February, 2005
The SDP description MUST also contain m-lines describing the audio
capabilities, and the coders it supports.
Example 4:
The client uses the SIP OPTIONS method to query the capabilities of
the MRCPv2 server.
C->S:
OPTIONS sip:mrcp@mediaserver.com SIP/2.0
Max-Forwards: 6
To: <sip:mrcp@mediaserver.com>
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:sarvi@cisco.com>
Accept: application/sdp
Content-Length: 0
S->C:
SIP/2.0 200 OK
To: <sip:mrcp@mediaserver.com>;tag=93810874
From: Sarvi <sip:sarvi@Cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:mrcp@mediaserver.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 274
v=0
o=sarvi 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A session for processing media
c=IN IP4 224.2.17.12/127
m=application 9 TCP/MRCPv2
a=resource:speechsynth
a=resource:speechrecog
a=resource:speakverify
m=audio 0 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
S Shanmugham IETF-Draft Page 32
MRCPv2 Protocol February, 2005
8. Speech Synthesizer Resource
This resource is capable of converting text provided by the client
and generating a speech stream in real-time. Depending on the
implementation and capability of this resource, the client can
control parameters like voice characteristics, speaker speed, etc.
The synthesizer resource is controlled by MRCPv2 requests from the
client. Similarly the resource can respond to these requests or
generate asynchronous events to the server to indicate certain
conditions during the processing of the stream.
This section applies for the following resource types.
1. speechsynth
2. basicsynth
The capability of these resources are addressed in Section 4.5.
8.1. Synthesizer State Machine
The synthesizer maintains states to correlate MRCPv2 requests from
the client. The state transitions shown below describe the states of
the synthesizer and reflect the request at the head of the queue. A
SPEAK request in the PENDING state can be deleted or stopped by a
STOP request and does not affect the state of the resource.
Idle Speaking Paused
State State State
| | |
|----------SPEAK------->| |--------|
|<------STOP------------| CONTROL |
|<----SPEAK-COMPLETE----| |------->|
|<----BARGE-IN-OCCURRED-| |
| |--------| |
| CONTROL |-----------PAUSE--------->|
| |------->|<----------RESUME---------|
| | |----------|
| | PAUSE |
| | |--------->|
| |----------| |
| | SPEECH-MARKER |
| |<---------| |
|----------| | |------------|
| STOP | SPEAK |
| | | |----------->|
|<---------| | |
|<--------------------STOP-------------------------|
|----------| | |
| LOAD-LEXICON | |
S Shanmugham IETF-Draft Page 33
MRCPv2 Protocol February, 2005
| | | |
|<---------| | |
|<--------------------BARGE-IN-OCCURRED------------|
8.2. Synthesizer Methods
The synthesizer supports the following methods.
synthesizer-method = "SPEAK" ; A
/ "STOP" ; B
/ "PAUSE" ; C
/ "RESUME" ; D
/ "BARGE-IN-OCCURRED" ; E
/ "CONTROL" ; F
/ "LOAD-LEXICON" ; G
8.3. Synthesizer Events
The synthesizer may generate the following events.
synthesizer-event = "SPEECH-MARKER" ; H
/ "SPEAK-COMPLETE" ; I
8.4. Synthesizer Header Fields
A synthesizer message may contain header fields containing request
options and information to augment the Request, Response or Event
the message it is associated with.
synthesizer-header = jump-size
/ kill-on-barge-in
/ speaker-profile
/ completion-cause
/ completion-reason
/ voice-parameter
/ prosody-parameter
/ speech-marker
/ speech-language
/ fetch-hint
/ audio-fetch-hint
/ fetch-timeout
/ failed-uri
/ failed-uri-cause
/ speak-restart
/ speak-length
/ load-lexicon
/ lexicon-search-order
Header field where s g A B C D E F G H I
__________________________________________________________
Jump-Size R - - - - - - - o - - -
S Shanmugham IETF-Draft Page 34
MRCPv2 Protocol February, 2005
Kill-On-Barge-In R - - o - - - - - - - -
Speaker-Profile R o o o - - - - o - - -
Completion-Cause R - - - - - - - - - - m
Completion-Cause 4XX - - o - - - - - - - -
Completion-Reason R - - - - - - - - - - m
Completion-Reason 4XX - - o - - - - - - - -
Voice-Parameter R o o o - - - - o - - -
Prosody-Parameter R o o o - - - - o - - -
Speech-Marker R - - - - - - - - - m m
Speech-Marker 2XX - - m m m m - m - - -
Speech-Language R o o o - - - - - - - -
Fetch-Hint R o o o - - - - - - - -
Audio-Fetch-Hint R o o o - - - - - - - -
Fetch-Timeout R o o o - - - - - - - -
Failed-URI R - - - - - - - - - - o
Failed-URI 4XX - o - - - - - - - - o
Failed-URI-Cause R - - - - - - - - - - o
Failed-URI-Cause 4XX - o - - - - - - - - o
Speak-Restart 2XX - - - - - - - o - - -
Speak-Length R - o - - - - - o - - -
Load-Lexicon R - - - - - - - - o - -
Lexicon-Search-Order R - - - - - - - - m - -
Legend: (s) - SET-PARAMS, (g) - GET-PARAMS, (A) - SPEAK, (B) -
STOP, (C) - PAUSE, (D) RESUME, (E) - BARGE-IN-OCCURRED, (F) -
CONTROL, (G) - LOAD-LEXICON (o) - Optional(Refer text for further
constraints), (m) - Mandatory, (R) - Request, (r) - Response
Jump-Size
This header MAY BE specified in a CONTROL method and controls the
jump size to move forward or rewind backward on an active SPEAK
request. A + or - indicates a relative value to what is being
currently played. This MAY BE specified in a SPEAK request to
indicate an offset into the speech markup that the SPEAK request
should start speaking from. The different speech length units
supported are dependent on the synthesizer implementation. If it
does not support a unit or the operation the resource SHOULD respond
with a status code of 404 "Illegal or Unsupported value for
parameter".
jump-size = "Jump-Size" ":" speech-length-value CRLF
speech-length-value = numeric-speech-length
/ text-speech-length
text-speech-length = 1*VCHAR SP "Tag"
numeric-speech-length= ("+" / "-") 1*DIGIT SP
numeric-speech-unit
numeric-speech-unit = "Second"
/ "Word"
/ "Sentence"
S Shanmugham IETF-Draft Page 35
MRCPv2 Protocol February, 2005
/ "Paragraph"
Kill-On-Barge-In
This header MAY BE sent as part of the SPEAK method to enable kill-
on-barge-in support. If enabled, the SPEAK method is interrupted by
DTMF input detected by a signal detector resource or by the start of
speech sensed or recognized by the speech recognizer resource.
kill-on-barge-in = "Kill-On-Barge-In" ":" boolean-value CRLF
boolean-value = "true" / "false"
If the recognizer or signal detector resource is on the same server
as the synthesizer, the server SHOULD recognize their interactions
by their common MRCPv2 channel identifier (ignoring the portion
after "@" which is the resource type) and work with each other to
provide kill-on-barge-in support.
The client MUST send a BARGE-IN-OCCURRED method to the synthesizer
resource when it receives a bargin-in-able event from any source.
This source could be a synthesizer resource or signal detector
resource and MAY BE local or distributed. If this field is not
specified, the value defaults to "true".
Speaker Profile
This header MAY BE part of the SET-PARAMS/GET-PARAMS or SPEAK
request from the client to the server and specifies the profile of
the speaker by a uri, which may be a set of voice parameters like
gender, accent etc.
speaker-profile = "Speaker-Profile" ":" uri CRLF
Completion Cause
This header field MUST be specified in a SPEAK-COMPLETE event coming
from the synthesizer resource to the client. This indicates the
reason behind the SPEAK request completion.
completion-cause = "Completion-Cause" ":" 1*DIGIT SP
1*VCHAR CRLF
Cause-Code Cause-Name Description
000 normal SPEAK completed normally.
001 barge-in SPEAK request was terminated because
of barge-in.
002 parse-failure SPEAK request terminated because of a
failure to parse the speech markup text.
003 uri-failure SPEAK request terminated because, access
to one of the URIs failed.
004 error SPEAK request terminated prematurely due
S Shanmugham IETF-Draft Page 36
MRCPv2 Protocol February, 2005
to synthesizer error.
005 language-unsupported
Language not supported.
006 lexicon-load-failure
Lexicon loading failed.
Completion Reason
This header field MAY be specified in a SPEAK-COMPLETE event coming
from the synthesizer resource to the client. This contains the
reason text behind the SPEAK request completion. This field can be
use to communicate text describing the reason for the failure, such
as an error in parsing the speech markup text.
completion-reason = "Completion-Reason" ":"
quoted-string CRLF
Voice-Parameters
This set of headers defines the voice of the speaker.
voice-parameter = "Voice-" voice-param-name ":"
voice-param-value CRLF
voice-param-name is any one of the attribute names under the voice
element specified in W3C's Speech Synthesis Markup Language
Specification[10]. The voice-param-value is any one of the value
choices of the corresponding voice element attribute specified in
the above section.
These header fields MAY BE sent in SET-PARAMS/GET-PARAMS request to
define/get default values for the entire session or MAY BE sent in
the SPEAK request to define default values for that speak request.
Furthermore these attributes can be part of the speech text marked
up in SML.
These voice parameter header fields can also be sent in a CONTROL
method to affect a SPEAK request in progress and change its behavior
on the fly. If the synthesizer resource does not support this
operation, it should respond back to the client with a status of
unsupported.
Prosody-Parameters
This set of headers defines the prosody of the speech.
prosody-parameter = "Prosody-" prosody-param-name ":"
prosody-param-value CRLF
S Shanmugham IETF-Draft Page 37
MRCPv2 Protocol February, 2005
prosody-param-name is any one of the attribute names under the
prosody element specified in W3C's Speech Synthesis Markup Language
Specification[10]. The prosody-param-value is any one of the value
choices of the corresponding prosody element attribute specified in
the above section.
These header fields MAY BE sent in SET-PARAMS/GET-PARAMS request to
define/get default values for the entire session or MAY BE sent in
the SPEAK request to define default values for that speak request.
Further more these attributes can be part of the speech text marked
up in SML.
The prosody parameter header fields in the SET-PARAMS or SPEAK
request only apply if the speech data is of type text/plain and does
not use a speech markup format.
These prosody parameter header fields MAY also be sent in a CONTROL
method to affect a SPEAK request in progress and change its behavior
on the fly. If the synthesizer resource does not support this
operation, it should respond back to the client with a status of
unsupported.
Speech Marker
This header field contains a marker tag that may be embedded in the
speech data. Most speech markup formats provide mechanisms to embed
marker fields between speech texts. The synthesizer will generate
SPEECH-MARKER events when it reaches these marker fields. This field
SHOULD be part of the SPEECH-MARKER event and will contain the
marker tag values. This header may have additional timestamp
information in a "timestamp" field separated by a semicolon. This is
the NTP timestamp and MUST be synced with the RTP timestamp. This
header field SHOULD also be returned in responses to STOP and
CONTROL methods and in the SPEAK-COMPLETE event. In these messages
the marker tag SHOULD be the last tag encountered and would be "" if
none was encountered. The marker tag SHOULD have timestamp
information which reflects at what point into the current SPEAK
request the particular message was generated.
timestamp = "timestamp" "=" time-stamp-value CRLF
speech-marker = "Speech-Marker" ":" 1*VCHAR
[";" timestamp ]CRLF
Speech Language
This header field specifies the default language of the speech data
if it is not specified in it. The value of this header field should
follow RFC 3066 for its values. This MAY occur in SPEAK, SET-PARAMS
or GET-PARAMS requests.
S Shanmugham IETF-Draft Page 38
MRCPv2 Protocol February, 2005
speech-language = "Speech-Language" ":" 1*VCHAR CRLF
Fetch Hint
When the synthesizer needs to fetch documents or other resources
like speech markup or audio files, etc., this header field controls
URI access properties. This defines when the synthesizer should
retrieve content from the server. A value of "prefetch" indicates a
file may be downloaded when the request is received, whereas "safe"
indicates a file that should only be downloaded when actually
needed. The default value is "prefetch". This header field MAY occur
in SPEAK, SET-PARAMS or GET-PARAMS requests.
fetch-hint = "Fetch-Hint" ":" 1*ALPHA CRLF
Audio Fetch Hint
When the synthesizer needs to fetch documents or other resources
like speech audio files, etc., this header field controls URI access
properties. This defines whether or not the synthesizer can attempt
to optimize speech by pre-fetching audio. The value is either "safe"
to say that audio is only fetched when it is needed, never before;
"prefetch" to permit, but not require the platform to pre-fetch the
audio; or "stream" to allow it to stream the audio fetches. The
default value is "prefetch". This header field MAY occur in SPEAK,
SET-PARAMS or GET-PARAMS. requests.
audio-fetch-hint = "Audio-Fetch-Hint" ":" 1*ALPHA CRLF
Fetch Timeout
When the synthesizer needs to fetch documents or other resources
like speech audio files, etc., this header field controls URI access
properties. This defines the synthesizer timeout for content the
server may need to fetch from the network. This is specified in
milliseconds. The default value is platform-dependent. This header
field MAY occur in SPEAK, SET-PARAMS or GET-PARAMS.
fetch-timeout = "Fetch-Timeout" ":" 1*DIGIT CRLF
Failed URI
When a synthesizer method needs a synthesizer to fetch or access a
URI and the access fails the server SHOULD provide the failed URI in
this header field in the method response.
failed-uri = "Failed-URI" ":" Uri CRLF
Failed URI Cause
S Shanmugham IETF-Draft Page 39
MRCPv2 Protocol February, 2005
When a synthesizer method needs a synthesizer to fetch or access a
URI and the access fails the server SHOULD provide the URI specific
or protocol specific response code through this header field in the
method response. This field has been defined as alphanumeric to
accommodate all protocols, some of which might have a response
string instead of a numeric response code.
failed-uri-cause = "Failed-URI-Cause" ":" 1*alphanum CRLF
Speak Restart
When a CONTROL request to jump backward is issued to a currently
speaking synthesizer resource and the target jump point is beyond
the start of the current SPEAK request, the current SPEAK request
SHALL re-start from the beginning of its speech data and the
response to the CONTROL request SHOULD contain this header
indicating a restart. This header MAY occur in the CONTROL response.
speak-restart = "Speak-Restart" ":" boolean-value CRLF
Speak Length
This header MAY be specified in a CONTROL method to control the
length of speech to speak, relative to the current speaking point in
the currently active SPEAK request. A - value is illegal in this
field. If a field with a Tag unit is specified, then the media must
speak till the tag is reached or the SPEAK request complete,
whichever comes first. This MAY BE specified in a SPEAK request to
indicate the length to speak in the speech data and is relative to
the point in speech the SPEAK request starts. The different speech
length units supported are dependent on the synthesizer
implementation. If it does not support a unit or the operation the
resource SHOULD respond with a status code of 404 "Illegal or
Unsupported value for header".
speak-length = "Speak-Length" ":" speech-length-value
CRLF
speech-length-value = numeric-speech-length
/ text-speech-length
text-speech-length = 1*VCHAR SP "Tag"
numeric-speech-length= ("+" / "-") 1*DIGIT SP
numeric-speech-unit
numeric-speech-unit = "Second"
/ "Word"
/ "Sentence"
/ "Paragraph"
Load-Lexicon
This header field is used to indicate whether a lexicon has to be
loaded or unloaded. The default value for this field is "true".
S Shanmugham IETF-Draft Page 40
MRCPv2 Protocol February, 2005
load-lexicon = "Load-Lexicon" : Boolean-value CRLF
Lexicon-Search-Order
This header field is used to specify the list of active Lexicon URIs
and the search order among the active lexicons. Note, the lexicons
specified within the SSML document still takes precedence over the
lexicons specified here.
Lexicon-search-order = "Lexicon-Search-Order" : uri-list CRLF
8.5. Synthesizer Message Body
A synthesizer message may contain additional information associated
with the Method, Response or Event in its message body.
Synthesizer Speech Data
Marked-up text for the synthesizer to speak is specified as a MIME
entity in the message body. The message to be spoken by the
synthesizer can be specified inline by embedding the data in the
message body or by reference by providing the URI to the data. In
either case the data and the format used to markup the speech needs
to be supported by the server.
All MRCPv2 servers MUST support plain text speech data and W3C's
Speech Synthesis Markup Language[10] as a minimum and hence MUST
support the MIME types text/plain and application/ssml+xml at a
minimum.
If the speech data needs to be specified by URI reference the MIME
type text/uri-list is used to specify the one or more URI that will
list what needs to be spoken. If a list of speech URI is specified,
speech data provided by each URI must be spoken in the order in
which the URI are specified.
If the data to be spoken consists of a mix of URI and inline speech
data the multipart/mixed MIME-type is used and embedded with the
MIME-blocks for text/uri-list, application/ssml+xml or text/plain.
The character set and encoding used in the speech data may be
specified according to standard MIME-type definitions. The multi-
part MIME-block can contain actual audio data in .wav or sun audio
format. This is used when the client has audio clips that it may
have recorded and has it stored in memory or a local device and it
needs to play it as part of the SPEAK request. The audio MIME-parts,
can be sent by the client as part of the multi-part MIME-block. This
audio will be referenced in the speech markup data that will be
S Shanmugham IETF-Draft Page 41
MRCPv2 Protocol February, 2005
another part in the multi-part MIME-block according to the
multipart/mixed MIME-type specification.
Example 1:
Content-Type: text/uri-list
Content-Length: 176
http://www.example.com/ASR-Introduction.ssml
http://www.example.com/ASR-Document-Part1.ssml
http://www.example.com/ASR-Document-Part2.ssml
http://www.example.com/ASR-Conclusion.ssml
Example 2:
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
Example 3:
Content-Type: multipart/mixed; boundary="break"
--break
Content-Type: text/uri-list
Content-Length: 176
http://www.example.com/ASR-Introduction.ssml
http://www.example.com/ASR-Document-Part1.ssml
http://www.example.com/ASR-Document-Part2.ssml
http://www.example.com/ASR-Conclusion.ssml
--break
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
S Shanmugham IETF-Draft Page 42
MRCPv2 Protocol February, 2005
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
--break--
Lexicon Data
Synthesizer lexicon data from the client to the server can be
provided inline or by reference. Either way they are carried as MIME
entities in the message body of the MRCPv2 request message.
When a lexicon is specified in-line in the message, the client MUST
provide a content-id for that lexicon as part of the content
headers. The server MUST store the lexicon associated with that
content-id for the duration of the session. A stored lexicon can be
overwritten by defining a new lexicon with the same content-id.
Lexicons that have been associated with a content-id can be
referenced through a special "session:" URI scheme.
If lexicon data needs to be specified by external URI reference, the
MIME-type text/uri-list is used to list the one or more URI that
will specify the lexicon data. All media servers MUST support the
HTTP uri access mechanism.
If the data to be defined consists of a mix of URI and inline
lexicon data the multipart/mixed MIME-type is used. The character
set and encoding used in the lexicon data may be specified according
to standard MIME-type definitions.
8.6. SPEAK
The SPEAK method from the client to the server provides the
synthesizer resource with the speech text and initiates speech
synthesis and streaming. The SPEAK method can carry voice and
prosody header fields that define the behavior of the voice being
synthesized, as well as the actual marked-up text to be spoken. If
specific voice and prosody parameters are specified as part of the
S Shanmugham IETF-Draft Page 43
MRCPv2 Protocol February, 2005
speech markup text, it will take precedence over the values
specified in the header fields and those set using a previous SET-
PARAMS request.
When applying voice parameters there are 3 levels of scope. The
highest precedence are those specified within the speech markup
text, followed by those specified in the header fields of the SPEAK
request and hence apply for that SPEAK request only, followed by the
session default values which can be set using the SET-PARAMS request
and apply for the whole session moving forward.
If the resource is idle and the SPEAK request is being actively
processed the resource will respond with a success status code and a
request-state of IN-PROGRESS.
If the resource is in the speaking or paused states, i.e. it is in
the middle of processing a previous SPEAK request, the status
returns success and a request-state of PENDING. This means that this
SPEAK request will be placed in the request queue and will be
processed in the other order received after the currently active
SPEAK request and previously queued SPEAK requests are completed.
For the synthesizer resource, this is the only request that can
return a request-state of IN-PROGRESS or PENDING.
When the text to be synthesized is complete, the resource will issue
a SPEAK-COMPLETE event with the request-id of the SPEAK message and
a request-state of COMPLETE.
Example:
C->S:MRCP/2.0 489 SPEAK 543257
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
S Shanmugham IETF-Draft Page 44
MRCPv2 Protocol February, 2005
</p>
</speak>
S->C:MRCP/2.0 28 543257 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
S->C:MRCP/2.0 79 SPEAK-COMPLETE 543257 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Completion-Cause: 000 normal
8.7. STOP
The STOP method from the client to the server tells the resource to
stop speaking if it is speaking something.
The STOP request can be sent with an active-request-id-list header
field to stop the zero or more specific SPEAK requests that may be
in queue and return a response code of 200(Success). If no active-
request-id-list header field is sent in the STOP request it will
terminate all outstanding SPEAK requests.
If a STOP request successfully terminated one or more PENDING or IN-
PROGRESS SPEAK requests, then the response message body contains an
active-request-id-list header field listing the SPEAK request-ids
that were terminated. Otherwise there will be no active-request-id-
list header field in the response. No SPEAK-COMPLETE events will be
sent for these terminated requests.
If a SPEAK request that was IN-PROGRESS and speaking was stopped the
next pending SPEAK request, if any, would become IN-PROGRESS and
move to the speaking state.
If a SPEAK request that was IN-PROGRESS and in the paused state was
stopped the next pending SPEAK request, if any, would become IN-
PROGRESS and move to the paused state.
Example:
C->S:MRCP/2.0 423 SPEAK 543258
Channel-Identifier: 32AECB23433802@speechsynth
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
S Shanmugham IETF-Draft Page 45
MRCPv2 Protocol February, 2005
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C:MRCP/2.0 48 543258 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
C->S:MRCP/2.0 44 STOP 543259 200
Channel-Identifier: 32AECB23433802@speechsynth
S->C:MRCP/2.0 66 543259 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Active-Request-Id-List: 543258
8.8. BARGE-IN-OCCURRED
The BARGE-IN-OCCURRED method is a mechanism for the client to
communicate a barge-in-able event it detects to the speech resource.
This event is useful in two scenarios,
1. The client has detected some events like DTMF digits or other
barge-in-able events and wants to communicate that to the
synthesizer.
2. The recognizer resource and the synthesizer resource are in
different servers. In which case the client MUST act as a proxy and
receive event from the recognition resource, and then send a BARGE-
IN-OCCURRED method to the synthesizer. In such cases, the BARGE-IN-
OCCURRED method would also have a proxy-sync-id header field
received from the resource generating the original event.
If a SPEAK request is active with kill-on-barge-in enabled, and the
BARGE-IN-OCCURRED event is received, the synthesizer should stop
streaming out audio. It should also terminate any speech requests
queued behind the current active one, irrespective of whether they
have barge-in enabled or not. If a barge-in-able prompt was playing
and it was terminated, the response MUST contain the request-ids of
all SPEAK requests that were terminated in its active-request-id-
list. There will be no SPEAK-COMPLETE events generated for these
requests.
S Shanmugham IETF-Draft Page 46
MRCPv2 Protocol February, 2005
If the synthesizer and the recognizer are part of the same session
they could be optimized for a quicker kill-on-barge-in response by
the recognizer and synthesizer interacting directly. In these cases,
the client MUST still proxy the START-OF-SPEECH event through a
BARGE-IN-OCCURRED method, but the synthesizer resource may have
already stopped and sent a SPEAK-COMPLETE event with a barge in
completion cause code. If there were no SPEAK requests terminated
as a result of the BARGE-IN-OCCURRED method, the response would
still be a 200 success but MUST NOT contain an active-request-id-
list header field.
C->S:MRCP/2.0 433 SPEAK 543258
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C:MRCP/2.0 47 543258 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
C->S:MRCP/2.0 69 BARGE-IN-OCCURRED 543259 200
Channel-Identifier: 32AECB23433802@speechsynth
Proxy-Sync-Id: 987654321
S->C:MRCP/2.0 72 543259 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Active-Request-Id-List: 543258
8.9. PAUSE
S Shanmugham IETF-Draft Page 47
MRCPv2 Protocol February, 2005
The PAUSE method from the client to the server tells the resource to
pause speech, if it is speaking something. If a PAUSE method is
issued on a session when a SPEAK is not active the server SHOULD
respond with a status of 402 or "Method not valid in this state". If
a PAUSE method is issued on a session when a SPEAK is active and
paused the server SHOULD respond with a status of 200 or "Success".
If a SPEAK request was active the server MUST return an active-
request-id-list header with the request-id of the SPEAK request that
was paused.
C->S:MRCP/2.0 434 SPEAK 543258
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C:MRCP/2.0 48 543258 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
C->S:MRCP/2.0 43 PAUSE 543259
Channel-Identifier: 32AECB23433802@speechsynth
S->C:MRCP/2.0 68 543259 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Active-Request-Id-List: 543258
8.10. RESUME
The RESUME method from the client to the server tells a paused
synthesizer resource to continue speaking. If a RESUME method is
issued on a session with no active SPEAK request, the server SHOULD
S Shanmugham IETF-Draft Page 48
MRCPv2 Protocol February, 2005
respond with a status of 402 or "Method not valid in this state". If
a RESUME method is issued on a session with an active SPEAK request
is speaking(i.e. not paused) the server SHOULD respond with a status
of 200 or "Success". If a SPEAK request was active the server MUST
return an active-request-id-list header with the request-id of the
SPEAK request that was resumed
Example:
C->S:MRCP/2.0 434 SPEAK 543258
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C:MRCP/2.0 48 543258 200 IN-PROGRESS@speechsynth
Channel-Identifier: 32AECB23433802
C->S:MRCP/2.0 44 PAUSE 543259
Channel-Identifier: 32AECB23433802@speechsynth
S->C:MRCP/2.0 47 543259 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Active-Request-Id-List: 543258
C->S:MRCP/2.0 44 RESUME 543260
Channel-Identifier: 32AECB23433802@speechsynth
S->C:MRCP/2.0 66 543260 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Active-Request-Id-List: 543258
S Shanmugham IETF-Draft Page 49
MRCPv2 Protocol February, 2005
8.11. CONTROL
The CONTROL method from the client to the server tells a synthesizer
that is speaking to modify what it is speaking on the fly. This
method is used to make the synthesizer jump forward or backward in
what it is speaking, change speaker rate, and speaker parameters,
etc. It affects the active or IN-PROGRESS SPEAK request. Depending
on the implementation and capability of the synthesizer resource it
may allow this operation or one or more of its headers.
When a CONTROL to jump forward is issued and the operation goes
beyond the end of the active SPEAK method's text, the CONTROL
request succeeds. Also, the active SPEAK request completes and
returns a SPEAK-COMPLETE event following the response to the CONTROL
method. If there are more SPEAK requests in the queue, the
synthesizer resource will start at the beginning of the next SPEAK
request in the queue.
When a CONTROL to jump backwards is issued and the operation jumps
to the beginning or beyond the beginning of the speech data of the
active SPEAK request, the response to the CONTROL request contains
the speak-restart header, and the active SPEAK request starts from
the beginning of its speech data.
These two behaviors can be used to rewind or fast-forward across
multiple speech requests, if the client wants to break up a speech
markup text to multiple SPEAK requests.
If a SPEAK request was active when the CONTROL method was received
the server MUST return an active-request-id-list header with the
Request-id of the SPEAK request that was active.
Example:
C->S:MRCP/2.0 434 SPEAK 543258
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
S Shanmugham IETF-Draft Page 50
MRCPv2 Protocol February, 2005
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C:MRCP/2.0 47 543258 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
C->S:MRCP/2.0 63 CONTROL 543259
Channel-Identifier: 32AECB23433802@speechsynth
Prosody-rate: fast
S->C:MRCP/2.0 67 543259 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Active-Request-Id-List: 543258
C->S:MRCP/2.0 68 CONTROL 543260
Channel-Identifier: 32AECB23433802@speechsynth
Jump-Size: -15 Words
S->C:MRCP/2.0 69 543260 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Active-Request-Id-List: 543258
8.12. SPEAK-COMPLETE
This is an Event message from the synthesizer resource to the client
indicating that the SPEAK request was completed. The request-id
header field WILL match the request-id of the SPEAK request that
initiated the speech that just completed. The request-state field
should be COMPLETE indicating that this is the last Event with that
request-id, and that the request with that request-id is now
complete. The completion-cause header field specifies the cause code
pertaining to the status and reason of request completion such as
the SPEAK completed normally or because of an error or kill-on-
barge-in etc.
Example:
C->S:MRCP/2.0 434 SPEAK 543260
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
S Shanmugham IETF-Draft Page 51
MRCPv2 Protocol February, 2005
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C:MRCP/2.0 48 543260 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
S->C:MRCP/2.0 73 SPEAK-COMPLETE 543260 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Completion-Cause: 000 normal
8.13. SPEECH-MARKER
This is an event generated by the synthesizer resource to the client
when it hits a marker tag in the speech markup it is currently
processing. The request-id field in the header matches the SPEAK
request request-id that initiated the speech. The request-state
field should be IN-PROGRESS as the speech is still not complete and
there is more to be spoken. The actual speech marker tag hit,
describing where the synthesizer is in the speech markup, is
returned in the speech-marker header field, with an NTP timestamp.
The SPEECH-MARKER event is also generated with a marker value of ""
and the NTP timestamp, when a SPEAK-REQUEST in Pending-State(in the
queue) moves to IN-PROGRESS and starts speaking. The NTP timestamp
MUST be synchronized with the RTP timestamp used to generate the
speech stream.
Example:
C->S:MRCP/2.0 434 SPEAK 543261
Channel-Identifier: 32AECB23433802@speechsynth
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: synthesis+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
S Shanmugham IETF-Draft Page 52
MRCPv2 Protocol February, 2005
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<mark name="here"/>
<s>The subject is
<prosody rate="-20%">ski trip</prosody>
</s>
<mark name="ANSWER"/>
</p>
</speak>
S->C:MRCP/2.0 48 543261 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
S->C:MRCP/2.0 73 SPEECH-MARKER 543261 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
Speech-Marker: here
S->C:MRCP/2.0 74 SPEECH-MARKER 543261 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
Speech-Marker: ANSWER
S->C:MRCP/2.0 73 SPEAK-COMPLETE 543261 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Completion-Cause: 000 normal
8.14. DEFINE-LEXICON
The DEFINE-LEXICON method, from the client to the server, provides a
lexicon and tells the server to load, unload, activate or deactivate
the lexicon.
If the server resource is in the speaking or paused state, the
DEFINE-LEXICON request MUST respond with a failure status.
If the resource is in the idle state and is able to successfully
load/unload/activate/deactivate the lexicon the status MUST return a
success code and the request-state MUST be COMPLETE.
If the synthesizer could not define the lexicon for some reason, say
the download failed or the lexicon was in an unsupported form, the
MRCPv2 response for the DEFINE-LEXICON method MUST contain a failure
status code of 407, and a completion-cause header field describing
the failure reason.
S Shanmugham IETF-Draft Page 53
MRCPv2 Protocol February, 2005
9. Speech Recognizer Resource
The speech recognizer resource is capable of receiving an incoming
voice stream and providing the client with an interpretation of what
was spoken in textual form.
This section applies for the following resource types.
1. speechrecog
2. dtmfrecog
The difference between the above two resources is in their level of
support for recognition grammars. The "dtmfrecog" resource is
capable of recognizing DTMF digits only and hence will accept DTMF
grammars only. The "speechrecog" can recognize regular speech as
well as DTMF digits and hence SHOULD support grammars describing
speech or DTMF. The recognition resource may support recognition in
the normal or hotword modes or both. For implementations where a
single recognition resource does not support both modes, they can be
implemented as separate resources and allocated to the same SIP
session with different MRCP session identifiers and share the RTP
audio feed.
Normal Mode Recognition
Regular mode recognition tries to match all of the speech or dtmf
from the time it starts recognizing to the grammar and returns a no-
match status if it fails to match or times out.
Hotword Mode Recognition
Hotword mode is where the recognizer looks for a specific speech
grammar or dtmf sequence and ignores speech or DTMF that does not
match. It does not timeout nor generate a no-match and will complete
only for a successful match of grammar.
Voice Enrolled Grammars
A recognition resource may optionally support Voice Enrolled
Grammars. With this functionality enrollment is performed using a
person's voice. For example, a list of contacts can be created and
maintained by recording the person's names using the caller's voice.
This technique is sometimes also called speaker-dependent
recognition.
Voice Enrollment has a concept of an enrollment session. A session
to add a new phrase to a personal grammar involves the initial
enrollment followed by a repeat of enough utterances before
committing the new phrase to the personal grammar. Each time an
utterance is recorded, it is compared for similarity with the other
samples and a clash test is performed against other entries in the
S Shanmugham IETF-Draft Page 54
MRCPv2 Protocol February, 2005
personal grammar to ensure there are no similar and confusable
entries.
Enrollment is done using a Recognizer resource. Controlling which
utterances are to be considered for enrollment of a new phrase is
done by setting a header field in the Recognize request.
9.1. Recognizer State Machine
The recognizer resource is controlled by MRCPv2 requests from the
client. Similarly the resource can respond to these requests or
generate asynchronous events to the server to indicate certain
conditions during the processing of the stream. Hence the recognizer
maintains states to correlate MRCPv2 requests from the client. The
state transitions are described below.
Idle Recognizing Recognized
State State State
| | |
|---------RECOGNIZE---->|---RECOGNITION-COMPLETE-->|
|<------STOP------------|<-----RECOGNIZE-----------|
| | |
| | |-----------|
| |--------| GET-RESULT |
| START-OF-SPEECH | |---------->|
|------------| |------->| |
| | |----------| |
| DEFINE-GRAMMAR | START-INPUT-TIMERS |
|<-----------| |<---------| |
| | |
| |------| |
|-------| | RECOGNIZE |
| STOP |<-----| |
|<------| |
| |
|<-------------------STOP--------------------------|
|<-------------------DEFINE-GRAMMAR----------------|
If a recognition resource support voice enrolled grammars, starting
an enrollment session does not change the state of the recognizer
resource. Once an enrollment session is started, then utterances
are enrolled by calling the RECOGNIZE method repeatedly. The state
of the Speech Recognizer resources goes from IDLE to RECOGNIZING
state each time RECOGNIZE is called.
9.2. Recognizer Methods
The recognizer supports the following methods.
recognizer-method = recog-only-method
S Shanmugham IETF-Draft Page 55
MRCPv2 Protocol February, 2005
/ enrollment-method
recog-only-method = "DEFINE-GRAMMAR" ; A
/ "RECOGNIZE" ; B
/ "INTERPRET" ; C
/ "GET-RESULT" ; D
/ "START-INPUT-TIMERS" ; E
/ "STOP" ; F
It is OPTIONAL for a recognizer resource to support voice enrolled
grammars. If the recognizer resource does support voice enrolled
grammars it MUST support the following methods.
enrollment-method = "START-PHRASE-ENROLLMENT" ; G
/ "ENROLLMENT-ROLLBACK" ; H
/ "END-PHRASE-ENROLLMENT" ; I
/ "MODIFY-PHRASE" ; J
/ "DELETE-PHRASE" ; K
9.3. Recognizer Events
The recognizer may generate the following events.
recognizer-event = "START-OF-SPEECH" ; L
/ "RECOGNITION-COMPLETE" ; M
/ "INTERPRETATION-COMPLETE" ; N
9.4. Recognizer Header Fields
A recognizer message may contain header fields containing request
options and information to augment the Method, Response or Event
message it is associated with.
recognizer-header = recog-only-header
/ enrollment-header
recog-only-header = confidence-threshold
/ sensitivity-level
/ speed-vs-accuracy
/ n-best-list-length
/ no-input-timeout
/ recognition-timeout
/ waveform-uri
/ input-waveform-uri
/ completion-cause
/ completion-reason
/ recognizer-context-block
/ start-input-timers
/ speech-complete-timeout
/ speech-incomplete-timeout
/ dtmf-interdigit-timeout
S Shanmugham IETF-Draft Page 56
MRCPv2 Protocol February, 2005
/ dtmf-term-timeout
/ dtmf-term-char
/ fetch-timeout
/ failed-uri
/ failed-uri-cause
/ save-waveform
/ new-audio-channel
/ speech-language
/ ver-buffer-utterance
/ recognition-mode
/ cancel-if-queue
/ hotword-max-duration
/ hotword-min-duration
/ interpret-text
/ one-of-rule-id-uri
If a recognition resource supports voice enrolled grammars, the
following header fields apply towards using that functionality.
enrollment-header = num-min-consistent-pronunciations
/ consistency-threshold
/ clash-threshold
/ personal-grammar-uri
/ phrase-id
/ phrase-nl
/ weight
/ save-best-waveform
/ new-phrase-id
/ confusable-phrases-uri
/ abort-phrase-enrollment
Header field where s g A B C D E F G H I J K L M N
__________________________________________________________
Confidence-Threshold R o o - o - o - - - - - - - - - -
Sensitivity-Level R o o - o - - - - - - - - - - - -
Speed-Vs-Accuracy R o o - o - - - - - - - - - - - -
N-Best-List-Length R o o - o - o - - - - - - - - - -
No-Input-Timeout R o o - o - - - - - - - - - - - -
Recognition-Timeout R o o - o - - - - - - - - - - - -
Waveform-URI R - - - - - - - - - - - - - - o -
Waveform-URI 2XX - - - - - - - - - - o - - - - -
Input-Waveform-URI R - - - o - - - - - - - - - - - -
Completion-Cause R - - - - - - - - - - - - - - m m
Completion-Cause 2XX - - o o o - - - - - - - - - - -
Completion-Cause 4XX - - m m m - - - - - - - - - - -
Completion-Reason R - - - - - - - - - - - - - - m m
Completion-Reason 2XX - - o o o - - - - - - - - - - -
Completion-Reason 4XX - - m m m - - - - - - - - - - -
Recognizer-Context-Bl. R o o - - - - - - - - - - - - - -
Start-Input-Timers R - - - o - - - - - - - - - - - -
Speech-Complete-Time. R o o - o - - - - - - - - - - - -
S Shanmugham IETF-Draft Page 57
MRCPv2 Protocol February, 2005
Speech-Incomplete-Time. R o o - o - - - - - - - - - - - -
DTMF-Interdigit-Timeo. R o o - o - - - - - - - - - - - -
DTMF-Term-Timeout R o o - o - - - - - - - - - - - -
DTMF-Term-Char R o o - o - - - - - - - - - - - -
Fetch-Timeout R o o o o - - - - - - - - - - - -
Failed-URI R - - - - - - - - - - - - - - o o
Failed-URI 4XX - - o o - - - - - - - - - - - -
Failed-URI-Cause R - - - - - - - - - - - - - - o o
Failed-URI-Cause 4XX - - o o - - - - - - - - - - - -
Save-Waveform R o o - o - - - - - - - - - - - -
New-Audio-Channel R - - - o - - - - - - - - - - - -
Speech-Language R o o o o - - - - - - - - - - - -
Ver-Buffer-Utterance R o o - o - - - - - - - - - - - -
Recognition-Mode R - - - o - - - - - - - - - - - -
Cancel-If-Queue R - - - o - - - - - - - - - - - -
Hotword-Max-Duration R o o - o - - - - - - - - - - - -
Hotword-Min-Duration R o o - o - - - - - - - - - - - -
Interpret-Text R - - - - m - - - - - - - - - - -
One-Of-Rule-Id-URI R - - - o o - - - - - - - - - - -
Num-Min-Consistent-Pr R o o - - - - - - o - - - - - - -
Consistency-Threshold R o o - - - - - - o - - - - - - -
Clash-Threshold R o o - - - - - - o - - - - - - -
Personal-Grammar-URI R o o - - - - - - o - - o o - - -
Phrase-ID R - - - - - - - - m - - m m - - -
Phrase-NL R - - - - - - - - o - - o - - - -
Weight R - - - - - - - - o - - o - - - -
Save-Best-Waveform R o o - - - - - - o - - - - - - -
New-Phrase-ID R - - - - - - - - - - - o - - - -
Confusable-Phrases-URI R - - - o - - - - - - - - - - - -
Abort-Phrase-Enrollment R - - - - - - - - - - o - - - - -
Legend: (s) - SET-PARAMS, (g) - GET-PARAMS, (A) - DEFINE, (B) -
RECOGNIZE, (C) -INTERPRET, (D) GET-RESULT, (E) - START-INPUT-TIMERS,
(F) - STOP, (G) - START-PHRASE-ENROLLMENT, (H) - ENROLLMENT-
ROLLBACK, (I) - END-PHRASE-ENROLLMENT, (J) - MODIFY-PHRASE, (K) -
DELETE-PHRASE, (L) - START-OF-SPEECH, (M) - RECOGNITION-COMPLETE,
(N) - INTERPRETATION-COMPLETE (o) - Optional(Refer text for further
constraints), (m) - Mandatory, (R) - Request, (r) - Response
For enrollment-specific header fields that can appear as part of
SET-PARAMS or GET-PARAMS methods, the following general rule
applies: the START-PHRASE-ENROLLMENT method must be called before
these header fields can be set through the SET-PARAMS method or
retrieved through the GET-PARAMS method.
Note that the waveform-uri header field of the Recognizer resource
can also appear in the response to the END-PHRASE-ENROLLMENT method.
S Shanmugham IETF-Draft Page 58
MRCPv2 Protocol February, 2005
Confidence Threshold
When a recognition resource recognizes or matches a spoken phrase
with some portion of the grammar, it associates a confidence level
with that conclusion. The confidence-threshold header tells the
recognizer resource what confidence level should be considered a
successful match. This is a float value between 0.0-1.0 indicating
the recognizer's confidence in the recognition. If the recognizer
determines that its confidence in all its recognition results is
less than the confidence threshold, then it MUST return no-match as
the recognition result. This header field MAY occur in RECOGNIZE,
SET-PARAMS or GET-PARAMS. The default value for this field is
platform specific.
confidence-threshold= "Confidence-Threshold" ":" FLOAT CRLF
Sensitivity Level
To filter out background noise and not mistake it for speech, the
recognizer may support a variable level of sound sensitivity. The
sensitivity-level header is a float value between 0.0 and 1.0 and
allows the client to set the sensity level for the recognizer. This
header field MAY occur in RECOGNIZE, SET-PARAMS or GET-PARAMS. A
higher value for this field means higher sensitivity. The default
value for this field is platform specific.
sensitivity-level = "Sensitivity-Level" ":" FLOAT CRLF
Speed Vs Accuracy
Depending on the implementation and capability of the recognizer
resource it may be tunable towards Performance or Accuracy. Higher
accuracy may mean more processing and higher CPU utilization,
meaning less calls per server and vice versa. This header is a float
value between 0.0 and 1.0 and allows this field to be tuned by the
speed-vs-accuracy header. This header field MAY occur in RECOGNIZE,
SET-PARAMS or GET-PARAMS. A higher value for this field means higher
speed. The default value for this field is platform specific.
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" FLOAT CRLF
N Best List Length
When the recognizer matches an incoming stream with the grammar, it
may come up with more than one alternative matches because of
confidence levels in certain words or conversation paths. If this
header field is not specified, by default, the recognition resource
will only return the best match above the confidence threshold. The
client, by setting this header, could ask the recognition resource
to send it more than 1 alternative. All alternatives must still be
above the confidence-threshold. A value greater than one does not
S Shanmugham IETF-Draft Page 59
MRCPv2 Protocol February, 2005
guarantee that the recognizer will send the requested number of
alternatives. This header field MAY occur in RECOGNIZE, SET-PARAMS
or GET-PARAMS. The minimum value for this field is 1. The default
value for this field is 1.
n-best-list-length = "N-Best-List-Length" ":" 1*DIGIT CRLF
No Input Timeout
When recognition is started and there is no speech detected for a
certain period of time, the recognizer can send a RECOGNITION-
COMPLETE event to the client and terminate the recognition
operation. The no-input-timeout header field can set this timeout
value. The value is in milliseconds. This header field MAY occur in
RECOGNIZE, SET-PARAMS or GET-PARAMS. The value for this field ranges
from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The
default value for this field is platform specific.
no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
Recognition Timeout
When recognition is started and there is no match for a certain
period of time, the recognizer can send a RECOGNITION-COMPLETE event
to the client and terminate the recognition operation. It is the
timer that is started when START-OF-SPEECH event is generated by the
resource and specifies the maximum duration of the utterance. When
this timer expires the recognition request would complete with a
status code of "008 too-much-speech-timeout". The recognition-
timeout header field sets this timeout value. The value is in
milliseconds. The value for this field ranges from 0 to MAXTIMEOUT,
where MAXTIMEOUT is platform specific. The default value is 10
seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS or
GET-PARAMS.
recognition-timeout = "Recognition-Timeout" ":" 1*DIGIT CRLF
Waveform URI
If the save-waveform header field is set to true, the recognizer
MUST record the incoming audio stream of the recognition into a file
and provide a URI for the client to access it. This header MUST be
present in the RECOGNITION-COMPLETE event if the save-waveform
header field was set to true. The URI value of the header MUST be
NULL if there was some error condition preventing the server from
recording. Otherwise, the URI generated by the server SHOULD be
globally unique across the server and all its recognition sessions.
The URI SHOULD BE available until the session is torn down.
S Shanmugham IETF-Draft Page 60
MRCPv2 Protocol February, 2005
Similarly, if the save-best-waveform header field is set to true,
the recognizer MUST save the audio stream for the best repetition of
the phrase that was used during the enrollment session. The
recognizer MUST then record the recognized audio and make it
available to the client in the form of a URI returned in the
waveform-uri header field in the response to the END-PHRASE-
ENROLLMENT method. The URI value of the header MUST be NULL if there
was some error condition preventing the server from recording.
Otherwise, the URI generated by the server SHOULD be globally unique
across the server and all its recognition sessions. The URI SHOULD
BE available until the session is torn down.
waveform-uri = "Waveform-URI" ":" Uri CRLF
Input-Waveform-Uri
This optional header field specifies an audio file that has to be
processed according to the RECOGNIZE operation. This enables the
client to recognize from a specified buffer or audio file. It MAY be
part of the RECOGNIZE method.
input-waveform-uri = "Input-Waveform-URI" ":" Uri CRLF
Completion Cause
This header field MUST be part of a RECOGNITION-COMPLETE, event
coming from the recognizer resource to the client. This indicates
the reason behind the RECOGNIZE method completion. This header field
MUST BE sent in the DEFINE-GRAMMAR and RECOGNIZE responses, if they
return with a failure status and a COMPLETE state.
completion-cause = "Completion-Cause" ":" 1*DIGIT SP
1*VCHAR CRLF
Cause-Code Cause-Name Description
000 success RECOGNIZE completed with a match or
DEFINE-GRAMMAR succeeded in
downloading and compiling the
grammar
001 no-match RECOGNIZE completed, but no match
was found
002 no-input-timeout
RECOGNIZE completed without a match
due to a no-input-timeout
003 recognition-timeout
RECOGNIZE completed without a match
due to a recognition-timeout
004 gram-load-failure
RECOGNIZE failed due grammar load
failure.
S Shanmugham IETF-Draft Page 61
MRCPv2 Protocol February, 2005
005 gram-comp-failure
RECOGNIZE failed due to grammar
compilation failure.
006 error RECOGNIZE request terminated
prematurely due to a recognizer
error.
007 speech-too-early
RECOGNIZE request terminated because
speech was too early. This happens
when the audio stream is already
"in-speech" when the RECOGNIZE
request was received.
008 too-much-speech-timeout
RECOGNIZE request terminated because
speech was too long.
009 uri-failure Failure accessing a URI.
010 language-unsupported
Language not supported.
011 cancelled A new RECOGNIZE cancelled this one.
012 semantics-failure
Recognition succeeded but semantic
interpretation of the recognized
input failed. The RECOGNITION-
COMPLETE event MUST contain the
Recognition result with only input
text and no interpretation.
Completion Reason
This header field MAY be specified in a RECOGNITION-COMPLETE event
coming from the recognizer resource to the client. This contains the
reason text behind the RECOGNIZE request completion. This field can
be use to communicate text describing the reason for the failure,
such as an error in parsing the grammar markup text.
completion-reason = "Completion-Reason" ":"
quoted-string CRLF
Recognizer Context Block
This header MAY BE sent as part of the SET-PARAMS or GET-PARAMS
request. If the GET-PARAMS method contains this header field with no
value, then it is a request to the recognizer to return the
recognizer context block. The response to such a message MAY contain
a recognizer context block as a message entity. If the server
returns a recognizer context block, the response MUST contain this
header field and its value MUST match the content-id of that entity.
If the SET-PARAMS method contains this header field, it MUST contain
a message entity containing the recognizer context data, and a
content-id matching this header field. This content-id should match
S Shanmugham IETF-Draft Page 62
MRCPv2 Protocol February, 2005
the content-id that came with the context data during the GET-PARAMS
operation.
Each recognition vendor choosing to use this mechanism to handoff
recognizer context data between servers MUST distinguish its vendor
specific block of data by using an IANA-registered content type in
the IANA MIME vendor tree.
recognizer-context-block = "Recognizer-Context-Block" ":"
1*VCHAR CRLF
Start Input Timers
This header MAY BE sent as part of the RECOGNIZE request. A value of
false tells the recognizer to start recognition, but not to start
the no-input timer yet. The recognizer should not start the timers
until the client sends a START-INPUT-TIMERS request to the
recognizer. This is useful in the scenario when the recognizer and
synthesizer engines are not part of the same session. Here when a
kill-on-barge-in prompt is being played, you want the RECOGNIZE
request to be simultaneously active so that it can detect and
implement kill-on-barge-in. But at the same time you don't want the
recognizer to start the no-input timers until the prompt is
finished. The default value is "true".
start-input-timers = "Start-Input-Timers" ":"
boolean-value CRLF
Speech Complete Timeout
This header field specifies the length of silence required following
user speech before the speech recognizer finalizes a result (either
accepting it or throwing a nomatch event). The speech-complete-
timeout value is used when the recognizer currently has a complete
match of an active grammar, and specifies how long it should wait
for more input declaring a match. By contrast, the incomplete
timeout is used when the speech is an incomplete match to an active
grammar. The value is in milliseconds.
speech-complete-timeout= "Speech-Complete-Timeout" ":"
1*DIGIT CRLF
A long speech-complete-timeout value delays the result completion
and therefore makes the computer's response slow. A short speech-
complete-timeout may lead to an utterance being broken up
inappropriately. Reasonable complete timeout values are typically in
the range of 0.3 seconds to 1.0 seconds. The value for this field
ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific.
The default value for this field is platform specific. This header
field MAY occur in RECOGNIZE, SET-PARAMS or GET-PARAMS.
S Shanmugham IETF-Draft Page 63
MRCPv2 Protocol February, 2005
Speech Incomplete Timeout
This header field specifies the required length of silence following
user speech after which a recognizer finalizes a result. The
incomplete timeout applies when the speech prior to the silence is
an incomplete match of all active grammars. In this case, once the
timeout is triggered, the partial result is rejected (with a nomatch
event). The value is in milliseconds. The value for this field
ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific.
The default value for this field is platform specific.
speech-incomplete-timeout= "Speech-Incomplete-Timeout" ":"
1*DIGIT CRLF
The speech-incomplete-timeout also applies when the speech prior to
the silence is a complete match of an active grammar, but where it
is possible to speak further and still match the grammar. By
contrast, the complete timeout is used when the speech is a complete
match to an active grammar and no further words can be spoken.
A long speech-incomplete-timeout value delays the result completion
and therefore makes the computer's response slow. A short speech-
incomplete-timeout may lead to an utterance being broken up
inappropriately.
The speech-incomplete-timeout is usually longer than the speech-
complete-timeout to allow users to pause mid-utterance (for example,
to breathe). This header field MAY occur in RECOGNIZE, SET-PARAMS or
GET-PARAMS.
DTMF Interdigit Timeout
This header field specifies the inter-digit timeout value to use
when recognizing DTMF input. The value is in milliseconds. The
value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT
is platform specific. The default value is 5 seconds. This header
field MAY occur in RECOGNIZE, SET-PARAMS or GET-PARAMS.
dtmf-interdigit-timeout= "DTMF-Interdigit-Timeout" ":"
1*DIGIT CRLF
DTMF Term Timeout
This header field specifies the terminating timeout to use when
recognizing DTMF input. The DTMF-Term-Timeout applies only when no
additional input is allowed by the grammar; otherwise, the
DTMF-Interdigit-Timeout applies. The value is in milliseconds. The
value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT
is platform specific. The default value is 10 seconds. This header
field MAY occur in RECOGNIZE, SET-PARAMS or GET-PARAMS.
S Shanmugham IETF-Draft Page 64
MRCPv2 Protocol February, 2005
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*DIGIT CRLF
DTMF-Term-Char
This header field specifies the terminating DTMF character for DTMF
input recognition. The default value is NULL which is specified as
an empty header field. This header field MAY occur in RECOGNIZE,
SET-PARAMS or GET-PARAMS.
dtmf-term-char = "DTMF-Term-Char" ":" VCHAR CRLF
Fetch Timeout
When the recognizer needs to fetch grammar documents this header
field controls URI access properties. This defines the recognizer
timeout for content that the server may need to fetch from the
network. The value is in milliseconds. The value for this field
ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific.
The default value for this field is platform specific. This header
field MAY occur in RECOGNIZE, SET-PARAMS or GET-PARAMS.
fetch-timeout = "Fetch-Timeout" ":" 1*ALPHA CRLF
Failed URI
When a recognizer method needs a recognizer to fetch or access a URI
and the access fails the server SHOULD provide the failed URI in
this header field in the method response.
failed-uri = "Failed-URI" ":" Uri CRLF
Failed URI Cause
When a recognizer method needs a recognizer to fetch or access a URI
and the access fails the server SHOULD provide the URI specific or
protocol specific response code through this header field in the
method response. This field has been defined as alphanumeric to
accommodate all protocols, some of which might have a response
string instead of a numeric response code.
failed-uri-cause = "Failed-URI-Cause" ":" 1*alphanum
CRLF
Save Waveform
This header field allows the client to indicate to the recognizer
that it MUST save the audio stream that was recognized. The
recognizer MUST then record the recognized audio, without end-
pointing and make it available to the client in the form of a URI
returned in the waveform-uri header field in the RECOGNITION-
S Shanmugham IETF-Draft Page 65
MRCPv2 Protocol February, 2005
COMPLETE event. If there was an error in recording the stream or the
audio clip is otherwise not available, the recognizer MUST return an
empty waveform-uri header field. The default value for this fields
is "false".
save-waveform = "Save-Waveform" ":" boolean-value CRLF
New Audio Channel
This header field MAY BE specified in a RECOGNIZE message and allows
the client to tell the server that, from that point on, it will be
sending audio data from a new audio source, channel or speaker. If
the recognition resource had collected any line statistics or
information, it MUST discard it and start fresh for this RECOGNIZE.
Note that if there are multiple resources on the same SIP session
that may be collecting or using these line statistics, the client
MUST reset the line statistics for all these resource. This helps in
the case where the client MAY want to reuse an open recognition
session with a media resource for multiple telephone calls.
new-audio-channel = "New-Audio-Channel" ":" boolean-value
CRLF
Speech-Language
This header field specifies the language of recognition grammar data
within a session or request, if it is not specified within the data.
The value of this header field should follow RFC 3066 for its
values. This MAY occur in DEFINE-GRAMMAR, RECOGNIZE, SET-PARAMS or
GET-PARAMS request.
speech-language = "Speech-Language" ":" 1*VCHAR CRLF
One-Of-Rule-Id-URI
This header field MAY be specified in the RECOGNIZE or INTERPRET
method that ONLY carries a single URI or a grammar block in its
message body. This header refers to a specific rule-id in the
grammar mime-body which should be treated as the list of activation
grammars. This rule-id MUST be a <one-of> rule-id and the listed
items MUST ALL BE grammar-uri-references and MAY NOT be a grammar
token. This is considered equivalent to specifying a tex/uri mime
type with a list of grammar URIs for activation, but has the
additional benefit of being able to provide weights for the
individual grammar URIs. The order of the URI items in the one-of
rule-id MUST bet precedence of the list of activation grammars.
one-of-rule-id-uri = "One-Of-Rule-Id-URI" ":" token CRLF
S Shanmugham IETF-Draft Page 66
MRCPv2 Protocol February, 2005
Ver-Buffer-Utterance
This header field is the same as the one described for the
Verification resource. This tells the server to buffer the utterance
associated with this recognition request into the verification
buffer. Sending this header field is not valid if the verification
buffer is not instantiated for the session. This buffer is shared
across resource within a session and gets instantiated when a
verification resource is added to this session and is released when
the resource is released from the session.
Recognition-Mode
This header field specifies what mode the RECOGNIZE command should
start up in. The value choices are "normal" or "hotword". If the
value is "normal", the RECOGNIZE starts matching all speech and DTMF
from that point to the grammars specified in the RECOGNIZE commands.
If any portion of the speech does not match the grammar, the
RECOGNIZE command completes with a no-match status. Also, timers may
be active to detect speech in the audio, and the RECOGNIZE command
finish because of timeout waiting for speech. If the value of this
header field is "hotword", the RECOGNIZE command starts up in
hotword mode, where it only looks for particular keywords or DTMF
sequences specified in the grammar and ignore silence or other
speech in the audio stream. The default value for this header field
is "normal".
recognition-mode = "Recognition-Mode" ":" 1*ALPHA CRLF
Cancel-If-Queue
This header field specifies what should happen to this RECOGNIZE
method when the client queues more RECOGNIZE methods to the
resource. The value for this header field is Boolean. A value of
"true" for this header field in a RECOGNIZE method, means this
RECOGNIZE method when active MUST terminate, with a Completion-Cause
of "cancelled", when the client queues another RECOGNIZE command to
the resource. A value of "false" for this header field in a
RECOGNIZE method, means that the RECOGNIZE method will continue till
its operation is complete and if the client queues more RECOGNIZE
methods to the resource, they are queued. When the current RECOGNIZE
method is stopped or completes with a successful match, the first
RECOGNIZE method in the queue becomes active. If the current
RECOGNIZE fails, all RECOGNIZE methods in the pending queue are
cancelled and will generate a RECOGNITION-COMPLETE event with a
Completion-Cause of "cancelled". This field MUST exist in all
RECOGNIZE methods.
cancel-if-queue = "Cancel-If-Queue" ":" Boolean-value CRLF
S Shanmugham IETF-Draft Page 67
MRCPv2 Protocol February, 2005
Hotword-Max-Duration
This header MAY BE sent in a hotword mode RECOGNIZE request. It
specifies the maximum length of an utterance (in seconds) that
should be considered for Hotword recognition. This header, along
with Hotword-Min-Duration, can be used to tune performance by
preventing the recognizer from evaluating utterances that are too
short or too long to be the Hotword. The value is in milliseconds.
The default is platform dependent.
hotword-max-duration = "Hotword-Max-Duration" ":" 1*DIGIT
CRLF
Hotword-Min-Duration
This header MAY BE sent in a hotword mode RECOGNIZE request. It
specifies the minimum length of an utterance (in seconds) that can
be considered for Hotword. This header, along with Hotword-Max-
Duration, can be used to tune performance by preventing the
recognizer from evaluating utterances that are too short or too long
to be the hot word. The value is in milliseconds. The default value
is platform dependent.
hotword-min-duration = "Hotword-Min-Duration" ":" 1*DIGIT CRLF
Interpret-Text
This header field is used to provide the text for which a natural
language interpretation is desired. The value of this field has a
content-id that refers to a MIME entity of type plain/text in the
body of the message. This header field MUST be used when invoking
the INTERPRET method.
interpret-text = "Interpret-Text" : 1*VCHAR CRLF
Num-Min-Consistent-Pronunciations
This header MAY BE specified in a START-PHRASE-ENROLLMENT, SET-
PARAMS, or GET-PARAMS method and is used to specify the minimum
number of consistent pronunciations that must be obtained to voice
enroll a new phrase. The minimum value is 1. The default value is
platform specific and MAY BE greater than 1.
num-min-consistent-pronunciations =
"Num-Min-Consistent-Pronunciations" ":" 1*DIGIT CRLF
Consistency-Threshold
This header MAY BE sent as part of the START-PHRASE-ENROLLMENT, SET-
PARAMS, or GET-PARAMS method. Used during voice-enrollment, this
S Shanmugham IETF-Draft Page 68
MRCPv2 Protocol February, 2005
header specifies how similar an utterance needs to be, to a
previously enrolled pronunciation of the same phrase to be
considered "consistent." The higher the threshold, the closer the
match between an utterance and previous pronunciations must be for
the pronunciation to be considered consistent. The range for this
threshold is a float value between is 0.0 to 1.0. The default value
for this field is platform specific.
consistency-threshold = "Consistency-Threshold" ":" FLOAT CRLF
Clash-Threshold
This header MAY BE sent as part of the START-PHRASE-ENROLLMENT, SET-
PARMS, or GET-PARAMS method. Used during voice-enrollment, this
header specifies how similar the pronunciations of two different
phrases can be before they are considered to be clashing. For
example, pronunciations of phrases such as "John Smith" and "Jon
Smits" may be so similar that they are difficult to distinguish
correctly. A smaller threshold reduces the number of clashes
detected. The range for this threshold is float value between 0.0
and 1.0. The default value for this field is platform specific.
clash-threshold = "Clash-Threshold" ":" 1*DIGIT CRLF
Personal-Grammar-URI
This header specifies the speaker-trained grammar to be used or
referenced during enrollment operations. For example, a contact
list for user "Jeff" could be stored at the Personal-Grammar-
URI="http://myserver/myenrollmentdb/jeff-list". There is no default
value for this header field.
personal-grammar-uri = "Personal-Grammar-URI" ":" Uri CRLF
Phrase-Id
This header identifies a phrase in a personal grammar and will also
be returned when doing recognition. This header field MAY occur in
START-PHRASE-ENROLLMENT, MODIFY-PHRASE or DELETE-PHRASE requests.
There is no default value for this header field.
phrase-id = "Phrase-ID" ":" 1*VCHAR CRLF
Phrase-NL
This is a string specifying the natural language statement to
execute when the phrase is recognized. This header field MAY occur
S Shanmugham IETF-Draft Page 69
MRCPv2 Protocol February, 2005
in START-PHRASE-ENROLLMENT and MODIFY-PHRASE requests. There is no
default value for this header field.
phrase-nl = "Phrase-NL" ":" 1*VCHAR CRLF
Weight
The value of this header field represents the occurrence likelihood
of this branch of the grammar. The weights are normalized to sum to
one at compilation time, so use the value of '1' if you want all
branches to have the same weight. This header field MAY occur in
START-PHRASE-ENROLLMENT and MODIFY-PHRASE requests. The default
value for this field is platform specific.
weight = "Weight" ":" weight-value CRLF
Save-Best-Waveform
This header field allows the client to indicate to the recognizer
that it MUST save the audio stream for the best repetition of the
phrase that was used during the enrollment session. The recognizer
MUST then record the recognized audio and make it available to the
client in the form of a URI returned in the waveform-uri header
field in the response to the END-PHRASE-ENROLLMENT method. If there
was an error in recording the stream or the audio clip is otherwise
not available, the recognizer MUST return an empty waveform-uri
header field.
save-best-waveform = "Save-Best-Waveform" ":" Boolean-value CRLF
New-Phrase-Id
This header field replaces the id used to identify the phrase in a
personal grammar. The recognizer returns the new id when using an
enrollment grammar. This header field MAY occur in MODIFY-PHRASE
requests.
new-phrase-id = "New-Phrase-ID" ":" 1*VCHAR CRLF
Confusable-Phrases-URI
This optional header field specifies the grammar that defines
invalid phrases for enrollment. For example, typical applications
do not allow an enrolled phrase that is also a command word. This
header field MAY occur in RECOGNIZE requests.
confusable-phrases-uri = "Confusable-Phrases-URI" ":"
S Shanmugham IETF-Draft Page 70
MRCPv2 Protocol February, 2005
Uri CRLF
Abort-Phrase-Enrollment
This header field can optionally be specified in the END-PHRASE-
ENROLLMENT method to abort the phrase enrollment, rather than
committing the phrase to the personal grammar.
abort-phrase-enrollment = "Abort-Phrase-Enrollment" ":"
Boolean- value CRLF
9.5. Recognizer Message Body
A recognizer message may carry additional data associated with the
method, response or event. The client may send the grammar to be
recognized in DEFINE-GRAMMAR or RECOGNIZE requests. When the grammar
is sent in the DEFINE-GRAMMAR method, the server should be able to
download compile and optimize the grammar. The RECOGNIZE request
MUST contain a list of grammars that need to be active during the
recognition. The server resource may send the recognition results in
the RECOGNITION-COMPLETE event or the GET-RESULT response. This data
will be carried in the message body of the corresponding MRCPv2
message.
Recognizer Grammar Data
Recognizer grammar data from the client to the server can be
provided inline or by reference. Either way they are carried as MIME
entities in the message body of the MRCPv2 request message. The
grammar specified inline or by reference specifies the grammar used
to match in the recognition process and this data is specified in
one of the standard grammar specification formats like W3C's XML or
ABNF or Sun's Java Speech Grammar Format etc. All MRCPv2 servers
MUST support W3C's XML based grammar markup format [11](MIME-type
application/srgs+xml) and SHOULD support the ABNF form (MIME-type
application/srgs).
When a grammar is specified in-line in the message, the client MUST
provide a content-id for that grammar as part of the content
headers. The server MUST store the grammar associated with that
content-id for the duration of the session. A stored grammar can be
overwritten by defining a new grammar with the same content-id.
Grammars that have been associated with a content-id can be
referenced through a special "session:" URI scheme.
Example:
session:help@root-level.store
S Shanmugham IETF-Draft Page 71
MRCPv2 Protocol February, 2005
If grammar data needs to be specified by external URI reference, the
MIME-type text/uri-list is used to list the one or more URI that
will specify the grammar data. All servers MUST support the HTTP uri
access mechanism.
If the data to be defined consists of a mix of URI and inline
grammar data the multipart/mixed MIME-type is used and embedded with
the MIME-blocks for text/uri-list, application/srgs or
application/srgs+xml. The character set and encoding used in the
grammar data may be specified according to standard MIME-type
definitions.
When more than one grammar URI or inline grammar block is specified
in a message body of the RECOGNIZE request, it is an active list of
grammar alternatives to listen. The ordering of the list implies
the precedence of the grammars, with the first grammar in the list
having the highest precedence.
Example 1:
Content-Type: application/srgs+xml
Content-Id: <request1@form-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!-- the equivalent single-language attachment expansion -->
S Shanmugham IETF-Draft Page 72
MRCPv2 Protocol February, 2005
<rule id="people2">
<one-of>
<item xml:lang="en-US">Robert</item>
<item xml:lang="fr-CA">Robert</item>
</one-of>
</rule>
</grammar>
Example 2:
Content-Type: text/uri-list
Content-Length: 176
session:help@root-level.store
http://www.example.com/Directory-Name-List.grxml
http://www.example.com/Department-List.grxml
http://www.example.com/TAC-Contact-List.grxml
session:menu1@menu-level.store
Example 3:
Content-Type: multipart/mixed; boundary="break"
--break
Content-Type: text/uri-list
Content-Length: 176
http://www.example.com/Directory-Name-List.grxml
http://www.example.com/Department-List.grxml
http://www.example.com/TAC-Contact-List.grxml
--break
Content-Type: application/srgs+xml
Content-Id: <request1@form-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
S Shanmugham IETF-Draft Page 73
MRCPv2 Protocol February, 2005
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!-- the equivalent single-language attachment expansion -->
<rule id="people2">
<one-of>
<item xml:lang="en-US">Robert</item>
<item xml:lang="fr-CA">Robert</item>
</one-of>
</rule>
</grammar>
--break--
Recognizer Result Data
Recognition result data from the server is carried in the MRCPv2
message body of the RECOGNITION-COMPLETE event or the GET-RESULT
response message as MIME entities. All servers MUST support Natural
Language Semantics Markup Language (NLSML), an XML markup based on
an early draft from the W3C. This is the default standard for
returning recognition results back to the client, and hence MUST
support the MIME-type application/nlsml+xml.
MRCP-specific additions to this result format have been made and is
fully described in section 9.6 with a normative definition of the
DTD and schema in the Appendix.
Example 1:
Content-Type: application/nlsml+xml
Content-Length: 104
<?xml version="1.0"?>
<result grammar="http://theYesNoGrammar">
<interpretation>
<instance>
<response>yes</response>
</instance>
<input>ok</input>
</interpretation>
</result>
S Shanmugham IETF-Draft Page 74
MRCPv2 Protocol February, 2005
Enrollment Result Data
Enrollment results come as part of the RECOGNIZE-COMPLETE event as
part of the Recognition result XML data. The XML Schema and DTD for
this XML data is provided in section 9.7 with a normative definition
of the DTD and scheme in the Appendix.
Recognizer Context Block
When the client has to change servers within a call, this is a block
of data that the client MAY collect from the first server and
provide to the second server. This may be because the client needs a
different language support or because the server issued a redirect.
Here the first recognizer resource may have collected acoustic and
other data during its recognition. When we switch servers,
communicating this data may allow the recognition resource on the
new server to provide better recognition based on the acoustic data
collected by the previous recognizer. This block of data is vendor-
specific and MUST be carried as MIME-type application/octets in the
body of the message.
This block of data is communicated in the SET-PARAMS and GET-PARAMS
method/response messages. In the GET-PARAMS method, if an empty
recognizer-context-block header field is present, then the
recognizer should return its vendor-specific context block in the
message body as a MIME-entity with a specific content-id. The
content-id value should also be specified in the recognizer-context-
block header field in the GET-PARAMS response. The SET-PARAMS
request wishing to provide this vendor-specific data should send it
in the message body as a MIME-entity with the same content-id that
it received from the GET-PARAMS. The content-id should also be sent
in the recognizer-context-block header field of the SET-PARAMS
message.
Each automatic speech recognition (ASR) vendor choosing to use this
mechanism to handoff recognizer context data among its servers
should distinguish its vendor-specific block of data from other
vendors by choosing a unique content-id that they should recognize.
9.6. Natural Language Semantic Markup Language
The general purpose of the NL Semantics Markup is to represent
information automatically extracted from a user's utterances by a
semantic interpretation component, where utterance is to be taken in
the general sense of a meaningful user input in any modality
supported by the platform. A specific architecture can take
advantage of this representation by using it to convey content among
S Shanmugham IETF-Draft Page 75
MRCPv2 Protocol February, 2005
various system components that generate and make use of the markup.
In MRCP it is to be used to convey these results between a
recognition resource on the MRCP server and the MRCP client.
Components that generate NLSML:
1. Automatic Speech Recognition (ASR)
2. Natural language understanding
3. Other input media interpreters (e.g. DTMF, pointing,
keyboard)
4. Reusable dialog components
5. Multimedia integration
Components that use NLSML:
1. Dialog manager
2. Multimedia integration
A platform may also choose to use this general format as the basis
of a general semantic result that is carried along and filled out
during each stage of processing. In addition, future systems may
also potentially make use of this markup to convey abstract semantic
content to be rendered into natural language by a natural language
generation component.
Markup Functions
A semantic interpretation system that supports the Natural Language
Semantics Markup Language is responsible for interpreting natural
language inputs and formatting the interpretation as defined in this
document. Semantic interpretation is typically either included as
part of the speech recognition process, or involves one or more
additional components, such as natural language interpretation
components and dialog interpretation components.
The elements of the markup fall into the following general
functional categories:
Interpretation:
Elements and attributes representing the semantics of the user's
utterance, including the <result>, <interpretation>, and <instance>
elements. The <result> element contains the full result of
processing one utterance. It may contain multiple <interpretation>
elements if the interpretation of the utterance results in multiple
alternative meanings due to uncertainty in speech recognition or
natural language understanding. There are at least two reasons for
providing multiple interpretations:
1. another component, such as a dialog manager, might have
additional information, for example, information from a
database, that would allow it to select a preferred
S Shanmugham IETF-Draft Page 76
MRCPv2 Protocol February, 2005
interpretation from among the possible interpretations returned
from the semantic interpreter.
2. a dialog manager that was unable to select between several
competing interpretations could use this information to go back
to the user and find out what was intended. For example, Did
you say "Boston" or "Austin"?
Side Information:
Elements and attributes representing additional information about
the interpretation, over and above the interpretation itself. Side
information includes
1. Whether an interpretation was achieved (the <nomatch> element)
and the system's confidence in an interpretation (the
"confidence" attribute of <interpretation>).
2. Alternative interpretations (<interpretation>)
3. Input formats and ASR information: The <input> element,
representing the input to the semantic interpreter.
Multi-modal integration:
When more than one modality is available for input, the
interpretation of the inputs need to be coordinated. The "mode"
attribute of <input> supports this by indicating whether the
utterance was input by speech, dtmf, pointing, etc.
The"timestamp_start" and "timestamp_end" attributes of
<interpretation> also provide for temporal coordination by
indicating when inputs occurred.
Overview of NLSML Elements and their Relationships
The elements in NLSML fall into two categories:
1. description of the input that was processed.
2. description of the meaning which was extracted from the input.
Next to each element are its attributes. In addition, some elements
can contain multiple instances of other elements. For example, a
<result> can contain multiple <interpretations>, each of which is
taken to be an alternative. Similarly, <input> can contain multiple
child <input> elements which are taken to be cumulative. A URI
reference to an XForms data model is permitted but not required.
To illustrate the basic usage of these elements, as a simple
example, consider the utterance ok (interpreted as "yes"). The
S Shanmugham IETF-Draft Page 77
MRCPv2 Protocol February, 2005
example illustrates how that utterance and its interpretation would
be represented in the NL Semantics markup.
<result grammar="http://theYesNoGrammar>
<interpretation>
<instance>
<response>yes</response>
</instance>
<input>ok</input>
</interpretation>
</result>
This example includes only the minimum required information. There
is an overall <result> element which includes one interpretation,
containing the application-specific elements "<yes_no>" and
"<response>".
Elements and Attributes
RESULT Root Element
Attributes: grammar, x-model xmlns
The root element of the markup is <result>. The <result> element
includes one or more <interpretation> elements. Multiple
interpretations can result from ambiguities in the input or in the
semantic interpretation. If the "grammar" and "x-model" attributes
don't apply to all of the interpretations in the result they can be
overridden for individual interpretations at the <interpretation>
level.
Attributes:
1. grammar: The grammar or recognition rule matched by this
result. The format of the grammar attribute will match the rule
reference semantics defined in the grammar specification.
Specifically, the rule reference will be in the external XML
form for grammar rule references. The dialog markup interpreter
needs to know the grammar rule that is matched by the utterance
because multiple rules may be simultaneously active. The value
is the grammar URI used by the dialog markup interpreter to
specify the grammar. The grammar can be overridden by a grammar
attribute in the <interpretation> element if the input was
ambiguous as to which grammar it matched.
2. x-model: The URI which defines the XForms data model used for
this result. The x-model can be overridden by an x-model
attribute in the <interpretation> element if the input was
ambiguous as to which x-model it matched.(optional)
<result grammar="http://grammar">
S Shanmugham IETF-Draft Page 78
MRCPv2 Protocol February, 2005
<interpretation>
....
</interpretation>
</result>
INTERPRETATION Element
Attributes: confidence, grammar, x-model
An <interpretation> element contains a single semantic
interpretation.
Attributes:
1. confidence: An integer from 0-100 indicating the semantic
analyzer's confidence in this interpretation. At this point
there is no formal, platform-independent, definition of
confidence. (optional)
2. grammar: The grammar or recognition rule matched by this
interpretation (if needed to override the grammar specification
at the <interpretation> level.) This attribute will only be
needed under <interpretation> if it is necessary to override a
grammar that was defined at the <result> level.) (optional)
3. x-model: The URI which defines the XForms data model used for
this interpretation. (As in the case of "grammar", this
attribute only needs to be defined under <interpretation> if it
is necessary to override the x-model specification at the
<interpretation> level.) (optional)
Interpretations must be sorted best-first by some measure of
"goodness". The goodness measure is "confidence" if present,
otherwise, it is some platform-specific indication of quality.
The x-model and grammar are expected to be specified most frequently
at the <result> level, because most often one data model will be
sufficient for the entire result. However, it can be overridden at
the <interpretation> level because it is possible that different
interpretations may have different data models - perhaps because
they match different grammar rules.
The <interpretation> element includes an optional <input> element
which contains the input being analyzed, and an <instance> element
containing the interpretation of the utterance.
<interpretation confidence="75" grammar="http://grammar"
x-model="http://dataModel">
...
</interpretation>
S Shanmugham IETF-Draft Page 79
MRCPv2 Protocol February, 2005
INSTANCE Element
The <instance> element contains the interpretation of the utterance.
If a reference to a data model is present (that is, if there is an
"x-model" attribute on the <result> or <interpretation> elements),
the markup describing the instance should conform to that data
model. When there is semantic markup in the grammar that does not
create semantic objects, but instead only does a semantic
translation of a portion of the input, such as translating "coke" to
"coca-cola", the instance contains the whole input but with the
translation applied. The NLSML looks like in example 2 below. If
there is no semantic objects created, nor any semantic translation
the instance value is the same as the input value.
Attributes:
1. confidence: Each element of the instance may have a confidence
attribute, defined in the NL semantics namespace. The
confidence attribute contains an integer value in the range
from 0-100 reflecting the system's confidence in the analysis
of that slot. The meaning of confidence scores has not been
defined in a platform-independent way. The default value of
"confidence" is 100. (optional)
Example 1:
<instance name="nameAddress">
<nameAddress>
<street confidence="75">123 Maple Street</street>
<city>Mill Valley</city>
<state>CA</state>
<zip>90952</zip>
</nameAddress>
</instance>
<input>
My address is 123 Maple Street,
Mill Valley, California, 90952
</input>
Example 2:
<instance>
I would like to buy a coca-cola
</instance>
<input>
I would like buy a coke
</input>
INPUT Element
S Shanmugham IETF-Draft Page 80
MRCPv2 Protocol February, 2005
The <input> element is the text representation of a user's input. It
includes an optional "confidence" attribute which indicates the
recognizer's confidence in the recognition result (as opposed to the
confidence in the interpretation, which is indicated by the
"confidence" attribute of <interpretation>). Optional "timestamp-
start" and "timestamp-end" attributes indicate the start and end
times of a spoken utterance, in ISO 8601 format.
Attributes:
1. timestamp-start: The time at which the input began. (optional)
2. timestamp-end: The time at which the input ended. (optional)
3. mode: The modality of the input, for example, speech, dtmf,
etc. (optional)
4. confidence: the confidence of the recognizer in the correctness
of the input in the range 0.0 to 1.0 (optional)
Note that it may not make sense for temporally overlapping inputs to
have the same mode; however, this constraint is not expected to be
enforced by platforms.
When there is no time zone designator, ISO 8601 time representations
default to local time.
There are three possible formats for the <input> element.
a) The <input> element can contain simple text:
<input>onions</input>
A future possibility is for <input> to contain not only text but
additional markup that represents prosodic information that was
contained in the original utterance and extracted by the speech
recognizer. This depends on the availability of ASR's that are
capable of producing prosodic information.
b) An <input> tag can also contain additional <input> tags. Having
additional input elements allows the representation to support
future multi-modal inputs as well as finer-grained speech
information, such as timestamps for individual words and word-
level confidences.
<input>
<input mode="speech" confidence="0.5"
timestamp-start="2000-04-03T0:00:00"
timestamp-end="2000-04-03T0:00:00.2">fried</input>
<input mode="speech" confidence="1.0"
timestamp-start="2000-04-03T0:00:00.25"
S Shanmugham IETF-Draft Page 81
MRCPv2 Protocol February, 2005
timestamp-end="2000-04-03T0:00:00.6">onions</input>
</input>
c) Finally, the <interpretation> element can contain <nomatch> and
<noinput> elements, which describe situations in which the speech
recognizer (or other media interpreter) received input that it was
unable to process, or did not receive any input at all,
respectively.
NOMATCH Element
The <nomatch> element under <input> is used to indicate that the
semantic interpreter was unable to successfully match any input with
confidence above the threshold. It can optionally contain the text
of the best of the (rejected) matches.
<interpretation>
<instance/>
<input confidence="0.1">
<nomatch/>
</input>
</interpretation>
<interpretation>
<instance/>
<input mode="speech" confidence="0.1">
<nomatch>I want to go to New York</nomatch>
</input>
</interpretation>
NOINPUT Element
<noinput> indicates that there was no input-- a timeout occurred in
the speech recognizer due to silence.
<interpretation>
<instance/>
<input>
<noinput/>
</input>
</interpretation>
If there are multiple levels of inputs, it appears that the most
natural place for <nomatch> and <noinput> elements is under the
highest level of <input> for <no input>, and under the appropriate
level of <interpretation> for <nomatch>. So <noinput> means "no
input at all" and <nomatch> means "no match in speech modality" or
"no match in dtmf modality". For example, to represent garbled
speech combined with dtmf "1 2 3 4", we would have the following:
<input>
<input mode="speech"><nomatch/></input>
S Shanmugham IETF-Draft Page 82
MRCPv2 Protocol February, 2005
<input mode="dtmf">1 2 3 4</input>
</input>
While <noinput> could be represented as an attribute of input,
<nomatch> cannot, since it could potentially include PCDATA content
with the best match. For parallelism, <noinput> is also an element.
9.7. Enrollment Results
It will contain the following elements/tags to provide information
associated with the voice enrollment.
1. Num-Clashes
2. Num-Good-Repetitions
3. Num-Repetitions-Still-Needed
4. Consistency-Status
5. Clash-Phrase-Ids
6. Transcriptions
7. Confusable-Phrases
1. Num-Clashes
This is not a header field, but part of the recognition results. It
is returned in a RECOGNITION-COMPLETE event. Its value represents
the number of clashes that this pronunciation has with other
pronunciations in an active enrollment session. The header field
Clash-Threshold determines the sensitivity of the clash measurement.
Clash testing can be turned off completely by setting Clash-
Threshold to 0.
num-clashes = "<num-clashes>" 1*DIGIT "</num-clashes>" CRLF
2. Num-Good-Repetitions
This is not a header field, but part of the recognition results. It
is returned in a RECOGNITION-COMPLETE event. Its value represents
the number of consistent pronunciations obtained so far in an active
enrollment session.
num-good-repetitions = "<num-good-repetitions>" 1*DIGIT
"</num-good-repetitions>" CRLF
3. Num-Repetitions-Still-Needed
This is not a header field, but part of the recognition results. It
is returned in a RECOGNITION-COMPLETE event. Its value represents
the number of consistent pronunciations that must still be obtained
before the new phrase can be added to the enrollment grammar. The
number of consistent pronunciations required is determined by the
S Shanmugham IETF-Draft Page 83
MRCPv2 Protocol February, 2005
header Num-Min-Consistent-Pronunciations, whose default value is
two. The returned value must be 0 before the system will allow you
to end an enrollment session for a new phrase.
num-repetitions-still-needed =
"<num-repetitions-still-needed>" 1*DIGIT
"</num-repetitions-still-needed>" CRLF
4. Consistency-Status
This is not a header field, but part of the recognition results. It
is returned in a RECOGNITION-COMPLETE event. This is used to
indicate how consistent the repetitions are when learning a new
phrase. It can have the values of CONSISTENT, INCONSISTENT and
UNDECIDED.
consistency-status = "<consistency-status>" 1*ALPHA
"</consistency-status>" CRLF
5. Clash-Phrase-Ids
This is not a header field, but part of the recognition results. It
is returned in a RECOGNITION-COMPLETE event. This gets filled with
the phrase ids of the clashing pronunciation(s). This field is
absent if there are no clashes. This MAY occur in RECOGNITION-
COMPLETE events.
phrase-id = "<item>" 1*ALPHA "</item>" CRLF
clash-phrase-ids = "<clash-phrase-ids>" 1*phrase-id
"</clash-phrase-ids>" CRLF
6. Transcriptions
This is not a header field, but part of the recognition results. It
is optionally returned in a RECOGNITION-COMPLETE event. This gets
filled with the transcriptions returned in the last repetition of
the phrase being enrolled. This MAY occur in RECOGNITION-COMPLETE
events.
transcription = "<item>" 1*OCTET "</item>" CRLF
transcriptions = "<transcriptions>" 1*transcription
"</transcriptions>" CRLF
7. Confusable-Phrases
This is not a header field, but part of the recognition results. It
is optionally returned in a RECOGNITION-COMPLETE event. This gets
S Shanmugham IETF-Draft Page 84
MRCPv2 Protocol February, 2005
filled with the list of phrases from a command grammar that are
confusable with the phrase being added to the personal grammar.
This MAY occur in RECOGNITION-COMPLETE events.
Confusable-phrase = "<item>" 1*OCTET "</item>" CRLF
confusable-phrases = "<confusable-phrases>" 1*confusable-phrase
"</confusable-phrases>" CRLF
9.8. DEFINE-GRAMMAR
The DEFINE-GRAMMAR method, from the client to the server, provides a
grammar and tells the server to define, download if needed and
compile the grammar.
If the server resource is in the recognition state, the DEFINE-
GRAMMAR request MUST respond with a failure status.
If the resource is in the idle state and is able to successfully
load and compile the grammar the status MUST return a success code
and the request-state MUST be COMPLETE.
If the recognizer could not define the grammar for some reason, say
the download failed or the grammar failed to compile, or the grammar
was in an unsupported form, the MRCPv2 response for the DEFINE-
GRAMMAR method MUST contain a failure status code of 407, and a
completion-cause header field describing the failure reason.
Example:
C->S:MRCP/2.0 589 DEFINE-GRAMMAR 543257
Channel-Identifier: 32AECB23433801@speechrecog
Content-Type: application/srgs+xml
Content-Id: <request1@form-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
S Shanmugham IETF-Draft Page 85
MRCPv2 Protocol February, 2005
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C:MRCP/2.0 73 543257 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
C->S:MRCP/2.0 334 DEFINE-GRAMMAR 543258
Channel-Identifier: 32AECB23433801@speechrecog
Content-Type: application/srgs+xml
Content-Id: <helpgrammar@root-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<rule id="request">
I need help
</rule>
S->C:MRCP/2.0 73 543258 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
C->S:MRCP/2.0 723 DEFINE-GRAMMAR 543259
Channel-Identifier: 32AECB23433801@speechrecog
Content-Type: application/srgs+xml
Content-Id: <request2@field-level.store>
Content-Length: 104
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
"http://www.w3.org/TR/speech-
grammar/grammar.dtd">
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/06/grammar
http://www.w3.org/TR/speech-grammar/grammar.xsd"
version="1.0" mode="voice" root="basicCmd">
S Shanmugham IETF-Draft Page 86
MRCPv2 Protocol February, 2005
<meta name="author" content="Stephanie Williams"/>
<rule id="basicCmd" scope="public">
<example> please move the window </example>
<example> open a file </example>
<ruleref
uri="http://grammar.example.com/politeness.grxml#startPo
lite"/>
<ruleref uri="#command"/>
<ruleref
uri="http://grammar.example.com/politeness.grxml#endPoli
te"/>
</rule>
<rule id="command">
<ruleref uri="#action"/> <ruleref uri="#object"/>
</rule>
<rule id="action">
<one-of>
<item weight="10"> open <tag>TAG-CONTENT-1</tag>
</item>
<item weight="2"> close <tag>TAG-CONTENT-2</tag>
</item>
<item weight="1"> delete <tag>TAG-CONTENT-3</tag>
</item>
<item weight="1"> move <tag>TAG-CONTENT-4</tag>
</item>
</one-of>
</rule>
<rule id="object">
<item repeat="0-1">
<one-of>
<item> the </item>
<item> a </item>
</one-of>
</item>
<one-of>
<item> window </item>
<item> file </item>
<item> menu </item>
</one-of>
</rule>
</grammar>
S Shanmugham IETF-Draft Page 87
MRCPv2 Protocol February, 2005
S->C:MRCP/2.0 69 543259 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
C->S:MRCP/2.0 155 RECOGNIZE 543260
Channel-Identifier: 32AECB23433801@speechrecog
N-Best-List-Length: 2
Content-Type: text/uri-list
Content-Length: 176
session:request1@form-level.store
session:request2@field-level.store
session:helpgramar@root-level.store
S->C:MRCP/2.0 48 543260 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
S->C:MRCP/2.0 48 START-OF-SPEECH 543260 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
S->C:MRCP/2.0 486 RECOGNITION-COMPLETE 543260 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
Waveform-URI: http://web.media.com/session123/audio.wav
Content-Type: applicationt/x-nlsml
Content-Length: 276
<?xml version="1.0"?>
<result grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
9.9. RECOGNIZE
The RECOGNIZE method from the client to the server tells the
recognizer to start recognition and provides it with a grammar to
match for. The RECOGNIZE method can carry headers to control the
sensitivity, confidence level and the level of detail in results
provided by the recognizer. These headers override the current
defaults set by a previous SET-PARAMS method.
S Shanmugham IETF-Draft Page 88
MRCPv2 Protocol February, 2005
The RECOGNIZE method can be started in normal or hotword mode, and
is specified by the Recognition-Mode header field. The default value
is "normal".
The RECOGNIZE method MUST carry the grammars that need to be
activated for that RECOGNIZE method, in its message body. The
grammars that need to be activated can be specified in one of 3
ways. The grammar content could be specified as a mime-content in
the message body. It could be a simple list of grammar URIs
specified in a mime-content of type text/uri-list, in which case the
order of the URI refer to the precedence order of the grammars
during the recognize. Or it could specified using a One-Of-Rule-Id-
URI header field in the message, which refers to a specific <one-of>
rule-id that should be available in the grammar specified in the
body of the message.
Note that the recognizer may also enroll the collected utterance in
a personal grammar if the Enroll-utterance header field is set to
true and an Enrollment is active (via an earlier execution of the
START-PHRASE-ENROLLMENT method). If so, and if the RECOGNIZE request
contains a Content-Id header field then the resulting grammar (which
includes the personal grammar as a sub-grammar) can be referenced
from elsewhere by using "session:foo", where "foo" is the value of
the Content-Id header field.
If the resource is in the recognizing state, the RECOGNIZE request
MUST respond with a failure status. If the resource is in the Idle
state and was able to successfully start the recognition, the server
MUST return a success code and a request-state of IN-PROGRESS. This
means that the recognizer is active and that the client should
expect further events with this request-id.
If the resource could not start a recognition, it MUST return a
failure status code of 407 and contain a completion-cause header
field describing the cause of failure.
For the recognizer resource, this is the only request that can
return request-state of IN-PROGRESS, meaning that recognition is in
progress. When the recognition completes by matching one of the
grammar alternatives or by a time-out without a match or for some
other reason, the recognizer resource MUST send the client a
RECOGNITION-COMPLETE event with the result of the recognition and a
request-state of COMPLETE.
For large grammars that can take a long time to compile and for
grammars which are used repeatedly, the client could issue a DEFINE-
GRAMMAR request with the grammar ahead of time. In such a case the
client can issue the RECOGNIZE request and reference the grammar
through the "session:" special URI. This also applies in general if
the client wants to restart recognition with a previous inline
grammar.
S Shanmugham IETF-Draft Page 89
MRCPv2 Protocol February, 2005
Note that since the audio and the messages are carried over separate
communication paths there may be a race condition between the start
of the flow of audio and the receipt of the RECOGNIZE method. For
example, if audio flow is started by the client at the same time as
the RECOGNIZE method is sent, either the audio or the RECOGNIZE will
arrive at the recognizer first. As another example, the client may
chose to continuously send audio to the Server and signal the Server
to recognize using the RECOGNIZE method. A number of mechanisms
exist to resolve this condition and the mechanism chosen is left to
the implementers of recognition resource. The recognizer should
expect the media to start flowing when it receives the recognize
request, and shouldn't buffer anything it receives beforehand.
Example 1:
C->S:MRCP/2.0 479 RECOGNIZE 543257
Channel-Identifier: 32AECB23433801@speechrecog
Confidence-Threshold: 0.9
Content-Type: application/srgs+xml
Content-Id: <request1@form-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C:MRCP/2.0 48 543257 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
S->C:MRCP/2.0 49 START-OF-SPEECH 543257 IN-PROGRESS
S Shanmugham IETF-Draft Page 90
MRCPv2 Protocol February, 2005
Channel-Identifier: 32AECB23433801@speechrecog
S->C:MRCP/2.0 467 RECOGNITION-COMPLETE 543257 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
Waveform-URI: http://web.media.com/session123/audio.wav
Content-Type: application/nlsml+xml
Content-Length: 276
<?xml version="1.0"?>
<result grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
Example 2:
C->S:MRCP/2.0 479 RECOGNIZE 543257
Channel-Identifier: 32AECB23433801@speechrecog
Confidence-Threshold: 0.9
Fetch-Timeout:20
One-Of-URI-Rule-Id:rule_list
Content-Type: application/srgs+xml
Content-Length: 176
<?xml version="1.0"? version="1.0" mode="voice"
root="basicCmd">
<rule id="rule_list" scope="public">
<one-of>
<item weight=10>
<ruleref uri=
"http://grammar.example.com/world-cities.grxml#canada"/>
</item>
<item weight=1.5>
<ruleref uri=
"http://grammar.example.com/world-cities.grxml#america"/>
</item>
<item weight=0.5>
<ruleref uri=
"http://grammar.example.com/world-cities.grxml#india"/>
</item>
</one-of>
</rule>
9.10. STOP
S Shanmugham IETF-Draft Page 91
MRCPv2 Protocol February, 2005
The STOP method from the client to the server tells the resource to
stop recognition if one is active. If a RECOGNIZE request is active
and the STOP request successfully terminated it, then the response
header contains an active-request-id-list header field containing
the request-id of the RECOGNIZE request that was terminated. In this
case, no RECOGNITION-COMPLETE event will be sent for the terminated
request. If there was no recognition active, then the response MUST
NOT contain an active-request-id-list header field. Either way the
response MUST contain a status of 200(Success).
Example:
C->S:MRCP/2.0 573 RECOGNIZE 543257
Channel-Identifier: 32AECB23433801@speechrecog
Confidence-Threshold: 0.9
Content-Type: application/srgs+xml
Content-Id: <request1@form-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C:MRCP/2.0 47 543257 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
C->S:MRCP/2.0 28 STOP 543258 200
Channel-Identifier: 32AECB23433801@speechrecog
S->C:MRCP/2.0 67 543258 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Active-Request-Id-List: 543257
S Shanmugham IETF-Draft Page 92
MRCPv2 Protocol February, 2005
9.11. GET-RESULT
The GET-RESULT method from the client to the server can be issued
when the recognizer is in the recognized state. This request allows
the client to retrieve results for a completed recognition. This is
useful if the client decides it wants more alternatives or more
information. When the server receives this request it should re-
compute and return the results according to the recognition
constraints provided in the GET-RESULT request.
The GET-RESULT request could specify constraints like a different
confidence-threshold, or n-best-list-length. This feature is
optional and the automatic speech recognition (ASR) engine may
return a status of unsupported feature.
Example:
C->S:MRCP/2.0 73 GET-RESULT 543257
Channel-Identifier: 32AECB23433801@speechrecog
Confidence-Threshold: 0.9
S->C:MRCP/2.0 487 543257 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Content-Type: application/nlsml+xml
Content-Length: 276
<?xml version="1.0"?>
<result grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
9.12. START-OF-SPEECH
This is an event from the recognizer to the client indicating that
it has detected speech or a DTMF digit. This event is useful in
implementing kill-on-barge-in scenarios when the synthesizer
resource is in a different session than the recognizer resource and
hence is not aware of an incoming audio source. In these cases, it
is up to the client to act as a proxy and turn around and issue the
BARGE-IN-OCCURRED method to the synthesizer resource. The recognizer
resource also sends a unique proxy-sync-id in the header for this
event, which is sent to the synthesizer in the BARGE-IN-OCCURRED
method to the synthesizer.
S Shanmugham IETF-Draft Page 93
MRCPv2 Protocol February, 2005
This event should be generated irrespective of whether the
synthesizer and recognizer are on the same server or not.
9.13. START-INPUT-TIMERS
This request is sent from the client to the recognition resource
when it knows that a kill-on-barge-in prompt has finished playing.
This is useful in the scenario when the recognition and synthesizer
engines are not in the same session. Here when a kill-on-barge-in
prompt is being played, you want the RECOGNIZE request to be
simultaneously active so that it can detect and implement kill on
barge-in. But at the same time you don't want the recognizer to
start the no-input timers until the prompt is finished. The header
Start-Input-Timers header field in the RECOGNIZE request will allow
the client to say if the timers should be started or not. The
recognizer should not start the timers until the client sends a
START-INPUT-TIMERS method to the recognizer.
9.14. RECOGNITION-COMPLETE
This is an Event from the recognizer resource to the client
indicating that the recognition completed. The recognition result is
sent in the MRCPv2 body of the message. The request-state field MUST
be COMPLETE indicating that this is the last event with that
request-id, and that the request with that request-id is now
complete. The recognizer context still holds the results and the
audio waveform input of that recognition till the next RECOGNIZE
request is issued. A URI to the audio waveform MAY BE returned to
the client in a waveform-uri header field in the RECOGNITION-
COMPLETE event. The client can use this URI to retrieve or playback
the audio.
Note if an enrollment session was active on with the recognizer that
the event can contain recognition or enrollment results depending on
what was spoken.
Example 1:
C->S:MRCP/2.0 487 RECOGNIZE 543257
Channel-Identifier: 32AECB23433801@speechrecog
Confidence-Threshold: 0.9
Content-Type: application/srgs+xml
Content-Id: <request1@form-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
S Shanmugham IETF-Draft Page 94
MRCPv2 Protocol February, 2005
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C:MRCP/2.0 48 543257 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
S->C:MRCP/2.0 49 START-OF-SPEECH 543257 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
S->C:MRCP/2.0 465 RECOGNITION-COMPLETE 543257 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
Waveform-URI: http://web.media.com/session123/audio.wav
Content-Type: application/nlsml+xml
Content-Length: 276
<?xml version="1.0"?>
<result grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
Example 2:
S->C:MRCP/2.0 465 RECOGNITION-COMPLETE 543257 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
S Shanmugham IETF-Draft Page 95
MRCPv2 Protocol February, 2005
Content-Length: 123
<?xml version= "1.0"?>
<result grammar="Personal-Grammar-URI"
xmlns:mrcp="http://www.ietf.org/xml/ns/mrcpv2">
<mrcp:result-type type="ENROLLMENT" />
<mrcp:enrollment-result>
<num-clashes> 2 </num-clashes>
<num-good-repetitions> 1 </num-good-repetitions>
<num-repetitions-still-needed>
1
</num-repetitions-still-needed>
<consistency-status> consistent </consistency-status>
<clash-phrase-ids>
<item> Jeff </item> <item> Andre </item>
</clash-phrase-ids>
<transcriptions>
<item> m ay b r ow k er </item>
<item> m ax r aa k ah </item>
</transcriptions>
<confusable-phrases>
<item>
<phrase> call </phrase>
<confusion-level> 10 </confusion-level>
</item>
</confusable-phrases>
</mrcp:enrollment-result>
</result>
9.15. START-PHRASE-ENROLLMENT
The START-PHRASE-ENROLLMENT method sent from the client to the
server starts a new phrase enrollment session during which the
client may call RECOGNIZE to enroll a new utterance. This consists
of a set of calls to RECOGNIZE in which the caller speaks a phrase
several times so the system can "learn" it. The phrase is then added
to a personal grammar (speaker-trained grammar), and the system can
recognize it later.
Only one phrase enrollment session may be active at a time. The
Personal-Grammar-URI identifies the grammar that is used during
enrollment to store the personal list of phrases. Once RECOGNIZE is
called, the result is returned in a RECOGNITION-COMPLETE event and
may contain either an enrollment result OR a recognition result for
a regular recognition.
Calling END-PHRASE-ENROLLMENT ends the ongoing phrase enrollment
session, which is typically done after a sequence of successful
calls to RECOGNIZE. This method can be called to commit the new
phrase to the personal grammar or to abort the phrase enrollment
session.
S Shanmugham IETF-Draft Page 96
MRCPv2 Protocol February, 2005
The Personal-Grammar-URI, which specifies the grammar to contain the
new enrolled phrase, will be created if it does not exist. Also, the
personal grammar may ONLY contain phrases added via a phrase
enrollment session.
The Phrase-ID passed to this method will be used to identify this
phrase in the grammar and will be returned as the speech input when
doing a RECOGNIZE on the grammar. The Phrase-NL similarly will be
returned in a RECOGNITION-COMPLETE event in the same manner as other
NL in a grammar. The tag-format of this NL is vendor specific.
If the client has specified Save-Best-Waveform as true, then the
response after ending the phrase enrollment session should contain
the location/URI of a recording of the best repetition of the
learned phrase.
Example:
C->S: MRCP/2.0 123 START-PHRASE-ENROLLMENT 543258
Channel-Identifier: 32AECB23433801@speechrecog
Num-Min-Consistent-Pronunciations: 2
Consistency-Threshold: 30
Clash-Threshold: 12
Personal-Grammar-URI: <personal grammar uri>
Phrase-Id: <phrase id>
Phrase-NL: <NL phrase>
Weight: 1
Save-Best-Waveform: true
S->C: MRCP/2.0 49 543258 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
9.16. ENROLLMENT-ROLLBACK
The ENROLLMENT-ROLLBACK method discards the last live utterance from
the RECOGNIZE operation. This method should be invoked when the
caller provides undesirable input such as non-speech noises, side-
speech, commands, utterance from the RECOGNIZE grammar, etc. Note
that this method does not provide a stack of rollback states.
Executing ENROLLMENT-ROLLBACK twice in succession without an
intervening recognition operation has no effect on the second
attempt.
Example:
C->S: MRCP/2.0 49 ENROLLMENT-ROLLBACK 543261
Channel-Identifier: 32AECB23433801@speechrecog
S->C: MRCP/2.0 49 543261 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
S Shanmugham IETF-Draft Page 97
MRCPv2 Protocol February, 2005
9.17. END-PHRASE-ENROLLMENT
The END-PHRASE-ENROLLMENT method can only be called during an active
phrase enrollment session, which was started by calling the method
START-PHRASE-ENROLLMENT. It may NOT be called during an ongoing
RECOGNIZE operation. It should be called when successive calls to
RECOGNIZE have succeeded and Num-Repetitions-Still-Needed has been
returned as 0 in the RECOGNITION-COMPLETE event to commit the new
phrase in the grammar. Alternatively, it can be called by
specifying the Abort-Phrase-Enrollment header to abort the phrase
enrollment session.
If the client has specified Save-Best-Waveform as true in the START-
PHRASE-ENROLLMENT request, then the response should contain the
location/URI of a recording of the best repetition of the learned
phrase.
Example:
C->S: MRCP/2.0 49 END-PHRASE-ENROLLMENT 543262
Channel-Identifier: 32AECB23433801@speechrecog
S->C: MRCP/2.0 123 543262 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Waveform-URI: <waveform uri>
9.18. MODIFY-PHRASE
The MODIFY-PHRASE method sent from the client to the server is used
to change the phrase ID, NL phrase and/or weight for a given phrase
in a personal grammar.
If no fields are supplied then calling this method has no effect and
it is silently ignored.
Example:
C->S: MRCP/2.0 123 MODIFY-PHRASE 543265
Channel-Identifier: 32AECB23433801@speechrecog
Personal-Grammar-URI: <personal grammar uri>
Phrase-Id: <phrase id>
New-Phrase-Id: <new phrase id>
Phrase-NL: <NL phrase>
Weight: 1
S->C: MRCP/2.0 49 543265 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
S Shanmugham IETF-Draft Page 98
MRCPv2 Protocol February, 2005
9.19. DELETE-PHRASE
The DELETE-PHRASE method sent from the client to the server is used
to delete a phase in a personal grammar added through voice
enrollment or text enrollment. If the specified phrase doesn't
exist, this method has no effect and it is silently ignored.
Example:
C->S: MRCP/2.0 123 DELETE-PHRASE 543266
Channel-Identifier: 32AECB23433801@speechrecog
Personal-Grammar-URI: <personal grammar uri>
Phrase-Id: <phrase id>
S->C: MRCP/2.0 49 543266 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
9.20. INTERPRET
The INTERPRET method from the client to the server takes as input an
interpret-text header, containing the text for which the semantic
interpretation is desired, and returns, via the INTERPRETATION-
COMPLETE event, an interpretation result which is very similar to
the one returned from a RECOGNIZE method invocation. Only portions
of the result relevant to acoustic matching are excluded from the
result. The interpret-text header MUST be included in the INTERPRET
request.
Recognizer grammar data is treated in the same way as it is when
issuing a RECOGNIZE method call.
If a RECOGNIZE, RECORD or another INTERPRET operation is already in
progress, invoking this method will cause the response to have a
status code of 402, "Method not valid in this state", and a COMPLETE
request state.
Example:
C->S: MRCP/2.0 123 INTERPRET 543266
Channel-Identifier: 32AECB23433801@speechrecog
Interpret-Text: may I speak to Andre Roy
Content-Type: application/srgs+xml
Content-Id: <request1@form-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
S Shanmugham IETF-Draft Page 99
MRCPv2 Protocol February, 2005
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 49 543266 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
S->C: MRCP/2.0 49 543267 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 276
<?xml version="1.0"?>
<result grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
9.21. INTERPRETATION-COMPLETE
This event from the recognition resource to the client indicates
that the INTERPRET operation is complete. The interpretation result
is sent in the body of the MRCP message. The request state MUST be
set to COMPLETE.
The completion-cause header MUST be included in this event and MUST
be set to an appropriate value from the list of cause codes.
Example:
C->S: MRCP/2.0 123 INTERPRET 543266
Channel-Identifier: 32AECB23433801@speechrecog
Interpret-Text: may I speak to Andre Roy
Content-Type: application/srgs+xml
S Shanmugham IETF-Draft Page 100
MRCPv2 Protocol February, 2005
Content-Id: <request1@form-level.store>
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 49 543266 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
S->C: MRCP/2.0 49 543267 200 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 276
<?xml version="1.0"?>
<result grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
9.22. DTMF Detection
Digits received as DTMF tones will be delivered to the automatic
speech recognition (ASR) engine in the RTP stream according to RFC
2833. The automatic speech recognizer (ASR) MUST support RFC 2833 to
S Shanmugham IETF-Draft Page 101
MRCPv2 Protocol February, 2005
recognize digits and it MAY support recognizing DTMF tones in the
audio.
10. Recorder Resource
This resource captures the received audio and video and stores it as
file. Their main applications would be for capturing speech audio
that may be applied for recognition at a later time or recording
voice or video mails. Both these applications require functionality
above and beyond those specified by protocols such as RTSP such as
Audio End-pointing(i.e detecting speech or silence). Detection of
speech or silence may be required to start or stop recording. The
support for video is optional and is mainly capturing video mails
that may require the speech or audio processing mentioned above.
10.1. Recorder State Machine
Idle Recording
State State
| |
|---------RECORD------->|
| |
|<------STOP------------|
| |
|<--RECORD-COMPLETE-----|
| |
| |--------|
| START-OF-SPEECH |
| |------->|
| |
10.2. Recorder Methods
The recorder supports the following methods.
recorder-Method = "RECORD" ; A
/ "STOP" ; B
/ "START-INPUT-TIMERS" ; C
10.3. Recorder Events
The recorder may generate the following events.
recorder-Event = "START-OF-SPEECH" ; D
/ "RECORD-COMPLETE" ; E
10.4. Recorder Header Fields
S Shanmugham IETF-Draft Page 102
MRCPv2 Protocol February, 2005
A recorder messages may contain header fields containing request
options and information to augment the Method, Response or Event
message it is associated with.
recorder-header = sensitivity-level
/ no-input-timeout
/ completion-cause
/ completion-reason
/ failed-uri
/ failed-uri-cause
/ record-uri
/ media-type
/ max-time
/ final-silence
/ capture-on-speech
/ ver-buffer-utterance
/ start-input-timers
/ new-audio-channel
Header field where s g A B C D E
__________________________________________________________
Sensitivity-Level R o o o - - - -
No-Input-Timeout R o o o - - - -
Completion-Cause R - - - - - - m
Completion-Cause 2XX - - - o - - -
Completion-Cause 4XX - - - m - - -
Completion-Reason R - - - - - - m
Completion-Reason 2XX - - - o - - -
Completion-Reason 4XX - - - m - - -
Start-Input-Timers R - - - o - - -
Fetch-Timeout R o o o - - - -
Failed-URI R - - - - - - o
Failed-URI 4XX - - o - - - -
Failed-URI-Cause R - - - - - - o
Failed-URI-Cause 4XX - - o - - - -
New-Audio-Channel R - - o - - - -
Ver-Buffer-Utterance R - o o o - - - -
Capture-On-Speech R o o o - - - -
Media-Type R - - m - - - -
Max-Time R o o o - - - -
Final-Silence R o o o - - - -
Record-URI R - - m - - - -
Legend: (s) - SET-PARAMS, (g) - GET-PARAMS, (A) - RECORD, (B) -
STOP, (C) - START-TIMERS , (D) - START-OF-SPEECH, (E) - RECORD-
COMPLETE, (o) - Optional(Refer text for further constraints), (m) -
Mandatory, (m) - Mandatory, (R) - Request, (r) - Response
S Shanmugham IETF-Draft Page 103
MRCPv2 Protocol February, 2005
Sensitivity Level
To filter out background noise and not mistake it for speech, the
recorder may support a variable level of sound sensitivity. The
sensitivity-level header allows the client to set this value on the
recorder. This header field MAY occur in RECORD, SET-PARAMS or GET-
PARAMS. A higher value for this field means higher sensitivity. The
default value for this field is platform specific.
sensitivity-level = "Sensitivity-Level" ":" 1*DIGIT CRLF
No Input Timeout
When recorder is started and there is no speech detected for a
certain period of time, the recorder can send a RECORDER-COMPLETE
event to the client and terminate the record operation. The no-
input-timeout header field can set this timeout value. The value is
in milliseconds. This header field MAY occur in RECORD, SET-PARAMS
or GET-PARAMS. The value for this field ranges from 0 to MAXTIMEOUT,
where MAXTIMEOUT is platform specific. The default value for this
field is platform specific.
no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
Completion Cause
This header field MUST be part of a RECORD-COMPLETE, event coming
from the recorder resource to the client. This indicates the reason
behind the RECORD method completion. This header field MUST be sent
in the RECORD responses, if they return with a failure status and a
COMPLETE state.
completion-cause = "Completion-Cause" ":" 1*DIGIT SP
1*VCHAR CRLF
Cause-Code Cause-Name Description
000 success-silence RECORD completed with a silence at
the end
001 success-maxtime RECORD completed after reaching
Maximum recording time specified in
record method.
002 noinput-timeout RECORD failed due to no input
003 uri-failure Failure accessing the record URI.
004 error RECORD request terminated
prematurely due to a recorder error.
Completion Reason
This header field MAY be specified in a RECORD-COMPLETE event coming
from the recorder resource to the client. This contains the reason
S Shanmugham IETF-Draft Page 104
MRCPv2 Protocol February, 2005
text behind the RECORD request completion. This field can be use to
communicate text describing the reason for the failure.
completion-reason = "Completion-Reason" ":"
quoted-string CRLF
Failed URI
When a record method needs to post the audio to an URI and access to
the URI fails, the server SHOULD provide the failed URI in this
header field in the method response.
failed-uri = "Failed-URI" ":" Uri CRLF
Failed URI Cause
When a record method needs to post the audio to an URI and access to
the URI fails, the server SHOULD provide the URI specific or
protocol specific response code through this header field in the
method response. This field has been defined as alphanumeric to
accommodate all protocols, some of which might have a response
string instead of a numeric response code.
failed-uri-cause = "Failed-URI-Cause" ":" 1*alphanum
CRLF
Record URI
When a record method contains this header field the server must
capture the audio and store it. If the header field is empty, it
MUST store it locally and generate a URI that points to it. This URI
is then returned in the STOP response of the RECORD-COMPLETE events.
If the header in the RECORD method specifies a URI the server must
capture and store the audio at that location. If this header field
is not specified in the RECORD message the server MUST capture the
audio and send it in the STOP response or the RECORD-COMPLETE event
as a message body. In the case, the message carrying the audio
content would have this header field with a cid value pointing to
the Content-ID in the message body.
record-uri = "Record-URI" ":" Uri CRLF
Media Type
A RECORD method MUST contain this header field and specifies to the
server the file format in which to store the captured audio or
video.
Media-type = "Media-Type" ":" media-type-value
CRLF
S Shanmugham IETF-Draft Page 105
MRCPv2 Protocol February, 2005
Max Time
When recorder is started this specifies the maximum length of the
recording, calculated from the time the actual capture and store
begins and is not necessarily the time the RECORD method is
recieved. After this time, the recording stops and the server must
return a RECORD-COMPLETE event back to the client and will have a
request-state of "COMPLETE".This header field MAY occur in RECORD,
SET-PARAMS or GET-PARAMS. The value for this field ranges from 0 to
MAXTIMEOUT, where MAXTIMEOUT is platform specific. A value of zero
means infinity and hence the recording will continue until one of
the other stop conditions are met. The default value for this field
is 0.
max-time = "Max-Time" ":" 1*DIGIT CRLF
Final Silence
When recorder is started and the actual capture begins, this header
field specifies the length of silence in the audio that is to be
interpreted as the end of the recording. This header field MAY occur
in RECORD, SET-PARAMS or GET-PARAMS. The value for this field ranges
from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. A value
of zero means infinity and hence the recording will continue until
one of the other stop conditions are met. The default value for this
field is platform specific.
final-silence = "Final-Silence" ":" 1*DIGIT CRLF
Capture On Speech
When recorder is started this header field specifies if the recorder
should start capturing immediately(false) or wait for the end-
pointing functionality to detect speech(true) before it start
capturing. This header field MAY occur in the RECORD, SET-PARAMS or
GET-PARAMS. The value for this field is a Boolean. The default value
for this field is false.
capture-on-speech = "Capture-On-Speech " ":" 1*DIGIT CRLF
Ver-Buffer-Utterance
This header field is the same as the one described for the
Verification resource. This tells the server to buffer the utterance
associated with this recording request into the verification buffer.
Sending this header field is not valid if the verification buffer is
not instantiated for the session. This buffer is shared across
resources within a session and gets instantiated when a verification
resource is added to this session and is released when the resource
is released from the session.
S Shanmugham IETF-Draft Page 106
MRCPv2 Protocol February, 2005
Start Input Timers
This header MAY BE sent as part of the RECORD request. A value of
false tells the recorder resource to start the operation, but not to
start the no-input timer yet. The recorder resource should not start
the timers until the client sends a START-INPUT-TIMERS request to
the recorder resource. This is useful in the scenario when the
recorder and synthesizer resources are not part of the same session.
Here when a kill-on-barge-in prompt is being played, you may want
the RECORD request to be simultaneously active so that it can detect
and implement kill-on-barge-in. But at the same time you don't want
the recorder resource to start the no-input timers until the prompt
is finished. The default value is "true".
start-input-timers = "Start-Input-Timers" ":"
boolean-value CRLF
New Audio Channel
This header field is the same as the one described for the
Recognizer resource.
10.5. Recorder Message Body
The STOP response or the RECORD-COMPLETE events MAY contain a
message body carrying the captured audio. This happens if the RECORD
method did not have a Record-Uri header field in it. In this case,
message carrying the audio content would have a Record-Uri header
field with a cid value pointing to the message part that contains
the recorded audio
10.6. RECORD
The RECORD method moves the recorder resource to the Recording
State. Depending on the header fields specified in the RECORD method
the resource may start recording the audio immediately or wait for
the end pointing functionality to detect speech in the audio. It
then saves the audio to the URI supplied in the recording-uri header
field. If the recording-uri is not specified, the server MUST
capture the media onto a local disk and return a URI pointing to the
recorded audio in the RECORD-COMPLETE event. The server MUST support
HTTP and file URI schemes.
If a RECORD operation is already in progress, invoking this method
will cause the response to have a status code of 402, "Method not
valid in this state", and a COMPLETE request state.
If the recording-uri is not valid, a status code of 404, "Illegal
Value for Header", will be returned in the response. If it is
S Shanmugham IETF-Draft Page 107
MRCPv2 Protocol February, 2005
impossible for the server to create the requested file, a status
code of 407, "Method or Operation Failed", will be returned.
When the recording operation is initiated the response will indicate
an IN-PROGRESS request state. The server MAY generate a subsequent
START-OF-SPEECH event when speech is detected. Upon completion of
the recording operation, the server will generate a RECORDING-
COMPLETE event.
Example:
C->S:MRCP/2.0 386 RECORD 543257
Channel-Identifier: 32AECB23433802@recorder
Record-URI: file://mediaserver/recordings/myfile.wav
Capture-On-Speech: true
Final-Silence: 300
Max-Time: 6000
S->C:MRCP/2.0 48 456234 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@recorder
S->C:MRCP/2/0 49 START-OF-SPEECH 456234 IN-PROGRESS
Channel-Identifier: 32AECB23433802@recorder
S->C:MRCP/2.0 54 RECORDING-COMPLETE 456234 COMPLETE
Channel-Identifier: 32AECB23433802@recorder
Completion-Cause: 000 success-silence
Record-URI: file://mediaserver/recordings/myfile.wav
10.7. STOP
The STOP method moves the recorder from the recording state back to
the idle state. If the recording was a success the STOP response
contains a Record-URI header pointing to the recorded audio file on
the server or to a MIME part in the body of the message containing
the recorded audio file. The STOP method may have a Trim-Length
header field, in which case the specified length of audio is trimmed
from the end of the recording after the stop.
Example:
C->S:MRCP/2.0 386 RECORD 543257
Channel-Identifier: 32AECB23433802@recorder
Record-URI: file://mediaserver/recordings/myfile.wav
Capture-On-Speech: true
Final-Silence: 300
Max-Time: 6000
S->C:MRCP/2.0 48 456234 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@recorder
S Shanmugham IETF-Draft Page 108
MRCPv2 Protocol February, 2005
S->C:MRCP/2/0 49 START-OF-SPEECH 456234 IN-PROGRESS
Channel-Identifier: 32AECB23433802@recorder
C->S:MRCP/2.0 386 STOP 543257
Channel-Identifier: 32AECB23433802@recorder
Trim-Length: 200
S->C:MRCP/2.0 48 456234 200 COMPLETE
Channel-Identifier: 32AECB23433802@recorder
Completion-Cause: 000 success
Record-URI: file://mediaserver/recordings/myfile.wav
10.8. RECORD-COMPLETE
If the recording completes due to no-input, silence after speech or
max-time the server MUST generate the RECORD-COMPLETE event to the
client with a request-state of "COMPLETE". If the recording was a
success the RECORD-COMPLETE event contains a Record-URI header
pointing to the recorded audio file on the server or to a MIME part
in the body of the message containing the recorded audio file.
Example:
C->S:MRCP/2.0 386 RECORD 543257
Channel-Identifier: 32AECB23433802@recorder
Record-URI: file://mediaserver/recordings/myfile.wav
Capture-On-Speech: true
Final-Silence: 300
Max-Time: 6000
S->C:MRCP/2.0 48 456234 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@recorder
S->C:MRCP/2/0 49 START-OF-SPEECH 456234 IN-PROGRESS
Channel-Identifier: 32AECB23433802@recorder
S->C:MRCP/2.0 48 RECORD-COMPLETE 456234 COMPLETE
Channel-Identifier: 32AECB23433802@recorder
Completion-Cause: 000 success
Record-URI: file://mediaserver/recordings/myfile.wav
10.9. START-INPUT-TIMERS
This request is sent from the client to the recorder resource when
it knows that a kill-on-barge-in prompt has finished playing. This
is useful in the scenario when the recorder and synthesizer
resources are not in the same session. Here when a kill-on-barge-in
prompt is being played, you want the RECORD request to be
simultaneously active so that it can detect and implement kill on
barge-in. But at the same time you don't want the recorder resource
S Shanmugham IETF-Draft Page 109
MRCPv2 Protocol February, 2005
to start the no-input timers until the prompt is finished. The
header Start-Input-Timers header field in the RECORD request will
allow the client to say if the timers should be started or not. In
the above case the recorder resource should not start the timers
until the client sends a START-INPUT-TIMERS method to the recorder.
S Shanmugham IETF-Draft Page 110
MRCPv2 Protocol February, 2005
11. Speaker Verification and Identification
This section describes the methods, responses and events needed for
doing Speaker Verification / Identification.
Speaker verification is a voice authentication feature that can be
used to identify the speaker in order to grant the user access to
sensitive information and transactions. To do this, a recorded
utterance is compared to a voiceprint previously stored for that
user. Verification consists of two phases: a designation phase to
establish the claimed identity of the caller and an execution phase
in which a voiceprint is either created (training) or used to
authenticate the claimed identity (verification). The resource name
is 'speakverify'.
Speaker identification identifies the speaker from a set of valid
users, such as family members. It may also be referred to,
sometimes as Multi-Verification. Identification can be performed on
a small set of users or for a large population. This feature is
useful for applications where multiple users share the same account
number, but where the individual speaker must be uniquely identified
from the group. Speaker identification is also done in two phases,
a designation phase and an execution phase.
It is possible for a speaker verification resource to share the same
session as an existing recognizer resource or a speaker verification
session can be set up to operate in standalone mode, without a
recognizer resource sharing the same session. In order to share the
same session, the SDP/SIP INVITE message for the verification
resource MUST also include the recognizer resource request.
Otherwise, an independent verification resource, running on the same
physical server or a separate one, will be set up.
Some of the speaker verification methods, described below, apply
only to a specific mode of operation.
The verification resource supports buffering that allow the user to
buffer the verification data from an utterance and then process this
utterance later. This is different from collecting waveforms and
processing them using the VERIFY method that operates directly on
the incoming audio stream, because this buffering mechanism does not
simply accumulate utterance data to a buffer. This buffer is iwned
by the verification resource but shares write access with other
input resources such as the recognizer and recorder resources. When
both the recognition and verification resources share the same
session, additional information gathered by the recognition resource
may be saved with these buffers to improve verification performance.
This buffer can be cleared by a CLEAR-BUFFER request from the client
and is freed when the resource is 'speakverify' is freed.
S Shanmugham IETF-Draft Page 111
MRCPv2 Protocol February, 2005
11.1. Speaker Verification State Machine
Speaker Verification has a concept of a training or verification
sessions. Starting one of these sessions does not change the state
of the verification resource, i.e. it remains idle. Once a
verification or training session is started, then utterances are
trained or verified by calling the VERIFY or VERIFY-FROM-BUFFER
method. The state of the Speaker Verification resources goes from
IDLE to VERIFYING state each time VERIFY or VERIFY-FROM-BUFFER is
called.
As mentioned above, the verification resource has a verification
buffer associated with it. This allows the buffering of speech
utterances for the purposes of verification, identification or
training from the buffered speech. This buffer is owned by the
verification resource but other input resources such as the
recognition resource or recorder resource share write access to it.
This allows the speech received as part of a recognition or
recording scenario to be later used for verification, identification
or training.
Note that access the buffer is limited to one operation at time.
Hence when resource is doing read, write or delete operation such as
a RECOGNIZE with ver-buffer-utternance turned on, another operation
involving the buffer such a CLEAR-BUFFER would fail with a status of
402.
11.2. Speaker Verification Methods
Speaker Verification supports the following methods.
verification-method = "START-SESSION" ; A
/ "END-SESSION" ; B
/ "QUERY-VOICEPRINT" ; C
/ "DELETE-VOICEPRINT" ; D
/ "VERIFY" ; E
/ "VERIFY-FROM-BUFFER" ; F
/ "VERIFY-ROLLBACK" ; G
/ "STOP" ; H
/ "CLEAR-BUFFER" ; I
/ "START-INPUT-TIMERS" ; J
/ "GET-INTERMEDIATE-RESULT" ; K
These methods allow the client to control the mode and target of
verification or identification operations within the context of a
session. All the verification input cycles that occur within a
session may be used to create, update, or validate against the
voiceprint specified during the session. At the beginning of each
session the verification resource is reset to a known state.
Verification/identification operations can be executed against live
or buffered audio. The verification resource provides methods for
S Shanmugham IETF-Draft Page 112
MRCPv2 Protocol February, 2005
for collecting and evaluating live audio data, and methods for
controlling the verification resource and adjusting its configured
behavior.
There are no specific methods for collecting buffered audio data.
This is accomplished by calling VERIFY, RECOGNIZE or RECORD as
appropriate for the resource, with the header ver-buffer-utterance.
Then, when the following method is called verification is performed
using the set of buffered audio.
1. VERIFY-FROM-BUFFER
The following methods provide controls for verification of live
audio utterances :
1. VERIFY
2. START-INPUT-TIMERS
The following methods provide controls for configuring the
verification resource and for establishing resource states :
1. START-SESSION
2. END-SESSION
3. QUERY-VOICEPRINT
4. DELETE-VOICEPRINT
5. VERIFY-ROLLBACK
6. STOP
7. CLEAR-BUFFER
The following method allows the polling a Verification in progress
for intermediate results.
8. GET-INTERMEDIATE-RESULTS
11.3. Verification Events
Speaker Verification may generate the following events.
verification-event = "VERIFICATION-COMPLETE" ; L
/ "START-OF-SPEECH" ; M
11.4. Verification Header Fields
A Speaker Verification request may contain header fields containing
request options and information to augment the Request, Response or
Event message it is associated with.
verification-header = repository-uri
/ voiceprint-identifier
/ verification-mode
/ adapt-model
S Shanmugham IETF-Draft Page 113
MRCPv2 Protocol February, 2005
/ abort-model
/ security-level
/ num-min-verification-phrases
/ num-max-verification-phrases
/ no-input-timeout
/ save-waveform
/ waveform-uri
/ voiceprint-exists
/ ver-buffer-utterance
/ input-waveform-uri
/ completion-cause
/ completion-reason
/ speech-complete-timeout
/ new-audio-channel
/ abort-verification
/ start-input-timers
Header field where s g A B C D E F G H I J K L M
__________________________________________________________
Repository-URI R - - m - m m - - - - - - - - -
Voiceprint-Identifier R - - m - m m - - - - - - - - -
Verification-Mode R o o o - - - - - - - - - - - -
Adapt-Model R o o o - - - - - - - - - - - -
Abort-Model R - - - o - - - - - - - - - - -
Security-Level R o o o - - - - - - - - - - - -
Num-Min-Verification-P. R o o o - - - - - - - - - - - -
Num-Max-Verification-P. R o o o - - - - - - - - - - - -
No-Input-Timeout R o o - - - - o - - - - - - - -
Save-Waveform R o o - - - - o - - - - - - - -
Waveform-URI R - - - - - - - - - - - - - o -
Input-Waveform-URI R - - - - - - o - - - - - - - -
Ver-Buffer-Utterance R o o - - - - o - - - - - - - -
Completion-Cause R - - - - - - - - - - - - - m -
Completion-Cause 2XX - - - - m m - o - - - - - - -
Completion-Cause 4XX - - - - m m m m - - - - - - -
Completion-Reason R - - - - - - - - - - - - - m -
Completion-Reason 2XX - - - - m m - o - - - - - - -
Completion-Reason 4XX - - - - m m m m - - - - - - -
Start-Input-Timers R - - - - - - o - - - - - - - -
Fetch-Timeout R o o o o - - - - - - - - - - -
Failed-URI R - - - - - - - - - - - - - o -
Failed-URI 4XX - - o o - - - - - - - - - - -
Failed-URI-Cause R - - - - - - - - - - - - - o -
Failed-URI-Cause 4XX - - o o - - - - - - - - - - -
New-Audio-Channel R - - - o - - o - - - o - - - -
Abort-Verification R - - - - - - - - - m - - - - -
Speech-Complete-Timeout R o o - - - - o - - - - - - - -
Voice-Print-Exists 2XX - - - - m m - - - - - - - - -
S Shanmugham IETF-Draft Page 114
MRCPv2 Protocol February, 2005
Legend: (s) - SET-PARAMS, (g) - GET-PARAMS, (A) - START-SESSION,
(B) - END-SESSION, (C) - QUERY-VOICE-PRINT, (D) DELETE-VOICE-PRINT,
(E) - VERIFY, (F) - VERIFY-FROM-BUFFER, (G) - VERIFY-ROLLBACK, (H) -
STOP, (I) - CLEAR-BUFFER, (J) - START-INPUT-TIMERS , (K) - GET-
INTERMEDIATE-RESULTS, (L) - VERIFICATION-COMPLETE, (M) - START-OF-
SPEECH, (o) - Optional(Refer text for further constraints), (m) -
Mandatory, (R) - Request, (r) - Response
Repository-URI
This header specifies the voiceprint repository to be used or
referenced during speaker verification or identification operations.
This header field is required in START-SESSION, QUERY-VOICEPRINT and
DELETE-VOICEPRINT methods.
repository-uri = "Repository-URI" ":" Uri CRLF
Voiceprint-Identifier
This header field specifies the claimed identity for voice
verification applications. The claimed identity may be used to
specify an existing voiceprint or to establish a new voiceprint.
This header field is required in QUERY-VOICEPRINT and DELETE-
VOICEPRINT methods. The Voiceprint-Identifier is required in the
SESSION-START method for verification operations. For Identification
or Multi-Verification operations this header may contain a list of
voice print identifiers separated by semi-colon. For identification
operations you could also specify a voice print group identifier
instead of a list of voice print identifiers. All voice print group
identifiers have an extension of ".vpg". The creation of such group
identifier objects is left to mechanism outside this protocol.
voiceprint-identifier = "Voiceprint-Identifier" ":"
1*VCHAR "." 3VCHAR
*[";" 1*VCHAR "." 3VCHAR] CRLF
Verification-Mode
This header field specifies the mode of the verification resource
and is set in SESSION-START method. Acceptable values indicate
whether the verification session should train a voiceprint ("train")
or verify/identify using an existing voiceprint ("verify").
Training and verification sessions both require the voiceprint
Repository-URI to be specified in the START-SESSION. In many usage
scenarios, however, the system cannot know the speaker's claimed
identity until the speaker says, for example, their account number.
In order to allow the first few utterances of a dialog to be both
recognized and verified, the verification resource on the MRCP
server retains an audio buffer. In this audio buffer, the MRCP
S Shanmugham IETF-Draft Page 115
MRCPv2 Protocol February, 2005
server will accumulate recognized utterances in memory. The
application can later execute a verification method and apply the
buffered utterances to the current verification session. The
buffering methods are used for this purpose. When buffering is used,
subsequent input utterances are added to the audio buffer for later
analysis.
Some voice user interfaces may require additional user input that
should not be analyzed for verification. For example, the user's
input may have been recognized with low confidence and thus require
a confirmation cycle. In such cases, the client should not execute
the VERIFY or VERIFY-FROM-BUFFER methods to collect and analyze the
caller's input. A separate recognizer resource can analyze the
caller's response without any participation on behalf of the
verification resource.
Once the following conditions have been met:
1. Voiceprint identity has been successfully established through the
voiceprint identifier header fields of the -VOICEPRINT method,
and
2. the verification mode has been set to one of "train" or "verify",
the verification resource may begin providing verification
information during verification operations. The verification
resource MUST reach one of the two major states ("train" or
"verify") if the above two conditions hold, or it MUST report an
error condition in the MRCP status code to indicate why the
verification resource is not ready for action.
The value of verification-mode is persistent within a verification
session. Changing the mode to a different value than the previous
setting causes the verification resource to report an error if the
previous setting was either "train" or "verify". If the mode is
changed back to its previous value, the operation may continue.
verification-mode = "Verification-Mode" ":"
verification-mode-string
verification-mode-string = "train"
/ "verify"
Adapt-Model
This header field indicates the desired behavior of the verification
resource after a successful verification execution. If the value of
this header is "true", the audio collected during the verification
session is may be to update the voiceprint to account for ongoing
changes in a speaker's incoming speech characteristics. If the value
is "false" (the default), the voiceprint is not updated with the
latest audio. This header field MAY only occur in START-SESSION
method.
adapt-model = "Adapt-Model" ":" Boolean-value CRLF
S Shanmugham IETF-Draft Page 116
MRCPv2 Protocol February, 2005
Abort-Model
The Abort-Model header field indicates the desired behavior of the
verification resource upon session termination. If the value of this
header is "true", the pending changes to a voiceprint due to
verification training or verification adaptation are discarded. If
the value is "false" (the default), the pending changes for a
training session or a successful verification session are committed
to the voiceprint repository. A value of "true" for Abort-Model
overrides a value of "true" for the Adapt-Model header field. This
header field MAY only occur in END-SESSION method.
abort-model = "Abort-Model" ":" Boolean-value CRLF
Security-Level
The Security-Level header field determines the range of verification
scores in which a decision of 'accepted' may be declared. This
header field MAY occur in SET-PARAMS, GET-PARAMS and START-SESSION
methods. It can be "high" (highest security level), "medium-high",
"medium" (normal security level), "medium-low", or "low" (low
security level). The default value is platform specific.
security-level = "Security-Level" ":" security-level-string CRLF
security-level-string = "high" /
"medium-high" /
"medium" /
"medium-low" /
"low"
Num-Min-Verification-Phrases
The Num-Min-Verification-Phrases header field is used to specify the
minimum number of valid utterances before a positive decision is
given for verification. The value for this header is integer and the
default value is 1. The verification resource should not announce a
decision of 'accepted' unless the Num-Min-Verification-Phrases
utterances are available. The minimum value is 1.
num-min-verification-phrases = "Num-Min-Verification-Phrases" ":"
1*DIGIT CRLF
S Shanmugham IETF-Draft Page 117
MRCPv2 Protocol February, 2005
Num-Max-Verification-Phrases
The Num-Max-Verification-Phrases header field is used to specify the
number of valid utterances required before a decision is forced for
verification. The verification resource MUST NOT return a decision
of 'undecided' once Num-Max-Verification-Phrases have been collected
and used to determine a verification score. The value for this
header is integer and the minimum value is 1.
num-min-verification-phrases = "Num-Max-Verification-Phrases" ":"
1*DIGIT CRLF
No-Input-Timeout
The No-Input-Timeout header field sets the length of time from the
start of the verification timers (see START-INPUT-TIMERS) until the
declaration of a no-input event in the VERIFICATION-COMPLETE server
event message. The value is in milliseconds. This header field MAY
occur in VERIFY, SET-PARAMS or GET-PARAMS. The value for this field
ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific.
The default value for this field is platform specific.
no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
Save-Waveform
This header field allows the client to indicate to the verification
resource that it MUST save the audio stream that was used for
verification/identification. The verification resource MUST then
record the audio and make it available to the client in the form of
a URI returned in the waveform-uri header field in the
VERIFICATION-COMPLETE event. If there was an error in recording the
stream or the audio clip is otherwise not available, the
verification resource MUST return an empty waveform-uri header
field. The default value for this field is "false". This header
field MAY appear in the VERIFY method, but NOT in the VERIFY-FROM-
BUFFER method since it can control whether or not to save the
waveform for live verification / identification operations only.
save-waveform = "Save-Waveform" ":" boolean-value CRLF
Waveform-URI
If the save-waveform header field is set to true, the verification
resource MUST record the incoming audio stream of the verification
into a file and provide a URI for the client to access it. This
header MUST be present in the VERIFICATION-COMPLETE event if the
save-waveform header field is set to true. The URI value of the
S Shanmugham IETF-Draft Page 118
MRCPv2 Protocol February, 2005
header MUST be NULL if there was some error condition preventing the
server from recording. Otherwise, the URI generated by the server
SHOULD be globally unique across the server and all its verification
sessions. The URI SHOULD BE available until the session is torn
down. Since the save-waveform header field applies only to live
verification / identification operations, the waveform-uri will only
be returned in the VERIFICATION-COMPLETE event for live verification
/ identification operations.
waveform-uri = "Waveform-URI" ":" Uri CRLF
Voiceprint-Exists
This header field is returned in a QUERY-VOICEPRINT or DELETE-
VOICEPRINT response. This is the status of the voiceprint specified
in the QUERY-VOICEPRINT method. For the DELETE-VOICEPRINT method
this field indicates the status of the voiceprint as the method
execution started.
voiceprint-exists = "Voiceprint-Exists" ":" Boolean-value CRLF
Ver-Buffer-Utterance
This header field is used to indicate that this utterance could be
later considered for Speaker Verification. This way, an application
can buffer utterances while doing regular recognition or
verification activities and speaker verification can later be
requested on the buffered utterances. This header field is OPTIONAL
in the RECOGNIZE, VERIFY or RECORD method. The default value for
this field is "false".
ver-buffer-utterance = "Ver-Buffer-Utterance" : Boolean-value CRLF
Input-Waveform-Uri
This optional header field specifies an audio file that has to be
processed according to the current verification mode, either to
train the voiceprint or verify the user. This enables the client to
implement the buffering use case also in the case where the
recognizer and verification resources live in two sessions. It MAY
be part of the VERIFY method.
input-waveform-uri = "Input-Waveform-URI" ":" Uri CRLF
Completion-Cause
S Shanmugham IETF-Draft Page 119
MRCPv2 Protocol February, 2005
This header field MUST be part of a VERIFICATION-COMPLETE event
coming from the verification resource to the client. This indicates
the reason behind the VERIFY or VERIFY-FROM-BUFFER method
completion. This header field MUST BE sent in the VERIFY, VERIFY-
FROM-BUFFER, QUERY-VOICEPRINT responses, if they return with a
failure status and a COMPLETE state.
completion-cause = "Completion-Cause" ":" 1*DIGIT SP
1*VCHAR CRLF
Cause-Code Cause-Name Description
000 success VERIFY or VERIFY-FROM-BUFFER
request
completed successfully. The verify
decision can be "accepted",
"rejected", or "undecided".
001 error VERIFY or VERIFY-FROM-BUFFER
Request terminated prematurely due
to a verification resource or
system error.
002 no-input-timeout VERIFY request completed with no
result due to a no-input-timeout.
003 too-much-speech-timeout VERIFY request completed
result due to too much speech
004 speech-too-early VERIFY request completed with no
result due to spoke too soon.
005 buffer-empty VERIFY-FROM-BUFFER request
completed
with no result due to empty buffer.
006 out-of-sequence Verification operation failed due
to out-of-sequence method
invocations. For example calling
VERIFY before QUERY-VOICEPRINT.
007 repository-uri-failure
Failure accessing Repository URI.
008 repository-uri-missing
Repository-uri is not specified.
009 voiceprint-id-missing
Voiceprint-identification is not
specified.
010 voiceprint-id-not-exist
Voiceprint-identification doesn't
exist in the voiceprint repository.
Completion Reason
This header field MAY be specified in a VERIFICATION-COMPLETE event
coming from the verifier resource to the client. This contains the
reason text behind the VERIFY request completion. This field can be
use to communicate text describing the reason for the failure.
S Shanmugham IETF-Draft Page 120
MRCPv2 Protocol February, 2005
completion-reason = "Completion-Reason" ":"
quoted-string CRLF
Speech Complete Timeout
This header field is the same as the one described for the
Recognizer resource.
New Audio Channel
This header field is the same as the one described for the
Recognizer resource.
Abort-Verification
This header field MUST BE sent in a STOP method to indicate if the
current VERIFY method in progress should be aborted or if it should
stop verifying and return the verification results until that point
in time. A value of "true" will abort the request and discard the
results. A value of "false" would stop verification and return the
verification result in the STOP response.
Abort-verification = "Abort-Verification " : Boolean-value CRLF
Start Input Timers
This header MAY BE sent as part of a VERIFY request. A value of
false tells the verification resource to start the VERIFY operation,
but not to start the no-input timer yet. The verification resource
should not start the timers until the client sends a START-INPUT-
TIMERS request to the resource. This is useful in the scenario when
the verifier and synthesizer resources are not part of the same
session. Here when a kill-on-barge-in prompt is being played, you
may want the VERIFY request to be simultaneously active so that it
can detect and implement kill-on-barge-in. But at the same time you
don't want the verification resource to start the no-input timers
until the prompt is finished. The default value is "true".
start-input-timers = "Start-Input-Timers" ":"
boolean-value CRLF
11.5. Verification Result Elements
The verification results will be returned as XML data in a
VERIFICATION-COMPLETE event containing an NLSML document, having a
MIME-type application/nlsml+xml. The XML Schema and DTD for this
portion XML data is provided in a normative form in the Appendix.
MRCP-specific tag additions to this XML result format described in
S Shanmugham IETF-Draft Page 121
MRCPv2 Protocol February, 2005
this section MUST be in the MRCPv2 namespace. In the result
structure, they must either be prefixed by a namespace prefix
declared within the result or must be children of an element
identified as belonging to the respective namespace. For details on
how to use XML Namespaces, see [21]. Section 2 of [21] provides
details on how to declare namespaces and namespace prefixes.
Example 1:
<?xml version="1.0"?>
<result grammar="What-Grammar-URI"
xmlns:mrcp="http://www.ietf.org/xml/ns/mrcpv2">
<mrcp:result-type type="VERIFICATION" />
<mrcp:verification-result>
<voiceprint id="johnsmith">
<adapted> true </adapted>
<incremental>
<num-frames> 50 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.98514 </verification-score>
</incremental>
<cumulative>
<num-frames> 1000 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.91725</verification-score>
</cumulative>
</voiceprint>
<voiceprint id="marysmith">
<cumulative>
<verification-score> 0.93410 </verification-score>
</cumulative>
</voiceprint>
<voiceprint uri="juniorsmith">
<cumulative>
<verification-score> 0.74209 </verification-score>
</cumulative>
</voiceprint>
</mrcp:verification-result>
</result>
Example 2:
<?xml version="1.0"?>
<result grammar="What-Grammar-URI"
xmlns:mrcp="http://www.ietf.org/xml/ns/mrcpv2">
xmlns:xmpl="http://www.example.org/2003/12/mrcpv2">
<mrcp:result-type type="VERIFICATION" />
<mrcp:verification-result>
<voiceprint id="johnsmith">
S Shanmugham IETF-Draft Page 122
MRCPv2 Protocol February, 2005
<incremental>
<num-frames> 50 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<needmoredata> true </needmoredata>
<verification-score> 0.88514 </verification-score>
<xmpl:raspiness> high </xmpl:raspiness>
<xmpl:emotion> sadness </xmpl:emotion>
</incremental>
<cumulative>
<num-frames> 1000 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<needmoredata> false </needmoredata>
<verification-score> 0.9345 </verification-score>
</cumulative>
</voiceprint>
</mrcp:verification-result>
</result>
Enrollment results XML markup can contain the following
elements/tags:
1. Voice-Print
2. Incremental
3. Cumulative
4. Decision
5. Utterance-Length
6. Device
7. Gender
8. Adapted
9. Verification-Score
10. Vendor-Specific-Results
1. VoicePrint
This element in the verification results provides information on how
the speech data matched a single voice print. The result data
returned may have more than one such entity in it in the case of
Identification or Multi-Verification. Each voice-print element and
the XML data within the element describe verification result
information for how well the speech data matched that particular
voice-print. The list of voice-print element data are ordered
according to their cumulative verification match scores, with the
highest as the first.
2. Cumulative
Within each voice-print element there MUST BE a "cumulative" element
with the cumulative scores of how well multiple utterances matched
the voice-print.
S Shanmugham IETF-Draft Page 123
MRCPv2 Protocol February, 2005
3. Incremental
The first voice-print element there MAY contain an "incremental"
element with the incremental scores of how well the last utterance
matched the voice-print.
4. Decision
This element is found within the incremental or cumulative element
within the verification results. Its value indicates the decision
as determined by verification. It can have the values of
"accepted", "rejected" or "undecided".
5. Utterance-Length
This element is found within the incremental or cumulative element
within the verification results. Its value indicates the size of the
last utterance or the cumulated set of utterances in milliseconds.
6. Device
This element is found within the incremental or cumulative element
within the verification results. Its value indicates the apparent
type of device used by the caller as determined by verification. It
can have the values of "cellular-phone", "electret-phone", "carbon-
button-phone" and "unknown".
7. Gender
This element is found within the incremental or cumulative element
within the verification results. Its value indicates the apparent
gender of the speaker as determined by verification. It can have the
values of "male", "female" or "unknown".
8. Adapted
This element is found within the voice-print element within the
verification results. When verification is trying to confirm the
voiceprint, this indicates if the voiceprint has been adapted as a
consequence of analyzing the source utterances. It is not returned
during verification training. The value can be "true" or "false".
9. Verification-Score
This element is found within the incremental or cumulative element
within the verification results. Its value indicates the score of
the last utterance as determined by verification.
During verification, the higher the score the more likely it is that
the speaker is the same one as the one who spoke the voiceprint
utterances. During training, the higher the score the more likely
the speaker is to have spoken all of the analyzed utterances. The
value is a floating point between 0.0 and 1.0. If there are no such
utterances the score is 0. It should be noted that though the value
of the verification score is between 0.0 and 1.0 it should NOT BE
interpreted as a probability value.
S Shanmugham IETF-Draft Page 124
MRCPv2 Protocol February, 2005
11. Vendor-Specific-Results
This section describes the method used to describe vendor specific
results using the xml syntax. Vendor-specific additions to the
default result format MUST belong to the vendor's own namespace. In
the result structure, they must either be prefixed by a namespace
prefix declared within the result or must be children of an element
identified as belonging to the respective namespace.
11.6. START-SESSION
The START-SESSION method starts a Speaker Verification or
Identification session. Execution of this method forces the
verification resource into a known initial state. If this method is
called during an ongoing verification session, the previous session
is implicitly aborted. If this method is invoked when VERIFY or
VERIFY-FROM-BUFFER is active, it would fail with a status code of
402.
Upon completion of the START-SESSION method, the verification
resource MUST terminate any ongoing verification sessions, and clear
any voiceprint designation.
A verification session needs to establish the voice print repository
that will be used as part of this session. This is specified through
the "Repository-URI" header field, in which a URI pointing to the
location of the voiceprint repository is given.
It also establishes the voice-print that is going to be matched or
trained during that verification session through the Voiceprint-
Identifier header field. If this is an Identification session or if
you wanted to do Multi-Verification, this header would contain a
list of semi-colon separated voice print identifiers.
The header field "Adapt-Model" may also be present in the start
session method to indicate whether or not to adapt a voiceprint with
data collected during the session (if the voiceprint verification
phase succeeds). By default the voiceprint model should NOT be
adapted with data from a verification session.
The START-SESION must also establish if the session is for a train
or verify a voice-print. Hence the Verification-Mode header field
MUST BE sent in this method. The value of the "Verification-Mode"
header field MUST be one of either "train" or "verify".
Before a verification/identification resource is started, only
VERIFY-ROLLBACK and generic SET-PARAMS and GET-PARAMS operations can
be performed. The server should return 402(Method not valid in this
state) for all other operations, such as VERIFY, QUERY-VOICEPRINT.
S Shanmugham IETF-Draft Page 125
MRCPv2 Protocol February, 2005
A single session can be active at one time.
Example:
C->S: MRCP/2.0 123 START-SESSION 314161
Channel-Identifier: 32AECB23433801@speakverify
Repository-URI: http://www.example.com/voiceprintdbase/
Voiceprint-Identifier: johnsmith.voiceprint
Adapt-Model: true
S->C: MRCP/2.0 49 314161 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
11.7. END-SESSION
The END-SESSION method terminates an ongoing verification session
and releases the verification voiceprint model in one of three ways:
a. aborting - the voiceprint adaptation or creation may be aborted
so that the voiceprint remains unchanged (or is not created).
b. committing - when terminating a voiceprint training session, the
new voiceprint is committed to the repository.
c. adapting - an existing voiceprint is modified using a successful
verification.
The header field "Abort-Model" may be included in the END-SESSION to
control whether or not to abort any pending changes to the
voiceprint. The default behavior is to commit (not abort) any
pending changes to the designated voiceprint.
The END-SESSION method may be safely executed multiple times without
first executing the START-SESSION method. Any additional executions
of this method without an intervening use of the START-SESSION
method have no effect on the system.
Example:
This example assumes there are a training session or a verification
session in progress.
C->S: MRCP/2.0 123 END-SESSION 314174
Channel-Identifier: 32AECB23433801@speakverify
Abort-Model: true
S->C: MRCP/2.0 49 314174 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
11.8. QUERY-VOICEPRINT
The QUERY-VOICEPRINT method is used to get a status on a particular
voice-print and can be used to find if a voice-print or repository
exists and if its trained.
S Shanmugham IETF-Draft Page 126
MRCPv2 Protocol February, 2005
The response to the QUERY-VOICEPRINT method request will contain an
indication of the status of the designated voiceprint in the
"Voiceprint-Exists" header field, allowing the client to determine
whether to use the current voiceprint for verification, train a new
voiceprint, or choose a different voiceprint.
A Voiceprint is completely specified by providing a repository
location and a voiceprint identifier. The particular voice-print or
identity within the repository is specified by string identifier
unique within the repository. The "Voiceprint-Identity" header field
MUST carry this unique voiceprint identifier within a given
repository.
Example1:
This example assumes a verification session is in progress and the
voiceprint exists in the voiceprint repository.
C->S: MRCP/2.0 123 QUERY-VOICEPRINT 314168
Channel-Identifier: 32AECB23433801@speakverify
Repository-URI: http://www.example.com/voice-prints/
Voiceprint-Identifier: johnsmith.voiceprint
S->C: MRCP/2.0 123 314168 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
Repository-URI: http://www.example.com/voice-prints/
Voiceprint-Identifier: johnsmith.voiceprint
Voiceprint-Exists: true
Example2:
This example assumes that the URI provided in the 'Repository-URI'
header field is a bad URI.
C->S: MRCP/2.0 123 QUERY-VOICEPRINT 314168
Channel-Identifier: 32AECB23433801@speakverify
Repository-URI: http://www.example.com/bad-uri/
Voiceprint-Identifier: johnsmith.voiceprint
S->C: MRCP/2.0 123 314168 405 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
Repository-URI: http://www.example.com/bad-uri/
Voiceprint-Identifier: johnsmith.voiceprint
Completion-Cause: 007 repository-uri-failure
11.9. DELETE-VOICEPRINT
The DELETE-VOICEPRINT method removes a voiceprint from a repository
or speaker identification repository. This method MUST carry
Repository-URI and the Voiceprint-Identifier header fields.
S Shanmugham IETF-Draft Page 127
MRCPv2 Protocol February, 2005
If a voiceprint record doesn't exist, the DELETE-VOICEPRINT method
can silently ignore the message and still return 200 status code.
Example:
This example demonstrates a message to remove a specific voiceprint.
C->S: MRCP/2.0 123 DELETE-VOICEPRINT 314168
Channel-Identifier: 32AECB23433801@speakverify
Repository-URI: http://www.example.com/bad-uri/
Voiceprint-Identifier: johnsmith.voiceprint
S->C: MRCP/2.0 49 314168 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
11.10. VERIFY
The VERIFY method is used to send the utterance's audio stream to
the verification resource, which will then process it according to
the current Verification-Mode, either to train/adapt the voiceprint
or verify/identify the user. If the voiceprint is new or was deleted
by a previous DELETE-VOICEPRINT method, the VERIFY method would
train the voiceprint. If the voiceprint already exits, it is adapted
and not re-trained by the VERIFY command.
When both a recognizer and verification resource share the same
session, the VERIFY method MUST be called prior to calling the
RECOGNIZE method on the recognizer resource. In such cases, server
vendors will know that verification must be enabled for a subsequent
call to RECOGNIZE.
Example:
C->S: MRCP/2.0 49 VERIFY 543260
Channel-Identifier: 32AECB23433801@speakverify
S->C: MRCP/2.0 49 543260 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speakverify
When the VERIFY request is done, the MRCP server should send a
'VERIFICATION-COMPLETE' event to the client.
11.11. VERIFY-FROM-BUFFER
The VERIFY-FROM-BUFFER method begins an ongoing evaluation of the
currently buffered audio against the voiceprint. Only one VERIFY or
VERIFY-FROM-BUFFER method can be active at any one time.
The buffered audio is not consumed by this evaluation operation and
thus VERIFY-FROM-BUFFER may be called multiple times using different
voiceprints.
S Shanmugham IETF-Draft Page 128
MRCPv2 Protocol February, 2005
For VERIFY-FROM-BUFFER method, the server can optionally return an
"IN-PROGRESS" response followed by the "VERIFICATION-COMPLETE"
event.
When the VERIFY-FROM-BUFFER method is invoked and the verification
buffer is in use the server MUST return an IN-PRGORESS response and
waits until the buffer is available for verify processing again. The
verification buffer is owned by the verification resource but shares
write access with other input resources on the same session, such as
recognition and recording. Hence, it is considered to be in use, if
there is a read or write operation such as, a RECORD or RECOGNIZE
with the ver-buffer-utterance header field set to "true", on a
resource that shares this buffer. Note that, if RECORD or RECOGNIZE
command returns with a failure cause code, the VERIFY-FROM-BUFFER
command waiting to process that buffer MUST also fail with a
Completion-Cause of 005 (buffer-empty).
Example:
This example illustrates the usage of some buffering methods. In
this scenario the client first performed a live verification, but
the utterance is rejected. In the meantime, the utterance is also
saved to the audio buffer. Then, another voiceprint is used to do
verification against the audio buffer and the utterance is accepted.
Here, we assume both 'num-min-verification-phrases' and 'num-max-
verification-phrases' are 1.
C->S: MRCP/2.0 123 START-SESSION 314161
Channel-Identifier: 32AECB23433801@speakverify
Adapt-Model: true
Repository-URI: http://www.example.com/voice-prints
Voiceprint-Identifier: johnsmith.voiceprint
S->C: MRCP/2.0 49 314161 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
C->S: MRCP/2.0 123 VERIFY 314162
Channel-Identifier: 32AECB23433801@speakverify
Ver-buffer-utterance: true
S->C: MRCP/2.0 49 314164 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speakverify
S->C: MRCP/2.0 123 VERIFICATION-COMPLETE 314162 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 123
<?xml version="1.0"?>
<result grammar="What-Grammar-URI">
<extensions>
S Shanmugham IETF-Draft Page 129
MRCPv2 Protocol February, 2005
<result-type type="VERIFICATION" />
<verification-result>
<voiceprint id="johnsmith">
<incremental>
<num-frames> 50 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> rejected </decision>
<verification-score> 0.05465 </verification-score>
</incremental>
<cumulative>
<num-frames> 50 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> rejected </decision>
<verification-score> 0.09664 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</extensions>
</result>
C->S: MRCP/2.0 123 QUERY-VOICEPRINT 314163
Channel-Identifier: 32AECB23433801@speakverify
Repository-URI: http://www.example.com/voiceprints/
Voiceprint-Identifier: johnsmith
S->C: MRCP/2.0 123 314163 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
Repository-URI: http://www.example.com/voiceprints/
Voiceprint-Identifier: johnsmith.voiceprint
Voiceprint-Exists: true
C->S: MRCP/2.0 123 START-SESSION 314164
Channel-Identifier: 32AECB23433801@speakverify
Adapt-Model: true
Repository-URI: http://www.example.com/voice-prints
Voiceprint-Identifier: marysmith.voiceprint
S->C: MRCP/2.0 49 314164 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
C->S: MRCP/2.0 123 VERIFY-FROM-BUFFER 314165
Channel-Identifier: 32AECB23433801@speakverify
Verification-Mode: verify
S->C: MRCP/2.0 49 314165 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speakverify
S->C: MRCP/2.0 123 VERIFICATION-COMPLETE 314165 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
S Shanmugham IETF-Draft Page 130
MRCPv2 Protocol February, 2005
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 123
<?xml version="1.0"?>
<result grammar="What-Grammar-URI">
<extensions>
<result-type type="VERIFICATION" />
<verification-result>
<voiceprint id="marysmith">
<incremental>
<num-frames> 50 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.98 </verification-score>
</incremental>
<cumulative>
<num-frames> 50 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.85 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</extensions>
</result>
C->S: MRCP/2.0 49 END-SESSION 314166
Channel-Identifier: 32AECB23433801@speakverify
S->C: MRCP/2.0 49 314166 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
11.12. VERIFY-ROLLBACK
The VERIFY-ROLLBACK method discards the last buffered utterance or
discards the last live utterances (when the mode is "train" or
"verify"). This method should be invoked when the caller provides
undesirable input such as non-speech noises, side-speech, out-of-
grammar utterances, commands, etc. Note that this method does not
provide a stack of rollback states. Executing VERIFY-ROLLBACK twice
in succession without an intervening recognition operation has no
effect on the second attempt.
Example:
C->S: MRCP/2.0 49 VERIFY-ROLLBACK 314165
Channel-Identifier: 32AECB23433801@speakverify
S Shanmugham IETF-Draft Page 131
MRCPv2 Protocol February, 2005
S->C: MRCP/2.0 49 314165 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
11.13. STOP
The STOP method from the client to the server tells the verification
resource to stop the VERIFY or VERIFY-FROM-BUFFER request if one is
active. If such a request is active and the STOP request
successfully terminated it, then the response header contains an
active-request-id-list header field containing the request-id of the
VERIFY or VERIFY-FROM-BUFFER request that was terminated. In this
case, no VERIFICATION-COMPLETE event will be sent for the terminated
request. If there was no verify request active, then the response
MUST NOT contain an active-request-id-list header field. Either way
the response MUST contain a status of 200(Success).
The STOP method can carry a "Abort-Verification" header field which
specifies if the verification result until that point should be
discarded or returned. If this header field is not present or if the
value is "true", the verification result is discarded and STOP
response does not contain any result data. If the field is present
and its value is "false", the STOP_ response MUST contain a
"Completion-Cause" header field and carry the Verification result
data in its body.
An aborted VERIFY request does an automatic roll-back and will not
affect the cumulative score. A VERIFY request that was stopped with
no "Abort-Verification" header field or with the "Abort-
Verification" header field set to "false" will affect cumulative
scores and would need to be explicitly rolled-back if it should not
be considered for cumulative scores.
Example:
This example assumes a voiceprint identity has already been
established.
C->S: MRCP/2.0 123 VERIFY 314177
Channel-Identifier: 32AECB23433801@speakverify
Verification-Mode: verify
S->C: MRCP/2.0 49 314177 200 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speakverify
C->S: MRCP/2.0 49 STOP 314178
Channel-Identifier: 32AECB23433801@speakverify
S->C: MRCP/2.0 123 314178 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
Active-Request-Id-List: 314177
S Shanmugham IETF-Draft Page 132
MRCPv2 Protocol February, 2005
11.14. START-INPUT-TIMERS
This request is sent from the client to the verification resource to
start the no-input timer, usually once the audio prompts to the
caller have played to completion.
Example:
C->S: MRCP/2.0 49 START-INPUT-TIMERS 543260
Channel-Identifier: 32AECB23433801@speakverify
S->C: MRCP/2.0 49 543260 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
11.15. VERIFICATION-COMPLETE
The VERIFICATION-COMPLETE event follows a call to VERIFY or VERIFY-
FROM-BUFFER and is used to communicate to the client the
verification results. This event will contain only verification
results.
Example:
S->C: MRCP/2.0 123 VERIFICATION-COMPLETE 543259 COMPLETE
Completion-Cause: 000 success
Content-Type: application/nlsml+xml
Content-Length: 123
<?xml version="1.0"?>
<result grammar="What-Grammar-URI">
<extensions>
<result-type type="VERIFICATION" />
<verification-result>
<voiceprint id="johnsmith">
<incremental>
<num-frames> 50 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.85 </verification-score>
</incremental>
<cumulative>
<num-frames> 150 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.75 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</extensions>
</result>
S Shanmugham IETF-Draft Page 133
MRCPv2 Protocol February, 2005
11.16. START-OF-SPEECH
The START-OF-SPEECH event is returned from the server to the client
once the server has detected speech. This event is always returned
by the verification resource when speech has been detected,
irrespective of the fact that both the recognizer and verification
resource are sharing the same session or not.
Example:
S->C: MRCP/2.0 49 START-OF-SPEECH 543259 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speakverify
11.17. CLEAR-BUFFER
The CLEAR-BUFFER method can be used to clear the verification
buffer. This buffer is used to buffer speech during a recognition,
record or verification operations that may later be used for
verification from buffer. As noted before, the verification resource
is shared by other input resources like, recognizers and recorders.
Hence, a CLEAR-BUFFER would fail if the verification buffer is in
use. This happens when any one of the input resources that shares
this buffer has an active read or write operation such as RECORD,
RECOGNIZE or VERIFY with the ver-buffer-utterance header field set
to "true".
Example:
C->S: MRCP/2.0 49 CLEAR-BUFFER 543260
Channel-Identifier: 32AECB23433801@speakverify
S->C: MRCP/2.0 49 543260 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
11.18. GET-INTERMEDIATE-RESULT
The GET-INTERMEDIATE-RESULT method can be used to poll for
intermediate results of a verification request that is in progress.
This does not change the state of the resource. It just collects the
verification results until that point and returns the information in
the method response. The response to this method will contain only
verification results. The method response MUST NOT contain a
Completion-Cause header field as the request is not complete yet.
If the resource does not have a verification in progress the
response would have a 402 failure code and no result in the body.
Example:
C->S: MRCP/2.0 49 GET-INTERMEDIATE-RESULTS 543260
Channel-Identifier: 32AECB23433801@speakverify
S->C: MRCP/2.0 49 543260 200 COMPLETE
Channel-Identifier: 32AECB23433801@speakverify
S Shanmugham IETF-Draft Page 134
MRCPv2 Protocol February, 2005
Content-Type: application/nlsml+xml
Content-Length: 123
<?xml version="1.0"?>
<result grammar="What-Grammar-URI">
<extensions>
<result-type type="VERIFICATION" />
<verification-result>
<voiceprint id="marysmith">
<incremental>
<num-frames> 50 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.85 </verification-score>
</incremental>
<cumulative>
<num-frames> 150 </num-frames>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.65 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</extensions>
</result>
12. Security Considerations
The MRCPv2 protocol may carry sensitive information such as account
numbers, passwords etc as well as use media for identification and
verification purposes. For this reason it is important that the
client have the option of secure communication with the server for
both the control messages as well as the media, though the client is
not required to use it. This is achieved by imposing following
requirements on MRCPv2 server implementations. All MRCPv2 servers
MUST implement digest authentication (sip:) and SHOULD implement
sips: in its SIP implementation. All MRCPv2 servers must support TLS
for the transport of control messages between the client and server.
All MRCPv2 servers MUST support Secure Real-Time Transport Protocol
(SRTP) as an option to send and receive media.
13. IANA Considerations
13.1. New registries
This section describes the name spaces (registries) for MRCPv2 that
IANA is requested to create and maintain. Assignment/registration
S Shanmugham IETF-Draft Page 135
MRCPv2 Protocol February, 2005
policies are described in [24] and are consistent with RFC 2434
[25].
MRCPv2 resource types
IANA SHALL create a new name space of "MRCPv2 resource types" with
the initial values that are defined in section 4.2. All maintenance
within and additions to the contents of this name space MUST be
according to the "Standards Action" registration policy.
MRCPv2 methods and events
IANA SHALL create a new name space of "MRCPv2 methods and events"
with the initial values that are defined by the "method-name" BNF in
section 5.1 and the "event-name" BNF in section 5.3. All
maintenance within and additions to the contents of this name space
MUST be according to the "Standards Action" registration policy.
MRCPv2 headers
IANA SHALL create a new name space of "MRCPv2 headers" with the
initial values that are defined by the "message-header" BNF in
section 5. All maintenance within and additions to the contents of
this name space MUST be according to the "Standards Action"
registration policy. Note that the values permitted for the
"Vendor-Specific-Parameters" parameter are managed according to a
different policy. See "MRCPv2 vendor-specific parameters", below.
MRCPv2 status codes
IANA SHALL create a new name space of "MRCPv2 status codes" with the
initial values that are defined in section 5.2. All maintenance
within and additions to the contents of this name space MUST be
according to the "Specification Required with Expert Review"
registration policy.
MRCPv2 vendor-specific parameters
IANA SHALL create a new name space of "MRCPv2 vendor-specific
parameters". All maintenance within and additions to the contents
of this name space MUST be according to the "Hierarchical
Allocation" registration policy as follows. Each name
(corresponding to the "vendor-av-pair-name" BNF production) MUST
satisfy the syntax requirements of Internet Domain Names as
described in section 2.3.1 of RFC 1035 [26] (and as updated or
obsoleted by successive RFCs), with one exception, the order of the
domain names is reversed. For example, a vendor-specific parameter
"foo" by example.com would have the form "com.example.foo". The
first, or top-level domain, is restricted to exactly the set of Top-
Level Internet Domains defined by IANA and will be updated by IANA
S Shanmugham IETF-Draft Page 136
MRCPv2 Protocol February, 2005
when and only when that set changes. The second-level and all
subdomains within the parameter name MUST be allocated according to
the "Expert Review" policy. The Designated Expert MAY decide to
delegate subdomains to the requestor. As a general guideline, the
Designated Expert is encouraged to manage the allocation of
corporate, organizational, or institutional names and delegate all
subdomains accordingly. For example, the Designated Expert MAY
allocate "com.example" and delegate all subdomains of that name to
the organization represented by the Internet domain name
"example.com". For simplicity, the Designated Expert is encouraged
to perform allocations according to the existing allocations of
Internet domain names to organizations, institutions, corporations,
etc.
13.2. NLSML-related registrations
application/nlsml+xml MIME type registration
IANA is requested to register the following MIME type according to
the process defined in RFC 2048 [23].
To: ietf-types@iana.org
Subject: Registration of MIME media type application/nlsml+xml
MIME media type name: application
MIME subtype name: nlsml+xml
Required parameters:
Optional parameters:
"charset": All of the considerations described in RFC3023 also
apply to the application/nlsml+xml media type.
Encoding considerations: All of the considerations described in
RFC3023 also apply to the application/nlsml+xml media type.
Security considerations: As with HTML, NLSML documents contain
links to other data stores (grammars, verification resources, etc.).
Unlike HTML, however, the data stores are not treated as media to be
rendered. Nevertheless, linked files may themselves have security
considerations, which would be those of the individual registered
types. Additionally, this media type has all of the security
considerations described in RFC 3023.
Interoperability considerations: Although an NLSML document is
itself a complete XML document, for a fuller interpretation of the
content a receiver of an NLSML document may wish to access resources
linked to by the document. The inability of an NLSML processor to
access or process such linked resources could result in different
behavior by the ultimate consumer of the data.
S Shanmugham IETF-Draft Page 137
MRCPv2 Protocol February, 2005
Published specification: http://www.ietf.org/internet-drafts/draft-
ietf-speechsc-mrcpv2-06.txt
Applications which use this media type: MRCPv2 clients and servers
Additional information:
Magic number(s): There is no single initial byte sequence that is
always present for NLSML files.
Person & email address to contact for further information: Sarvi
Shanmugham, sarvi@cisco.com
Intended usage: This media type is expected to be used only in
conjunction with MRCPv2.
NLSML XML DTD registration
IANA is requested to register and maintain the following XML Public
ID and DTD. Information provided follows the template in RFC3688
[22].
XML element type: publicid
URI: "-//IETF//DTD NLSML//EN"
Registrant Contact: IESG
XML: See Appendix A.2.1 "NLSML Document Type Definition".
NLSML XML Schema registration
IANA is requested to register and maintain the following XML Schema.
Information provided follows the template in RFC3688 [22].
XML element type: schema
URI: http://www.ietf.org/xml/ns/mrcpv2
Registrant Contact: IESG
XML: See Appendix A.2.1 "NLSML Schema Definition".
NLSML XML Name space registration
IANA is requested to register and maintain the following XML Name
space. Information provided follows the template in RFC3688 [22].
XML element type: ns
S Shanmugham IETF-Draft Page 138
MRCPv2 Protocol February, 2005
URI: http://www.ietf.org/xml/schema/mrcpv2
Registrant Contact: IESG
XML: Please provide pointer to the RFC, when approved.
13.3. session URL scheme registration
IANA is requested to register the following new URI scheme. The
information below follows the template given in RFC 2717 [27].
URL scheme name: "session"
URL scheme syntax: The syntax of this scheme is identical to that
defined for the "cid" scheme in section 2 of RFC 2392 [15].
Character encoding considerations: URL values are limited to the
US-ASCII character set.
Intended usage: The URL is intended to identify a data resource
previously given to the network computing resource. The purpose of
this scheme is to permit access to the specific resource for the
lifetime of the session with the entity storing the resource. The
media type of the resource CAN vary. There is no explicit mechanism
for communication of the media type.
Applications and/or protocols which use this URL scheme name: This
scheme name will be used by MRCPv2 clients and servers.
Interoperability considerations: The character set for URLs is
restricted to US-ASCII. Note that none of the resources are
accessible after the MCRPv2 session ends, hence the name of the
scheme. For clients who establish one MRCPv2 session only for the
entire speech application being implemented this is sufficient, but
clients who create, terminate, and recreate MRCP sessions for
performance or scalability reasons will lose access to resources
established in the earlier session(s).
Security considerations: The URLs defined here provide an
addressing or referencing mechanism only. Given that the
communication channel between client and server is secure, that the
server correctly accesses the resource associated with the URL, and
that the server ensures session-only lifetime and access for each
URL, the only remaining security issues are those of the types of
media referred to by the URL.
Relevant publications: This specification, particularly sections
6.1 "Content-Id", 8.5 "Lexicon Data", 9.5 "Recognizer Grammar Data",
and 9.9 "RECOGNIZE".
Contact for further information: Sarvi Shanmugham, sarvi@cisco.com
S Shanmugham IETF-Draft Page 139
MRCPv2 Protocol February, 2005
Author/Change controller: IESG
13.4. SDP parameter registrations
IANA is requested to register the following SDP parameter values.
The information for each follows the template given in RFC 2327 [6],
Appendix B.
"TCP/MRCPv2" value of the "proto" parameter
Contact name, email address and telephone number: Sarvi Shanmugham,
sarvi@cisco.com, +1.408.902.3875
Name being registered (as it will appear in SDP): TCP/MRCPv2
Long-form name in English: MCRPV2 over TCP
Type of name: proto
Explanation of name: This name represents the MCRPv2 protocol
carried over TCP.
Reference to specification of name: IANA, please include a pointer
here to the current specification when approved as an RFC by the
IESG.
"TCP/TLS/MRCPv2" value of the "proto" parameter
Contact name, email address and telephone number: Sarvi Shanmugham,
sarvi@cisco.com, +1.408.902.3875
Name being registered (as it will appear in SDP): TCP/TLS/MRCPv2
Long-form name in English: MCRPV2 over TLS over TCP
Type of name: proto
Explanation of name: This name represents the MCRPv2 protocol
carried over TLS over TCP.
Reference to specification of name: IANA, please include a pointer
here to the current specification when approved as an RFC by the
IESG.
"resource" value of the "att-field" parameter
Contact name, email address and telephone number: Sarvi Shanmugham,
sarvi@cisco.com, +1.408.902.3875
S Shanmugham IETF-Draft Page 140
MRCPv2 Protocol February, 2005
Attribute name (as it will appear in SDP): resource
Long-form attribute name in English: MRCPv2 resource type
Type of attribute: session-level
Subject to charset attribute?: no
Explanation of attribute: See section 4.2 description and examples
Specification of appropriate attribute values: See section 13.1
"MRCPv2 resources types"
"channel" value of the "att-field" parameter
Contact name, email address and telephone number: Sarvi Shanmugham,
sarvi@cisco.com, +1.408.902.3875
Attribute name (as it will appear in SDP): channel
Long-form attribute name in English: MRCPv2 resource channel
identifier
Type of attribute: session-level
Subject to charset attribute?: no
Explanation of attribute: See section 4.2 description and examples
Specification of appropriate attribute values: See section 4.2 and
the "channel-id" ABNF production in this document.
14. Examples:
14.1. Message Flow
The following is an example of a typical MRCPv2 session of speech
synthesis and recognition between a client and a server.
Opening a session to the MRCPv2 server. This is exchange does not
allocate a resource or setup media. It simply establishes a SIP
session with the MRCPv2 server.
C->S:
INVITE sip:mresources@mediaserver.com SIP/2.0
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
S Shanmugham IETF-Draft Page 141
MRCPv2 Protocol February, 2005
Contact: <sip: sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 142
v=0
o=sarvi 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A session for processing media
c=IN IP4 224.2.17.12/127
S->C:
SIP/2.0 200 OK
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip: sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 131
v=0
o=sarvi 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A session for processing media
c=IN IP4 224.2.17.12/127
C->S:
ACK sip:mrcp@mediaserver.com SIP/2.0
Max-Forwards: 6
To: MediaServer <sip:mrcp@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 ACK
Content-Length: 0
The client requests the server to create synthesizer resource
control channel to do speech synthesis. This also adds a media pipe
to send the generated speech. Note that in this example, the client
request the reuse of an existing MRCPv2 TCP pipe between the client
and the server.
C->S:
INVITE sip:mresources@mediaserver.com SIP/2.0
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sip: sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 142
S Shanmugham IETF-Draft Page 142
MRCPv2 Protocol February, 2005
v=0
o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4
s=SDP Seminar
i=A session for processing media
c=IN IP4 224.2.17.12/127
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=recvonly
a=mid:1
S->C:
SIP/2.0 200 OK
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sip: sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 131
v=0
o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4
s=SDP Seminar
i=A session for processing media
c=IN IP4 224.2.17.12/127
m=application 32416 TCP/MRCPv2
a=setup:passive
a=connection:existing
a=channel:32AECB23433802@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
C->S:
ACK sip:mrcp@mediaserver.com SIP/2.0
Max-Forwards: 6
To: MediaServer <sip:mrcp@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 ACK
Content-Length: 0
S Shanmugham IETF-Draft Page 143
MRCPv2 Protocol February, 2005
This exchange allocates an additional resource control channel for a
recognizer. Since a recognizer would need to receive an audio stream
for recognition, this interaction also updates the audio stream to
sendrecv making it a 2-way audio stream.
C->S:
INVITE sip:mresources@mediaserver.com SIP/2.0
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip: sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 142
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=SDP Seminar
i=A session for processing media
c=IN IP4 224.2.17.12/127
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=recvonly
a=mid:1
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:existing
a=resource:speechrecog
a=cmid:2
m=audio 49180 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendonly
a=mid:2
S->C:
SIP/2.0 200 OK
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip: sarvi@cisco.com>
Content-Type: application/sdp
S Shanmugham IETF-Draft Page 144
MRCPv2 Protocol February, 2005
Content-Length: 131
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=SDP Seminar
i=A session for processing media
c=IN IP4 224.2.17.12/127
m=application 32416 TCP/MRCPv2
a=channel:32AECB23433801@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
m=application 32416 TCP/MRCPv2
a=channel:32AECB23433802@speechrecog
a=cmid:2
m=audio 48260 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=recvonly
a=mid:2
C->S:
ACK sip:mrcp@mediaserver.com SIP/2.0
Max-Forwards: 6
To: MediaServer <sip:mrcp@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314164 ACK
Content-Length: 0
A MRCPv2 SPEAK request initiates speech.
C->S: MRCP/2.0 386 SPEAK 543257
Channel-Identifier: 32AECB23433802@speechsynth
Kill-On-Barge-In: false
Voice-gender: neutral
Voice-category: teenager
Prosody-volume: medium
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
S Shanmugham IETF-Draft Page 145
MRCPv2 Protocol February, 2005
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
<mark name="Stephanie"/>
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C: MRCP/2.0 49 543257 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
The synthesizer hits the special marker in the message to be spoken
and faithfully informs the client of the event.
S->C: MRCP/2.0 46 SPEECH-MARKER 543257 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
Speech-Marker: Stephanie
The synthesizer finishes with the SPEAK request.
S->C: MRCP/2.0 48 SPEAK-COMPLETE 543257 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
The recognizer is issued a request to listen for the customer
choices.
C->S:MRCP/2.0 343 RECOGNIZE 543258
Channel-Identifier: 32AECB23433801@speechrecog
Content-Type: application/srgs+xml
Content-Length: 104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to a rule expansion -->
<rule id="request">
Can I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 49 543258 200 IN-PROGRESS
S Shanmugham IETF-Draft Page 146
MRCPv2 Protocol February, 2005
Channel-Identifier: 32AECB23433801@speechrecog
The client issues the next MRCPv2 SPEAK method. It is generally
RECOMMENDED when playing a prompt to the user with kill-on-barge-in
and asking for input, that the client issue the RECOGNIZE request
ahead of the SPEAK request for optimum performance and user
experience. This way, it is guaranteed that the recognizer is online
before the prompt starts playing and the user's speech will not be
truncated at the beginning (especially for power users).
C->S: MRCP/2.0 289 SPEAK 543259
Channel-Identifier: 32AECB23433802@speechsynth
Kill-On-Barge-In: true
Content-Type: application/ssml+xml
Content-Length: 104
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>Welcome to ABC corporation.</s>
<s>Who would you like Talk to.</s>
</p>
</speak>
S->C: MRCP/2.0 52 543259 200 IN-PROGRESS
Channel-Identifier: 32AECB23433802@speechsynth
Since the last SPEAK request had Kill-On-Barge-In set to "true", the
speech synthesizer is interrupted when the user starts speaking. And
the client is notified.
Now, since the recognition and synthesizer resources are on the same
session, they may have worked with each other to deliver kill-on-
barge-in. Whether the synthesizer and recognizer are in the same
session or not the recognizer MUST generate the START-OF-SPEECH
event to the client.
The client MUST then blindly turn around and issued a BARGE-IN-
OCCURRED method to the synthesizer resource(if a SPEAK request was
active). The synthesizer, if kill-on-barge-in was enabled on the
current SPEAK request, would have then interrupted it and issued a
SPEAK-COMPLETE event to the client.
The completion-cause code differentiates if this is normal
completion or a kill-on-barge-in interruption.
S Shanmugham IETF-Draft Page 147
MRCPv2 Protocol February, 2005
S->C: MRCP/2.0 49 START-OF-SPEECH 543258 IN-PROGRESS
Channel-Identifier: 32AECB23433801@speechrecog
Proxy-Sync-Id: 987654321
C->S: MRCP/2.0 69 BARGE-IN-OCCURRED 543259
Channel-Identifier: 32AECB23433802@speechsynth
Proxy-Sync-Id: 987654321
S->C: MRCP/2.0 72 543259 200 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Active-Request-Id-List: 543258
S->C: MRCP/2.0 73 SPEAK-COMPLETE 543259 COMPLETE
Channel-Identifier: 32AECB23433802@speechsynth
Completion-Cause: 001 barge-in
The recognition resource matched the spoken stream to a grammar and
generated results. The result of the recognition is returned by the
server as part of the RECOGNITION-COMPLETE event.
S->C: MRCP/2.0 412 RECOGNITION-COMPLETE 543258 COMPLETE
Channel-Identifier: 32AECB23433801@speechrecog
Completion-Cause: 000 success
Waveform-URI: http://web.media.com/session123/audio.wav
Content-Type: application/nlsml+xml
Content-Length: 104
<?xml version="1.0"?>
<result grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
When the client wants to tear down the whole session and all its
resources, it MUST issue a SIP BYE to close the SIP session. This
will de-allocate all the control channels and resources allocated
under the session.
C->S:BYE sip:mrcp@mediaserver.com SIP/2.0
Max-Forwards: 6
From: Sarvi <sip:sarvi@cisco.com>;tag=a6c85cf
To: MediaServer <sip:mrcp@mediaserver.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
S Shanmugham IETF-Draft Page 148
MRCPv2 Protocol February, 2005
Content-Length: 0
14.2. Recognition Result Examples
Simple ASR Ambiguity
System: To which city will you be traveling?
User: I want to go to Pittsburgh.
<result grammar="http://flight">
<interpretation confidence="0.6">
<instance>
<airline>
<to_city>Pittsburgh</to_city>
<airline>
<instance>
<input mode="speech">
I want to go to Pittsburgh
</input>
</interpretation>
<interpretation confidence="0.4"
<instance>
<airline>
<to_city>Stockholm</to_city>
</airline>
</instance>
<input>I want to go to Stockholm</input>
</interpretation>
</result>
Mixed Initiative:
System: What would you like?
User: I would like 2 pizzas, one with pepperoni and cheese, one with
sausage and a bottle of coke, to go.
This representation includes an order object which in turn contains
objects named "food_item", "drink_item" and "delivery_method". This
representation assumes there are no ambiguities in the speech or
natural language processing. Note that this representation also
assumes some level of intrasentential anaphora resolution, i.e., to
resolve the two "one's" as "pizza".
<result grammar="http://foodorder">
<interpretation confidence="1.0" >
<instance>
<order>
<food_item confidence="1.0">
<pizza>
<ingredients confidence="1.0">
pepperoni
S Shanmugham IETF-Draft Page 149
MRCPv2 Protocol February, 2005
</ingredients>
<ingredients confidence="1.0">
cheese
</ingredients>
</pizza>
<pizza>
<ingredients>sausage</ingredients>
</pizza>
</food_item>
<drink_item confidence="1.0">
<size>2-liter</size>
</drink_item>
<delivery_method>to go</delivery_method>
</order>
</instance>
<input mode="speech">I would like 2 pizzas,
one with pepperoni and cheese, one with sausage
and a bottle of coke, to go.
</input>
</interpretation>
</result>
DTMF Input
A combination of dtmf input and speech would be represented using
nested input elements. For example:
User: My pin is (dtmf 1 2 3 4)
<input>
<input mode="speech" confidence ="1.0"
timestamp-start="2000-04-03T0:00:00"
timestamp-end="2000-04-03T0:00:01.5">My pin is
</input>
<input mode="dtmf" confidence ="1.0"
timestamp-start="2000-04-03T0:00:01.5"
timestamp-end="2000-04-03T0:00:02.0">1 2 3 4
</input>
</input>
Note that grammars that recognize mixtures of speech and DTMF are
not currently possible in VoiceXML; however this representation may
be needed for other applications of NLSML, and it may be introduced
in future versions of VoiceXML.
Interpreting Meta-Dialog and Meta-Task Utterances
The natural language requires that the semantics specification must
be capable of representing a number of types of meta-dialog and
meta-task utterances (Task-Specific Information/Meta-task
Information Requirements 1-8 and Generic Information about the
S Shanmugham IETF-Draft Page 150
MRCPv2 Protocol February, 2005
Communication Process Requirements 1-6). This specification is
flexible enough so that meta utterances can be represented on an
application-specific basis without defining specific formats in this
specification.
Here are two examples of how meta-task and meta-dialog utterances
might be represented.
System: What toppings do you want on your pizza?
User: What toppings do you have?
<interpretation grammar="http://toppings">
<instance>
<question>
<questioned_item>toppings<questioned_item>
<questioned_property>
availability
</questioned_property>
</question>
</instance>
<input mode="speech">
what toppings do you have?
</input>
</interpretation>
User: slow down.
<interpretation grammar="http://generalCommandsGrammar">
<instance>
<command>
<action>reduce speech rate</action>
<doer>system</doer>
</command>
</instance>
<input mode="speech">slow down</input>
</interpretation>
Anaphora and Deixis
This specification can be used on an application-specific basis to
represent utterances that contain unresolved anaphoric and deictic
references. Anaphoric references, which include pronouns and
definite noun phrases that refer to something that was mentioned in
the preceding linguistic context, and deictic references, which
refer to something that is present in the non-linguistic context,
present similar problems in that there may not be sufficient
unambiguous linguistic context to determine what their exact role in
the interpretation should be. In order to represent unresolved
anaphora and deixis using this specification, one strategy would be
for the developer to define a more surface-oriented representation
that leaves the specific details of the interpretation of the
S Shanmugham IETF-Draft Page 151
MRCPv2 Protocol February, 2005
reference open. (This assumes that a later component is responsible
for actually resolving the reference)
Example: (ignoring the issue of representing the input from the
pointing gesture.)
System: What do you want to drink?
User: I want this (clicks on picture of large root beer.)
<result>
<interpretation>
<instance>
<doer>I</doer>
<action>want</action>
<object>this</object>
</instance>
<input mode="speech">I want this</input>
</interpretation>
</result>
Future versions of the W3C Speech Interface Framework may address
issues of representing resolved anaphora.
Distinguishing Individual Items from Sets with One Member
For programming convenience, it is useful to be able to distinguish
between individual items and sets containing one item in the XML
representation of semantic results. For example, a pizza order might
consist of exactly one pizza, but a pizza might contain zero or more
toppings. Since there is no standard way of marking this distinction
directly in XML, in the current framework, the developer is free to
adopt any conventions that would convey this information in the XML
markup. One strategy would be for the developer to wrap the set of
items in a grouping element, as in the following example.
<order>
<pizza>
<topping-group>
<topping>mushrooms</topping>
</topping-group>
</pizza>
<drink>coke</drink>
</order>
In this example, the programmer can assume that there is supposed to
be exactly one pizza and one drink in the order, but the fact that
there is only one topping is an accident of this particular pizza
order.
S Shanmugham IETF-Draft Page 152
MRCPv2 Protocol February, 2005
If a data model is used this distinction can be made in the data
model by stating that the value of the "maxOccurs" attribute can be
greater than 1.
Extensibility
One of the natural language requirements states that the
specification must be extensible. The specification supports this
requirement because of its flexibility, as discussed in the
discussions of meta utterances and anaphora. NLSML can easily be
used in sophisticated systems to convey application-specific
information that more basic systems would not make use of, for
example defining speech acts. Defining standard representations for
items such as dates, times, etc. could also be done.
Normative Reference
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk. H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
transfer protocol -- HTTP/1.1", RFC 2616, June 1999.
[2] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998
[3] Crocker, D. and P. Overell, "Augmented BNF for syntax
specifications: ABNF", RFC 2234, November 1997.
[4] Rosenberg, J., Schulzrinne, H., Schooler, E., Camarillo, G.,
Johnston, A. Peterson, J., Sparks, R., Handley, M., Schooler,
E., "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[6] Handley, M. and V. Jacobson, "SDP: session description
protocol", RFC 2327, April 1998.
[7] World Wide Web Consortium, "Voice Extensible Markup Language
(VoiceXML) Version 2.0", W3C Recommendation, March 2004.
[8] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
MESSAGES", RFC 822, August 1982.
[9] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[10] World Wide Web Consortium, "Speech Synthesis Markup Language
(SSML) Version 1.0", W3C Recommendation, September 2004.
[11] World Wide Web Consortium, "Speech Recognition Grammar
Specification Version 1.0", W3C Recommendation, March 2004.
S Shanmugham IETF-Draft Page 153
MRCPv2 Protocol February, 2005
[12] Bradner, S., "The Internet Standards Process - Revision 3",
RFC 2026, October 1996
[13] Yergeau, F., "UTF-8, a transformation format of Unicode and
ISO 10646", RFC 2044, October 1996
[14] Freed, N., Borenstein, N., "Multipupose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996
[15] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998
[16] Schulzrinne, H., Petrack, S., "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000
[17] Alvestrand, H., "Tags for the Identification of Languages",
RFC 3066, January 2001
[18] Camarillo, G., Eriksson, G., Holler, J., "Grouping of Media
Lines in the Session Description Protocol (SDP) ", RFC 3388,
December 2002
[19] T. Bray et al., "Namespaces in XML", W3C Recommendation, 14
January 1999.
[20] Yon, D., Camarillo, G., "Connection-Oriented Media Transport
in the Session Description Protocol (SDP)", draft-ietf-
mmusic-sdp-comedia-09.txt, (work in progress), September
2004.
[21] Lenox, J., "Connection-Oriented Media Transport over the
Transport Layer Security(TLS) Protocol in the Session
Description Protocol (SDP)", (work in progress), draft-ietf-
mmusic-comedia-tls-02.txt
[22] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004.
[23] Freed, N., Klensin, J., and Postel, J., "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
[24] Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", (work in progress),
http://www.ietf.org/internet-drafts/draft-narten-iana-
considerations-rfc2434bis-01.txt.
[25] Narten, T. and Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October 1998.
S Shanmugham IETF-Draft Page 154
MRCPv2 Protocol February, 2005
[26] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC 1035, November 1987.
[27] Petke, R. and King, I., "Registration Procedures for URL
Scheme Names", RFC 2717, November 1999.
Appendix
A.1 ABNF Message Definitions
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep whitespace
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
VCHAR = %x21-7E
param = *pchar
quoted-string = SWS DQUOTE *(qdtext / quoted-pair )
DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
quoted-pair = "\" (%x00-09 / %x0B-0C
/ %x0E-7F)
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
/ "+" / "$" / ","
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
unreserved = alphanum / mark
pchar = unreserved / escaped
/ ":" / "@" / "&" / "=" / "+" / "$" / ","
alphanum = ALPHA / DIGIT
S Shanmugham IETF-Draft Page 155
MRCPv2 Protocol February, 2005
escaped = "%" HEXDIG HEXDIG
fragment = *uric
uri = [ absoluteURI / relativeURI ]
[ "#" fragment ]
absoluteURI = scheme ":" ( hier-part / opaque-part )
relativeURI = ( net-path / abs-path / rel-path )
[ "?" query ]
hier-part = ( net-path / abs-path ) [ "?" query ]
net-path = "//" authority [ abs-path ]
abs-path = "/" path-segments
rel-path = rel-segment [ abs-path ]
rel-segment = 1*( unreserved / escaped / ";" / "@"
/ "&" / "=" / "+" / "$" / "," )
opaque-part = uric-no-slash *uric
uric = reserved / unreserved / escaped
uric-no-slash = unreserved / escaped / ";" / "?" / ":"
/ "@" / "&" / "=" / "+" / "$" / ","
path-segments = segment *( "/" segment )
segment = *pchar *( ";" param )
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = srvr / reg-name
srvr = [ [ userinfo "@" ] hostport ]
reg-name = 1*( unreserved / escaped / "$" / ","
/ ";" / ":" / "@" / "&" / "=" / "+" )
query = *uric
userinfo = ( user ) [ ":" password ] "@"
user = 1*( unreserved / escaped
/ user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";"
S Shanmugham IETF-Draft Page 156
MRCPv2 Protocol February, 2005
/ "?" / "/"
password = *( unreserved / escaped
/ "&" / "=" / "+" / "$" / "," )
hostport = host [ ":" port ]
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum / alphanum *( alphanum / "-" )
alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" )
alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::"
[ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
cmid-attribute = "a=cmid:" identification-tag
identification-tag = token
generic-message = start-line
message-header
CRLF
[ message-body ]
message-body = *OCTET
start-line = request-line / status-line / event-line
request-line = mrcp-version SP message-length SP method-name
SP request-id CRLF
status-line = mrcp-version SP message-length SP request-id
SP status-code SP request-state CRLF
S Shanmugham IETF-Draft Page 157
MRCPv2 Protocol February, 2005
event-line = mrcp-version SP message-length SP event-name
SP request-id SP request-state CRLF
method-name = generic-method
/ synthesizer-method
/ recorder-method
/ recognizer-method
/ verifier-method
generic-method = "SET-PARAMS"
/ "GET-PARAMS"
request-state = "COMPLETE"
/ "IN-PROGRESS"
/ "PENDING"
event-name = synthesizer-event
/ recognizer-event
/ recorder-event
/ verifier-event
message-header = 1*(generic-header / resource-header)
resource-header = recognizer-header
/ synthesizer-header
/ recorder-header
/ verifier-header
generic-header = channel-identifier
/ active-request-id-list
/ proxy-sync-id
/ content-id
/ content-type
/ content-length
/ content-base
/ content-location
/ content-encoding
/ cache-control
/ logging-tag
/ vendor-specific
; -- content-id is as defined in RFC 2111, RFC2046 and RFC822
mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT
request-id = 1*DIGIT
status-code = 1*DIGIT
channel-identifier = "Channel-Identifier" ":"
S Shanmugham IETF-Draft Page 158
MRCPv2 Protocol February, 2005
channel-id CRLF
channel-id = 1*HEXDIG "@" 1*VCHAR
active-request-id-list = "Active-Request-Id-List" ":"
request-id *("," request-id) CRLF
proxy-sync-id = "Proxy-Sync-Id" ":" 1*VCHAR CRLF
content-length = "Content-Length" ":" 1*DIGIT CRLF
content-base = "Content-Base" ":" absoluteURI CRLF
content-type = "Content-Type" ":" media-type-value
media-type-value = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token / quoted-string
content-encoding = "Content-Encoding" ":"
*WSP content-coding
*(*WSP "," *WSP content-coding *WSP )
CRLF
content-coding = token
content-location = "Content-Location" ":"
( absoluteURI / relativeURI ) CRLF
cache-control = "Cache-Control" ":"
[*WSP cache-directive
*( *WSP "," *WSP cache-directive *WSP )]
CRLF
cache-directive = "max-age" "=" delta-seconds
/ "max-stale" "=" [ delta-seconds ]
/ "min-fresh" "=" delta-seconds
logging-tag = "Logging-Tag" ":" 1*VCHAR CRLF
vendor-specific = "Vendor-Specific-Parameters" ":"
[vendor-specific-av-pair
S Shanmugham IETF-Draft Page 159
MRCPv2 Protocol February, 2005
*[";" vendor-specific-av-pair]] CRLF
vendor-specific-av-pair = vendor-av-pair-name "="
vendor-av-pair-value
vendor-av-pair-name = 1*VCHAR
vendor-av-pair-value = 1*VCHAR
set-cookie = "Set-Cookie:" cookies CRLF
cookies = cookie *("," *LWS cookie)
cookie = attribute "=" value *(";" cookie-av)
cookie-av = "Comment" "=" value
/ "Domain" "=" value
/ "Max-Age" "=" value
/ "Path" "=" value
/ "Secure"
/ "Version" "=" 1*DIGIT
/ "Age" "=" delta-seconds
set-cookie2 = "Set-Cookie2:" cookies2 CRLF
cookies2 = cookie2 *("," *LWS cookie2)
cookie2 = attribute "=" value *(";" cookie-av2)
cookie-av2 = "Comment" "=" value
/ "CommentURL" "=" DQUOTE uri DQUOTE
/ "Discard"
/ "Domain" "=" value
/ "Max-Age" "=" value
/ "Path" "=" value
/ "Port" [ "=" DQUOTE portlist DQUOTE ]
/ "Secure"
/ "Version" "=" 1*DIGIT
/ "Age" "=" delta-seconds
portlist = portnum *("," *LWS portnum)
portnum = 1*DIGIT
; Synthesizer ABNF
synthesizer-method = "SPEAK"
/ "STOP"
/ "PAUSE"
/ "RESUME"
/ "BARGE-IN-OCCURRED"
S Shanmugham IETF-Draft Page 160
MRCPv2 Protocol February, 2005
/ "CONTROL"
synthesizer-event = "SPEECH-MARKER"
/ "SPEAK-COMPLETE"
synthesizer-header = jump-size
/ kill-on-barge-in
/ speaker-profile
/ completion-cause
/ completion-reason
/ voice-parameter
/ prosody-parameter
/ speech-marker
/ speech-language
/ fetch-hint
/ audio-fetch-hint
/ fetch-timeout
/ failed-uri
/ failed-uri-cause
/ speak-restart
/ speak-length
/ load-lexicon
/ lexicon-search-order
jump-size = "Jump-Size" ":" speech-length-value CRLF
speech-length-value = numeric-speech-length
/ text-speech-length
text-speech-length = 1*ALPHA SP "Tag"
numeric-speech-length = ("+" / "-") 1*DIGIT SP
numeric-speech-unit
numeric-speech-unit = "Second"
/ "Word"
/ "Sentence"
/ "Paragraph"
delta-seconds = 1*DIGIT
kill-on-barge-in = "Kill-On-Barge-In" ":" boolean-value
CRLF
boolean-value = "true" / "false"
speaker-profile = "Speaker-Profile" ":" absoluteURI
CRLF
completion-cause = "Completion-Cause" ":" 1*DIGIT SP
S Shanmugham IETF-Draft Page 161
MRCPv2 Protocol February, 2005
1*VCHAR CRLF
completion-reason = "Completion-Reason" ":"
quoted-string CRLF
voice-parameter = "Voice-" voice-param-name ":"
[voice-param-value] CRLF
voice-param-name = 1*VCHAR
voice-param-value = 1*VCHAR
prosody-parameter = "Prosody-" prosody-param-name ":"
[prosody-param-value] CRLF
prosody-param-name = 1*VCHAR
prosody-param-value = 1*VCHAR
timestamp = "Timestamp" "=" time-stamp-value CRLF
speech-marker = "Speech-Marker" ":" 1*VCHAR
[";" timestamp ] CRLF
speech-language = "Speech-Language" ":" [1*VCHAR] CRLF
fetch-hint = "Fetch-Hint" ":" [1*ALPHA] CRLF
audio-fetch-hint = "Audio-Fetch-Hint" ":" [1*ALPHA] CRLF
fetch-timeout = "Fetch-Timeout" ":" [1*DIGIT] CRLF
failed-uri = "Failed-URI" ":" absoluteURI CRLF
failed-uri-cause = "Failed-URI-Cause" ":" 1*alphanum CRLF
speak-restart = "Speak-Restart" ":" boolean-value CRLF
speak-length = "Speak-Length" ":" speech-length-value
CRLF
load-lexicon = "Load-Lexicon" ":" boolean CRLF
lexicon-search-order = "Lexicon-Search-Order" ":"
absoluteURI *[";" absoluteURI] CRLF
; Recognizer ABNF
recognizer-method = recog-only-method
/ enrollment-method
S Shanmugham IETF-Draft Page 162
MRCPv2 Protocol February, 2005
recog-only-method = "DEFINE-GRAMMAR"
/ "RECOGNIZE"
/ "INTERPRET"
/ "GET-RESULT"
/ "START-INPUT-TIMERS"
/ "STOP"
enrollment-method = "START-PHRASE-ENROLLMENT"
/ "ENROLLMENT-ROLLBACK"
/ "END-PHRASE-ENROLLMENT"
/ "MODIFY-PHRASE"
/ "DELETE-PHRASE"
recognizer-event = "START-OF-SPEECH"
/ "RECOGNITION-COMPLETE"
/ "INTERPRETATION-COMPLETE"
recognizer-header = recog-only-header
/ enrollment-header
recog-only-header = confidence-threshold
/ sensitivity-level
/ speed-vs-accuracy
/ n-best-list-length
/ no-input-timeout
/ recognition-timeout
/ waveform-uri
/ input-waveform-uri
/ completion-cause
/ completion-reason
/ recognizer-context-block
/ start-input-timers
/ speech-complete-timeout
/ speech-incomplete-timeout
/ dtmf-interdigit-timeout
/ dtmf-term-timeout
/ dtmf-term-char
/ fetch-timeout
/ failed-uri
/ failed-uri-cause
/ save-waveform
/ new-audio-channel
/ speech-language
/ ver-buffer-utterance
/ recognition-mode
/ cancel-if-queue
/ hotword-max-duration
/ hotword-min-duration
/ interpret-text
/ one-of-rule-id-uri
S Shanmugham IETF-Draft Page 163
MRCPv2 Protocol February, 2005
enrollment-header = num-min-consistent-pronunciations
/ consistency-threshold
/ clash-threshold
/ personal-grammar-uri
/ phrase-id
/ phrase-nl
/ weight
/ save-best-waveform
/ new-phrase-id
/ confusable-phrases-uri
/ abort-phrase-enrollment
confidence-threshold = "Confidence-Threshold" ":"
[1*DIGIT] CRLF
sensitivity-level = "Sensitivity-Level" ":" [1*DIGIT]
CRLF
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" [1*DIGIT]
CRLF
n-best-list-length = "N-Best-List-Length" ":" [1*DIGIT]
CRLF
no-input-timeout = "No-Input-Timeout" ":" [1*DIGIT]
CRLF
recognition-timeout = "Recognition-Timeout" ":" [1*DIGIT]
CRLF
waveform-uri = "Waveform-URI" ":" absoluteURI CRLF
recognizer-context-block = "Recognizer-Context-Block" ":"
[1*VCHAR] CRLF
start-input-timers = "Start-Input-Timers" ":"
boolean-value CRLF
speech-complete-timeout = "Speech-Complete-Timeout" ":"
[1*DIGIT] CRLF
speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":"
[1*DIGIT] CRLF
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":"
[1*DIGIT] CRLF
dtmf-term-timeout = "DTMF-Term-Timeout" ":" [1*DIGIT]
CRLF
S Shanmugham IETF-Draft Page 164
MRCPv2 Protocol February, 2005
dtmf-term-char = "DTMF-Term-Char" ":" [VCHAR] CRLF
fetch-timeout = "Fetch-Timeout" ":" [1*DIGIT] CRLF
save-waveform = "Save-Waveform" ":" [boolean-value] CRLF
new-audio-channel = "New-Audio-Channel" ":"
boolean-value CRLF
one-of-rule-id-uri = "One-Of-Rule-Id-URI" ":" token CRLF
recognition-mode = "Recognition-Mode" ":" 1*ALPHA CRLF
cancel-if-queue = "Cancel-If-Queue" ":" boolean-value CRLF
hotword-max-duration = "Hotword-Max-Duration" ":"
1*DIGIT CRLF
hotword-min-duration = "Hotword-Min-Duration" ":"
1*DIGIT CRLF
num-min-consistent-pronunciations =
"Num-Min-Consistent-Pronunciations" ":" 1*DIGIT CRLF
consistency-threshold = "Consistency-Threshold" ":" 1*DIGIT
CRLF
clash-threshold = "Clash-Threshold" ":" 1*DIGIT CRLF
personal-grammar-uri = "Personal-Grammar-URI" ":" uri CRLF
phrase-id = "Phrase-ID" ":" 1*VCHAR CRLF
phrase-nl = "Phrase-NL" ":" 1*VCHAR CRLF
weight = "Weight" ":" weight-value CRLF
weight-value = 1*DIGIT
save-best-waveform = "Save-Best-Waveform" ":"
boolean-value CRLF
new-phrase-id = "New-Phrase-ID" ":" 1*VCHAR CRLF
confusable-phrases-uri = "Confusable-Phrases-URI" ":"
uri CRLF
abort-phrase-enrollment = "Abort-Phrase-Enrollment" ":"
boolean-value CRLF
S Shanmugham IETF-Draft Page 165
MRCPv2 Protocol February, 2005
; Verifier ABNF
verifier-method = "START-SESSION"
/ "END-SESSION"
/ "QUERY-VOICEPRINT"
/ "DELETE-VOICEPRINT"
/ "VERIFY"
/ "VERIFY-FROM-BUFFER"
/ "VERIFY-ROLLBACK"
/ "STOP"
/ "START-INPUT-TIMERS"
verifier-event = "VERIFICATION-COMPLETE"
/ "START-OF-SPEECH"
verifier-header = repository-uri
/ voiceprint-identifier
/ verification-mode
/ adapt-model
/ abort-model
/ security-level
/ num-min-verification-phrases
/ num-max-verification-phrases
/ no-input-timeout
/ save-waveform
/ waveform-uri
/ voiceprint-exists
/ ver-buffer-utterance
/ input-waveform-uri
/ completion-cause
/ completion-reason
/ speech-complete-timeout
/ new-audio-channel
/ abort-verification
/ start-input-timers
repository-uri = "Respository-URI" ":" uri CRLF
voiceprint-identifier = "Voiceprint-Identifier" ":"
1*VCHAR "." 3VCHAR
[";" 1*VCHAR "." 3VCHAR] CRLF
verification-mode = "Verification-Mode" ":"
verification-mode-string
S Shanmugham IETF-Draft Page 166
MRCPv2 Protocol February, 2005
verification-mode-string = "train" / "verify"
adapt-model = "Adapt-Model" ":" boolean-value CRLF
abort-model = "Abort-Model" ":" boolean-value CRLF
security-level = "Security-Level" ":"
security-level-string CRLF
security-level-string = "high"
/ "medium-high"
/ "medium"
/ "medium-low"
/ "low"
num-min-verification-phrases = "Num-Min-Verification-Phrases"
":" 1*DIGIT CRLF
num-max-verification-phrases = "Num-Max-Verification-Phrases"
":" 1*DIGIT CRLF
voiceprint-exists = "Voiceprint-Exists" ":"
boolean-value CRLF
ver-buffer-utterance = "Ver-Buffer-Utterance" ":"
boolean-value CRLF
input-waveform-uri = "Input-Waveform-URI" ":" uri CRLF
abort-verification = "Abort-Verification " ":"
boolean-value CRLF
; Recorder ABNF
recorder-method = "RECORD"
/ "STOP"
recorder-event = "START-OF-SPEECH"
/ "RECORD-COMPLETE"
recorder-header = sensitivity-level
/ no-input-timeout
/ completion-cause
/ completion-reason
/ failed-uri
/ failed-uri-cause
/ record-uri
S Shanmugham IETF-Draft Page 167
MRCPv2 Protocol February, 2005
/ media-type
/ max-time
/ final-silence
/ capture-on-speech
/ new-audio-channel
/ start-input-timers
record-uri = "Record-URI" ":" uri CRLF
media-type = "Media-Type" ":" media-type-value CRLF
max-time = "Max-Time" ":" 1*DIGIT CRLF
final-silence = "Final-Silence" ":" 1*DIGIT CRLF
capture-on-speech = "Capture-On-Speech " ":"
1*DIGIT CRLF
A.2 XML Schema and DTD
A.2.1 Recognition Results
NLSML Schema Definition
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.ietf.org/xml/schema/mrcpv2"
xmlns="http://www.ietf.org/xml/ns/mrcpv2"
elementFormDefault="qualified"
attributeFormDefault="unqualified" >
<xs:element name="result">
<xs:annotation>
<xs:documentation> Natural Language Semantic Markup Schema
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="interpretation" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="instance" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:any/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="input">
<xs:complexType mixed="true">
S Shanmugham IETF-Draft Page 168
MRCPv2 Protocol February, 2005
<xs:choice>
<xs:element name="noinput" minOccurs="0"/>
<xs:element name="nomatch" minOccurs="0"/>
<xs:element name="input" minOccurs="0"/>
</xs:choice>
<xs:attribute name="confidence"
type="confidenceinfo"
default="1.0"/>
<xs:attribute name="timestamp-start"
type="xs:string"/>
<xs:attribute name="timestamp-end"
type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="confidence" type="confidenceinfo"
default="1.0"/>
<xs:attribute name="grammar" type="xs:anyURI"
use="optional"/>
<xs:attribute name="x-model" type="xs:anyURI"
use="optional"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="grammar" type="xs:anyURI"
use="optional"/>
<xs:attribute name="x-model" type="xs:anyURI"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="confidenceinfo">
<xs:restriction base="xs:float">
<xs:minInclusive value="0.0"/>
<xs:maxInclusive value="1.0"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
NLSML Document Type Definition
<!-- NLSML Results DTD
-->
<!ELEMENT result (interpretation*)>
<!ATTLIST result
grammar CDATA #IMPLIED
x-model CDATA #IMPLIED
>
<!ELEMENT interpretation (instance,input?)>
<!ATTLIST interpretation
S Shanmugham IETF-Draft Page 169
MRCPv2 Protocol February, 2005
confidence CDATA "1.0"
grammar CDATA #IMPLIED
x-model CDATA #IMPLIED
>
<!ELEMENT input (#PCDATA|noinput|nomatch|input)*>
<!ATTLIST input
mode (dtmf | speech) "speech"
timestamp-start CDATA #IMPLIED
timestamp-end CDATA #IMPLIED
confidence CDATA "1.0"
>
<!ELEMENT nomatch (#PCDATA)*>
<!ELEMENT noinput EMPTY>
<!ELEMENT instance (#PCDATA|EMPTY)*>
A.2.2 Enrollment Results
Enrollment Results Schema Definition
<!-- MRCP Enrollment Schema
(See http://www.oasis-open.org/committees/relax-ng/spec.html)
-->
<element name="enrollment-result"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-
datatypes"
ns="" xmlns="http://relaxng.org/ns/structure/1.0">
<interleave>
<element name="num-clashes">
<data type="nonNegativeInteger"/>
</element>
<element name="num-good-repetitions">
<data type="nonNegativeInteger"/>
</element>
<element name="num-repetitions-still-needed">
<data type="nonNegativeInteger"/>
</element>
<element name="consistency-status">
<choice>
<value>CONSISTENT</value>
<value>INCONSISTENT</value>
<value>UNDECIDED</value>
</choice>
</element>
<optional>
<element name="clash-phrase-ids">
<oneOrMore>
<element name="item">
<data type="token"/>
</element>
</oneOrMore>
</element>
S Shanmugham IETF-Draft Page 170
MRCPv2 Protocol February, 2005
</optional>
<optional>
<element name="transcriptions">
<oneOrMore>
<element name="item">
<text/>
</element>
</oneOrMore>
</element>
</optional>
<optional>
<element name="confusable-phrases">
<oneOrMore>
<element name="item">
<text/>
</element>
</oneOrMore>
</element>
</optional>
</interleave>
</element>
Enrollment Results Document Type Definition
<!-- MRCP Enrollment Results DTD
-->
<!ELEMENT enrollment-result (num-clashes,
num-good-repetitions,num-repetitions-still-needed,
consistency-status, clash-phrase-ids?,
transcriptions?, confusable-phrases?)>
<!ELEMENT num-clashes (#PCDATA)>
<!ELEMENT num-good-repetitions (#PCDATA)>
<!ELEMENT num-repetitions-still-needed (#PCDATA)>
<!ELEMENT consistency-status (#PCDATA)>
<!ELEMENT clash-phrase-ids (item)>
<!ELEMENT transcriptions (item)>
<!ELEMENT confusable-phrases (item)>
<!ELEMENT item (#PCDATA)>
A.2.3 Verification Results
Verification Results Schema Definition
<!-- MRCP Verification Results Schema
(See http://www.oasis-open.org/committees/relax-ng/spec.html)
-->
<grammar datatypeLibrary="http://www.w3.org/2001/XMLSchema-
datatypes"
ns="" xmlns="http://relaxng.org/ns/structure/1.0">
S Shanmugham IETF-Draft Page 171
MRCPv2 Protocol February, 2005
<start>
<element name="verification-result">
<element name="num-frames">
<ref name="num-framesContent"/>
</element>
<element name="voiceprint">
<ref name="firstVoiceprintContent"/>
</element>
<zeroOrMore>
<element name="voiceprint">
<ref name="restVoiceprintContent"/>
</element>
</zeroOrMore>
</element>
</start>
<define name="firstVoiceprintContent">
<attribute name="id">
<data type="string"/>
</attribute>
<interleave>
<optional>
<element name="adapted">
<data type="boolean"/>
</element>
<element name="needmoredata">
<ref name="needmoredataContent"/>
</element>
</optional>
<element name="incremental">
<ref name="firstCommonContent"/>
</element>
<element name="cumulative">
<ref name="firstCommonContent"/>
</element>
</interleave>
</define>
<define name="restVoiceprintContent">
<attribute name="id">
<data type="string"/>
</attribute>
<interleave>
<optional>
<element name="incremental">
<ref name="restCommonContent"/>
</element>
</optional>
<element name="cumulative">
<ref name="restCommonContent"/>
</element>
S Shanmugham IETF-Draft Page 172
MRCPv2 Protocol February, 2005
</interleave>
</define>
<define name="firstCommonContent">
<interleave>
<choice>
<element name="decision">
<ref name="decisionContent"/>
</element>
</choice>
<element name="device">
<ref name="deviceContent"/>
</element>
<element name="gender">
<ref name="genderContent"/>
</element>
<zeroOrMore>
<element name="verification-score">
<ref name="verification-scoreContent"/>
</element>
</zeroOrMore>
</interleave>
</define>
<define name="restCommonContent">
<interleave>
<optional>
<element name="decision">
<ref name="decisionContent"/>
</element>
</optional>
<optional>
<element name="utterance-length">
<ref name="utterance-lengthContent"/>
</element>
</optional>
<optional>
<element name="device">
<ref name="deviceContent"/>
</element>
</optional>
<optional>
<element name="gender">
<ref name="genderContent"/>
</element>
</optional>
<zeroOrMore>
<element name="verification-score">
<ref name="verification-scoreContent"/>
</element>
</zeroOrMore>
S Shanmugham IETF-Draft Page 173
MRCPv2 Protocol February, 2005
</interleave>
</define>
<define name="decisionContent">
<choice>
<value>accepted</value>
<value>rejected</value>
<value>undecided</value>
</choice>
</define>
<define name="needmoredataContent">
<data type="boolean"/>
</define>
<define name="utterance-lengthContent">
<data type="nonNegativeInteger"/>
</define>
<define name="deviceContent">
<choice>
<value>cellular-phone</value>
<value>electret-phone</value>
<value>carbon-button-phone</value>
<value>unknown</value>
</choice>
</define>
<define name="genderContent">
<choice>
<value>male</value>
<value>female</value>
<value>unknown</value>
</choice>
</define>
<define name="verification-scoreContent">
<data type="float">
<param name="minInclusive">0</param>
<param name="maxInclusive">1</param>
</data>
</define>
</grammar>
Verification Results Document Type Definition
<!-- MRCP Verification Results DTD
-->
<!ELEMENT verification-result (voiceprint+)>
<!ELEMENT voiceprint (adapted?, incremental?, cumulative)>
S Shanmugham IETF-Draft Page 174
MRCPv2 Protocol February, 2005
<!ATTLIST voiceprint id CDATA #REQUIRED>
<!ELEMENT incremental ((decision | needmoredata)?,
num-frames?, device?, gender?, verification-score)>
<!ELEMENT cumulative ((decision | needmoredata)?,
num-frames?, device?, gender?, verification-score)>
<!ELEMENT decision (#PCDATA)>
<!ELEMENT needmoredata (#PCDATA)>
<!ELEMENT num-frames (#PCDATA)>
<!ELEMENT device (#PCDATA)>
<!ELEMENT gender (#PCDATA)>
<!ELEMENT adapted (#PCDATA)>
<!ELEMENT verification-score (#PCDATA)>
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
S Shanmugham IETF-Draft Page 175
MRCPv2 Protocol February, 2005
Contributors
Daniel C. Burnett
Nuance Communications
1005 Hamilton Court
Menlo Park, CA 94025-1422
USA
Email: burnett@nuance.com
Pierre Forgues
Nuance Communications Ltd.
111 Duke Street
Suite 4100
Montreal, Quebec
Canada H3C 2M1
Email: forgues@nuance.com
Charles Galles
Intervoice, Inc.
17811 Waterview Parkway
Dallas, Texas 75252
Email: charles.galles@intervoice.com
Klaus Reifenrath
Scansoft, Inc
Guldensporenpark 32
Building D
9820 Merelbeke
Belgium
Email: klaus.reifenrath@scansoft.com
Acknowledgements
Andre Gillet (Nuance Communications)
Andrew Hunt (ScanSoft)
Aaron Kneiss (ScanSoft)
Brian Eberman (ScanSoft)
Corey Stohs (Cisco Systems Inc)
Dan Burnett (Nuance Communications)
Jeff Kusnitz (IBM Corp)
Ganesh N Ramaswamy (IBM Corp)
Klaus Reifenrath (ScanSoft)
Kristian Finlator (ScanSoft)
Martin Dragomirecky (Cisco Systems Inc)
Peter Monaco (Nuance Communications)
Pierre Forgues (Nuance Communications)
S Shanmugham IETF-Draft Page 176
MRCPv2 Protocol February, 2005
Ran Zilca (IBM Corp)
Suresh Kaliannan (Cisco Systems Inc.)
Skip Cave (Intervoice Inc)
Magnus Westerlun (Ericsson)
Thomas Gal (LumenVox)
Dave Burke (VoxPilot)
Paolo Baggia (Loquendo)
Editors' Addresses
Saravanan Shanmugham
Cisco Systems Inc.
170 W Tasman Drive,
San Jose,
CA 95134
Email: sarvi@cisco.com
Daniel C. Burnett
Nuance Communications
1380 Willow Road
Menlo Park, CA 94025
Email: burnett@nuance.com
S Shanmugham IETF-Draft Page 177 | PAFTECH AB 2003-2026 | 2026-04-23 09:38:44 |