Media Resource Control Protocol Version 2 (MRCPv2)
Extracted elements (31)
MRCPv2 does not run over RTSP because the consensus at the time work began was that using RTSP in the way MRCPv1 did would break the RTSP protocol or cause backward-compatibility problems, which was forbidden by Section 3.2 of RFC 4313. SIP was chosen instead as the session establishment protocol.
The channel identifier is designed to be 'difficult-to-guess' in addition to being unambiguous. This provides a modest security property: an attacker who does not know the identifier cannot inject or hijack control messages on an active channel, even if they can reach the TCP port.
If an MRCPv2 server implementation neither multiplexes nor mixes multiple resource streams onto a single audio session, it MUST reject the SDP offer with SIP 488. New implementations SHOULD treat a legacy SIP 501 response in this context as equivalent to a 488, to maintain interoperability with a large installed base that returns 501.
There is no expectation that an MRCPv2 client will work with an MRCPv1 server or vice versa. There is no migration plan or gateway definition between the two protocols; MRCPv1 was taken only as input to the design of MRCPv2.
All MRCPv2 messages (requests, responses, and events) MUST carry the Channel-Identifier header field so that the server or client can differentiate messages from different control channels sharing the same transport connection.
Clients and servers MUST implement TLS to meet the security requirements of the SPEECHSC requirements (RFC 4313). All MRCPv2 servers MUST support TLS; servers MAY use TCP without TLS only in controlled environments where both nodes are inside a protected perimeter.
Clients MUST utilize monotonically increasing request-ids for consecutive requests within an MRCP session. The request-id space is linear (not mod 32) and does not wrap. If the server receives duplicate or out-of-order requests, it MUST reject them with response code 410.
For SET-PARAMS, if the server accepts all parameters it MUST return 200; if it ignores optional header fields it MUST return 201. Error 403 takes priority over 409; error 404 takes priority over both. Error responses MUST echo back the bad or unsupported header fields exactly as sent.
GET-PARAMS with no parameter header fields causes the server MUST return all settable parameters and their values. If requested header fields are unsupported, the server MUST reject with 403 and MUST include the unsupported fields without values. Wildcard GET-PARAMS is RECOMMENDED to be used sparingly due to processing cost.
If an MRCPv2 client or server notices the underlying connection has been closed unexpectedly (without a prior re-INVITE closing that channel), it MUST send a SIP BYE to close down the SIP dialog and all other MRCP channels.
It is mandatory to support SIP as the session establishment protocol to ensure interoperability. Other protocols can be used for session establishment only by prior agreement; this document only describes the use of SIP and SDP.
The a=setup attribute MUST be 'active' for the SDP offer from the client and MUST be 'passive' for the answer from the MRCPv2 server, per RFC 4145 for TCP and RFC 4572 for TLS. The a=connection attribute MUST have value 'new' on the very first control 'm=' line offer.
The server MUST respond with the full Channel-Identifier (including the resource type and a difficult-to-guess, unambiguous string) in the 'channel' attribute of the SDP answer. The server MUST ensure the channel identifier does not clash with any other MRCP channel currently allocated on that server.
There MUST be one SDP 'm=' line for each MRCPv2 resource to be used in the session. This 'm=' line MUST have media type 'application' and transport type 'TCP/MRCPv2' or 'TCP/TLS/MRCPv2'. The port MUST be the discard port (9) in the client offer and the TCP listen port in the server answer.
MRCPv2 defines six resource types registered with IANA: speechrecog (Speech Recognizer), dtmfrecog (DTMF Recognizer), speechsynth (Speech Synthesizer), basicsynth (Basic Synthesizer), speakverify (Speaker Verification), and recorder (Speech Recorder). The resource type follows '@' in the channel identifier.
MRCPv2 defines Success codes 200 (success) and 201 (success with optional header fields ignored); Client Failure codes 401–410 (method not allowed, illegal state, unsupported header, illegal value, resource not found, missing mandatory header, operation failed, unrecognized entity, unsupported value, out-of-order sequence); and Server Failure codes 501–504.
The 'cmid' (channel media identifier) SDP attribute associates a control 'm=' line with one or more audio 'm=' lines by matching the 'cmid' value to the 'mid' attribute of audio lines. If a control 'm=' line has no 'cmid', it is not associated with any media, limiting operations such as RECOGNIZE (which requires media) while leaving INTERPRET functional.
The request-state field in a response indicates PENDING (queued for FIFO processing), IN-PROGRESS (being processed, further events expected), or COMPLETE (processed to completion, no more events will follow for that request-id).
IANA established the 'MRCPv2 Methods and Events' registry and the 'MRCPv2 Header Fields' registry, listing all defined methods (e.g., SPEAK, RECOGNIZE, RECORD, VERIFY) and header fields (e.g., Channel-Identifier, Completion-Cause, Confidence-Threshold) along with the resource types they apply to.
IANA established the 'MRCPv2 Resource Types' registry with initial values: speechrecog, dtmfrecog, speechsynth, basicsynth, speakverify, and recorder. New resource types may be added via IANA registration with corresponding methods/events and state machine definitions.
IANA registered SDP protocol identifiers 'TCP/MRCPv2' and 'TCP/TLS/MRCPv2' in the SDP 'proto' sub-registry, and the 'resource', 'channel', and 'cmid' SDP media-level attributes in the SDP att-field (media-level) sub-registry.
IANA registered the 'application/nlsml+xml' media type for Natural Language Semantics Markup Language (NLSML) results, the XML namespace 'urn:ietf:params:xml:ns:mrcpv2', the 'text/grammar-ref-list' media type, and the 'session' URI scheme used to reference in-session data.
Indirect content access via URIs (e.g., grammar URIs, audio URIs) introduces risk: a malicious client could direct the server to fetch content from arbitrary hosts or exhaust server resources. Implementations MUST carefully validate URI schemes and enforce access controls, and SHOULD use HTTPS for fetched content.
MRCPv2 control channels MUST be protected using TLS to prevent eavesdropping and tampering. SIP signaling used for rendezvous and session establishment SHOULD also be protected. Servers in controlled environments MAY use plain TCP, but MUST NOT expose plain TCP outside a protected perimeter.
The DELETE-VOICEPRINT method can irreversibly delete a speaker's voiceprint from a repository; servers MUST ensure appropriate authorization before permitting this operation. DTMF and recognition audio buffers may capture sensitive user input, requiring access controls to prevent unauthorized retrieval.
The Recorder resource defines a state machine (Section 10.1) driven by RECORD and STOP methods, with RECORD-COMPLETE as the terminal event. The recorder MUST provide endpointing for silence suppression at the beginning and end of recordings and MUST maintain timing metadata when silence is suppressed mid-recording.
The Speaker Verification resource defines a state machine (Section 11.1) for voiceprint enrollment and verification sessions. Key methods include START-SESSION, END-SESSION, VERIFY, VERIFY-FROM-BUFFER, VERIFY-ROLLBACK, QUERY-VOICEPRINT, and DELETE-VOICEPRINT, with VERIFICATION-COMPLETE as the terminal event.
The Speech Recognizer resource defines a state machine (Section 9.1) driven by RECOGNIZE, STOP, START-INPUT-TIMERS, and enrollment methods, with states reflecting idle, recognizing (IN-PROGRESS), and completion via RECOGNITION-COMPLETE event. Hotword mode allows continuous recognition against a small command grammar.
The Speech Synthesizer resource defines a state machine (Section 8.1) driven by methods including SPEAK, STOP, PAUSE, RESUME, BARGE-IN-OCCURRED, and CONTROL, with states transitioning based on whether a SPEAK request is PENDING, IN-PROGRESS (speaking), paused, or COMPLETE (via SPEAK-COMPLETE event).
An MRCPv2 message consists of a start-line, one or more header fields, an empty CRLF line terminating the headers, and an optional message body. Messages are UTF-8 encoded; lines are terminated by CRLF. The message-length field, which includes the start-line, MUST be the second token of every message to simplify framing and parsing.
The request-line format is: 'mrcp-version SP message-length SP method-name SP request-id CRLF'. The response-line format is: 'mrcp-version SP message-length SP request-id SP status-code SP request-state CRLF'. Clients and servers MUST indicate mrcp-version 'MRCP/2.0'.