MRCPv2基础知识
MRCPv2需要面向连接的传输层协议（如TCP），来保证客户端和服务端之间MRCPv2控制消息的保证传送和正确顺序，为了满足SPEECHSC要求[RFC4313]中列举的安全性要求，客户端和服务端也必须实现TLS。客户端和服务端之间的连接可以在到服务端的不同MRCPv2信道之间共享，消息携带信道标识符以区分不同信道上的消息，MRCPv2编码是基于文本的同时也支持携带内嵌式二进制数据的机制，这允许在MRCPv2消息中携带识别语法、识别结果、合成器语音标记等数据。有关消息框架的信息，请参阅第5节
4.1 服务端连接方式
MRCPv2将SIP与SDP结合使用作为会话建立和管理协议。客户端发送传统的INVITE和其他SIP请求到达MRCPv2服务端来建立、维护和终止SIP对话，SIP上的SDP提供/应答交互模型用于为每个资源建立资源控制信道。SDP提供/应答交互还用于在服务端与声音源或接收器之间建立媒体会话。
4.2 资源控制信道管理
客户端需要单独的MRCPv2资源控制通道来控制SIP对话下的每个媒体资源。唯一信道标识符字符串标识这些资源控制信道。通道标识符是由一个唯一的字符串后跟一个“@”，然后是一个指定资源类型的字符串标记组成的。通道标识符由服务端生成，并务必确保它不与该服务端当前分配的任何其他MRCP通道的标识符冲突，MRCPv2定义了以下IANA注册过的媒体处理类型资源，可以添加附加资源类型及其相关方法/事件和状态机，如下面13节所述
SIP INVITE、re-INVITE的SDP信息包含的”m=”行描述了要分配的资源控制信道，SDP中每个”m=”行对应于每个MRCPv2资源，该”m=”行具有”application”的媒体类型字段和”TCP/MRCPv2”或”TCP/TLS/MRCPv2”的传输类型字段，”m =”行的端口号字段必须包含来自客户端的SDP提供的传输协议的”丢弃”端口（TCP的端口9），并且必须在SDP应答中包含服务端上的TCP侦听端口，然后，客户端可以建立到该服务端端口的TCP或TLS连接，或者共享已建立的与该端口的连接。由于MRCPv2允许多个会话共享相同的TCP连接，因此单个SDP中的多个”m=”行可以共享相同的端口，除了共享通信信道之外，使用相同端口的资源之间不存在任何其它关系。
MRCPv2资源不使用”m=”行的端口或其它字段来区分使用相同通道的其他资源，客户端必须在与SDP提供的控制”m=”行相关的资源属性中指定资源类型标识符，服务端必须在与SDP应答的控制”m=”行相关联的”信道”中用完整的信道标识符（包括资源类型标识符唯一的字符串）进行响应。为了保持向后兼容传统的SDP使用，”m=”行的格式字段必须具有任意选择的值”1”。
当客户端想要向会话添加媒体资源时，它根据RFC 3264 [RFC3264]的程序在SIP re-INVITE请求中发出新的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连接。如RFC 4145 [RFC4145]中所述，对客户端的请求a=setup属性必须是’active’，而对MRCPv2服务端的响应a=setup属性必须是’passive’。a=connection属性必须从客户端到MRCPv2服务端的第一个控制’m=’行中提供，而且值必须为“new”。从客户端到MRCP服务端的后续控制’m=’行提供可以包含’new’或’existing’，这取决于客户端是想建立新连接还是使用现有连接，如果客户端指定值’new’，则服务端必须以值’new’响应，如果客户端指定值’existing’则服务端将共享现有连接，则响应中的合法值为’existing’，相反为’new’,在后一种情况下，客户端必须建立新的传输连接。
当客户端想要从会话中释放资源时，它会根据RFC 3264 [RFC3264]发出新的SDP请求，其中控制’m=’线路端口必须设置为0，此SDP请求在SIP中发送re-Invite请求,这释放了相关的MRCPv2标识符和资源的分配。如果当前资源正在多个MRCP通道之间共享，则服务端不得关闭TCP或TLS连接，当所有共享连接的所有MRCP信道释放或相关的SIP会话终止时，客户端或服务端终止TCP或TLS连接。
当客户端想要关闭整个会话及释放其所有资源时，它必须发出SIP BYE请求来关闭SIP会话然后释放在会话下分配的所有控制信道和资源。
所有服务端必须支持TLS，服务端可以在内部环境（不在公共互联网中）中使用不带TLS的TCP，要求其中两个节点都在受保护的边界内，客户可以通过SDP响应选择要用于MRCPv2会话的传输，当使用TCP时，’m=’行必须符合RFC4145 [RFC4145]，它描述了SDP用于面向连接的传输的用法,当使用TLS时，控制流的SDP’m=’行必须符合TLS [RFC4572]上的面向连接的媒体（COMEDIA）。
4.3 SIP会话例子
第一个例子显示了使用SIP如何路由到适当资源，在例子中，注意在INVITE中对域的请求是[email protected]，域中的SIP路由机制定位实际服务端[email protected]，该域名在200 OK中返回。
注：’cmid’在4.4节中定义。
例子中，SIP会话为语音合成器添加资源控制通道请求，由于合成器也会生成语音流，因此此交互还会为服务端创建仅接收实时协议（RTP）[RFC3550]媒体流的客户端。
与媒体相关的会话和MRCP独立。所以在例子中没有显示。
C->S: INVITE sip:[email protected] SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf1 Max-Forwards:6
To:MediaServer <sip:[email protected]> From:sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314161 INVITE
Contact:<sip:[email protected]> Content-Type:application/sdp
Content-Length:...
v=0
o=sarvi 2890844526 2890844526 IN IP4 192.0.2.12
s=-
c=IN IP4 192.0.2.12
t=0 0
m=application 9 TCP/MRCPv2 1 a=setup:active
a=connection:new a=resource:speechsynth a=cmid:1
m=audio 49170 RTP/AVP 0 a=rtpmap:0 pcmu/8000 a=recvonly
a=mid:1
S->C: SIP/2.0 200 OK
Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf1;received=192.0.32.10
To:MediaServer <sip:[email protected]>;tag=62784 From:sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314161 INVITE
Contact:<sip:[email protected]> Content-Type:application/sdp
Content-Length:...
v=0
o=- 2890842808 2890842808 IN IP4 192.0.2.11
s=-
c=IN IP4 192.0.2.11
t=0 0
m=application 32416 TCP/MRCPv2 1 a=setup:passive a=connection:new
a=channel:32AECB234338@speechsynth a=cmid:1
m=audio 48260 RTP/AVP 0 a=rtpmap:0 pcmu/8000 a=sendonly
a=mid:1
C->S: ACK sip:[email protected] SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf2 Max-Forwards:6
To:MediaServer <sip:[email protected]>;tag=62784 From:Sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314161 ACK
Content-Length:0
下面的例子是上面的延续，为识别器分配额外的资源控制通道，由于识别器需要接收用于识别的语音流，因此该会话还将语音流更新为sendrecv，使其成为双向RTP媒体会话。
C->S: INVITE sip:[email protected] SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf3 Max-Forwards:6
To:MediaServer <sip:[email protected]>;tag=62784 From:sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314162 INVITE
Contact:<sip:[email protected]> Content-Type:application/sdp
Content-Length:...
v=0
o=sarvi 2890844526 2890844527 IN IP4 192.0.2.12
s=-
c=IN IP4 192.0.2.12
t=0 0
m=application 9 TCP/MRCPv2 1 a=setup:active a=connection:existing a=resource:speechsynth a=cmid:1
m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15
a=sendrecv a=mid:1
m=application 9 TCP/MRCPv2 1 a=setup:active a=connection:existing a=resource:speechrecog a=cmid:1
S->C: SIP/2.0 200 OK
Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf3;received=192.0.32.10
To:MediaServer <sip:[email protected]>;tag=62784 From:sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314162 INVITE
Contact:<sip:[email protected]> Content-Type:application/sdp
Content-Length:...
v=0
o=- 2890842808 2890842809 IN IP4 192.0.2.11
s=-
c=IN IP4 192.0.2.11
t=0 0
m=application 32416 TCP/MRCPv2 1 a=setup:passive a=connection:existing a=channel:32AECB234338@speechsynth a=cmid:1
m=audio 48260 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15
a=sendrecv a=mid:1
m=application 32416 TCP/MRCPv2 1 a=setup:passive a=connection:existing a=channel:32AECB234338@speechrecog a=cmid:1
C->S: ACK sip:[email protected] SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf4 Max-Forwards:6
To:MediaServer <sip:[email protected]>;tag=62784 From:Sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314162 ACK
Content-Length:0
例: 增加语音识别能力
此例子是上述例子的延续，释放识别器通道。释放了识别器，不再需要接收语音流，因此该交互还会重新更新RTP媒体会话。
C->S: INVITE sip:[email protected] SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf5 Max-Forwards:6
To:MediaServer <sip:[email protected]>;tag=62784 From:sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314163 INVITE
Contact:<sip:[email protected]> Content-Type:application/sdp
Content-Length:...
v=0
o=sarvi 2890844526 2890844528 IN IP4 192.0.2.12
s=-
c=IN IP4 192.0.2.12
t=0 0
m=application 9 TCP/MRCPv2 1 a=resource:speechsynth a=cmid:1
m=audio 49170 RTP/AVP 0 a=rtpmap:0 pcmu/8000 a=recvonly
a=mid:1
m=application 0 TCP/MRCPv2 1 a=resource:speechrecog a=cmid:1
S->C: SIP/2.0 200 OK
Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf5;received=192.0.32.10
To:MediaServer <sip:[email protected]>;tag=62784 From:sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314163 INVITE
Contact:<sip:[email protected]> Content-Type:application/sdp
Content-Length:...
v=0
o=- 2890842808 2890842810 IN IP4 192.0.2.11
s=-
c=IN IP4 192.0.2.11
t=0 0
m=application 32416 TCP/MRCPv2 1 a=channel:32AECB234338@speechsynth a=cmid:1
m=audio 48260 RTP/AVP 0 a=rtpmap:0 pcmu/8000 a=sendonly
a=mid:1
m=application 0 TCP/MRCPv2 1 a=channel:32AECB234338@speechrecog a=cmid:1
C->S: ACK sip:[email protected] SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf6 Max-Forwards:6
To:MediaServer <sip:[email protected]>;tag=62784 From:Sarvi <sip:[email protected]>;tag=1928301774 Call-ID:a84b4c76e66710
CSeq:314163 ACK
Content-Length:0
例: 释放识别器资源
4.4 媒体流和RTP端口
客户端或服务端需要将媒体会话与其对应的资源相关联，这样MRCPv2资源才能发送、接收媒体流。单个媒体会话可以关联单个或多个资源，另外如果需要，可以将多个媒体会话与单个资源相关联，但这种方式目前的MRCP资源中没有用到。
例如，如果语音合成器和语音识别器以’sendrecv’模式打开，则它可以与同一媒体会话（m=audio line）相关联或语音识别器可以使用’recvonly’只接收媒体流，语音合成器可以使用自己的’sendonly’只发送媒体流。
媒体会话和控制信道之间是通过’resource channel media identifier’的媒体属性（’cmid’）来关联的，此属性的取值范围是[RFC5888]中定义的’mid’属性的值。如果有多个语音m=行，则每个’m=’行必须具有’mid’属性，每个’m=’行可以具有一个或多个’cmid’属性，这些属性和它所关联的语音’m=’行的’mid’属性相匹配。请注意，如果控制信息’m=’行没有’cmid’属性，则它不会与任何媒体相关联，因而对资源的操作将受到限制。例如，在语音识别过程中，RECOGNIZE方法需要关联媒体进行处理，而INTERPRET方法则不需要。’cmid’属性的格式由以下ABNF描述：
cmid-attribute = "a=cmid:" identification-tag identification-tag = token
为了灵活实现媒体会话到MRCPv2控制信道的映射，单个语音’m=’通道可以与单个或者多个资源关联。例如，如果客户端想要分配语音识别器和语音合成器并将它们与单个双向语音流相关联，则SDP将包含两个控制’m=’行和一个具有属性’sendrecv’的语音’m=’行。每个控制’m=’行将具有’cmid’属性，其值与语音’m=’行的’mid’匹配。另一方面，如果客户想要分配语音识别器和语音合成器，每个都有自己独立的语音流，则SDP提供将带有两个控制’m=’行（一个用于识别器，另一个用于合成器）和两个语音’m=’行（一个属性为’sendonly’，另一个属性为’recvonly’）。语音识别器’m=’行的’cmid’属性将匹配’sendonly’语音’m=’行的’mid’值，而语音合成器控件’m=’行的’cmid’属性将匹配’recvonly’的’m=’行的’mid’属性。
当服务端接收一个关联多个媒体处理资源的媒体会话上媒体流时，服务端需要复制媒体流到其它媒体资源去。如果MRCPv2会话中的多个资源都要生成媒体流，则服务端负责将多个流融合到单个RTP会话或包含嵌入式RTP混合器（参见RFC 3550 [RFC3550]）,将多个流合并为一个。在前一种情况下，媒体流将包含由不同源生成的RTP分组，分组具有不同的同步源标识符（SSRC）。在后一种情况下，RTP数据包将包含多个与原始流相对应的贡献源标识符（CSRC），然后由混合器进行组合。如果MRCPv2服务端实现既不复用也不混合，它必须回复SIP 488(不可接受)错误给客户端，拒绝将多个这样的资源关联到单个语音流。注意，在这种情况下，一般系统将返回SIP 501(未实现)错误。为了操作的互通性，当接收为501时，系统实现应该将此上下文中的501视为488。
4.5 MRCPv2消息传输
本文档中定义的MRCPv2消息通过客户端和服务端之间的TCP或TLS连接传输的。第4.1和4.2节讨论了建立连接传输通道和资源控制通道的方法，不同SIP会话的多个资源控制通道可以共享一个或多个TLS或TCP连接;服务端和客户端必须支持这种共享操作模式。客户端和服务端必须使用MRCPv2通道标识符（在各个MRCPv2消息中的通道标识符头字段中携带）来区分来自不同资源通道的MRCPv2消息（有关详细信息，请参见第6.2.1节）。所有MRCPv2服务端都必须支持TLS，服务端可以在内部环境（例如，不在公共互联网中）中使用不带TLS的TCP，其中两个节点都在受保护的环境内，例如，防止从受控边界外的远程节点访问MRCP服务端。是由客户端决定MRCPv2会话的传输模式
本文中例子仅显示MRCPv2消息，并且不显示用于建立MRCPv2控制信道的SIP消息
4.6 MRCPv2会话停止
如果MRCP客户端发现其MRCP通道之一的基础连接已关闭，并且之前没有启动re-INVITE来关闭该通道，则它必须发送BYE以关闭SIP对话和所有其他MRCP通道。如果MRCP服务端发现其MRCP通道之一的基础连接已经关闭，并且之前没有收到并接受关闭该通道的re-INVITE，那么它必须也发送一个BYE以关闭SIP对话框和其他所有MRCP通道