歡迎大家轉載，為保留作者成果，轉載請注明出處，http://blog.csdn.net/netluoriver，有些文件在資源中也可以下載！如果你沒有積分，可以聯系我！

SIP voip 測試交流群： 323827101

1名詞解釋

VAD靜音抑制，又稱語音活動偵測。靜音抑制的目的是從聲音信號流里識別和消除長時間的靜音期，以達到在不降低業務質量的情況下節省話路資源的作用，它是IP電話應用的重要組成部分。靜音抑制可以節省寶貴的帶寬資源，可以有利于減少用戶感覺到的端到端的時延。

?

根據上面的定義我們可以理解為，當進行語音通訊時，如果終端開啟了靜音檢測功能，當用戶在一段時間內沒有講話時，終端不會向外發送語音包或發送少量的包，節約帶寬！

?

2場景定義

在測試之前我們先定義下測試場景

?

服務器是公網服務器，IP地址是218.249.39.212，其中終端1007使用的是聯通上網卡，15623722867使用的是公司內部WIFI。

終端1007用的語音呼叫終端15623722867之前，我們用tcpcump在服務器端先進行抓包，然后再進行抓包。語音呼叫完畢后，停止抓包，然后從服務器中下載抓取的包，在windows中用wireshark或Hammer工具進行分析。

?

?

我們分別用不開啟靜音檢測功能與開啟靜音檢測功能的兩個包為例來分析！兩個包PTIME都為100，速率為4.75kbit/s，

jingyin_100_4.75.pcap開啟了靜音檢測功能進抓的包；

null_jingyin.pcap沒有開啟靜音檢測功能時抓的包；

3過濾SIP呼叫與RTP媒體流

我們用wireshark打開開啟靜音檢測后抓的包jingyin100_4.75.pcap為例來分析。

怎樣在服務器中眾多的SIP包中過濾出我們指定的SIP呼叫流與語音包呢？

3.1過濾SIP呼叫流程

根據SIP協議在呼叫過程中CALL-ID的唯一性，我們先把客戶端主叫方1007 INVITE請求中的CALL-ID記錄下來，通過在服務器方法如下

過濾的內容為“sip.Call-ID == "421943381468"”顯示如下：

從Filter中再過濾SIP包，查找服務器給15623722867發送的INVITE請求。所以Source地址一定是服務器218.249.39.212，且請求行為INVITE的包。找到后用上面同樣的方法把CALL-ID拷貝出來至記事本中，這次過濾服務器到15623722867的內容為“sip.Call-ID == "Anta1397122876180baaa61fd4c77752c15112@d427f9da"” 如下圖：

我們獲得的這兩個CALL-ID其實就是此次呼叫的SIP流程。

我們在wireshark容器中輸入這兩個CALL-ID，過濾內容如下：

sip.Call-ID == "421943381468" || sip.Call-ID == "Anta1397122876180baaa61fd4c77752c15112@d427f9da"

在wireshark中顯示如下：

我們通過以下方法可以看一下它的呼叫流程圖：

下圖為上面直觀的SIP呼叫流程圖：

到目前為止，我們已經過濾出SIP呼叫的流程來了，下面我們需要過濾出呼叫的語音流。

3.2過濾RTP語音流

首先我們先來了解下本次過濾信息SDP協議中的一些知識：

（SDP具體內容請參考：

http://wenku.baidu.com/view/92e3e71714791711cc7917f7.html）

通過上圖信息及SIP消息流程，我們首先過濾下1007至服務器端的SIP呼叫，在wireshark容器中過濾CALL-ID,內容為：“sip.Call-ID == "421943381468"”，如圖所示：

因1007是主叫，服務器中返回的200 OK的SDP中攜帶了服務器接收的媒體端口號，上圖中端口12650即為服務器1007將語音媒體流發送給服務器的端口號，我們將此端口號記錄在記事本中；

同樣的，我們 過濾服務器至15623722867的SIP程，內容為sip.Call-ID == "Anta1397122876180baaa61fd4c77752c15112@d427f9da"，這一次我們過濾的不是15623722867返回的200 OK，而是服務器發起的INVITE請求SDP中攜帶接收的媒體端口號，此次服務器在端口39510接收15623722867發來的語音媒體流，如下圖所示：

至此，我們可以過濾出此次呼叫的SIP呼叫流程及RTP流。

在wireshark過濾信息內容為：

sip.Call-ID == "421943381468" || sip.Call-ID == "Anta1397122876180baaa61fd4c77752c15112@d427f9da" ||udp.dstport == 39510 ||udp.dstport ==12650

?

?

其實上面的內容只是顯示整個呼叫過程中的SIP呼叫流程及RTP流。

3.3靜音檢測分析步驟

由于兩端都開啟了靜音檢測功能，我們只需要分析一端的RTP流就可以了。

我們過濾15623722867至服務器端的媒體流為例。

在wireshark中過濾udp.dstport == 39510

然后我們進行分析，操作如下：

?

其中Delta(ms)代表此包與前一包的時間間隔，通過上圖可以看出，靜音檢測功能生效了。最大間隔為718ms。我們設置的PTIME間隔為100ms，比實際延遲了618ms.

用同樣的方法測試沒有開啟靜音檢測功能的終端，Delta最大值為123.18ms。比實際延遲了23.18ms.如下圖。

4總結

通過以上進行分析，我們設置的PTIME為100ms,當啟用了靜音檢測功能后，發送間隔最大會有618ms，這樣在同樣的單位時間內發送的包就會少一些，不啟用靜音檢測功能時，最大延時只有23.18ms，通過對比發現靜音檢測功能生效了！

總結

以上是生活随笔為你收集整理的如何测试静音检测的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。