rfc3550（RTP協議） 翻譯

Network Working Group                                    H.Schulzrinne
Request for Comments: 3550                          Columbia University
Obsoletes: 1889                                       S. Casner
Category: Standards Track                           Packet Design
                                                                R. Frederick
                                                Blue Coat Systems Inc.
                                                           V. Jacobson
                                                        Packet Design
                                                            July 2003
RTP：即時應用程式傳輸協議
（RTP: A Transport Protocol for Real-Time Applications）備忘錄狀態       本文檔為網際網路社區提供了一個網際網路標準協議的詳細說明，它還需要進一步的討論和建議。請查閱目前的版本的“網際網路官方協議標準”（STD1）以得到本標準說明和這個協議的狀態。本備忘錄發布沒有限制。著作權公告       Copyright (C) The Internet Society (2003). All Rights Reserved.摘要       本備忘錄描述了RTP，即時傳輸協議。RTP提供端到端網路傳輸功能，它適用與傳輸即時資料的應用程式，比如 音頻，視頻或者類比資料穿越單播或多播網路服務。RTP沒有地址資源預約也不保證即時服務品質。通過一個控制協議（RTCP）資料轉送得到了加強。RTCP允許以一個隨大型多播網路伸縮的方式監視資料傳遞，並提供最低限度的控制和驗證功能。RTP和RTCP獨立於下面的傳輸層和網路層。本協議支援RTP層的轉寄站和混合器。       本備忘錄的大部分內容和已經廢棄的RFC1889是相同的，包格式並沒有改變，僅對協議如何使用的規則和演算法做少許改動。最大的改動是增強了可伸縮定時器的演算法，這個定時器是計算髮送RTCP包的時機，目的是在許多參與者同時加入到一個會話是以超過預期的速率將傳輸減到最少。 目錄1           介紹1．1              術語2                         RTP使用說明2．1              簡單多播音訊會議2．2              音頻和視頻會議2．3              混合器和轉寄站2．4              分層編碼3                         定義4                         位元組序，校正和時間格式5                         RTP資料轉送協議5．1              RTP固定分組頭5．2              多工RTP會話5．3              變更RTP頭的概述5．3．1            RTP頭擴充6                         RTP控制協議————RTCP6．1              RTCP包格式6．2              RTCP傳輸時間間隔6．2．1 維持會話成員數量       6．3       RTCP包發送和接收規則       6．3．1 計算RTCP傳輸時間間隔       6．3．2 初始化       6．3．3 接收一個RTP 或者 Non-BYE RTCP 包       6．3．4 接收一個RTP BYE包       6．3．5 逾時SSRC       6．3．6 傳輸定時器的截止       6．3．7 發送一個 BYE 包       6．3．8 更新 we-sent       6．3．9 指定資源描述頻寬6．4       發送方和接收方通告       6．4．1 SR：發送方通告RTCP包       6．4．2 RR：接收方通告RTCP包       6．4．3 擴充發送方和接收方通告       6．4．4 分析發送方和接收方通告6．5 SDES：資源描述RTCP包       6．5．1 CNAME：規範的終端標示符 SDES 條款       6．5．2 NAME：使用者名稱稱 SDES條款       6．5．3 EMAIL：電子郵件地址 SDES條款       6．5．4 PHONE：電話號碼 SDES條款       6．5．5 LOC：地理位置 SDES 條款       6．5．6 TOOL：應用程式或工具名稱 SDES條款       6．5．7 NOTE：通知/狀態 SDES 條款       6．5．8 PRV：私人擴充 SDES 條款6．6       BYE：再見 RTCP 包6．7       APP：應用程式定義RTCP包7     RTP 轉寄站和混合器       7．1       概述       7．2       在轉寄站中的RTCP資料處理       7．2       在混合器中的RTCP資料處理       7．3       級聯混合器8     SSRC 標示符分配和使用       8．1       衝突的可能性       8．2       衝突解決和迴圈檢測       8．3       使用分層編碼9     安全       9．1       機密性       9．2       身分識別驗證和資訊完整10    阻塞控制11    網路和傳輸協議之上的RTP12    協議常量概述       12．1     RTCP 包類型       12．2     SDES 類型13    RTP 概況和淨荷格式詳細說明14    安全考慮15    IANA考慮16    智慧財產權描述17    感謝附錄A。演算法附錄A。1      RTP資料頭校正附錄A。2      RTCP資料頭校正附錄A。3      確定期望報數和丟失包數附錄A。4      產生RTCP SDES 包附錄A。5      解析RTCP SDES 包附錄A。6      產生一個隨即32位標示符附錄A。7      計算RTCP傳輸時間間隔附錄A。8     估計兩次時間間隔的抖動附錄B           與RFC1889的不同引用標準引用資料引用作者地址著作權描述  1 介紹       本備忘錄詳細規定了即時傳輸協議（RTP），它為某些類型的資料提供了端到端的傳輸服務。這些資料具有即時屬性，比如互動音頻和視頻。這些服務包括淨荷類型標示，順序號，時間戳記，和傳遞監視。典型情況下，應用程式在UDP上運行RTP，通過利用UDP的多路傳輸和校正服務；這兩個協議到提供了傳輸協議的功能，但是RTP應該與其他下層的網路或傳輸協議共同使用（見11節）。如果下層網路提供了多播，那麼RTP支援資料的多目的傳輸。       需要注意的是RTP本身並不提供任何機制來保證及時傳送或其他服務品質保證。而是依靠下層服務做到這一點，它不能提供可靠傳輸或預防失序傳遞。也不假定下層網路是可靠的或是以序傳遞包的。例如在視頻編碼裡，編碼包的順序並不是必須的。       RTP主要用於滿足多使用者多媒體會議需要，但它並不局限與此。連續資料存放區，互動的分布式類比，主動標記，和控制，測量應用程式，也有RTP的一席之地。       本文檔定義了RTP，由緊密相連的兩部分組成1 即時傳輸協議（RTP），傳輸具有即時屬性的資料2 RTP控制協議（RTCP），監視服務品質和傳遞下一個會話中的參與者資訊。後一方面對於鬆散控制會話可能已經足夠了，例如在沒有顯式的成員資格控制和建立的地方，它並不是必須支援一個應用程式控制通訊的所有需求。這些功能可能被全部或部分地包含在一個單獨的會話控制協議，對它的討論已經超出了本文檔的範圍。隨著由Clark 和Tennenhouse提議的應用程式層架構和綜合層處理原則，RTP表現出一種新的協議形式。那就是說，RTP計劃有伸縮性地由一個特殊應用程式來提供所需要的資訊並且經常被綜合進應用程式處理中而不是作為一個分開的層來實現。RTP僅是一個不完整的協議架構，這個文檔詳細說明的這些功能對所有適用RTP的應用程式來說都是通用的。在一些常規的協議裡，附加的功能可能通過使協議更通用或添加需要解析的選項機制來調節，與它們不同，RTP通過修改或添加需要的協議頭來達到預期的裁剪。例子在5。3和6。4。3中給出。因此，除這篇文檔之外，一個完整的RTP詳細說明還需要一個或更多的協作文檔（見13節）一個概要的說明文檔，它定義了一系列的淨荷類型代碼和他們到淨荷格式的影射（例如，多媒體編碼）。也可能定義一些對RTP的擴充和修改並在一個特別的應用程式類裡得到了明確。典型情況下一個應用程式僅遵照一個概要。一個對音頻和視頻資料的說明可以在RFC3551 中找到。淨載格式詳細說明文檔，它定義了一個獨特的淨載，例如一個音頻或視頻編碼，在RTP中是如何被運載的。關於即時服務和演算法的實現的討論以及一些RTP設計決議的背景討論可以在 [11] 中找到。1．1              術語本文檔中的關鍵字 “MUST” “MUST NOT” “REQUIRED” “SHALL” “SHALL NOT”, “SHOULD” “SHOULD NOT” “RECOMMENED” “MAY” AND “OPTICAL”將在BCF14，RFC2119中給出描述性解析。並指出了相應的RTP實現的需求。2                         RTP 使用說明書隨後的章節描述了使用RTP的一些方面。所選擇的例子是示範使用RTP的應用程式的基本操作，不要因此而限制了RTP 的使用範圍。在這些例子中， RTP加上了IP和UDP頭部，並遵從RFC3551的約定。 2．2 音視頻會議       如果音頻和視頻同時應用到一個會議，他們被作為分離的RTP會話來傳遞。那就是說，對一個媒體的RTP包和RTCP包用兩個不同的UDP連接埠對或多播地址來傳輸。音頻和視頻會話之間並不存在RTP層的直接耦合，除非參與到兩個會話的一個使用者在兩者的RTCP包中使用了相同的規範的名字，以便於是兩個會話聯絡起來。       對這種分離機制的一個動機是為了允許會話中的一些參與者接收到自己所選擇的一種媒體。進一步的解釋在5。2節中給出。經管同源的音頻和視頻是分開的，利用兩個會話的RTCP包裡的時間資訊，也能達到同步回放。2．3 混頻器 和 轉換器       迄今為止，我們一直假設所有的地點都想接收相同格式的媒體資料。但是，這一點並不總是適當的。想象一下，一個地區的參與者通過一個低速連結 串連到高速網路會議上。代替強迫每個人都使用一個較低的頻寬（音頻編碼品質下降），一個叫做混頻器的RTP級的中繼器可以放在低頻寬地區的附近。這個混頻器再次同步接收到的音頻包來重構這個由寄件者產生的連續的20毫秒間隔，把這些重構的音頻流混合到一個單獨的流。轉換這個音頻編碼到一個低頻寬編碼並把這個低頻寬包流推向前，穿過這個低頻寬連結。這些包可能單播到一個單獨的接收者，或在一個不同的地址上多播到多個接收者。這個RTP頭包括了混合器的標誌來表明該資源是混合的以便把正確的談話者指示提供給接收者。       音訊會議中的一些參與者可能採用了高頻寬接入，但是卻不能通過 IP 多播直接到達。比如， 他們很可能在一個應用程式級的防火牆的後面， 而這個防火牆不讓任何IP 包通過。對這些地點來說，混合也許不是必需的，而另一種RTP級的中繼稱為轉換器的就派上了用場。兩個轉換器分別被安裝在防火牆的兩邊， 外面的哪個把通過一個安全連線接收的全部多播包灌進防火牆。而在內側的轉換器把它們作為多播包再次發送到一個特定的多播組，該多播組被限制在該地點的內部網路。       混合器和轉換器可以用於各種各樣的用途。一個例子是一個視頻混合器測量分開的視頻流裡的個別人的圖象然後把它們合成到一個視頻流中來類比一組景物。其他關於傳輸的例子包括串連一組IP/UDP主機到一組ST—II 主機，或者來自分開源的視頻流不需要再同步或混合而一個包接一個包的傳輸。混合器和轉換器的操作細節在 7 節中給出。2．4              分層編碼多媒體應用程式應該能夠調節傳輸速率來匹配接收容量或者適應網路阻塞。許多實現把速率適應的責任放在源端。但是由於不同接收者對頻寬需求的衝突，它在多播傳輸時並不能工作的很好。這經常導致最小公分母方案，即用網格中的最小管道來規定全部多媒體傳輸的品質和逼真度。相反，可以聯合分層編碼和分層傳輸系統來把速率適應的責任放在接收端。在IP多播之上的RTP上下文中，源能夠把一個分級描述訊號的層分成條狀穿過多重會話，每個會話運載它自己的多播組。 接收方通過僅僅加入適當的多播組子集來適應網路非均勻性和控制接收頻寬。（這句看著頭暈，翻的不太準確）。RTP分層編碼的細節在 6。3。9 節和11 節中給出。