隨著Internet和多媒體技術(shù)的飛速發(fā)展,Internet已由早期的單一數(shù)據(jù)傳輸網(wǎng)向多媒體數(shù)據(jù)(視頻、音頻、文本等)綜合傳輸網(wǎng)發(fā)展。但Internet提供的只是盡力而為的服務,不能滿足多媒體應用程序?qū)鬏斞舆t、包丟失、抖動控制等要求,為了能在傳統(tǒng)的IP網(wǎng)上運行多媒體程序,必須考慮服務質(zhì)量(Ouality
of Service,QoS)。QoS可用延遲、抖動、吞吐量、丟包率等參數(shù)來描述。為了支持網(wǎng)絡(luò)的實時傳輸服務,互聯(lián)網(wǎng)工作組(Internet
Engineering Task Force,IETF)制定了實時傳輸協(xié)議(Real-time Transport Protocol,RTP)。RTP是專門為交互式音頻、視頻、仿真數(shù)據(jù)等實時媒體應用而設(shè)計的輕型傳輸協(xié)議,已廣泛應用于各種多媒體傳輸系統(tǒng)中。IP電話作為一種新興業(yè)務,因其低廉的話費受到廣大用戶的歡迎。但IP電話中的通話時延、話音失真一直是制約IP電話迅速發(fā)展的“瓶頸”。如何確保IP電話的QoS,是IP電話成功與否的關(guān)鍵。
RTP是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議,被定義為在一對一或一對多的傳輸情況下工作,其目的是提供時間信息和實現(xiàn)流同步。RTP通常使用用戶數(shù)據(jù)報協(xié)議(User
Datagram Protocol,UDP)來傳送數(shù)據(jù),但RTP也可以在傳輸控制協(xié)議(Transmission Control Protocol,TCP)或異步傳輸模式(Asynchronous
Transfer Mode,ATM)等其他協(xié)議之上工作。當應用程序開始一個RTP會話時將使用2個端口:1個給RTP,1個給RTCP。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制,也不提供流量控制或擁塞控制,它依靠RTCP提供這些服務。通常RTP算法并不作為一個獨立的網(wǎng)絡(luò)層來實現(xiàn),而是作為應用程序代碼的一部分,RTCP和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間,參與者周期性地傳送RTCP包,RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料,因此,服務器可以利用這些信息動態(tài)地改變傳輸速率,甚至改變有效載荷類型。RTP和RTCP配合使用能以有效的反饋和最小的開銷使傳輸效率最佳化,因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。
分組語音網(wǎng)絡(luò)中的延遲可分為固定延遲和可變延遲。前者相對容易得到,筆者不作考慮。在計算丟包率時,主要考慮可變延遲。丟包判定等待時限Twait設(shè)定的大小在很大程度上影響丟包率計算的準確性,也就是可變延遲的影響,它與語音包的傳輸延遲Ttrf有關(guān),Twait越大等待時限就越長。但不能超過保證語音流連續(xù)播放的時間上限Tmax(Tmax一般取250
ms),即:Twait=min(Twait,Tmax)。Ttrf可根據(jù)RTCP協(xié)議的SR控制包中的NTP(Network Time Protoco1)時間戳計算得到,見圖2。