国产精品国三级国产av,最新先锋资源网站在线观看

善于提問，勤于回答，你也是專家

問題已開啟 (普通問題)

請問什么是RTP協(xié)議？

提問者: aoshicanglong 提問時間: 2012-04-17

	我要回答：

	請先登錄或注冊再回答問題

更多 RTP 協(xié)議相關(guān)問題

• 空口協(xié)議棧中，數(shù)據(jù)的壓縮功能位于什么層 2020-06-15
• VOLTE中的RTP抖動問題怎么分析 2020-05-25
• 5G協(xié)議中經(jīng)常提到“如 TS 38.331 [3]”，這個在38.331中怎么尋找【3】呀？ 2020-02-25
• thuraya衛(wèi)星系統(tǒng)是否完全按照GRM_1協(xié)議做的 2020-01-21
• VOLTE測試中發(fā)現(xiàn)，鼎力軟件掉話上報原因RTP Inactivity，查看信令發(fā)現(xiàn)持續(xù)20s,RTP包單通，即IMS RTP SN and... 2019-11-25
• 你好，能否送5g核心網(wǎng)中文協(xié)議 2019-11-24
• 既然5GC云都是通用數(shù)據(jù)中心組成，它們又一張蜂窩網(wǎng)，說云，實(shí)質(zhì)又在地面，基本不存在供電難度。為什么不把5GNRA的基站再碎片化，將AAU（只含PHYL物理層低層協(xié)議，及射頻RF）放在鐵塔上，改由太陽能 2019-09-15
• 協(xié)議還能不能下載 2019-06-11

問題答案 ( 2 )

實(shí)時傳送協(xié)議（Real-time Transport Protocol或簡寫RTP）是一個網(wǎng)絡(luò)傳輸協(xié)議。
實(shí)時傳輸協(xié)議（RTP）為數(shù)據(jù)提供了具有實(shí)時特征的端對端傳送服務(wù)，如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或模擬數(shù)據(jù)。應(yīng)用程序通常在 UDP 上運(yùn)行 RTP 以便使用其多路結(jié)點(diǎn)和校驗(yàn)服務(wù)；這兩種協(xié)議都提供了傳輸層協(xié)議的功能。但是 RTP 可以與其它適合的底層網(wǎng)絡(luò)或傳輸協(xié)議一起使用。如果底層網(wǎng)絡(luò)提供組播方式，那么 RTP 可以使用該組播表傳輸數(shù)據(jù)到多個目的地。

RTP 本身并沒有提供按時發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實(shí)現(xiàn)這一過程。 RTP 并不保證傳送或防止無序傳送，也不確定底層網(wǎng)絡(luò)的可靠性。 RTP 實(shí)行有序傳送， RTP 中的序列號允許接收方重組發(fā)送方的包序列，同時序列號也能用于決定適當(dāng)?shù)陌恢�，例如：在視頻解碼中，就不需要順序解碼。

回答者： zhangshiqin 回答時間：2012-04-17 21:57

支持流媒體的協(xié)議多媒體應(yīng)用的一個顯著特點(diǎn)是數(shù)據(jù)量大,并且許多應(yīng)用對實(shí)時性要求比較高。傳統(tǒng)的TCP 協(xié)議是一個面向連接的協(xié)議,它的重傳機(jī)制和擁塞控制機(jī)制都是不適用于實(shí)時多媒體傳輸?shù)摹?span lang=EN-US>RTP 是一個應(yīng)用型的傳輸層協(xié)議,它并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制。RTP 位于UDP(User Datagram Protocol) 之上。UDP 雖然沒有TCP 那么可靠,并且無法保證實(shí)時業(yè)務(wù)的服務(wù)質(zhì)量,需要RTCP 實(shí)時監(jiān)控數(shù)據(jù)傳輸和服務(wù)質(zhì)量。但是,由于UDP 的傳輸時延低于TCP ,能與音頻和視頻很好地配合。因此,在實(shí)際應(yīng)用中,RTP/ RTCP/ UDP 用于音頻/ 視頻媒體,而TCP 用于數(shù)據(jù)和控制信令的傳輸。目前,支持流媒體傳輸?shù)膮f(xié)議主要有實(shí)時傳輸協(xié)議RTP( Real-Time Transport Protocol) 、實(shí)時傳輸控制協(xié)議RTCP(Real-Time Transport Control Protocol) 和實(shí)時流協(xié)議RTSP(Real-Time Streaming Protocol) 等。下面分別對這三種協(xié)議作簡要介紹。流媒體協(xié)議棧如圖1 所示。
圖1 流媒體協(xié)議棧

2．實(shí)時傳輸協(xié)議RTP（Real-Time Transport Protocol）：
RTP是針對Internet上多媒體數(shù)據(jù)流的一個傳輸協(xié)議, 由IETF(Internet工程任務(wù)組)作為RFC1889發(fā)布。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實(shí)現(xiàn)流同步。RTP的典型應(yīng)用建立在UDP上，但也可以在TCP或ATM等其他協(xié)議之上工作。RTP本身只保證實(shí)時數(shù)據(jù)的傳輸，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。

2.1 RTP工作機(jī)制
威脅多媒體數(shù)據(jù)傳輸?shù)囊粋€尖銳的問題就是不可預(yù)料數(shù)據(jù)到達(dá)時間。但是流媒體的傳輸是需要數(shù)據(jù)的適時的到達(dá)用以播放和回放。rtp協(xié)議就是提供了時間標(biāo)簽,序列號以及其它的結(jié)構(gòu)用于控制適時數(shù)據(jù)的流放。在流的概念中”時間標(biāo)簽”是最重要的信息。發(fā)送端依照即時的采樣在數(shù)據(jù)包里隱蔽的設(shè)置了時間標(biāo)簽。在接受端收到數(shù)據(jù)包后,就依照時間標(biāo)簽按照正確的速率恢復(fù)成原始的適時的數(shù)據(jù)。不同的媒體格式調(diào)時屬性是不一樣的。但是rtp本身并不負(fù)責(zé)同步，rtp只是傳輸層協(xié)議，為了簡化運(yùn)輸層處理，提高該層的效率。將部分運(yùn)輸層協(xié)議功能（比如流量控制）上移到應(yīng)用層完成。同步就是屬于應(yīng)用層協(xié)議完成的。它沒有運(yùn)輸層協(xié)議的完整功能，不提供任何機(jī)制來保證實(shí)時地傳輸數(shù)據(jù)，不支持資源預(yù)留，也不保證服務(wù)質(zhì)量。rtp報文甚至不包括長度和報文邊界的描述。同時rtp協(xié)議的數(shù)據(jù)報文和控制報文的使用相鄰的不同端口，這樣大大提高了協(xié)議的靈活性和處理的簡單性。
rtp協(xié)議和udp二者共同完成運(yùn)輸層協(xié)議功能。udp協(xié)議只是傳輸數(shù)據(jù)包，不管數(shù)據(jù)包傳輸?shù)臅r間順序。 rtp的協(xié)議數(shù)據(jù)單元是用udp分組來承載的。在承載rtp數(shù)據(jù)包的時候，有時候一幀數(shù)據(jù)被分割成幾個包具有相同的時間標(biāo)簽，則可以知道時間標(biāo)簽并不是必須的。而udp的多路復(fù)用讓rtp協(xié)議利用支持顯式的多點(diǎn)投遞，可以滿足多媒體會話的需求。
rtp協(xié)議雖然是傳輸層協(xié)議但是它沒有作為osi體系結(jié)構(gòu)中單獨(dú)的一層來實(shí)現(xiàn)。rtp協(xié)議通常根據(jù)一個具體的應(yīng)用來提供服務(wù)，rtp只提供協(xié)議框架，開發(fā)者可以根據(jù)應(yīng)用的具體要求對協(xié)議進(jìn)行充分的擴(kuò)展。

2.2 RTP協(xié)議的報文結(jié)構(gòu)
RTP頭格式如圖2所示：

開始12個八進(jìn)制出現(xiàn)在每個RTP包中，而CSRC標(biāo)識列表僅出現(xiàn)在混合器插入時。各段含義如下：
①版本（V）
2位，標(biāo)識RTP版本。

②填充標(biāo)識（P）
1位，如設(shè)置填充位，在包尾將包含附加填充字，它不屬于有效載荷。填充的最后一個八進(jìn)制包含應(yīng)該忽略的八進(jìn)制計數(shù)。某些加密算法需要固定大小的填充字，或?yàn)樵诘讓訁f(xié)議數(shù)據(jù)單元中攜帶幾個RTP包。

③擴(kuò)展（X）
1位，如設(shè)置擴(kuò)展位，固定頭后跟一個頭擴(kuò)展。

④CSRC計數(shù)（CC）
4位，CSRC計數(shù)包括緊接在固定頭后CSRC標(biāo)識符個數(shù)。

⑤標(biāo)記（M）
1位，標(biāo)記解釋由設(shè)置定義，目的在于允許重要事件在包流中標(biāo)記出來。設(shè)置可定義其他標(biāo)示位，或通過改變位數(shù)量來指定沒有標(biāo)記位。

⑥載荷類型（PT）
7位，記錄后面資料使用哪種 Codec ， receiver 端找出相應(yīng)的 decoder 解碼出來。

常用 types：

Payload Type	Codec
0	PCM μ -Law
8	PCM-A Law
9	G..722 audio codec
4	G..723 audio codec
15	G..728 audio codec
18	G..729 audio codec
34	G..763 audio codec
31	G..761 audio codec

⑦系列號
16位，系列號隨每個RTP數(shù)據(jù)包而增加1，由接收者用來探測包損失。系列號初值是隨機(jī)的，使對加密的文本攻擊更加困難。

⑧時標(biāo)
32位，時標(biāo)反映RTP數(shù)據(jù)包中第一個八進(jìn)制數(shù)的采樣時刻，采樣時刻必須從單調(diào)、線性增加的時鐘導(dǎo)出，以允許同步與抖動計算。時標(biāo)可以讓receiver端知道在正確的時間將資料播放出來。

由上圖可知，如果只有系列號，并不能完整按照順序的將data播放出來，因?yàn)槿绻?/span>data中間有一段是沒有資料的，只有系列號的話會造成錯誤，需搭配上讓它知道在哪個時間將data正確播放出來，如此我們才能播放出正確無誤的信息。

⑨SSRC
32位，SSRC段標(biāo)識同步源。此標(biāo)識不是隨機(jī)選擇的，目的在于使同一RTP包連接中沒有兩個同步源有相同的SSRC標(biāo)識。盡管多個源選擇同一個標(biāo)識的概率很低，所有RTP實(shí)現(xiàn)都必須探測并解決沖突。如源改變源傳輸?shù)刂�，也必須選擇一個新SSRC標(biāo)識以避免插入成環(huán)行源。

⑩CSRC列表
0到15項(xiàng)，每項(xiàng)32位。CSRC列表表示包內(nèi)的對載荷起作用的源。標(biāo)識數(shù)量由CC段給出。如超出15個作用源，也僅標(biāo)識15個。CSRC標(biāo)識由混合器插入，采用作用源的SSRC標(biāo)識。
見http://zhangjunhd.blog.51cto.com/113473/25481/

回答者： xhy1331 回答時間：2012-04-29 01:34

未找到滿意答案？

移動通信論壇，提供全面的通信資料、技術(shù)支持！

最新緊急招聘通信職位

熱點(diǎn)問題


聯(lián)系我們 - 問通信專家	Powered by MSCBSC 移動通信網(wǎng) © 2006 -