首頁>>>技術(shù)>>>VoIP

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

2007/10/30

1 引言

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

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

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

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

2.1 RTP數(shù)據(jù)包

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


RTP報(bào)文頭部分各個參數(shù)的意義如下：
  1. 版本(V)：2bit版本號置2。


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


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


  4. 負(fù)載類型(PT)：對音頻或視頻等數(shù)據(jù)類型予以說明，并說明數(shù)據(jù)的編碼方式。

  5. 標(biāo)志位(Marker-M)：標(biāo)志位由具體的應(yīng)用框架定義。


  6. 序列號(Sequence Number)：為了安全，服務(wù)器從一個隨機(jī)初始化值開始，每發(fā)送一個RTP數(shù)據(jù)包序列號增加1�？蛻舳丝筛鶕�(jù)序列號重新排列數(shù)據(jù)包的順序，并對丟失、損壞和重復(fù)的數(shù)據(jù)包進(jìn)行檢測。


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


  8. 同步源標(biāo)識(SSRG)：幫助接收方利用發(fā)送方生成的唯一的數(shù)值來區(qū)分多個同時(shí)的數(shù)據(jù)流。SRC必須是一個嚴(yán)格的隨機(jī)數(shù)。


  9. 作用標(biāo)識(CSRC)：網(wǎng)絡(luò)中使用混合器時(shí)，混合器會在RTP報(bào)文頭部之后插入新的同步源標(biāo)識，其作用是區(qū)分多個同時(shí)的數(shù)據(jù)流。
2.2 RTP控制協(xié)議——RTCP

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

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

通過這5種控制包，RTCP協(xié)議實(shí)現(xiàn)了以下4個主要功能：

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

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

　　(3)根據(jù)參與RTP會話的數(shù)量調(diào)整RTCP的發(fā)送速率。

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

3 由RTP包分析影響多媒體數(shù)據(jù)流實(shí)時(shí)傳輸?shù)囊蛩?/b>

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

3.1 抖動

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

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

　　包i和包j之間增加的延遲差(二階效應(yīng))計(jì)算公式如下：設(shè)Rj代表第j個包的接受時(shí)刻，Sj代表第j個包的RTP時(shí)戳值，則第i個RTP報(bào)文與第j個RTP報(bào)文間的抖動為D(i，j)



　　在生成RTCP報(bào)文時(shí)，其應(yīng)當(dāng)傳送的時(shí)延抖動的值可用以下公式進(jìn)行遞推計(jì)算



　　其中：J為要傳送的時(shí)延抖動值。對后一項(xiàng)除以16是為了消除連帶噪聲。

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

3.2 時(shí)延

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

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



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

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



4 結(jié)束語

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

中國通信網(wǎng)(www.c114.net)


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

分類信息: