摘要
Microsoft Windows 的實時通信（RTC）客戶端由一系列核心組件構成，它提供了豐富 的通信特性。這些特性通過 Windows Messager 和其它一些使用了此應用程序編程接口（ APIs）的應用程序展示給用戶。本文將概述與媒體相關的特性以及這些組件提供的增強特 性。應用程序開發者或許想要將 RTC 特性 集成到自己的程序中以改進用戶體驗。開發者 還能利用 RTC 的特性構建自己的社區。
引言
Microsoft Windows XP 中結合與增強了豐富的通信特性，為 RTC 體驗提供了基礎。 Microsoft Windows Messager 利用這些特性為用戶到用戶間的通信提供了實時語音和視 頻、即時消息和其它的協作功能。另外，其所提供的應用程序編程接口（APIs）使得這些 豐富的通信特性可用於任何應用程序。
本文詳細討論了添加到 RTC 的媒體改進特性，這些改進使得最終用戶和開發者都能有 更愉快的體驗。當應用程序被構建在 RTC 客戶端 API 之上，最終用戶能獲得豐富的音視 頻體驗，而開發者可以使程序得到一系列免費的改進。使用這些 API 構建的應用程序還 能夠訪問 RTC 提供的即時消息和出席功能。有關這些API的信息，可在 Windows Platform SDK中獲得。
本文討論了以下的特性和改進之處：
音頻視頻編解碼器的可獲得性
回波抵消（AEC）
冗余音頻編碼
動態抖動緩沖和調整
自動增益控制（AGC）
帶寬估計
質量控制算法
音頻視頻編解碼器的可獲得性
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，可以廣泛應用於其它應用程序中。
