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

　　1 引言

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

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

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

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

　　2.1 RTP數據包

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

　　RTP報文頭部分各個(gè)參數的意義如下：

　　(1)版本(V)：2bit版本號置2。

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

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

　　(4)負載類(lèi)型(PT)：對音頻或視頻等數據類(lèi)型予以說(shuō)明，并說(shuō)明數據的編碼方式。

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

　　(6)序列號(Sequence Number)：為了安全，服務(wù)器從一個(gè)隨機初始化值開(kāi)始，每發(fā)送一個(gè)RTP數據包序列號增加1?？蛻?hù)端可根據序列號重新排列數據包的順序，并對丟失、損壞和重復的數據包進(jìn)行檢測。

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

　　(8)同步源標識(SSRG)：幫助接收方利用發(fā)送方生成的唯一的數值來(lái)區分多個(gè)同時(shí)的數據流。SSRC必須是一個(gè)嚴格的隨機數。

　　(9)作用標識(CSRC)：網(wǎng)絡(luò )中使用混合器時(shí)，混合器會(huì )在RTP報文頭部之后插入新的同步源標識，其作用是區分多個(gè)同時(shí)的數據流。

　　2.2 RTP控制協(xié)議——RTCP

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

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

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

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

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

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

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

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

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

　　3.1 抖動(dòng)

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

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

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

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

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

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

　　3.2 時(shí)延

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

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

　　使用RTCP包計算網(wǎng)絡(luò )時(shí)延要求在兩個(gè)端點(diǎn)之間傳送發(fā)送方報告(RTCPSR)。RTCP包中的報文類(lèi)型以二進(jìn)制表示，其中十進(jìn)制的200代表此包的報文類(lèi)型為SR(發(fā)送報文)。收到200的包類(lèi)型，表明可以提供足夠的信息，計算與這個(gè)SSRC有關(guān)的發(fā)送方的延遲。那么就計算發(fā)送方流(SSRC)和源流(SSRC_n)之間的雙向延遲。每次在收到RTCPSR包時(shí)，必須保存上一個(gè)時(shí)間戳(Last SR Timestamp，LSR)和DLSR(Delay SinceLast SR)值。SSRC的LSR域是從該SSRC接收到的NTP時(shí)間戳的中間32 bit，只要接收到一個(gè)NTP時(shí)間戳就可以了。如果沒(méi)有接收到NTP時(shí)間戳，那么這個(gè)域應該設置為0。信源可能無(wú)法獲得時(shí)鐘，或者其他可接受的消逝的時(shí)間。因此，在會(huì )話(huà)持續期間，特定SSRC的這個(gè)域可能保持為0。DLSR域是端點(diǎn)從發(fā)送者那里接收到一個(gè)SR以后過(guò)去的時(shí)問(wèn)。這個(gè)計數器的每一步代表1/65 536 s。一般來(lái)說(shuō)，在NTP時(shí)戳，LSR或DLSR等于零時(shí)，不應該計算雙向延遲。網(wǎng)絡(luò )傳輸時(shí)延Ttrf即為雙向延遲的一半。具體計算方法如下：設目的網(wǎng)關(guān)接收源網(wǎng)關(guān)發(fā)送的控制包SRi，經(jīng)過(guò)一段時(shí)延DLSR后，向源網(wǎng)關(guān)發(fā)送相應的響應SR控制包SRj，并從控制包SRj中的NTP時(shí)間戳域中提取中間的32 bit作為控制包SRi的LSR。如果沒(méi)有收到源網(wǎng)關(guān)發(fā)出的SR控制包，則L5R和DLSR都置為0。最后，將DLSR和LSR的值填入到控制包SRj的相應域中。設源網(wǎng)關(guān)接收到控制包SRj時(shí)刻為A，則當前網(wǎng)絡(luò )傳輸延時(shí)為

　　Ttrf=(A-LSR-DLSR)/2 (3)

　　由實(shí)驗包中的數據得出的Ttrf是使用32 bit歸一化NTP時(shí)戳計算的，所以要把延遲轉換成毫秒單位，結果中前16 bit將與延遲秒數對應，后16 bit與1/65 536 s的數字對應。因此，上面16 bit必須乘以1 000，把秒轉換成毫秒。下面16 bit必須除以65 536，然后再乘以1 000。兩個(gè)因數之和可以得到最終結果。

　　實(shí)時(shí)語(yǔ)音傳輸要求端對端時(shí)延不能太大，端到端的時(shí)延要求分成4個(gè)等級：≤150ms(最好)、150～250ms(較好)、250～450ms(一般)和450ms以上(差)?？梢酝ㄟ^(guò)設定IP優(yōu)先級、路由選擇、RED(隨機早期檢查)等技術(shù)來(lái)縮短IP網(wǎng)絡(luò )時(shí)延。

　?、賰?yōu)先級是指對每個(gè)數據包的級別進(jìn)行分類(lèi)，不同級別的數據包在網(wǎng)絡(luò )進(jìn)行預留帶寬分配、通過(guò)順序、時(shí)延抖動(dòng)、丟包等方面處理時(shí)，所受到的待遇不同，這樣可以確保語(yǔ)音、圖像等對實(shí)時(shí)性要求比較高的數據包優(yōu)先傳輸，以提高傳輸質(zhì)量。

　?、谶x擇合適的路由繞過(guò)那些負載過(guò)重的路由器，直接連到主干網(wǎng)進(jìn)行傳輸。

　?、郛斁W(wǎng)絡(luò )擁擠發(fā)生擁塞時(shí)，RED就優(yōu)先丟棄一些對話(huà)音影響較小的數據包，并讓終點(diǎn)站降低傳輸速率，避免路由器或交換設備緩沖區溢出。

　　此外，采用流量控制、隊列管理、數據包保護技術(shù)也可以提高網(wǎng)絡(luò )的管理性能，從而縮小網(wǎng)絡(luò )時(shí)延。

　　3.3 丟包率

　　丟包率定義為在網(wǎng)絡(luò )中傳輸數據包時(shí)丟棄數據包的最高比率。數據包丟失一般是由網(wǎng)絡(luò )擁塞引起的。丟包對VoIP語(yǔ)音質(zhì)量的影響較大，在本實(shí)驗環(huán)境中，采用G.711時(shí)，當丟包率大于10%時(shí)，已不能接受，而在丟包率為5%時(shí)，基本還可以接受，因此，要求IP承載網(wǎng)的丟包率小于5%。

　　丟包率為單位時(shí)間內丟失的語(yǔ)音包的數目。檢測的具體方法是統計語(yǔ)音流中的連續2個(gè)SR(發(fā)送端報告控制包)的時(shí)間間隔Tint內實(shí)際接收語(yǔ)音包的數目Nreal，然后按下面公式來(lái)計算丟包率Rlost

　　Rlost=(Nexp-Nreal)Nexp (4)

　　其中：Nexp為期望的語(yǔ)音包數目，它等于在Tint內接收到語(yǔ)音包的最小序號Ni和最大序號Nj之差，用下面公式來(lái)表示：Nexp=Nj-Ni，實(shí)際接收到的語(yǔ)音包Nreal可能包括在Tint之前的遲到包(由于語(yǔ)音數據采用UDP協(xié)議傳輸，不存在重復包)，所以計算所得的丟包率會(huì )出現負數。此時(shí)丟包率定義為0。

　　丟包率的計算可在每個(gè)丟包判定等待時(shí)限內計算，也可按照一定的時(shí)間間隔來(lái)計算一次，而這個(gè)時(shí)間間隔要根據網(wǎng)絡(luò )的負載、網(wǎng)絡(luò )的穩定情況來(lái)確定。為了減少網(wǎng)絡(luò )的負載，不是每次計算的丟包率都要反饋給源網(wǎng)關(guān)的，而是事先根據網(wǎng)絡(luò )用戶(hù)期望的語(yǔ)音質(zhì)量來(lái)確定兩個(gè)丟包率狀態(tài)的閾值R1和R2。對于音頻而言，取R1=3%，R2=8%。當Rlost>R2時(shí)，將丟包率信息的標志位，置為“overload”(擁塞)，表示網(wǎng)絡(luò )處于擁塞狀態(tài);當Rlost

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

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

　　4 結束語(yǔ)

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