中介和邊緣的故事

最近有兩個朋友在部署Lync的企業語音的時候都遇到了相似的問題,表象是經過Edge登陸上來以後,客戶端打電話都會出現接不通的問題。咱們今天就來分析一下如何來搞定這種問題。前端

故事仍是從OCS時×××始吧 服務器

 

 

p_w_picpath

 上面這幅圖OCS的語音整合圖來自於Technet,你們應該都很熟悉。說實話之前我非常不理解我用綠色框圈住地方,在通過一些部署和抓包分析後來我才知道,原來它就表示在通過了SIP信令協商協商以後,客戶端就直接把媒體流直接發送給中介服務器。媒體流也就繞過了前端服務器。因此在OCS的時代,若是須要在分支部署網關的話,咱們也須要在分支部署一臺中介服務器,爲何?假如分支的用戶打個電話,他們的媒體流都要跑到總部的前端上轉一圈而後再送給分支的網關,企業的那點WAN怎麼會耐得住。因此若是分支的用戶數量在必定規模之上的話,在分支部署一臺中介服務器也就是必須的了。這個也屬於一種Bypass功能,而如今在Lync裏面,微軟作得更好了,還能夠bypass中介服務器,咱們能夠在分支只部署網關就能夠,在通過媒體協商以後,客戶端能夠直接把音頻流直接發送給網關。真是很給力,不過呢須要使用認證過的網關才行。ide

 這樣的模式有沒有問題呢?測試

仍是有的,那就是當用戶從Edge上登陸過來的時候。用戶登陸Edge以後,它所發出的信息會先到Edge服務器上,而後Edge服務器再發給中介服務器。通常企業也就在總部部署Edge服務器,那就意味着用戶的媒體流確定要從總部的Edge發到中介服務器,而後中介服務器在發送給網關,這就意味着沒有辦法作Bypass了。同時也說明邊緣服務器和中介服務器仍是有着某種關係的,若是沒有處理好這種關係,可能呼叫就會出問題。
 server

說道這裏,咱們先來看看上面提到的朋友遇到問題是什麼樣子的?blog

客戶端經過Edge登陸以後,若是發起PSTN呼叫的話,首先顯示Calling,而後變爲Connecting call,最後就顯示Call failed due to network issues。這說明呼叫創建的信令都是正常的,可是問題發生在系統嘗試創建媒體流的時候。部署

 如何來解決呢?get

在前端輸入以下命令看看中介服務器的配置it

Get-CsService –MediationServerio

 p_w_picpath

咱們看到EdgeServer那裏是空着,咱們使用以下的命令把Edge服務器的值補上

Set-CsMediationServer -Identity "MediationServer:Lync_pool_name" -EdgeServer Your_edge_server_internal_address

輸入完畢,再打一個電話測試一下,就一切正常了。

緣由呢,若是咱們在邊緣或者中介上抓包,可能就會看到這樣的Ms-client-diagnostics: 52031; reason="Call terminated on media connectivity failure" 的錯誤提示。在仔細研究研究你會發現原來中介服務器要去嘗試鏈接一個外部地址,它不知道咱們有邊緣服務器?確實不知道,由於edgeserver那裏是空的麼。咱們後來在中介服務器上配置那個參數就是告訴它,咱們有Edge服務器的。

 這也說明在部署企業語音的時候,處理好中介和Edge的關係仍是比較重要的。如過你在部署中遇到了一樣的問題,不妨試試這個方法。

相關文章
相關標籤/搜索