轉載自:http://if.ustc.edu.cn/~zhouwei/backup/tech/linux/translator/rtpfaq.html
RTP協議有傳輸層協議的許多特性:它運行在端到端系統中,并且提供雙工服務。但是它和象TCP協議一樣的傳輸層協議不一樣,它并不提供任何的可靠性或者錯誤恢復和流量控制機制。但是,它卻為實現這樣的控制協議提供了接口,有點象應用層窗體的屬性,具體參加D.Clark和D.Tennenhouse的"Architectural consideration for a new generation of protocols", SIGCOMM'90, Philadelpia。雖然現在大多數的RTP實現都是作為應用程序,但是這和它的定位無關。TCP的實現如果作為應用程序的一部分而不是操作系統內核,它還是一個傳輸層協議。
RTP不能保證實時傳輸,那為什么還叫real-time protocol呢?
沒有任何一種端到端協議,包括RTP,都不能提供完全的實時服務。這還需要底層的設備如路由器和交換機對資源的控制。RTP提供了一些特性以適合攜帶實時數據,如時間戳、同步機制等。
RTP是可靠的嗎?RTP中提供什么樣的機制用于錯誤恢復?
就現在的定義,RTP還沒有提供恢復錯誤的機制,這樣的機制依賴于所攜帶的數據。比如,對于語音數據,就需要對低low-bit-rate數據進行較多的緩存,而對于其他數據,則更多的需要重傳(H.261 RTP載荷提供了這樣的機制)。RTP可能可以提供一些可能的首部信息如序列號來實現重傳的錯誤恢復機制。
當然可以。RTP與底層沒有什么關系,除非底層提供了分幀。RTP沒有網絡層的地址,所以當地址改變的時候是影響不到RTP的,而其他的底層提供的服務如安全或者QoS保證則可以由使用RTP的應用程序使用。現在已經有直接運行在AAL5的RTP實現了,還有對AAL2和AAL5運載RTP載荷的規范。有一點需要指出的是,RTCP中的CNAME域現在是基于沒有臺主機都有一個因特網形式的域名的假設上的。
在異步傳輸網絡中,一般來說,從用戶到因特網的帶寬是要明顯小于從因特網到用戶的帶寬的。這些網絡包括ADSL、Cable Modem還有衛星網絡。RTP協議需要在發送者發送了RTCP控制消息以后才可以使用,RTCP消息允許媒體之間進行內容同步。
RTP沒有長度域,也就是說分片是由下層協議來進行,并且一個PDU只能夠攜帶一個RTP分組,非常典型的下層協議就是UDP或者AAL5,因為現在很多的應用程序都不需要分幀,可以想象加入這點特性對于處理和帶寬是一個浪費,具體可以參閱RTP規范的RTP over Network and Transport Protocols。如果RTP使用的不是基于消息的協議或者需要攜帶幾個RTP分組在一個PDU中,則需要定義一個16位或者32位bit的長度域,由載荷和字節對齊來共同決定。
有些實現假設語音分組有固定的封裝包的間隔,如20ms,但是這是錯誤的,RFC1890建議可以使用固定的值作為默認參數,但是具體的實現必須能夠處理所有的情況。G.711和其他基于采樣協議的格式就在一個單位中有不同的時間。盡管使用123采樣的G.711的RTP包是合法的,但是還需要進行適當的處理。
周期性的就有人提出一個將12字節的首部長度域縮減到"RTP lite"版本,他們的依據是在一些通信特別是語音中根本不需要這樣多的域,而這些通信傳遞的都是小分組,對于長度的變化是非常敏感的。
一般的講,最完美的壓縮就是將IP/UDP/RTP的40字節壓縮到1到2個字節,但是,這只有在單鏈路的時延小的連接中使用。
在大范圍的互聯中,如PBX互聯,RTP混用更加的高效,因為它避免了IP和UDP報文頭,還有RTP頭的長度,此時,每個channel只需要一到兩個字節,而平常需要幾十個channels。
一個最小版本的RTP包括一個序列號(SN)和載荷類型(PT),兩個字節。但是,這樣的選擇有下面一些缺點:
- 沒有了SSRC域,則不能選擇合適的混和器和轉換器
- 對于頭標的減少是有限的,如G.723.1分組,帶有20字節語音分組的數據可以從60字節壓縮到50字節,單這也只有因特網兩個月的增長量
- 在組播中,由于沒有SSRC,報文會被丟棄,H.323族中也是如此
- H.245和SDP用來對附加的RTP格式進行協商
- 不是每一個設備都支持兩種長度的RTP報文,需要網關進行轉換
- 由于沒有時間戳,媒體中間的同步變得非常的困難,無聲的丟棄報文比頭標壓縮更能夠節省帶寬
- 許多RTCP的功能需要重新定義,由于它是基于時間戳和序列號來進行抖動計算、誤差統計和同步的。
由于底層傳輸單位定義了報文的結尾,應用程序一般都可以定位到最后一個字節并知道可以填充多少字節。
對于語音來講,時間戳是封包間隔和采樣速率的乘積的遞增的,比如,如果封包時間是20ms,而采樣率是8000Hz,則每一塊的時間戳遞增是160,即使由于某些原因包被丟棄,另外要注意的是,真實的采樣速率和預定的速率有一些小的變化,但是發送著一般沒有可靠的辦法察覺這些區別。
對于視頻來說,時間戳的生成依賴于應用程序是否能夠分辯其幀數。如果能夠分辯幀速率,則時間戳可以使用一個固定的速率增加,如對于30f/s的視頻,時間戳就每一幀增加3000,而對于25f/s的視頻就增加3600f/s,如果一個幀被幾個RTP包攜帶,則這些包應該有相同的時間戳。而如果應用程序并不能夠識別幀數或者采樣是變化的,現在很多編碼器都是這樣做的,那么時間戳就必須由系統時鐘來獲得,如gettimeofday()。
不,初始化的時間戳值是隨即選取的,而且每一個RTP流應該無關(對于相互獨立的程序生成的不同的媒體類型,不管是否在一臺主機上,這都是或多或少難以避免的)。不同媒體間的同步(如嘴唇同步)是通過RTCP報告中的NTP時間戳來實現的。這個時間戳提供了一個公共的參照把媒體指定的時間戳和墻上時間聯系起來。而這種同步機制并不是在RTP定義的,盡管如此,一個可能的處理是定期的交換所有的時延信息然后由應用程序來選擇一個最大的時延如果沒有同步的話。
時間戳是用來把接收到的語音和視頻數據按照正確的時間順序提交給上層,而序列號主要是用來檢查包的丟失。序列號是遞增的,而時間戳則遞增一個所攜帶報文的時間,對于視頻來說,一幀被分割成好幾個RTP包,則這些包具有相同的時間戳。對于某些情況,如攜帶DTMF(RFC 2833)數據,RTP時間戳可能是不會變化的。
RFC 1889 定義了一個在RTP報文首部中的媒體時鐘,還有一個由RTCP時間戳攜帶的從此時戳到全局定位時鐘的映射。
SR中的NTP時戳則可以在一個會話中同步所有的每天發送者,如果來自相同的網絡源,這顯然不是問題,而接受者要同步發送者,唯一的方法只有廣播。
經驗表明:所有其他的交互媒體和交互主機之間的同步,常常要次于NTP和應用規范。
對于語音分組,標記比特可以用來指示一個語音流的開始。在開始的時候,如果發現不同的時鐘或者網絡延時的變化,可以比較容易檢查出來。中間的分組則最好能夠連續發送,而對于前面的短暫的時延是不太敏感的。
標記比特指示一個指示,如果時鐘速率是已知的話,對話的開頭還可以通過比較兩個分組時間戳和序列號的不同來獲得的。
分組可能不是按照順序到達的,所以含有標記比特的分組比其他分組后到,只要分組延時超過重排序的時間,那么接受者就可以適應這種延時。如果不是的話,那么就只有簡單的等待下一個會話了。
這些對于丟包計算沒有作用,序列號是完成這個任務的。它們只是用來統計發送端的包速率和字節速率。
RTP時戳和NTP時戳結合在一起用來識別一個流中的絕對時間。比如,如果RTCP源端報告中包含RTP時戳 1234和NTP時戳 February 3, 10:14:15,就表示采樣1234發生在February 3, 10:14:15。
如果有幾個分組攜帶著同樣的時間戳(如視頻幀),應該使用第一個分組來計算抖動(這可能會在以后的發行中規范)。
抖動是通過時戳來計算的,如,音頻流的采樣率是8000Hz,到達的時間就會乘以8000。
首先,它不是鏈路帶寬,它不是一個比例關系的,即使只有5%的帶寬用于RTCP,大量的會話也會將鏈路占滿。其次,鏈路帶寬的定義在不同的網絡中是有不同的定義的。
會話帶寬是指普通的數據帶寬乘以IP、UDP和RTP首部(40字節)。比如,對于一個64Kb/s的PCM編碼語音,以20ms遞增,則會話帶寬就是(160+40)/0.02 B/s即80Kb/s,如果有多個發送端,則需要把每一個單獨相加起來。
因為發送RTCP的代價需要最小(大概5秒鐘一個包),即使對于端到端的連接也是有影響的:
- 使用RTCP,通信雙方都知道對方接收音頻和視頻的情況;這是很重要的,因為,經常有由于網絡丟包、延時或者抖動而造成的質量下降。一個特別的例子是在呼叫技術支持的時候,技術支持人員可以在遠程獲得網絡的性能
- RTCP對于音頻流和視頻流的同步是必須的
- 對于音頻的無聲丟失,RTCP可以觀察到并指示
- SDES信息對于用戶接口是有用的
- 許多應用需要支持單播和組播,使得具體實現的附加復雜度為0。
動態載荷類型被定義在了RTP A/V配置中,不想靜態的載荷類型,動態載荷類型沒有被IANA所定義,它們在一個會話中將一種RTP載荷映射到音頻和視頻上,不同的成員可以使用不同的映射,但是一般都不常用。動態載荷類型的范圍是96到127,它們沒有在標準中被定義,包括:
- 會話描述象SDP(使用a:rtpmap參數),使用聲明和邀請(如SIP),比如 m=audio 12345 RTP/AVP/121 a=rtpmap:121 RT24
- 其他的信令協議(盡管如此,H.245好像沒有這樣的機制,至少在非ITU的協議中)
因為載荷類型的空間是有限的,只有常用的編碼才會定義一個靜態的類型,它們是被國際標準化組織定義的音頻或者視頻編碼標準,如ITU-T音頻編碼的G系列標準。RTP A/V配置定義了一組靜態載荷類型。
如果使用H.323或者其他的建立協議,可否忽略其中的PT(載荷類型)域?
一種應用程序不應該只是支持一種載荷類型,盡管是通過H.245或者其他協議協商的。新的機制應該有:
- 傳輸DTMF數據(RFC 2833)
- 適當的噪聲標明
- 使用冗余的數據進行錯誤恢復
- 可以對網絡情況進行估計
可以使用PT域來標注可能在應用中被忽略的特殊的分組,如果需要的話,需要保證兼容性。但是這個假設在應用程序忽略所有的PT域的時候是沒有作用的。
另外,在組播環境中,每一個發送端使用相同的載荷類型是不好的。
建議使用沒有混用的底層技術,如AAL5上的RTP,其PT域可以區分不同源發出的流,但其實這是一個不好的規范。一方面是因為不容易在一個單獨的流中使用不同的PT(見前面的問題),零位一方面也沒有必要,因為SSRC就是被設計成可以分別不同的源的。
RTP SSRC是用來標記不同的源的,也就是說,在一個會議中每一個發送者都有一個SSRC。對于不同的流媒體,如語音和視頻,對于不同的SSRC最好使用單獨的源來發送。但是在下列情況下是不合適的:
- 一個RTP混合器一般是結合所有的SSRCs,對于某些RTP會話和結合方法,這是合適的,如語音的混合。如果在一個會話中有不同的媒體,則SSRCs需要通過附加的信息來隔離不同的媒體,這將使問題變得復雜。如果不能使用相同的轉換器,則對于終端接收程序來說,也是很復雜的;
- 在同一個RTP會話中攜帶不同的媒體阻止了使用不同的網絡媒體和鏈路選路,對于同步的音頻或者視頻信號,可能并不需要選路等,但是難以想象一個媒體需要通過低速率低時延的有線線路和另外一個媒體能夠容忍長時延來獲得高的帶寬之間結合的情況;
- 在同一個RTP會話中攜帶不同的媒體阻止了對于一組媒體集合的接收,如音頻集合,而視頻超過了可用帶寬,這在單播的時候不是一個問題,因為發送者可以選擇類型,而在組播當中,這是應該注意的,因為可能有許多不同類型的接受者;
- 在同一個RTP會話中攜帶不同的媒體組織了接收端對于不同媒體之間的單獨處理;
- 如果使得SSRCs固定的話,對于組播是不合適的,因為某些組播沖突解決方案是需要更改SSRC的。
當然,每一個RTP會話中的參加者都有一個SSRC值,只要它們需要接收報告。
如果說只是把音頻和視頻下載下來回放的話,TCP是一個不錯的選擇。如果對于實時要求不是很高的話,具有大的緩沖和好的帶寬的TCP是一個不錯的選擇,如通過www點播,TCP還可以運行在如X.25這樣的網絡上,盡管有些語音或者視頻通信少量的損失都是不可接受的。
盡管如此,對于實時傳輸來說,象TCP或者其他的可靠性協議XTP都不適合用來做傳輸協議,主要有三個原因:
- 可靠性的協議并不適合用來傳輸對于時延很敏感的數據如實時語音或視頻等,當發送者發現包丟失并且重傳的時候,至少已經過了一個RTT的時間,而發送者要么必須等待重傳的數據,造成聲音的不連續或者不按照TCP協議而丟棄重發的數據,而標準的TCP實現都要求等待重發的數據并處理,所以延時不斷增加,這對于實時傳輸是不利的;
- TCP不支持組播;
- TCP擁塞控制機制是在發現丟包的時候減小窗口,而對于語音或者視頻來說,是不能夠突然減小速率來餓死接受者的,比如對于PCM編碼的語音數據來說,是不會超過64kb/s多少的。對于這些媒體的擁塞控制機制最好是更改編碼的比特率,比方說根據RTCP接收報告分組。
還有一個不利的地方是TCP和XTP相對UDP來說具有過多的首部開銷(TCP和XTP3.6是40字節,XTP4.0是32字節,而UDP是8字節),而且這些協議還不帶有接收端所需要的時間戳,所以它們不能夠代替RTP(這些協議不含有序列號,因為它假設不會發生丟包或者重復的情況)。
對于局域網來說,由于具有足夠的帶寬且只有極少量的錯誤,這個時候TCP就只是在恢復少量錯誤的時候有優勢,這并沒有什么作用,而且,TCP的競爭機制會限制源端的初始速率。
前面的小節中有許多相同的爭論。關于RTP和XTP的關系有許多討論,可能是由于它們都是屬于傳輸層的吧,盡管如此,兩者并不能夠互相代替。XTP是為了可靠或者不可靠的數據通信中設計一個可配置和傳輸的協議,而RTP并不包含任何可靠的機制(盡管可以添加)和象XTP那樣的流控機制,所以RTP不適合傳輸常規的需要保證可靠性的數據(TCP或XTP更加適合)。對實時傳輸來說,由于延時問題,重傳一般是禁止的,XTP也是這樣。還有,流控和擁塞控制對于實時傳輸來說都是不合適的,因為一般實時數據都有相對穩定的比特率,但是,要注意的是,RTP提供了對于變化比較大的比特率進行擁塞控制的機制,如調整編碼率等。
RTP沒有自己的承載協議,所以需要使用非面向連接的協議如UDP、TCP或者是面向連接的協議如XTP、ST-II、ATM(AAL3/4, AAL5)。一般的實時應用大多使用組播,比如一千多人的講座、報告,而面向連接的協議如XTP是難以適應這樣的規模的。
XTP不含有定時或者媒體類型信息,而這些是由RTP提供的,XTP也不含有象RTP那樣的直接反饋,所以需要從其他協議中獲取這些信息。看看現在使用XTP的實時傳輸實現,都在XTP和實時媒體之間加了一層象RTP數據一樣的信息。
由于RTCP含有絕對時間信息,所以一個記錄的會話是不容易直接使用移動時間的方法來重放的。一個想法就是將時間重組然后重放數據包。SDES信息和NOTE可以用來收集然后重生一個會話。NOTE SDES當它們可以修改的時候應該可以在合適的時間插入流中。
由于RTP(特別是數據部分)和應用程序是緊緊關聯的,所以內核的實現沒有什么意義。一些人已經實現了RTP和RTCP的庫。NeVoT, rtpdump, vat, rat 和 vic都含有可以修改的RTP和RTCP處理模塊,要注意的是它們還含有各自的許多代碼(還有其他的一些實現是依據老版本的RTP,不要用它們來作為開發)。
Java Media Framework (JMF),一個JAVA API,也支持RTP和RTCP。
現在還沒有對于RTP的標準的API。
版本1現在只是歷史意義了,應用程序不應該根據它來寫。而且RTP版本2和1也不兼容。如果你關注這個的話,可以從Internet draft中找一找版本1的定義。
沒有。
在RTP協議規范的端口分配中這樣說明的:
- RTP使用一個偶數的UDP端口,而RTCP則使用大一個端口的奇數端口;
- 應用程序可以使用任意的UDP端口對,如由應用程序分配并管理。之所以這樣,是因為對于多媒體來說,需要有多個協議運行在一個端口,而這在一些操作系統中是不允許的,所以沒有分配固定的端口;
- 5004和5005作為默認的端口對。如果應用程序沒有這樣的默認選擇的話可能需要明確的指定。選擇的端口超過5000是因為在UNIX系統中小于1024的端口是特權端口而1024到5000是由操作系統自動分配的。
組播實現使用下面的端口范圍:
Table 1.
開始端口 |
結束端口 |
應用 |
優先級 |
0 |
16383 |
未指定 |
最低 |
16384 |
32767 |
語音 |
最高 |
32768 |
49151 |
白板 |
中等 |
49152 |
65535 |
視頻 |
低 |
注意:當組播速率沒有超過路由器的配置的組播速率限制的時候,端口是沒有區別的。
當RTP使用H.323的協議框架的時候,由H.225來分配端口,如在SDP和SIP中,由會議的控制者來選擇端口。
每端選擇自己的源地址,也就是說,不會說Alice發送語音信息到5000端口,而Bob必須在5000端口接收數據。每端只需要簡單的告訴對方是在哪個端口監聽數據,如通過SDP。
RFC1889的第十章說道,在一個單播會話中,應用必須準備接收數據,控制一個端口對并且可以將數據發往另外一個節點。
注意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是被飛利浦公司注冊的。
沒有,如果路由器在會話建立的時候沒有對協議進行過問的話,那么是沒有辦法告訴路由器某個特定的包是RTP報文的。但是,如果路由器維持狀態的話,當發現序列號緩慢增加(如加1),或者UDP的端口為一對的時候,路由器還是可以概率的發現的。另外,報文的前兩個比特是不變的,用來標識RTP報文,還有,載荷類型一般也是不變的。
語音和視頻格式和編碼有:
- MPEG L3 G.711 G.722 G.723 G.723.1 G.726 G.728 G.729 H.261 H.263
- H.324 在POTS長傳輸Audio和Video,速率在20kb/s以下。
在ISDN上傳輸的標準有:
- H.221 視聽設備,從64到1920kb/s
- H.320 電路交換
- H.323 H.320在LAN中的傳輸
對于會議的控制,管理和數據交換,還有一些建議:
- T.120 一個簡單的可視化電話建議
- T.121 常用應用模板
- T.122 多點通信
- T.123 電話通信應用中的協議棧
- T.124 基本會議控制
- T.125 多點通信服務協議規范
- T.126 靜態圖象協議規范
- T.127 多點二進制文件傳輸協議
- mbus 對等媒體應用協議