live555傳輸Speex音訊詳解二：Speex 使用SDP及其它事項
阿新 • • 發佈：2019-02-11
1. Speex使用SDP
當使用SDP來描述使用Speex格式的會話時，對映是下面這樣的：
o 媒體型別 ("audio") 在"m="行中指定媒體的名字。
o 媒體子型別 ("speex") 在SDP "a=rtpmap"行中指定編碼名字。所需的"rate"引數
也在"a=rtpmap" 行中，表明時鐘頻率。
o 引數 "ptime" 和 "maxptime" 分別在SDP 的"a=ptime"行和"a=maxptime"中指明。
o 其它引數都在SDP的"a=fmtp"行中以parameter=value的形式指明。它們的名字與媒
體內部的命名一致，並且以分號分分開不同的鍵值對們。
下面的表包含了mode與位元速率之間的對應，窄帶，寬頻和超寬頻各不相同。並且也包含了對應的"Speex quality"的值(見Speex編碼手冊中的SPEEX_SET_QUALITY的解釋)。
表 1: 窄帶下的 Mode vs. Bit-Rate
Table 2: 寬頻和超寬頻下的Mode vs. Bit-Rate
a=fmtp:97 mode="1,any";vbr=on
1.1. 舉例：支援所有模式，模式4優先
m=audio 8088 RTP/AVP 97
a=rtpmap:97 speex/8000
a=fmtp:97 mode="4,any"
1.2. 舉例：只支援Modes 3 和 5
m=audio 8088 RTP/AVP 97
a=rtmap:97 speex/8000
a=fmtp:97 mode="3,5"
1.3. 舉例：支援可變位元速率和舒適噪音
m=audio 8088 RTP/AVP 97
a=rtmap:97 speex/8000
a=fmtp:97 vbr=on;cng=on
1.4. 舉例：支援聲音動態檢測
使用vbr=vad parameter:
m=audio 8088 RTP/AVP 97
a=rtmap:97 speex/8000
a=fmtp:97 vbr=vad
1.5. 舉例：支援多采樣率
表明一個Speex流支援16000Hz, mode 10 (42.2 kbit/s)；或8000Hz，mode 7 (24.6 kbit/s)。
m=audio 8088 RTP/AVP 97 98
a=rtmap:97 speex/16000
a=fmtp:97 mode="10,any"
a=rtmap:98 speex/8000
a=fmtp:98 mode="7,any"
1.6. 舉例：支援Ptime和多Speex幀
SDP的"ptime"屬性表示分包間隔(也就是，一個RTP包中編碼了多少毫秒的音訊資料)。因為Speex使用20毫秒一幀，ptime的值除以20就表明了一個包中有多少幀。建義使用的ptime的值可以被20整除。如果ptime的值不能被20整除，那麼需要先從它計算出最接近的能整除20的數，然後再計算幀數．例如，如果"ptime"為30，那麼修正後的值就是40，然後用修正後的值來計算出幀數：為2．
下例中表明一個包中有兩個幀:
m=audio 8088 RTP/AVP 97
a=rtpmap:97 speex/8000
a=ptime:40
1.7. 舉例：一個完整的發起者／迴應者互動
發起者表明它提供Speex 音訊，取樣率為16000Hz 或8000 Hz,並且發起者支援所有的模式，因為mode引數並沒有指定．
m=audio 8088 RTP/AVP 97 98
a=rtmap:97 speex/16000
a=rtmap:98 speex/8000
迴應者表明了它希望接收8000Hz的音訊，這是它唯一支援的取樣率．迴應者支援所有的模式，因為沒有指定mode引數.
m=audio 8088 RTP/AVP 99
a=rtmap:99 speex/8000
2. 實現方針
支援Speex的實現者負責正確的解碼Speex幀．
每個Speex幀包含所有解碼需要的資訊．尤其，SDP中的'mode' 和 'ptime'的值必不能在解碼時使用：因為要解碼一個RTP Speex流並不需要這些值．
3. 安全相關
本負載的安全問題符合[RFC3550]中的定義以及．這表明私密媒體流需被加密．因為本負載格式的資料壓縮/解壓是端對端的，加密是可以在壓縮後進行的，所以兩種操作不會有衝突．但是一個潛在的可能造成拒絕服務的危險是所採用的編碼技術具有不一至的接收端計算負載．攻擊者可以向流中注入有毒的資料報使解碼變得複雜而引起接收端超負載．然而，本編碼格式沒有表現出任何明顯的不一致問題．像其它任何的基於IP的協議，在某些環境下，一個接收者可能很簡單地由於接收了太多的包而超出負載,不論是不是故意設計的．網路層的驗證可以用於丟棄從不想要的源發來的包，但是驗證計算本身可能耗費很多的計算．