首頁>>>技術>>>VoIP

基于RTP協(xié)議的IP電話QoS監(jiān)測及提高策略

2007/10/30

1 引言

  隨著Internet和多媒體技術的飛速發(fā)展,Internet已由早期的單一數據傳輸網向多媒體數據(視頻、音頻、文本等)綜合傳輸網發(fā)展。但Internet提供的只是盡力而為的服務,不能滿足多媒體應用程序對傳輸延遲、包丟失、抖動控制等要求,為了能在傳統(tǒng)的IP網上運行多媒體程序,必須考慮服務質量(Ouality of Service,QoS)。QoS可用延遲、抖動、吞吐量、丟包率等參數來描述。為了支持網絡的實時傳輸服務,互聯(lián)網工作組(Internet Engineering Task Force,IETF)制定了實時傳輸協(xié)議(Real-time Transport Protocol,RTP)。RTP是專門為交互式音頻、視頻、仿真數據等實時媒體應用而設計的輕型傳輸協(xié)議,已廣泛應用于各種多媒體傳輸系統(tǒng)中。IP電話作為一種新興業(yè)務,因其低廉的話費受到廣大用戶的歡迎。但IP電話中的通話時延、話音失真一直是制約IP電話迅速發(fā)展的“瓶頸”。如何確保IP電話的QoS,是IP電話成功與否的關鍵。

  結合IP電話系統(tǒng),從音頻實時傳輸和控制兩方面來討論RTP及實時傳輸控制協(xié)議(Real-time TransportControl Protocol,RTCP)應用技術,分析影響媒體流實時傳輸的因素。最后從實際實驗、應用的角度,討論如何獲得當前Internet可行的QoS監(jiān)測,并針對QoS質量保證提出切實可行的解決方案。

2 實時傳輸協(xié)議RTP

  RTP是用于Internet上針對多媒體數據流的一種傳輸協(xié)議,被定義為在一對一或一對多的傳輸情況下工作,其目的是提供時間信息和實現流同步。RTP通常使用用戶數據報協(xié)議(User Datagram Protocol,UDP)來傳送數據,但RTP也可以在傳輸控制協(xié)議(Transmission Control Protocol,TCP)或異步傳輸模式(Asynchronous Transfer Mode,ATM)等其他協(xié)議之上工作。當應用程序開始一個RTP會話時將使用2個端口:1個給RTP,1個給RTCP。RTP本身并不能為按順序傳送數據包提供可靠的傳送機制,也不提供流量控制或擁塞控制,它依靠RTCP提供這些服務。通常RTP算法并不作為一個獨立的網絡層來實現,而是作為應用程序代碼的一部分,RTCP和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間,參與者周期性地傳送RTCP包,RTCP包中含有已發(fā)送的數據包的數量、丟失的數據包的數量等統(tǒng)計資料,因此,服務器可以利用這些信息動態(tài)地改變傳輸速率,甚至改變有效載荷類型。RTP和RTCP配合使用能以有效的反饋和最小的開銷使傳輸效率最佳化,因而特別適合傳送網上的實時數據。

2.1 RTP數據包

  RTP數據包由12個字節(jié)的固定RTP頭和不定長的連續(xù)媒體數據(視頻幀或音頻幀)組成。RTP協(xié)議的數據包格式如圖1所示。


RTP報文頭部分各個參數的意義如下:
  1. 版本(V):2bit版本號置2。


  2. 擴展位(Extension-X):由使用的RTP框架定義。


  3. 填充(P):用以說明包尾是否附有非負荷信息。


  4. 負載類型(PT):對音頻或視頻等數據類型予以說明,并說明數據的編碼方式。

  5. 標志位(Marker-M):標志位由具體的應用框架定義。


  6. 序列號(Sequence Number):為了安全,服務器從一個隨機初始化值開始,每發(fā)送一個RTP數據包序列號增加1?蛻舳丝筛鶕蛄刑栔匦屡帕袛祿捻樞,并對丟失、損壞和重復的數據包進行檢測。


  7. 時間戳(Timestamp):RTP時間戳為同步不同的媒體流提供采樣時間,用于重新建立原始音頻或視頻的時序。另外,它還可以幫助接收方確定數據到達時間的一致性或變化(有時被稱為抖動)。


  8. 同步源標識(SSRG):幫助接收方利用發(fā)送方生成的唯一的數值來區(qū)分多個同時的數據流。SRC必須是一個嚴格的隨機數。


  9. 作用標識(CSRC):網絡中使用混合器時,混合器會在RTP報文頭部之后插入新的同步源標識,其作用是區(qū)分多個同時的數據流。
2.2 RTP控制協(xié)議——RTCP

  在RTP會話中,RTCP周期性地給所有參與者發(fā)送控制包,應用程序或第三方監(jiān)控者接受RTCP控制包,從中獲取控制信息,估計當前QoS,以便進行傳輸控制、擁塞處理、錯誤診斷等。

  RTCP報文頭部參數首先要區(qū)別攜帶不同控制信息的RTCP報文的類型,RTCP報文的類型主要有以下幾種:(1)SR:發(fā)送報告,當前活動發(fā)送者發(fā)送、接收統(tǒng)計;(2)RR:接收報告,非活動發(fā)送者接收統(tǒng)計;(3)SDES:源描述項,包括CNAME;(4)BYB:表示結束;(5)APP:應用特定函數。其中最主要的RTCP報文是SR和RR。通常SR報文占總RTCP包數量的25%,RR報文占75%。

通過這5種控制包,RTCP協(xié)議實現了以下4個主要功能:

  (1)提供數據發(fā)布的質量反饋,這是RTCP最主要的功能。作為RTP傳輸協(xié)議的一部分,與其他傳輸協(xié)議的流和阻塞控制有關。反饋對自適應編碼控制直接起作用。反饋功能由RTCP發(fā)送者和接收者報告執(zhí)行。

  (2)送帶有稱作規(guī)范名字(CNAME)的RTP源持久傳輸層標識。如發(fā)現沖突,或程序重新啟動,SSRC標識可改變,接收者需要CNAME跟蹤參加者。接收者也需要CNAME與相關RTP連接中給定的幾個數據流聯(lián)系。

  (3)根據參與RTP會話的數量調整RTCP的發(fā)送速率。

  (4)傳送最小連接控制信息,如參加者辨識。最可能用在“松散控制”連接,那里參加者自由進入或離開,沒有成員控制或參數協(xié)調,RTCP充當通往所有參加者的方便通道,但不必支持應用的所有控制通信要求。

3 由RTP包分析影響多媒體數據流實時傳輸的因素

  隨著VoIP領域不斷發(fā)展,滿足網絡QoS檢測需求的應用也成為引人注目的焦點。IP QoS是指IP的服務質量,也是指IP數據流通過網絡時的性能。目的就是向用戶提供端到端的服務質量保證。有一套度量指標,包括業(yè)務可用性、延遲、可變延遲、吞吐量和丟包率等,現就項目中在上海阿爾卡特網絡支援系統(tǒng)有限公司NGN實驗室中所得到的RTP和RTCP包進行分析,主要研究其中3個因素,從而達到對實時流媒體數據進行監(jiān)控的目的。

3.1 抖動

  抖動會引起端到端時延的增加,引起語音質量的降低。在音頻數據的傳輸過程中,由于傳輸延遲的不穩(wěn)定而造成相鄰數據包接收時刻間隔不穩(wěn)定,從而產生抖動。消除抖動的主要依據就是RTP包的首部中包含的時間戳字段。時間戳標志著該段音頻數據中第一個采樣點的采樣時間。每兩個RTP包的抖動可以用其RTP包中的RTP時戳和接收的時刻進行計算。

  關于包的傳送時間,接收者最先了解到的是它的時間戳和接收者當前時間之間的差值。該差值是:Di=Ri-Si,表示從包被蓋上戳開始,到它在信源的輸出鏈路上被實際發(fā)送為止,其中的傳送時間和某個機器時間。RFC 1889建議使用NTP來完成端點的端到端同步,但是也有非同步端點實現存在。

  包i和包j之間增加的延遲差(二階效應)計算公式如下:設Rj代表第j個包的接受時刻,Sj代表第j個包的RTP時戳值,則第i個RTP報文與第j個RTP報文間的抖動為D(i,j)



  在生成RTCP報文時,其應當傳送的時延抖動的值可用以下公式進行遞推計算



  其中:J為要傳送的時延抖動值。對后一項除以16是為了消除連帶噪聲。

  抖動是分組交換的必然結果,影響抖動的因素一般和網絡的擁塞程度有關。由于語音同數據在同一條物理線上傳輸,語音數據通常會由于數據報文占用了物理線路而導致阻塞。解決抖動通常采用緩沖隊列來解決(在網關、IAD上均有JitterBuffer來消除抖動),每收到一個數據包,先將其放人緩沖區(qū),應用程序在緩沖區(qū)另一端取數據,只要緩沖區(qū)足夠大,抖動一定能被平滑掉。而錯序是由于網絡擁擠而使某些后發(fā)的數據包先到達收端而引起的,只要設置足夠大的緩沖區(qū)來對數據包重新排序,就能解決這個問題。或者需要IP承載網采用QoS策略,保證語音數據的最高優(yōu)先級,得到最先發(fā)送和獲得高帶寬也是解決抖動問題的主要手段。

3.2 時延

  時延是處理和傳輸導致數據不能按時到達的延遲,是影響流媒體數據傳輸的一個主要因素。話音信號在端到端傳輸過程中受到的時延遲滯通常包括:編解碼器引入的時延、打包時延、去抖動時延、承載網上的傳輸節(jié)點中排隊、服務處理時延。這些時延累計的總和將影響話質,導致回聲干擾和交互性的劣化。對于VoIP系統(tǒng),規(guī)定時延一般控制在150 ms內。

  分組語音網絡中的延遲可分為固定延遲和可變延遲。前者相對容易得到,筆者不作考慮。在計算丟包率時,主要考慮可變延遲。丟包判定等待時限Twait設定的大小在很大程度上影響丟包率計算的準確性,也就是可變延遲的影響,它與語音包的傳輸延遲Ttrf有關,Twait越大等待時限就越長。但不能超過保證語音流連續(xù)播放的時間上限Tmax(Tmax一般取250 ms),即:Twait=min(Twait,Tmax)。Ttrf可根據RTCP協(xié)議的SR控制包中的NTP(Network Time Protoco1)時間戳計算得到,見圖2。



  根據RTP頭中的sequence number域,可以在接收端很輕易地發(fā)現包丟失,為丟包修復奠定基礎。在實際使用中發(fā)現,絕大多數丟包是單個丟包,兩個或兩個以上包丟失的比例較小。針對單個包的丟失,傳統(tǒng)的丟包處理方法有兩種:一種方法是重發(fā),但在傳輸語音數據時,重發(fā)將引起播放質量下降,出現無法識別的話音或回音現象;另一種方法是忽略,這同樣會影響播放質量。更好的方案是使用拆分法優(yōu)化丟包損失。拆分法的基本思想是:在發(fā)送端把原來要打入一個RTP包的話音數據按照采樣間隔分成兩塊,然后采用相同的壓縮算法分別壓縮、打入RTP包,并標記相同的時印進行傳輸。在接收方執(zhí)行相反的過程,把解壓縮后的數據采樣、合并、回放。

  如果某個RTP包在傳輸過程中丟失,那么丟失的只是原數據包按采樣間隔的一半信息,接收端可以用接受到的另一半信息,利用插值等方法恢復出原話音包的大部分信息,從而使話音質量不至于下降太多。拆分法的主要思想如圖4所示。



4 結束語

  對音頻數據的實時傳輸問題進行了詳細分析,在分析RTP協(xié)議的基礎上,探討了基于RTP協(xié)議的QoS動態(tài)監(jiān)測的一些方法,并提出了解決在流媒體中存在的語音實時傳輸質量保證的策略。避免語音通信實時性差的缺點,減小了網絡延時使抖動的影響減低,改善了語音傳輸效果。目前,IP電話用戶數每年正以239%的速度增長。下一步將以此為依據設計出基于RTP的一個應用模型,進行深層開發(fā)研究。

中國通信網(www.c114.net)



相關鏈接:
微軟:用軟件融合電信 2007-10-29
統(tǒng)一通信移向超級連接的通信新大陸 2007-10-29
統(tǒng)一通信市場尚需培育 2007-10-25
高清語音技術騰飛之路在何方? 2007-10-24
Skype和Vonage為何必死無疑? 2007-10-24

分類信息: