MRCP協議學習筆記-關於媒體資源伺服器的定位路由策略
前面我們討論了分散式的媒體源處理方式和直接指定了媒體資源伺服器。但是，如果媒體資源伺服器是通過分散式部署，同時為了拓展性的需要，可能不同的媒體資源伺服器支持了不同的功能。MRCP 客戶端需要查詢媒體資源伺服器來進行進一步的處理。為了對多個媒體資源伺服器進行路由調度處理，我們將簡要介紹關於媒體資源伺服器的能力支持查詢和媒體資源代理（MRB）的使用方式，其路由方式的存在的問題進行討論，還有如何使用SIP拓展來實現媒體能力查詢。
1
MRCP 客戶端可以通過一個OPTION 請求來對媒體資源伺服器進行能力查詢，然後通過路由方式對媒體資源伺服器進行進一步的控制管理。現在讓我們看一下如何實現MRCP 客戶端發送OPTION請求進行媒體資源伺服器查詢處理。
這是一個從MRCP客戶端發送到OPTION請求消息內容：
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKab3
Max-Forwards: 70
Accept: application/sdp
Content-Length: 0
媒體資源伺服器的回復的響應消息中，我們可以看到媒體資源伺服器端的各種支持能力：
SIP/2.0 200 OK
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKab3
Max-Forwards: 70
Allow: INVITE, BYE, OPTIONS, ACK, CANCEL
Content-Type: application/sdp
Content-Length: 288
v=0
o=Server 289123140 289123140 IN IP4 host99.example.com
s=-
t=0 0
m=application 0 TCP/MRCPv2
a=resource:speechsynth
a=resource:speechrecog
a=resource:recorder
m=audio 0 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
在響應消息中，媒體資源伺服器支持的三種媒體資源，它們是語音識別，語音合成和錄音。媒體資源伺服器可以支持PCMU 和PCMA的格式，同時，它也支持RFC 2833, a=fmtp的 payload是96，支持16個 DTMF事件。通過回復消息，我們獲悉了媒體資源伺服器端所支持的功能。
2
在實際生產環境中，我們不可能總是使用一種媒體資源來實現對多種MRCP客戶端的支持。為了實現媒體資源伺服器的拓展和逃生處理方式，我們需要媒體資源伺服器能夠實現靈活方便的媒體資源支持，同時也能夠應對不同的媒體資源能力的需要。其解決辦法就是在MRCP客戶端和媒體資源池之間提供一個路由的功能或者媒體資源代理，我們稱之為-Media Resource Broker（MBR）在實際生產部署環境中，用戶可以通過以下兩種方式來實現對媒體資源伺服器的路由管理。現在我們簡要介紹一下兩種媒體資源伺服器的部署方式。
3
首先，我們介紹一下所謂的內聯方式來處理媒體資源伺服器的路由管理。此方式是基於SIP代理的工作方式。在這種內聯工作模式下，MBR通過定位伺服器資料庫查詢INVITE請求中的REQUEST-URL，獲得相應的媒體資源伺服器的AOR記錄信息，然後返回到SIP代理伺服器，它會通過不同的路由策略來對媒體資源伺服器進行路由處理。SIP代理對有效的媒體資源伺服器進行不同的調度路由，它支持的路由查詢方式可能是輪詢方式或其他的任意路由方式等。如果出現媒體資源調度失敗的響應消息，它可以通過二次路由使用其它媒體資源來實現逃生功能。
4
另外一種MRB的路由調度方式就是使用轉發伺服器來進行路由處理。
在此示例中，MRB可以通過重定位伺服器來進行一個基本的查詢服務。重定位伺服器通過回復一個302 Moved Temporarily 響應，通過響應消息中的Contact頭來表示媒體資源伺服器。此方案仍然通過輪詢的方式來進行路由調度處理。
5
在上面章節中的示例中，我們都是假設媒體資源伺服器池中註冊的都有同樣的AOR和同樣的支持能力。但是，在實際生產環境中，可能一台媒體資源伺服器同時支持了語音識別和語音合成，但是另外一台資源伺服器可能僅支持語音識別。為了支持這種比較複雜的部署環境，我們通常會要求MRCP客戶端請求時攜帶推薦的支持能力，這樣的話，MRB會根據客戶端的推薦能力來選擇路由策略，最終可以實現複雜環境中智能化的媒體資源路由管理。
為了保證準確獲悉媒體資源伺服器的支持能力。同樣的原理，MRB也要需要一個控制機制來獲悉媒體資源伺服器的支持能力，當註冊到定位伺服器時，媒體資源伺服器首先需要對MRB聲明自己的媒體資源伺服器所支持的媒體類型。MRB可以通過一個OPTION 請求來查詢定位伺服器資料庫中的不同的媒體資源伺服器URL來獲得媒體資源伺服器的支持能力。
如果MRCP客戶端發起一個請求時，來自MRCP INVITE中會在SDP中攜帶所需要的媒體資源伺服器的支持能力，MRB會對照檢查MRCP客戶端的SDP消息體，它然後會和媒體資源伺服器端所提供的支持能力進行對比，然後給出路由策略。但是這樣的方式可能會存在一定的局限性，如果SDP是支持的加密的S/MIME時，SDP消息體的訪問會被拒絕，所以在使用時需要讀者了解具體的適用場景。
另外一種解決方案就是使用SIP協議的拓展來支持對媒體資源伺服器的路由處理。RFC3841協議提供了一種機制可以讓SIP用戶代理或MRCP客戶端來標識自己的推薦能力。伺服器端可以對其INVITE消息回復一個結果。RFC3840協議也可以支持伺服器端來標識自己的功能支持。客戶端在註冊時，伺服器端會添加一些額外的標籤來表示支持能力。此處理方法就是在註冊時，對Contact URL添加 URL參數（功能標籤）來表示所提供的支持能力。MRCP客戶端則可以在INVITE中通過Accept-Contact 頭域設定一個所需功能。
這裡，MRB實際上執行了一個媒體資源協商的過程。MRB接下來會URL來查詢定位伺服器來選擇一個合適的媒體資源伺服器。通過匹配MRCP客戶端發送的功能請求標籤，對比媒體資源伺服器所提供的功能支持，最後給MRCP客戶端返回最終的推薦支持功能，並且對MRCP客戶端返回協商後的建議的功能標籤。
6
在本章節中，筆者重點討論了如何實現媒體資源伺服器的定位查詢，同時介紹了媒體資源伺服器的支持能力的問題。我們也討論了關於MRB 媒體資源伺服器代理和其部署方式，包括分散式部署的媒體資源伺服器的兩種類型。在討論了兩種類型後，我們添加了對通過SIP拓展方式實現媒體資源路由的支持的討論，並且具體解釋了媒體支持能力，功能標籤的處理和其協商過程。
參考資料：
https://tools.ietf.org/html/rfc3841
http://www.ietf.org/rfc/rfc3840.txt
TAG:Asterisk開源派 |