再談Lync的MoH

在好久之前，我寫過一篇關於等待音樂的文章。經過這麼設置以後，用戶能夠能夠在通話過程當中按Hold鍵，這樣對方就能夠聽到等待音樂。並且咱們都知道這個音樂是從客戶端發送到服務器上，而後再傳給對方的。這樣的client-side MoH在實際的操做中存在這麼兩個小問題：

第一：在客戶端點擊了Hold以後，配置不是很高的電腦上可能會出現一段時間的假死，大概在4秒只以後，對方纔會聽到音樂。估計這段時間內應該是本地啓動什麼播放模塊，而後再發送這個音樂的流媒體到服務器。

第二：若是用戶是經過Edge登陸撥打電話的話，在網絡狀況不是很好的狀況下，對端所聽到的音樂音質降低得厲害

 

今天咱們來看看Server-side的MoH是如何實現的。目前Lync尚未本身的Server Side的功能，只能藉助於外部設備。如今藉助於NET的UX 1000，咱們看看MoH整個過程是如何來實現的。在這裏的呼叫流程是Lync把全部的呼叫發送給UX 1000，而後UX 1000再把呼叫發送給PSTN，最終達到用戶端。

 

咱們先看看UX 1000上如何設置MoH

首先檢查UX 1000上是否加載了音樂文件，經過下圖咱們看到如今系統裏面並無文件。

而後咱們到媒體配置，選擇上載一個音樂文件

選擇一個以前弄好的WAV文件，這個文件大小仍是有要求的（UX 1000最大爲1M，UX2000爲4M），在格式方面須要文件的採樣率爲8KHz的單聲道WAV文件。

而後再回到DSP信息處檢查，這個時候就顯示loaded了。

下面就是爲針對Lync的SIP 中繼打開MoH功能，咱們看到在這裏能夠打開，也能夠關閉。咱們足額則Always Enabled就行了。

 

一切都OK了，使用Lync用戶撥打一個3001測試看看。接通以後，而後點擊下圖所示的圖標，這個時候對方立馬就能夠聽到音樂的。

 

而Lync客戶端也會以下同樣顯示，若是要恢復呼叫，只要點擊Resume Call就OK。

 

到這裏MoH就已經實現了，並且咱們發現，如今一點擊hold，對方立刻就聽到音樂，沒有任何的延遲，並且客戶端也不會有任何的假死。同時這個音質就很是好，和用戶所在的網絡沒有任何關係。

可是咱們固然不知足這點了，咱們想看看在用戶點擊了Hold以後，到底Lync發送了什麼消息給網關。

 什麼？Lync竟然發送了一個INVITE給網關？確實是這樣一個包，不過咱們注意到在SDP裏面有這麼一句話a=inactive，這句就是告訴網關，如今Lync客戶端要進入inactive狀態了，請不要發送任何的RTP過來，Lync客戶端也不會發送任何的RTP給網關。在網關收到這個INVITE以後，它就開始給對方播放音樂了

INVITE sip:192.168.1.223:5060;transport=TCP SIP/2.0 FROM: <sip:+216@lync2010.ucdemo.net;user=phone>;epid=225A1702DD;tag=901872914a TO: <sip:3001@192.168.1.223;user=phone>;tag=c0a801df-32 CSEQ: 177 INVITE CALL-ID: 7b914bb2-4361-4b83-a33c-20bfb3f03eb2 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.1.82:49880;branch=z9hG4bK543e4d6f CONTACT: <sip:Lync2010.ucdemo.net:5068;transport=Tcp;maddr=192.168.1.82;ms-opaque=49ed7dd110f0a17a> CONTENT-LENGTH: 278 SUPPORTED: 100rel USER-AGENT: RTCC/4.0.0.0 MediationServer CONTENT-TYPE: application/sdp v=0 o=- 14 2 IN IP4 192.168.1.82 s=session c=IN IP4 192.168.1.82 b=CT:1000 t=0 0 m=audio 50932 RTP/AVP 101 13 0 c=IN IP4 192.168.1.82 a=rtcp:50933 a=label:Audio a=inactive a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=rtpmap:0 PCMU/8000

 

若是用戶點擊了Resume以後，咱們則會看到以下的數據包，其中的SDP變成了a=sendrecv，這個代表如今客戶端是出於活動狀態，又能夠接受，又能夠發送，網關在收到這個信息以後，就中止播放音樂，從新把兩個端點的語音通道創建起來。

INVITE sip:192.168.1.223:5060;transport=TCP SIP/2.0 FROM: <sip:+216@lync2010.ucdemo.net;user=phone>;epid=225A1702DD;tag=901872914a TO: <sip:3001@192.168.1.223;user=phone>;tag=c0a801df-32 CSEQ: 178 INVITE CALL-ID: 7b914bb2-4361-4b83-a33c-20bfb3f03eb2 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 192.168.1.82:49880;branch=z9hG4bKb33556 CONTACT: <sip:Lync2010.ucdemo.net:5068;transport=Tcp;maddr=192.168.1.82;ms-opaque=49ed7dd110f0a17a> CONTENT-LENGTH: 278 SUPPORTED: 100rel USER-AGENT: RTCC/4.0.0.0 MediationServer CONTENT-TYPE: application/sdp v=0 o=- 14 3 IN IP4 192.168.1.82 s=session c=IN IP4 192.168.1.82 b=CT:1000 t=0 0 m=audio 50932 RTP/AVP 101 13 0 c=IN IP4 192.168.1.82 a=rtcp:50933 a=label:Audio a=sendrecv a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=rtpmap:0 PCMU/8000

 

若是咱們採用的是Lync本身的Client-side MoH，經過抓包，咱們會發現Lync送過來的INVITE的裏面的SDP爲a=sendonly，這個則是代表，如今的Lync客戶端是隻發不收的，它只會把MoH的音樂傳出來，而不會接受網關發過的媒體消息。

另外須要注意一點的是，若是Server side的MoH和客戶端的MoH都設置的話，服務器端的設置會把客戶端的設置覆蓋。因此建議若是你啓用了Server side的MoH，

能夠以下的命令取消客戶端的MoH。