中文字幕在线视频第一页,黄色毛片在线看,日本爱爱网站,亚洲系列中文字幕一区二区

您當前的位置是：  首頁 > 新聞 > 國內 >
 首頁 > 新聞 > 國內 >

MRCP學習筆記-通過SIP協(xié)議實現會話管理

2018-05-21 09:37:41   作者：   來源：CTI論壇   評論：0 　點擊：

　　在前面的分享中，我們討論了MRCP的整體介紹，包括客戶端和服務器端的相互通信的流程。在這些流程中，它涉及了SIP和RTP的傳輸問題。我們在很多歷史文檔中已經對SIP協(xié)議和RTP協(xié)議做過很多介紹，這里我們不再做更多討論，讀者可以查閱歷史文章對SIP協(xié)議和RTP協(xié)議做一個補充了解。在本分享中，我們會專門針對SIP協(xié)議在MRCP中實現會話控制管理做一個比較完整的介紹，幫助讀者進一步了解SIP需要在MRCP協(xié)議中的作用。在下面的分享中，我們將介紹初始化會話，初始化示例，單媒體源，分布式的媒體源。
　　1、在前面的章節(jié)中，我們已經介紹了MRCP的架構。在MRCP的架構中，通過SIP來創(chuàng)建和管理會話，以保證MRCP客戶端和服務器端的正常工作。這里，系統(tǒng)都使用標準的三方通信機制INVITE-200 OK-ACK的方式來創(chuàng)建媒體和會話控制，使用BYE-200 OK來結束會話，其中，系統(tǒng)使用SDP的Offer/Answer模式來進行媒體和會話支持能力，屬性等的協(xié)商。在接下來的分享中，我們將通過具體的示例，并且結合握手機制，SDP協(xié)商等流程來進一步討論關于SIP在MRCP中的角色和其作用。
　　2、大家知道，SDP是MRCP客戶端提供的終端側的支持能力的描述。首先讓我們看一下關于控制話的初始化過程中的SDP協(xié)商能力的支持消息。每個通道都會創(chuàng)建一個唯一的通道ID號，通過通道ID號和其他的通道來加以區(qū)別。以下是一段關于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，也可能支持實現TLS支持：TCP/TLS/MRCPv2。m= 中的9表示MRCP客戶端的端口號。注意，MRCP客戶端的端口號只能是9或0。9 表示將被丟棄的端口；0 表示一個特殊含義，此通道將被關閉。客戶端也可以提供一個0端口來指示關閉MRCP的控制通道。
　　MRCP客戶端必須總是需要通過a=來發(fā)起一個初始化的連接。客戶端的a=是active，而服務器端則會返回passive。如果是一個新的連接，則使用a=connection:new；如果是一個已存在的連接，則使用existing來表示。
　　客戶端通過a=resource:來指定媒體服務的類型，這里的是speechsynth。
　　a=cmid則和媒體流的控制通道相關聯。這里的cmid值必須匹配屬于媒體流的cmid值。有一些情況下（例如，在同一個SIPdialog中，同時語音合成和語音識別同時啟用，使用了單個sendrecv 媒體資源），多個媒體通道使用同一cmid值，這表示一個或多個媒體控制通道正在使用同一個媒體流資源。
　　上面我們介紹了MRCP客戶端初始化中INVITE的SDP消息，現在讓我們看一下從服務器端返回的消息體（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=中表示了服務器端口是4325，通過此支持客戶端創(chuàng)建連接。c=包含了服務器的IP地址。a=說明了passive，通過服務器端返回的值。增加了另外一行a=,它來表示創(chuàng)建的通道ID。cmid和上面的客戶端消息中的一致。
　　3、現在，我們介紹兩個會話初始化的思路，讓讀者能夠更加清楚了解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)建媒體流數據連接。第二個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客戶端不可能僅實現一個請求回復的流程，在使用過程中，可能會發(fā)生很多的變化，通過發(fā)送一個re-INVITE來控制目前存在的SIPdialog會話屬性，例如需要臨時添加一些媒體資源或使用媒體資源后刪除此媒體資源。關于SIP re-INVITE
　　的詳細說明讀者可以查閱我們的歷史文檔，也可以參考其他的SIP學習資源來獲取關于re-INVITE的說明。對會話的控制需要MRCP客戶端重新發(fā)起一個re-INVITE消息來實現。首先，讓我們看一下簡單的流程示例：
　　這是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中需要更新完整的會話屬性參數，因此，MRCP客戶端會修改一些參數來支持SDP協(xié)商。
　　這里，讀者可能注意到，o= 的數值增加了1表示會話被修改。a= 在INVITE消息中是reconly, 但是現在修改為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中，媒體會話已經更新為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
　　在以上的媒體資源服務器的回復中，媒體資源服務器確認會關閉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 媒體資源的流程結束。
　　5、在上面的示例中，我們介紹了一個單媒體源的流程處理方式。現在讓我們進一步討論如何實現分布式媒體源的處理流程和SIP在處理流程中所扮演的角色。在分布式的媒體源處理流程中，媒體源可以是一個SIP終端，媒體網關或者其他的SIP應用。MRCP 客戶端則作為一個背靠背代理（B2BUA）的方式工作，簡單來說，媒體源來說，MRCP 客戶端作為一個SIP 用戶代理的方式來工作，同時，MRCP客戶端也作為一種SIP 代理的模式來配合媒體資源服務器。所以，如以下示例所示，在整個會話控制流程中，MRCP 客戶端會生成兩個SDP描述消息。一個是針對媒體源的SDP消息，另外一個是針對媒體資源服務器的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客戶端接受了INVITE消息，它根據應用客戶端的請求在會話中生成了媒體資源類型消息，并且根據SDPo1的描述重新生成了一個SDPo2的消息內容，這些內容會包含到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=相關聯。c= 則攜帶了m=指定的媒體源地址
　　。m=的媒體端口和媒體源的端口是一致的。
　　媒體資源服務器端則回復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 // 定義了媒體資源服務類型
　　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的描述內容，再次生成新的SDPa1 描述內容發(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é)商流程完成，媒體流數據可以正式發(fā)送。
　　6、通過以上多個示例的介紹，我們把整個SIP協(xié)議在進行握手處理中SDP消息的內容變化都進行了介紹，并且通過完整的示例流程介紹了MRCP客戶端，媒體資源服務器端的SDP消息說明，另外也介紹了分布式媒體源和MRCP協(xié)議的通過B2BUA的方式進行媒體資源服務器的協(xié)商處理，和在其消息生成過程中各自SDP的描述變化。筆者希望通過此章節(jié)的介紹筆者用戶基本了解了SIP協(xié)議在MRCP協(xié)商過程中所扮演的控制角色，對MRCP流程有一個非常清晰的概念。在接下來的章節(jié)中，我們會針對媒體資源服務器的分布式部署查詢定位的處理進行討論介紹。
　　　　

　　unimrcp-MRCP協(xié)議學習分享，QQ群號：208136295
　　關注微信公眾號：asterisk-cn，獲得有價值的行業(yè)分享
　　freepbx 技術論壇：www.ippbx.org.cn
　　Asterisk， freepbx技術文檔： www.freepbx.org.cn
　　歐米（Omni）智能客服解決方案
　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產品：www.hiastar.com
【免責聲明】本文僅代表作者本人觀點，與CTI論壇無關。CTI論壇對文中陳述、觀點判斷保持中立，不對所包含內容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考，并請自行承擔全部責任。

專題

棋牌| 凭祥市| 长子县| 阿鲁科尔沁旗| 永泰县| 永仁县| 石嘴山市| 肇庆市| 余江县| 青海省| 蒲城县| 宝丰县| 肥东县| 开封市| 马关县| 福建省| 天台县| 金华市| 三门县| 义乌市| 莲花县| 阜城县| 高密市| 诸城市| 大宁县| 和顺县| 泗阳县| 尤溪县| 怀仁县| 隆昌县| 涪陵区| 青阳县| 措美县| 房产| 长子县| 耿马| 大余县| 南陵县| 梁山县| 清河县| 崇州市|