Microsoft Windows的实时通信客户端的媒体支持
摘要：Microsoft Windows的实时通信（RTC）客户端由一系列核心组件构成，它提供了丰富的通信特征。这些特征通过Windows Messager和其他一些使用了应用程序接口（APIs）的应用程序展示给用户。本文将概述这些组件提供的与媒体相关的特征和改进之处。应用程序的开发者或许想要将RTC的特征结合到自己的程序中。开发者还能利用RTC的特征构建一个自己的社区。
目录
引言
音频视频编解码的使用
回波抵消（AEC）
冗余音频编码
动态抖动缓冲和调整
自动增益控制（AGC）
带宽估计
质量控制算法
结论
相关连接
感谢
引言
微软XP的介入，为RTC 结构的应用提供了丰富的交流特性。微软Messager为用户提供了实时语音和视频通信、即时消息和其他的互动功能。另外，应用程序接口（APIs）的提供使得这些丰富的通信特征可用于任何的应用程序。
本文详细讨论了添加到RTC的媒体改进之处，这些改进使得最终用户和开发者都能有个更愉快的经历。当应用程序构建在RTC客户端API的基础上的时候，最终用户能获得更丰富的音视频体验，而开发者可以使程序得到一系列免费的改进。使用这些API的应用程序还能够获得RTC提供的即时消息和在线查看功能。关于这些API的信息，可在Windows Platform SDK中获得。
本文讨论了以下的特征和改进之处：
音频视频编解码的使用
回波抵消（AEC）
冗余音频编码
动态抖动缓冲和调整
自动增益控制（AGC）
带宽估计
质量控制算法
音频视频编解码的使用
下表列出了Windows的RTC客户端提供的音频codec，同时列出了相关的取样率和比特率。选择哪一种codec取决于通信双方的能力和带宽。例如，如果其中一方使用56KBps的拨号连接，那么G.711就不能使用了，因为它超出了带宽的限制。又比如假如其中一方支持SIREN而另一方不支持，那么首选的codec SIREN也无效。如果双方均支持SIREN并且带宽足够，那么在所有的codec中SIREN即为首选。
Codec |
取 样 率 |
比 特 率 |
RTP包的长度 |
| G.711 |
8 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是视频所支持的codec，其比特率在6到125KBps之间。出于兼容性的考虑，H.261也是被支持的codec。该版本只支持1/4公共中间格式OCIF（176×144）。不支持第三方的codec的plug-in。
回波抵消（AEC）
AEC的工作原理是通过构建讲话者的输出模型，并且将其从麦克风收取的信号里除去。AEC使得对端听不到回声。
为使用AEC，在Windows Messager的菜单：工具/音频调节向导中启动音频调节向导。在向导的音频调节部分，去掉“I am using headphones”单选框前面的“√”。
图1：音视频调节向导对话框
在程序里通过IRTCClient的接口PreferredAEC对AEC进行激活或者去活。
可参考SDK获得有关RTC客户端和接口的更多信息。
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个包当中）。下表说明在丢包率不同的情况下距离的取值。
| Distance |
Loss Rate (Low) |
Loss Rate (High) |
| 0 |
0 |
5 |
| 1 |
4 |
10 |
| 2 |
9 |
15 |
| 3 |
14 |
20 |
RTC的客户端自动实现冗余音频编码。
动态抖动缓冲和调整
抖动缓冲通过设置一个接收包的缓冲区并且调整语音的再现来平滑接收到的语音的延迟的变化。这样可以使语音的传输更平滑。客户端有一个能增大到500msec的抖动缓冲。换句话说，这个缓冲区可以吸收接受包中500msec的延迟变化，而不会引起语音的抖动。
再现缓冲是一个两秒的循环缓冲。如果在一个很短的时间里我们得到了一个超过两秒的语音数据包，那么新收到的包将会被丢掉。
在这一版本中，抖动缓冲在新的音频数据产生之初进行调整。为确保高的语音质量，发送者应该为所有的codec使用静音压缩。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算法包括以下三个主要部分：计算输出流的可用带宽、动态选择和设置音频Codec和计算视频输出流的带宽和帧率。以下三节详细讨论这三部分内容。
可用带宽
QC根据以下因素计算流的可用带宽：
本地带宽――本地带宽等于检测到的链路速度减去预留带宽。预留带宽为20Kbps和检测到的链路速度的2/5的最小值。预留的带宽用于非音频和视频流的传输，比如SIP协议的信令等等。在呼叫的最初――RTP模块还没有报告任何估计带宽之前――如果检测到的带宽大于200Kbps，则本地带宽被限制在不大于120Kbps的范围之内。
远端带宽――远端带宽从SDP的blob中接受得到。
应用带宽——应用带宽由应用程序设置。它的上限是1Mbps。应用程序通过设置IRTCClient接口的MaxBitrate进行设置。
估计带宽——估计带宽为RTP模块报告的带宽减去预留带宽。预留带宽为10Kbps和报告值的1/3的最小值。
以前分配带宽――以前分配带宽为呼叫中所计算出的上一次可用带宽。
当前带宽――当前带宽为流所使用的实际的总带宽。
当前丢包率――当前丢包率指的是本端发出的包的丢失百分比。
连续的0丢失报告数目――当接收到一个0丢失报告，这一数目每次加1；当接受到一个非0的丢失报告，这一数目被设为0。
音频Codec的选择
音频Codec的选择和设置基于以下因素：
可用带宽
计算可用带宽的算法对带宽的限制
视频流的存在
SDP中首选codec的顺序
每一个音频codec预定义的最小带宽
是否RTP模块已经报告了带宽估计
codec转换时的带宽门限
根据条件选择最好的codec和帧大小。在呼叫过程中情况会发生动态的变化。如果有多种载荷类型，那么使用RTC的端点应该准备好支持载荷类型和帧大小的变化。
视频带宽和帧率
输出的视频流的帧率由以下因素计算：
可用带宽
最近所选择的视频codec的总带宽
应用程序设置的临时带宽
视频的比特率和帧率由以上因素计算，这样视频将不会打断音频的正常通信。所有的变化都是动态的。应用程序可以通过设置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的最新信息，参见Windows XP Web site.