分类：
2008-10-14 14:52:27
Microsoft Windows 实时通信(RTC)客户端的媒体支持
原著：Tom Fout
翻译：
原文出处：
摘要
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，在 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 底层结构的一部分。该组件包括下列特性和限制：
冗余音频编码是一种补偿丢包的技术。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是一种根据输入信号水平动态调整增益的机制。RTC 客户端根据所捕捉到的音量调整麦克风的增益，以实现AGC。
当音量（无论是捕捉到的音量还是再现的音量）超过某一门限值，信号就会被限幅。限幅指的是音频设备的输出不再随着输入而变化，输出实质上变成了最大音量位置上的一条水平线，这会引起声音的中断。当RTC客户端检测到音频增益达到了某一门限——每一个包的连续平均峰值的脉冲编码调制的值都超过了最大门限值——它会自动减小增益来避免限幅的发生。
另一方面，如果捕捉到的音量太低（每一个包的连续平均峰值的脉冲编码调制的值低于最低门限值），RTC的客户端会提高增益。当然，增益的调整不会使音量超过用户在调节向导中设置的值。注意当
启用 AEC 时增益不会被增大，因为这样会使得 AEC 重新聚合，而这需要几秒的时间。
实际可用带宽可能少于 Windows Socket 所报告的本地连接速度。有很多因素会引起这种现象，包括通道的低速连接，其它应用程序消耗的带宽等等。
为了估计实际可用带宽，RTC 客户端发送连续不断的 RTCP 包。另一端根据包与包的延迟来估计带宽。最初每一个 RTCP 包的报告都用于估计带宽，然后逐渐减小到每三个包中的一个用于估计带宽。
当前，带宽估计的结果可用于指示连接是否是 LAN，并且被用作计算实际可用带宽的上限。以后，这一算法将扩展到能给出更多具体的结果。
RTC 媒体的质量管理的目标是在不同的网络环境中，通过 RTC 客户端为用户提供更好的音频视频服务。QC 持续监控网络环境，计算输出流的可用带宽，动态改变音视频输出流的设置，以提供更平滑的流输出、最小的抖动和延迟。在音视频输出流之间，QC为音频提供更高的优先级。
QC收到来自以下三个源之一的命令或者事件的时候，对输出流进行调整：应用程序、远端和实时通信传输协议（RTP）模块。应用程序通过增加去除流或者改变最大比特率的设置来触发对输出流的调整。远端通过发送新的 SDP（会话描述协议）来触发调整，这反过来也会引起流和比特率的设置。RTP模块周期性
地发送 RTC 媒体事件来报告对端的估计带宽和丢包率。通过接收这些事件，QC对音频和视频流进行调整。
QC 算法包括以下三个主要部分：计算输出流的可用带宽、动态选择和设置音频编解码器和计算视频输出流的带宽和帧率。以下三节详细讨论这三部分内容。
可用带宽
QC根据以下因素计算流的可用带宽：
音频编解码器的选择
流出音频编解码器的选择和设置基于以下几个因素：
根据条件选择最好的编解码器和帧大小。在呼叫过程中情况是动态变化的。如果有多种载荷类型，那么使用 RTC 的端点应该准备好支持载荷类型和帧大小的变化。
视频带宽和帧率
输出的视频流的帧率由以下因素计算：
视频的比特率和帧率由以上因素计算，这样视频将不会打断音频的正常通信。所有的变化都是动态的。应用程序可以通过设置 IRTCClient接口的 MaxBitRate 和 TemporalSpatialTradeOff
方法左右算法，但是不能决定最后的设置结果。
通过实时通信客户端包含在 Windows XP 里的媒体特性使得 RTC 客户端成为在各种应用程序中使用 RTC 特性的一个巨大平台。这些特性在 Windows
Messager 中得到了体现，通过 RTC 客户端的 API，可以广泛应用于其它应用程序中。
可参考以下资源得到进一步的信息：
关于Windows XP的最新信息，参见
.
：Robert Osborne，Mu Han，Qianbo Huai。
