live555传输Speex音频详解二：Speex 使用SDP及其它事项

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

许多Speex特殊参数可以在一个a=fmtp行中提供，它们被分号分隔:

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的协议，在某些环境下，一个接收者可能很简单地由于接收了太多的包而超出负载,不论是不是故意设计的．网络层的验证可以用于丢弃从不想要的源发来的包，但是验证计算本身可能耗费很多的计算．

原文链接： http://blog.csdn.net/nkmnkm/article/details/7209470