RTP協(xié)議有傳輸層協(xié)議的許多特性：它運(yùn)行在端到端系統(tǒng)中，并且提供雙工服務(wù)。但是它和象TCP協(xié)議一樣的傳輸層協(xié)議不一樣，它并不提供任何的可靠性或者錯(cuò)誤恢復(fù)和流量控制機(jī)制。但是，它卻為實(shí)現(xiàn)這樣的控制協(xié)議提供了接口，有點(diǎn)象應(yīng)用層窗體的屬性，具體參加D.Clark和D.Tennenhouse的"Architectural consideration for a new generation of protocols", SIGCOMM'90, Philadelpia。雖然現(xiàn)在大多數(shù)的RTP實(shí)現(xiàn)都是作為應(yīng)用程序，但是這和它的定位無關(guān)。TCP的實(shí)現(xiàn)如果作為應(yīng)用程序的一部分而不是操作系統(tǒng)內(nèi)核，它還是一個(gè)傳輸層協(xié)議。

當(dāng)然可以。RTP與底層沒有什么關(guān)系，除非底層提供了分幀。RTP沒有網(wǎng)絡(luò)層的地址，所以當(dāng)?shù)刂犯淖兊臅r(shí)候是影響不到RTP的，而其他的底層提供的服務(wù)如安全或者QoS保證則可以由使用RTP的應(yīng)用程序使用。現(xiàn)在已經(jīng)有直接運(yùn)行在AAL5的RTP實(shí)現(xiàn)了，還有對AAL2和AAL5運(yùn)載RTP載荷的規(guī)范。有一點(diǎn)需要指出的是，RTCP中的CNAME域現(xiàn)在是基于沒有臺主機(jī)都有一個(gè)因特網(wǎng)形式的域名的假設(shè)上的。

在異步傳輸網(wǎng)絡(luò)中，一般來說，從用戶到因特網(wǎng)的帶寬是要明顯小于從因特網(wǎng)到用戶的帶寬的。這些網(wǎng)絡(luò)包括ADSL、Cable Modem還有衛(wèi)星網(wǎng)絡(luò)。RTP協(xié)議需要在發(fā)送者發(fā)送了RTCP控制消息以后才可以使用，RTCP消息允許媒體之間進(jìn)行內(nèi)容同步。

RTP沒有長度域，也就是說分片是由下層協(xié)議來進(jìn)行，并且一個(gè)PDU只能夠攜帶一個(gè)RTP分組，非常典型的下層協(xié)議就是UDP或者AAL5，因?yàn)楝F(xiàn)在很多的應(yīng)用程序都不需要分幀，可以想象加入這點(diǎn)特性對于處理和帶寬是一個(gè)浪費(fèi)，具體可以參閱RTP規(guī)范的RTP over Network and Transport Protocols。如果RTP使用的不是基于消息的協(xié)議或者需要攜帶幾個(gè)RTP分組在一個(gè)PDU中，則需要定義一個(gè)16位或者32位bit的長度域，由載荷和字節(jié)對齊來共同決定。

有些實(shí)現(xiàn)假設(shè)語音分組有固定的封裝包的間隔，如20ms，但是這是錯(cuò)誤的，RFC1890建議可以使用固定的值作為默認(rèn)參數(shù)，但是具體的實(shí)現(xiàn)必須能夠處理所有的情況。G.711和其他基于采樣協(xié)議的格式就在一個(gè)單位中有不同的時(shí)間。盡管使用123采樣的G.711的RTP包是合法的，但是還需要進(jìn)行適當(dāng)?shù)奶幚怼?/p>

周期性的就有人提出一個(gè)將12字節(jié)的首部長度域縮減到"RTP lite"版本，他們的依據(jù)是在一些通信特別是語音中根本不需要這樣多的域，而這些通信傳遞的都是小分組，對于長度的變化是非常敏感的。

一般的講，最完美的壓縮就是將IP/UDP/RTP的40字節(jié)壓縮到1到2個(gè)字節(jié)，但是，這只有在單鏈路的時(shí)延小的連接中使用。

在大范圍的互聯(lián)中，如PBX互聯(lián)，RTP混用更加的高效，因?yàn)樗苊饬薎P和UDP報(bào)文頭，還有RTP頭的長度，此時(shí)，每個(gè)channel只需要一到兩個(gè)字節(jié)，而平常需要幾十個(gè)channels。

一個(gè)最小版本的RTP包括一個(gè)序列號(SN)和載荷類型(PT)，兩個(gè)字節(jié)。但是，這樣的選擇有下面一些缺點(diǎn)：

由于底層傳輸單位定義了報(bào)文的結(jié)尾，應(yīng)用程序一般都可以定位到最后一個(gè)字節(jié)并知道可以填充多少字節(jié)。

對于語音來講，時(shí)間戳是封包間隔和采樣速率的乘積的遞增的，比如，如果封包時(shí)間是20ms，而采樣率是8000Hz，則每一塊的時(shí)間戳遞增是160，即使由于某些原因包被丟棄，另外要注意的是，真實(shí)的采樣速率和預(yù)定的速率有一些小的變化，但是發(fā)送著一般沒有可靠的辦法察覺這些區(qū)別。

對于視頻來說，時(shí)間戳的生成依賴于應(yīng)用程序是否能夠分辯其幀數(shù)。如果能夠分辯幀速率，則時(shí)間戳可以使用一個(gè)固定的速率增加，如對于30f/s的視頻，時(shí)間戳就每一幀增加3000，而對于25f/s的視頻就增加3600f/s，如果一個(gè)幀被幾個(gè)RTP包攜帶，則這些包應(yīng)該有相同的時(shí)間戳。而如果應(yīng)用程序并不能夠識別幀數(shù)或者采樣是變化的，現(xiàn)在很多編碼器都是這樣做的，那么時(shí)間戳就必須由系統(tǒng)時(shí)鐘來獲得，如gettimeofday()。

不，初始化的時(shí)間戳值是隨即選取的，而且每一個(gè)RTP流應(yīng)該無關(guān)(對于相互獨(dú)立的程序生成的不同的媒體類型，不管是否在一臺主機(jī)上，這都是或多或少難以避免的)。不同媒體間的同步(如嘴唇同步)是通過RTCP報(bào)告中的NTP時(shí)間戳來實(shí)現(xiàn)的。這個(gè)時(shí)間戳提供了一個(gè)公共的參照把媒體指定的時(shí)間戳和墻上時(shí)間聯(lián)系起來。而這種同步機(jī)制并不是在RTP定義的，盡管如此，一個(gè)可能的處理是定期的交換所有的時(shí)延信息然后由應(yīng)用程序來選擇一個(gè)最大的時(shí)延如果沒有同步的話。

時(shí)間戳是用來把接收到的語音和視頻數(shù)據(jù)按照正確的時(shí)間順序提交給上層，而序列號主要是用來檢查包的丟失。序列號是遞增的，而時(shí)間戳則遞增一個(gè)所攜帶報(bào)文的時(shí)間，對于視頻來說，一幀被分割成好幾個(gè)RTP包，則這些包具有相同的時(shí)間戳。對于某些情況，如攜帶DTMF(RFC 2833)數(shù)據(jù)，RTP時(shí)間戳可能是不會變化的。

RFC 1889 定義了一個(gè)在RTP報(bào)文首部中的媒體時(shí)鐘，還有一個(gè)由RTCP時(shí)間戳攜帶的從此時(shí)戳到全局定位時(shí)鐘的映射。

SR中的NTP時(shí)戳則可以在一個(gè)會話中同步所有的每天發(fā)送者，如果來自相同的網(wǎng)絡(luò)源，這顯然不是問題，而接受者要同步發(fā)送者，唯一的方法只有廣播。

經(jīng)驗(yàn)表明：所有其他的交互媒體和交互主機(jī)之間的同步，常常要次于NTP和應(yīng)用規(guī)范。

對于語音分組，標(biāo)記比特可以用來指示一個(gè)語音流的開始。在開始的時(shí)候，如果發(fā)現(xiàn)不同的時(shí)鐘或者網(wǎng)絡(luò)延時(shí)的變化，可以比較容易檢查出來。中間的分組則最好能夠連續(xù)發(fā)送，而對于前面的短暫的時(shí)延是不太敏感的。

標(biāo)記比特指示一個(gè)指示，如果時(shí)鐘速率是已知的話，對話的開頭還可以通過比較兩個(gè)分組時(shí)間戳和序列號的不同來獲得的。

分組可能不是按照順序到達(dá)的，所以含有標(biāo)記比特的分組比其他分組后到，只要分組延時(shí)超過重排序的時(shí)間，那么接受者就可以適應(yīng)這種延時(shí)。如果不是的話，那么就只有簡單的等待下一個(gè)會話了。

這些對于丟包計(jì)算沒有作用，序列號是完成這個(gè)任務(wù)的。它們只是用來統(tǒng)計(jì)發(fā)送端的包速率和字節(jié)速率。

RTP時(shí)戳和NTP時(shí)戳結(jié)合在一起用來識別一個(gè)流中的絕對時(shí)間。比如，如果RTCP源端報(bào)告中包含RTP時(shí)戳 1234和NTP時(shí)戳 February 3, 10:14:15，就表示采樣1234發(fā)生在February 3, 10:14:15。

如果有幾個(gè)分組攜帶著同樣的時(shí)間戳(如視頻幀)，應(yīng)該使用第一個(gè)分組來計(jì)算抖動(dòng)(這可能會在以后的發(fā)行中規(guī)范)。

抖動(dòng)是通過時(shí)戳來計(jì)算的，如，音頻流的采樣率是8000Hz，到達(dá)的時(shí)間就會乘以8000。

首先，它不是鏈路帶寬，它不是一個(gè)比例關(guān)系的，即使只有5%的帶寬用于RTCP，大量的會話也會將鏈路占滿。其次，鏈路帶寬的定義在不同的網(wǎng)絡(luò)中是有不同的定義的。

會話帶寬是指普通的數(shù)據(jù)帶寬乘以IP、UDP和RTP首部(40字節(jié))。比如，對于一個(gè)64Kb/s的PCM編碼語音，以20ms遞增，則會話帶寬就是(160+40)/0.02 B/s即80Kb/s，如果有多個(gè)發(fā)送端，則需要把每一個(gè)單獨(dú)相加起來。

因?yàn)榘l(fā)送RTCP的代價(jià)需要最小(大概5秒鐘一個(gè)包)，即使對于端到端的連接也是有影響的：

可以看看 RFC1890 的描述。

如果需要知道現(xiàn)在RTP的載荷類型，可以查看由IANA維護(hù)的文件： http://www.iana.org/assignments/rtp-parameters.

動(dòng)態(tài)載荷類型被定義在了RTP A/V配置中，不想靜態(tài)的載荷類型，動(dòng)態(tài)載荷類型沒有被IANA所定義，它們在一個(gè)會話中將一種RTP載荷映射到音頻和視頻上，不同的成員可以使用不同的映射，但是一般都不常用。動(dòng)態(tài)載荷類型的范圍是96到127，它們沒有在標(biāo)準(zhǔn)中被定義，包括：

因?yàn)檩d荷類型的空間是有限的，只有常用的編碼才會定義一個(gè)靜態(tài)的類型，它們是被國際標(biāo)準(zhǔn)化組織定義的音頻或者視頻編碼標(biāo)準(zhǔn)，如ITU-T音頻編碼的G系列標(biāo)準(zhǔn)。RTP A/V配置定義了一組靜態(tài)載荷類型。

一種應(yīng)用程序不應(yīng)該只是支持一種載荷類型，盡管是通過H.245或者其他協(xié)議協(xié)商的。新的機(jī)制應(yīng)該有：

可以使用PT域來標(biāo)注可能在應(yīng)用中被忽略的特殊的分組，如果需要的話，需要保證兼容性。但是這個(gè)假設(shè)在應(yīng)用程序忽略所有的PT域的時(shí)候是沒有作用的。

另外，在組播環(huán)境中，每一個(gè)發(fā)送端使用相同的載荷類型是不好的。

建議使用沒有混用的底層技術(shù)，如AAL5上的RTP，其PT域可以區(qū)分不同源發(fā)出的流，但其實(shí)這是一個(gè)不好的規(guī)范。一方面是因?yàn)椴蝗菀自谝粋€(gè)單獨(dú)的流中使用不同的PT(見前面的問題)，零位一方面也沒有必要，因?yàn)镾SRC就是被設(shè)計(jì)成可以分別不同的源的。

RTP SSRC是用來標(biāo)記不同的源的，也就是說，在一個(gè)會議中每一個(gè)發(fā)送者都有一個(gè)SSRC。對于不同的流媒體，如語音和視頻，對于不同的SSRC最好使用單獨(dú)的源來發(fā)送。但是在下列情況下是不合適的：

當(dāng)然，每一個(gè)RTP會話中的參加者都有一個(gè)SSRC值，只要它們需要接收報(bào)告。

如果說只是把音頻和視頻下載下來回放的話，TCP是一個(gè)不錯(cuò)的選擇。如果對于實(shí)時(shí)要求不是很高的話，具有大的緩沖和好的帶寬的TCP是一個(gè)不錯(cuò)的選擇，如通過www點(diǎn)播，TCP還可以運(yùn)行在如X.25這樣的網(wǎng)絡(luò)上，盡管有些語音或者視頻通信少量的損失都是不可接受的。

盡管如此，對于實(shí)時(shí)傳輸來說，象TCP或者其他的可靠性協(xié)議XTP都不適合用來做傳輸協(xié)議，主要有三個(gè)原因：

還有一個(gè)不利的地方是TCP和XTP相對UDP來說具有過多的首部開銷(TCP和XTP3.6是40字節(jié)，XTP4.0是32字節(jié)，而UDP是8字節(jié))，而且這些協(xié)議還不帶有接收端所需要的時(shí)間戳，所以它們不能夠代替RTP（這些協(xié)議不含有序列號，因?yàn)樗僭O(shè)不會發(fā)生丟包或者重復(fù)的情況）。

對于局域網(wǎng)來說，由于具有足夠的帶寬且只有極少量的錯(cuò)誤，這個(gè)時(shí)候TCP就只是在恢復(fù)少量錯(cuò)誤的時(shí)候有優(yōu)勢，這并沒有什么作用，而且，TCP的競爭機(jī)制會限制源端的初始速率。

前面的小節(jié)中有許多相同的爭論。關(guān)于RTP和XTP的關(guān)系有許多討論，可能是由于它們都是屬于傳輸層的吧，盡管如此，兩者并不能夠互相代替。XTP是為了可靠或者不可靠的數(shù)據(jù)通信中設(shè)計(jì)一個(gè)可配置和傳輸?shù)膮f(xié)議，而RTP并不包含任何可靠的機(jī)制(盡管可以添加)和象XTP那樣的流控機(jī)制，所以RTP不適合傳輸常規(guī)的需要保證可靠性的數(shù)據(jù)(TCP或XTP更加適合)。對實(shí)時(shí)傳輸來說，由于延時(shí)問題，重傳一般是禁止的，XTP也是這樣。還有，流控和擁塞控制對于實(shí)時(shí)傳輸來說都是不合適的，因?yàn)橐话銓?shí)時(shí)數(shù)據(jù)都有相對穩(wěn)定的比特率，但是，要注意的是，RTP提供了對于變化比較大的比特率進(jìn)行擁塞控制的機(jī)制，如調(diào)整編碼率等。

RTP沒有自己的承載協(xié)議，所以需要使用非面向連接的協(xié)議如UDP、TCP或者是面向連接的協(xié)議如XTP、ST-II、ATM(AAL3/4, AAL5)。一般的實(shí)時(shí)應(yīng)用大多使用組播，比如一千多人的講座、報(bào)告，而面向連接的協(xié)議如XTP是難以適應(yīng)這樣的規(guī)模的。

XTP不含有定時(shí)或者媒體類型信息，而這些是由RTP提供的，XTP也不含有象RTP那樣的直接反饋，所以需要從其他協(xié)議中獲取這些信息。看看現(xiàn)在使用XTP的實(shí)時(shí)傳輸實(shí)現(xiàn)，都在XTP和實(shí)時(shí)媒體之間加了一層象RTP數(shù)據(jù)一樣的信息。

由于RTCP含有絕對時(shí)間信息，所以一個(gè)記錄的會話是不容易直接使用移動(dòng)時(shí)間的方法來重放的。一個(gè)想法就是將時(shí)間重組然后重放數(shù)據(jù)包。SDES信息和NOTE可以用來收集然后重生一個(gè)會話。NOTE SDES當(dāng)它們可以修改的時(shí)候應(yīng)該可以在合適的時(shí)間插入流中。

由于RTP(特別是數(shù)據(jù)部分)和應(yīng)用程序是緊緊關(guān)聯(lián)的，所以內(nèi)核的實(shí)現(xiàn)沒有什么意義。一些人已經(jīng)實(shí)現(xiàn)了RTP和RTCP的庫。NeVoT, rtpdump, vat, rat 和 vic都含有可以修改的RTP和RTCP處理模塊，要注意的是它們還含有各自的許多代碼(還有其他的一些實(shí)現(xiàn)是依據(jù)老版本的RTP，不要用它們來作為開發(fā))。

Java Media Framework (JMF)，一個(gè)JAVA API，也支持RTP和RTCP。

現(xiàn)在還沒有對于RTP的標(biāo)準(zhǔn)的API。

版本1現(xiàn)在只是歷史意義了，應(yīng)用程序不應(yīng)該根據(jù)它來寫。而且RTP版本2和1也不兼容。如果你關(guān)注這個(gè)的話，可以從Internet draft中找一找版本1的定義。

沒有。

在RTP協(xié)議規(guī)范的端口分配中這樣說明的：

組播實(shí)現(xiàn)使用下面的端口范圍：

注意：當(dāng)組播速率沒有超過路由器的配置的組播速率限制的時(shí)候，端口是沒有區(qū)別的。

當(dāng)RTP使用H.323的協(xié)議框架的時(shí)候，由H.225來分配端口，如在SDP和SIP中，由會議的控制者來選擇端口。

每端選擇自己的源地址，也就是說，不會說Alice發(fā)送語音信息到5000端口，而Bob必須在5000端口接收數(shù)據(jù)。每端只需要簡單的告訴對方是在哪個(gè)端口監(jiān)聽數(shù)據(jù)，如通過SDP。

RFC1889的第十章說道，在一個(gè)單播會話中，應(yīng)用必須準(zhǔn)備接收數(shù)據(jù)，控制一個(gè)端口對并且可以將數(shù)據(jù)發(fā)往另外一個(gè)節(jié)點(diǎn)。

注意SSRCs通常是不相同的。

端口使用： H.323 TCP 1720 H.235 TCP 大于1024

請參閱語音編碼部分。

許多舊的，高比特率的編解碼都是不受保護(hù)的，但是，G.723，G.729和GSM都受到了各種專利限制的。如 美國 4,752,956 專利是在GSM中使用的Digital speech coder with baseband residual coding modifies coding using short term fine structure speech data produced by analysers within encoder-multiplexers是被飛利浦公司注冊的。

沒有，如果路由器在會話建立的時(shí)候沒有對協(xié)議進(jìn)行過問的話，那么是沒有辦法告訴路由器某個(gè)特定的包是RTP報(bào)文的。但是，如果路由器維持狀態(tài)的話，當(dāng)發(fā)現(xiàn)序列號緩慢增加(如加1)，或者UDP的端口為一對的時(shí)候，路由器還是可以概率的發(fā)現(xiàn)的。另外，報(bào)文的前兩個(gè)比特是不變的，用來標(biāo)識RTP報(bào)文，還有，載荷類型一般也是不變的。

語音和視頻格式和編碼有：

在ISDN上傳輸?shù)臉?biāo)準(zhǔn)有：

對于會議的控制，管理和數(shù)據(jù)交換，還有一些建議：