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