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

當(dāng)然可以。RTP與底層沒有什么關(guān)系，除非底層提供了分幀。RTP沒有網(wǎng)絡(luò)層的地址，所以當(dāng)?shù)刂犯淖兊臅r候是影響不到RTP的，而其他的底層提供的服務(wù)如安全或者QoS保證則可以由使用RTP的應(yīng)用程序使用。現(xiàn)在已經(jīng)有直接運行在AAL5的RTP實現(xiàn)了，還有對AAL2和AAL5運載RTP載荷的規(guī)范。有一點需要指出的是，RTCP中的CNAME域現(xiàn)在是基于沒有臺主機都有一個因特網(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消息允許媒體之間進行內(nèi)容同步。

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

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

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

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

在大范圍的互聯(lián)中，如PBX互聯(lián)，RTP混用更加的高效，因為它避免了IP和UDP報文頭，還有RTP頭的長度，此時，每個channel只需要一到兩個字節(jié)，而平常需要幾十個channels。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

抖動是通過時戳來計算的，如，音頻流的采樣率是8000Hz，到達的時間就會乘以8000。

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

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

因為發(fā)送RTCP的代價需要最小(大概5秒鐘一個包)，即使對于端到端的連接也是有影響的：

可以看看 RFC1890 的描述。

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

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

因為載荷類型的空間是有限的，只有常用的編碼才會定義一個靜態(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é)商的。新的機制應(yīng)該有：

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

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

建議使用沒有混用的底層技術(shù)，如AAL5上的RTP，其PT域可以區(qū)分不同源發(fā)出的流，但其實這是一個不好的規(guī)范。一方面是因為不容易在一個單獨的流中使用不同的PT(見前面的問題)，零位一方面也沒有必要，因為SSRC就是被設(shè)計成可以分別不同的源的。

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

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

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

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

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

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

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

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

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

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

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

Java Media Framework (JMF)，一個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)注這個的話，可以從Internet draft中找一找版本1的定義。

沒有。

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

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

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

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

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

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

注意SSRCs通常是不相同的。

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

請參閱語音編碼部分。

許多舊的，高比特率的編解碼都是不受保護的，但是，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是被飛利浦公司注冊的。

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

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

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

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