[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 RFC 6787

 Internet Engineering Task Force                    Saravanan Shanmugham
 Internet-Draft                                       Cisco Systems Inc.
 draft-ietf-speechsc-mrcpv2-04                             July 19, 2004
 Expires: January 19, 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 January 19, 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                  July 2004
 
 
    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:...............................................5
      3.1.  MRCPv2 Media Resources:...................................7
      3.2.  Server and Resource Addressing............................7
      4.   MRCPv2 Protocol Basics......................................7
      4.1.  Connecting to the Server..................................8
      4.2.  Managing Resource Control Channels........................8
      4.3.  Media Streams and RTP Ports..............................13
      4.4.  MRCPv2 Message Transport.................................14
      4.5.  Resource Types...........................................15
      5.   MRCPv2 Specification.......................................16
      5.1.  Request..................................................17
      5.2.  Response.................................................18
      5.3.  Event....................................................20
      6.   MRCP Generic Features......................................20
      6.1.  Generic Message Headers..................................20
      6.2.  SET-PARAMS...............................................28
      6.3.  GET-PARAMS...............................................29
      7.   Resource Discovery.........................................30
      8.   Speech Synthesizer Resource................................31
      8.1.  Synthesizer State Machine................................31
      8.2.  Synthesizer Methods......................................32
      8.3.  Synthesizer Events.......................................32
      8.4.  Synthesizer Header Fields................................32
      8.5.  Synthesizer Message Body.................................39
      8.6.  SPEAK....................................................41
      8.7.  STOP.....................................................43
      8.8.  BARGE-IN-OCCURRED........................................44
 
 S Shanmugham                  IETF-Draft                        Page 2
                            MRCPv2 Protocol                  July 2004
 
 
      8.9.  PAUSE....................................................45
      8.10. RESUME...................................................46
      8.11. CONTROL..................................................47
      8.12. SPEAK-COMPLETE...........................................49
      8.13. SPEECH-MARKER............................................49
      8.14. DEFINE-LEXICON...........................................51
      9.   Speech Recognizer Resource.................................51
      9.1.  Recognizer State Machine.................................52
      9.2.  Recognizer Methods.......................................53
      9.3.  Recognizer Events........................................53
      9.4.  Recognizer Header Fields.................................53
      9.5.  Recognizer Message Body..................................68
      9.6.  DEFINE-GRAMMAR...........................................75
      9.7.  RECOGNIZE................................................78
      9.8.  STOP.....................................................80
      9.9.  GET-RESULT...............................................81
      9.10. START-OF-SPEECH..........................................82
      9.11. START-INPUT-TIMERS.......................................82
      9.12. RECOGNITION-COMPLETE.....................................83
      9.13. START-PHRASE-ENROLLMENT..................................85
      9.14. ENROLLMENT-ROLLBACK......................................86
      9.15. END-PHRASE-ENROLLMENT....................................86
      9.16. MODIFY-PHRASE............................................87
      9.17. DELETE-PHRASE............................................87
      9.18. INTERPRET................................................88
      9.19. INTERPRETATION-COMPLETE..................................89
      9.20. DTMF Detection...........................................90
      10.  Recorder Resource..........................................90
      10.1. Recorder State Machine...................................91
      10.2. Recorder Methods.........................................91
      10.3. Recorder Events..........................................91
      10.4. Recorder Header Fields...................................91
      10.5. Recorder Message Body....................................96
      10.6. RECORD...................................................96
      10.7. STOP.....................................................97
      10.8. RECORD-COMPLETE..........................................97
      10.9. START-INPUT-TIMERS.......................................98
      11.  Speaker Verification and Identification....................99
      11.1. Speaker Verification State Machine......................100
      11.2. Speaker Verification Methods............................100
      11.3. Verification Events.....................................101
      11.4. Verification Header Fields..............................101
      11.5. Verification Result Elements............................110
      11.6. START-SESSION...........................................114
      11.7. END-SESSION.............................................115
      11.8. QUERY-VOICEPRINT........................................115
      11.9. DELETE-VOICEPRINT.......................................116
      11.10.                            VERIFY..................................................117
      11.11.                            VERIFY-FROM-BUFFER......................................117
      11.12.                            VERIFY-ROLLBACK.........................................120
      11.13.                            STOP....................................................120
 
 S Shanmugham                  IETF-Draft                        Page 3
                            MRCPv2 Protocol                  July 2004
 
 
      11.14.                            START-INPUT-TIMERS......................................121
      11.15.                            VERIFICATION-COMPLETE...................................122
      11.16.                            START-OF-SPEECH.........................................122
      11.17.                            CLEAR-BUFFER............................................123
      11.18.                            GET-INTERMEDIATE-RESULT.................................123
      12.  Security Considerations...................................124
      13.  Examples:.................................................124
      14.  Reference Documents.......................................131
      15.  Appendix..................................................133
      15.1. ABNF Message Definitions................................133
      15.2. XML Schema and DTD......................................147
      Full Copyright Statement.......................................152
      Intellectual Property..........................................152
      Contributors...................................................152
      Acknowledgements...............................................153
      Editors' Addresses.............................................154
 
 
 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 [8] 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
    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
 
 
 
 S Shanmugham                  IETF-Draft                        Page 4
                            MRCPv2 Protocol                  July 2004
 
 
    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, SCTP or TLS.
 
 
 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[10].
 
    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)
 
 
 
 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.
 
 S Shanmugham                  IETF-Draft                        Page 5
                            MRCPv2 Protocol                  July 2004
 
 
 
    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-----||---------------------------||
      |--------------------|             |-----------------------------|
               |                             /
              SIP                           /
               |                           /
      |-------------------|              RTP
      |                   |              /
      | Media Source/Sink |-------------/
      |                   |
      |-------------------|
 
                     Fig 1: Architectural Diagram
 
 
 S Shanmugham                  IETF-Draft                        Page 6
                            MRCPv2 Protocol                  July 2004
 
 
 3.1. MRCPv2 Media Resources:
 
    The MRCP server may offer one or more of the following media
    processing resources to its clients.
 
    Speech Recognition
    The server may offer speech recognition engines that the client can
    allocate, control and have it recognize the spoken input contained
    in the audio stream.
 
    Speech Synthesis
    The server may offer speech synthesis engines that the client can
    allocate, control and have it generate synthesized voice into the
    audio stream.
 
    Speaker Identification
    The server may offer speaker recognition engines that the client can
    allocate, control and have it recognize the speaker from voice in
    the audio stream.
 
    Speaker Verification
    The server may offer speaker Verification engines that the client
    can allocate, control and have it verify and authenticate the
    speaker based on his voice.
 
 3.2. 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 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,
    SCTP or TLS 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.
 
 S Shanmugham                  IETF-Draft                        Page 7
                            MRCPv2 Protocol                  July 2004
 
 
 
 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.
 
 
 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 Recognition
                dtmfrecog      DTMF Recognition
                speechsynth    Speech Synthesis
                basicsynth     Poorman's Speech Synthesizer
                speakverify    Speaker Verification
                recorder       Speech Recording
 
    Additional resource types, their associated methods/events and state
    machines can be added by future specification proposing to extend
    the capabilities of MRCPv2.
 
    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 "control" and a transport type field
    of "TCP", "SCTP" or "TLS". 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
 
 S Shanmugham                  IETF-Draft                        Page 8
                            MRCPv2 Protocol                  July 2004
 
 
    m-line MUST contain "application/mrcpv2". 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 TCP, SCTP and TLS and it is up to the
    client to choose which mode of transport it wants to use for an
    MRCPv2 session.
 
    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.
 
    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.
 
 
    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>
           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=control 9 TCP application/mrcpv2
           a=resource:speechsynth
           a=cmid:1
 
 S Shanmugham                  IETF-Draft                        Page 9
                            MRCPv2 Protocol                  July 2004
 
 
           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=control 32416 TCP application/mrcpv2
           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
           CSeq: 314162 ACK
           Content-Length: 0
 
    Example 2:
    This exchange continues from example 1 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
 
 S Shanmugham                  IETF-Draft                       Page 10
                            MRCPv2 Protocol                  July 2004
 
 
           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=control 9 TCP application/mrcpv2
           a=resource:speechrecog
           a=cmid:1
           m=control 9 TCP application/mrcpv2
           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
           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=control 32416 TCP application/mrcpv2
           a=channel:32AECB234338@speechrecog
           a=cmid:1
           m=control 32416 TCP application/mrcpv2
           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
 
 S Shanmugham                  IETF-Draft                       Page 11
                            MRCPv2 Protocol                  July 2004
 
 
           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
           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=control 0 TCP application/mrcpv2
           a=resource:speechrecog
           a=cmid:1
           m=control 9 TCP application/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:
 
 S Shanmugham                  IETF-Draft                       Page 12
                            MRCPv2 Protocol                  July 2004
 
 
           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=control 0 TCP application/mrcpv2
           a=channel:32AECB234338@speechrecog
           a=cmid:1
           m=control 32416 TCP application/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;
                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
 
 S Shanmugham                  IETF-Draft                       Page 13
                            MRCPv2 Protocol                  July 2004
 
 
    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
    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 SDP offer.
 
 4.4. MRCPv2 Message Transport
 
    The MRCPv2 resource messages defined in this document are
    transported over a TCP, SCTP or TLS pipe between the client and the
    server. The setting up of this TCP pipe and the resource control
    channel is discussed in Section 3.2. Multiple resource control
    channels between a client and a server that belong to different SIP
    sessions can share one or more TCP or SCTP pipes between them. The
    individual MRCPv2 messages carry the MRCPv2 channel identifier in
 
 S Shanmugham                  IETF-Draft                       Page 14
                            MRCPv2 Protocol                  July 2004
 
 
    their Channel-Identifier header field MUST be used to differentiate
    MRCPv2 messages from different resource channels. All MRCPv2 servers
    MUST support TCP, SCTP and TLS 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/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
            <paragraph>
              <sentence>You have 4 new messages.</sentence>
              <sentence>The first is from <say-as
              type="name">Stephanie Williams</say-as>
              and arrived at <break/>
              <say-as type="time">3:45pm</say-as>.</sentence>
 
              <sentence>The subject is <prosody
              rate="-20%">ski trip</prosody></sentence>
            </paragraph>
           </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.
 
 4.5. Resource Types
 
    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>, <sayas>
    and <mark>.
 
    Speech Synthesizer
    A full capability speech synthesizer capable of rendering regular
    speech and having full SSML support.
 
 S Shanmugham                  IETF-Draft                       Page 15
                            MRCPv2 Protocol                  July 2004
 
 
 
    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
    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.
 
 
 
 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 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, but receivers SHOULD be prepared to
    also interpret CR and LF by themselves as line terminators. 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 TCP connection.
 
 
 S Shanmugham                  IETF-Draft                       Page 16
                            MRCPv2 Protocol                  July 2004
 
 
    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 ]
 
      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
                       /    extension-header
 
      header-extension =    1*(ALPHANUM / "-") CRLF
 
    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 zero or more
    parameters as part of the 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
 
 S Shanmugham                  IETF-Draft                       Page 17
                            MRCPv2 Protocol                  July 2004
 
 
    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 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
 
    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
                     /    extension-methods
 
      extension-methods = 1*(ALPHA / "-")
 
 5.2. Response
 
    After receiving and interpreting the request message, the server
    resource responds with an MRCPv2 response message. It consists of a
    status line optionally followed by a message body.
 
      response-line  =    mrcp-version SP message-length SP request-id
                     SP status-code SP request-state CRLF
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 18
                            MRCPv2 Protocol                  July 2004
 
 
    The mrcp-version field used here is similar to the one used in the
    Request Line and indicates the version of 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
    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 and the
    Failure(4XX) codes.
 
 Success 2xx
 
       200       Success
       201       Success with some optional parameters ignored.
 
 Failure 4xx
 
       401       Method not allowed
       402       Method not valid in this state
       403       Unsupported Parameter
       404       Illegal Value for Parameter
       405       Not found (e.g. Resource URI not initialized
                 or doesn't exist)
       406       Mandatory Parameter 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 Parameter Value
       421-499   Resource specific Failure codes
 
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 19
                            MRCPv2 Protocol                  July 2004
 
 
 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
    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. Events have 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
                       /  extension-event
 
      extension-event  =  1*(ALPHA /"-")
 
 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 general-header (section 5.5) and
    resource-specific-header (section 7.4 and section 8.4), follow the
    same generic format as that given in Section 3.1 of RFC 822 [8].
 
 S Shanmugham                  IETF-Draft                       Page 20
                            MRCPv2 Protocol                  July 2004
 
 
    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. 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    = *( field-content / LWS )
      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
 
 S Shanmugham                  IETF-Draft                       Page 21
                            MRCPv2 Protocol                  July 2004
 
 
                          /    set-cookie
                          /    set-cookie2
                          /    vendor-specific
 
    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
    hexadecimal digit string 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
    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.
 
 
 S Shanmugham                  IETF-Draft                       Page 22
                            MRCPv2 Protocol                  July 2004
 
 
      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
 
    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 2111[17] 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
 
 S Shanmugham                  IETF-Draft                       Page 23
                            MRCPv2 Protocol                  July 2004
 
 
 
    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.
 
 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.
 
      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
 
 
 
 S Shanmugham                  IETF-Draft                       Page 24
                            MRCPv2 Protocol                  July 2004
 
 
    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
    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" ":" 1#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 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
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 25
                            MRCPv2 Protocol                  July 2004
 
 
    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.
 
    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
 
 S Shanmugham                  IETF-Draft                       Page 26
                            MRCPv2 Protocol                  July 2004
 
 
 
 Set-Cookie and Set-Cookie2:
 
    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
          cookies         =       1#cookie
          cookie          =       NAME "=" VALUE *(";" cookie-av)
          NAME            =       attribute
          VALUE           =       value
          cookie-av       =       "Comment" "=" value
                          /       "Domain" "=" value
                          /       "Max-Age" "=" value
                          /       "Path" "=" value
                          /       "Secure"
                          /       "Version" "=" 1*DIGIT
                          /       "Age" "=" delta-seconds
 
          set-cookie2     =       "Set-Cookie2:" cookies2
          cookies2        =       1#cookie2
          cookie2         =       NAME "=" VALUE *(";" cookie-av2)
          NAME            =       attribute
          VALUE           =       value
          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        =       1#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.
 
 
 S Shanmugham                  IETF-Draft                       Page 27
                            MRCPv2 Protocol                  July 2004
 
 
    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.
 
 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 can be any Vendor specific field name and
    conforms to the XML vendor-specific attribute naming convention. The
    vendor-av-pair-value is the value to set the attribute to and needs
    to be quoted.
 
    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
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 28
                            MRCPv2 Protocol                  July 2004
 
 
    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
    parameters it MUST return 201.
 
    If some of the parameters being set are unsupported for the resource
    or have illegal values, the server MUST accept and set the remaining
    valid parameters and MUST respond with a Response-Status of 403 or
    404, 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->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 parameter it
    wants to read from the server by listing a set of empty parameter
    header fields. If a specific list is not specified then the server
    SHOULD return all the settable parameters 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 Shanmugham                  IETF-Draft                       Page 29
                            MRCPv2 Protocol                  July 2004
 
 
      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 "control", transport type "TCP" or "SCTP" and a format of
    "application/mrcpv2". There should be one "resource" attribute for
    each media resource that the server supports with the resource type
    identifier as its value.
 
    The SDP description SHOULD 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
 
 S Shanmugham                  IETF-Draft                       Page 30
                            MRCPv2 Protocol                  July 2004
 
 
           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=control 9 TCP application/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
 
 
 
 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
           3. audioplayer
    The difference between the above three resources is in their level
    of support in rendering SSML. The "audioplayer" resource MUST
    support the <audio> and <marker> tags of SSML at minimum. The
    "basicsynth" in addition to the "audioplayer" MUST support the
    <sayas> tag and be able to render it using concatenated audio files.
    The "speechsynth" resource is advanced speech synthesizer capable of
    synthesizing speech and SHOULD support the rest of the SSML tags as
    well.
 
 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
 
 S Shanmugham                  IETF-Draft                       Page 31
                            MRCPv2 Protocol                  July 2004
 
 
    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      |                          |
          |          |            |                          |
          |<---------|            |                          |
 
 
 8.2. Synthesizer Methods
 
    The synthesizer supports the following methods.
 
    synthesizer-method    =  "SPEAK"
                          /  "STOP"
                          /  "PAUSE"
                          /  "RESUME"
                          /  "BARGE-IN-OCCURRED"
                          /  "CONTROL"
                          /  "LOAD-LEXICON"
 
 8.3. Synthesizer Events
 
    The synthesizer may generate the following events.
 
      synthesizer-event   =  "SPEECH-MARKER"
                          /  "SPEAK-COMPLETE"
 
 8.4. Synthesizer Header Fields
 
 
 S Shanmugham                  IETF-Draft                       Page 32
                            MRCPv2 Protocol                  July 2004
 
 
    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-target
                          /  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
 
 
      Parameter           Support        Methods/Events/Response
 
      jump-target         MANDATORY      SPEAK, CONTROL
      logging-tag         MANDATORY      SET-PARAMS, GET-PARAMS
      kill-on-barge-in    MANDATORY      SPEAK
      speaker-profile     OPTIONAL       SET-PARAMS, GET-PARAMS,
                                         SPEAK, CONTROL
      completion-cause    MANDATORY      SPEAK-COMPLETE
      completion-reason   MANDATORY      SPEAK-COMPLETE
      voice-parameter     MANDATORY      SET-PARAMS, GET-PARAMS,
                                         SPEAK, CONTROL
      prosody-parameter   MANDATORY      SET-PARAMS, GET-PARAMS,
                                         SPEAK, CONTROL
      speech-marker       MANDATORY      SPEECH-MARKER
      speech-language     MANDATORY      SET-PARAMS, GET-PARAMS, SPEAK
      fetch-hint          MANDATORY      SET-PARAMS, GET-PARAMS, SPEAK
      audio-fetch-hint    MANDATORY      SET-PARAMS, GET-PARAMS, SPEAK
      fetch-timeout       MANDATORY      SET-PARAMS, GET-PARAMS, SPEAK
      failed-uri          MANDATORY      Any
      failed-uri-cause    MANDATORY      Any
      speak-restart       MANDATORY      CONTROL
      speak-length        MANDATORY      SPEAK, CONTROL
      load-lexicon        MANDATORY      LOAD-LEXICON
      lexicon-search-order MANDATORY     LOAD-LEXICON
 
 
 Jump-Target
 
 S Shanmugham                  IETF-Draft                       Page 33
 
    This parameter 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-target         =    "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"
                          /    "Paragraph"
 
 Kill-On-Barge-In
 
    This parameter 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 be intelligent enough to
    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 needs to send a BARGE-IN-OCCURRED method to the
    synthesizer resource when it receives a bargin-in-able event from
    the synthesizer resource or signal detector resource. These
    resources MAY BE local or distributed. If this field is not
    specified, the value defaults to "true".
 
 Speaker Profile
 
    This parameter MAY BE part of the SET-PARAMS/GET-PARAMS or SPEAK
    request from the client to the server and specifies the profile of
 
 
 
 S. Shanmugham, et. al.                                         Page 34
                            MRCPv2 Protocol                  July 2004
 
 
    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*ALPHA 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
                               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 parameters 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[11]. The voice-param-value is any one of the value
 
 S Shanmugham                  IETF-Draft                       Page 35
                            MRCPv2 Protocol                  July 2004
 
 
    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 parameters defines the prosody of the speech.
 
      prosody-parameter   =    "Prosody-" prosody-param-name ":"
                               prosody-param-value CRLF
 
    prosody-param-name is any one of the attribute names under the
    prosody element specified in W3C's Speech Synthesis Markup Language
    Specification[11]. 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
 
 S Shanmugham                  IETF-Draft                       Page 36
                            MRCPv2 Protocol                  July 2004
 
 
    marker tag values. This header may have additional timestamp
    information in a "timestamp" field separated by a semicolon. The
    value of the timestamp parameter specifies the time in milliseconds
    from the beginning of the SPEAK request that the marker was hit.
 
      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 request.
 
      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
 
 S Shanmugham                  IETF-Draft                       Page 37
                            MRCPv2 Protocol                  July 2004
 
 
    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" ":" Url CRLF
 
 Failed URI Cause
 
    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 jump backward request is issued to a currently
    speaking synthesizer resource and the jumps beyond the start of the
    speech, the current SPEAK request re-starts from the beginning of
    its speech data and the response to the CONTROL request would
    contain this header indicating a restart. This header MAY occur in
    the CONTROL response.
 
      speak-restart       =    "Speak-Restart" ":" boolean-value CRLF
 
 Speak Length
 
    This parameter 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, which
    ever 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 parameter".
 
 S Shanmugham                  IETF-Draft                       Page 38
                            MRCPv2 Protocol                  July 2004
 
 
 
      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".
 
           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[11] as a minimum and hence MUST
    support the MIME types text/plain and application/synthesis+ssml 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,
 
 
 
 S Shanmugham                  IETF-Draft                       Page 39
                            MRCPv2 Protocol                  July 2004
 
 
    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/synthesis+ssml 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 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.sml
         http://www.example.com/ASR-Document-Part1.sml
         http://www.example.com/ASR-Document-Part2.sml
         http://www.example.com/ASR-Conclusion.sml
 
    Example 2:
         Content-Type: application/synthesis+ssml
         Content-Length: 104
 
         <?xml version="1.0"?>
         <speak>
         <paragraph>
                  <sentence>You have 4 new messages.</sentence>
                  <sentence>The first is from <say-as
                  type="name">Stephanie Williams</say-as>
                  and arrived at <break/>
                  <say-as type="time">3:45pm</say-as>.</sentence>
 
                  <sentence>The subject is <prosody
                  rate="-20%">ski trip</prosody></sentence>
         </paragraph>
         </speak>
 
    Example 3:
         Content-Type: multipart/mixed; boundary="break"
 
         --break
         Content-Type: text/uri-list
         Content-Length: 176
 
 
 S Shanmugham                  IETF-Draft                       Page 40
                            MRCPv2 Protocol                  July 2004
 
 
         http://www.example.com/ASR-Introduction.sml
         http://www.example.com/ASR-Document-Part1.sml
         http://www.example.com/ASR-Document-Part2.sml
         http://www.example.com/ASR-Conclusion.sml
 
         --break
         Content-Type: application/synthesis+ssml
         Content-Length: 104
 
         <?xml version="1.0"?>
         <speak>
         <paragraph>
                  <sentence>You have 4 new messages.</sentence>
                  <sentence>The first is from <say-as
                  type="name">Stephanie Williams</say-as>
                  and arrived at <break/>
                  <say-as type="time">3:45pm</say-as>.</sentence>
 
                  <sentence>The subject is <prosody
                  rate="-20%">ski trip</prosody></sentence>
         </paragraph>
         </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
 
 
 S Shanmugham                  IETF-Draft                       Page 41
                            MRCPv2 Protocol                  July 2004
 
 
    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
    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 is in queue and will be processed after the currently
    active SPEAK request is 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/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
             <sentence>You have 4 new messages.</sentence>
             <sentence>The first is from <say-as
             type="name">Stephanie Williams</say-as>
             and arrived at <break/>
             <say-as type="time">3:45pm</say-as>.</sentence>
 
 
 S Shanmugham                  IETF-Draft                       Page 42
                            MRCPv2 Protocol                  July 2004
 
 
             <sentence>The subject is <prosody
             rate="-20%">ski trip</prosody></sentence>
           </paragraph>
           </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/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
             <sentence>You have 4 new messages.</sentence>
 
 S Shanmugham                  IETF-Draft                       Page 43
                            MRCPv2 Protocol                  July 2004
 
 
             <sentence>The first is from <say-as
             type="name">Stephanie Williams</say-as>
             and arrived at <break/>
             <say-as type="time">3:45pm</say-as>.</sentence>
 
             <sentence>The subject is <prosody
             rate="-20%">ski trip</prosody></sentence>
           </paragraph>
           </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.
 
    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
 
 S Shanmugham                  IETF-Draft                       Page 44
                            MRCPv2 Protocol                  July 2004
 
 
    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/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
             <sentence>You have 4 new messages.</sentence>
             <sentence>The first is from <say-as
             type="name">Stephanie Williams</say-as>
             and arrived at <break/>
             <say-as type="time">3:45pm</say-as>.</sentence>
 
             <sentence>The subject is <prosody
             rate="-20%">ski trip</prosody></sentence>
           </paragraph>
           </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
 
    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".
 
 S Shanmugham                  IETF-Draft                       Page 45
                            MRCPv2 Protocol                  July 2004
 
 
    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/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
             <sentence>You have 4 new messages.</sentence>
             <sentence>The first is from <say-as
             type="name">Stephanie Williams</say-as>
             and arrived at <break/>
             <say-as type="time">3:45pm</say-as>.</sentence>
 
             <sentence>The subject is <prosody
             rate="-20%">ski trip</prosody></sentence>
           </paragraph>
           </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 when a SPEAK is not active the server SHOULD
    respond with a status of 402 or "Method not valid in this state". If
    a RESUME method is issued on a session when a SPEAK is active and
    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
 
 S Shanmugham                  IETF-Draft                       Page 46
                            MRCPv2 Protocol                  July 2004
 
 
           Voice-gender: neutral
           Voice-category: teenager
           Prosody-volume: medium
           Content-Type: application/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
               <sentence>You have 4 new messages.</sentence>
               <sentence>The first is from <say-as
               type="name">Stephanie Williams</say-as>
               and arrived at <break/>
               <say-as type="time">3:45pm</say-as>.</sentence>
 
               <sentence>The subject is <prosody
               rate="-20%">ski trip</prosody></sentence>
           </paragraph>
           </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
 
 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 parameters.
 
    When a CONTROL to jump forward is issued and the operation goes
    beyond the end of the active SPEAK method's text, the request
    succeeds. A SPEAK-COMPLETE event follows the response to the CONTROL
 
 
 
 S Shanmugham                  IETF-Draft                       Page 47
                            MRCPv2 Protocol                  July 2004
 
 
    method. If there are more SPEAK requests in the queue, the
    synthesizer resource will continue to process the next SPEAK method.
    When a CONTROL to jump backwards is issued and the operation jumps
    to the beginning of the speech data of the active SPEAK request, the
    response to the CONTROL request contains the speak-restart header.
 
    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/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
             <sentence>You have 4 new messages.</sentence>
             <sentence>The first is from <say-as
             type="name">Stephanie Williams</say-as>
             and arrived at <break/>
             <say-as type="time">3:45pm</say-as>.</sentence>
 
             <sentence>The subject is <prosody
             rate="-20%">ski trip</prosody></sentence>
           </paragraph>
           </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
 
 S Shanmugham                  IETF-Draft                       Page 48
                            MRCPv2 Protocol                  July 2004
 
 
           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/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
             <sentence>You have 4 new messages.</sentence>
             <sentence>The first is from <say-as
             type="name">Stephanie Williams</say-as>
             and arrived at <break/>
             <say-as type="time">3:45pm</say-as>.</sentence>
 
             <sentence>The subject is <prosody
             rate="-20%">ski trip</prosody></sentence>
           </paragraph>
           </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
 
 
 S Shanmugham                  IETF-Draft                       Page 49
                            MRCPv2 Protocol                  July 2004
 
 
    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.
 
    Example:
      C->S:MRCP/2.0 434 SPEAK 543261
           Channel-Identifier: 32AECB23433802@speechsynth
           Voice-gender: neutral
           Voice-category: teenager
           Prosody-volume: medium
           Content-Type: application/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
             <sentence>You have 4 new messages.</sentence>
             <sentence>The first is from <say-as
             type="name">Stephanie Williams</say-as>
             and arrived at <break/>
             <say-as type="time">3:45pm</say-as>.</sentence>
             <mark name="here"/>
             <sentence>The subject is
                <prosody rate="-20%">ski trip</prosody>
             </sentence>
             <mark name="ANSWER"/>
           </paragraph>
           </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
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 50
                            MRCPv2 Protocol                  July 2004
 
 
 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.
 
 
 
 
 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.
 
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 51
                            MRCPv2 Protocol                  July 2004
 
 
 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
    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       |
          |<-----------|          |<---------|               |
          |                       |                          |
 
 S Shanmugham                  IETF-Draft                       Page 52
                            MRCPv2 Protocol                  July 2004
 
 
          |                       |------|                   |
          |-------|               |   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
                          /    enrollment-method
 
    recog-only-method     =    "DEFINE-GRAMMAR"
                          /    "RECOGNIZE"
                          /    "INTERPRET"
                          /    "GET-RESULT"
                          /    "START-INPUT-TIMERS"
                          /    "STOP"
 
    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"
                          /    "ENROLLMENT-ROLLBACK"
                          /    "END-PHRASE-ENROLLMENT"
                          /    "MODIFY-PHRASE"
                          /    "DELETE-PHRASE"
 
 9.3. Recognizer Events
 
    The recognizer may generate the following events.
      recognizer-event    =    "START-OF-SPEECH"
                          /    "RECOGNITION-COMPLETE"
                          /    "INTERPRETATION-COMPLETE"
 
 
 9.4. Recognizer Header Fields
 
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 53
                            MRCPv2 Protocol                  July 2004
 
 
    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-url
                          /    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
 
    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
 
 
 S Shanmugham                  IETF-Draft                       Page 54
                            MRCPv2 Protocol                  July 2004
 
 
      Parameter                Support   Methods/Events
 
      confidence-threshold     MANDATORY SET-PARAMS, RECOGNIZE
                                         GET-RESULT
      sensitivity-level        Optional  SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE
      speed-vs-accuracy        Optional  SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE
      n-best-list-length       Optional  SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE, GET-RESULT
      no-input-timeout         MANDATORY SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE
      recognition-timeout      MANDATORY SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE
      waveform-url             MANDATORY RECOGNITION-COMPLETE,
                                         END-PHRASE-ENROLLMENT
      completion-cause         MANDATORY DEFINE-GRAMMAR, RECOGNIZE,
                                         RECOGNITION-COMPLETE
      completion-reason        MANDATORY DEFINE-GRAMMAR, RECOGNIZE,
                                         RECOGNITION-COMPLETE
      recognizer-context-block Optional  SET-PARAMS, GET-PARAMS
      start-input-timers       MANDATORY RECOGNIZE
      speech-complete-timeout  MANDATORY SET-PARAMS, GET-PARAMS
                                         RECOGNIZE
      speech-incomplete-timeout MANDATORY SET-PARAMS, GET-PARAMS
                                         RECOGNIZE
      dtmf-interdigit-timeout  MANDATORY SET-PARAMS, GET-PARAMS
                                         RECOGNIZE
      dtmf-term-timeout        MANDATORY SET-PARAMS, GET-PARAMS
                                         RECOGNIZE
      dtmf-term-char           MANDATORY SET-PARAMS, GET-PARAMS
                                         RECOGNIZE
      fetch-timeout            MANDATORY SET-PARAMS, GET-PARAMS
                                         RECOGNIZE, DEFINE-GRAMMAR
      failed-uri               MANDATORY DEFINE-GRAMMAR response,
                                         RECOGNITION-COMPLETE
      failed-uri-cause         MANDATORY DEFINE-GRAMMAR response,
                                         RECOGNITION-COMPLETE
      save-waveform            MANDATORY SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE
      new-audio-channel        MANDATORY RECOGNIZE
      speech-language          MANDATORY SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE, DEFINE-GRAMMAR
      ver-buffer-utterance     OPTIONAL  SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE
      recognition-mode    `    MANDATORY SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE
      cancel-if-queue          MANDATORY RECOGNIZE
      hotword-max-duration     MANDATORY SET-PARAMS, GET-PARAMS,
                                         RECOGNIZE
      hotword-min-duration     MANDATORY SET-PARAMS, GET-PARAMS,
 
 S Shanmugham                  IETF-Draft                       Page 55
                            MRCPv2 Protocol                  July 2004
 
 
                                         RECOGNIZE
      Interpret-text           MANDATORY INTERPRET
 
    If a recognition resource supports voice enrolled grammars, the
    following header fields apply towards using that functionality.
 
      Parameter            Support   Methods/Events
 
    num-min-consistent     MANDATORY START-PHRASE-ENROLLMENT,
      -pronunciations                SET-PARAMS, GET-PARAMS
    consistency-threshold  OPTIONAL  START-PHRASE-ENROLLMENT,
                                     SET-PARAMS, GET-PARAMS
    clash-threshold        OPTIONAL  START-PHRASE-ENROLLMENT,
                                     SET-PARAMS, GET-PARAMS
    personal-grammar-uri   MANDATORY START-PHRASE-ENROLLMENT,
                                     SET-PARAMS, GET-PARAMS,
                                     MODIFY-PHRASE, DELETE-PHRASE
    phrase-id              MANDATORY MODIFY-PHRASE, DELETE-PHRASE,
                                     START-PHRASE-ENROLLMENT
    phrase-nl              MANDATORY MODIFY-PHRASE,
                                     START-PHRASE-ENROLLMENT
    weight                 OPTIONAL  MODIFY-PHRASE,
                                     START-PHRASE-ENROLLMENT
    save-best-waveform     OPTIONAL  SET-PARAMS, GET-PARAMS,
                                     START-PHRASE-ENROLLMENT
    new-phrase-id          OPTIONAL  MODIFY-PHRASE
    confusable-phrases-uri OPTIONAL  RECOGNIZE
    abort-phrase-enrollment OPTIONAL END-PHRASE-ENROLLMENT
 
    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-url header field of the Recognizer resource
    can also appear in the response to the END-PHRASE-ENROLLMENT method.
 
 
 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 parameter 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,
 
 
 
 S Shanmugham                  IETF-Draft                       Page 56
                            MRCPv2 Protocol                  July 2004
 
 
    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 parameter 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 parameter 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 parameter, 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 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
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 57
                            MRCPv2 Protocol                  July 2004
 
 
    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 parameter 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 URL
    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 URL value of the header MUST be
    NULL if there was some error condition preventing the server from
    recording. Otherwise, the URL generated by the server SHOULD be
    globally unique across the server and all its recognition sessions.
    The URL SHOULD BE available until the session is torn down.
 
    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 URL returned in the
    waveform-url header field in the response to the END-PHRASE-
    ENROLLMENT method. The URL value of the header MUST be NULL if there
    was some error condition preventing the server from recording.
    Otherwise, the URL generated by the server SHOULD be globally unique
    across the server and all its recognition sessions. The URL SHOULD
    BE available until the session is torn down.
 
 S Shanmugham                  IETF-Draft                       Page 58
                            MRCPv2 Protocol                  July 2004
 
 
 
      waveform-url        =    "Waveform-URL" ":" Url 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*ALPHA 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.
        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
 
 S Shanmugham                  IETF-Draft                       Page 59
                            MRCPv2 Protocol                  July 2004
 
 
                                    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 parameter 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 the content-id that came with the
    context data during the GET-PARAMS operation.
 
      recognizer-context-block =    "Recognizer-Context-Block" ":"
                                    1*VCHAR CRLF
 
 Start Input Timers
 
    This parameter 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".
 
 
 S Shanmugham                  IETF-Draft                       Page 60
                            MRCPv2 Protocol                  July 2004
 
 
      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.
 
 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.
 
 
 S Shanmugham                  IETF-Draft                       Page 61
                            MRCPv2 Protocol                  July 2004
 
 
    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.
 
      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" ":" CHAR 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
 
 
 S Shanmugham                  IETF-Draft                       Page 62
                            MRCPv2 Protocol                  July 2004
 
 
    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" ":" Url 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 and make it
    available to the client in the form of a URI returned in the
    waveform-uri header field in the RECOGNITION-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
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 63
                            MRCPv2 Protocol                  July 2004
 
 
    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
 
 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
 
 S Shanmugham                  IETF-Draft                       Page 64
                            MRCPv2 Protocol                  July 2004
 
 
     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" ":" 1*ALPHA CRLF
 
 Hotword-Max-Duration
 
    This parameter 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 parameter, 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 parameter 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 parameter, 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 string for which a
    natural language interpretation is desired.  This header field MUST
    be used when invoking the INTERPRET method as it cannot be set with
    the SET-PARAMS method.
 
              interpret-text = "Interpret-Text" : 1*OCTET CRLF
 
 Num-Min-Consistent-Pronunciations
 
    This parameter 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  =
 
 S Shanmugham                  IETF-Draft                       Page 65
                            MRCPv2 Protocol                  July 2004
 
 
                   "Num-Min-Consistent-Pronunciations" ":" 1*DIGIT CRLF
 
 
 Consistency-Threshold
 
    This parameter MAY BE sent as part of the START-PHRASE-ENROLLMENT,
    SET-PARAMS, or GET-PARAMS method.  Used during voice-enrollment,
    this parameter 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 parameter MAY BE sent as part of the START-PHRASE-ENROLLMENT,
    SET-PARMS, or GET-PARAMS method.  Used during voice-enrollment, this
    parameter 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 parameter 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" ":" Url 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.
 
 
 S Shanmugham                  IETF-Draft                       Page 66
                            MRCPv2 Protocol                  July 2004
 
 
      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
    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 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 URL returned in the waveform-url 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-url
    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
 
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 67
                            MRCPv2 Protocol                  July 2004
 
 
 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" ":"
                                    Url 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 [13](MIME-type
    application/grammar+xml) and SHOULD support the ABNF form (MIME-type
    application/grammar).
 
    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
 
 S Shanmugham                  IETF-Draft                       Page 68
                            MRCPv2 Protocol                  July 2004
 
 
    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
 
    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/grammar or
    application/grammar+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/grammar+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>
 
 S Shanmugham                  IETF-Draft                       Page 69
                            MRCPv2 Protocol                  July 2004
 
 
 
            <!-- 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>
 
    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/grammar+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>
 
 S Shanmugham                  IETF-Draft                       Page 70
                            MRCPv2 Protocol                  July 2004
 
 
                    </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 -->
           <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 W3C's
    Natural Language Semantics Markup Language (NLSML)[11] as the
    default standard for returning recognition results back to the
    client, and hence MUST support the MIME-type application/x-nlsml.
 
    MRCP-specific additions to this result format MUST be in the MRCPv2
    namespace, and vendor-specific additions to this 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.  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:
        Content-Type: application/x-nlsml
        Content-Length: 104
 
        <?xml version="1.0"?>
 
 S Shanmugham                  IETF-Draft                       Page 71
                            MRCPv2 Protocol                  July 2004
 
 
        <result grammar="http://theYesNoGrammar">
            <interpretation>
                <instance>
                    <myApp:yes_no>
                        <response>yes</response>
                    </myApp:yes_no>
                </instance>
                <input>ok</input>
            </interpretation>
        </result>
 
 
 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 a normative form in the Appendix. 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
 
 S Shanmugham                  IETF-Draft                       Page 72
                            MRCPv2 Protocol                  July 2004
 
 
 
 
    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
    parameter 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.
 
 
 S Shanmugham                  IETF-Draft                       Page 73
                            MRCPv2 Protocol                  July 2004
 
 
      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
    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
 
 
 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.
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 74
                            MRCPv2 Protocol                  July 2004
 
 
 9.6. 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/grammar+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 73 543257 200 COMPLETE
 
 S Shanmugham                  IETF-Draft                       Page 75
                            MRCPv2 Protocol                  July 2004
 
 
           Channel-Identifier: 32AECB23433801@speechrecog
           Completion-Cause: 000 success
 
 
      C->S:MRCP/2.0 334 DEFINE-GRAMMAR 543258
           Channel-Identifier: 32AECB23433801@speechrecog
           Content-Type: application/grammar+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/grammar+xml
           Content-Id: <request2@field-level.store>
           Content-Length: 104
 
           <?xml version="1.0"?>
 
                <grammar xml:lang="en">
 
                <import uri="session:politeness@form-level.store"
                        name="polite"/>
 
                <rule id="basicCmd" scope="public">
                <example> please move the window </example>
                <example> open a file </example>
 
                <ruleref import="polite#startPolite"/>
                <ruleref uri="#command"/>
                <ruleref import="polite#endPolite"/>
                </rule>
 
                <rule id="command">
                <ruleref uri="#action"/> <ruleref uri="#object"/>
                </rule>
 
                <rule id="action">
                     <choice>
 
 S Shanmugham                  IETF-Draft                       Page 76
                            MRCPv2 Protocol                  July 2004
 
 
                     <item weight="10" tag="OPEN">   open </item>
                     <item weight="2"  tag="CLOSE">  close </item>
                     <item weight="1"  tag="DELETE"> delete </item>
                     <item weight="1"  tag="MOVE">   move </item>
                     </choice>
                </rule>
 
                <rule id="object">
                <count number="optional">
                     <choice>
                          <item> the </item>
                          <item> a </item>
                     </choice>
                </count>
                <choice>
                     <item> window </item>
                     <item> file </item>
                     <item> menu </item>
                </choice>
                </rule>
 
                </grammar>
 
      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-URL: http://web.media.com/session123/audio.wav
           Content-Type: applicationt/x-nlsml
           Content-Length: 276
 
           <?xml version="1.0"?>
 
 S Shanmugham                  IETF-Draft                       Page 77
                            MRCPv2 Protocol                  July 2004
 
 
           <result x-model="http://IdentityModel"
             xmlns:xf="http://www.w3.org/2000/xforms"
             grammar="session:request1@form-level.store">
                <interpretation>
                     <xf:instance name="Person">
                       <Person>
                           <Name> Andre Roy </Name>
                       </Person>
                     </xf:instance>
                     <input>   may I speak to Andre Roy </input>
                </interpretation>
           </result>
 
 9.7. 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 parameters to control the
    sensitivity, confidence level and the level of detail in results
    provided by the recognizer. These parameters override the current
    defaults set by a previous SET-PARAMS method.
 
    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".
 
    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 recognition 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
 
 S Shanmugham                  IETF-Draft                       Page 78
                            MRCPv2 Protocol                  July 2004
 
 
    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.
 
    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:
      C->S:MRCP/2.0 479 RECOGNIZE 543257
           Channel-Identifier: 32AECB23433801@speechrecog
           Confidence-Threshold: 90
           Content-Type: application/grammar+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 79
                            MRCPv2 Protocol                  July 2004
 
 
                             <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 467 RECOGNITION-COMPLETE 543257 COMPLETE
           Channel-Identifier: 32AECB23433801@speechrecog
           Completion-Cause: 000 success
           Waveform-URL: http://web.media.com/session123/audio.wav
           Content-Type: application/x-nlsml
           Content-Length: 276
 
           <?xml version="1.0"?>
           <result x-model="http://IdentityModel"
             xmlns:xf="http://www.w3.org/2000/xforms"
             grammar="session:request1@form-level.store">
               <interpretation>
                   <xf:instance name="Person">
                       <Person>
                           <Name> Andre Roy </Name>
                       </Person>
                   </xf:instance>
                     <input>   may I speak to Andre Roy </input>
               </interpretation>
           </result>
 
 9.8. STOP
 
    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: 90
           Content-Type: application/grammar+xml
 
 S Shanmugham                  IETF-Draft                       Page 80
                            MRCPv2 Protocol                  July 2004
 
 
           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
 
 9.9. 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.
 
 S Shanmugham                  IETF-Draft                       Page 81
                            MRCPv2 Protocol                  July 2004
 
 
 
    Example:
      C->S:MRCP/2.0 73 GET-RESULT 543257
           Channel-Identifier: 32AECB23433801@speechrecog
           Confidence-Threshold: 90
 
 
      S->C:MRCP/2.0 487 543257 200 COMPLETE
           Channel-Identifier: 32AECB23433801@speechrecog
           Content-Type: application/x-nlsml
           Content-Length: 276
 
           <?xml version="1.0"?>
           <result x-model="http://IdentityModel"
             xmlns:xf="http://www.w3.org/2000/xforms"
             grammar="session:request1@form-level.store">
               <interpretation>
                   <xf:instance name="Person">
                       <Person>
                           <Name> Andre Roy </Name>
                       </Person>
                   </xf:instance>
                             <input>   may I speak to Andre Roy </input>
               </interpretation>
           </result>
 
 9.10.     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.
 
    This event should be generated irrespective of whether the
    synthesizer and recognizer are on the same server or not.
 
 9.11.     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
 
 S Shanmugham                  IETF-Draft                       Page 82
                            MRCPv2 Protocol                  July 2004
 
 
    start the no-input timers until the prompt is finished. The
    parameter 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.12.     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 URL to the audio waveform MAY BE returned to
    the client in a waveform-url 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: 90
           Content-Type: application/grammar+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>
 
 S Shanmugham                  IETF-Draft                       Page 83
                            MRCPv2 Protocol                  July 2004
 
 
                             <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-URL: http://web.media.com/session123/audio.wav
           Content-Type: application/x-nlsml
           Content-Length: 276
 
           <?xml version="1.0"?>
           <result x-model="http://IdentityModel"
             xmlns:xf="http://www.w3.org/2000/xforms"
             grammar="session:request1@form-level.store">
               <interpretation>
                   <xf:instance name="Person">
                       <Person>
                           <Name> Andre Roy </Name>
                       </Person>
                   </xf: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/x-nlsml
           Content-Length: 123
 
           <?xml version= "1.0"?>
           <result grammar="Personal-Grammar-URI"
                   xmlns:mrcp="http://www.ietf.org/mrcp2">
              <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
 
 S Shanmugham                  IETF-Draft                       Page 84
                            MRCPv2 Protocol                  July 2004
 
 
                </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.13.     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.
 
    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.
 
 S Shanmugham                  IETF-Draft                       Page 85
                            MRCPv2 Protocol                  July 2004
 
 
 
    If the client has specified Save-Best-Waveform as true, then the
    response after ending the phrase enrollment session should contain
    the location/URL 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.14.     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
 
 9.15.     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.
 
 
 S Shanmugham                  IETF-Draft                       Page 86
                            MRCPv2 Protocol                  July 2004
 
 
    If the client has specified Save-Best-Waveform as true in the START-
    PHRASE-ENROLLMENT request, then the response should contain the
    location/URL 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-URL: <waveform url>
 
 
 9.16.     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
 
 
 9.17.     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 Shanmugham                  IETF-Draft                       Page 87
                            MRCPv2 Protocol                  July 2004
 
 
    S->C:  MRCP/2.0 49 543266 200 COMPLETE
           Channel-Identifier: 32AECB23433801@speechrecog
 
 9.18.     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/grammar+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 Shanmugham                  IETF-Draft                       Page 88
                            MRCPv2 Protocol                  July 2004
 
 
 
    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/x-nlsml
           Content-Length: 276
 
           <?xml version="1.0"?>
           <result   x-model="http://IdentityModel"
                     xmlns:xf="http://www.w3.org/2000/xforms"
                     grammar="session:request1@form-level.store">
                <interpretation>
                     <xf:instance name="Person">
                          <Person>
                               <Name> Andre Roy </Name>
                          </Person>
                     </xf:instance>
                     <input>   may I speak to Andre Roy </input>
                </interpretation>
           </result>
 
 9.19.     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/grammar+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>
 
 S Shanmugham                  IETF-Draft                       Page 89
                            MRCPv2 Protocol                  July 2004
 
 
                   </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/x-nlsml
           Content-Length: 276
 
           <?xml version="1.0"?>
           <result   x-model="http://IdentityModel"
                     xmlns:xf="http://www.w3.org/2000/xforms"
                     grammar="session:request1@form-level.store">
                <interpretation>
                     <xf:instance name="Person">
                          <Person>
                               <Name> Andre Roy </Name>
                          </Person>
                     </xf:instance>
                     <input>   may I speak to Andre Roy </input>
                </interpretation>
           </result>
 
 9.20.     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
    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
 
 S Shanmugham                  IETF-Draft                       Page 90
                            MRCPv2 Protocol                  July 2004
 
 
    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
                          /    "STOP"
                          /    "START-INPUT-TIMERS"
 
 
 10.3.     Recorder Events
 
    The recorder may generate the following events.
 
      recorder-Event      =    "START-OF-SPEECH"
                          /    "RECORD-COMPLETE"
 
 10.4.     Recorder Header Fields
 
    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
 
 S Shanmugham                  IETF-Draft                       Page 91
                            MRCPv2 Protocol                  July 2004
 
 
                          /    max-time
                          /    final-silence
                          /    capture-on-speech
                          /    ver-buffer-utterance
                          /    start-input-timers
                          /    new-audio-channel
 
      Parameter                Support   Methods/Events
 
      sensitivity-level        Optional  SET-PARAMS, GET-PARAMS,
                                         RECORD
      No-input-timeout         MANDATORY RECORD,
                                         RECORD-COMPLETE
      completion-cause         MANDATORY RECORD,
                                         RECORD-COMPLETE
      completion-reason        MANDATORY RECORD,
                                         RECORD-COMPLETE
 
      failed-uri               MANDATORY RECORD response,
                                         RECORD-COMPLETE
      failed-uri-cause         MANDATORY RECORD response,
                                         RECORD-COMPLETE
                                              record-uri
                                         MANDATORY RECORD
      media-type               MANDATORY RECORD
      max-time                 MANDATORY RECORD
      final-silence            MANDATORY RECORD
      capture-on-speech        OPTIONAL  RECORD
      ver-buffer-utterance     OPTIONAL  RECORD, SET-PARAMS, GET-PARAMS
      start-input-timers       MANDATORY RECORD
      new-audio-channel        MANDATORY RECORD
 
 
 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 parameter 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
 
 S Shanmugham                  IETF-Draft                       Page 92
                            MRCPv2 Protocol                  July 2004
 
 
    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*ALPHA 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
    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" ":" Url 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
 
 S Shanmugham                  IETF-Draft                       Page 93
                            MRCPv2 Protocol                  July 2004
 
 
    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" ":" Url 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 CRLF
 
 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
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 94
                            MRCPv2 Protocol                  July 2004
 
 
    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.
 
 Start Input Timers
 
    This parameter 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
 
 
 
 
 S Shanmugham                  IETF-Draft                       Page 95
                            MRCPv2 Protocol                  July 2004
 
 
 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 URL supplied in the recording-url header
    field. If the recording-url 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-url is not valid, a status code of 404, "Illegal
    Value for Parameter", will be returned in the response. If it is
    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-URL: 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
 
 S Shanmugham                  IETF-Draft                       Page 96
                            MRCPv2 Protocol                  July 2004
 
 
                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-URL: 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-URL 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-URL: 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
 
           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-URL: 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-URL header
 
 
 
 S Shanmugham                  IETF-Draft                       Page 97
                            MRCPv2 Protocol                  July 2004
 
 
    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-URL: 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-URL: 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
    to start the no-input timers until the prompt is finished. The
    parameter 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 98
                            MRCPv2 Protocol                  July 2004
 
 
 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 99
                            MRCPv2 Protocol                  July 2004
 
 
 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"
                          / "END-SESSION"
                          / "QUERY-VOICEPRINT"
                          / "DELETE-VOICEPRINT"
                          / "VERIFY"
                          / "VERIFY-FROM-BUFFER"
                          / "VERIFY-ROLLBACK"
                          / "STOP"
                          / "CLEAR-BUFFER"
                          / "START-INPUT-TIMERS"
                          / "GET-INTERMEDIATE-RESULT"
 
    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 100
                            MRCPv2 Protocol                  July 2004
 
 
    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"
                          /   "START-OF-SPEECH"
 
 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 101
                            MRCPv2 Protocol                  July 2004
 
 
                          /    abort-model
                          /    security-level
                          /    num-min-verification-phrases
                          /    num-max-verification-phrases
                          /    no-input-timeout
                          /    save-waveform
                          /    waveform-url
                          /    voiceprint-exists
                          /    ver-buffer-utterance
                          /    input-waveform-url
                          /    verification-type
                          /    digit-sequence
                          /    completion-cause
                          /    completion-reason
                          /    speech-complete-timeout
                          /    new-audio-channel
                          /    abort-verification
                          /    start-input-timers
 
 
 
      Parameter                     Support   Methods/Events
    repository-uri                  MANDATORY START-SESSION,
                                              DELETE-VOICEPRINT,
                                              QUERY-VOICEPRINT
    voiceprint-identifier           MANDATORY START-SESSION,
                                              DELETE-VOICEPRINT,
                                              VER-QUERY-VOICEPRINT
    verification-mode               MANDATORY SET-PARAMS, GET-PARAMS,
                                              START-SESSION
    adapt-model                     OPTIONAL  START-SESSION
    abort-model                     OPTIONAL  END-SESSION
    security-level                  OPTIONAL  SET-PARAMS, GET-PARAMS,
                                              VERIFY, VERIFY-FROM-BUFFER
    num-min-verification-phrases    OPTIONAL  SET-PARAMS, GET-PARAMS,
     -phrases                                 VERIFY, VERIFY-FROM-BUFFER
    num-max-verification-phrases    OPTIONAL  SET-PARAMS, GET-PARAMS,
     -phrases                                 VERIFY, VERIFY-FROM-BUFFER
    no-input-timeout                MANDATORY SET-PARAMS, GET-PARAMS,
                                              VERIFY
    save-waveform                   MANDATORY SET-PARAMS, GET-PARAMS,
                                              VERIFY
    waveform-url                    MANDATORY VERIFICATION-COMPLETE
    voiceprint-exists               MANDATORY QUERY-VOICEPRINT,
                                              DELETE-VOICEPRINT
    ver-buffer-utterance            OPTIONAL  VERIFY
    input-waveform-url              OPTIONAL  VERIFY
    verification-type               OPTIONAL  START-SESSION
    digit-sequence                  OPTIONAL  VERIFY, VERIFY-FROM-BUFFER
    completion-cause                MANDATORY VERIFICATION-COMPLETE
                                              QUERY-VOICEPRINT,
 
 S Shanmugham                  IETF-Draft                      Page 102
                            MRCPv2 Protocol                  July 2004
 
 
                                              DELETE-VOICEPRINT
    completion-reason               MANDATORY VERIFICATION-COMPLETE
                                              QUERY-VOICEPRINT,
                                              DELETE-VOICEPRINT
    speech-complete-timeout         MANDATORY SET-PARAMS, GET-PARAMS
                                              VERIFY
    new-audio-channel               MANDATORY VERIFY, CLEAR-BUFFER
    abort-verification              MANDATORY STOP
    start-input-timers              MANDATORY VERIFY
 
 
 Repository-URI
 
    This parameter 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. If this header field is set through the
    SET-PARAMS method, it can be silently ignored.
 
      repository-uri = "Repository-URI" ":" Url 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 and is not require
    for identification operations.
 
      voiceprint-identifier = "Voiceprint-Identifier" ":" 1*VCHAR 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
    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,
 
 S Shanmugham                  IETF-Draft                      Page 103
                            MRCPv2 Protocol                  July 2004
 
 
    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 parameter 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
 
 
 Abort-Model
 
 
 S Shanmugham                  IETF-Draft                      Page 104
                            MRCPv2 Protocol                  July 2004
 
 
    The Abort-Model header field indicates the desired behavior of the
    verification resource upon session termination. If the value of this
    parameter 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, VERIFY and VERIFY-
    FROM-BUFFER 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 parameter 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
 
 
 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
 
 
 
 S Shanmugham                  IETF-Draft                      Page 105
                            MRCPv2 Protocol                  July 2004
 
 
    and used to determine a verification score. The value for this
    parameter 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-URL
 
    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 URL value of the
    header MUST be NULL if there was some error condition preventing the
    server from recording. Otherwise, the URL generated by the server
    SHOULD be globally unique across the server and all its verification
    sessions. The URL SHOULD BE available until the session is torn
    down. Since the save-waveform header field applies only to live
    verification / identification operations, the waveform-url will only
 
 S Shanmugham                  IETF-Draft                      Page 106
                            MRCPv2 Protocol                  July 2004
 
 
    be returned in the VERIFICATION-COMPLETE event for live verification
    / identification operations.
 
       waveform-url = "Waveform-URL" ":" Url 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-Url
 
    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-url    = "Input-Waveform-URL" ":" Url CRLF
 
 
 Verification-Type
 
    This optional header field specifies whether this is text-
    independent, text dependant or digit string based verification.  It
    MAY be part of the VERIFY method.  The default for this field is
    "text-independent".
 
      verification-type = "Verification-Type" ":"
 
 S Shanmugham                  IETF-Draft                      Page 107
                            MRCPv2 Protocol                  July 2004
 
 
                          verification-type-string
      verification-type-string = "text-independent"
                               / "text-dependent"
                               / "digits"
 
 Digit-Sequence
 
    This optional header field specifies the digit sequence to use for
    verification if the verification mode is "digits".  It MAY be part
    of the VERIFY method.
 
      digit-sequence = "digit-sequence" ":" 1*ALPHA CRLF
 
 Completion-Cause
 
    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*ALPHA 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.
 
 S Shanmugham                  IETF-Draft                      Page 108
                            MRCPv2 Protocol                  July 2004
 
 
        008       repository-uri-missing
                                     Repository-uri is not specified.
        007       voiceprint-id-missing
                                     Voiceprint-identification is not
                                     specified.
        008       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.
 
      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 parameter 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
 
 S Shanmugham                  IETF-Draft                      Page 109
                            MRCPv2 Protocol                  July 2004
 
 
    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 [12],
    having a MIME-type application/x-nlsml.  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 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/mrcp2">
             <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>
 
 S Shanmugham                  IETF-Draft                      Page 110
                            MRCPv2 Protocol                  July 2004
 
 
               <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/mrcp2">
             xmlns:xmpl="http://www.example.org/2003/12/mrcp2">
             <mrcp:result-type type="VERIFICATION" />
             <mrcp:verification-result>
               <voiceprint id="johnsmith">
                 <incremental>
                   <num-frames> 50 </num-frames>
                   <device> cellular-phone </device>
                   <gender> female </gender>
                   <needmoredata> true </needmoredata>
                   <verification-score> 98.514 </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> 193.450 </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. Num-Frames
       6. Device
       7. Gender
       8. Adapted
       9. Verification-Score
       10. Score
       11. Vendor-Specific-Results
 
 
 S Shanmugham                  IETF-Draft                      Page 111
                            MRCPv2 Protocol                  July 2004
 
 
 
    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.
 
    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.
 
      decision-string = "accepted" / "rejected" / "undecided"
      decision        = "<decision>" decision-string "</decision>" CRLF
 
 
    5. Num-Frames
    This is not a header field, but part of the verification results. It
    is returned in a VERIFICATION-COMPLETE event.  Its value indicates
    the number of 10 millisecond speech frames in the last utterance or
    in the cumulated set of utterances.
 
      num-frames          = "<num-frames>" 1*DIGIT "</num-frames>" CRLF
 
    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.
 
      device-string = "cellular-phone" / "electret-phone"
                      / "carbon-button-phone" / "unknown"
      device        = "<device>" device-string "</device>" CRLF
 
 S Shanmugham                  IETF-Draft                      Page 112
                            MRCPv2 Protocol                  July 2004
 
 
 
    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.
 
      gender-string = "male" / "female" / "unknown"
      gender        = "<gender>" gender-string "</gender>" CRLF
 
    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.
 
      adapted              = "<adapted>" Boolean-value "</adapted>" CRLF
 
    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 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.
 
      verification-score   = "<verification-score>" FLOAT
                             "</verification-score>" CRLF
 
    10. Score
    This element is found within the incremental or cumulative element
    within the verification results. This is the score associated with
    the identified member of the group, as returned in the member
    result. The value is floating point between 0.0 and 1.0. If there
    are no such utterances the score is 0.
 
      score               = "<score>" FLOAT "</score>" CRLF
 
    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
 
 
 
 S Shanmugham                  IETF-Draft                      Page 113
                            MRCPv2 Protocol                  July 2004
 
 
    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 Multi-Verification, this header would contain a list
    of command 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.
 
    A single session can be active at one time.
 
 Example:
    C->S:  MRCP/2.0 123 START-SESSION 314161
           Channel-Identifier: 32AECB23433801@speakverify
 
 
 
 S Shanmugham                  IETF-Draft                      Page 114
                            MRCPv2 Protocol                  July 2004
 
 
           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.
 
    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.
 
 S Shanmugham                  IETF-Draft                      Page 115
                            MRCPv2 Protocol                  July 2004
 
 
 
    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: 006 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.
 
    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.
 
 S Shanmugham                  IETF-Draft                      Page 116
                            MRCPv2 Protocol                  July 2004
 
 
 
    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.
 
    For VERIFY-FROM-BUFFER method, the server can optionally return an
    "IN-PROGRESS" response followed by the "VERIFICATION-COMPLETE"
    event.
 
 
 
 
 S Shanmugham                  IETF-Draft                      Page 117
                            MRCPv2 Protocol                  July 2004
 
 
    When the VERIFY-FROM-BUFFER method is invoked and the verification
    buffer is in use the server MUST return a failure response with a
    status-code of 402. 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.
 
 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/x-nlsml
           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>
 
 S Shanmugham                  IETF-Draft                      Page 118
                            MRCPv2 Protocol                  July 2004
 
 
                     <decision> rejected </decision>
                     <verification-score> -50 </verification-score>
                </incremental>
                <cumulative>
                     <num-frames> 50 </num-frames>
                     <device> cellular-phone </device>
                     <gender> female </gender>
                     <decision> rejected </decision>
                     <verification-score> -50 </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
           Completion-Cause: 000 success
           Content-Type: application/x-nlsml
           Content-Length: 123
 
           <?xml version="1.0"?>
           <result grammar="What-Grammar-URI">
           <extensions>
 
 S Shanmugham                  IETF-Draft                      Page 119
                            MRCPv2 Protocol                  July 2004
 
 
              <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> 50 </verification-score>
                </incremental>
                <cumulative>
                     <num-frames> 50 </num-frames>
                     <device> cellular-phone </device>
                     <gender> female </gender>
                     <decision> accepted </decision>
                     <verification-score> 50 </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->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
 
 S Shanmugham                  IETF-Draft                      Page 120
                            MRCPv2 Protocol                  July 2004
 
 
    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
 
 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
 
 S Shanmugham                  IETF-Draft                      Page 121
                            MRCPv2 Protocol                  July 2004
 
 
           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/x-nlsml
           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> 50 </verification-score>
                </incremental>
                <cumulative>
                     <num-frames> 150 </num-frames>
                     <device> cellular-phone </device>
                     <gender> female </gender>
                     <decision> accepted </decision>
                     <verification-score> 25 </verification-score>
                </cumulative>
                </voiceprint>
              </verification-result>
           </extensions>
           </result>
 
 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.
 
 
 S Shanmugham                  IETF-Draft                      Page 122
                            MRCPv2 Protocol                  July 2004
 
 
 
    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
           Content-Type: application/x-nlsml
           Content-Length: 123
 
           <?xml version="1.0"?>
           <result grammar="What-Grammar-URI">
           <extensions>
              <result-type type="VERIFICATION" />
              <verification-result>
 
 S Shanmugham                  IETF-Draft                      Page 123
                            MRCPv2 Protocol                  July 2004
 
 
                <voiceprint id="marysmith">
                <incremental>
                     <num-frames> 50 </num-frames>
                     <device> cellular-phone </device>
                     <gender> female </gender>
                     <decision> accepted </decision>
                     <verification-score> 50 </verification-score>
                </incremental>
                <cumulative>
                     <num-frames> 150 </num-frames>
                     <device> cellular-phone </device>
                     <gender> female </gender>
                     <decision> accepted </decision>
                     <verification-score> 25 </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 he client and server.
    All MRCPv2 servers MUST support Secure Real-Time Transport Protocol
    (SRTP) as an option to send and receive media.
 
 13.  Examples:
 
    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 124
                            MRCPv2 Protocol                  July 2004
 
 
           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.
 
    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
 
           v=0
 
 S Shanmugham                  IETF-Draft                      Page 125
                            MRCPv2 Protocol                  July 2004
 
 
           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=control 9 SCTP application/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
           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=control 32416 SCTP application/mrcpv2
           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
 
    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:
 
 S Shanmugham                  IETF-Draft                      Page 126
                            MRCPv2 Protocol                  July 2004
 
 
           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=control 9 SCTP application/mrcpv2
           a=resource:speechsynth
           a=cmid:1
           m=audio 49170 RTP/AVP 0 96
           a=rtpmap:0 pcmu/8000
           a=recvonly
           a=mid:1
           m=control 9 SCTP application/mrcpv2
           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
           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=control 32416 SCTP application/mrcpv2
           a=channel:32AECB23433801@speechsynth
           a=cmid:1
 
 S Shanmugham                  IETF-Draft                      Page 127
                            MRCPv2 Protocol                  July 2004
 
 
           m=audio 48260 RTP/AVP 0
           a=rtpmap:0 pcmu/8000
           a=sendonly
           a=mid:1
           m=control 32416 SCTP application/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/synthesis+ssml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
                    <sentence>You have 4 new messages.</sentence>
                    <sentence>The first is from <say-as
                    type="name">Stephanie Williams</say-as> <mark
           name="Stephanie"/>
                    and arrived at <break/>
                    <say-as type="time">3:45pm</say-as>.</sentence>
 
                    <sentence>The subject is <prosody
                    rate="-20%">ski trip</prosody></sentence>
           </paragraph>
           </speak>
 
    S->C:  MRCP/2.0 49 543257 200 IN-PROGRESS
           Channel-Identifier: 32AECB23433802@speechsynth
 
 S Shanmugham                  IETF-Draft                      Page 128
                            MRCPv2 Protocol                  July 2004
 
 
 
    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/grammar+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
           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
 
 S Shanmugham                  IETF-Draft                      Page 129
                            MRCPv2 Protocol                  July 2004
 
 
           Content-Type: application/sml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <speak>
           <paragraph>
                    <sentence>Welcome to ABC corporation.</sentence>
                    <sentence>Who would you like Talk to.</sentence>
           </paragraph>
           </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->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
 
 
 
 
 S Shanmugham                  IETF-Draft                      Page 130
                            MRCPv2 Protocol                  July 2004
 
 
    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-URL: http://web.media.com/session123/audio.wav
           Content-Type: application/x-nlsml
           Content-Length: 104
 
           <?xml version="1.0"?>
           <result x-model="http://IdentityModel"
             xmlns:xf="http://www.w3.org/2000/xforms"
             grammar="session:request1@form-level.store">
               <interpretation>
                   <xf:instance name="Person">
                       <Person>
                           <Name> Andre Roy </Name>
                       </Person>
                   </xf: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
           Content-Length: 0
 
 
 14.  Reference Documents
 
    [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.
 
 
 S Shanmugham                  IETF-Draft                      Page 131
                            MRCPv2 Protocol                  July 2004
 
 
    [4]    Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
           "SIP: Session Initiation Protocol", RFC 2543, March 1999.
 
    [6]    Handley, M. and V. Jacobson, "SDP: session description
           protocol", RFC 2327, April 1998.
 
    [7]    Robinson, F., Marquette, B., and R. Hernandez, "Using Media
           Resource Control Protocol with SIP", draft-robinson-mrcp-sip-
           00, (work in progress), September 2001.
 
     [8]   World Wide Web Consortium, "Voice Extensible Markup Language
           (VoiceXML) Version 2.0", W3C Candidate Recommendation, March
           2004.
 
     [9]   Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
           MESSAGES", RFC 822, August 1982.
 
     [10]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, March 1997.
 
     [11]  World Wide Web Consortium, "Speech Synthesis Markup Language
           (SSML)", W3C Candidate Recommendation, July 2004.
 
     [12]  World Wide Web Consortium, "Natural Language Semantics Markup
           Language (NLSML) for the Speech Interface Framework", W3C
           Working Draft, 30 May 2001.
 
     [13]  World Wide Web Consortium, "Speech Recognition Grammar
           Specification Version 1.0", W3C Candidate Recommendation,
           March 2004.
 
     [14]  Bradner, S., "The Internet Standards Process “ Revision 3",
           RFC 2026, October 1996
 
     [15]  Yergeau, F., "UTF-8, a transformation format of Unicode and
           ISO 10646", RFC 2044, October 1996
 
     [16]  Freed, N., Borenstein, N., "Multipupose Internet Mail
           Extensions (MIME) Part Two: Media Types", RFC 2046, November
           1996
 
     [17]  Levinson, E., "Content-ID and Message-ID Uniform Resource
           Locators", RFC 2111, March 1997
 
     [18]  Schulzrinne, H., Petrack, S., "RTP Payload for DTMF Digits,
           Telephony Tones and Telephony Signals", RFC 2833, May 2000
 
     [19]  Alvestrand, H., "Tags for the Identification of Languages",
           RFC 3066, January 2001
 
 
 
 
 S Shanmugham                  IETF-Draft                      Page 132
                            MRCPv2 Protocol                  July 2004
 
 
     [20]  Camarillo, G., Eriksson, G., Holler, J., "Grouping of Media
           Lines in the Session Description Protocol (SDP) ", RFC 3388,
           December 2002
 
     [21]  T. Bray et al., "Namespaces in XML", W3C Recommendation, 14
           January 1999. See http://www.w3.org/TR/1999/REC-xml-names-
           19990114.
 
 15.  Appendix
 
 15.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 /
                             ":" / "@" / "&" / "=" / "+" / "$" / ","
 
 
 S Shanmugham                  IETF-Draft                      Page 133
                            MRCPv2 Protocol                  July 2004
 
 
           alphanum       =    ALPHA / DIGIT
 
           escaped        =    "%" HEXDIG HEXDIG
 
           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  =  "&" / "=" / "+" / "$" / "," / ";"
                               / "?" / "/"
 
           password         =  *( unreserved / escaped /
 
 S Shanmugham                  IETF-Draft                      Page 134
                            MRCPv2 Protocol                  July 2004
 
 
                               "&" / "=" / "+" / "$" / "," )
 
           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   =    method-name SP request-id SP
                               mrcp-version CRLF
 
           status-line    =    mrcp-version SP request-id SP
                               status-code SP request-state CRLF
 
           event-line     =    event-name SP request-id SP
                               request-state SP mrcp-version CRLF
 
 S Shanmugham                  IETF-Draft                      Page 135
                            MRCPv2 Protocol                  July 2004
 
 
 
           method-name    =    generic-method
                          /    synthesizer-method
                          /    recorder-method
                          /    recognizer-method
                          /    verifier-method
                          /    extension-method
 
           extension-method =  1*(ALPHA / "-")
 
           generic-method =    "SET-PARAMS"
                          /    "GET-PARAMS"
 
           request-state  =    "COMPLETE"
                          /    "IN-PROGRESS"
                          /    "PENDING"
 
           event-name     =    synthesizer-event
                          /    recognizer-event
                          /    recorder-event
                          /    verifier-event
                          /    extension-event
 
           extension-event =   1*(ALPHA / "-")
 
           message-header =    1*(generic-header / resource-header)
 
           resource-header     =    recognizer-header
                               /    synthesizer-header
                               /    recorder-header
                               /    verifier-header
                               /    extension-header
 
           extension-header    =    1*(ALPHANUM) CRLF
 
           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
 
 
 S Shanmugham                  IETF-Draft                      Page 136
                            MRCPv2 Protocol                  July 2004
 
 
           request-id     =    1*DIGIT
 
           status-code    =    1*DIGIT
 
           channel-identifier  =    "Channel-Identifier" ":"
                                    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
 
           media-type     =    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
 
 S Shanmugham                  IETF-Draft                      Page 137
                            MRCPv2 Protocol                  July 2004
 
 
 
           logging-tag    =    "Logging-Tag" ":" 1*VCHAR CRLF
 
           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
 
           vendor-av-pair-name = 1*VCHAR
 
           vendor-av-pair-value = 1*VCHAR
 
           set-cookie     =       "Set-Cookie:" cookies
 
           cookies        =       1#cookie
 
           cookie         =       NAME "=" VALUE *(";" cookie-av)
 
           NAME           =       attribute
 
           VALUE          =       value
 
           cookie-av      =       "Comment" "=" value
                          /       "Domain" "=" value
                          /       "Max-Age" "=" value
                          /       "Path" "=" value
                          /       "Secure"
                          /       "Version" "=" 1*DIGIT
                          /       "Age" "=" delta-seconds
 
           set-cookie2    =       "Set-Cookie2:" cookies2
 
           cookies2       =       1#cookie2
 
           cookie2        =       NAME "=" VALUE *(";" cookie-av2)
 
           NAME           =       attribute
 
           VALUE          =       value
 
           cookie-av2     =       "Comment" "=" value
                          /       "CommentURL" "=" <"> http_URL <">
                          /       "Discard"
                          /       "Domain" "=" value
                          /       "Max-Age" "=" value
                          /       "Path" "=" value
                          /       "Port" [ "=" <"> portlist <"> ]
                          /       "Secure"
                          /       "Version" "=" 1*DIGIT
 
 S Shanmugham                  IETF-Draft                      Page 138
                            MRCPv2 Protocol                  July 2004
 
 
                          /       "Age" "=" delta-seconds
 
          portlist        =       1#portnum
 
          portnum         =       1*DIGIT
 
      ; Synthesizer ABNF
 
      synthesizer-method =     "SPEAK"
                          /    "STOP"
                          /    "PAUSE"
                          /    "RESUME"
                          /    "BARGE-IN-OCCURRED"
                          /    "CONTROL"
 
           synthesizer-event = "SPEECH-MARKER"
                          /    "SPEAK-COMPLETE"
 
           synthesizer-header = jump-target
                          /    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-target    =    "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"
 
 S Shanmugham                  IETF-Draft                      Page 139
                            MRCPv2 Protocol                  July 2004
 
 
                          /    "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
                               1*ALPHA 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-marker  =    "Speech-Marker" ":" 1*VCHAR 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
 
 
 S Shanmugham                  IETF-Draft                      Page 140
                            MRCPv2 Protocol                  July 2004
 
 
           speak-length   =    "Speak-Length" ":" 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"
 
           load-lexicon = "Load-Lexicon" : boolean CRLF
 
           lexicon-search-order = "Lexicon-Search-Order" : absoluteURI
                                     *[";" absoluteURI] CRLF
 
      ; Recognizer ABNF
 
           recognizer-method = recog-only-method
                          /    enrollment-method
 
           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
 
 S Shanmugham                  IETF-Draft                      Page 141
                            MRCPv2 Protocol                  July 2004
 
 
                          /    recognition-timeout
                          /    waveform-url
                          /    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
 
           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-url   =    "Waveform-URL" ":" absoluteURI CRLF
 
 S Shanmugham                  IETF-Draft                      Page 142
                            MRCPv2 Protocol                  July 2004
 
 
 
           completion-cause=   "Completion-Cause" ":" 1*DIGIT SP
                               1*ALPHA 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
 
           dtmf-term-char =    "DTMF-Term-Char" ":" [CHAR] CRLF
 
           fetch-timeout  =    "Fetch-Timeout" ":" [1*DIGIT] CRLF
 
           save-waveform  =    "Save-Waveform" ":" [boolean-value] CRLF
 
           new-audio-channel = "New-Audio-Channel" ":"
                               boolean-value CRLF
 
           recognition-mode =  "Recognition-Mode" ":" 1*ALPHA CRLF
 
           cancel-if-queue  =  "Cancel-If-Queue" ":" 1*ALPHA 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
 
 
 S Shanmugham                  IETF-Draft                      Page 143
                            MRCPv2 Protocol                  July 2004
 
 
           personal-grammar-uri =   "Personal-Grammar-URI" ":" Url CRLF
 
           phrase-id           =    "Phrase-ID" ":" 1*VCHAR CRLF
 
           phrase-nl           =    "Phrase-NL" ":" 1*VCHAR CRLF
 
           weight              =    "Weight" ":" WEIGHT CRLF
 
           save-best-waveform  =    "Save-Best-Waveform" ":"
                                    boolean-value CRLF
 
           new-phrase-id       =    "New-Phrase-ID" ":" 1*VCHAR CRLF
 
           confusable-phrases-uri = "Confusable-Phrases-URI" ":"
                                    Url CRLF
 
           abort-phrase-enrollment= "Abort-Phrase-Enrollment" ":"
                                    boolean- value CRLF
 
 
      ; 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-url
                          /    voiceprint-exists
                          /    ver-buffer-utterance
                          /    input-waveform-url
 
 S Shanmugham                  IETF-Draft                      Page 144
                            MRCPv2 Protocol                  July 2004
 
 
                          /    verification-type
                          /    digit-sequence
                          /    completion-cause
                          /    completion-reason
                          /    speech-complete-timeout
                          /    new-audio-channel
                          /    abort-verification
 
 
           repository-uri =    "Respository-URI" ":" Url CRLF
 
           voiceprint-identifier = "Voiceprint-Identifier" ":"
                               1*VCHAR [";" 1*VCHAR] CRLF
 
           verification-mode = "Verification-Mode" ":"
                               verification-mode-string
 
           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-min-verification-phrases = "Num-Max-Verification-Phrases"
                               ":" 1*DIGIT CRLF
 
           no-input-timeout =  "No-Input-Timeout" ":" [1*DIGIT] CRLF
 
           save-waveform       =    "Save-Waveform" ":"
                                    boolean-value CRLF
 
           waveform-url   =    "Waveform-URL" ":" Url CRLF
 
           voiceprint-exists = "Voiceprint-Exists" ":"
                               Boolean-value CRLF
 
           ver-buffer-utterance = "Ver-Buffer-Utterance" ":"
                               Boolean-value CRLF
 
 S Shanmugham                  IETF-Draft                      Page 145
                            MRCPv2 Protocol                  July 2004
 
 
 
           input-waveform-url = "Input-Waveform-URL" ":" Url CRLF
 
           verification-type = "Verification-Type" ":"
                               verification-type-string
 
           verification-type-string = "text-independent"
                          /    "text-dependent"
                          /    "digits"
 
           digit-sequence =    "digit-sequence" ":" 1*ALPHA CRLF
 
           completion-cause =  "Completion-Cause" ":" 1*DIGIT SP
                               1*ALPHA 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
                          /    media-type
                          /    max-time
                          /    final-silence
                          /    capture-on-speech
                          /    new-audio-channel
 
 
           sensitivity-level = "Sensitivity-Level" ":" [1*DIGIT] CRLF
 
           no-input-timeout  = "No-Input-Timeout" ":" [1*DIGIT] CRLF
 
           completion-cause  = "Completion-Cause" ":" 1*DIGIT SP
                               1*ALPHA CRLF
 
 S Shanmugham                  IETF-Draft                      Page 146
                            MRCPv2 Protocol                  July 2004
 
 
 
           failed-uri     =    "Failed-URI" ":" Url CRLF
 
           failed-uri-cause  = "Failed-URI-Cause" ":" 1*ALPHANUM CRLF
 
           record-uri     =    "Record-URI" ":" Url CRLF
 
           media-type     =    "Media-Type" ":" media-type CRLF
 
           max-time       =    "Max-Time" ":" 1*DIGIT CRLF
 
           final-silence  =    "Final-Silence" ":" 1*DIGIT CRLF
 
           capture-on-speech = "Capture-On-Speech " ":"
                               1*DIGIT CRLF
 
 15.2.     XML Schema and DTD
 
   Enrollment Schema
 
      <!-- 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>
 
 S Shanmugham                  IETF-Draft                      Page 147
                            MRCPv2 Protocol                  July 2004
 
 
                   </oneOrMore>
                 </element>
               </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 DTD
 
           <!--      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)>
 
   Verification Results Schema
 
      <!-- 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 148
                            MRCPv2 Protocol                  July 2004
 
 
             <start>
               <element name="verification-result">
                 <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>
                 </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>
               </interleave>
             </define>
 
             <define name="firstCommonContent">
               <interleave>
                 <choice>
 
 S Shanmugham                  IETF-Draft                      Page 149
                            MRCPv2 Protocol                  July 2004
 
 
                   <element name="decision">
                     <ref name="decisionContent"/>
                   </element>
                   <element name="needmoredata">
                     <ref name="needmoredataContent"/>
                   </element>
                 </choice>
                 <element name="num-frames">
                   <ref name="num-framesContent"/>
                 </element>
                 <element name="device">
                   <ref name="deviceContent"/>
                 </element>
                 <element name="gender">
                   <ref name="genderContent"/>
                 </element>
                 <element name="verification-score">
                   <ref name="verification-scoreContent"/>
                 </element>
               </interleave>
             </define>
 
             <define name="restCommonContent">
               <interleave>
                 <optional>
                   <element name="decision">
                     <ref name="decisionContent"/>
                   </element>
                 </optional>
                 <optional>
                   <element name="num-frames">
                     <ref name="num-framesContent"/>
                   </element>
                 </optional>
                 <optional>
                   <element name="device">
                     <ref name="deviceContent"/>
                   </element>
                 </optional>
                 <optional>
                   <element name="gender">
                     <ref name="genderContent"/>
                   </element>
                 </optional>
                 <element name="verification-score">
                   <ref name="verification-scoreContent"/>
                 </element>
               </interleave>
             </define>
 
             <define name="decisionContent">
 
 S Shanmugham                  IETF-Draft                      Page 150
                            MRCPv2 Protocol                  July 2004
 
 
               <choice>
                 <value>accepted</value>
                 <value>rejected</value>
                 <value>undecided</value>
               </choice>
             </define>
 
             <define name="needmoredataContent">
               <data type="boolean"/>
             </define>
 
             <define name="num-framesContent">
               <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 DTD
           <!--      MRCP Verification Results DTD
           -->
 
           <!ELEMENT verification-result (voiceprint+)>
           <!ELEMENT voiceprint (adapted?, incremental?, cumulative)>
           <!ATTLIST voiceprint id CDATA #REQUIRED>
           <!ELEMENT incremental ((decision | needmoredata)?,
                     num-frames?, device?, gender?, verification-score)>
           <!ELEMENT cumulative  ((decision | needmoredata)?,
 
 S Shanmugham                  IETF-Draft                      Page 151
                            MRCPv2 Protocol                  July 2004
 
 
                     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.
 
 
 Contributors
      Daniel C. Burnett
      Nuance Communications
 
 S Shanmugham                  IETF-Draft                      Page 152
                            MRCPv2 Protocol                  July 2004
 
 
      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)
    Ran Zilca (IBM Corp)
    Suresh Kaliannan (Cisco Systems Inc.)
    Skip Cave (Intervoice Inc)
 
 
 S Shanmugham                  IETF-Draft                      Page 153
                            MRCPv2 Protocol                  July 2004
 
 
 
 Editors' Addresses
 
    Saravanan Shanmugham
    Cisco Systems Inc.
    170 W Tasman Drive,
    San Jose,
    CA 95134
 
    Email: sarvi@cisco.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 S Shanmugham                  IETF-Draft                      Page 154
 

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/