1、在前面的章節中，我們已經(jīng)介紹了MRCP的架構。在MRCP的架構中，通過(guò)SIP來(lái)創(chuàng )建和管理會(huì )話(huà)，以保證MRCP客戶(hù)端和服務(wù)器端的正常工作。這里，系統都使用標準的三方通信機制INVITE-200 OK-ACK的方式來(lái)創(chuàng )建媒體和會(huì )話(huà)控制，使用BYE-200 OK來(lái)結束會(huì )話(huà)，其中，系統使用SDP的Offer/Answer模式來(lái)進(jìn)行媒體和會(huì )話(huà)支持能力，屬性等的協(xié)商。在接下來(lái)的分享中，我們將通過(guò)具體的示例，并且結合握手機制，SDP協(xié)商等流程來(lái)進(jìn)一步討論關(guān)于SIP在MRCP中的角色和其作用。
2、大家知道，SDP是MRCP客戶(hù)端提供的終端側的支持能力的描述。首先讓我們看一下關(guān)于控制話(huà)的初始化過(guò)程中的SDP協(xié)商能力的支持消息。每個(gè)通道都會(huì )創(chuàng )建一個(gè)唯一的通道ID號，通過(guò)通道ID號和其他的通道來(lái)加以區別。以下是一段關(guān)于SDP的描述消息。
c=IN IP4 10.0.0.1
m=application 9 TCP/MRCPv2 // 客戶(hù)端端口是9
a=setup:active // 表示是客戶(hù)端發(fā)起的，媒體服務(wù)器端則回復passive
a=connection:new
a=resource:speechsynth
a=cmid:1
通過(guò)以上的消息體，我們可以看到SDP的所描述的支持能力。這里，c=中表示一個(gè)客戶(hù)端的IP地址。消息體中可能包含多個(gè)m=來(lái)媒體類(lèi)型。每個(gè)m=表示單個(gè)的控制通道，并且支持一個(gè)或多個(gè)媒體資源的映射。這里的是TCP TCP/MRCPv2，也可能支持實(shí)現TLS支持：TCP/TLS/MRCPv2。m= 中的9表示MRCP客戶(hù)端的端口號。注意，MRCP客戶(hù)端的端口號只能是9或0。9 表示將被丟棄的端口；0 表示一個(gè)特殊含義，此通道將被關(guān)閉。客戶(hù)端也可以提供一個(gè)0端口來(lái)指示關(guān)閉MRCP的控制通道。
MRCP客戶(hù)端必須總是需要通過(guò)a=來(lái)發(fā)起一個(gè)初始化的連接。客戶(hù)端的a=是active，而服務(wù)器端則會(huì )返回passive。如果是一個(gè)新的連接，則使用a=connection:new；如果是一個(gè)已存在的連接，則使用existing來(lái)表示。
客戶(hù)端通過(guò)a=resource:來(lái)指定媒體服務(wù)的類(lèi)型，這里的是speechsynth。
a=cmid則和媒體流的控制通道相關(guān)聯(lián)。這里的cmid值必須匹配屬于媒體流的cmid值。有一些情況下（例如，在同一個(gè)SIPdialog中，同時(shí)語(yǔ)音合成和語(yǔ)音識別同時(shí)啟用，使用了單個(gè)sendrecv 媒體資源），多個(gè)媒體通道使用同一cmid值，這表示一個(gè)或多個(gè)媒體控制通道正在使用同一個(gè)媒體流資源。
上面我們介紹了MRCP客戶(hù)端初始化中INVITE的SDP消息，現在讓我們看一下從服務(wù)器端返回的消息體（200 OK）包含了那些內容：
c=IN IP4 10.0.0.22
m=application 43251 TCP/MRCPv2
a=setup:passive
a=connection:new
a=channel:43b9ae17@speechsynth
a=cmid:1
這里在m=中表示了服務(wù)器端口是4325，通過(guò)此支持客戶(hù)端創(chuàng )建連接。c=包含了服務(wù)器的IP地址。a=說(shuō)明了passive，通過(guò)服務(wù)器端返回的值。增加了另外一行a=,它來(lái)表示創(chuàng )建的通道ID。cmid和上面的客戶(hù)端消息中的一致。
3、現在，我們介紹兩個(gè)會(huì )話(huà)初始化的思路，讓讀者能夠更加清楚了解MRCP的初始化過(guò)程。以下是一個(gè)示例流程（INVITE-200 OK-ACK）：
MRCP客戶(hù)端的INVITE信息示例：
INVITE sip:mrcpv2@example.com SIP/2.0
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKabc
Max-Forwards: 70
To:
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 264
v=0
o=client 2890844527 2890844527 IN IP4
host1.example.com
s=-
c=IN IP4 host1.example.com
t=0 0
m=audio 5324 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
a=mid:1
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:new
a=resource:speechsynth
a=cmid:
讀者需要注意，這里的SDP消息體中包含了兩個(gè)m=值。第一個(gè)m= 用來(lái)創(chuàng )建媒體流數據連接。第二個(gè)m=用來(lái)表示對媒體資源的會(huì )話(huà)控制。資源類(lèi)型是speechsynth。a=recvonly表示來(lái)自MRCP客戶(hù)端方向接收。
MRCP發(fā)出INVITE請求后，MRCP服務(wù)器端返回200 OK響應消息和SDP消息體：
SIP/2.0 200 OK
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKabc
;received=192.168.1.11
Max-Forwards: 70
To: ;tag=98452
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 1 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 274
v=0
o=server 31412312 31412312 IN IP4 host100.example.com
s=-
c=IN IP4 host100.example.com
t=0 0
m=audio 4620 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly // 發(fā)送
a=mid:1
m=application 9001 TCP/MRCPv2 // 通過(guò)TCP發(fā)送
a=setup:passive // 從服務(wù)器端發(fā)出。
a=connection:new
a=channel:153af6@speechsynth // 通道ID
a=cmid:1
這里，服務(wù)器 200 OK消息中表示了服務(wù)器端的必要信息，包括了服務(wù)器端的發(fā)送端口（4620）。
最后，MRCP客戶(hù)端發(fā)送一個(gè)確認信息（ACK）：
ACK sip:mrcpv2@host100.example.com SIP/2.0
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK214
Max-Forwards: 70
To: ;tag=98452
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 1 ACK
Contact:
Content-Length: 0
4、在上面的介紹中，我們給出了一個(gè)創(chuàng )建請求的示例。但是很多情況下，MRCP客戶(hù)端不可能僅實(shí)現一個(gè)請求回復的流程，在使用過(guò)程中，可能會(huì )發(fā)生很多的變化，通過(guò)發(fā)送一個(gè)re-INVITE來(lái)控制目前存在的SIPdialog會(huì )話(huà)屬性，例如需要臨時(shí)添加一些媒體資源或使用媒體資源后刪除此媒體資源。關(guān)于SIP re-INVITE
的詳細說(shuō)明讀者可以查閱我們的歷史文檔，也可以參考其他的SIP學(xué)習資源來(lái)獲取關(guān)于re-INVITE的說(shuō)明。對會(huì )話(huà)的控制需要MRCP客戶(hù)端重新發(fā)起一個(gè)re-INVITE消息來(lái)實(shí)現。首先，讓我們看一下簡(jiǎn)單的流程示例：
這是MRCP客戶(hù)端發(fā)起的re-INVITE消息：
INVITE sip:mrcpv2@host100.example.com SIP/2.0
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK452
Max-Forwards: 70
To: ;tag=98452
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 2 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 367
v=0
o=client 2890844527 2890844528 IN IP4
host1.example.com
s=-
c=IN IP4 host1.example.com
t=0 0
m=audio 5324 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=mid:1
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=application 9 TCP/MRCPv2 // 第三個(gè)m 增加了對recording 的控制
a=setup:active
a=connection:existing
a=resource:recorder
a=cmid:1
從以上的re-INVITE消息中我們可以看出，事實(shí)上，INVITE消息和re-INVITE消息幾乎相似，但是在存在的SIPdialog中增加了To和From。另外，因為SDP模式中的offer/answer中需要更新完整的會(huì )話(huà)屬性參數，因此，MRCP客戶(hù)端會(huì )修改一些參數來(lái)支持SDP協(xié)商。
這里，讀者可能注意到，o= 的數值增加了1表示會(huì )話(huà)被修改。a= 在INVITE消息中是reconly, 但是現在修改為a=sendrecv。m=也修改為existing, 而不是new。第三個(gè)m= 增加了對新recorder的會(huì )話(huà)控制。這是re-INVITE在此dialog中的真正作用。這里的recorder 和speechsynth共享同樣的媒體流，因為這里的cmid仍然是1。
接下來(lái)，服務(wù)器端接受這個(gè)re-INVITE的會(huì )話(huà)屬性，然后返回一個(gè)200 OK消息：
SIP/2.0 200 OK
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK452
;received=192.168.1.1
To: ;tag=98452
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 2 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 387
v=0
o=client 31412312 31412313 IN IP4 host100.example.com
s=-
c=IN IP4 host100.example.com
t=0 0
m=audio 4620 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=mid:1
m=application 9001 TCP/MRCPv2
a=setup:passive
a=connection:existing
a=channel:153af6@speechsynth
a=cmid:1
m=application 9001 TCP/MRCPv2
a=setup:passive
a=connection:existing
a=channel: 153af6@recorder
a=cmid:1
服務(wù)器端的響應消息中，其他的屬性沒(méi)有特別的變化，但是增加了對recorder的新的通道ID：a=channel: 153af6@recorder。
MRCP 客戶(hù)端繼續發(fā)送一個(gè)ACK確認消息：
ACK sip:mrcpv2@host100.example.com SIP/2.0
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK554
Max-Forwards: 70
To: ;tag=98452
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 2 ACK
Contact:
Content-Length: 0
至此，增加recorder的流程完成。
當完成錄音以后，如果MRCP需要刪除recorder 資源時(shí)，則需要再對服務(wù)器端發(fā)送一個(gè)re-INVITE消息來(lái)更新其會(huì )話(huà)管理。
INVITE sip:mrcpv2@host100.example.com SIP/2.0
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK763
Max-Forwards: 70
To: ;tag=98452
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 3 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 367
v=0
o=client 2890844527 2890844529 IN IP4
host1.example.com
s=-
c=IN IP4 host1.example.com
t=0 0
m=audio 5324 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
a=mid:1
m=application 9 TCP/MRCPv2
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=application 0 TCP/MRCPv2 // 針對相應的媒體資源更新為0-刪除資源
a=setup:active
a=connection:existing
a=resource:recorder
a=cmid:1
在以上的re-INVITE中，媒體會(huì )話(huà)已經(jīng)更新為reconly 表示只能接收此會(huì )話(huà)的媒體流，以前是sendrecv 方式。同時(shí)，如果刪除某一項媒體資源的話(huà)，需要在相應的m= 增加端口0表示對其媒體資源進(jìn)行刪除或釋放。
媒體服務(wù)器端則會(huì )回復一個(gè)200 OK消息：
SIP/2.0 200 OK
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK763
;received=192.168.1.1
To: ;tag=98452
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 3 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 384
v=0
o=client 31412312 31412314 IN IP4 host100.example.com
s=-
c=IN IP4 host100.example.com
t=0 0
m=audio 4620 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
a=mid:1
m=application 9001 TCP/MRCPv2
a=setup:passive
a=connection:existing
a=channel:153af6@speechsynth
a=cmid:1
m=application 0 TCP/MRCPv2
a=setup:passive
a=connection:existing
a=channel: 153af6@recorder
a=cmid:1
在以上的媒體資源服務(wù)器的回復中，媒體資源服務(wù)器確認會(huì )關(guān)閉recorder 端口，增加了端口0，并且對此MRCP客戶(hù)端會(huì )話(huà)中的媒體發(fā)送方式修改為sendonly。
最后，MRCP客戶(hù)端會(huì )發(fā)送一個(gè)ACK確認消息表示此re-INVITE確認，刪除recorder 媒體資源，然后對服務(wù)器端發(fā)送BYE消息：
ACK sip:mrcpv2@host100.example.com SIP/2.0
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK432
Max-Forwards: 70
To: ;tag=98452
From: ;tag=12425
Call-ID: 43fb8aec@host1.example.com
CSeq: 3 ACK
Contact:
Content-Length: 0
至此，整個(gè)刪除recorder 媒體資源的流程結束。
5、在上面的示例中，我們介紹了一個(gè)單媒體源的流程處理方式。現在讓我們進(jìn)一步討論如何實(shí)現分布式媒體源的處理流程和SIP在處理流程中所扮演的角色。在分布式的媒體源處理流程中，媒體源可以是一個(gè)SIP終端，媒體網(wǎng)關(guān)或者其他的SIP應用。MRCP 客戶(hù)端則作為一個(gè)背靠背代理（B2BUA）的方式工作，簡(jiǎn)單來(lái)說(shuō)，媒體源來(lái)說(shuō)，MRCP 客戶(hù)端作為一個(gè)SIP 用戶(hù)代理的方式來(lái)工作，同時(shí)，MRCP客戶(hù)端也作為一種SIP 代理的模式來(lái)配合媒體資源服務(wù)器。所以，如以下示例所示，在整個(gè)會(huì )話(huà)控制流程中，MRCP 客戶(hù)端會(huì )生成兩個(gè)SDP描述消息。一個(gè)是針對媒體源的SDP消息，另外一個(gè)是針對媒體資源服務(wù)器的SDP消息。
現在讓我們根據以上圖例所示，一步步討論B2BUA中INVITE消息，200 OK消息中SDP消息所發(fā)生的變化。
首先是媒體源在INVITE中提供的SDP消息（SDPo1）：
v=0
o=Bob 31245351 31245352 IN IP4 pc02.newton.com
s=-
c=IN IP4 pc02.newton.com
t=0 0
m=audio 5632 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=sendrecv
MRCP客戶(hù)端接受了INVITE消息，它根據應用客戶(hù)端的請求在會(huì )話(huà)中生成了媒體資源類(lèi)型消息，并且根據SDPo1的描述重新生成了一個(gè)SDPo2的消息內容，這些內容會(huì )包含到MRCP客戶(hù)端對媒體資源服務(wù)器發(fā)起的INVITE消息中：
v=0
o=Client 43523532 43523532 IN IP4 host01.example.com
s=-
t=0 0
m=audio 5632 RTP/AVP 8
c=IP IP4 pc02.newton.com
a=rtpmap:8 PCMA/8000
a=sendrecv
a=mid:1
m=application 9 TCP/MRCPv2
c=IN IP4 host01.example.com
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=application 9 TCP/MRCPv2
c=IN IP4 host01.example.com
a=setup:active
a=connection:existing
a=resource:speechrecog
a=cmid:
注意，這里的每個(gè)m= 都和一個(gè)c=相關(guān)聯(lián)。c= 則攜帶了m=指定的媒體源地址
。m=的媒體端口和媒體源的端口是一致的。
媒體資源服務(wù)器端則回復200 OK消息，并且返回SDPa2 的消息內容：
v=0
o=Server 15454326 15454326 IN IP4 host99.example.com
s=-
t=0 0
m=audio 87242 RTP/AVP 8 // 定義了媒體端口
c=IP IP4 host99.example.com
a=rtpmap:8 PCMA/8000
a=sendrecv
a=mid:1
m=application 56723 TCP/MRCPv2 // 定義了媒體資源服務(wù)類(lèi)型
c=IN IP4 host99.example.com
a=setup:passive
a=connection:existing
a=channel:42a6f3e9@speechsynth
a=cmid:1
m=application 56723 TCP/MRCPv2 // 定義了媒體資源服務(wù)類(lèi)型
c=IN IP4 host99.example.com
a=setup:passive
a=connection:existing
a=channel: 42a6f3e9@speechrecog
a=cmid:1
在SDPa2 中，媒體資源服務(wù)器通知MRCP客戶(hù)端使用的端口和其使用的媒體資源服務(wù)類(lèi)型，通道ID等消息。
MRCP客戶(hù)端收到媒體資源服務(wù)器端返回的200 OK消息，然后基于SDPa2的描述內容，再次生成新的SDPa1 描述內容發(fā)送到媒體源：：
v=0
o=Client 24356331 24356331 IN IP4 host01.example.com
s=-
c=IP IP4 host99.example.com // 這里定義了媒體資源服務(wù)器的地址
t=0 0
m=audio 87242 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=sendrecv
這里定義了媒體資源服務(wù)器的地址。媒體源對MRCP客戶(hù)端發(fā)送ACK消息確認，MRCP客戶(hù)端繼續對媒體資源服務(wù)器發(fā)送ACK消息確認。至此，媒體源，MRCP客戶(hù)端和媒體資源服務(wù)器之間的協(xié)商流程完成，媒體流數據可以正式發(fā)送。
6、通過(guò)以上多個(gè)示例的介紹，我們把整個(gè)SIP協(xié)議在進(jìn)行握手處理中SDP消息的內容變化都進(jìn)行了介紹，并且通過(guò)完整的示例流程介紹了MRCP客戶(hù)端，媒體資源服務(wù)器端的SDP消息說(shuō)明，另外也介紹了分布式媒體源和MRCP協(xié)議的通過(guò)B2BUA的方式進(jìn)行媒體資源服務(wù)器的協(xié)商處理，和在其消息生成過(guò)程中各自SDP的描述變化。筆者希望通過(guò)此章節的介紹筆者用戶(hù)基本了解了SIP協(xié)議在MRCP協(xié)商過(guò)程中所扮演的控制角色，對MRCP流程有一個(gè)非常清晰的概念。在接下來(lái)的章節中，我們會(huì )針對媒體資源服務(wù)器的分布式部署查詢(xún)定位的處理進(jìn)行討論介紹。
unimrcp-MRCP協(xié)議學(xué)習分享，QQ群號：208136295
關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的行業(yè)分享
freepbx 技術(shù)論壇：www.ippbx.org.cn
Asterisk， freepbx技術(shù)文檔： www.freepbx.org.cn
歐米（Omni）智能客服解決方案
融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
