MRCPv2 is the abbreviation of Media Resource Control Protocol Version 2 (MRCPv2). This article translates RFC6787 section 4.2. Managing Resource Control Channels
4.2. Managing Resource Control Channels resource control channel management
The client needs a separate MRCPv2 resource control channel ( Resource Control Channel ) to control each media processing resource under the SIP conversation.
Unique channel identifier strings identify these resource control channels. A channel identifier is a hard-to-guess unambiguous string followed by an "@" and then a string tag specifying the type of resource . The server generates the channel identifier and must ensure that it does not conflict with the identifiers of any other MRCP channels currently assigned by the server. MRCPv2 defines the following IANA-registered media processing resource types. Additional resource types and their associated methods/events and state machines can be added as described in Section 13 below.
| Resource Type | Resource Description | Described in |
|---|---|---|
| speechrecog | Speech Recognizer | Section 9 |
| dtmfrecog | DTMF Recognizer | Section 9 |
| speechsynth | Speech Synthesizer | Section 8 |
| basicsynth | Basic Synthesizer | Section 8 |
| speakverify | Speaker Verification | Section 11 |
| recorder | Speech Recorder | Section 10 |
Table 1: Resource Types
A SIP INVITE or re-INVITE transaction and the SDP offer/answer exchange it carries contains an " m= " line describing the resource control channel to be allocated . There must be an SDP " m= " line for each MRCPv2 resource used in a session .
The " m= " line MUST have an " application " media type field and a " TCP/MRCPv2 " or " TCP/TLS/MRCPv2 " transport type field.
The port number field of the " m= " line MUST contain the "drop" port (TCP port 9) of the transport protocol in the SDP provided by the client , and MUST contain the TCP listening port on the server in the SDP answer. Clients can then establish a TCP or TLS connection to that server port, or share an established connection to that port.
The following example
m=application 9 TCP/MRCPv2 1
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 that between resources using the same port any relationship exists.
MRCPv2 resources do not use the port or format fields of the " m= " line to distinguish them 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 provided by the SDP. The server MUST respond with the full Channel-Identifier (including the resource-type identifier and the hard-to-guess unambiguous string) in the " channel " attribute associated with the controlling " m= " line of the SDP reply . To maintain backward compatibility with legacy SDP usage, the format field of the " m= " line MUST have an arbitrarily chosen value of "1".
The following example
m=application 32416 TCP/MRCPv2 1 # The last 1
a=channel:32AECB234338@speechsynth #Channel-Identifier is 32AECB234338
When a client wants to add media processing resources to a session, it issues a new SDP offer in a SIP Re-Invite request according to the procedure of RFC 3264 [RFC3264]. The SDP offer/answer exchange carried by this SIP transaction contains one or more additional control " m= " lines for new resources allocated to the session.
The server allocates resources (if they are available) when it sees the new " m= " line and responds with the corresponding control " m= " line in the SDP reply carried in the SIP response . If new resources are not available, the re-INVITE will receive an error message, and existing media processing that was in progress prior to the re-INVITE will continue as before. It is not possible to allocate more than one resource of each type. If a client requests multiple resources of any type, the server MUST behave as if resources of that type (beyond the first resource) are not available.
MRCPv2 clients and servers using TCP as the transport protocol MUST use the procedures specified in RFC 4145 [RFC4145] to establish a TCP connection, taking into account the considerations described here.
Similarly, MRCPv2 clients and servers using TCP/TLS as the transport protocol MUST use the procedure specified in RFC 4572 [RFC4572] to set up a TLS connection, taking into account the considerations described here.
The a=setup attribute, as specified in RFC 4145 [RFC4145], MUST be "active" for offers from clients and " passive " for replies from MRCPv2 servers.
The following client example
a=setup:active
The following server example
a=setup:passive
The a=connection attribute must have the value "new" in the first control " m= " line from the client to the MRCPv2 server. Subsequent control "m=" lines provided from the client to the MRCP server may contain "new" or "existing", depending on whether the client wants to separately establish a new connection or share an existing connection . 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. Legal values in the response are " existing " if the server prefers to share an existing connection, and " new " otherwise. In the latter case, the client must initiate a new transport connection.
The following client example
a=connection:existing
According to RFC 3264 [RFC3264], when a client wants to release resources from this session, it issues a new SDP offer in which the control "m=" line port MUST be set to 0 .
This SDP proposes to send a re-invite request in SIP. This releases the associated MRCPv2 identifier and resources. A server MUST NOT close a TCP or TLS connection if it is currently being shared between multiple MRCP channels. A client or server terminates a connection when all MRCP channels that might share the connection are released and/or the associated SIP dialog is terminated.
The following client example
m=application 0 TCP/MRCPv2 1 # The 0 behind the application identifies the port, which is to delete
When a client wants to terminate the entire session and all its resources, it must issue a SIP BYE request to close the SIP session.
This will deallocate all control channels and resources allocated under the session.
All servers must support TLS. A server can use TCP without TLS in a controlled environment (eg not in the public internet) where both nodes are within a protected range, eg preventing access to the MRCP server from a remote node outside the controlled range. Offered by the client via SDP to select the transport it wants to use for the MRCPv2 session.
With the exceptions given above, when using TCP, the " m= " line MUST conform to RFC4145 [RFC4145], which describes the use of SDP for connection-oriented transports. When using TLS, the SDP "m=" line of the control flow must conform to Connection-Oriented Media over TLS (COMEDIA) [RFC4572], which specifies the use of SDP to establish a secure connection-oriented transport over TLS.