隨著Internet和多媒體技術的飛速發展，Internet已由早期的單一數據傳輸網向多媒體數據(視頻、音頻、文本等)綜合傳輸網發展。但Internet提供的只是盡力而為的服務，不能滿足多媒體應用程序對傳輸延遲、包丟失、抖動控制等要求，為了能在傳統的IP網上運行多媒體程序，必須考慮服務質量(Ouality of Service，QoS)。QoS可用延遲、抖動、吞吐量、丟包率等參數來描述。為了支持網絡的實時傳輸服務，互聯網工作組(Internet Engineering Task Force，IETF)制定了實時傳輸協議(Real-time Transport Protocol，RTP)。RTP是專門為交互式音頻、視頻、仿真數據等實時媒體應用而設計的輕型傳輸協議，已廣泛應用于各種多媒體傳輸系統中。IP電話作為一種新興業務，因其低廉的話費受到廣大用戶的歡迎。但IP電話中的通話時延、話音失真一直是制約IP電話迅速發展的“瓶頸”。如何確保IP電話的QoS，是IP電話成功與否的關鍵。
結合IP電話系統，從音頻實時傳輸和控制兩方面來討論RTP及實時傳輸控制協議(Real-time TransportControl Protocol，RTCP)應用技術，分析影響媒體流實時傳輸的因素。從實際實驗、應用的角度，討論如何獲得當前Internet可行的QoS監測，并針對QoS質量保證提出切實可行的解決方案。
2 實時傳輸協議RTP
RTP是用于Internet上針對多媒體數據流的一種傳輸協議，被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP通常使用用戶數據報協議(User Datagram Protocol，UDP)來傳送數據，但RTP也可以在傳輸控制協議(Transmission Control Protocol，TCP)或異步傳輸模式(Asynchronous Transfer Mode，ATM)等其他協議之上工作。當應用程序開始一個RTP會話時將使用2個端口：1個給RTP，1個給RTCP。RTP本身并不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。通常RTP算法并不作為一個獨立的網絡層來實現，而是作為應用程序代碼的一部分，RTCP和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間，參與者周期性地傳送RTCP包，RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用能以有效的反饋和小的開銷使傳輸效率化，因而特別適合傳送網上的實時數據。
2.1 RTP數據包
RTP數據包由12個字節的固定RTP頭和不定長的連續媒體數據(視頻幀或音頻幀)組成。RTP協議的數據包格式如圖1所示。
(1)版本(V)：2bit版本號置2。
(2)擴展位(Extension-X)：由使用的RTP框架定義。
(3)填充(P)：用以說明包尾是否附有非負荷信息。
(4)負載類型(PT)：對音頻或視頻等數據類型予以說明，并說明數據的編碼方式。
(5)標志位(Marker-M)：標志位由具體的應用框架定義。
(6)序列號(Sequence Number)：為了安全，服務器從一個隨機初始化值開始，每發送一個RTP數據包序列號增加1。客戶端可根據序列號重新排列數據包的順序，并對丟失、損壞和重復的數據包進行檢測。
(7)時間戳(Timestamp)：RTP時間戳為同步不同的媒體流提供采樣時間，用于重新建立原始音頻或視頻的時序。另外，它還可以幫助接收方確定數據到達時間的一致性或變化(有時被稱為抖動)。
(8)同步源標識(SSRG)：幫助接收方利用發送方生成的的數值來區分多個同時的數據流。SSRC必須是一個嚴格的隨機數。
(9)作用標識(CSRC)：網絡中使用混合器時，混合器會在RTP報文頭部之后插入新的同步源標識，其作用是區分多個同時的數據流。
2.2 RTP控制協議——RTCP
在RTP會話中，RTCP周期性地給所有參與者發送控制包，應用程序或第三方監控者接受RTCP控制包，從中獲取控制信息，估計當前QoS，以便進行傳輸控制、擁塞處理、錯誤診斷等。
RTCP報文頭部參數首先要區別攜帶不同控制信息的RTCP報文的類型，RTCP報文的類型主要有以下幾種：(1)SR：發送報告，當前活動發送者發送、接收統計；(2)RR：接收報告，非活動發送者接收統計；(3)SDES：源描述項，包括CNAME；(4)BYB：表示結束；(5)APP：應用特定函數。其中主要的RTCP報文是SR和RR。通常SR報文占總RTCP包數量的25％，RR報文占75％。
通過這5種控制包，RTCP協議實現了以下4個主要功能：
(1)提供數據發布的質量反饋，這是RTCP主要的功能。作為RTP傳輸協議的一部分，與其他傳輸協議的流和阻塞控制有關。反饋對自適應編碼控制直接起作用。反饋功能由RTCP發送者和接收者報告執行。
(2)送帶有稱作規范名字(CNAME)的RTP源持久傳輸層標識。如發現沖突，或程序重新啟動，SSRC標識可改變，接收者需要CNAME跟蹤參加者。接收者也需要CNAME與相關RTP連接中給定的幾個數據流聯系。
(3)根據參與RTP會話的數量調整RTCP的發送速率。
(4)傳送小連接控制信息，如參加者辨識。可能用在“松散控制”連接，那里參加者自由進入或離開，沒有成員控制或參數協調，RTCP充當通往所有參加者的方便通道，但不必支持應用的所有控制通信要求。
3 由RTP包分析影響多媒體數據流實時傳輸的因素
隨著VoIP領域不斷發展，滿足網絡QoS檢測需求的應用也成為引人注目的焦點。IP QoS是指IP的服務質量，也是指IP數據流通過網絡時的性能。目的就是向用戶提供端到端的服務質量保證。有一套度量指標，包括業務可用性、延遲、可變延遲、吞吐量和丟包率等，現就項目中在上海阿爾卡特網絡支援系統有限公司NGN實驗室中所得到的RTP和RTCP包進行分析，主要研究其中3個因素，從而達到對實時流媒體數據進行監控的目的。
3.1 抖動
抖動會引起端到端時延的增加，引起語音質量的降低。在音頻數據的傳輸過程中，由于傳輸延遲的不穩定而造成相鄰數據包接收時刻間隔不穩定，從而產生抖動。消除抖動的主要依據就是RTP包的首部中包含的時間戳字段。時間戳標志著該段音頻數據中個采樣點的采樣時間。每兩個RTP包的抖動可以用其RTP包中的RTP時戳和接收的時刻進行計算。
關于包的傳送時間，接收者了解到的是它的時間戳和接收者當前時間之間的差值。該差值是：Di=Ri-Si，表示從包被蓋上戳開始，到它在信源的輸出鏈路上被實際發送為止，其中的傳送時間和某個機器時間。RFC 1889建議使用NTP來完成端點的端到端同步，但是也有非同步端點實現存在。
包i和包j之間增加的延遲差(二階效應)計算公式如下：設Rj代表第j個包的接受時刻，Sj代表第j個包的RTP時戳值，則第i個RTP報文與第j個RTP報文間的抖動為D(i，j)
抖動是分組交換的必然結果，影響抖動的因素一般和網絡的擁塞程度有關。由于語音同數據在同一條物理線上傳輸，語音數據通常會由于數據報文占用了物理線路而導致阻塞。解決抖動通常采用緩沖隊列來解決(在網關、IAD上均有JitterBuffer來消除抖動)，每收到一個數據包，先將其放人緩沖區，應用程序在緩沖區另一端取數據，只要緩沖區足夠大，抖動一定能被平滑掉。而錯序是由于網絡擁擠而使某些后發的數據包先到達收端而引起的，只要設置足夠大的緩沖區來對數據包重新排序，就能解決這個問題。或者需要IP承載網采用QoS策略，保證語音數據的優先級，得到發送和獲得高帶寬也是解決抖動問題的主要手段。
3.2 時延
時延是處理和傳輸導致數據不能按時到達的延遲，是影響流媒體數據傳輸的一個主要因素。話音信號在端到端傳輸過程中受到的時延遲滯通常包括：編解碼器引入的時延、打包時延、去抖動時延、承載網上的傳輸節點中排隊、服務處理時延。這些時延累計的總和將影響話質，導致回聲干擾和交互性的劣化。對于VoIP系統，規定時延一般控制在150 ms內。
分組語音網絡中的延遲可分為固定延遲和可變延遲。前者相對容易得到，筆者不作考慮。在計算丟包率時，主要考慮可變延遲。丟包判定等待時限Twait設定的大小在很大程度上影響丟包率計算的準確性，也就是可變延遲的影響，它與語音包的傳輸延遲Ttrf有關，Twait越大等待時限就越長。但不能超過保證語音流連續播放的時間上限Tmax(Tmax一般取250 ms)，即：Twait=min(Twait，Tmax)。Ttrf可根據RTCP協議的SR控制包中的NTP(Network Time Protoco1)時間戳計算得到，見圖2。
Ttrf=(A-LSR-DLSR)／2 (3)
由實驗包中的數據得出的Ttrf是使用32 bit歸一化NTP時戳計算的，所以要把延遲轉換成毫秒單位，結果中前16 bit將與延遲秒數對應，后16 bit與1／65 536 s的數字對應。因此，上面16 bit必須乘以1 000，把秒轉換成毫秒。下面16 bit必須除以65 536，然后再乘以1 000。兩個因數之和可以得到終結果。
實時語音傳輸要求端對端時延不能太大，端到端的時延要求分成4個等級：≤150ms()、150～250ms(較好)、250～450ms(一般)和450ms以上(差)。可以通過設定IP優先級、路由選擇、RED(隨機早期檢查)等技術來縮短IP網絡時延。
①優先級是指對每個數據包的級別進行分類，不同級別的數據包在網絡進行預留帶寬分配、通過順序、時延抖動、丟包等方面處理時，所受到的待遇不同，這樣可以確保語音、圖像等對實時性要求比較高的數據包優先傳輸，以提高傳輸質量。
②選擇合適的路由繞過那些負載過重的路由器，直接連到主干網進行傳輸。
③當網絡擁擠發生擁塞時，RED就優先丟棄一些對話音影響較小的數據包，并讓終點站降低傳輸速率，避免路由器或交換設備緩沖區溢出。
此外，采用流量控制、隊列管理、數據包保護技術也可以提高網絡的管理性能，從而縮小網絡時延。
3.3 丟包率
丟包率定義為在網絡中傳輸數據包時丟棄數據包的比率。數據包丟失一般是由網絡擁塞引起的。丟包對VoIP語音質量的影響較大，在本實驗環境中，采用G.711時，當丟包率大于10％時，已不能接受，而在丟包率為5％時，基本還可以接受，因此，要求IP承載網的丟包率小于5％。
丟包率為單位時間內丟失的語音包的數目。檢測的具體方法是統計語音流中的連續2個SR(發送端報告控制包)的時間間隔Tint內實際接收語音包的數目Nreal，然后按下面公式來計算丟包率Rlost
Rlost=(Nexp-Nreal)Nexp (4)
其中：Nexp為期望的語音包數目，它等于在Tint內接收到語音包的小序號Ni和序號Nj之差，用下面公式來表示：Nexp=Nj-Ni，實際接收到的語音包Nreal可能包括在Tint之前的遲到包(由于語音數據采用UDP協議傳輸，不存在重復包)，所以計算所得的丟包率會出現負數。此時丟包率定義為0。
丟包率的計算可在每個丟包判定等待時限內計算，也可按照一定的時間間隔來計算一次，而這個時間間隔要根據網絡的負載、網絡的穩定情況來確定。為了減少網絡的負載，不是每次計算的丟包率都要反饋給源網關的，而是事先根據網絡用戶期望的語音質量來確定兩個丟包率狀態的閾值R1和R2。對于音頻而言，取R1=3％，R2=8％。當Rlost>R2時，將丟包率信息的標志位，置為“overload”(擁塞)，表示網絡處于擁塞狀態；當Rlost＜R1時，置為“abnormality”(異常)，表示網絡處于失載狀態；其余均置為“normality”(正常)，表示網絡處于正常狀態。將這些信息封裝在RTCP的SR，RR控制包中，并反饋給源網關，過程如圖3所示。
如果某個RTP包在傳輸過程中丟失，那么丟失的只是原數據包按采樣間隔的一半信息，接收端可以用接受到的另一半信息，利用插值等方法恢復出原話音包的大部分信息，從而使話音質量不至于下降太多。拆分法的主要思想如圖4所示。
對音頻數據的實時傳輸問題進行了詳細分析，在分析RTP協議的基礎上，探討了基于RTP協議的QoS動態監測的一些方法，并提出了解決在流媒體中存在的語音實時傳輸質量保證的策略。避免語音通信實時性差的缺點，減小了網絡延時使抖動的影響減低，改善了語音傳輸效果。目前，IP電話用戶數每年正以239％的速度增長。下一步將以此為依據設計出基于RTP的一個應用模型，進行深層開發研究。