VOIP RTP分析和AC490除錯記錄

最近在研究voip ，**閘道器底層使用ac490 進行語音頻號ip 化( 驅動不由我寫) ，碰見一些，總結如下。

ac490 是audiocodes 公司的voip 處理器，可以執行8/12 通道lbrc ，包括g.723/g.729/ilbc/amr/gsm fr 。支援24 通道的g.711 算法或12 通道的g.711/g.723 演算法的語音編碼；g.168-2002 回波消除；t.38 傳真；支援rtp/rtcp 的打包/ 解包。

詳細定義請見rfc3550
(對rtp
格式的描述) 
和 rfc3551
(對rtp
攜帶的**資訊格式的描述).

前12 個位元組在每乙個rtp packet 中都存在，而一系列的csrc 標記只有存在mixer 時才有。

version (v): 2 bits

標明rtp 版本號。協議初始版本為0 ，rfc3550 中規定的版本號為2 。

padding (p): 1 bit

如果該位被設定，則在該packet 末尾包含了額外的附加資訊，附加資訊的最後乙個位元組表示額外附加資訊的長度（包含該位元組本身）。該欄位之所以存在是因為一些加密機制需要固定長度的資料塊，或者為了在乙個底層協議資料單元中傳輸多個rtp packets 。

extension (x): 1 bit

如果該位被設定，則在固定的頭部後存在乙個擴充套件頭部，格式定義在rfc3550 5.3.1 節。

csrc count (cc): 4 bits

在固定頭部後存在多少個csrc 標記。

marker (m): 1 bit

該位的功能依賴於profile 的定義。profile 可以改變該位的長度，但是要保持marker 和payload type 總長度不變（一共是8 bit ）。

payload type (pt): 7 bits

標記著rtp packet 所攜帶資訊的型別，標準型別列出在rfc3551 中。如果接收方不能識別該型別，必須忽略該packet 。

sequence number: 16 bits

序列號，每個rtp packet 傳送後該序列號加1 ，接收方可以根據該序列號重新排列資料報順序。

timestamp: 32 bits

時間戳。反映rtp packet 所攜帶資訊包中第乙個位元組的取樣時間。

ssrc: 32 bits

標識資料來源。在乙個rtp session 其間每個資料流都應該有乙個不同的ssrc 。

csrc list: 0 to 15 items, 32 bits each

標識貢獻的資料來源。只有存在mixer 的時候才有效。如乙個將多聲道的語音流合併成乙個單聲道的語音流，在這裡就列出原來每個聲道的ssrc 。

payload ：此部分的格式規定見rfc3551, 隨攜帶的**流格式不同而不同。

按照rfc3551 中4.5.6 規定，乙個攜帶g729 格式的rtp 包的payload 可以由0 或多個g.729 或 g.729 annex a 幀組成，後面再有0 或多個g.729 annex b 幀組成。

g.729 或 g.729 annex a 每幀長10 byte ，相互間完全相容，主要攜帶語音資訊。g.729 annex b 幀每幀長4 byte ，主要攜帶vad(voice activity detector, 語音行為檢測) 和cng(comfort noise generator, 舒適噪音生成) 。

不過根據對sip **和軟sip **的g729 的rtp 包抓包分析，其payload 一般是由4 個g.729 或 g.729 annex a 組成。因為vad 不是所有設備都支援，例如asterisk 不支援。

按照rfc3551 中4.5.14 規定，乙個攜帶g711 格式的rtp 包格式較簡單，在g711 中每個聲音取樣被編碼為8 bit 。56 kb/s 和48 kb/s 在rtp 中是不被支援的。

本身希望用ac490 直接傳送rtp 包，但是控制其直接傳送的rtp 包卻無法被sip **，asterisk 和wireshark 正確分析。

3.1 g

.729

的問題

rtp

頭部多了4

個bit

，一般來時g729

的rtp

包頭2個bite

是80 12

，或者80 92(mark

被置為1

，一般是在第乙個rtp

包中)，而

ac490

傳送g729

的rtp

包中80 12

前面多個4bit

，修改ac490

的驅動使其去掉頭4

個bit

，可以被wireshark

分析為g729

的rtp

包，

但仍然無法與sip

**互通，繼續分析發現sip

**的g729

的rtp

包payload

長度為20 bit

，而ac490

的為12bit

，且在通過

asterisk

的時候，asterisk

報告檢測有vad

幀，檢視asterisk

原始碼發現asterisk

的frame.c

不支援vad

。

綜上和前面對g729

格式的描述，猜測ac490

的預設g729

的rtp

包由2個g.729

或 g.729 annex a

幀和乙個g.729 annex b

幀組成。而sip

**和軟sip

**的g729

的rtp

包一般由4

個g.729

或 g.729 annex a

幀組成。

修改驅動，改變ac490

的g729

的rtp

包為4個g.729

幀，與sip

**和軟sip

**互通成功。

3.2 g

.711a

的問題

在前面的除錯過程，由於修改ac490

的g729

的rtp

包格式的方式需要些時間，嘗試修改ac490

的rtp

格式為g.711a

，也就是pcma

，

因為其格式較為簡單。但開始時仍然無法與sip

**互通，表現為sip

**可以聽到聲音但有很大的雜音，ac490

這面的普通**靜音。分析

為還是兩端包格式不符，ac490

丟棄了所有發過來的包。

繼續抓包，sip

**的g.711a

的rtp

包payload

長度為160bit

，而ac490g.711a

的rtp

包payload

長度為162bit

，多次試驗分析後，發

現主要在ac490rtp

包payload

最後兩個bit

上，在一次通話中，這兩個bit

要麼是00 00

，要麼是固定的兩個bit

，所有包後面都是這兩種型別。

而不同通話中，00 00

外的另一種方式的兩個bit

不同。而00 00

或兩個固定bit

出現方式暫時為發現規律，在靜音包和語音包尾部兩種都會

出現。

建議修改ac490

驅動為在傳送時去掉尾部兩個bit

，接受時補上兩個bit 00 00

。

再次試驗互通成功。

較為仔細的學習了rtp

有關rfc

，主要是rfc3550, rfc3551,

還有rfc 2198

和rfc2833

。

基本掌握了sip

**和軟sip

**的rtp

包結構，了解了常見的rtp

包格式(

即rfc

中建議的多種方式那種最常用)

。

對asterisk

的sip.conf

配置進一步熟悉，尤其是canreinvite

這一段，怎樣使其表現的近似於stateless

的sip

伺服器。

對用wireshark

抓包進一步掌握。

VOIP RTP分析和AC490除錯記錄

VOIP RTP分析和AC490除錯記錄

DC係數和AC係數

AC和AP的區別

VOIP RTP分析和AC490除錯記錄

VOIP RTP分析和AC490除錯記錄

DC係數和AC係數

AC和AP的區別

相關推薦