新聞中心

EEPW首頁 > 手機(jī)與無線通信 > 設(shè)計(jì)應(yīng)用 > 基于RTP協(xié)議的IP電話QoS監(jiān)測(cè)及提高策略

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

——
作者: 時(shí)間:2007-10-29 來源:電聲技術(shù) 收藏

  1 引言

  隨著Internet和多媒體技術(shù)的飛速發(fā)展,Internet已由早期的單一數(shù)據(jù)傳輸網(wǎng)向多媒體數(shù)據(jù)(視頻、音頻、文本等)綜合傳輸網(wǎng)發(fā)展。但I(xiàn)nternet提供的只是盡力而為的服務(wù),不能滿足多媒體應(yīng)用程序?qū)鬏斞舆t、包丟失、抖動(dòng)控制等要求,為了能在傳統(tǒng)的IP網(wǎng)上運(yùn)行多媒體程序,必須考慮服務(wù)質(zhì)量(Ouality of Service,)。可用延遲、抖動(dòng)、吞吐量、丟包率等參數(shù)來描述。為了支持的實(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)中。作為一種新興業(yè)務(wù),因其低廉的話費(fèi)受到廣大用戶的歡迎。但中的通話時(shí)延、話音失真一直是制約迅速發(fā)展的“瓶頸”。如何確保IP電話的,是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)測(cè),并針對(duì)QoS質(zhì)量保證提出切實(shí)可行的解決方案。

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

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

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

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

  

  RTP報(bào)文頭部分各個(gè)參數(shù)的意義如下:

  (1)版本(V):2bit版本號(hào)置2。

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

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

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

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

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

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

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

  (9)作用標(biāo)識(shí)(CSRC):中使用混合器時(shí),混合器會(huì)在RTP報(bào)文頭部之后插入新的同步源標(biāo)識(shí),其作用是區(qū)分多個(gè)同時(shí)的數(shù)據(jù)流。

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

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

  RTCP報(bào)文頭部參數(shù)首先要區(qū)別攜帶不同控制信息的RTCP報(bào)文的類型,RTCP報(bào)文的類型主要有以下幾種:(1)SR:發(fā)送報(bào)告,當(dāng)前活動(dòng)發(fā)送者發(fā)送、接收統(tǒng)計(jì);(2)RR:接收?qǐng)?bào)告,非活動(dòng)發(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個(gè)主要功能:

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

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

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

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

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

  隨著VoIP領(lǐng)域不斷發(fā)展,滿足網(wǎng)絡(luò)QoS檢測(cè)需求的應(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個(gè)因素,從而達(dá)到對(duì)實(shí)時(shí)流媒體數(shù)據(jù)進(jìn)行監(jiān)控的目的。

  3.1 抖動(dòng)

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

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

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

  

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

  

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

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

  3.2 時(shí)延

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

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

  

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

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

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

  實(shí)時(shí)語音傳輸要求端對(duì)端時(shí)延不能太大,端到端的時(shí)延要求分成4個(gè)等級(jí):≤150ms(最好)、150~250ms(較好)、250~450ms(一般)和450ms以上(差)。可以通過設(shè)定IP優(yōu)先級(jí)、路由選擇、RED(隨機(jī)早期檢查)等技術(shù)來縮短IP網(wǎng)絡(luò)時(shí)延。

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

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

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

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

  3.3 丟包率

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

  丟包率為單位時(shí)間內(nèi)丟失的語音包的數(shù)目。檢測(cè)的具體方法是統(tǒng)計(jì)語音流中的連續(xù)2個(gè)SR(發(fā)送端報(bào)告控制包)的時(shí)間間隔Tint內(nèi)實(shí)際接收語音包的數(shù)目Nreal,然后按下面公式來計(jì)算丟包率Rlost

  Rlost=(Nexp-Nreal)Nexp (4)

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

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

  

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

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

  

  4 結(jié)束語

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



評(píng)論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉