diff options
Diffstat (limited to 'doc/rfc/rfc4463.txt')
| -rw-r--r-- | doc/rfc/rfc4463.txt | 4819 |
1 files changed, 4819 insertions, 0 deletions
diff --git a/doc/rfc/rfc4463.txt b/doc/rfc/rfc4463.txt new file mode 100644 index 0000000..37bb4eb --- /dev/null +++ b/doc/rfc/rfc4463.txt @@ -0,0 +1,4819 @@ + + + + + + +Network Working Group S. Shanmugham +Request for Comments: 4463 Cisco Systems, Inc. +Category: Informational P. Monaco + Nuance Communications + B. Eberman + Speechworks Inc. + April 2006 + + + A Media Resource Control Protocol (MRCP) + Developed by Cisco, Nuance, and Speechworks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +IESG Note + + This RFC is not a candidate for any level of Internet Standard. The + IETF disclaims any knowledge of the fitness of this RFC for any + purpose and in particular notes that the decision to publish is not + based on IETF review for such things as security, congestion control, + or inappropriate interaction with deployed protocols. The RFC Editor + has chosen to publish this document at its discretion. Readers of + this document should exercise caution in evaluating its value for + implementation and deployment. See RFC 3932 for more information. + + Note that this document uses a MIME type 'application/mrcp' which has + not been registered with the IANA, and is therefore not recognized as + a standard IETF MIME type. The historical value of this document as + an ancestor to ongoing standardization in this space, however, makes + the publication of this document meaningful. + + + + + + + + + + + + + +Shanmugham, et al. Informational [Page 1] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +Abstract + + This document describes a Media Resource Control Protocol (MRCP) that + was developed jointly by Cisco Systems, Inc., Nuance Communications, + and Speechworks, Inc. It is published as an RFC as input for further + IETF development in this area. + + MRCP controls media service resources like speech synthesizers, + recognizers, signal generators, signal detectors, fax servers, etc., + over a network. This protocol is designed to work with streaming + protocols like RTSP (Real Time Streaming Protocol) or SIP (Session + Initiation Protocol), which help establish control connections to + external media streaming devices, and media delivery mechanisms like + RTP (Real Time Protocol). + +Table of Contents + + 1. Introduction ....................................................3 + 2. Architecture ....................................................4 + 2.1. Resources and Services .....................................4 + 2.2. Server and Resource Addressing .............................5 + 3. MRCP Protocol Basics ............................................5 + 3.1. Establishing Control Session and Media Streams .............5 + 3.2. MRCP over RTSP .............................................6 + 3.3. Media Streams and RTP Ports ................................8 + 4. Notational Conventions ..........................................8 + 5. MRCP Specification ..............................................9 + 5.1. Request ...................................................10 + 5.2. Response ..................................................10 + 5.3. Event .....................................................12 + 5.4. Message Headers ...........................................12 + 6. Media Server ...................................................19 + 6.1. Media Server Session ......................................19 + 7. Speech Synthesizer Resource ....................................21 + 7.1. Synthesizer State Machine .................................22 + 7.2. Synthesizer Methods .......................................22 + 7.3. Synthesizer Events ........................................23 + 7.4. Synthesizer Header Fields .................................23 + 7.5. Synthesizer Message Body ..................................29 + 7.6. SET-PARAMS ................................................32 + 7.7. GET-PARAMS ................................................32 + 7.8. SPEAK .....................................................33 + 7.9. STOP ......................................................34 + 7.10. BARGE-IN-OCCURRED ........................................35 + 7.11. PAUSE ....................................................37 + 7.12. RESUME ...................................................37 + 7.13. CONTROL ..................................................38 + 7.14. SPEAK-COMPLETE ...........................................40 + + + +Shanmugham, et al. Informational [Page 2] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 7.15. SPEECH-MARKER ............................................41 + 8. Speech Recognizer Resource .....................................42 + 8.1. Recognizer State Machine ..................................42 + 8.2. Recognizer Methods ........................................42 + 8.3. Recognizer Events .........................................43 + 8.4. Recognizer Header Fields ..................................43 + 8.5. Recognizer Message Body ...................................51 + 8.6. SET-PARAMS ................................................56 + 8.7. GET-PARAMS ................................................56 + 8.8. DEFINE-GRAMMAR ............................................57 + 8.9. RECOGNIZE .................................................60 + 8.10. STOP .....................................................63 + 8.11. GET-RESULT ...............................................64 + 8.12. START-OF-SPEECH ..........................................64 + 8.13. RECOGNITION-START-TIMERS .................................65 + 8.14. RECOGNITON-COMPLETE ......................................65 + 8.15. DTMF Detection ...........................................67 + 9. Future Study ...................................................67 + 10. Security Considerations .......................................67 + 11. RTSP-Based Examples ...........................................67 + 12. Informative References ........................................74 + Appendix A. ABNF Message Definitions ..............................76 + Appendix B. Acknowledgements ......................................84 + +1. Introduction + + The Media Resource Control Protocol (MRCP) is designed to provide a + mechanism for a client device requiring audio/video stream processing + to control processing resources on the network. These media + processing resources may be speech recognizers (a.k.a. Automatic- + Speech-Recognition (ASR) engines), speech synthesizers (a.k.a. Text- + To-Speech (TTS) engines), fax, signal detectors, etc. MRCP allows + implementation of distributed Interactive Voice Response platforms, + for example VoiceXML [6] interpreters. The MRCP protocol defines the + requests, responses, and events needed to control the media + processing resources. The MRCP protocol defines the state machine + for each resource and the required state transitions for each request + and server-generated event. + + The MRCP protocol does not address how the control session is + established with the server and relies on the Real Time Streaming + Protocol (RTSP) [2] to establish and maintain the session. The + session control protocol is also responsible for establishing the + media connection from the client to the network server. The MRCP + protocol and its messaging is designed to be carried over RTSP or + another protocol as a MIME-type similar to the Session Description + Protocol (SDP) [5]. + + + + +Shanmugham, et al. Informational [Page 3] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 [8]. + +2. Architecture + + The system consists of a client that requires media streams generated + or needs media streams processed and a server that has the resources + or devices to process or generate the streams. The client + establishes a control session with the server for media processing + using a protocol such as RTSP. This will also set up and establish + the RTP stream between the client and the server or another RTP + endpoint. Each resource needed in processing or generating the + stream is addressed or referred to by a URL. The client can now use + MRCP messages to control the media resources and affect how they + process or generate the media stream. + + |--------------------| + ||------------------|| |----------------------| + || Application Layer|| ||--------------------|| + ||------------------|| || TTS | ASR | Fax || + || ASR/TTS API || ||Plugin|Plugin|Plugin|| + ||------------------|| || on | on | on || + || MRCP Core || || MRCP | MRCP | MRCP || + || Protocol Stack || ||--------------------|| + ||------------------|| || RTSP Stack || + || RTSP Stack || || || + ||------------------|| ||--------------------|| + || TCP/IP Stack ||========IP=========|| TCP/IP Stack || + ||------------------|| ||--------------------|| + |--------------------| |----------------------| + + MRCP client Real-time Streaming MRCP + media server + +2.1. Resources and Services + + The server is set up to offer a certain set of resources and services + to the client. These resources are of 3 types. + + Transmission Resources + + These are resources that are capable of generating real-time streams, + like signal generators that generate tones and sounds of certain + frequencies and patterns, and speech synthesizers that generate + spoken audio streams, etc. + + + + + +Shanmugham, et al. Informational [Page 4] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Reception Resources + + These are resources that receive and process streaming data like + signal detectors and speech recognizers. + + Dual Mode Resources + + These are resources that both send and receive data like a fax + resource, capable of sending or receiving fax through a two-way RTP + stream. + +2.2. Server and Resource Addressing + + The server as a whole is addressed using a container URL, and the + individual resources the server has to offer are reached by + individual resource URLs within the container URL. + + RTSP Example: + + A media server or container URL like, + + rtsp://mediaserver.com/media/ + + may contain one or more resource URLs of the form, + + rtsp://mediaserver.com/media/speechrecognizer/ + rtsp://mediaserver.com/media/speechsynthesizer/ + rtsp://mediaserver.com/media/fax/ + +3. MRCP Protocol Basics + + The message format for MRCP 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 MRCP message between the client and the server resource. The + protocol does not address session control management, media + management, reliable sequencing, and delivery or server or resource + addressing. These are left to a protocol like SIP or RTSP. MRCP + addresses the issue of controlling and communicating with the + resource processing the stream, and defines the requests, responses, + and events needed to do that. + +3.1. Establishing Control Session and Media Streams + + The control session between the client and the server is established + using a protocol like RTSP. This protocol will also set up the + appropriate RTP streams between the server and the client, allocating + ports and setting up transport parameters as needed. Each control + + + +Shanmugham, et al. Informational [Page 5] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + session is identified by a unique session-id. The format, usage, and + life cycle of the session-id is in accordance with the RTSP protocol. + The resources within the session are addressed by the individual + resource URLs. + + The MRCP protocol is designed to work with and tunnel through another + protocol like RTSP, and augment its capabilities. MRCP relies on + RTSP headers for sequencing, reliability, and addressing to make sure + that messages get delivered reliably and in the correct order and to + the right resource. The MRCP messages are carried in the RTSP + message body. The media server delivers the MRCP message to the + appropriate resource or device by looking at the session-level + message headers and URL information. Another protocol, such as SIP + [4], could be used for tunneling MRCP messages. + +3.2. MRCP over RTSP + + RTSP supports both TCP and UDP mechanisms for the client to talk to + the server and is differentiated by the RTSP URL. All MRCP based + media servers MUST support TCP for transport and MAY support UDP. + + In RTSP, the ANNOUNCE method/response MUST be used to carry MRCP + request/responses between the client and the server. MRCP messages + MUST NOT be communicated in the RTSP SETUP or TEARDOWN messages. + + Currently all RTSP messages are request/responses and there is no + support for asynchronous events in RTSP. This is because RTSP was + designed to work over TCP or UDP and, hence, could not assume + reliability in the underlying protocol. Hence, when using MRCP over + RTSP, an asynchronous event from the MRCP server is packaged in a + server-initiated ANNOUNCE method/response communication. A future + RTSP extension to send asynchronous events from the server to the + client would provide an alternate vehicle to carry such asynchronous + MRCP events from the server. + + An RTSP session is created when an RTSP SETUP message is sent from + the client to a server and is addressed to a server URL or any one of + its resource URLs without specifying a session-id. The server will + establish a session context and will respond with a session-id to the + client. This sequence will also set up the RTP transport parameters + between the client and the server, and then the server will be ready + to receive or send media streams. If the client wants to attach an + additional resource to an existing session, the client should send + that session's ID in the subsequent SETUP message. + + + + + + + +Shanmugham, et al. Informational [Page 6] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + When a media server implementing MRCP over RTSP receives a PLAY, + RECORD, or PAUSE RTSP method from an MRCP resource URL, it should + respond with an RTSP 405 "Method not Allowed" response. For these + resources, the only allowed RTSP methods are SETUP, TEARDOWN, + DESCRIBE, and ANNOUNCE. + + Example 1: + + C->S: ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:4 + Session:12345678 + Content-Type:application/mrcp + Content-Length:223 + + SPEAK 543257 MRCP/1.0 + 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: RTSP/1.0 200 OK + CSeq: 4 + Session:12345678 + RTP-Info:url=rtsp://media.server.com/media/synthesizer; + seq=9810092;rtptime=3450012 + Content-Type:application/mrcp + Content-Length:52 + + MRCP/1.0 543257 200 IN-PROGRESS + + S->C: ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:6 + Session:12345678 + + + +Shanmugham, et al. Informational [Page 7] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Content-Type:application/mrcp + Content-Length:123 + + SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0 + + C->S: RTSP/1.0 200 OK + CSeq:6 + + For the sake of brevity, most examples from here on show only the + MRCP messages and do not show the RTSP message and headers in which + they are tunneled. Also, RTSP messages such as response that are not + carrying an MRCP message are also left out. + +3.3. Media Streams and RTP Ports + + A single set of RTP/RTCP ports is negotiated and shared between the + MRCP client and server when multiple media processing resources, such + as automatic speech recognition (ASR) engines and text to speech + (TTS) engines, are used for a single session. The individual + resource instances allocated on the server under a common session + identifier will feed from/to that single RTP stream. + + The client can send multiple media streams towards the server, + differentiated by using different synchronized source (SSRC) + identifier values. Similarly the server can use multiple + Synchronized Source (SSRC) identifier values to differentiate media + streams originating from the individual transmission resource URLs if + more than one exists. The individual resources may, on the other + hand, work together to send just one stream to the client. This is + up to the implementation of the media server. + +4. Notational Conventions + + 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] refers 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) similar to that used + in [H2.1]. It is described in detail in RFC 4234 [3]. + + The ABNF provided along with the descriptive text is informative in + nature and may not be complete. The complete message format in ABNF + form is provided in Appendix A and is the normative format + definition. + + + + + +Shanmugham, et al. Informational [Page 8] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +5. MRCP Specification + + The MRCP PDU is textual using an ISO 10646 character set in the UTF-8 + encoding (RFC 3629 [12]) to allow many different languages to be + represented. However, to assist in compact representations, MRCP + also allows other character sets such as ISO 8859-1 to be used when + desired. The MRCP 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 + MRCP 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. + + The whole MRCP PDU is encoded in the body of the session level + message as a MIME entity of type application/mrcp. The individual + MRCP messages do not have addressing information regarding which + resource the request/response are to/from. Instead, the MRCP message + relies on the header of the session level message carrying it to + deliver the request to the appropriate resource, or to figure out who + the response or event is from. + + The MRCP 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 ] + + message-body = *OCTET + + start-line = request-line / status-line / event-line + + 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. + + + + +Shanmugham, et al. Informational [Page 9] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 + + An MRCP 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 = method-name SP request-id SP + mrcp-version CRLF + + The request-id field is a unique identifier created by the client and + sent to the server. The server resource should 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 = synthesizer-method + / recognizer-method + + The mrcp-version field is the MRCP protocol version that is being + used by the client. + + mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT + +5.2. Response + + After receiving and interpreting the request message, the server + resource responds with an MRCP response message. It consists of a + status line optionally followed by a message body. + + response-line = mrcp-version SP request-id SP status-code SP + request-state CRLF + + + + + +Shanmugham, et al. Informational [Page 10] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + The mrcp-version field used here is similar to the one used in the + Request Line and indicates the version of MRCP 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 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" + +5.2.1. Status Codes + + The status codes are classified under the Success(2XX) codes and the + Failure(4XX) codes. + +5.2.1.1. Success 2xx + + 200 Success + 201 Success with some optional parameters ignored. + +5.2.1.2. 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 + + + + +Shanmugham, et al. Informational [Page 11] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 409 Unsupported Parameter Value + 421-499 Resource specific Failure codes + +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 is 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 = event-name SP request-id SP request-state SP + mrcp-version CRLF + + The mrcp-version used here is identical to the one used in the + Request/Response Line and indicates the version of MRCP protocol + running on the server. + + The request-id used in the event should 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.2. 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 + +5.4. Message Headers + + MRCP header fields, which include general-header (Section 5.4) and + resource-specific-header (Sections 7.4 and 8.4), follow the same + generic format as that given in Section 2.1 of RFC 2822 [7]. 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 linear whitespace (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. + + + + +Shanmugham, et al. Informational [Page 12] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + message-header = 1*(generic-header / resource-header) + + 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. Therefore, the order in which header fields + with the same field-name are received is 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 Headers + + generic-header = active-request-id-list + / proxy-sync-id + / content-id + / content-type + / content-length + / content-base + / content-location + / content-encoding + / cache-control + / logging-tag + + All headers in MRCP will be case insensitive, consistent with HTTP + and RTSP protocol header definitions. + +5.4.1. Active-Request-Id-List + + In a request, this field indicates the list of request-ids to which + it should apply. 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 were in progress or just completed. 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 + + + + + +Shanmugham, et al. Informational [Page 13] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + or IN-PROGRESS requests is sent from the client to the server, the + response MUST contain the list of request-ids that were affected in + this 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) that has one or more + SPEAK requests in the PENDING or IN-PROGRESS state, all SPEAK + requests MUST be cancelled, including the one IN-PROGRESS. In + addition, the response to the STOP request would contain the + request-id of all the SPEAK requests that were terminated in the + active-request-id-list. In this case, no SPEAK-COMPLETE or + RECOGNITION-COMPLETE events will be sent for these terminated + requests. + + active-request-id-list = "Active-Request-Id-List" ":" request-id + *("," request-id) CRLF + +5.4.2. 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 (Section 7.10) 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*ALPHA CRLF + +5.4.3. 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 Natural Language Semantics Markup Language (NLSML) results of a + RECOGNITON-COMPLETE event. + + + + + + + + +Shanmugham, et al. Informational [Page 14] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +5.4.4. Content-Type + + See [H14.17]. Note that the content types suitable for MRCP 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 + MRCP specific headers. + +5.4.5. Content-Id + + This field contains an ID or name for the content, by which it can be + referred to. The definition of this field conforms to RFC 2392 [14], + RFC 2822 [7], RFC 2046 [13] and is needed in multi-part messages. In + MRCP 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. + +5.4.6. Content-Base + + The content-base entity-header field may be used to specify the base + URI for resolving relative URLs within the entity. + + content-base = "Content-Base" ":" absoluteURI CRLF + + Note, however, that the base URI of the contents within the entity- + body may be redefined within that entity-body. An example of this + would be a multi-part MIME entity, which in turn can have multiple + entities within it. + +5.4.7. 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 has 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 = token + + + + +Shanmugham, et al. Informational [Page 15] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + token = 1*(alphanum / "-" / "." / "!" / "%" / "*" + / "_" / "+" / "`" / "'" / "~" ) + + Content coding is defined in [H3.5]. An example of its use is + + Content-Encoding:gzip + + If multiple encodings have been applied to an entity, the content + codings MUST be listed in the order in which they were applied. + +5.4.8. 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 media server MAY use this header field to optimize + certain operations. When providing this header field, the entity + being sent should not have been modified from what was retrieved from + the content-location URI. + + For example, if the client provided a grammar markup inline, and it + had previously retrieved it from a certain URI, that URI can be + provided as part of the entity, using the content-location header + field. This allows a resource like the recognizer to look into its + cache to see if this grammar was previously retrieved, compiled, and + cached. In which case, it might optimize by using the previously + compiled grammar object. + + If the content-location is a relative URI, the relative URI is + interpreted relative to the content-base URI. + +5.4.9. 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]. + + + + + +Shanmugham, et al. Informational [Page 16] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +5.4.10. Cache-Control + + If the media 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 media 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 SHOULD apply for + all requests for documents the media server may make in that session. + If the directives are sent on any other messages, they MUST only + apply to document requests the media server needs to make for that + method. An empty cache-control header on the GET-PARAMS method is a + request for the media server to return the current cache-control + directives setting on the server. + + 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 + + delta-seconds = 1*DIGIT + + Here, delta-seconds is a time value to be specified as an integer + number of seconds, represented in decimal, after the time that the + message response or data was received by the media server. + + These directives allow the media server to override the basic + expiration mechanism. + + max-age + + Indicates that the client is OK with the media 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 media server + using a response whose freshness lifetime is no less than its + current age plus the specified time in seconds. That is, the + + + +Shanmugham, et al. Informational [Page 17] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + client wants the media 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 media server + using a response that has exceeded its expiration time. If max- + stale is assigned a value, then the client is willing to accept + the media 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 + media server using a stale response of any age. + + The media 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 MRCP cache-control directive and the cached entry on the + media 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. + +5.4.11. 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 media server. + Once set, the value persists until a new value is set or the session + is ended. The MRCP 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. + + MRCP 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 MRCP server's + output logs in undefined. + + logging-tag = "Logging-Tag" ":" 1*ALPHA CRLF + + + + + + + + + + + +Shanmugham, et al. Informational [Page 18] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +6. Media Server + + The capability of media server resources can be found using the RTSP + DESCRIBE mechanism. When a client issues an RTSP DESCRIBE method for + a media resource URI, the media server response MUST contain an SDP + description in its body describing the capabilities of the media + server resource. The SDP description MUST contain at a minimum the + media header (m-line) describing the codec and other media related + features it supports. It MAY contain another SDP header as well, but + support for it is optional. + + The usage of SDP messages in the RTSP message body and its + application follows the SIP RFC 2543 [4], but is limited to media- + related negotiation and description. + +6.1. Media Server Session + + As discussed in Section 3.2, a client/server should share one RTSP + session-id for the different resources it may use under the same + session. The client MUST allocate a set of client RTP/RTCP ports for + a new session and MUST NOT send a Session-ID in the SETUP message for + the first resource. The server then creates a Session-ID and + allocates a set of server RTP/RTCP ports and responds to the SETUP + message. + + If the client wants to open more resources with the same server under + the same session, it will send the session-id (that it got in the + earlier SETUP response) in the SETUP for the new resource. A SETUP + message with an existing session-id tells the server that this new + resource will feed from/into the same RTP/RTCP stream of that + existing session. + + If the client wants to open a resource from a media server that is + not where the first resource came from, it will send separate SETUP + requests with no session-id header field in them. Each server will + allocate its own session-id and return it in the response. Each of + them will also come back with their own set of RTP/RTCP ports. This + would be the case when the synthesizer engine and the recognition + engine are on different servers. + + The RTSP SETUP method SHOULD contain an SDP description of the media + stream being set up. The RTSP SETUP response MUST contain an SDP + description of the media stream that it expects to receive and send + on that session. + + The SDP description in the SETUP method from the client SHOULD + describe the required media parameters like codec, Named Signaling + Event (NSE) payload types, etc. This could have multiple media + + + +Shanmugham, et al. Informational [Page 19] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + headers (i.e., m-lines) to allow the client to provide the media + server with more than one option to choose from. + + The SDP description in the SETUP response should reflect the media + parameters that the media server will be using for the stream. It + should be within the choices that were specified in the SDP of the + SETUP method, if one was provided. + + Example: + + C->S: + + SETUP rtsp://media.server.com/recognizer/ RTSP/1.0 + CSeq:1 + Transport:RTP/AVP;unicast;client_port=46456-46457 + Content-Type:application/sdp + Content-Length:190 + + v=0 + o=- 123 456 IN IP4 10.0.0.1 + s=Media Server + p=+1-888-555-1212 + c=IN IP4 0.0.0.0 + t=0 0 + m=audio 46456 RTP/AVP 0 96 + a=rtpmap:0 pcmu/8000 + a=rtpmap:96 telephone-event/8000 + a=fmtp:96 0-15 + + S->C: + + RTSP/1.0 200 OK + CSeq:1 + Session:0a030258_00003815_3bc4873a_0001_0000 + Transport:RTP/AVP;unicast;client_port=46456-46457; + server_port=46460-46461 + Content-Length:190 + Content-Type:application/sdp + + v=0 + o=- 3211724219 3211724219 IN IP4 10.3.2.88 + s=Media Server + c=IN IP4 0.0.0.0 + t=0 0 + m=audio 46460 RTP/AVP 0 96 + a=rtpmap:0 pcmu/8000 + a=rtpmap:96 telephone-event/8000 + a=fmtp:96 0-15 + + + +Shanmugham, et al. Informational [Page 20] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + If an SDP description was not provided in the RTSP SETUP method, then + the media server may decide on parameters of the stream but MUST + specify what it chooses in the SETUP response. An SDP announcement + is only returned in a response to a SETUP message that does not + specify a Session. That is, the server will not return an SDP + announcement for the synthesizer SETUP of a session already + established with a recognizer. + + C->S: + + SETUP rtsp://media.server.com/recognizer/ RTSP/1.0 + CSeq:1 + Transport:RTP/AVP;unicast;client_port=46498 + + S->C: + + RTSP/1.0 200 OK + CSeq:1 + Session:0a030258_000039dc_3bc48a13_0001_0000 + Transport:RTP/AVP;unicast; client_port=46498; + server_port=46502-46503 + Content-Length:193 + Content-Type:application/sdp + + v=0 + o=- 3211724947 3211724947 IN IP4 10.3.2.88 + s=Media Server + c=IN IP4 0.0.0.0 + t=0 0 + m=audio 46502 RTP/AVP 0 101 + a=rtpmap:0 pcmu/8000 + a=rtpmap:101 telephone-event/8000 + a=fmtp:101 0-15 + +7. 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 MRCP 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. + + + + + + +Shanmugham, et al. Informational [Page 21] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.1. Synthesizer State Machine + + The synthesizer maintains states because it needs to correlate MRCP + requests from the client. The state transitions shown below describe + the states of the synthesizer and reflect the request at the head of + the queue. A SPEAK request in the PENDING state can be deleted or + stopped by a STOP request and does not affect the state of the + resource. + + Idle Speaking Paused + State State State + | | | + |----------SPEAK------->| |--------| + |<------STOP------------| CONTROL | + |<----SPEAK-COMPLETE----| |------->| + |<----BARGE-IN-OCCURRED-| | + | |--------| | + | CONTROL |-----------PAUSE--------->| + | |------->|<----------RESUME---------| + | | |----------| + | | PAUSE | + | | |--------->| + | |--------|----------| | + | BARGE-IN-OCCURRED | SPEECH-MARKER | + | |------->|<---------| | + |----------| | |------------| + | STOP | SPEAK | + | | | |----------->| + |<---------| | + |<-------------------STOP--------------------------| + +7.2. Synthesizer Methods + + The synthesizer supports the following methods. + + synthesizer-method = "SET-PARAMS" + / "GET-PARAMS" + / "SPEAK" + / "STOP" + / "PAUSE" + / "RESUME" + / "BARGE-IN-OCCURRED" + / "CONTROL" + + + + + + + + +Shanmugham, et al. Informational [Page 22] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.3. Synthesizer Events + + The synthesizer may generate the following events. + + synthesizer-event = "SPEECH-MARKER" + / "SPEAK-COMPLETE" + +7.4. Synthesizer Header Fields + + A synthesizer message may contain header fields containing request + options and information to augment the Request, Response, or Event of + the message with which it is associated. + + synthesizer-header = jump-target ; Section 7.4.1 + / kill-on-barge-in ; Section 7.4.2 + / speaker-profile ; Section 7.4.3 + / completion-cause ; Section 7.4.4 + / voice-parameter ; Section 7.4.5 + / prosody-parameter ; Section 7.4.6 + / vendor-specific ; Section 7.4.7 + / speech-marker ; Section 7.4.8 + / speech-language ; Section 7.4.9 + / fetch-hint ; Section 7.4.10 + / audio-fetch-hint ; Section 7.4.11 + / fetch-timeout ; Section 7.4.12 + / failed-uri ; Section 7.4.13 + / failed-uri-cause ; Section 7.4.14 + / speak-restart ; Section 7.4.15 + / speak-length ; Section 7.4.16 + + 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 + voice-parameter MANDATORY SET-PARAMS, GET-PARAMS, + SPEAK, CONTROL + prosody-parameter MANDATORY SET-PARAMS, GET-PARAMS, + SPEAK, CONTROL + vendor-specific MANDATORY SET-PARAMS, GET-PARAMS + 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 + + + +Shanmugham, et al. Informational [Page 23] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + failed-uri MANDATORY Any + failed-uri-cause MANDATORY Any + speak-restart MANDATORY CONTROL + speak-length MANDATORY SPEAK, CONTROL + +7.4.1. Jump-Target + + 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*ALPHA SP "Tag" + numeric-speech-length= ("+" / "-") 1*DIGIT SP + numeric-speech-unit + numeric-speech-unit = "Second" + / "Word" + / "Sentence" + / "Paragraph" + +7.4.2. 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 RTSP session-id 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 barge-in-able event from the synthesizer resource + + + + + +Shanmugham, et al. Informational [Page 24] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + or signal detector resource. These resources MAY BE local or + distributed. If this field is not specified, the value defaults to + "true". + +7.4.3. 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 + the speaker by a URI, which may be a set of voice parameters like + gender, accent, etc. + + speaker-profile = "Speaker-Profile" ":" uri CRLF + +7.4.4. 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. + +7.4.5. 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 [9]. The voice-param-value is any one of the value + choices of the corresponding voice element attribute specified in the + above section. + + + + +Shanmugham, et al. Informational [Page 25] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 Speech Synthesis Markup Language (SSML). + + 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. + +7.4.6. 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 [9]. 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. + Furthermore, these attributes can be part of the speech text marked + up in SSML. + + 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 to 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. + + + + + + + + + + + +Shanmugham, et al. Informational [Page 26] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.4.7. 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. + +7.4.8. Speech Marker + + This header field contains a marker tag that may be embedded in the + speech data. Most speech markup formats provide mechanisms to embed + marker fields between speech texts. The synthesizer will generate + SPEECH-MARKER events when it reaches these marker fields. This field + SHOULD be part of the SPEECH-MARKER event and will contain the marker + tag values. + + speech-marker = "Speech-Marker" ":" 1*ALPHA CRLF + +7.4.9. Speech Language + + This header field specifies the default language of the speech data + if it is not specified in the speech data. The value of this header + field should follow RFC 3066 [16] for its values. This MAY occur in + SPEAK, SET-PARAMS, or GET-PARAMS request. + + speech-language = "Speech-Language" ":" 1*ALPHA CRLF + + + + + + + + + +Shanmugham, et al. Informational [Page 27] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.4.10. 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 + +7.4.11. 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 + +7.4.12. 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 resources the + media 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 + +7.4.13. Failed URI + + When a synthesizer method needs a synthesizer to fetch or access a + URI, and the access fails, the media server SHOULD provide the failed + URI in this header field in the method response. + + failed-uri = "Failed-URI" ":" Url CRLF + + + + + + +Shanmugham, et al. Informational [Page 28] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.4.14. Failed URI Cause + + When a synthesizer method needs a synthesizer to fetch or access a + URI, and the access fails, the media 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*ALPHA CRLF + +7.4.15. 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 + +7.4.16. 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 until the tag is reached or the SPEAK request complete, + whichever comes first. This MAY BE specified in a SPEAK request to + indicate the length to speak in the speech data and is relative to + the point in speech where 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". + + speak-length = "Speak-Length" ":" speech-length-value + CRLF + +7.5. Synthesizer Message Body + + A synthesizer message may contain additional information associated + with the Method, Response, or Event in its message body. + + + + + + + +Shanmugham, et al. Informational [Page 29] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.5.1. 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 media server. + + All media servers MUST support plain text speech data and W3C's + Speech Synthesis Markup Language [9] at 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 URIs that will + list what needs to be spoken. If a list of speech URIs is specified, + speech data provided by each URI must be spoken in the order in which + the URI are specified. + + If the data to be spoken consists of a mix of URI and inline speech + data, the multipart/mixed MIME-type is used and embedded with the + MIME-blocks for text/uri-list, application/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, then stored in memory or a local device, and that + it currently needs to play 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.cisco.com/ASR-Introduction.sml + http://www.cisco.com/ASR-Document-Part1.sml + http://www.cisco.com/ASR-Document-Part2.sml + http://www.cisco.com/ASR-Conclusion.sml + + Example 2: + Content-Type:application/synthesis+ssml + Content-Length:104 + + <?xml version="1.0"?> + + + +Shanmugham, et al. Informational [Page 30] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + <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 + + http://www.cisco.com/ASR-Introduction.sml + http://www.cisco.com/ASR-Document-Part1.sml + http://www.cisco.com/ASR-Document-Part2.sml + http://www.cisco.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 + + + + + + + + +Shanmugham, et al. Informational [Page 31] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.6. SET-PARAMS + + The SET-PARAMS method, from the client to server, tells the + synthesizer resource to define default synthesizer context + parameters, like voice characteristics and prosody, 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 or have illegal + values, the server accepts and sets the remaining 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. + + Example: + C->S:SET-PARAMS 543256 MRCP/1.0 + Voice-gender:female + Voice-category:adult + Voice-variant:3 + + S->C:MRCP/1.0 543256 200 COMPLETE + +7.7. GET-PARAMS + + The GET-PARAMS method, from the client to server, asks the + synthesizer resource for its current synthesizer context parameters, + like voice characteristics and prosody, etc. The client SHOULD send + the list of parameters 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. + + Example: + C->S:GET-PARAMS 543256 MRCP/1.0 + Voice-gender: + Voice-category: + Voice-variant: + Vendor-Specific-Parameters:com.mycorp.param1; + com.mycorp.param2 + + S->C:MRCP/1.0 543256 200 COMPLETE + Voice-gender:female + Voice-category:adult + Voice-variant:3 + + + +Shanmugham, et al. Informational [Page 32] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Vendor-Specific-Parameters:com.mycorp.param1="Company Name"; + com.mycorp.param2="124324234@mycorp.com" + +7.8. SPEAK + + The SPEAK method from the client to the server provides the + synthesizer resource with the speech text and initiates speech + synthesis and streaming. The SPEAK method can carry voice and + prosody header fields that define the behavior of the voice being + synthesized, as well as the actual marked-up text to be spoken. If + specific voice and prosody parameters are specified as part of the + 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 that 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:SPEAK 543257 MRCP/1.0 + Voice-gender:neutral + Voice-category:teenager + Prosody-volume:medium + Content-Type:application/synthesis+ssml + Content-Length:104 + + + + + + +Shanmugham, et al. Informational [Page 33] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + <?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/1.0 543257 200 IN-PROGRESS + + S->C:SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0 + Completion-Cause:000 normal + +7.9. 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. + + + + + + + +Shanmugham, et al. Informational [Page 34] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Example: + C->S:SPEAK 543258 MRCP/1.0 + 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/1.0 543258 200 IN-PROGRESS + + C->S:STOP 543259 200 MRCP/1.0 + + S->C:MRCP/1.0 543259 200 COMPLETE + Active-Request-Id-List:543258 + +7.10. 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 + + + +Shanmugham, et al. Informational [Page 35] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 on the same server, they + could be optimized for a quicker kill-on-barge-in response by having + them interact directly based on a common RTSP session-id. In these + cases, the client MUST still proxy the recognition 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:SPEAK 543258 MRCP/1.0 + 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/1.0 543258 200 IN-PROGRESS + + C->S:BARGE-IN-OCCURRED 543259 200 MRCP/1.0 + Proxy-Sync-Id:987654321 + + S->C:MRCP/1.0 543259 200 COMPLETE + Active-Request-Id-List:543258 + + + + + + + +Shanmugham, et al. Informational [Page 36] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.11. 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". + 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:SPEAK 543258 MRCP/1.0 + 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/1.0 543258 200 IN-PROGRESS + + C->S:PAUSE 543259 MRCP/1.0 + + S->C:MRCP/1.0 543259 200 COMPLETE + Active-Request-Id-List:543258 + +7.12. 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 + + + +Shanmugham, et al. Informational [Page 37] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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:SPEAK 543258 MRCP/1.0 + 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/1.0 543258 200 IN-PROGRESS + + C->S:PAUSE 543259 MRCP/1.0 + + S->C:MRCP/1.0 543259 200 COMPLETE + Active-Request-Id-List:543258 + + C->S:RESUME 543260 MRCP/1.0 + + S->C:MRCP/1.0 543260 200 COMPLETE + Active-Request-Id-List:543258 + +7.13. 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 being spoken, 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. + + + + +Shanmugham, et al. Informational [Page 38] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 + 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 into 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:SPEAK 543258 MRCP/1.0 + 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/1.0 543258 200 IN-PROGRESS + + C->S:CONTROL 543259 MRCP/1.0 + Prosody-rate:fast + + S->C:MRCP/1.0 543259 200 COMPLETE + Active-Request-Id-List:543258 + + C->S:CONTROL 543260 MRCP/1.0 + + + +Shanmugham, et al. Informational [Page 39] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Jump-Size:-15 Words + + S->C:MRCP/1.0 543260 200 COMPLETE + Active-Request-Id-List:543258 + +7.14. 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:SPEAK 543260 MRCP/1.0 + 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/1.0 543260 200 IN-PROGRESS + + S->C:SPEAK-COMPLETE 543260 COMPLETE MRCP/1.0 + + Completion-Cause:000 normal + + + + + + +Shanmugham, et al. Informational [Page 40] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +7.15. SPEECH-MARKER + + This is an event generated by the synthesizer resource to the client + when it hits a marker tag in the speech markup it is currently + processing. The request-id field in the header matches the SPEAK + request request-id that initiated the speech. The request-state + field should be IN-PROGRESS as the speech is still not complete and + there is more to be spoken. The actual speech marker tag hit, + describing where the synthesizer is in the speech markup, is returned + in the speech-marker header field. + + Example: + C->S:SPEAK 543261 MRCP/1.0 + 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/1.0 543261 200 IN-PROGRESS + + S->C:SPEECH-MARKER 543261 IN-PROGRESS MRCP/1.0 + Speech-Marker:here + + S->C:SPEECH-MARKER 543261 IN-PROGRESS MRCP/1.0 + Speech-Marker:ANSWER + + S->C:SPEAK-COMPLETE 543261 COMPLETE MRCP/1.0 + Completion-Cause:000 normal + + + + + + +Shanmugham, et al. Informational [Page 41] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +8. 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. + +8.1. Recognizer State Machine + + The recognizer resource is controlled by MRCP 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 MRCP 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 | RECOGNITION-START-TIMERS | + |<-----------| |<---------| | + | | | + | | | + |-------| | | + | STOP | | + |<------| | | + | | + |<-------------------STOP--------------------------| + |<-------------------DEFINE-GRAMMAR----------------| + +8.2. Recognizer Methods + + The recognizer supports the following methods. + recognizer-method = SET-PARAMS + / GET-PARAMS + / DEFINE-GRAMMAR + / RECOGNIZE + / GET-RESULT + / RECOGNITION-START-TIMERS + / STOP + + + + +Shanmugham, et al. Informational [Page 42] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +8.3. Recognizer Events + + The recognizer may generate the following events. + + recognizer-event = START-OF-SPEECH + / RECOGNITION-COMPLETE + +8.4. Recognizer Header Fields + + A recognizer message may contain header fields containing request + options and information to augment the Method, Response, or Event + message it is associated with. + + recognizer-header = confidence-threshold ; Section 8.4.1 + / sensitivity-level ; Section 8.4.2 + / speed-vs-accuracy ; Section 8.4.3 + / n-best-list-length ; Section 8.4.4 + / no-input-timeout ; Section 8.4.5 + / recognition-timeout ; Section 8.4.6 + / waveform-url ; Section 8.4.7 + / completion-cause ; Section 8.4.8 + / recognizer-context-block ; Section 8.4.9 + / recognizer-start-timers ; Section 8.4.10 + / vendor-specific ; Section 8.4.11 + / speech-complete-timeout ; Section 8.4.12 + / speech-incomplete-timeout; Section 8.4.13 + / dtmf-interdigit-timeout ; Section 8.4.14 + / dtmf-term-timeout ; Section 8.4.15 + / dtmf-term-char ; Section 8.4.16 + / fetch-timeout ; Section 8.4.17 + / failed-uri ; Section 8.4.18 + / failed-uri-cause ; Section 8.4.19 + / save-waveform ; Section 8.4.20 + / new-audio-channel ; Section 8.4.21 + / speech-language ; Section 8.4.22 + + 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 + + + +Shanmugham, et al. Informational [Page 43] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + recognition-timeout MANDATORY SET-PARAMS, GET-PARAMS, + RECOGNIZE + waveform-url MANDATORY RECOGNITION-COMPLETE + completion-cause MANDATORY DEFINE-GRAMMAR, RECOGNIZE, + RECOGNITON-COMPLETE + recognizer-context-block Optional SET-PARAMS, GET-PARAMS + recognizer-start-timers MANDATORY RECOGNIZE + vendor-specific MANDATORY SET-PARAMS, GET-PARAMS + 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 + +8.4.1. 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 an integer from 0-100 indicating the + recognizer's confidence in the recognition. If the recognizer + determines that its confidence in all its recognition results is less + than the confidence threshold, then it MUST return no-match as the + recognition result. This header field MAY occur in RECOGNIZE, SET- + PARAMS, or GET-PARAMS. The default value for this field is platform + specific. + + confidence-threshold = "Confidence-Threshold" ":" 1*DIGIT CRLF + + + + + + +Shanmugham, et al. Informational [Page 44] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +8.4.2. 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 allows the client to set this value on + 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" ":" 1*DIGIT CRLF + +8.4.3. 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 media server and vice versa. This parameter on the + resource can 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" ":" 1*DIGIT CRLF + +8.4.4. N Best List Length + + When the recognizer matches an incoming stream with the grammar, it + may come up with more than one alternative match 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 + +8.4.5. No Input Timeout + + When recognition is started and there is no speech detected for a + certain period of time, the recognizer can send a RECOGNITION- + COMPLETE event to the client and terminate the recognition operation. + The no-input-timeout header field can set this timeout value. The + value is in milliseconds. This header field MAY occur in RECOGNIZE, + + + +Shanmugham, et al. Informational [Page 45] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 + +8.4.6. 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. 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 + +8.4.7. 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. + + waveform-url = "Waveform-URL" ":" Url CRLF + +8.4.8. 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. + + Cause-Code Cause-Name Description + + 000 success RECOGNIZE completed with a match or + DEFINE-GRAMMAR succeeded in + downloading and compiling the + grammar + + + + +Shanmugham, et al. Informational [Page 46] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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. + 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. + +8.4.9. 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*ALPHA CRLF + + + + + +Shanmugham, et al. Informational [Page 47] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +8.4.10. Recognition Start 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 RECOGNITION-START-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". + + recognizer-start-timers = "Recognizer-Start-Timers" ":" + boolean-value CRLF + +8.4.11. Vendor Specific Parameters + + This set of headers allows the client to set Vendor Specific + parameters. + + This header can be sent in the SET-PARAMS method and is used to set + vendor-specific parameters on the server. 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. + This header field MAY occur in SET-PARAMS or GET-PARAMS. + +8.4.12. 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 before 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 + + + + + +Shanmugham, et al. Informational [Page 48] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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. + +8.4.13. Speech Incomplete Timeout + + This header field specifies the required length of silence following + user speech, after which a recognizer finalizes a result. The + incomplete timeout applies when the speech prior to the silence is an + incomplete match of all active grammars. In this case, once the + timeout is triggered, the partial result is rejected (with a nomatch + event). The value is in milliseconds. The value for this field + ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. + The default value for this field is platform specific. + + speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" + 1*DIGIT CRLF + + The speech-incomplete-timeout also applies when the speech prior to + the silence is a complete match of an active grammar, but where it is + possible to speak further and still match the grammar. By contrast, + the complete timeout is used when the speech is a complete match to + an active grammar and no further words can be spoken. + + A long speech-incomplete-timeout value delays the result completion + and, therefore, makes the computer's response slow. A short speech- + incomplete-timeout may lead to an utterance being broken up + inappropriately. + + The speech-incomplete-timeout is usually longer than the speech- + complete-timeout to allow users to pause mid-utterance (for example, + to breathe). This header field MAY occur in RECOGNIZE, SET-PARAMS, + or GET-PARAMS. + +8.4.14. 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. + + + + + +Shanmugham, et al. Informational [Page 49] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":" + 1*DIGIT CRLF + +8.4.15. DTMF Term Timeout + + This header field specifies the terminating timeout 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 10 seconds. This header field MAY + occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. + + dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*DIGIT CRLF + +8.4.16. 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 + +8.4.17. Fetch Timeout + + When the recognizer needs to fetch grammar documents, this header + field controls URI access properties. This defines the recognizer + timeout for completing the fetch of the resources the media server + needs 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. + +8.4.18. Failed URI + + When a recognizer method needs a recognizer to fetch or access a URI, + and the access fails, the media server SHOULD provide the failed URI + in this header field in the method response. + +8.4.19. Failed URI Cause + + When a recognizer method needs a recognizer to fetch or access a URI, + and the access fails, the media 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. + + + + + +Shanmugham, et al. Informational [Page 50] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +8.4.20. 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 + +8.4.21. New Audio Channel + + This header field MAY BE specified in a RECOGNIZE message and allows + the client to tell the media 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. + This helps in the case where the client MAY want to reuse an open + recognition session with the media server for multiple telephone + calls. + + new-audio-channel = "New-Audio-Channel" ":" boolean-value CRLF + +8.4.22. Speech Language + + This header field specifies the language of recognition grammar data + within a session or request, if it is not specified within the data. + The value of this header field should follow RFC 3066 [16] for its + values. This MAY occur in DEFINE-GRAMMAR, RECOGNIZE, SET-PARAMS, or + GET-PARAMS request. + +8.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 MRCP + message. + + + + +Shanmugham, et al. Informational [Page 51] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +8.5.1. 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 MRCP 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 media servers MUST + support W3C's XML based grammar markup format [11] (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 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 media 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"?> + + + +Shanmugham, et al. Informational [Page 52] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + <!-- the default grammar language is US English --> + <grammar xml:lang="en-US" version="1.0"> + + <!-- single language attachment to tokens --> + <rule id="yes"> + <one-of> + <item xml:lang="fr-CA">oui</item> + <item xml:lang="en-US">yes</item> + </one-of> + </rule> + + <!-- single language attachment to a rule expansion --> + <rule id="request"> + may I speak to + <one-of xml:lang="fr-CA"> + <item>Michel Tremblay</item> + <item>Andre Roy</item> + </one-of> + </rule> + + <!-- multiple language attachment to a token --> + <rule id="people1"> + <token lexicon="en-US,fr-CA"> Robert </token> + </rule> + + <!-- the equivalent single-language attachment expansion --> + <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.cisco.com/Directory-Name-List.grxml + http://www.cisco.com/Department-List.grxml + http://www.cisco.com/TAC-Contact-List.grxml + session:menu1@menu-level.store + + Example 3: + Content-Type:multipart/mixed; boundary="--break" + + + + +Shanmugham, et al. Informational [Page 53] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + --break + Content-Type:text/uri-list + Content-Length:176 + http://www.cisco.com/Directory-Name-List.grxml + http://www.cisco.com/Department-List.grxml + http://www.cisco.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> + </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> + + + + +Shanmugham, et al. Informational [Page 54] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + </grammar> + --break + +8.5.2. Recognizer Result Data + + Recognition result data from the server is carried in the MRCP + message body of the RECOGNITION-COMPLETE event or the GET-RESULT + response message as MIME entities. All media servers MUST support + W3C's Natural Language Semantics Markup Language (NLSML) [10] as the + default standard for returning recognition results back to the + client, and hence MUST support the MIME-type application/x-nlsml. + + Example 1: + Content-Type:application/x-nlsml + Content-Length:104 + + <?xml version="1.0"?> + <result grammar="http://theYesNoGrammar"> + <interpretation> + <instance> + <myApp:yes_no> + <response>yes</response> + </myApp:yes_no> + </instance> + <input>ok</input> + </interpretation> + </result> + +8.5.3. Recognizer Context Block + + When the client has to change recognition servers within a call, this + is a block of data that the client MAY collect from the first media + server and provide to the second media server. This may be because + the client needs different language support or because the media + server issued an RTSP RE-DIRECT. Here, the first recognizer may have + collected acoustic and other data during its recognition. When we + switch recognition servers, communicating this data may allow the + second recognition 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 + + + +Shanmugham, et al. Informational [Page 55] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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. + +8.6. SET-PARAMS + + The SET-PARAMS method, from the client to the server, tells the + recognizer resource to set and modify recognizer context parameters + like recognizer characteristics, result detail level, etc. In the + following sections some standard parameters are discussed. If the + server resource does not recognize an OPTIONAL parameter, it MUST + ignore that field. Many of the parameters in the SET-PARAMS method + can also be used in another method like the RECOGNIZE method. But + the difference is that when you set something like the sensitivity- + level using the SET-PARAMS, it applies for all future requests, + whenever applicable. On the other hand, when you pass sensitivity- + level in a RECOGNIZE request, it applies only to that request. + + Example: + C->S:SET-PARAMS 543256 MRCP/1.0 + Sensitivity-Level:20 + Recognition-Timeout:30 + Confidence-Threshold:85 + + S->C:MRCP/1.0 543256 200 COMPLETE + +8.7. GET-PARAMS + + The GET-PARAMS method, from the client to the server, asks the + recognizer resource for its current default parameters, like + sensitivity-level, n-best-list-length, etc. The client can request + specific parameters from the server by sending it one or more empty + parameter headers with no values. The server should then return the + settings for those specific parameters only. When the client does + not send a specific list of empty parameter headers, the recognizer + should return the settings for all parameters. 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. + + + + + +Shanmugham, et al. Informational [Page 56] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Example: + C->S:GET-PARAMS 543256 MRCP/1.0 + Sensitivity-Level: + Recognition-Timeout: + Confidence-threshold: + + S->C:MRCP/1.0 543256 200 COMPLETE + Sensitivity-Level:20 + Recognition-Timeout:30 + Confidence-Threshold:85 + +8.8. DEFINE-GRAMMAR + + The DEFINE-GRAMMAR method, from the client to the server, provides a + grammar and tells the server to define, download if needed, and + compile the grammar. + + If the server resource is in the recognition state, the DEFINE- + GRAMMAR request MUST respond with a failure status. + + If the resource is in the idle state and is able to successfully load + and compile the grammar, the status MUST return a success code and + the request-state MUST be COMPLETE. + + If the recognizer could not define the grammar for some reason, say + the download failed or the grammar failed to compile, or the grammar + was in an unsupported form, the MRCP 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:DEFINE-GRAMMAR 543257 MRCP/1.0 + 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> + + + +Shanmugham, et al. Informational [Page 57] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + <!-- 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/1.0 543257 200 COMPLETE + Completion-Cause:000 success + + + C->S:DEFINE-GRAMMAR 543258 MRCP/1.0 + 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> + + </grammar> + + S->C:MRCP/1.0 543258 200 COMPLETE + Completion-Cause:000 success + + C->S:DEFINE-GRAMMAR 543259 MRCP/1.0 + Content-Type:application/grammar+xml + Content-Id:request2@field-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/1.0 543258 200 COMPLETE + + + +Shanmugham, et al. Informational [Page 58] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Completion-Cause:000 success + + C->S:DEFINE-GRAMMAR 543259 MRCP/1.0 + 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> + <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> + + + +Shanmugham, et al. Informational [Page 59] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + </rule> + + </grammar> + + S->C:MRCP/1.0 543259 200 COMPLETE + Completion-Cause:000 success + + C->S:RECOGNIZE 543260 MRCP/1.0 + 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/1.0 543260 200 IN-PROGRESS + + S->C:START-OF-SPEECH 543260 IN-PROGRESS MRCP/1.0 + + S->C:RECOGNITION-COMPLETE 543260 COMPLETE MRCP/1.0 + 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"?> + <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> + +8.9. RECOGNIZE + + The RECOGNIZE method from the client to the server tells the + recognizer to start recognition and provides it with a grammar to + match for. The RECOGNIZE method can carry 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. + + + +Shanmugham, et al. Informational [Page 60] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 + other reason, the recognizer resource MUST send the client a + RECOGNITON-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 that 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 Media server and signal the + Media 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 recognizer Media servers. + + Example: + C->S:RECOGNIZE 543257 MRCP/1.0 + Confidence-Threshold:90 + Content-Type:application/grammar+xml + Content-Id:request1@form-level.store + Content-Length:104 + + <?xml version="1.0"?> + + + +Shanmugham, et al. Informational [Page 61] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + + <!-- 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/1.0 543257 200 IN-PROGRESS + + S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0 + + S->C:RECOGNITION-COMPLETE 543257 COMPLETE MRCP/1.0 + + 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> + + + + +Shanmugham, et al. Informational [Page 62] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +8.10. 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,method the response MUST contain a status of 200(Success). + + Example: + C->S:RECOGNIZE 543257 MRCP/1.0 + 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> + <item>Andre Roy</item> + </one-of> + </rule> + + </grammar> + + S->C:MRCP/1.0 543257 200 IN-PROGRESS + + C->S:STOP 543258 200 MRCP/1.0 + + + + + +Shanmugham, et al. Informational [Page 63] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + S->C:MRCP/1.0 543258 200 COMPLETE + Active-Request-Id-List:543257 + +8.11. GET-RESULT + + The GET-RESULT method from the client to the server can be issued + when the recognizer is in the recognized state. This request allows + the client to retrieve results for a completed recognition. This is + useful if the client decides it wants more alternatives or more + information. When the media server receives this request, it should + re-compute and return the results according to the recognition + constraints provided in the GET-RESULT request. + + The GET-RESULT request could specify constraints like a different + confidence-threshold, or n-best-list-length. This feature is + optional and the automatic speech recognition (ASR) engine may return + a status of unsupported feature. + + Example: + C->S:GET-RESULT 543257 MRCP/1.0 + Confidence-Threshold:90 + + S->C:MRCP/1.0 543257 200 COMPLETE + 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> + +8.12. START-OF-SPEECH + + This is an event from the recognizer to the client indicating that it + has detected speech. 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 + + + +Shanmugham, et al. Informational [Page 64] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 in the same media server or not. + +8.13. RECOGNITION-START-TIMERS + + This request is sent from the client to the recognition resource when + it knows that a kill-on-barge-in prompt has finished playing. This + is useful in the scenario when the recognition and synthesizer + engines are not in the same session. Here, when a kill-on-barge-in + prompt is being played, you want the RECOGNIZE request to be + simultaneously active so that it can detect and implement kill-on- + barge-in. But at the same time, you don't want the recognizer to + start the no-input timers until the prompt is finished. The + parameter recognizer-start-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 RECOGNITION-START-TIMERS method to the recognizer. + +8.14. RECOGNITON-COMPLETE + + This is an Event from the recognizer resource to the client + indicating that the recognition completed. The recognition result is + sent in the MRCP 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 until 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. + + Example: + C->S:RECOGNIZE 543257 MRCP/1.0 + 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"> + + + +Shanmugham, et al. Informational [Page 65] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + + <!-- 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/1.0 543257 200 IN-PROGRESS + + S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0 + + S->C:RECOGNITION-COMPLETE 543257 COMPLETE MRCP/1.0 + 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> + + + + + + + + +Shanmugham, et al. Informational [Page 66] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +8.15. 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 [15]. The automatic speech recognizer (ASR) needs to support + RFC 2833 [15] to recognize digits. If it does not support RFC 2833 + [15], it will have to process the audio stream and extract the audio + tones from it. + +9. Future Study + + Various sections of the recognizer could be distributed into Digital + Signal Processors (DSPs) on the Voice Browser/Gateway or IP Phones. + For instance, the gateway might perform voice activity detection to + reduce network bandwidth and CPU requirement of the automatic speech + recognition (ASR) server. Such extensions are deferred for further + study and will not be addressed in this document. + +10. Security Considerations + + The MRCP protocol may carry sensitive information such as account + numbers, passwords, etc. 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. If all MRCP communications happens in a + trusted domain behind a firewall, this may not be necessary. If the + client or server is deployed in an insecure network, communication + happening across this insecure network needs to be protected. In + such cases, the following additional security functionality MUST be + supported on the MRCP server. MRCP servers MUST implement Transport + Layer Security (TLS) to secure the RTSP communication, i.e., the RTSP + stack SHOULD support the rtsps: URI form. MRCP servers MUST support + Secure Real-Time Transport Protocol (SRTP) as an option to send and + receive media. + +11. RTSP-Based Examples + + The following is an example of a typical session of speech synthesis + and recognition between a client and the server. + + Opening the synthesizer. This is the first resource for this + session. The server and client agree on a single Session ID 12345678 + and set of RTP/RTCP ports on both sides. + + C->S:SETUP rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:2 + Transport:RTP/AVP;unicast;client_port=46456-46457 + Content-Type:application/sdp + + + +Shanmugham, et al. Informational [Page 67] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Content-Length:190 + + v=0 + o=- 123 456 IN IP4 10.0.0.1 + s=Media Server + p=+1-888-555-1212 + c=IN IP4 0.0.0.0 + t=0 0 + m=audio 0 RTP/AVP 0 96 + a=rtpmap:0 pcmu/8000 + a=rtpmap:96 telephone-event/8000 + a=fmtp:96 0-15 + + S->C:RTSP/1.0 200 OK + CSeq:2 + Transport:RTP/AVP;unicast;client_port=46456-46457; + server_port=46460-46461 + Session:12345678 + Content-Length:190 + Content-Type:application/sdp + + v=0 + o=- 3211724219 3211724219 IN IP4 10.3.2.88 + s=Media Server + c=IN IP4 0.0.0.0 + t=0 0 + m=audio 46460 RTP/AVP 0 96 + a=rtpmap:0 pcmu/8000 + a=rtpmap:96 telephone-event/8000 + a=fmtp:96 0-15 + + Opening a recognizer resource. Uses the existing session ID and + ports. + + C->S:SETUP rtsp://media.server.com/media/recognizer RTSP/1.0 + CSeq:3 + Transport:RTP/AVP;unicast;client_port=46456-46457; + mode=record;ttl=127 + Session:12345678 + + S->C:RTSP/1.0 200 OK + CSeq:3 + Transport:RTP/AVP;unicast;client_port=46456-46457; + server_port=46460-46461;mode=record;ttl=127 + Session:12345678 + + + + + + +Shanmugham, et al. Informational [Page 68] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + An ANNOUNCE message with the MRCP SPEAK request initiates speech. + + C->S:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:4 + Session:12345678 + Content-Type:application/mrcp + Content-Length:456 + + SPEAK 543257 MRCP/1.0 + 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:RTSP/1.0 200 OK + CSeq:4 + Session:12345678 + RTP-Info:url=rtsp://media.server.com/media/synthesizer; + seq=9810092;rtptime=3450012 + Content-Type:application/mrcp + Content-Length:456 + + MRCP/1.0 543257 200 IN-PROGRESS + + + The synthesizer hits the special marker in the message to be spoken + and faithfully informs the client of the event. + + S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:5 + Session:12345678 + + + +Shanmugham, et al. Informational [Page 69] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Content-Type:application/mrcp + Content-Length:123 + + SPEECH-MARKER 543257 IN-PROGRESS MRCP/1.0 + Speech-Marker:Stephanie + C->S:RTSP/1.0 200 OK + CSeq:5 + + The synthesizer finishes with the SPEAK request. + + S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:6 + Session:12345678 + Content-Type:application/mrcp + Content-Length:123 + + SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0 + + + C->S:RTSP/1.0 200 OK + CSeq:6 + + The recognizer is issued a request to listen for the customer + choices. + + C->S:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0 + CSeq:7 + Session:12345678 + + RECOGNIZE 543258 MRCP/1.0 + 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> + + + +Shanmugham, et al. Informational [Page 70] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + S->C:RTSP/1.0 200 OK + CSeq:7 + Content-Type:application/mrcp + Content-Length:123 + + MRCP/1.0 543258 200 IN-PROGRESS + + The client issues the next MRCP SPEAK method in an ANNOUNCE message, + asking the user the question. 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:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:8 Session:12345678 Content-Type:application/mrcp + Content-Length:733 + + SPEAK 543259 MRCP/1.0 + Kill-On-Barge-In:true + Content-Type:application/synthesis+ssml + 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:RTSP/1.0 200 OK + CSeq:8 + Content-Type:application/mrcp + Content-Length:123 + + MRCP/1.0 543259 200 IN-PROGRESS + + Since the last SPEAK request had Kill-On-Barge-In set to "true", the + message synthesizer is interrupted when the user starts speaking, and + the client is notified. + + Now, since the recognition and synthesizer resources are in the same + session, they worked with each other to deliver kill-on-barge-in. If + the resources were in different sessions, it would have taken a few + more messages before the client got the SPEAK-COMPLETE event from the + + + +Shanmugham, et al. Informational [Page 71] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + synthesizer resource. 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 should have then blindly turned around and issued a + BARGE-IN-OCCURRED method to the synthesizer resource. The + synthesizer, if kill-on-barge-in was enabled on the current SPEAK + request, would have then interrupted it and issued SPEAK-COMPLETE + event to the client. In this example, since the synthesizer and + recognizer are in the same session, the client did not issue the + BARGE-IN-OCCURRED method to the synthesizer and assumed that kill- + on-barge-in was implemented between the two resources in the same + session and worked. + + The completion-cause code differentiates if this is normal completion + or a kill-on-barge-in interruption. + + S->C:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0 + CSeq:9 + Session:12345678 + Content-Type:application/mrcp + Content-Length:273 + + START-OF-SPEECH 543258 IN-PROGRESS MRCP/1.0 + + C->S:RTSP/1.0 200 OK + CSeq:9 + + S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:10 + Session:12345678 + Content-Type:application/mrcp + Content-Length:273 + + SPEAK-COMPLETE 543259 COMPLETE MRCP/1.0 + Completion-Cause:000 normal + + C->S:RTSP/1.0 200 OK + CSeq:10 + + 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:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0 + CSeq:11 + Session:12345678 + Content-Type:application/mrcp + + + +Shanmugham, et al. Informational [Page 72] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + Content-Length:733 + + RECOGNITION-COMPLETE 543258 COMPLETE MRCP/1.0 + 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> + + C->S:RTSP/1.0 200 OK + CSeq:11 + + C->S:TEARDOWN rtsp://media.server.com/media/synthesizer RTSP/1.0 + CSeq:12 + Session:12345678 + + S->C:RTSP/1.0 200 OK + CSeq:12 + + We are done with the resources and are tearing them down. When the + last of the resources for this session are released, the Session-ID + and the RTP/RTCP ports are also released. + + C->S:TEARDOWN rtsp://media.server.com/media/recognizer RTSP/1.0 + CSeq:13 + Session:12345678 + + S->C:RTSP/1.0 200 OK + CSeq:13 + + + + + + + + + +Shanmugham, et al. Informational [Page 73] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +12. Informative References + + [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 4234, October 2005. + + [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [5] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [6] World Wide Web Consortium, "Voice Extensible Markup Language + (VoiceXML) Version 2.0", W3C Candidate Recommendation, March + 2004. + + [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [9] World Wide Web Consortium, "Speech Synthesis Markup Language + (SSML) Version 1.0", W3C Candidate Recommendation, September + 2004. + + [10] World Wide Web Consortium, "Natural Language Semantics Markup + Language (NLSML) for the Speech Interface Framework", W3C + Working Draft, 30 May 2001. + + [11] World Wide Web Consortium, "Speech Recognition Grammar + Specification Version 1.0", W3C Candidate Recommendation, March + 2004. + + [12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD + 63, RFC 3629, November 2003. + + [13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, November + 1996. + + + + + +Shanmugham, et al. Informational [Page 74] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + [14] Levinson, E., "Content-ID and Message-ID Uniform Resource + Locators", RFC 2392, August 1998. + + [15] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, + Telephony Tones and Telephony Signals", RFC 2833, May 2000. + + [16] Alvestrand, H., "Tags for the Identification of Languages", BCP + 47, RFC 3066, January 2001. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Shanmugham, et al. Informational [Page 75] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +Appendix A. ABNF Message Definitions + + ALPHA = %x41-5A / %x61-7A ; A-Z / a-z + + CHAR = %x01-7F ; any 7-bit US-ASCII character, + ; excluding NUL + + CR = %x0D ; carriage return + + CRLF = CR LF ; Internet standard newline + + DIGIT = %x30-39 ; 0-9 + + DQUOTE = %x22 ; " (Double Quote) + + HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" + + HTAB = %x09 ; horizontal tab + + LF = %x0A ; linefeed + + OCTET = %x00-FF ; 8 bits of data + + SP = %x20 ; space + + WSP = SP / HTAB ; white space + + 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 + + param = *pchar + + quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) + DQUOTE + + qdtext = LWS / %x21 / %x23-5B / %x5D-7E + / UTF8-NONASCII + + + + + +Shanmugham, et al. Informational [Page 76] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + quoted-pair = "\" (%x00-09 / %x0B-0C + / %x0E-7F) + + token = 1*(alphanum / "-" / "." / "!" / "%" / "*" + / "_" / "+" / "`" / "'" / "~" ) + + reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" + / "+" / "$" / "," + + mark = "-" / "_" / "." / "!" / "~" / "*" / "'" + / "(" / ")" + + unreserved = alphanum / mark + + char = unreserved / escaped / + ":" / "@" / "&" / "=" / "+" / "$" / "," + + 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 ) + + + + +Shanmugham, et al. Informational [Page 77] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 / + "&" / "=" / "+" / "$" / "," ) + + 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 + + + + +Shanmugham, et al. Informational [Page 78] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + port = 1*DIGIT + + 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 + + message-header = 1*(generic-header / resource-header) + + generic-header = active-request-id-list + / proxy-sync-id + / content-id + / content-type + / content-length + / content-base + / content-location + / content-encoding + / cache-control + / logging-tag + ; -- content-id is as defined in RFC 2392 and RFC 2046 + + mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT + + request-id = 1*DIGIT + + status-code = 1*DIGIT + + active-request-id-list = "Active-Request-Id-List" ":" + request-id *("," request-id) CRLF + + proxy-sync-id = "Proxy-Sync-Id" ":" 1*ALPHA CRLF + + content-length = "Content-Length" ":" 1*DIGIT CRLF + + content-base = "Content-Base" ":" absoluteURI CRLF + + + +Shanmugham, et al. Informational [Page 79] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + 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 + + logging-tag = "Logging-Tag" ":" 1*ALPHA CRLF + + + resource-header = recognizer-header + / synthesizer-header + + method-name = synthesizer-method + / recognizer-method + + event-name = synthesizer-event + / recognizer-event + + + + + + +Shanmugham, et al. Informational [Page 80] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + request-state = "COMPLETE" + / "IN-PROGRESS" + / "PENDING" + + synthesizer-method = "SET-PARAMS" + / "GET-PARAMS" + / "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 + / voice-parameter + / prosody-parameter + / vendor-specific + / speech-marker + / speech-language + / fetch-hint + / audio-fetch-hint + / fetch-timeout + / failed-uri + / failed-uri-cause + / speak-restart + / speak-length + + recognizer-method = "SET-PARAMS" + / "GET-PARAMS" + / "DEFINE-GRAMMAR" + / "RECOGNIZE" + / "GET-RESULT" + / "RECOGNITION-START-TIMERS" + / "STOP" + + recognizer-event = "START-OF-SPEECH" + / "RECOGNITION-COMPLETE" + + recognizer-header = confidence-threshold + / sensitivity-level + / speed-vs-accuracy + / n-best-list-length + + + +Shanmugham, et al. Informational [Page 81] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + / no-input-timeout + / recognition-timeout + / waveform-url + / completion-cause + / recognizer-context-block + / recognizer-start-timers + / vendor-specific + / 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 + + 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" + / "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 + + voice-parameter = "Voice-" voice-param-name ":" + voice-param-value CRLF + + + + +Shanmugham, et al. Informational [Page 82] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + voice-param-name = 1*ALPHA + + voice-param-value = 1*alphanum + + prosody-parameter = "Prosody-" prosody-param-name ":" + prosody-param-value CRLF + + prosody-param-name = 1*ALPHA + + prosody-param-value = 1*alphanum + + 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*ALPHA + + vendor-av-pair-value = 1*alphanum + + speech-marker = "Speech-Marker" ":" 1*ALPHA CRLF + + speech-language = "Speech-Language" ":" 1*ALPHA 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*ALPHA CRLF + + speak-restart = "Speak-Restart" ":" boolean-value CRLF + + speak-length = "Speak-Length" ":" speech-length-value + CRLF + 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 + + + +Shanmugham, et al. Informational [Page 83] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + + no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF + + recognition-timeout = "Recognition-Timeout" ":" 1*DIGIT CRLF + + waveform-url = "Waveform-URL" ":" absoluteURI CRLF + + recognizer-context-block = "Recognizer-Context-Block" ":" + 1*ALPHA CRLF + + recognizer-start-timers = "Recognizer-Start-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 + + save-waveform = "Save-Waveform" ":" boolean-value CRLF + + new-audio-channel = "New-Audio-Channel" ":" + boolean-value CRLF + +Appendix B. Acknowledgements + + Andre Gillet (Nuance Communications) + Andrew Hunt (SpeechWorks) + Aaron Kneiss (SpeechWorks) + Kristian Finlator (SpeechWorks) + Martin Dragomirecky (Cisco Systems, Inc.) + Pierre Forgues (Nuance Communications) + Suresh Kaliannan (Cisco Systems, Inc.) + Corey Stohs (Cisco Systems, Inc.) + Dan Burnett (Nuance Communications) + + + + + + + + + + +Shanmugham, et al. Informational [Page 84] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +Authors' Addresses + + Saravanan Shanmugham + Cisco Systems, Inc. + 170 W. Tasman Drive + San Jose, CA 95134 + + EMail: sarvi@cisco.com + + + Peter Monaco + Nuasis Corporation + 303 Bryant St. + Mountain View, CA 94041 + + EMail: peter.monaco@nuasis.com + + + Brian Eberman + Speechworks, Inc. + 695 Atlantic Avenue + Boston, MA 02111 + + EMail: brian.eberman@speechworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Shanmugham, et al. Informational [Page 85] + +RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Shanmugham, et al. Informational [Page 86] + |