欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

您當(dāng)前的位置是：  首頁 > 新聞 > 國(guó)內(nèi) >
 首頁 > 新聞 > 國(guó)內(nèi) >

MRCP學(xué)習(xí)筆記-通過SIP協(xié)議實(shí)現(xiàn)會(huì)話管理

2018-05-21 09:37:41   作者：   來源：CTI論壇   評(píng)論：0 　點(diǎn)擊：

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

　　unimrcp-MRCP協(xié)議學(xué)習(xí)分享，QQ群號(hào)：208136295
　　關(guān)注微信公眾號(hào)：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
【免責(zé)聲明】本文僅代表作者本人觀點(diǎn)，與CTI論壇無關(guān)。CTI論壇對(duì)文中陳述、觀點(diǎn)判斷保持中立，不對(duì)所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請(qǐng)讀者僅作參考，并請(qǐng)自行承擔(dān)全部責(zé)任。

專題