draft-ietf-speechsc-mrcpv2-05.txt

MRCP V2版协议

    "sendonly" and another with attribute "recvonly"). The "cmid" 
    attribute of the recognizer control m-line would match the "mid" 
    value of the "sendonly" audio m-line and the "cmid" attribute of the 
    synthesizer control m-line would match the "mid" attribute of the 
    "recvonly" m-line.   
     
    When a server receives media(say audio) on a media pipe that is 
    associated with more than one media processing resource, it is the 
    responsibility of the server to receive and fork it to the resources 
    that need it. If the multiple resources in a session are generating 
    audio (or other media), that needs to be sent on a single associated 
    media pipe, it is the responsibility of the server to mix the 
    streams before sending on the media pipe. The media stream in either 
  
 S Shanmugham                  IETF-Draft                       Page 15 

                            MRCPv2 Protocol              October, 2004 

    direction may contain more than one Synchronized Source (SSRC) 
    identifier due to multiple sources contributing to the media on the 
    pipe and the client or server SHOULD be able to deal with it. 
     
    If a server does not have the capability to mix or fork media, in 
    the above cases, then the server SHOULD disallow the client from 
    associating multiple such resources to a single audio pipe, by 
    rejecting the SIP INVITE with a SIP 501 "Not Implemented" error.  
     
 4.4. MRCPv2 Message Transport 
     
    The MRCPv2 resource messages defined in this document are 
    transported over a TCP, SCTP or TLS pipe between the client and the 
    server. The setting up of this transport pipe and the resource 
    control channel is discussed in Section 3.2. Multiple resource 
    control channels between a client and a server that belong to 
    different SIP sessions can share one or more TLS, TCP or SCTP pipes 
    between them and the server and client MUST support this operation. 
    The individual MRCPv2 messages carry the MRCPv2 channel identifier 
    in their Channel-Identifier header field MUST be used to 
    differentiate MRCPv2 messages from different resource channels. All 
    MRCPv2 servers MUST support TLS, SHOULD support TCP and MAY support 
    SCTP and it is up to the client to choose which mode of transport it 
    wants to use for an MRCPv2 session.  
  
    Example 1: 
  
    C->S:  MRCP/2.0 483 SPEAK 543257 
           Channel-Identifier: 32AECB23433802@speechsynth 
           Voice-gender: neutral 
           Voice-category: teenager 
           Prosody-volume: medium 
           Content-Type: application/synthesis+ssml 
           Content-Length: 104 
     
           <?xml version="1.0"?> 
           <speak> 
            <paragraph> 
              <sentence>You have 4 new messages.</sentence> 
              <sentence>The first is from <say-as  
              type="name">Stephanie Williams</say-as> 
              and arrived at <break/> 
              <say-as type="time">3:45pm</say-as>.</sentence> 
     
              <sentence>The subject is <prosody 
              rate="-20%">ski trip</prosody></sentence> 
            </paragraph> 
           </speak> 
     
    S->C:  MRCP/2.0 81 543257 200 IN-PROGRESS 
           Channel-Identifier: 32AECB23433802@speechsynth 
  
 S Shanmugham                  IETF-Draft                       Page 16 

                            MRCPv2 Protocol              October, 2004 

     
    S->C:  MRCP/2.0 89 SPEAK-COMPLETE 543257 COMPLETE 
           Channel-Identifier: 32AECB23433802@speechsynth 
  
    Most examples from here on show only the MRCPv2 messages and do not 
    show the SIP messages and headers that may have been used to 
    establish the MRCPv2 control channel.  
     
  
 5.   MRCPv2 Specification 
     
    The MRCPv2 PDU is textual using an ISO 10646 character set in the 
    UTF-8 encoding (RFC 2044) to allow many different languages to be 
    represented. However, to assist in compact representations, MRCPv2 
    also allows other character sets such as ISO 8859-1 to be used when 
    desired. The MRCPv2 protocol headers(the first line of an MRCP 
    message) and field names use only the US-ASCII subset of UTF-8. 
    Internationalization only applies to certain fields like grammar, 
    results, speech markup etc, and not to MRCPv2 as a whole.   
     
    Lines are terminated by CRLF. Also, some parameters in the PDU may 
    contain binary data or a record spanning multiple lines. Such fields 
    have a length value associated with the parameter, which indicates 
    the number of octets immediately following the parameter. 
     
    All MRCPv2 messages, responses and events MUST carry the Channel-
    Identifier header field in it, for the server or client to 
    differentiate messages from different control channels that may 
    share the same transport connection. 
     
    The MRCPv2 message set consists of requests from the client to the 
    server, responses from the server to the client and asynchronous 
    events from the server to the client. All these messages consist of 
    a start-line, one or more header fields (also known as "headers"), 
    an empty line (i.e. a line with nothing preceding the CRLF) 
    indicating the end of the header fields, and an optional message 
    body. 
     
      generic-message  =    start-line 
                            message-header 
                            CRLF 
                            [ message-body ] 
     
      start-line       =    request-line / response-line / event-line 
  
      message-header   =   1*(generic-header / resource-header) 
     
      resource-header  =    recognizer-header 
                       /    synthesizer-header 
                       /    recorder-header 
                       /    verifier-header 
  
 S Shanmugham                  IETF-Draft                       Page 17 

                            MRCPv2 Protocol              October, 2004 

                       /    extension-header 
     
      header-extension =    1*(ALPHANUM / "-") CRLF      
     
    The message-body contains resource-specific and message-specific 
    data that needs to be carried between the client and server as a 
    MIME entity. The information contained here and the actual MIME-
    types used to carry the data are specified later when addressing the 
    specific messages.  
     
    If a message contains data in the message body, the header fields 
    will contain content-headers indicating the MIME-type and encoding 
    of the data in the message body. 
     
 5.1. Request 
     
    A MRCPv2 request consists of a Request line followed by zero or more 
    message headers and an optional message body containing data 
    specific to the request message.  
     
    The Request message from a client to the server includes within the 
    first line, the method to be applied, a method tag for that request 
    and the version of protocol in use. 
     
      request-line   =    mrcp-version SP message-length SP method-name 
                          SP request-id CRLF 
     
    The mrcp-version field is the MRCPv2 protocol version that is being 
    used by the client. Request, response and event messages include the 
    version of MRCP in use, and follow [H3.1] (with HTTP replaced by 
    MRCP, and HTTP/1.1 replaced by MRCP/2.0) regarding version ordering, 
    compliance requirements, and upgrading of version numbers. To be 
    compliant with this specification, applications sending MRCP 
    messages MUST include a mrcp-version of "MRCP/2.0". 
     
     
      mrcp-version   =    "MRCP" "/" 1*DIGIT "." 1*DIGIT 
     
    The message-length field specifies the length of the message and 
    MUST be the 2nd token from the beginning of the message. This is to 
    make the framing and parsing of the message simpler to do. 
     
      message-length =    1*DIGIT 
    
    The request-id field is a unique identifier representable as a 
    unsigned 32 bit integer created by the client and sent to the 
    server. The initial value of the request-id is arbitrary. 
    Consecutive requests within a MRCP session MUST contain strictly 
    monotonically increasing and contiguous request-id's. The server 
    resource MUST use this identifier in its response to this request. 
    If the request does not complete with the response future 
  
 S Shanmugham                  IETF-Draft                       Page 18 

                            MRCPv2 Protocol              October, 2004 

    asynchronous events associated with this request MUST carry the 
    request-id. 
     
      request-id    =    1*DIGIT 
  
    The method-name field identifies the specific request that the 
    client is making to the server. Each resource supports a certain 
    list of requests or methods that can be issued to it, and will be 
    addressed in later sections.  
     
      method-name    =    generic-method      ; Section 6 
                     /    synthesizer-method 
                     /    recorder-method 
                     /    recognizer-method 
                     /    verifier-method 
                     /    extension-methods 
     
      extension-methods = 1*(ALPHA / "-") 
     
 5.2. Response 
     
    After receiving and interpreting the request message, the server 
    resource responds with an MRCPv2 response message. It consists of a 
    status line optionally followed by a message body. 
     
      response-line  =    mrcp-version SP message-length SP request-id 
                     SP status-code SP request-state CRLF 
     
    The mrcp-version field used here MUST be the same as the one used in 
    the Request Line and specifies the version of MRCPv2 protocol 
    running on the server. 
     
    The request-id used in the response MUST match the one sent in the 
    corresponding request message. 
     
    The status-code field is a 3-digit code representing the success or 
    failure or other status of the request. 
  
    The request-state field indicates if the job initiated by the 
    Request is PENDING, IN-PROGRESS or COMPLETE. The COMPLETE status 
    means that the Request was processed to completion and that there 
    are will be no more events from that resource to the client with 
    that request-id. The PENDING status means that the job has been 
    placed on a queue and will be processed in first-in-first-out order. 
    The IN-PROGRESS status means that the request is being processed and 
    is not yet complete. A PENDING or IN-PROGRESS status indicates that 
    further Event messages will be delivered with that request-id. 
     
      request-state    =  "COMPLETE" 
                       /  "IN-PROGRESS"        
                       /  "PENDING" 
  
 S Shanmugham                  IETF-Draft                       Page 19 

                            MRCPv2 Protocol              October, 2004 

 Status Codes 
     
    The status codes are classified under the Success(2XX) codes,  
    Client Failure(4XX) codes and Server Failure (5XX). 
     
 Success 2xx 
     
       200       Success 
       201       Success with some optional headers ignored. 
     
 Client Failure 4xx 
     
       401       Method not allowed 
       402       Method not valid in this state 
       403       Unsupported Header 
       404       Illegal Value for Header 
       405       Not found (e.g. Resource URI not initialized  
                 or doesn't exist) 
       406       Mandatory Header Missing 
       407       Method or Operation Failed(e.g. Grammar compilation 
                 failed in the recognizer. Detailed cause codes MAY BE 
                 available through a resource specific header field.) 
       408       Unrecognized or unsupported message entity 
       409       Unsupported Header Value 
       421-499   Resource specific Failure codes 
     
 Server Failure 5xx 
     
       501       Server Internal Error 
       502       Protocol Version not supported 
       503       Proxy Timeout. The MRCP Proxy did not receive a 
                 response from the MRCP server.