<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> Document Conventions</h1>

<p id="rfc.section.1.p.1">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 <a href="#RFC2119" class="xref">RFC 2119</a>.</p>

<p id="rfc.section.1.p.2">Since many of the definitions and syntax are identical to those for the <a href="#RFC2616" class="xref">Hypertext Transfer Protocol -- HTTP/1.1</a>, this specification refers to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of RFC 2616.</p>

<p id="rfc.section.1.p.3">All the mechanisms specified in this document are described in both prose and an augmented Backus-Naur form (<a href="#RFC5234" class="xref">ABNF</a>).</p>

<p id="rfc.section.1.p.4">The complete message format in ABNF form is provided in <a href="#S.abnf" class="xref">[S.abnf]</a> and is the normative format definition. Note that productions may be duplicated within the main body of the document for reading convenience. If a production in the body of the text conflicts with one in the normative definition, the latter rules.</p>

<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> Definitions</h1>

<p></p>

<dl>
<dt>Media Resource</dt>
<dd style="margin-left: 15">
<br>An entity on the speech processing server that can be controlled through MRCPv2.</dd>
<dt>MRCP Server</dt>
<dd style="margin-left: 15">
<br> Aggregate of one or more "Media Resource" entities on a server, exposed through MRCPv2.  Often, 'server' in this document refers to an MRCP server.</dd>
<dt>MRCP Client</dt>
<dd style="margin-left: 15">
<br>An entity controlling one or more Media Resources through MRCPv2 ("Client" for short).</dd>
<dt>DTMF</dt>
<dd style="margin-left: 15">
<br>Dual-Tone Multi-Frequency; a method of transmitting key presses in-band, either as actual tones (<a href="#Q.23" class="xref">Q.23</a>) or as named tone events (<a href="#RFC4733" class="xref">RFC 4733</a>).</dd>
<dt>Endpointing</dt>
<dd style="margin-left: 15">
<br>The process of automatically detecting the beginning and end of speech in an audio stream. This is critical both for speech recognition and for automated recording as one would find in voice mail systems.</dd>
<dt>Hotword Mode</dt>
<dd style="margin-left: 15">
<br>A mode of speech recognition where a stream of utterances is evaluated for match against a small set of command words. This is generally employed either to trigger some action or to control the subsequent grammar to be used for further recognition.</dd>
</dl>

<h1 id="rfc.section.1.2">
<a href="#rfc.section.1.2">1.2.</a> Nroff Beginning-of-Line Character Escaping</h1>

<p id="rfc.section.1.2.p.1">'Line starting with single apostrophe'.</p>

<p id="rfc.section.1.2.p.2">... Line starting with period.</p>

<h1 id="rfc.section.1.3">
<a href="#rfc.section.1.3">1.3.</a> A Section Title which is so long that it will extend to the next Line.</h1>

<h1 id="rfc.section.1.4">
<a href="#rfc.section.1.4">1.4.</a> State-Machine Diagrams</h1>

<p id="rfc.section.1.4.p.1"><a name="state-machine-diagram-para-1"></a>The state-machine diagrams in this document do not show every possible method call. Rather, they reflect the state of the resource based on the methods that have moved to IN-PROGRESS or COMPLETE states (see <a href="#sec.response" class="xref">[sec.response]</a>). Note that since PENDING requests essentially have not affected the resource yet and are in the queue to be processed, they are not reflected in the state-machine diagrams.</p>

<h1 id="rfc.section.1.5">
<a href="#rfc.section.1.5">1.5.</a> URI Schemes</h1>

<p id="rfc.section.1.5.p.1">This document defines many protocol headers that contain URIs (<a href="#RFC3986" class="xref">Uniform Resource Identifiers</a>) or lists of URIs for referencing media. The entire document, including the Security Considerations section (Section 12), assumes that HTTP or <a href="#RFC2818" class="xref">HTTP over TLS (HTTPS)</a> will be used as the URI addressing scheme unless otherwise stated. However, implementations MAY support other schemes (such as 'file'), provided they have addressed any security considerations described in this document and any others particular to the specific scheme. For example, implementations where the client and server both reside on the same physical hardware and the file system is secured by traditional file access controls on user-level could be reasonable candidates for supporting the 'file' scheme.</p>

<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#sec.resourceControl" id="sec.resourceControl">Managing Resource Control Channels</a>
</h1>

<p id="rfc.section.2.p.1">The client needs a separate MRCPv2 resource control channel to control each media processing resource under the SIP dialog. A unique channel identifier string identifies these resource control channels.  The channel identifier is a difficult-to-guess, unambiguous string followed by an "@", then by a string token specifying the type of resource. The server generates the channel identifier and MUST make sure it does not clash with the identifier of any other MRCP channel currently allocated by that server. MRCPv2 defines the following IANA-registered types of media processing resources. Additional resource types and their associated methods/events and state machines may be added as described below in <a href="#sec.iana" class="xref">[sec.iana]</a>.</p>

<div id="rfc.table.1"></div>

<div id="table.resourceTypes"></div>

<table cellpadding="3" cellspacing="0" class="tt full center">
<caption>Resource Types</caption>
<thead><tr>
<th class="left">Resource Type</th>
<th class="left">Resource Description</th>
<th class="left">Described in</th>
</tr></thead>
<tbody>
<tr>
<td class="left">speechrecog</td>
<td class="left">Speech Recognizer</td>
<td class="left"><a href="#sec.recognizerResource" class="xref">[sec.recognizerResource]</a></td>
</tr>
<tr>
<td class="left">dtmfrecog</td>
<td class="left">DTMF Recognizer</td>
<td class="left"><a href="#sec.recognizerResource" class="xref">[sec.recognizerResource]</a></td>
</tr>
<tr>
<td class="left">speechsynth</td>
<td class="left">Speech Synthesizer</td>
<td class="left"><a href="#sec.synthesizerResource" class="xref">[sec.synthesizerResource]</a></td>
</tr>
<tr>
<td class="left">basicsynth</td>
<td class="left">Basic Synthesizer</td>
<td class="left"><a href="#sec.synthesizerResource" class="xref">[sec.synthesizerResource]</a></td>
</tr>
<tr>
<td class="left">speakverify</td>
<td class="left">Speaker Verification</td>
<td class="left"><a href="#sec.verifierResource" class="xref">[sec.verifierResource]</a></td>
</tr>
<tr>
<td class="left">recorder</td>
<td class="left">Speech Recorder</td>
<td class="left"><a href="#sec.recorderResource" class="xref">[sec.recorderResource]</a></td>
</tr>
</tbody>
</table>

<p id="rfc.section.2.p.2">The SIP INVITE or re-INVITE transaction and the SDP offer/answer exchange it carries contain "m=" lines describing the resource control channel to be allocated. There MUST be one SDP "m=" line for each MRCPv2 resource to be used in the session. This "m=" line MUST have a media type field of "application" and a transport type field of either "TCP/MRCPv2" or "TCP/TLS/MRCPv2". The port number field of the "m=" line MUST contain the "discard" port of the transport protocol (port 9 for TCP) in the SDP offer from the client and MUST contain the TCP listen port on the server in the SDP answer. The client may then either set up a TCP or TLS connection to that server port or share an already established connection to that port. Since MRCPv2 allows multiple sessions to share the same TCP connection, multiple "m=" lines in a single SDP document MAY share the same port field value; MRCPv2 servers MUST NOT assume any relationship between resources using the same port other than the sharing of the communication channel.</p>

<p id="rfc.section.2.p.3">MRCPv2 resources do not use the port or format field of the "m=" line to distinguish themselves from other resources using the same channel.  The client MUST specify the resource type identifier in the resource attribute associated with the control "m=" line of the SDP offer. The server MUST respond with the full Channel-Identifier (which includes the resource type identifier and a difficult-to-guess, unambiguous string) in the "channel" attribute associated with the control "m=" line of the SDP answer. To remain backwards compatible with conventional SDP usage, the format field of the "m=" line MUST have the arbitrarily selected value of "1".</p>

<p id="rfc.section.2.p.4">When the client wants to add a media processing resource to the session, it issues a new SDP offer, according to the procedures of <a href="#RFC3264" class="xref">RFC 3264</a>, in a SIP re-INVITE request.  The SDP offer/answer exchange carried by this SIP transaction contains one or more additional control "m=" lines for the new resources to be allocated to the session. The server, on seeing the new "m=" line, allocates the resources (if they are available) and responds with a corresponding control "m=" line in the SDP answer carried in the SIP response. If the new resources are not available, the re-INVITE receives an error message, and existing media processing going on before the re-INVITE will continue as it was before. It is not possible to allocate more than one resource of each type. If a client requests more than one resource of any type, the server MUST behave as if the resources of that type (beyond the first one) are not available.</p>

<p id="rfc.section.2.p.5">MRCPv2 clients and servers using TCP as a transport protocol MUST use the procedures specified in <a href="#RFC4145" class="xref">RFC 4145</a> for setting up the TCP connection, with the considerations described hereby. Similarly, MRCPv2 clients and servers using TCP/TLS as a transport protocol MUST use the procedures specified in <a href="#RFC4572" class="xref">RFC 4572</a> for setting up the TLS connection, with the considerations described hereby. The a=setup attribute, as described in <a href="#RFC4145" class="xref">RFC 4145</a>, MUST be "active" for the offer from the client and MUST be "passive" for the answer from the MRCPv2 server. The a=connection attribute MUST have a value of "new" on the very first control "m=" line offer from the client to an MRCPv2 server. Subsequent control "m=" line offers from the client to the MRCP server MAY contain "new" or "existing", depending on whether the client wants to set up a new connection or share an existing connection, respectively. If the client specifies a value of "new", the server MUST respond with a value of "new". If the client specifies a value of "existing", the server MUST respond. The legal values in the response are "existing" if the server prefers to share an existing connection or "new" if not. In the latter case, the client MUST initiate a new transport connection.</p>

<p id="rfc.section.2.p.6">When the client wants to deallocate the resource from this session, it issues a new SDP offer, according to <a href="#RFC3264" class="xref">RFC 3264</a>, where the control "m=" line port MUST be set to 0. This SDP offer is sent in a SIP re-INVITE request. This deallocates the associated MRCPv2 identifier and resource. The server MUST NOT close the TCP or TLS connection if it is currently being shared among multiple MRCP channels. When all MRCP channels that may be sharing the connection are released and/or the associated SIP dialog is terminated, the client or server terminates the connection.</p>

<p id="rfc.section.2.p.7">When the client wants to tear down the whole session and all its resources, it MUST issue a SIP BYE request to close the SIP session.  This will deallocate all the control channels and resources allocated under the session.</p>

<p id="rfc.section.2.p.8">All servers MUST support TLS. Servers MAY use TCP without TLS in controlled environments (e.g., not in the public Internet) where both nodes are inside a protected perimeter, for example, preventing access to the MRCP server from remote nodes outside the controlled perimeter. It is up to the client, through the SDP offer, to choose which transport it wants to use for an MRCPv2 session. Aside from the exceptions given above, when using TCP, the "m=" lines MUST conform to <a href="#RFC4145" class="xref">RFC4145</a>, which describes the usage of SDP for connection-oriented transport. When using TLS, the SDP "m=" line for the control stream MUST conform to <a href="#RFC4572" class="xref">Connection-Oriented Media (COMEDIA) over TLS</a>, which specifies the usage of SDP for establishing a secure connection-oriented transport over TLS.</p>

<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> Section Three</h1>

<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#sec.synthMessageBody" id="sec.synthMessageBody">Synthesizer Message Body</a>
</h1>

<p id="rfc.section.3.1.p.1">A synthesizer message can contain additional information associated with the Request, Response, or Event in its message body.</p>

<h1 id="rfc.section.3.1.1">
<a href="#rfc.section.3.1.1">3.1.1.</a> Synthesizer Speech Data</h1>

<p id="rfc.section.3.1.1.p.1">Marked-up text for the synthesizer to speak is specified as a typed media entity in the message body. The speech data to be spoken by the synthesizer can be specified inline by embedding the data in the message body or by reference by providing a URI for accessing the data. In either case, the data and the format used to markup the speech needs to be of a content type supported by the server.</p>

<p id="rfc.section.3.1.1.p.2">All MRCPv2 servers containing synthesizer resources MUST support both plain text speech data and W3C's <a href="#W3C.REC-speech-synthesis-20040907" class="xref">Speech Synthesis Markup Language</a> and hence MUST support the media types 'text/plain' and 'application/ssml+xml'. Other formats MAY be supported.</p>

<p id="rfc.section.3.1.1.p.3">If the speech data is to be fetched by URI reference, the media type 'text/uri-list' (see <a href="#RFC2483" class="xref">RFC 2483</a>) is used to indicate one or more URIs that, when dereferenced, will contain the content to be spoken. If a list of speech URIs is specified, the resource MUST speak the speech data provided by each URI in the order in which the URIs are specified in the content.</p>

<p id="rfc.section.3.1.1.p.4">MRCPv2 clients and servers MUST support the 'multipart/mixed' media type. This is the appropriate media type to use when providing a mix of URI and inline speech data. Embedded within the multipart content block, there MAY be content for the 'text/uri-list', 'application/ssml+xml', and/or 'text/plain' media types. The character set and encoding used in the speech data is specified according to standard media type definitions. The multipart content MAY also contain actual audio data. Clients may have recorded audio clips stored in memory or on a local device and wish to play it as part of the SPEAK request. The audio portions MAY be sent by the client as part of the multipart content block. This audio is referenced in the speech markup data that is another part in the multipart content block according to the 'multipart/mixed' media type specification.</p>