Microsoft Windows 实时通信(RTC)客户端的媒体支持
原著：Tom Fout
翻译：孟谨
原文出处：Media Support in the Microsoft Windows Real-Time Communications Client
Microsoft Windows 的实时通信（RTC）客户端由一系列核心组件构成，它提供了丰富的通信特性。这些特性通过 Windows Messager
和其它一些使用了此应用程序编程接口（APIs）的应用程序展示给用户。本文将概述与媒体相关的特性以及这些组件提供的增强特性。应用程序开发者或许想要将 RTC 特性
集成到自己的程序中以改进用户体验。开发者还能利用 RTC 的特性构建自己的社区。
Microsoft Windows XP 中结合与增强了丰富的通信特性，为 RTC 体验提供了基础。Microsoft Windows Messager
利用这些特性为用户到用户间的通信提供了实时语音和视频、即时消息和其它的协作功能。另外，其所提供的应用程序编程接口（APIs）使得这些丰富的通信特性可用于任何应用程序。
本文详细讨论了添加到 RTC 的媒体改进特性，这些改进使得最终用户和开发者都能有更愉快的体验。当应用程序被构建在 RTC 客户端 API 之上，最终用户能获得丰富的音视频体验，而开发者可以使程序得到一系列免费的改进。使用这些 API
构建的应用程序还能够访问 RTC 提供的即时消息和出席功能。有关这些API的信息，可在
本文讨论了以下的特性和改进之处：
Windows RTC 客户端支持下表列出的音频编解码器（codec），同时列出了相关的采样率和比特率。选择哪一种编解码器取决于通信双方的能力和带宽。例如，如果其中一方使用56KBps的拨号连接，那么G.711将被禁用，因为它超出了
可获得的带宽限制。又比如，假设其中一方支持SIREN，而另一方不支持，那么首选的编解码器
SIREN 将被禁用。如果双方均支持SIREN并且带宽足够，那么在所有的编解码器中SIREN即为首选。
Codec
采样率
比特率
RTP包长度
G.711
Kilohertz (kHz)
64 kilobits per second (Kbps)
20 milliseconds (msec)
G.722.1
16 Khz
24 Kbps
20 msec
G.723
8 Khz
6.4 Kbps
30 msec, 60 msec or 90 msec
GSM
8 Khz
13 Kbps
20 msec
DVI4
8 Khz
32 Kbps
20 msec
SIREN
16 Khz
16 Kbps
20 msec or 40 msec
H.263是视频所支持的编解码器，其比特率在6KBps到125KBps之间不等。出于兼容性的考虑，H.261也是被支持的编解码器。该版本只支持 OCIF（176×144）。不支持第三方
编解码器的插件。
回波抵消（AEC）
AEC的工作原理是通过对讲话者的输出建模，并且将其从麦克风捕捉的信号里除去。AEC有助于确保对端听不到回声。
为了启用 AEC，在 Windows Messager 中运行“音频和视频调节”向导（Audio and Video
Tuning：进入菜单：Tools/Audio Tuning Wizard...）。在音频调节部分，去掉“I am using
headphones”复选框前面的“√”。
图一：音视频调节向导对话框
使用 IRTCClient 接口 PreferredAEC 方法可以通过编程实现对 AEC 的启用和禁用。有关 RTC 客户端 API
和接口的更多信息请参考Platform SDK 文档。
RTC 客户端使用的 AEC 模块是 Microsoft DirectSound 底层结构的一部分。该组件包括下列特性和限制：
AEC只在不超过 25×15×9 英尺的小房间才会有效；
AEC只对单声道有效，当输出是多个通道的立体声的时候，只有一个通道能够具有回波抵消的效果；
AEC不能抵消来自其它声音源的声音，比如背景中收音机放出来的歌曲；
注：以下两条限制只应用于 Windows XP 的 RTM RTC 客户端。可从Windows Update
下载一个包来去掉这两条限制。
AEC要求音频捕捉和再现设备使用同一个时钟，这意味着，AEC 对 USB 音频设备无效。如果 RTC 的客户端检测到了这样的情况，音频调节向导
中的那个复选框会被禁用，以阻止用户启用 AEC。
AEC仅对采样率为8KHZ和16KHZ的信号有用。这意味着AEC对采样率为其它值的声卡无效，例如基于AC''''97的声卡，这种声卡的采样率在44KHZ左右。调节向导检测到这样的声卡时
同样也会禁用 AEC。
可在程序里通过 IRTCClient 接口的 PreferredAEC方法对 AEC 进行控制。
冗余音频编码是一种补偿丢包的技术。RTC 客户端实现了一种 one-packet 冗余算法。当该算法被启用的时候，每一个包都包含了当前的音频帧和前一个音频帧。若某一个包丢失，接受者还有第二个机会在紧随其后的包里得到
该音频帧。这个过程在 IETF
RFC2198 中有文档说明。可被恢复的包的最大数目是3个。该算法根据实时通信控制协议（RTCP）所提供的信息进行自适应调节。
该算法开始的冗余为0，随着丢包的发生引入冗余。原始数据包和携带原始数据备份的包的距离决定有多少个已丢失的包能被恢复。这一距离在1到3之间不等。例如，假如距离为2，而丢失了第n个包，那么在第n+2个包中可以获得同样的信息。如果丢失了第n和第n+1个包，我仍然可以在第n+2和n+3个包中获得全部所有信息。如果我丢失了第n个、第n+1个和第n+2个包，那么第n个包的信息将无法重新获得（因为这些信息在第n+2个包当中）。下表说明在丢包率不同的情况下距离的取值。
距离
丢包率（低）
丢包率（高）
0
0
5
1
4
10
2
9
15
3
14
20
RTC 的客户端实现了自动冗余音频编码（Redundant Audio Coding）。
动态抖动缓冲和调整
抖动缓冲被用于通过缓冲音频包及调整其呈现，从而在接收的音频中进行平滑延迟变化处理。这样可以使语音更平滑地传输给用户。客户端可有一个能增大到500毫秒的抖动缓冲。换句话说，这个缓冲区可以吸收接
收包中500毫秒的延迟变化，而不会引起语音的抖动。
再现缓冲是一个两秒的循环缓冲。如果在一个很短的时间里我们得到了超过两秒的语音数据包，那么新收到的包将会被丢掉。
在这一版本中，抖动缓冲在新的音频数据高峰进行重新调整。为确保高质量语音，发送者应该为所有的编解码使用静音抑制。RTC 的客户端默认使用静音
抑制。
自动增益控制（AGC）
AGC是一种根据输入信号水平动态调整增益的机制。RTC 客户端根据所捕捉到的音量调整麦克风的增益，以实现AGC。
当音量（无论是捕捉到的音量还是再现的音量）超过某一门限值，信号就会被限幅。限幅指的是音频设备的输出不再随着输入而变化，输出实质上变成了最大音量位置上的一条水平线，这会引起声音的中断。当RTC客户端检测到音频增益达到了某一门限——每一个包的连续平均峰值的脉冲编码调制的值都超过了最大门限值——它会自动减小增益来避免限幅的发生。
另一方面，如果捕捉到的音量太低（每一个包的连续平均峰值的脉冲编码调制的值低于最低门限值），RTC的客户端会提高增益。当然，增益的调整不会使音量超过用户在调节向导中设置的值。注意当
启用 AEC 时增益不会被增大，因为这样会使得 AEC 重新聚合，而这需要几秒的时间。
带宽估计
实际可用带宽可能少于 Windows Socket 所报告的本地连接速度。有很多因素会引起这种现象，包括通道的低速连接，其它应用程序消耗的带宽等等。
为了估计实际可用带宽，RTC 客户端发送连续不断的 RTCP 包。另一端根据包与包的延迟来估计带宽。最初每一个 RTCP 包的报告都用于估计带宽，然后逐渐减小到每三个包中的一个用于估计带宽。
当前，带宽估计的结果可用于指示连接是否是 LAN，并且被用作计算实际可用带宽的上限。以后，这一算法将扩展到能给出更多具体的结果。
质量管理算法
RTC 媒体的质量管理的目标是在不同的网络环境中，通过 RTC 客户端为用户提供更好的音频视频服务。QC 持续监控网络环境，计算输出流的可用带宽，动态改变音视频输出流的设置，以提供更平滑的流输出、最小的抖动和延迟。在音视频输出流之间，QC为音频提供更高的优先级。
QC收到来自以下三个源之一的命令或者事件的时候，对输出流进行调整：应用程序、远端和实时通信传输协议（RTP）模块。应用程序通过增加去除流或者改变最大比特率的设置来触发对输出流的调整。远端通过发送新的 SDP（会话描述协议）来触发调整，这反过来也会引起流和比特率的设置。RTP模块周期性
地发送 RTC 媒体事件来报告对端的估计带宽和丢包率。通过接收这些事件，QC对音频和视频流进行调整。
QC 算法包括以下三个主要部分：计算输出流的可用带宽、动态选择和设置音频编解码器和计算视频输出流的带宽和帧率。以下三节详细讨论这三部分内容。
可用带宽
QC根据以下因素计算流的可用带宽：
本地带宽——本地带宽等于检测到的链路速度减去预留带宽。预留带宽为 20Kbps 和检测到的链路速度的 2/5 的最小值。预留的带宽用于非音频和视频流的传输，比如 SIP
协议的信令等等。在呼叫之初——在RTP模块报告任何估计的带宽之前——本地带宽是被限制的，因此，如果检测到的带宽大于 200Kbps，则本地带宽被限制在不大于 120Kbps 的范围之内。
远端带宽——远端带宽从SDP的blob中接受得到。
应用程序带宽——应用程序带宽由应用程序设置。它的上限是1Mbps。应用程序通过设置IRTCClient 接口的 MaxBitrate
方法来实现此配置。
估计带宽——估计带宽为 RTP 模块报告的带宽减去预留带宽。预留带宽为 10Kbps 和报告值的1/3的最小值。
以前分配带宽——以前分配带宽为呼叫中所计算出的上一次可用带宽。
当前带宽——当前带宽为流所使用的实际的总带宽。
当前丢包率——当前丢包率指的是本端发出的包的丢失百分比。
连续的0丢失报告数目——当接收到一个0丢失报告，这一数目每次加1；当接受到一个非0的丢失报告，这一数目被设为0。
音频编解码器的选择
流出音频编解码器的选择和设置基于以下几个因素：
可用带宽
计算可用带宽的算法对带宽的限制
流出视频流的存在
SDP中首选的编解码器顺序
每一个音频编解码器预定义的最小带宽
是否RTP模块已经报告了带宽估计
编解码器转换时的带宽门限
根据条件选择最好的编解码器和帧大小。在呼叫过程中情况是动态变化的。如果有多种载荷类型，那么使用 RTC 的端点应该准备好支持载荷类型和帧大小的变化。
视频带宽和帧率
输出的视频流的帧率由以下因素计算：
可用带宽
最近所选择的视频编解码器的总带宽
应用程序设置的临时带宽
视频的比特率和帧率由以上因素计算，这样视频将不会打断音频的正常通信。所有的变化都是动态的。应用程序可以通过设置 IRTCClient接口的 MaxBitRate 和 TemporalSpatialTradeOff
方法左右算法，但是不能决定最后的设置结果。
结论
通过实时通信客户端包含在 Windows XP 里的媒体特性使得 RTC 客户端成为在各种应用程序中使用 RTC 特性的一个巨大平台。这些特性在 Windows
Messager 中得到了体现，通过 RTC 客户端的 API，可以广泛应用于其它应用程序中。
相关链接
可参考以下资源得到进一步的信息：
Platform SDK for the
Real-time Communications (RTC) Client.
Inside Windows Messenger: How it Communicates.
Windows Messenger in Windows XP: Working with Firewalls and Network Address Translation Devices.
RFC 2198 RTP Payload for Redundant Audio Data.
关于Windows XP的最新信息，参见
感谢：Robert Osborne，Mu Han，Qianbo Huai。
