在很久以前，我寫過一篇關於等待音樂的文章。通過這麼設置之後，用戶可以可以在通話過程中按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 v=0 |
如果用戶點擊了Resume之後，我們則會看到如下的數據包，其中的SDP變成了a=sendrecv，這個表明現在客戶端是出於活動狀態，又可以接受，又可以發送，網關在收到這個信息之後，就停止播放音樂，重新把兩個端點的語音通道建立起來。
|
INVITE sip:192.168.1.223:5060;transport=TCP SIP/2.0 v=0 |
如果我們採用的是Lync自己的Client-side MoH，通過抓包，我們會發現Lync送過來的INVITE的裏面的SDP爲a=sendonly，這個則是表明，現在的Lync客戶端是隻發不收的，它只會把MoH的音樂傳出來，而不會接受網關發過的媒體消息。
另外需要注意一點的是，如果Server side的MoH和客戶端的MoH都設置的話，服務器端的設置會把客戶端的設置覆蓋。所以建議如果你啓用了Server side的MoH，
可以如下的命令取消客戶端的MoH。
