MRCPv2 是 Media Resource Control Protocol Version 2 (MRCPv2)的缩写，这一篇翻译RFC6787一节4.2. Managing Resource Control Channels
4.2. Managing Resource Control Channels 资源控制通道管理
客户端需要单独的MRCPv2 资源控制通道(Resource Control Channel) 来控制SIP对话下的各个媒体处理资源。
唯一的通道标识符字符串标识这些资源控制通道。 通道标识符是一个难以猜测的明确字符串，后跟一个“@”，然后是一个指定资源类型的字符串标记。 服务器生成通道标识符，并且必须确保它不会与该服务器当前分配的任何其他 MRCP 通道的标识符冲突。 MRCPv2 定义了以下 IANA 注册的媒体处理资源类型。 额外的资源类型及其关联的方法/事件和状态机可以添加，如下面第 13 节所述。
| 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
SIP INVITE 或 re-INVITE 事务及其承载的 SDP 提议/应答交换包含描述要分配的资源控制信道的“m=”行。 会话中使用的每个 MRCPv2 资源必须有一个 SDP“m=”行。
这个“m=”行必须有一个“application”的媒体类型字段和一个“TCP/MRCPv2”或“TCP/TLS/MRCPv2”的传输类型字段。
“m=”行的端口号字段必须包含客户端提供的 SDP 中传输协议的“丢弃”端口（TCP 端口 9），并且必须包含 SDP 应答中服务器上的 TCP 侦听端口。 然后，客户端可以建立到该服务器端口的 TCP 或 TLS 连接，或者共享到该端口的已建立连接。
如下示例
m=application 9 TCP/MRCPv2 1
由于 MRCPv2 允许多个会话共享相同的 TCP 连接，单个 SDP 文档中的多个“m=”行可以共享相同的端口字段值； 除了共享通信通道之外，MRCPv2 服务器不得假定使用相同端口的资源之间存在任何关系。
MRCPv2 资源不使用“m=”行的端口或格式字段来区别于使用相同通道的其他资源。 客户端必须在与 SDP 提供的控制“m=”行关联的资源属性中指定资源类型标识符。 服务器必须在与 SDP 应答的控制“m=”行关联的“channel”属性中用完整的 Channel-Identifier（包括资源类型标识符和难以猜测的明确字符串）进行响应。 为了保持与传统 SDP 使用的向后兼容，“m=”行的格式字段必须具有任意选择的值“1”。
如下示例
m=application 32416 TCP/MRCPv2 1 # 最后的1
a=channel:32AECB234338@speechsynth #Channel-Identifier为32AECB234338
当客户端想要向会话添加媒体处理资源时，它会根据 RFC 3264 [RFC3264] 的过程在 SIP 重新邀请请求中发出新的 SDP 提议。 此 SIP 事务承载的 SDP 提议/应答交换包含一个或多个附加控制“m=”行，用于分配给会话的新资源。
服务器在看到新的“m=”行时分配资源（如果它们可用）并在 SIP 响应中携带的 SDP 应答中使用相应的控制“m=”行进行响应。 如果新资源不可用，re-INVITE 会收到一条错误消息，并且在 re-INVITE 之前正在进行的现有媒体处理将像以前一样继续进行。 不可能为每种类型分配一个以上的资源。 如果客户端请求任何类型的多个资源，则服务器必须表现得好像该类型的资源（第一个资源之外）不可用。
使用 TCP 作为传输协议的 MRCPv2 客户端和服务器必须使用 RFC 4145 [RFC4145] 中指定的过程来建立 TCP 连接，并考虑此处所述的注意事项。
类似地，使用 TCP/TLS 作为传输协议的 MRCPv2 客户端和服务器必须使用 RFC 4572 [RFC4572] 中指定的过程来设置 TLS 连接，并考虑此处所述的注意事项。
a=setup 属性，如 RFC 4145 [RFC4145] 中所述，对于来自客户端的提议必须是“主动的”，对于来自 MRCPv2 服务器的应答必须是“passive”。
如下客户端示例
a=setup:active
如下服务端示例
a=setup:passive
a=connection 属性必须在从客户端到 MRCPv2 服务器的第一个控制“m=”行中具有“new”值。 从客户端向 MRCP 服务器提供的后续控制“m=”行可能包含“新”或“现有”，这取决于客户端是要分别建立新连接还是共享现有连接。 如果客户端指定一个值“new”，服务器必须响应一个“new”值。 如果客户端指定一个值“existing”，服务器必须响应。 如果服务器更愿意共享现有连接，则响应中的合法值为“existing”，否则为“new”。 在后一种情况下，客户端必须发起一个新的传输连接。
如下客户端示例
a=connection:existing
根据 RFC 3264 [RFC3264]，当客户端想要从该会话中释放资源时，它发出一个新的 SDP 提议，其中控制“m=”线路端口必须设置为 0。
这个 SDP 提议在 SIP 中发送 重新邀请请求。 这会释放关联的 MRCPv2 标识符和资源。 如果当前正在多个 MRCP 通道之间共享，服务器不得关闭 TCP 或 TLS 连接。 当所有可能共享连接的 MRCP 通道被释放和/或关联的 SIP 对话终止时，客户端或服务器终止连接。
如下客户端示例
m=application 0 TCP/MRCPv2 1 # application后面的0 标识端口，这样就是删除
当客户端想要终止整个会话及其所有资源时，它必须发出 SIP BYE 请求以关闭 SIP 会话。
这将取消分配会话下分配的所有控制信道和资源。
所有服务器都必须支持 TLS。 服务器可以在受控环境（例如，不在公共互联网中）中使用不带 TLS 的 TCP，其中两个节点都在受保护范围内，例如，防止从受控范围外的远程节点访问 MRCP 服务器。 由客户端通过 SDP 提供来选择它想要用于 MRCPv2 会话的传输。
除了上面给出的例外情况，当使用 TCP 时，“m=”行必须符合 RFC4145 [RFC4145]，它描述了 SDP 在面向连接的传输中的用法。 使用 TLS 时，控制流的 SDP“m=”行必须符合基于 TLS 的面向连接的媒体 (COMEDIA) [RFC4572]，它指定了使用 SDP 来通过 TLS 建立安全的面向连接的传输。