售前電話
135-3656-7657
售前電話 : 135-3656-7657
釋放雙眼,帶上耳機,聽聽看~!
00:00
00:00
利用RTP可提供大量的實時業(yè)務(wù),特別是語聲業(yè)務(wù)和視頻業(yè)務(wù)。RTP主要應(yīng)用于在Internet上傳輸對時延敏感的業(yè)務(wù),使得這些業(yè)務(wù)的傳輸更具規(guī)律性和可預(yù)測性。
RTP可提供的功能包括:
打時截。在諸如Internet的分組網(wǎng)中,從發(fā)送端到接收端不同的時延通常導(dǎo)致到達目的地的分組“成堆”,也就是說,大量的分組兒乎一起到達,其間一會兒丟失分組,一會兒到達大量的分組,造成的結(jié)果就是時延抖動,從而達不到專用電路的傳輸質(zhì)量。在專用電路中,數(shù)據(jù)以固定的時延到達。RTP通過一個32比特域來解決此問題:此域用于標(biāo)識數(shù)據(jù)的時截值,并用-隨機標(biāo)識符產(chǎn)生第一個分組的時戳值。對后續(xù)的分組,按照已過去的“時鐘滴塔”數(shù)以線性方式增加時截值。
盡管此法并不能保證數(shù)據(jù)按時到達,但是當(dāng)此方案與接收端時延抖動緩沖區(qū)結(jié)合使用時,收到的數(shù)據(jù)至少能以發(fā)送端一樣的相對分組時延饋入接收應(yīng)用程序。接收端的時延緩沖區(qū)根據(jù)分組的時截值(由RTP發(fā))對來得太快的分組加上一些附加時延,從而平滑數(shù)據(jù)發(fā)送。
編序列號。太多數(shù)分組交換網(wǎng)允許同一數(shù)據(jù)流的分組在網(wǎng)中沿不同路徑傳輸,這樣很可能會出現(xiàn)到達接收端的分組順序與發(fā)送時的分組順序不一致。為解決此問題,RTP給第一個分組分配一個隨機序號,后續(xù)分組的序號按序遞增。這樣就允許接收端:(1)對收到的分組排序:(2)檢測丟失的分組。盡管RTP并沒有為丟失的分組提供重傳機制(事實上,實時或接近實時的數(shù)據(jù)傳送不允許重發(fā)),但是接收端至少知道語音流有間斷期。
發(fā)送監(jiān)控。RTP可通過與它關(guān)系密切的RTCP向語音流的發(fā)送端提供有用的反饋信息。RTCP定義了發(fā)送端記錄(SR)和接收端記錄(RR)分組,這些記錄分組所記錄的情況包括:到達時延間隔的抖動、丟失分組數(shù)、傳輸?shù)姆纸M和字節(jié)總數(shù),以及其他對診斷、監(jiān)控和糾正網(wǎng)絡(luò)錯誤等有用的數(shù)據(jù)。比如,當(dāng)端到端時延增加或抖動加劇,以至影響到聲音的保真度時,自適應(yīng)編碼器可能會產(chǎn)生即短又低質(zhì)的分組。
負(fù)載標(biāo)識。不僅對通過RTP傳送的語音數(shù)據(jù)要用正確的順序接收,而且要按編碼方法對其進行解碼,因此,RTP給每一個分組指配負(fù)載類型標(biāo)識符以標(biāo)識該分組所用的負(fù)載類型。RFC1890定義了語音和視頻信息的負(fù)載類型(用于語音或視頻的具體編解碼方式),其他的負(fù)載類型可由IETF定義或動態(tài)地由軟件定義。
ITU-T的RTP實現(xiàn)方案是將RTP和它所支持的應(yīng)用層高度集成,而不是將其作為單獨的協(xié)議層。因此,RTP更像支持應(yīng)用程序所要求的功能的“協(xié)議頓”。協(xié)議頓頭不支持的功能可由開發(fā)商自行增加,但這將引起多個供應(yīng)商的互操作性問題。
RTP和RTCP分組都不包括復(fù)用信息,因此應(yīng)沒法區(qū)分不同的數(shù)據(jù)流、但接收端可能同時收到來自不同地方的多個語音數(shù)據(jù)分組,他必須要將其區(qū)別開,所以RTP分組被封裝在UDP中,UDP本身封裝在IP中。UDP是不可靠傳輸層協(xié)議,它提供了端口號標(biāo)識,但沒有糾正錯誤的能力。
H.323協(xié)議與SIP之間的斗爭日趨激烈。H.323協(xié)議應(yīng)用得較早,而SIP得到了許多強有力的IP團體的支持。然而限制VoIP發(fā)展的因素,既不是H.323協(xié)議,也不是SIP,而是VoIP的服務(wù)質(zhì)量。