rfc3550-中文版
RTP：實時應用程序的傳輸協議
這份備忘錄的狀態
本文件規定了一個Internet標準跟蹤協議 互聯網社區，請求討論和建議 改進。請參閱當前版本的「Internet」 官方協議標準「（STD 1）的標準化狀態 和這個協議的狀態。這份備忘錄的分發是無限的。
版權聲明
版權全部（C）互聯網協會（2003）。版權全部。
抽象
這個備忘錄描述了實時傳輸協議RTP。RTP 提供適合的端到端網絡傳輸功能 應用程序傳輸實時數據，如音頻，視頻或 模擬數據，經過多播或單播網絡服務。RTP 不解決資源保留，不保證 實時服務的服務質量。數據傳輸是 由控制協議（RTCP）加強以容許監視 以可擴展到大型多播網絡的方式進行數據傳送， 提供最小的控制和識別功能。RTP和 RTCP被設計成獨立於底層傳輸和 網絡層。該協議支持使用RTP級別 和各類級別的混合翻譯。
大多數在這個備忘錄的文本是相同的RFC 1889，它 淘汰了。線路上的數據包格式沒有變化， 只改變了管理協議的規則和算法 用來。最大的變化是對可擴展定時器的加強 計算什麼時候發送RTCP數據包的算法 儘可能減小超過預期速率的傳輸 參與者同時加入會議。
Schulzrinne等人 標準跟蹤[頁1]
RFC 3550 RTP 2003年7月 目錄 1。簡介................................................ 4 1.1 術語............................................ 5 2。RTP使用場景.................................................. 5 2.1 簡單組播音頻會議.................................. 6 2.2 音視頻會議.................... ......... 7 2.3 混音器和翻譯器................................. 7 2.4 分層編碼...................................... 8 3。定義................................................. 8 4。字節順序，對齊方式和時間格式...................... 12 5。RTP數據傳輸協議.................................... 13 5.1 RTP固定標題字段...... ........................... 13 5.2 複用RTP會話................... ........... 16 5.3 對RTP頭的特定文件修改............ 18 5.3.1 RTP頭擴展............... ............. 18 6。RTP控制協議 - RTCP .................................. 19 6.1 RTCP數據包格式....... .............................. 21 6.2 RTCP傳輸間隔............................. 24 6.2.1 維護會話成員的人數....... 28 6.3 RTCP數據包發送和接收規則............................................................ 28 6.3.1 計算RTCP發送間隔.............................. 29 6.3.2 初始化.................................. 30 6.3.3 接收RTP或非BYE RTCP數據包... ...... 31 6.3.4 接收RTCP BYE包................................... 31 6.3.5 SSRC定時....... ....................... 32 6.3.6 發送定時器到期.................................. 32 6.3.7 發送BYE包...................... 。 33 6.3.8 更新we_sent ................................ 34 6.3.9 分配源說明帶寬的.. ... 34 6.4 發送者和接收者報告........................... 35 6.4.1 SR：發送者報告RTCP分組.. ................. 36 6.4.2 RR：接收報告RTCP包.................................. 42 6.4.3 擴展發送者和接收者報告....... 42 6.4.4 分析發送者和接收者報告............ 43 6.5 SDES：源描述RTCP數據包................ 45 6.5.1 CNAME：規範的終點標識符SDES項目。46 6.5.2 名稱：用戶名稱SDES項目........................................ 48 6.5.3 電子郵件：電子郵件地址SDES項目....... 。 48 6.5.4 電話：手機號碼SDES項目................... 49 6.5.5 LOC：地理用戶位置SDES項目......... 49 6.5.6 工具：應用程序或工具名稱SDES項目........................................ 49 6.5.7 注意：通知/狀態SDES項目................... 50 6.5.8 PRIV：專用擴展SDES項目........................................ 50 6.6 BYE：再見RTCP數據包................... ............ 51 6.7 APP：應用程序定義的RTCP數據包................... 52 7。RTP翻譯器和混音器.................................. 53 7.1 概述........ ........................... 53 Schulzrinne等人 標準跟蹤[第2頁]
RFC 3550 RTP 2003年7月 7.2 翻譯 器中的RTCP處理............................................................ 55 7.3混音器中的RTCP處理.................................... ................ 57 7.4 級聯攪拌器.............................. .......... 58 8。SSRC標識符的分配和使用........................... 59 8.1 碰撞機率.............. .................................... 59 8.2 碰撞分辨率和迴路檢測................................... 60 8.3 使用分層編碼.... ......................... 64 9。安全................................................. ... 65 9.1 保密........................................ 65 9.2 身份驗證和消息完整性... ................ 67 10。擁塞控制.......................................... 67 11。網絡和傳輸協議上的RTP .................... 68 12。協議常量摘要.............................. 69 12.1 RTCP包類型.......... ............................ 70 12.2 SDES類型.................. ........................... 70 13。RTP配置文件和有效負載格式規範.................................... 71 14。安全考慮.................................................. 73 15。IANA考慮............................................. 73 16。知識產權聲明.............................. 74 17。致謝............................................. 74 附錄A。算法........................................ 75 附錄A.1 RTP數據頭有效性檢查.................. 78 附錄A.2 RTCP報頭有效性檢查..................... .. 82 附錄A.3 預期和失落......包容量的肯定 83 附錄A.4 生成RTCP SDES數據包................................................ 84 附錄A.5 解析RTCP SDES數據包......... .............. 85 附錄A.6 生成隨機的32位標識符............. 85 附錄A.7 計算的RTCP發送間隔。 ......... 87 附錄A.8 估算間隔抖動................ 94 附錄B。RFC 1889的變化............................. 95 參考文獻............... ....................................... 100 規範性引用........ ....................................100 信息性參考.......................................... 100 做者的地址。 ............................................. 103 完整的版權聲明。 ....................................... 104 Schulzrinne等人 標準跟蹤[第3頁]
RFC 3550 RTP 2003年7月 。 本備忘錄規定了實時傳輸協議（RTP）， 爲實時數據提供端到端的交付服務 特色，如交互式音頻和視頻。那些服務 包括有效載荷類型標識，順序編號，時間戳 和交付監控。應用程序一般在其上運行RTP UDP來利用其複用和校驗和服務; 都 協議提供了傳輸協議功能的一部分。 可是，RTP能夠與其餘合適的底層網絡一塊兒使用 運輸協議（見第11節）。RTP支持數據傳輸 多個目的地使用多播分發，若是提供的 底層網絡。 請注意，RTP自己不提供任何機制來確保及時 交付或提供其餘服務質量保證，但依賴 在較低層的服務上這樣作。它不保證交付或 防止無序交付，也不假定其基礎 網絡是可靠的，並按順序發送數據包。序列 包含在RTP中的號碼容許接收機重建 發送者的數據包序列，可是也能夠使用序列號 肯定數據包的正確位置，例如在視頻中 解碼，而沒必要按順序解碼分組。 雖然RTP主要是爲了知足多用戶的需求而設計的， 參與者多媒體會議，但不限於此 特定的應用。連續數據存儲，交互式 分佈式仿真，主動式徽章以及控制和測量 應用程序也可能會發現RTP適用。 本文件定義了RTP，由兩個緊密相連的部分組成： o實時傳輸協議（RTP），用於傳輸具備的數據 實時屬性。 o RTP控制協議（RTCP），監視服務質量 並在進行中傳達有關參與者的信息 會話。RTCP的後一方面可能足以「鬆散」 控制「會議，即沒有明確的成員資格 控制和設置，但不必定打算支持 全部的應用程序的控制通訊要求。這個 功能可能徹底或部分納入單獨的 會話控制協議，這是超出了這個範圍 文件。 RTP表明遵循原則的新型協議 提出了應用級構架和集成層處理 Clark和Tennenhouse [ 10 ]。也就是說，RTP旨在具備延展性 Schulzrinne等人 標準跟蹤[第4頁]
RFC 3550 RTP 2003年7月 提供特定應用程序所需的信息 一般會被整合到應用程序處理中而不是 做爲一個單獨的層實現。RTP是一個協議框架 這是故意不完整的。這個文件指定了那些 預期在全部的應用程序中都有相同的功能 RTP將是適當的。不一樣於傳統的協議 經過制定協議可能會提供更多的功能 更通常的仍是經過增長一個須要的選擇機制 解析，RTP旨在經過修改和/或定製 根據須要添加標題。示例在章節中給出 5.3和6.4.3。 因此除了這個文件外，還有一個完整的規範 對於特定應用程序的RTP將須要一個或多個同伴 文件（見第13節）： o配置文件規範文件，它定義了一組有效載荷 類型代碼及其到有效載荷格式的映射（例如，媒體 編碼）。配置文件也能夠定義擴展或修改 到特定於特定類別的應用程序的RTP。 一般一個應用程序只能在一個配置文件下運行 一個 音頻和視頻數據的配置文件能夠在RFC 3551中找到 [ 1 ]。 o有效載荷格式規範文件，它定義了一個 特定的有效載荷，例如音頻或視頻編碼將是 在RTP中進行。 爲他們的實時服務和算法的討論 實施以及一些RTP的背景討論 設計決策能夠在[ 11 ]中找到。 術語 關鍵詞「必須」，「不得」，「須要」，「應該」，「不該該」， 「應該」，「不該該」，「推薦」，「可能」和「可選」 文件要按照BCP 14，RFC 2119 [ 2 ] 並指出符合RTP實施的要求級別。 。 如下部分描述了RTP使用的一些方面。該 例子被選來講明的基本操做 使用RTP的應用程序，而不是限制可能使用的RTP。在 這些例子，RTP是在IP和UDP之上進行的，並遵循 由指定的音頻和視頻配置文件創建的約定 在伴侶RFC 3551中。 Schulzrinne等人 標準跟蹤[第5頁]
RFC 3550 RTP 2003年7月 簡單的多播音頻會議 IETF的一個工做組開會討論最新的協議 文件，使用互聯網的IP多播服務進行語音 通訊。經過一些分配機制的工做組 主席得到一個組播組地址和一對端口。一個端口 用於音頻數據，另外一個用於控制（RTCP） 數據包。這個地址和端口信息被分配給 有意參加者。若是須要隱私，數據和控制在這種狀況下， 數據包能夠按9.1節的規定進行加密 還必須生成和分發加密密鑰。最正確 這些分配和分配機制的細節已經超出了 RTP的範圍。 每一個會議使用的音頻會議應用程序 參與者以例如20ms持續時間的小塊發送音頻數據。 每一個音頻數據塊以前都有一個RTP頭，RTP頭和 數據又被包含在UDP數據包中。RTP頭部表示 包含什麼類型的音頻編碼（如PCM，ADPCM或LPC） 在每一個數據包中，以便發件人能夠在一個過程當中更改編碼 會議，例如，以適應新的參與者 經過一個低帶寬的鏈路鏈接或反應的指示 網絡擁塞。 像其餘分組網絡同樣，互聯網偶爾也會失去 從新排序數據包並將其延遲不一樣的時間。至 應付這些損傷，RTP頭包含時間 信息和容許接收者的序列號 重建來源所產生的時間，以便在此 例如，大量的音頻是連續播放的揚聲器 每20毫秒。這個時間重建是分開進行的 會議中每一個RTP數據包的來源。序列號 也能夠被接收器用來估計有多少分組 正在失去。 因爲工做組成員在加入和離開期間 會議，知道誰在任什麼時候候參與是有用的 以及他們如何收到音頻數據。爲了這個目的， 會議中音頻應用程序的每一個實例週期性地 在RTCP上多播一個接收報告加上它的用戶名 （控制）端口。接待報告顯示目前狀況如何 揚聲器正在被接收，並可能被用來控制自適應 編碼。除了用戶名，其餘標識 信息也可能被包括在控制帶寬限制以內。 站點在離開時發送RTCP BYE數據包（第6.6節） 會議。 Schulzrinne等人 標準跟蹤[第6頁]
RFC 3550 RTP 2003年7月 音頻和視頻會議 若是音頻和視頻媒體在會議中使用，則是 做爲單獨的RTP會話傳輸。就是說，單獨的RTP和RTCP 使用兩個不一樣的UDP端口爲每一個介質傳輸數據包 配對和/或多播地址。在這裏沒有直接的聯結 音頻和視頻會話之間的RTP級別，除了用戶 參加這兩個會議應該使用相同的區分 （canonical）名稱在RTCP數據包中，以便進行會話 能夠關聯。 這種分離的一個動機是容許一些參與者 會議只收到一個媒體，若是他們選擇。進一步第5.2節 給出瞭解釋。儘管分離， 能夠實現源音視頻的同步播放 使用RTCP分組中攜帶的定時信息 會話。 混音器和翻譯器 到目前爲止，咱們已經假設全部網站都但願接收媒體數據 相同的格式。可是，這可能並不老是適當的。 考慮一個地區的參與者鏈接的狀況 經過低速連接到大部分會議 享受高速網絡接入的參與者。而不是強迫 每一個人都使用較低帶寬，質量較差的音頻編碼 稱爲混頻器的RTP級別的中繼器能夠放置在低帶寬附近 區。該混音器將傳入的音頻數據包從新同步到 重構發送器產生的恆定的20ms間隔，混合 這些重建的音頻流成一個單一的流，翻譯 將音頻編碼轉換爲較低帶寬的音頻， 經過低速鏈路的帶寬分組流。這些包 多是單播到單個接收者或多播在不一樣的 地址給多個收件人。RTP頭包含一個方法 混合器來識別形成混合數據包的來源 能夠在接收機處提供正確的講話者指示。 音頻會議中的一些預期參與者多是 鏈接高帶寬的連接，但可能不會直接 經過IP組播可達 例如，他們可能在一個後面 應用程序級防火牆不會讓任何IP數據包經過。 對於這些網站，混合可能不是必要的，在這種狀況下，另外一個 能夠使用稱爲翻譯器的RTP級中繼類型。二 翻譯器安裝在防火牆的兩側，一個 外部的一個經過a接收全部組播包 安全地鏈接到防火牆內的翻譯器。該 防火牆內部的轉換器將以組播數據包的形式再次發送 到一個限於該站點內部網絡的多播組。 Schulzrinne等人 標準跟蹤[第7頁]
RFC 3550 RTP 2003年7月 混音器和翻譯器能夠設計用於各類目的。一個 例如是一個縮放我的圖像的視頻混合器 在單獨的視頻流中，並將它們合成爲一個視頻流 模擬一個組景。其餘翻譯的例子包括 鏈接一組主機只說IP / UDP的一組主機 只理解ST-II的主機，或者逐包編碼 翻譯來自個別來源的視頻流 從新同步或混合。攪拌機的操做細節 譯文在第7部分給出。 分層編碼 多媒體應用程序應該可以調整傳輸 速率匹配接收器的容量或適應網絡 擁塞。許多實現都將速率 - 來源的適應性。這對多播不起做用 因爲帶寬需求的衝突傳輸 異構接收器。結果每每是最不常見的 分母場景，網絡中最小的管道網格 決定了整個現場多媒體的質量和保真度 「廣播」。 相反，速率適應的責任能夠放在這裏 接收器經過將分層編碼與分層傳輸相結合 系統。在RTP over IP組播的狀況下，源能夠 對分層表示的信號的漸進層進行條帶化 跨多個RTP會話，每一個會話都承載在本身的多播組上。 接收者能夠適應網絡異質性並控制它們 接收帶寬只經過加入適當的子集 多播組。 在分層編碼中使用RTP的細節在附錄中給出 第6.3.9，8.3和11。 。 RTP有效載荷：RTP在數據包中傳輸的數據 示例音頻樣本或壓縮視頻數據。有效載荷 格式和解釋超出了本文的範圍。 RTP包：由固定的RTP頭部組成的數據包， 多是空的清單的貢獻來源（見下文），和 淨荷數據。一些底層協議可能須要一個 封裝待定義的RTP包。一般是一個 底層協議的數據包包含單個RTP數據包， 可是若是容許，能夠包含幾個RTP包 封裝方法（見第11節）。 Schulzrinne等人 標準跟蹤[第8頁]
RFC 3550 RTP 2003年7月 RTCP數據包：一個由固定標題部分組成的控制數據包 相似於RTP數據包，其次是結構化的 元素根據RTCP數據包類型而變化。該 格式在第6節中定義。一般，多個RTCP 數據包做爲複合RTCP數據包一塊兒發送 底層協議的數據包; 這是由長度啓用 在每一個RTCP分組的固定報頭中。 端口：「傳輸協議使用的抽象 區分給定主機內的多個目的地 電腦。TCP / IP協議使用小正值來標識端口 整數「。[ 12 ] OSI使用的傳輸選擇器（TSEL） 傳輸層至關於端口。RTP取決於 下層協議提供一些機制如端口來 複用會話的RTP和RTCP數據包。 傳輸地址：網絡地址和端口的組合 標識傳輸級端點，例如IP 地址和一個UDP端口。數據包從源傳輸 傳輸地址到目的地傳輸地址。 RTP媒體類型：RTP媒體類型是有效載荷的集合 能夠在單個RTP會話中攜帶的類型。RTP 配置文件將RTP媒體類型分配給RTP有效內容類型。 多媒體會話：一組併發的RTP會話 共同參與者的小組。例如，一個視頻會議 （這是一個多媒體會話）可能包含一個音頻RTP會話 和一個視頻RTP會話。 RTP會話：一組參與者之間的關聯 與RTP進行通訊。參與者可能涉及多個 RTP會話。在多媒體會議中，每一個會議 媒體一般是在一個單獨的RTP會話中進行的 RTCP包，除非編碼自己多路複用 媒體轉換成單一的數據流。參與者區分 經過接收不一樣的會話使用多個RTP會話 不一樣的目標傳輸地址對，其中一對 的傳輸地址包括一個網絡地址加一對 用於RTP和RTCP的端口。RTP會話中的全部參與者均可以 共享一個共同的目的地傳輸地址對，如在這種狀況下 的IP組播，或者每對的配對可能不一樣 參與者，就像我的單播網絡同樣 地址和端口對。在單播狀況下，參與者能夠 從會議中的全部其餘參與者使用相同的方式接收 一對端口，或者能夠爲每一個端口使用一對不一樣的端口。 Schulzrinne等人 標準跟蹤[第9頁]
RFC 3550 RTP 2003年7月 RTP會話的顯着特色是每一個會話 保持SSRC標識符的完整，獨立空間（定義 下一個）。包括在一個RTP會話中的一組參與者 由那些能夠接收SSRC標識符傳輸的組成 由RTP中的任何一個參與者做爲SSRC或CSRC （也在下面定義）或RTCP。例如， 使用單播UDP實現第三方會議 參與者從另外兩個端口對分別接收。 若是每一個參與者發送有關從中接收的數據的RTCP反饋 另一個參與者只能回到那個參與者那裏 會議由三個獨立的點對點RTP組成 會話。若是每一個參與者提供有關RTCP的反饋 接收另外一個參與者給另外一個參與者 參與者，那麼這個會議就是由一個多方組成的 RTP會話。後一種狀況模擬了這種行爲 與三者之間的IP組播通訊發生 參與者。 RTP框架容許這裏定義的變化，可是a 一般特定的控制協議或應用程序設計 對這些變化施加限制。 同步源（SSRC）：RTP流的源 數據包，由一個32位數字SSRC標識符進行標識 RTP頭，以便不依賴於網絡地址。 全部來自同步源的數據包都是同一個數據包的一部分 定時和序列號空間，因此一個接收者按組來分組 用於播放的同步源。同步的例子 源包括從a派生的數據包流的發送者 信號源如麥克風或照相機，或RTP混頻器 （見下文）。同步源可能會更改其數據格式， 例如，音頻編碼，隨着時間的推移。SSRC標識符是 隨機選擇的價值意味着在全球範圍內獨一無二的 特定的RTP會話（參見第8節）。參與者不須要 對於a中的全部RTP會話使用相同的SSRC標識符 多媒體會議; SSRC標識符的綁定是 經過RTCP提供（見第6.5.1節）。若是是參與者 在一個RTP會話中產生多個流，例如來自 單獨的攝像機，每一個攝像機都必須被識別爲不一樣的攝像機 SSRC。 貢獻源（CSRC）：RTP數據包流的來源 這對RTP產生的合併流有貢獻 攪拌機（見下文）。混頻器插入一個SSRC列表 有助於生成a的源的標識符 特定的數據包放入該數據包的RTP頭中。這個清單 被稱爲中國證監會名單。一個示例應用程序是音頻 會議在哪裏混頻器指示全部講話者的講話 Schulzrinne等人 標準跟蹤[第10頁]
RFC 3550 RTP 2003年7月 被組合起來產生傳出包，容許接收者 表示當前的講話者，即便全部的音頻數據包 包含相同的SSRC標識符（混頻器的標識符）。 結束系統：生成要發送的內容的應用程序 在RTP分組中和/或消耗接收到的RTP的內容 數據包。終端系統能夠充當一個或多個同步 來源在特定的RTP會話中，但一般只有一個。 混音器：從中接收RTP數據包的中間系統 或更多的來源，可能會改變數據格式，結合起來 數據包，而後轉發一個新的RTP數據包。以來 多個輸入源之間的時間一般不會 同步，調音臺之間會進行定時調節 併爲合併的流生成本身的時間。 所以，來自混頻器的全部數據分組將被識別 做爲混音器做爲他們的同步源。 轉換器：轉發RTP數據包的中間系統 同步源標識符保持不變。示例 翻譯器包括轉換編碼而不混合的設備， 從多播到單播的複製器以及應用程序級別 過濾器在防火牆。 監視器：接收發送的RTCP數據包的應用程序 RTP會議的參與者，特別是接待 報告和估計目前的服務質量 分佈式監測，故障診斷和長期統計。 監視器功能可能被構建到應用程序中， 參加會議，但也多是單獨的 應用程序不參與，不發送 或接收RTP數據包（由於它們是分開的 港口）。這些被稱爲第三方監視器。也是 能夠接受第三方監視器接收RTP數據 數據包但不發送RTCP數據包或以其餘方式計入 會話。 非RTP意味着：可能須要的協議和機制 除了RTP提供可用的服務。特別是對於 多媒體會議，控制協議可能會分發 組播地址和密鑰進行加密，協商 要使用的加密算法，並定義動態映射 在RTP有效載荷類型值和它們的有效載荷格式之間 表明沒有預約義有效載荷類型的格式 值。這樣的協議的例子包括會話啓動 協議（SIP）（RFC 3261 [ 13 ]），ITU建議H.323 [ 14 ]和 應用程序使用SDP（RFC 2327 [ 15 ]），如RTSP（RFC 2326 [ 16 ]）。爲了簡單 Schulzrinne等人 標準跟蹤[第11頁]
RFC 3550 RTP 2003年7月 應用程序，電子郵件或會議數據庫也可能 用過的。這樣的協議和機制的規範是 超出了本文的範圍。 。 全部的整數字段都以網絡字節順序進行傳輸，也就是大部分 重要的字節（八位字節）首先。這個字節順序一般被稱爲 大端。傳輸順序在[ 3 ] 中詳細描述。 除非另有說明，不然數字常量以十進制表示（以10爲底）。 全部標題數據都對齊到其天然長度，即16位字段 在偶數偏移量上對齊，32位字段在偏移量上對齊 能夠被四整除等。指定爲填充的八位字節具備值 零。 Wallclock時間（絕對日期和時間）使用 網絡時間協議（NTP）的時間戳格式 秒，相對於1900年1月1日0時UTC [ 4 ]。完整的 分辨率NTP時間戳是一個64位無符號定點數字 在前32位的整數部分和小數部分 最後32位。在一些更緊湊的表明性領域 合適的，只使用中間的32位; 也就是最低的16 整數部分的位和小數部分的高16位。 必須肯定整數部分的高16位 獨立。 執行不須要運行網絡時間協議 爲了使用RTP。能夠使用其餘時間源，或根本沒有 （請參閱第6.4.1節中關於NTP時間戳字段的描述）。 可是，運行NTP可能對同步流有用 從不一樣的主機傳輸。 NTP時間戳將在一年中的某個時間回到零 2036，可是對於RTP的目的，只有NTP對之間的差別 時間戳被使用。只要時間戳對能夠 假定在68年以內，使用模塊化算術 對於減法和比較使得環繞無關。 Schulzrinne等人 標準跟蹤[第12頁]
RFC 3550 RTP 2003年7月 。 RTP固定標題字段 RTP頭有如下格式： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | V = 2 | P | X | CC | M | PT | 序號| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 時間戳| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 同步源（SSRC）標識符| + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | 來源（CSRC）標識符| | .... | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 前十二個八位字節出如今每一個RTP數據包中 CSRC標識符列表僅在由調音臺插入時出現。 這些字段具備如下含義： 版本（V）：2比特 該字段標識RTP的版本。版本定義 這個規範是兩個（2）。（值1被第一個使用 草案版本的RTP和值0被協議使用 最初是在「大桶」音頻工具中實現的。） 填充（P）：1位 若是填充位已設置，則數據包包含一個或多個 附加填充八位字節在不是的一部分 有效載荷。填充的最後八位字節包含如何計數 包括它自己在內的許多填充八位字節應該被忽略。填充 可能須要一些固定塊大小的加密算法 或者用於在較低層協議數據中攜帶多個RTP分組 單元。 擴展名（X）：1位 若是擴展位被設置，則固定的頭部必須跟在後面 正好有一個頭擴展，具備5.3.1 節 定義的格式。 CSRC計數（CC）：4位 CSRC計數包含後面的CSRC標識符的數量 固定的標題。 Schulzrinne等人 標準跟蹤[第13頁]
RFC 3550 RTP 2003年7月 標記（M）：1位 標記的解釋由配置文件定義。它是 旨在容許重要的事件，如框架邊界 在數據包流中被標記。配置文件能夠定義額外的 標記位或經過改變指定沒有標記位 有效載荷類型字段中的位數（見5.3節）。 有效載荷類型（PT）：7比特 該字段標識RTP有效載荷的格式並肯定 其應用程序的解釋。配置文件能夠指定一個 有效載荷類型碼到有效載荷格式的默認靜態映射。 額外的有效載荷類型代碼能夠經過動態定義 非RTP手段（見第3節）。一組默認映射 音頻和視頻在伴隨RFC 3551 [ 1 ]中指定。一個 RTP源能夠在會話期間改變有效載荷類型，可是這個 字段不該該用於複用單獨的媒體流 （見第5.2節）。 接收者必須忽略包含有效載荷類型的數據包 理解。 序列號：16位 每一個RTP數據包的序列號增長1 發送，並可能被接收方用來檢測丟包和 恢復數據包序列。序號的初始值 應該是隨機的（不可預知的）進行已知的明文攻擊 在加密上比較困難，即便源碼自己沒有 根據9.1節的方法加密，由於 數據包可能會流經一個翻譯器。技巧 在[ 17 ] 中討論選擇不可預測的數字。 時間戳：32位 時間戳反映了第一個八位字節的採樣時刻 RTP數據包。採樣瞬間必須來自a 時鐘的增量單調和線性的時間容許 同步和抖動計算（見第6.4.1節）。該 時鐘分辨率必須足夠知足所須要的 同步精度和測量分組到達抖動 （每一個視頻幀一個tick一般是不夠的）。時鐘 頻率取決於做爲有效載荷攜帶的數據的格式 並在配置文件或有效負載格式中被靜態指定 規範定義格式，或者能夠指定 動態地爲經過非RTP手段定義的有效載荷格式。若是 RTP包是週期性生成的標稱採樣 即時從採樣時鐘肯定要使用，而不是一個 讀取系統時鐘。例如，固定速率音頻 時間戳時鐘可能會每增長一個 採樣週期。若是音頻應用程序讀取塊覆蓋 Schulzrinne等人 標準跟蹤[第14頁]
RFC 3550 RTP 2003年7月 來自輸入設備的160個採樣週期，時間戳將是 每一個這樣的街區增長了160個，無論是否 塊在數據包中傳輸或者靜音。 時間戳的初始值應該是隨機的，至於 序列號。幾個連續的RTP數據包將會相等 時間戳，若是他們（邏輯）當即生成，例如屬於 到相同的視頻幀。連續的RTP包可能包含 若是數據未被傳輸，則時間戳不是單調的 按照它被採樣的順序，如MPEG插值的狀況 視頻幀。（發送的數據包的序列號 仍然是單調的。） 來自不一樣媒體流的RTP時間戳可能會提早 不一樣的費率，一般有獨立的，隨機的抵消。 所以，雖然這些時間戳足以重建 單個流的時間，直接比較RTP時間戳 來自不一樣媒體的同步效果不佳。 相反，對於每一個媒體的RTP時間戳是相關的 經過將其與來自參考的時間戳配對來當即採樣 時鐘（wallclock）表明數據的時間 對應於RTP時間戳被採樣。參考資料 時鐘由全部媒體共享以進行同步。時間戳 對不是在每一個數據包中傳輸，而是在較低的 RTCP SR數據包中的速率，如6.4節所述。 採樣時刻被選擇做爲參考點 RTP時間戳，由於它是發送端點所知道的 對於全部媒體都有一個通用的定義，與編碼無關 延誤或其餘處理。目的是容許同步 介紹全部同時採樣的媒體。 應用程序傳輸存儲的數據而不是數據採樣 實時一般使用派生的虛擬演示時間線 從掛鐘時間肯定什麼時候下一幀或其餘單位 存儲的數據中的每種介質都應該被呈現。在這 的狀況下，RTP時間戳將反映的演示時間 每一個單位。也就是說，每一個單元的RTP時間戳將是 與單元當前的掛鐘時間有關 虛擬展現時間線。實際的演示發生 一段時間後由接收器肯定。 描述預錄製視頻的實況音頻敘述的例子 說明了選擇抽樣時刻的意義 參考點。在這種狀況下，視頻將是 在當地呈現給敘述者查看並將是 同時使用RTP進行傳輸。a的「採樣時刻」 在RTP中傳輸的視頻幀將經過參考創建 Schulzrinne等人 標準跟蹤[第15頁]
RFC 3550 RTP 2003年7月 它的時間戳到了那個視頻幀的時間 提交給解說員。音頻RTP的採樣時刻 包含敘述者言語的分組將由...創建 在音頻採樣時參考相同的掛鐘時間。 音頻和視頻甚至能夠由不一樣的主機傳輸 兩臺主機的參考時鐘是同步的 意味着如NTP。接收者而後能夠同步呈現 的音頻和視頻數據包的RTP時間戳 使用RTCP SR數據包中的時間戳對。 SSRC：32位 SSRC字段標識同步源。這個 標識符應該隨機選擇，意圖是沒有兩個 在同一個RTP會話中的同步源將有 相同的SSRC標識符。一個算法生成一個例子 隨機標識符見附錄A.6。雖然 多個來源選擇相同標識符的機率是 低，全部的RTP實現必須準備好檢測和 解決衝突。 第8節描述的機率 碰撞和解決衝突的機制 檢測RTP級別轉發循環的惟一性 SSRC標識符。若是來源改變其來源運輸 地址，它也必須選擇一個新的SSRC標識符來避免 解釋爲一個循環的來源（見第8.2節）。 證監會名單：0-15項，每項32位 中國證監會的名單肯定了有效載荷的貢獻來源 包含在這個包裏。標識符的數量由下式給出 CC領域。若是有超過15個來源， 只有15個能夠被識別。CSRC標識符被插入 混頻器（見第7.1節），使用SSRC標識符 來源。例如，對於SSRC的音頻數據包 全部來源的標識符混合在一塊兒建立一個 數據包被列出，容許正確的說話者指示 接收器。 複用RTP會話 爲了有效協議處理，多路複用點的數量 應該最小化，如集成層處理中所述 設計原則[ 10 ]。在RTP中，複用是由... ...提供的 目的地傳輸地址（網絡地址和端口號）哪一個 對於每一個RTP會話是不一樣的。例如，在電話會議中 由分別編碼的音頻和視頻媒體組成，每一個媒體 應該在一個單獨的RTP會話中進行 運輸地址。 Schulzrinne等人 標準跟蹤[第16頁]
RFC 3550 RTP 2003年7月 獨立的音頻和視頻流不該該單獨攜帶 RTP會話並基於有效載荷類型或SSRC進行解複用 領域。使用不一樣的RTP媒體類型交錯數據包 使用相同的SSRC會帶來幾個問題： 若是兩個音頻流共享相同的RTP會話， 相同的SSRC值，一個是改變編碼，從而得到 一個不一樣的RTP負載類型，不會有通常的方法 識別哪一個流已經改變了編碼。 2. SSRC被定義爲識別單個時間和序列號 空間。交錯多種有效載荷類型將須要 不一樣的時間空間，若是媒體時鐘速度不一樣並且會 須要不一樣的序列號空間來告訴哪一個有效載荷 類型遭受丟包。 3. RTCP發送者和接收者報告（見第6.4節）只能 描述每一個SSRC的一個時序和序列號空間，而不是 攜帶有效載荷類型字段。 4.一個RTP混音器將不能組合交錯流 不兼容的媒體合併成一個流。 在一個RTP會話中攜帶多個媒體排除：使用 不一樣的網絡路徑或網絡資源分配 適當; 若是須要，接收媒體的一個子集 例如，若是視頻超過可用帶寬，則只是音頻; 和接收器實現使用單獨的進程的 不一樣的媒體，而使用單獨的RTP會話許可 不管是單進程仍是多進程實現。 每一個媒體使用不一樣的SSRC，但發送相同的 RTP會話將避免前三個問題，但不是最後一個 二。 另外一方面，複用多個相同的來源 在一個RTP會話中使用不一樣的SSRC值是正常的 多播會話。上面列出的問題不適用：RTP 調音臺能夠結合多個音源，例如和同樣 全部的治療都是適用的。這也多是適當的 使用不一樣的SSRC值複用相同介質的流 在最後兩個問題不適用的其餘狀況下。 Schulzrinne等人 標準跟蹤[第17頁]
RFC 3550 RTP 2003年7月 RTP頭的特定於配置文件的修改 現有的RTP數據包頭被認爲是完整的 在全部應用程序中共同須要的一組功能 RTP可能支持的類。可是，與ALF保持一致 設計原則，標題能夠經過修改或定製 在配置文件規範中定義的添加，同時仍然容許 獨立於配置文件的監視和錄製工具來運行。 標記位和有效載荷類型字段攜帶配置文件特定的 信息，可是因爲許多信息被分配在固定標題中 應用程序預計須要他們，不然可能不得不 添加另外一個32位字來保存它們。包含八位字節 這些字段可能會被一個配置文件從新定義，以適應不一樣的狀況 要求，例如具備更多或更少的標記位。若是 有任何標記位，應該位於最多的位置 自配置文件獨立監視器以來的八位字節的顯着位 可能可以觀察到分組丟失模式之間的相關性 和標記位。 o特定有效載荷所需的附加信息 格式，好比視頻編碼，應該在有效載荷中攜帶 包的一部分。這可能在老是一個頭 出如今有效載荷部分的開始處，或者可能被指示 經過數據模式中的保留值。 o若是特定類別的應用程序須要額外的 獨立於有效載荷格式的功能，下面的配置文件 這些應用程序運行應該定義額外的固定 在現有的SSRC領域以後當即跟隨領域 固定標題。這些應用程序將可以快速和 在配置文件無關的狀況下直接訪問其餘字段 監視器或錄像機仍然能夠處理RTP數據包 只解釋前十二個八位字節。 若是事實證實，共同須要額外的功能 跨全部配置文件，那麼應該定義一個新版本的RTP 對固定標題進行永久更改。 RTP頭擴展 提供了一個擴展機制來容許我的 實現實驗新的有效載荷格式無關 功能，須要額外的信息進行 RTP數據包頭。這個機制是這樣設計的 擴展頭可能會被其餘互操做忽略 還沒有擴展的實現。 Schulzrinne等人 標準跟蹤[第18頁]
RFC 3550 RTP 2003年7月 請注意，這個擴展頭僅用於有限的使用。 這個機制的大多數潛在用途會更好地作另外一個 方式，使用上一節中描述的方法。對於 例如，固定標題的特定於配置文件的擴展名較少 處理起來很昂貴，由於它不是有條件的，也不是一個變量 位置。特定有效載荷所需的附加信息 格式不該該使用這個頭擴展名，但應該進入 分組的有效載荷部分。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 由配置文件|定義 長度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 標題擴展| | .... | 若是RTP頭中的X位是一個可變長度的頭 在CSRC列表以後，擴展名必須附加到RTP頭 若是有的話。標題擴展名包含一個16位長度的字段 計算擴展名中32位字的數量，不包括 四個字節的擴展頭（所以零是有效的長度）。只要 一個擴展名能夠附加到RTP數據頭。容許 多個互操做實現到每一個實驗 獨立使用不一樣的頭擴展，或容許一個 特殊的實現來試驗多種類型的 頭擴展，頭擴展的前16位留下 打開區分標識符或參數。的格式 這16位是由profile配置文件定義的 這些實現正在運行。這個RTP規範呢 沒有定義任何頭擴展自己。 。 RTP控制協議（RTCP）基於週期性傳輸 的控制包給會話中的全部參與者，使用相同的方式 分配機制做爲數據包。底層協議 必須提供數據和控制數據包的複用 例如使用與UDP分開的端口號。RTCP執行四個 功能： 主要功能是提供關於質量的反饋 數據分配。這是RTP做用的組成部分 傳輸協議，並與流量和擁塞有關 其餘傳輸協議的控制功能（參見第10節） 擁塞控制的要求）。反饋多是 用於自適應編碼[控制直接有用18，19 ]，但 IP多播實驗代表，它也是 Schulzrinne等人 標準跟蹤[第19頁]
RFC 3550 RTP 2003年7月 相當重要的是從接收器得到反饋來診斷故障 分佈。向全部人發送接收反饋報告 參與者容許正在觀察問題的人進行評估 不管這些問題是本地仍是全球。隨着分配 像IP組播這樣的機制，對一個實體也是可能的 如沒有涉及的網絡服務提供商 在會議期間接收反饋信息並做爲一個 第三方監視器來診斷網絡問題。這個反饋 功能是由RTCP發送者和接收者報告執行的， 如6.4節所述。 2. RTCP爲RTP攜帶一個持久的傳輸級標識符 來源稱爲規範名稱或CNAME，第6.5.1節。以來 若是發現衝突，則SSRC標識符可能會更改 程序從新啓動，接收器須要CNAME跟蹤 每一個參與者。接收者也可能須要CNAME 未來自集合中給定參與者的多個數據流相關聯 相關的RTP會話，例如同步音頻和 視頻。媒體間同步也須要NTP和RTP 數據發送方包含在RTCP數據包中的時間戳。 3.前兩個功能要求全部參與者發送RTCP 數據包，所以速率必須被控制以使RTP到達 擴大到大量的參與者。經過每一個 參與者將其控制包發送給全部其餘人，每一個人均可以 獨立觀察參與者人數。這個數字是 用來計算數據包發送的速率，如 在6.2節中解釋。 4.第四，可選功能是傳達最小的會話控制 信息，例如參與者身份 顯示在用戶界面中。這極可能是有用的 在參與者進入的「鬆散控制的」會議中 離開沒有會員控制或參數協商。RTCP 做爲到達全部參與者的便利渠道，可是 不必定指望支持全部的控制 通訊要求的應用程序。更高一級 會話控制協議，這是超出了這個範圍 文件，多是須要的。 功能1-3應該在全部環境中使用，特別是在 IP組播環境。RTP應用程序設計者應該避免 機制只能在單播模式下工做，不能擴展到 更大的數字。RTCP的傳輸能夠單獨控制 對於發送者和接收者，如在第6.2節中，例 例如來自接收器的反饋不是單向鏈路 可能。 Schulzrinne等人 標準跟蹤[第20頁]
RFC 3550 RTP 2003年7月 非規範性說明：在組播路由方法中 稱爲源特定多播（SSM），只有一個發送者 每一個「通道」（源地址，組地址對），和 接收者（頻道源除外）不能使用多播 與其餘渠道成員直接溝通。該 這裏建議適應SSM只能經過第6.2節的 徹底關閉接收者的RTCP選項。將來的工做將會 指定適用於SSM的RTCP，以便從接收方反饋 能夠維持。 RTCP數據包格式 這個規範定義了幾個RTCP分組類型來攜帶一個 各類控制信息： SR：發件人報告，用於發送和接收統計 參與者是主動發件人 RR：接收者報告，用於接收參與者的接收統計 那些不是主動的發送者，而是與SR的組合 主動發送者報告超過31個來源 SDES：來源說明項目，包括CNAME BYE：表示參與結束 APP：應用程序特定的功能 每一個RTCP數據包以與RTP數據相似的固定部分開始 數據包，而後是結構化元素，多是可變的 長度根據數據包類型，但必須在32位結束 邊界。對齊要求和固定長度字段 包含每一個數據包的一部分以使RTCP數據包「可堆疊」。 多個RTCP數據包能夠鏈接而不須要任何干預 分隔符來造成一個複合RTCP數據包，它是在一個單一的發送 下層協議的數據包，例如UDP。沒有 顯式計數複合包中的單個RTCP包 由於低層協議有望提供一個總體 肯定複合包的結束長度。 能夠處理複合分組中的每一個單獨的RTCP分組 獨立，對訂單或組合沒有要求 數據包。可是，爲了執行協議的功能， 下面的限制是強加的： Schulzrinne等人 標準跟蹤[第21頁]
RFC 3550 RTP 2003年7月 o接收統計（在SR或RR中）應該常常發送 帶寬限制將容許最大化的分辨率 統計，因此每一個週期性地發送複合RTCP 分組必須包含一個報告分組。 o新接收者須要儘快接收源的CNAME 可能肯定來源並開始關聯媒體 目的如脣同步，因此每一個複合RTCP數據包也必須 包括SDES CNAME，除了複合RTCP數據包時 按9.1節所述進行部分加密分割。 o化合物中可能首先出現的數據包類型的數量 數據包須要被限制以增長固定位的數量 在第一個字和成功驗證的可能性 RTCP數據包針對錯誤的RTP數據包或其餘數據包 無關的數據包。 所以，全部RTCP分組至少必須在一個複合分組中發送 兩個單獨的數據包，格式以下： 加密前綴：當且僅當複合數據包是 根據9.1節的方法加密，它必須是 以每一個化合物的隨機32位數量做爲前綴 數據包傳輸。若是填充須要進行加密，則爲 務必添加到複合包的最後一個包中。 SR或RR：複合包中的第一個RTCP包必須 始終是一個報告數據包，以方便標題驗證 如附錄A.2所述。即便沒有數據，狀況也是如此 發送或接收，在這種狀況下，必須發送一個空的RR，甚至是 若是複合報文中惟一的其餘RTCP報文是BYE。 額外的RR：若是接收的來源的數量 統計報告超過31個，將適合的數量 到一個SR或RR數據包中，那麼附加的RR數據包應該遵循 最初的報告包。 SDES：必須包含一個包含CNAME項目的SDES數據包 在每一個複合RTCP分組中，除了在9.1節中提到的之外。 其餘來源的描述項目能夠選擇包括，若是 須要一個特定的應用程序，受帶寬限制 約束條件（見6.3.9節）。 BYE或APP：其餘RTCP數據包類型，包括那些還沒有被使用的數據包 定義，能夠按照任何順序，除了BYE應該是 與SSRC / CSRC給定的最後一個數據包。數據包類型可能會出現 不止一次。 Schulzrinne等人 標準跟蹤[第22頁]
RFC 3550 RTP 2003年7月 我的RTP參與者應該只發送一個複合RTCP 數據包每報告間隔爲了每一個RTCP帶寬 參與者被正確地估計（見第6.2節），除了何時 如上所述，複合RTCP分組被分割以進行部分加密 在9.1節。若是有太多的來源來適應全部的 必要的RR數據包合併爲一個複合RTCP數據包而不超過 網絡路徑的最大傳輸單位（MTU） 將適合一個MTU的子集應該包含在每一箇中 間隔。子集應該跨多個循環選擇 以便報告全部來源。 建議翻譯人員和混音人員合併我的RTCP 來自多個來源的數據包被轉發到一個 複合數據包在任何可行的狀況下，以分攤數據包 開銷（見第7節）。一個示例RTCP複合包可能 由混合器生產的如圖1所示 一個複合包將超過網絡路徑的MTU，應該是這樣的 被分割成多個較短的複合包進行傳輸 在底層協議的單獨數據包中。這不會損害 因爲每一個複合分組表示RTCP帶寬估計 至少有一個不一樣的參與者。請注意，每一個化合物 分組必須以SR或RR分組開始。 一個實現應該忽略帶有類型的傳入RTCP數據包 它不知道。額外的RTCP數據包類型能夠註冊 互聯網號碼分配機構（IANA）的描述 第15節。 若是加密：隨機的32位整數 | | [---------數據包--------] [----------數據包----------] [ - 數據包] | | 接收器塊大塊 V報告項目項目項目項目 -------------------------------------------------- ------------------ R [SR #sendinfo＃site1＃site2] [SDES #CNAME PHONE #CNAME LOC] [BYE ## why] -------------------------------------------------- ------------------ | | | <-----------------------複合包----------------------- > | | <-------------------------- UDP packet -------------------- -----> | ＃：SSRC / CSRC標識符 圖1：一個RTCP複合包的例子 Schulzrinne等人 標準跟蹤[第23頁]
RFC 3550 RTP 2003年7月 RTCP傳輸間隔 RTP旨在容許應用程序自動縮放 會議規模從幾個參與者到數千人不等。對於 例如，在音頻會議中，數據業務本質上是自組織的， 限制，由於一次只有一兩我的會說話，因此 多播分配，任何給定鏈路上的數據速率仍然保持 與參與者的數量無關。 可是，控制流量不是自我限制的。若是接待 每一個參與者的報告都是以恆定的速度發送的 控制流量將隨着參與者的數量呈線性增加。 所以，速率必須經過動態計算來縮小 RTCP數據包傳輸之間的時間間隔。 對於每一個會話，都假定數據流量受到影響 一個稱爲「會話帶寬」的聚合限制被分配 參與者們。這個帶寬可能被保留，而且是有限的 由網絡執行。若是沒有保留，可能會有 其餘限制，取決於環境，創建的 會議使用的「合理的」最大限度，這將是 會話帶寬。會話帶寬能夠根據一些選擇 成本或對可用網絡帶寬的先驗知識 會話。它有些獨立於媒體編碼，可是 編碼選擇可能會受到會話帶寬的限制。一般狀況下， 會話帶寬是發送者的標稱帶寬的總和 預計將同時活躍。對於電話會議音頻，這個 數字一般是一個發送者的帶寬。對於分層 編碼，每一層都是一個單獨的RTP會話與本身的會話 帶寬參數。 會話帶寬參數預計由a提供 會話管理應用程序在調用媒體應用程序時， 但媒體應用程序可能會根據單一發件人設置默認值 爲會話選擇的編碼的數據帶寬。該 應用程序也能夠強制基於多播的帶寬限制 範圍規則或其餘標準。全部參與者必須使用相同的 會話帶寬的值，以便相同的RTCP時間間隔 被計算。 控制和數據流量的帶寬計算包括： 層傳輸和網絡協議（例如，UDP和IP） 是資源預留系統須要知道的。該 應用程序也能夠被指望知道這些協議是哪個 正在使用。連接級別標題不包含在計算中 該數據包將被封裝爲不一樣的鏈路層頭 它旅行。 Schulzrinne等人 標準跟蹤[第24頁]
RFC 3550 RTP 2003年7月 控制流量應該限制在一個小的已知分數 的會話帶寬：小，這樣的主要功能 傳輸協議攜帶數據不受損害; 已知因此 控制流量能夠包含在給定的帶寬規範中 到資源預留協議，以便每一個參與者均可以 獨立計算其份額。控制流量帶寬是 除了數據流量的會話帶寬。它是 建議爲RTCP添加會話帶寬的一小部分 固定在5％。也建議使用RTCP的1/4 帶寬專用於正在發送數據的參與者 在與大量的接收器，但少數的會議 發件人，新加入的參與者將更快收到 發送網站的CNAME。當發件人的比例是 超過1/4的參與者，發件人獲得他們的 完整的RTCP帶寬的比例。而這些和價值 區間計算中的其餘常量並不重要 會話中的參與者必須使用相同的值 間隔將被計算。所以，這些常數應該是 固定爲特定的配置文件。 配置文件能夠指定控制流量帶寬多是a 會話的單獨參數而不是嚴格的百分比 會話帶寬。使用單獨的參數， 自適應應用程序來設置RTCP帶寬與a一致 「典型」數據帶寬低於最大帶寬 由會話帶寬參數指定。 配置文件能夠進一步指定控制流量帶寬 能夠分爲兩個單獨的會話參數 參與者是活躍的數據發送者而不是那些; 讓咱們調用參數S和R.按照推薦 那RTCP帶寬的四分之一專用於數據發送者 對於這兩個參數，推薦的默認值是1.25％ 和3.75％。發件人比例較大時 比參與者的S /（S + R），發件人獲得他們的比例 這些參數的總和。使用兩個參數容許RTCP 接待報告將徹底關閉一個特定的會議 經過將非數據發送者的RTCP帶寬設置爲零 保持數據發送者的RTCP帶寬不爲零，以便發送者 報告仍然能夠發送用於媒體間同步。車削 關閉RTCP接收報告是不推薦的，由於它們是須要的 對於第6節開頭列出的功能，尤爲如此 接收質量反饋和擁塞控制。可是，這樣作 可能適用於在單向鏈路上運行的系統 對於不須要接收質量反饋的會話 或接收者的活潑，並有其餘方法來避免 擁塞。 Schulzrinne等人 標準跟蹤[第25頁]
RFC 3550 RTP 2003年7月 計算複合RTCP的傳輸間隔 數據包還應該有一個下界，以免有突發 當參與者數量超過容許的帶寬時 規模小，交通不平順，規模大 數字。它也保持報告間隔變得過小 在像網絡分區這樣的暫時中斷期間 當分區癒合時適應被延遲。在應用程序 啓動時，應在第一個複合RTCP以前施加一個延遲 分組被髮送以容許從RTCP分組接收時間 其餘參與者如此報告的時間間隔將會收斂到 正確的價值更快。這個延遲可能會被設置爲一半 最小間隔容許更快通知新的 參加者在場。推薦值爲固定的最小值 間隔是5秒。 實現能夠將最小RTCP間隔縮小到更小 值與會話帶寬參數成反比 有如下限制： o對於多播會話，只有活動的數據發送者能夠使用 減少最小值來計算傳輸間隔 複合RTCP數據包。 o對於單播會話，能夠使用縮小的值 那些不是主動數據發送者的參與者，以及 在發送初始化合物RTCP包以前延遲可能爲零。 ○對於全部的會話，固定的最小值應該在何時使用 計算參與者超時間隔（參見第6.3.5節） 因此那些不使用減小值的實現 其餘參與者不會超時發送RTCP數據包 過早。 o以秒爲單位的最小值的推薦值爲360 會話帶寬除以千比特/秒。這最低限度 對於大於72kb / s的帶寬，小於5秒。 設計了6.3節和附錄A.7中 描述的算法 以達到本節所述的目標。它計算出 發送複合RTCP數據包之間的間隔來劃分容許的 控制參與者之間的流量帶寬。這容許一個 應用程序提供快速響應的小型會議，爲 例如，全部參與者的身份是重要的，但 自動適應大型會議。算法合併 如下特色： Schulzrinne等人 標準跟蹤[第26頁]
RFC 3550 RTP 2003年7月 計算的RTCP數據包之間的時間間隔線性變化 組中的成員數量。這是線性因素 在總結時容許控制流量不變 跨全部成員。 o RTCP數據包之間的間隔隨機變化 範圍[0.5,1.5]乘以計算的時間間隔以免意外 同步全部參與者[ 20 ]。第一個RTCP數據包 加入會議後發送的也是隨機變化的延遲 是最小RTCP間隔的一半。 ○對平均複合RTCP分組大小的動態估計是 計算，包括全部收到和發送的數據包 自動適應控制量的變化 信息進行。 o因爲計算的時間間隔取決於數量 觀察組員，可能會有不良的啓動效應 當一個新用戶加入一個現有的會議，或許多用戶 同時加入新的會議。這些新用戶將在最初 有不正確的團體成員的估計，所以他們的 RTCP傳輸間隔過短。這個問題能夠 若是許多用戶同時加入會話，這是很重要 至 處理這個，一個叫作「定時器從新考慮」的算法是 採用。這個算法實現了一個簡單的退避機制 這會致使用戶阻止RTCP數據包的傳輸 團體人數正在增長。 o當用戶離開會議時，或者用BYE或者超時， 組成員減小，從而計算出的間隔 應該減小。使用「反向從新考慮」算法 容許成員更快地縮短迴應的時間間隔 組員的減小。 BYE數據包的處理方式與其餘RTCP數據包不一樣。 當用戶離開一個組，並但願發送一個BYE包時， 能夠在其下一個調度的RTCP分組以前這樣作。然而， BYE的傳輸遵循避免的退避算法 BYE包的洪水應該是大量的成員 同時離開會議。 這個算法能夠用於全部參與者的會話 容許發送。在這種狀況下，會話帶寬參數是 我的發送者的帶寬乘以數量的乘積 參與者，而RTCP的帶寬是5％。 該算法的操做細節在如下部分給出 跟隨。 附錄A.7給出了一個示例實現。 Schulzrinne等人 標準跟蹤[第27頁]
RFC 3550 RTP 2003年7月 維護會話成員的數量 RTCP數據包間隔的計算取決於一個估計值 參加會議的網站數量。新的網站是 當他們被聽到時被添加到計數中，而且每一個都應該輸入 在由SSRC或CSRC標識符索引的表格中建立 8.2節）跟蹤他們。能夠考慮新的條目 直到有多個攜帶新的SSRC的數據包纔有效 接收（見附錄A.1），或直到一個SDES RTCP包包含 該SSRC的CNAME已收到。條目能夠從中刪除 當一個RTCP表與一個相應的SSRC的BYE包對照表時 標識符被接收，除了一些零散的數據包可能 在BYE以後到達而且致使條目被再造。代替， 該條目應該被標記爲已經收到BYE，而後被刪除 通過適當的延遲。 參與者能夠標記另外一個網站處於非活動狀態，或者若是還沒有刪除 若是沒有收到少許的RTP或RTCP數據包，則爲有效 的RTCP報告間隔（推薦5）。這提供了一些 對數據包丟失的魯棒性。全部網站必須具備相同的價值 對於這個乘數，必須計算大體相同的值 RTCP報告間隔，以便此超時正常工做。 所以，這個乘數應該是固定的一個特定的配置文件。 對於有大量參與者的會議，可能會是 維護一個表來存儲SSRC標識符是不切實際的 全部這些狀態信息。一個實現能夠使用SSRC 採樣，如[ 21 ]中所述，以減小存儲要求。 一個實現能夠使用任何其餘相似的算法 性能。一個關鍵的要求是考慮任何算法 雖然它不該該大大低估組的大小 可能高估了。 RTCP數據包發送和接收規則 如何發送的規則，以及接收RTCP時的操做規則 數據包在這裏列出。一個容許在其中運行的實現 多播環境或多點單播環境必須知足6.2節 的要求。這樣的實現能夠使用 算法在本節中定義，以知足這些要求，或者能夠 只要提供等價的或更好的，就能夠使用其餘一些算法 性能。一個限於雙方的實施 單播操做應該仍然使用RTCP的隨機化 傳輸間隔能夠避免多重意外同步 在相同環境中運行的實例，但能夠省略「計時器」 從新考慮「和」反向從新考慮「算法 6.3.3，6.3.6和6.3.7。 Schulzrinne等人 標準跟蹤[第28頁]
RFC 3550 RTP 2003年7月 爲了執行這些規則，會話參與者必須維護幾個 件狀態： tp：RTCP數據包最後一次傳輸的時間; tc：當前時間; tn：RTCP分組的下一個調度傳輸時間; 會員：在時間tn會議成員的估計數量 最後從新計算; 成員：會議次數的最新估計 成員; 發件人：最新的發件人數量估計 會議; rtcp_bw：目標RTCP帶寬，即總帶寬 該會話的全部成員將用於RTCP數據包， 以每秒八位字節爲單位。這將是一個指定的分數 提供給應用程序的「會話帶寬」參數 啓動。 we_sent：若是應用程序發送了數據，則爲true 自從第二個之前的RTCP報告被傳送。 avg_rtcp_size：平均複合RTCP數據包大小，以八位組爲單位， 經過此參與者發送和接收的全部RTCP數據包。該 大小包括低層傳輸和網絡協議頭 （如UDP和IP），如第6.2節所述。 initial：若是應用程序還沒有發送，則爲true的標誌 一個RTCP數據包。 這些規則中的不少都利用了二者之間的「計算間隔」 數據包傳輸。這個時間間隔以下所述 部分。 計算RTCP傳輸間隔 爲了保持可伸縮性，數據包之間的平均間隔由一個 會話參與者應按照組大小進行縮放。這個間隔 被稱爲計算間隔。它是經過組合一個 上述狀態的數量。計算 間隔T而後以下肯定： Schulzrinne等人 標準跟蹤[第29頁]
RFC 3550 RTP 2003年7月 1.若是發件人的數量少於或等於25％ 會員（會員）的間隔取決因而否 參與者是否爲發件人（基於we_sent的值）。 若是參與者是發件人（we_sent爲true），則常量C爲 設置爲平均RTCP數據包大小（avg_rtcp_size）除以25％ 的RTCP帶寬（rtcp_bw），常數n被設置爲 發件人數量。若是we_sent不正確，則設置常量C. 到平均RTCP數據包大小除以RTCP的75％ 帶寬。常數n被設置爲接收器的數量 （成員 - 發件人）。若是發件人的數量大於 25％，發件人和收件人一塊兒處理。常數C 被設置爲平均RTCP分組大小除以總RTCP 帶寬和n被設置爲成員總數。就像聲明的那樣 在6.2節中，RTP配置文件能夠指定RTCP帶寬 能夠由兩個獨立的參數明肯定義（稱它們爲S 和R）爲發件人和那些參與者 不是。在這種狀況下，25％的分數變成S /（S + R） 75％部分變成R /（S + R）。請注意，若是R是零， 發件人的百分比從不大於S /（S + R），而且 執行必須避免被零除。 2.若是參與者還沒有發送RTCP數據包（變量 初始值爲真），常數Tmin設置爲2.5秒，不然 設置爲5秒。 3.肯定性計算間隔Td被設置爲max（Tmin，n * C）。 4.計算出的間隔T被設定爲均勻分佈的數字 在肯定性計算間隔的0.5和1.5倍之間。 5. T的結果值除以e-3/2 = 1.21828來補償 定時器複議算法收斂到的事實 RTCP帶寬的值低於預期的平均值。 這個過程致使了一個隨機的間隔，可是這個間隔是 平均而言，RTCP帶寬至少爲發送方和服務器提供了25％的帶寬 休息給接收者。若是發件人構成四分之一以上 的程序，這個程序之間平分帶寬 全部的參與者，平均。 初始化 加入會話後，參與者將tp初始化爲0，tc爲 0，發件人爲0，發件人爲1，發件人爲1，發件人爲假， rtcp_bw到會話帶寬的指定分數，初始值 爲true，avg_rtcp_size爲第一個RTCP的可能大小 應用程序稍後將構建的數據包。計算 而後計算間隔T，而且計劃第一個分組 Schulzrinne等人 標準跟蹤[第30頁]
RFC 3550 RTP 2003年7月 時間tn = T。這意味着發送定時器被設置 在時間T到期。請注意，應用程序能夠使用任何須要的 實現這個計時器的方法。 參與者將其本身的SSRC添加到成員表中。 接收RTP或非BYE RTCP包 從SSRC的參與者收到RTP或RTCP數據包時 不在成員表中，SSRC被添加到表中，而 一旦參與者被驗證，成員的價值就會被更新 如第6.2.1節所述。每一個處理都發生相同的處理 證監會在一個通過驗證的RTP數據包。 從SSRC不參與者收到RTP包時 在發件人表中，SSRC被添加到表中，而且值 發件人更新。 對於收到的每一個複合RTCP數據包，avg_rtcp_size的值是 更新： avg_rtcp_size =（1/16）* packet_size +（15/16）* avg_rtcp_size 其中packet_size是剛收到的RTCP包的大小。 接收RTCP BYE包 除了6.3.7節中描述的狀況，當一個RTCP BYE是 若是收到的數據包是一個RTCP BYE數據包，則發送 SSRC是檢查成員表。若是有的話，那就是 從表中刪除，並更新成員的值。該 SSRC而後檢查發件人表。若是存在，輸入 將從表中刪除，並更新發件人的值。 此外，爲了使RTCP分組的傳輸速率更高 適應組員身份的變化，下面的「反向」 從新考慮「算法應該在BYE數據包執行時執行 收到，減小會員的價值低於pmembers： o tn的值根據如下公式進行更新： tn = tc +（會員/會員）*（tn - tc） o tp的值根據如下公式進行更新： tp = tc - （members / pmembers）*（tc - tp）。 Schulzrinne等人 標準跟蹤[第31頁]
RFC 3550 RTP 2003年7月 o下一個RTCP分組在tn時間從新調度傳輸， 如今是更早。 o pmembers的值等於成員。 該算法不會阻止來自組的大小估計 因爲過早而不正確地降到零 當一個大會議的大多數參與者同時離開時超時 一些保持。該算法確實使估計返回到 正確的價值更迅速。這種狀況是不尋常的， 後果是充分無害的，認爲這個問題 只是次要的關注。 定時SSRC 偶爾間隔，參與者必須檢查是否有任何 其餘參與者超時。要作到這一點，參與者 計算肯定性（沒有隨機因素） 計算出接收者的時間間隔Td，即we_sent爲false。 任何其餘會議成員，由於沒有發送RTP或RTCP數據包 時間tc - MTd（M是超時乘數，默認爲5） 時間到。這意味着其SSRC從成員列表中刪除， 並更新成員。對發件人執行相似的檢查 名單。發件人列表中還沒有發送RTP數據包的任何成員 由於時間tc - 2T（在最後兩個RTCP報告間隔內）是 從發件人列表中刪除，並更新發件人。 若是有任何成員超時，則反向從新考慮算法 在6.3.4節中描述應該被執行。 參與者必須至少每一個RTCP進行一次檢查 傳輸間隔。 發送計時器到期 當分組傳輸定時器到期時，參與者執行 如下操做： 傳輸間隔T按6.3.1 節 所述計算，包括隨機因子。 o若是tp + T小於或等於tc，則一個RTCP包是 傳輸。tp設置爲tc，那麼T的另外一個值是 按上一步計算，tn設爲tc + T 傳輸定時器被設置爲在時間tn再次到期。若是tp + T 大於tc，則tn被設置爲tp + T。沒有RTCP分組 傳輸。傳輸定時器設置爲在時間tn過時。 Schulzrinne等人 標準跟蹤[第32頁]
RFC 3550 RTP 2003年7月 會員設置爲會員。 若是發送RTCP分組，則初始值設置爲 假。此外，更新avg_rtcp_size的值： avg_rtcp_size =（1/16）* packet_size +（15/16）* avg_rtcp_size 其中packet_size是剛傳輸的RTCP數據包的大小。 傳輸BYE包 當一個參與者但願離開一個會話時，一個BYE包是 傳送給該事件的其餘參與者。爲了 當許多參與者離開時，避免BYE數據包的泛濫 系統，參與者必須執行如下算法 參與者選擇的會員人數超過50人 離開。這個算法篡奪了成員變量的正常角色 要計算BYE數據包，而不是： o當參與者決定離開系統時，tp被重置爲 tc，目前的時間，會員和會員都初始化爲1， 初始設置爲1，we_sent設置爲false，發件人設置爲0， avg_rtcp_size設置爲複合BYE報文的大小。 計算出的間隔T。BYE包是 預約時間tn = tc + T o每當收到來自其餘與會者的BYE數據包時， 不管是否參加者，成員都會加1 是否存在於成員表中，以及SSRC採樣是否存在 無論BYE SSRC是否包括在內，均可以使用 在樣本中。其餘RTCP數據包時，成員不增長 或收到RTP數據包，但僅用於BYE數據包。一樣的， avg_rtcp_size僅針對收到的BYE數據包進行更新。發件人 當RTP包到達時不更新; 它仍然是0。 o BYE包的傳輸遵循規則 如上所述發送常規的RTCP分組。 這容許BYE數據包當即被髮送，可是控制它們 總帶寬使用。在最壞的狀況下，這可能會致使RTCP 控制數據包使用正常的兩倍帶寬（10％） - 5％ 非BYE RTCP包和BYE的5％。 一個不想等待上述機制的參與者 容許BYE包的傳輸能夠離開組 發送一個BYE。該參與者最終將被超時 由其餘小組成員。 Schulzrinne等人 標準跟蹤[頁33]
RFC 3550 RTP 2003年7月 若是團體規模估算的成員小於50的時候 參與者決定離開，參與者能夠發送BYE包 當即。或者，參與者能夠選擇執行 上面的BYE退避算法。 在任何狀況下，都不會發送RTP或RTCP數據包的參與者 當他們離開組時，毫不能發送BYE包。 更新we_sent 若是參與者發送了RTP，則變量we_sent包含true 數據包最近，不然爲false。這個決心是由 使用相同的機制來管理其餘的一套 發件人列表中列出的參與者。若是參與者發送 一個RTP包，當we_sent爲false時，它將本身添加到發件人 表並將we_sent設置爲true。反向從新考慮 在6.3.4節中描述的算法應該可能被執行 減小發送SR包以前的延遲。每次都有另外一個RTP 分組被髮送，該分組的傳輸時間被保持 在桌子裏。正常的發送者超時算法而後被應用於 參與者 - 若是一個RTP包沒有被傳送 時間tc - 2T，參與者從發件人表中刪除本身， 遞減發件人計數，並將we_sent設置爲false。 源描述帶寬的分配 本規範定義了幾個源描述（SDES）項 除了必須的CNAME項目，如NAME（我的名稱） 和EMAIL（電子郵件地址）。它也提供了一種定義新的方法 特定於應用程序的RTCP數據包類型。應用程序應該運行 謹慎分配控制帶寬到這個額外的 信息，由於它會減慢接收的速度 報告和CNAME被髮送，從而削弱了CNAME的性能 協議。建議不要超過20％的RTCP 分配給單個參與者的帶寬用於承載 附加信息。並且，它並非所有 SDES項目將被包括在每一個應用程序中。那些是 包括應該被分配一部分帶寬根據 他們的效用。它不是動態地估計這些分數 建議將百分比靜態轉換爲 根據項目的典型長度報告間隔計數。 例如，應用程序可能被設計爲僅發送CNAME，名稱 和EMAIL，而不是其餘任何人。NAME可能會更高 優先級高於EMAIL，由於NAME會連續顯示 在應用程序的用戶界面中，而EMAIL將被顯示 只有在要求時。在每一個RTCP時間間隔，一個RR數據包和一個 帶有CNAME項目的SDES數據包將被髮送。對於一個小會議 Schulzrinne等人 標準跟蹤[頁34]
RFC 3550 RTP 2003年7月 以最小時間間隔運行，即每5秒開啓一次 平均。每隔三秒（15秒），一個額外的項目會 包含在SDES包中。八次中有七次會這樣 成爲名稱的項目，每八（2分鐘）它將是 電子郵件項目。 當多個應用程序使用交叉應用程序一致操做時 綁定經過一個共同的CNAME爲每一個參與者，例如在一個 由每一個媒體的RTP會話組成的多媒體會議 額外的SDES信息只能在一個RTP會話中發送。該 其餘會話將只攜帶CNAME項目。特別是這個 方法應該適用於分層的多個會話 編碼方案（見第2.4節）。 發件人和收件人報告 RTP接收器使用RTCP報告提供接收質量反饋 根據是否能夠採起兩種形式之一的分組 接收者也是發件人。惟一的區別 發送者報告（SR）和接收者報告（RR）形式 類型代碼，是發件人報告包含一個20字節的發件人 信息部分供主動發信人使用。若是一個 網站自發布以來已經發送了任何數據包 上次報告或上一次報告，不然發佈「無線電規則」。 SR和RR格式都包含零個或多個接收報告 塊，每一個同步源一個這個 接收方自上次報告以來收到了RTP數據包。 報告不是針對中國證監會上市的來源 名單。每一個接收報告塊提供有關數據的統計信息 從該區塊中指出的特定來源收到。因爲a 最多31個接收報告塊將適合SR或RR數據包， 額外的RR數據包應該在最初的SR或RR以後堆疊 數據包，以包含全部來源的接收報告 在上次報告以來的時間間隔內聽到。若是也有 許多來源將全部必要的RR數據包合併到一個化合物中 RTCP數據包，不超過網絡路徑的MTU，那麼只有 將適合一個MTU的子集應該包含在每一箇中 間隔。子集應該跨多個循環選擇 以便報告全部來源。 接下來的部分將定義這兩個報告的格式，它們可能如何 若是應用程序須要，能夠以特定於配置文件的方式擴展 額外的反饋信息，以及如何使用這些報告。 譯文和混音器的接收報告詳情請參閱 第7節。 Schulzrinne等人 標準跟蹤[第35頁]
RFC 3550 RTP 2003年7月 SR：發送者報告RTCP分組 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 頭| V = 2 | P | RC | PT = SR = 200 | 長度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 發件人SSRC | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 發件人| NTP時間戳，最重要的單詞| info + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | NTP時間戳，最低有效字| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | RTP時間戳| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 發件人的數據包數| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 發件人的八位字節計數| + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 報告| SSRC_1（SSRC第一來源）| 塊+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + 1 | 分數損失| 累積的丟包數| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 擴展的最高序列號收到| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 到達間隔抖動| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 最後一個SR（LSR）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 自上次SR（DLSR）|以後的延遲 + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 報告| SSRC_2（第二來源SSRC）| 塊+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + 2：...： + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | 特定於文件的擴展| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 發送者報告包可能由三部分組成 若是定義了第四個特定於文件的擴展部分。 第一部分，標題長度是8個八位字節。田野有 如下含義： 版本（V）：2比特 標識RTP的版本，在RTCP數據包中是相同的 如在RTP數據包中同樣。本規範定義的版本 是兩（2）。 Schulzrinne等人 標準跟蹤[第36頁]
RFC 3550 RTP 2003年7月 填充（P）：1位 若是填充位被設置，則這個單獨的RTCP分組包含 一些額外的填充八位字節在不是的一部分 控制信息但包含在長度字段中。該 填充的最後八位字節是多少個填充字節的計數 應該被忽略，包括它自己（這將是一個倍數 四）。某些加密算法可能須要填充 固定塊大小。在一個複合RTCP數據包中，填充是惟一的 由於複合包是一個單獨的包所須要的 加密做爲一個總體的方法在9.1節。所以，填充 只能添加到最後一個單獨的數據包，若是填充 被添加到該數據包中，填充位必須僅在該數據包上設置 包。這個約定有助於描述的頭部有效性檢查 在附錄A.2中，容許從一些早期檢測數據包 在第一個錯誤地設置填充位的實現 單獨的數據包和添加填充到最後一個單獨的數據包。 接收報告計數（RC）：5位 包中包含的接收報告塊的數量。一個 零值是有效的。 分組類型（PT）：8比特 包含常量200以將其標識爲RTCP SR數據包。 長度：16位 這個32位字的RTCP數據包的長度減1， 包括頭和任何填充。（一個的偏移量 零有效長度並避免可能的無限循環 掃描複合RTCP數據包，同時計數32位字 避免了4的倍數的有效性檢查。 SSRC：32位 這個發起者的同步源標識符 SR數據包。 第二部分，發件人信息，長度爲20個八位字節 存在於每一個發件人報告包中。它總結了這些數據 來自此發件人的傳輸。這些字段具備如下內容 含義： NTP時間戳：64位本報告顯示時 的時鐘時間（請參閱第4節） 發送，以便它能夠與時間戳結合使用 在接收報告中返回來自其餘接收者的測量 往返傳播給那些接收者。接收者應該 指望時間戳的測量準確性多是 限於遠低於NTP時間戳的分辨率。該 時間戳的測量不肯定度不會被指示出來 Schulzrinne等人 標準跟蹤[第37頁]
RFC 3550 RTP 2003年7月 可能不知道。在一個沒有wallclock概念的系統上 時間，但確實有一些系統特定的時鐘，如「系統」 正常運行時間「，發件人能夠使用該時鐘做爲參考來計算 相對NTP時間戳。通常選擇一個是很重要的 使用時鐘，以便若是使用單獨的實現來生產 多媒體會話的各個流，所有 實現將使用相同的時鐘。直到2036年， 相對和絕對時間戳會在高位有所不一樣 （無效）比較會顯示出很大的差別; 那麼一個 但願再也不須要相對時間戳。發件人 沒有掛鐘或通過時間的概念能夠設置NTP 時間戳爲零。 RTP時間戳：32位 與上面的NTP時間戳同時對應，可是以 相同的單位和與RTP相同的隨機偏移量 數據包中的時間戳。這個對應關係能夠用於 媒體內和媒體間同步的NTP源 時間戳是同步的，而且能夠由媒體獨立使用 接收器來估計標稱的RTP時鐘頻率。注意 在大多數狀況下，這個時間戳不會等於RTP 時間戳在任何相鄰的數據包中。相反，它必須是 從相應的NTP時間戳使用計算 RTP時間戳計數器和實時時間之間的關係 經過按期檢查wallclock時間來維護 抽樣即時。 發送者的包計數：32位 發送方發送的RTP數據包總數 由於直到這個SR數據包開始傳輸 產生。若是發件人更改其計數，計數應該被重置 SSRC標識符。 發送者的八位組數：32比特 有效載荷字節的總數（即不包括標題或 填充）由發送方自RTP發送的數據包 直到這個SR數據包開始傳輸 產生。若是發件人更改其計數，計數應該被重置 SSRC標識符。這個字段能夠用來估計平均值 淨荷數據速率。 第三部分包含零個或多個接收報告塊 這取決於此發件人從其餘來源收到的其餘來源的數量 最後的報告。每一個接收報告塊傳送統計信息 從單個同步源接收RTP數據包。 接收者不該該在源發生變化時進行統計 SSRC標識符因爲碰撞。這些統計是： Schulzrinne等人 標準跟蹤[第38頁]
RFC 3550 RTP 2003年7月 SSRC_n（源標識符）：32位 信息來源的SSRC標識符 接待報告塊屬於。 分數丟失：8位 自SSRC_n以來，RTP數據包的一部分丟失 先前的SR或RR包被髮送，表示爲固定點 編號與字段的左邊緣的二進制點。（那 至關於乘之後的整數部分 損失分數除以256）。這個分數被定義爲數字 丟失的數據包除以預期的數據包數量 在下一段定義。一個實現如圖所示 附錄A.3。若是因爲重複形成的損失是負面的，那麼 分數丟失被設置爲零。請注意，一個接收器不能告訴 最後一個收到的包是否丟失 沒有接收報告塊的來源 若是來自該源的全部分組在上次報告期間發送 間隔已經丟失。 累計丟包數：24位 來自源SSRC_n的RTP數據包的總數 自接待開始以來已經失去。這個數字是 定義爲數據包的數量少於預期的數量 實際收到的數據包，接收數據包的數量 包括任何遲到或重複。所以，數據包 遲到不計算在內，損失多是負數 若是有重複。預期的數據包數量是 定義爲收到的擴展的最後序列號，如 接下來定義，少於收到的初始序列號。這可能 按附錄A.3所示進行計算。 擴展的最高序列號收到：32位 低16位包含在一個接收到的最高序列號 來自SSRC_n的RTP數據包，最重要的16個 位以相應的計數擴展該序列號 序列號週期，能夠根據這個維護 算法見附錄A.1。請注意，不一樣的接收器內 同一個會話將生成不一樣的擴展名 序列號，若是他們的開始時間差別顯着。 到達間隔抖動：32位 RTP數據包統計方差的估計 到達間隔時間，以時間戳單位測量並表示爲 無符號整數。間隔抖動J被定義爲 差值D in的平均誤差（平滑的絕對值） 在接收端的數據包間隔與一對的發送端相比 的數據包。以下面的公式所示，這至關於 兩個數據包的「相對傳輸時間」的差別; Schulzrinne等人 標準跟蹤[第39頁]
RFC 3550 RTP 2003年7月 相對傳輸時間是數據包的RTP之間的差別 時間戳和到達時間的接收機時鐘， 在相同的單位測量。 若是Si是數據包i的RTP時間戳，而且Ri是時間戳 到達分組i的RTP時間戳單元，而後是兩個分組 我和j，D能夠表示爲 D（i，j）=（Rj-Ri） - （Sj-Si）=（Rj-Sj） - （Ri-Si） 到達間隔抖動應該連續計算 數據包i是從源SSRC_n接收的，使用它 該分組與前一個分組i-1的差值D 到達（不必定按順序），根據公式 J（i）= J（i-1）+（| D（i-1，i）| - J（i-1））/ 16 每當接收報告發出時，J的當前值是 採樣。 抖動計算必須符合這裏指定的公式 以容許配置文件無關的監視器生效 對來自不一樣實施的報告的解釋。 該算法是最優的一階估計器和增益 參數1/16給出了一個很好的降噪比 保持合理的收斂速度[ 22 ]。一個樣品 實現顯示在附錄A.8。參見6.4.4節的 討論不一樣的數據包持續時間和延遲的影響 在傳輸以前。 最後一個SR時間戳（LSR）：32位 NTP時間戳中的64位中的中間32位（如中所述） 第4節）做爲最新的RTCP發送者報告的一部分收到 （SR）數據包從源SSRC_n。若是還沒有收到SR， 該字段設置爲零。 自上次SR（DLSR）以來的延遲：32位 延遲時間以1/65536秒爲單位表示 從源SSRC_n接收最後一個SR包併發送 接待報告塊。若是尚未收到SR數據包 從SSRC_n，DLSR字段被設置爲零。 讓SSRC_r表示發送這個接收者報告的接收者。 源SSRC_n能夠計算往返傳播延遲 SSRC_r經過記錄該接收報告塊時的時間A. 接收。它使用的是計算總往返時間A-LSR 最後一個SR時間戳（LSR）字段，而後將該字段減去 （A-LSR-DLSR），將往返傳播延遲留下。這個 Schulzrinne等人 標準跟蹤[第40頁]
RFC 3550 RTP 2003年7月 如圖2所示。時間以十六進制顯示 32位字段的表示和等效的浮點數 點十進制表示。冒號表示一個32位字段 分爲16位整數部分和16位小數部分。 這能夠用做距離羣集的近似度量 接收器，儘管一些鏈路有很是不對稱的延遲。 [1995年11月10日11：33：25.125 UTC] [1995年11月10日11：33：36.5 UTC] n SR（n）A = b710：8000（46864.500 s） -------------------------------------------------- --------------> v ^ ntp_sec = 0xb44db705 v ^ dlsr = 0x0005：4000（5.250s） ntp_frac = 0x20000000 v ^ lsr = 0xb705：2000（46853.125s） （3024992005.125 s）v ^ rv ^ RR（n） -------------------------------------------------- --------------> | <-DLSR-> | （5.250秒） A 0xb710：8000（46864.500 s） DLSR -0x0005：4000（5.250 s） LSR -0xb705：2000（46853.125 s） ------------------------------- 延遲0x0006：2000（6.125秒） 圖2：往返時間計算示例 Schulzrinne等人 標準跟蹤[第41頁]
RFC 3550 RTP 2003年7月 RR：接收者報告RTCP分組 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 頭| V = 2 | P | RC | PT = RR = 201 | 長度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 包發件人SSRC | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 報告| SSRC_1（SSRC第一來源）| 塊+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + 1 | 分數損失| 累積的丟包數| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 擴展的最高序列號收到| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 到達間隔抖動| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 最後一個SR（LSR）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 自上次SR（DLSR）|以後的延遲 + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 報告| SSRC_2（第二來源SSRC）| 塊+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + 2：...： + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + | 特定於文件的擴展| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 接收方報告（RR）報文的格式與 除了分組類型字段包含常量以外的SR分組 201和發件人信息的五個字被省略（這些是 NTP和RTP時間戳以及發送者的包和八位字節計數）。 其他字段與SR數據包的含義相同。 一個空的RR包（RC = 0）務必放在一個複合的頭部 RTCP包沒有數據傳輸或接收時 報告。 擴展發件人和收件人報告 配置文件應該爲發件人定義配置文件特定的擴展名 報告和接收者報告，若是有額外的信息 須要按期報告發件人或收件人。這個 方法應該優先用於定義另外一個RTCP數據包 鍵入，由於它須要較少的開銷： o數據包中較少的八位字節（沒有RTCP頭或SSRC字段）; Schulzrinne等人 標準跟蹤[第42頁]
RFC 3550 RTP 2003年7月 更簡單和更快速的解析，由於應用程序正在運行 配置文件將被編程爲老是指望擴展字段 在接待報告後的直接訪問地點。 分機是發信人或收信人報告中的第四部分 在接收報告阻塞以後到來的分組，若是 任何。若是須要額外的發件人信息，則發件人 報告它將首先包含在擴展部分，可是 接收者報告它不會出現。若是信息 接收者將被包括在內，那麼數據應該被構造爲一個 與現有接收報告陣列平行的塊陣列 塊; 即區塊數目會由區域市政總署指明 領域。 分析發送者和接收者報告 預計接收質量反饋將不會有用 只適用於發件人，也適用於其餘收件人和第三方 顯示器。發件人能夠根據其修改傳輸 反饋; 接收者能夠肯定問題是不是本地的， 區域或全球; 網絡管理員能夠使用配置文件無關 監視器只接收RTCP數據包，而不是相應的 RTP數據包來評估其網絡的性能 組播分發。 累積計數用於發件人信息和 接收器報告塊，以即可以計算差別 任何兩份報告均可以在短時間和長期內進行測量 期間，並提供抵禦損失的報告。該 最近兩次收到的報告之間的差別能夠用來 估計最近的分配質量。NTP時間戳 被包括在內，以即可以從這些差別計算費率 在兩個報告之間的間隔。因爲時間戳是 獨立於數據編碼的時鐘速率，這是可能的 實現編碼和配置文件無關的質量監視器。 一個計算示例就是間隔內的丟包率 在兩個接待報告之間。累積的差別 丟失的數據包數量會致使在該時間間隔內丟失的數字。 所收到的最後一個序列號的差別給出了 間隔期間預期的分組數量。的比例 這兩個是間隔內的丟包率。這個比例 若是這兩個報告是應該等於分數丟失的領域 連續的，但不然可能不會。每秒的損失率能夠 經過將損失分數除以NTP的差值來得到 時間戳，以秒錶示。收到的數據包的數量是 預期的分組數目減去丟失的數目。的數量 Schulzrinne等人 標準跟蹤[第43頁]
RFC 3550 RTP 2003年7月 預期的分組也能夠用來判斷統計有效性 的任何損失估計。例如，丟失的五個數據包中有一個有一個 比1000中的200低。 從發件人信息，第三方監視器能夠計算出 平均有效載荷數據速率和平均數據包速率 間隔沒有收到數據。以二者的比例 給出平均有效載荷大小。若是能夠假設的話 丟失與數據包大小無關，而後是數據包數量 由特定接收機接收的平均有效負載大小（或 相應的分組大小）給出了表觀吞吐量 可用於該接收器。 除了容許長期數據包的累積計數以外 使用報告之間的差別進行損失測量，分數 失去的領域提供一個單一報告的短時間測量。 隨着會議規模的擴大，這變得更加劇要 接收狀態信息可能不會保留給全部的接收者 或報告之間的時間間隔變得足夠長，只有一個 報告多是從一個特定的接收器收到的。 到達間隔抖動字段提供了第二個短時間測量 網絡擁塞。數據包丟失跟蹤持續擁塞 抖動測量跟蹤瞬態擁塞。抖動測量 可能會致使擁塞，致使數據包丟失。該 到達間隔抖動場只是抖動的一個快照 報告的時間，而不是定量的。 相反，它是用來比較來自多個報告的 一個接收器隨着時間的推移或從多個接收器，例如，在一個 單一的網絡，在同一時間。容許比較 接收機，重要的是抖動按照計算 全部接收器都使用相同的公式。 由於抖動計算是基於RTP時間戳的 表示分組中的第一個數據被採樣的瞬間， 在採樣時刻和時間之間的任何延遲的變化 數據包的傳輸將會影響抖動 計算。音頻數據包會出現這種延遲的變化 持續時間不一樣 視頻編碼也會出現這種狀況，由於 對於一個幀的全部分組，時間戳是相同的 數據包並非所有同時傳輸。中的變化 延遲直到傳輸確實下降了抖動的準確度 計算做爲網絡自己的行爲的度量， 可是考慮到接收緩衝區是合適的 必須適應它。當抖動計算被用做a 比較測量，因爲變化的（恆定）份量 延遲，直到傳輸消失，使一個變化 Schulzrinne等人 標準跟蹤[第44頁]
RFC 3550 RTP 2003年7月 而後能夠觀察網絡抖動份量，除非它是相對的 小。若是變化很小，那極可能是 可有可無的。 SDES：源描述RTCP包 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 頭| V = 2 | P | SC | PT = SDES = 202 | 長度| + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 大塊| SSRC / CSRC_1 | 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + | SDES項目| | ... | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + 大塊| SSRC / CSRC_2 | 2 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | SDES項目| | ... | + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + SDES包是一個三層結構，由一個頭部和一個頭部組成 零或多個塊，每一個塊都由描述的項目組成 在該塊中標識的來源。這些項目被描述 分別在隨後的部分。 版本（V），填充（P），長度： 如SR數據包所述（見第6.4.1節）。 分組類型（PT）：8比特 包含常量202以將其標識爲RTCP SDES數據包。 源數（SC）：5位 包含在這個SDES包中的SSRC / CSRC塊的數量。一個 零值是有效的，可是沒用。 每一個塊由一個SSRC / CSRC標識符組成，後跟一個列表 零或多個項目，其中載有關於SSRC / CSRC的信息。 每一個塊在32位邊界上開始。每一個項目包括一個8- 位類型字段，一個8位八位字節計數描述的長度 文本（所以不包括這個雙字節標題）和文本 自己。請注意，文本不能超過255個八位字節，可是 這與限制RTCP帶寬消耗的須要是一致的。 Schulzrinne等人 標準跟蹤[第45頁]
RFC 3550 RTP 2003年7月 文本根據RFC 2279 [ 5 ]中規定的UTF-8編碼進行編碼。US-ASCII是這種編碼的一個子集，不須要 額外的編碼。多字節編碼的存在是 經過設置一個字符的最重要的位來表示 價值之一。 項目是連續的，即項目不是單獨填充到a 32位邊界。文本不是空終止的， 八位字節編碼包括空字節。每一個塊中的項目列表 必須由一個或多個空字節終止，其中第一個是 解釋爲零的項目類型以表示列表的結尾。 空項目類型八位字節以後沒有長度字節，可是額外的空值 必須包括八位字節，直到下一個32位爲止 邊界。請注意，此填充與表示的填充是分開的 RTCP頭中的P位。一個有零項的塊（四個空值 八位字節）是有效的，可是沒用。 終端系統發送一個包含本身的源的SDES數據包 標識符（與固定RTP報頭中的SSRC相同）。攪拌機 發送包含每一個貢獻源的塊的一個SDES包 從中收到SDES信息，或多個完整的 上述格式的SDES包若是有31個以上的話 來源（見第7節）。 目前定義的SDES項目將在下一節中介紹。 只有CNAME項是強制性的。這裏顯示的一些項目多是 只對特定配置文件有用，可是項目類型是所有的 從一個共同的空間分配，以促進共享使用和簡化 簡介獨立的應用程序。其餘項目可能被定義在 經過在IANA中註冊類型號碼來進行配置文件的描述 第15節。 CNAME：規範的終點標識符SDES項目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | CNAME = 1 | 長度| 用戶和域名... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + CNAME標識符具備如下屬性： o由於隨機分配的SSRC標識符可能會改變，若是一個 發現衝突或者程序從新啓動時，CNAME 必須包括項目以提供來自SSRC的綁定 標識符與源（發送者或接收者）的標識符 保持不變。 Schulzrinne等人 標準跟蹤[第46頁]
RFC 3550 RTP 2003年7月 o與SSRC標識符同樣，CNAME標識符也應該是 在一個RTP會話中的全部參與者中是惟一的。 o提供跨多個媒體工具的綁定 參與一組相關的RTP會話，CNAME應該是 爲該參與者固定。 o爲了方便第三方監控，CNAME應該是合適的 不管是一個程序或一我的來定位來源。 所以，CNAME應該算法導出而不是 儘量手動輸入。爲了知足這些要求， 應使用如下格式，除非配置文件指定了 備用語法或語義。CNAME項目應該有格式 若是用戶名不可用，則爲「user @ host」或「host」 用戶系統。對於這兩種格式，「主機」是徹底合格的 實時數據來源主機的域名， 根據RFC 1034 [ 6 ]，RFC 1035 [ 7 ]和RFC 1123的第2.1節 [ 8 ]中規定的規則進行格式化; 或標準的ASCII 在所使用的接口上表示主機的數字地址 用於RTP通訊。例如，標準的ASCII IP版本4地址的表示也是「點分十進制」 稱爲虛線四，IP版本6，地址是文本 以冒號分隔的十六進制數字組（以 如RFC 3513 [ 23 ]中詳述的變化）。其餘地址類型是 但願具備相互獨特的ASCII表示。該 徹底合格的域名對於觀察者來講更爲方便 而且能夠避免另外發送名稱項目的須要，可是多是這樣 在一些操做中難以或不可能得到可靠的 環境。可能在這樣的環境中運行的應用程序 應該使用地址的ASCII表示。 例子是「doe@sleepy.example.com」，「doe@192.0.2.89」或者 對於多用戶系統，「doe @ 2201：056D :: 112E：144A：1E24」。在一個系統上 沒有用戶名，例子就是「sleepy.example.com」， 「192.0.2.89」或「2201：056D :: 112E：144A：1E24」。 用戶名應當以「finger」之類的程序的形式存在 「談話」能夠使用，即它一般是登陸名而不是 我的的名字。主機名不必定徹底相同 一個在參與者的電子郵件地址中。 若是是，則此語法將不會爲每一個源提供惟一的標識符 應用程序容許用戶從一個生成多個來源 主辦。這樣的申請將不得不依靠SSRC進一步 識別來源，或該應用程序的配置文件將具備 指定CNAME標識符的附加語法。 Schulzrinne等人 標準跟蹤[第47頁]
RFC 3550 RTP 2003年7月 若是每一個應用程序獨立建立其CNAME，則生成 CNAME可能與提供綁定所需的內容不一樣 跨多個屬於一個參與者的媒體工具 相關的RTP會話。若是須要跨媒體綁定，則多是 每一個工具的CNAME須要外部配置 協調工具的價值是相同的。 應用程序編寫者應該知道專用網絡地址 例如RFC 1918 [ 24 ]中提出的Net-10分配， 可能會建立不是全球惟一的網絡地址。這個 會致使非惟一的CNAME若是主機與私人地址和 沒有直接的IP鏈接到公共互聯網的RTP 數據包經過RTP級別轉發到公共Internet 翻譯。（另見RFC 1627 [ 25 ]。）爲了處理這種狀況， 應用程序能夠提供一種手段來配置一個惟一的CNAME，可是 翻譯人員將CNAME翻譯成私人文件的負擔 地址公共地址，若是有必要保持私人地址 從被暴露。 名稱：用戶名稱SDES項目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | NAME = 2 | 長度| 通用名稱的來源... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 這是用來形容來源的真實名稱，例如「John Doe， 位再循環器「，它能夠是用戶想要的任何形式 會議等應用，這種形式的名稱多是最多的 但願在參與者列表中顯示，所以多是 最常發送CNAME之外的項目。配置文件可能 肯定這樣的重點。NAME值預計將保持不變 至少在會議期間不變。它不該該 依靠在本屆會議的全部與會者中都是獨一無二的。 電子郵件：電子郵件地址SDES項目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | EMAIL = 3 | 長度| 來源的電子郵件地址... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 電子郵件地址根據RFC 2822 [ 9 ] 格式化 例如，「John.Doe@example.com」。預計EMAIL值 在會議期間保持不變。 Schulzrinne等人 標準跟蹤[第48頁]
RFC 3550 RTP 2003年7月 PHONE：電話號碼SDES項目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | PHONE = 4 | 長度| 電話號碼的來源... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 電話號碼應該用加號來代替格式 國際接入碼。例如，「+1 908 555 1212」爲一個 在美國的數字。 LOC：地理用戶位置SDES項目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | LOC = 5 | 長度| 網站的地理位置... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 取決於應用程序，不一樣程度的細節 適合這個項目。對於會議應用程序，字符串 像「新澤西州美利山」可能就足夠了，而對於一個 積極的徽章系統，像「房間2A244，AT＆T BL MH」多是字符串 適當。細節的程度留給實施 和/或用戶，但格式和內容能夠由配置文件規定。 LOC值預計在a的持續時間內保持不變 會話，除了移動主機。 工具：應用程序或工具名稱SDES項目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | TOOL = 6 | 源程序的長度|名稱/版本。... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 一個字符串，提供應用程序的名稱和可能的版本 生成流，例如「錄像工具1.2」。這個信息可能 對於調試目的是有用的，而且相似於郵件程序或 郵件系統版本SMTP頭。預計TOOL值 在會議期間保持不變。 Schulzrinne等人 標準跟蹤[第49頁]
RFC 3550 RTP 2003年7月 注意：通知/狀態SDES項目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 注= 7 | 長度| 請注意有關來源... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 爲這個項目建議如下語義，但這些或 其餘語義能夠由配置文件顯式定義。筆記 項目用於描述當前狀態的瞬態消息 的來源，例如「在電話中，不能說話」。或者，在一個 研討會，這個項目可能被用來表達對話的標題。它 應該只用來攜帶特殊的信息，不該該 被全部參與者按期包括在內，由於這會慢 下降接收報告和CNAME發送的速率 損害協議的性能。特別是，它應該 不做爲一個項目包含在用戶的配置文件也不包括在內 自動生成，現在天的報價。 因爲NOTE項目在激活時可能很重要， 其餘非CNAME項目（如NAME）的傳輸速率 可能會減小，因此NOTE項能夠佔用RTCP的那部分 帶寬。當瞬態消息變爲無效時，注意 項目應該繼續傳送幾回相同 重複率但用一串長度爲零的信號來表示 接收器。可是，接收者也應該考慮注意項目 若是沒有收到一小部分重複，則無效 速率，或者20-30 RTCP間隔。 PRIV：私有擴展SDES項目 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | PRIV = 8 | 長度| 前綴長度|前綴字符串... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + ... | 值字符串... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 此項目用於定義實驗或特定於應用程序的SDES 擴展。該項目包含由長度字符串組成的前綴 隨後是填充項目其他部分的值字符串 並攜帶所需的信息。前綴長度字段是8 位長。前綴字符串是由人員定義的名稱 該PRIV項目是獨一無二的其餘PRIV項目 應用可能會收到。應用程序建立者可能會選擇 使用應用程序名稱加上附加的子類型標識 Schulzrinne等人 標準跟蹤[第50頁]
RFC 3550 RTP 2003年7月 須要。或者，建議其餘人選擇一個名字 基於它們所表明的實體，而後協調使用 該實體內的名稱。 請注意，前綴會消耗項目總數中的一些空間 長度爲255個八位字節，因此前綴應該保持爲短 可能。這個設施和受約束的RTCP帶寬應該 不要超載; 並非要知足全部的控制 全部應用程序的通訊要求。 SDES PRIV前綴不會由IANA註冊。若是某種形式的 PRIV項目被證實是通用的，它應該是 指定了一個按期的SDES項目類型在IANA註冊，因此沒有 前綴是必需的。這簡化了使用並增長了傳輸 效率。 BYE：再見RTCP分組 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | V = 2 | P | SC | PT = BYE = 203 | 長度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | SSRC / CSRC | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + ：...： + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + = + （opt）| 長度| 離開的緣由 ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + BYE數據包表示一個或多個源再也不 活性。 版本（V），填充（P），長度： 如SR數據包所述（見第6.4.1節）。 分組類型（PT）：8比特 包含常量203以將其標識爲RTCP BYE分組。 源數（SC）：5位 此BYE包中包含的SSRC / CSRC標識符的數量。 計數值爲零是有效的，可是沒用。 應該發送BYE包的規則在中指定6.3.7和8.2 節。 Schulzrinne等人 標準跟蹤[第51頁]
RFC 3550 RTP 2003年7月 若是BYE包被混頻器接收到，混頻器應該轉發 具備SSRC / CSRC標識符的BYE分組不變。若是一臺攪拌機 關閉，它應該發送一個BYE數據包列出全部的貢獻 它處理的來源，以及它本身的SSRC標識符。（可選） BYE包可能包含一個8位八位字節計數，而後是許多 指示離開緣由的文本的八位字節，例如「相機」 故障「或」檢測到RTP迴路「，字符串相同 如SDES所描述的編碼。若是字符串填充數據包 到下一個32位的邊界，字符串不是空終止的。若是 不是，BYE包必須用空的八位字節填充到下一個32位字節， 位邊界。該填充與P所示的填充是分開的 位在RTCP頭。 APP：應用程序定義的RTCP數據包 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | V = 2 | P | 子類型| PT = APP = 204 | 長度| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | SSRC / CSRC | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 名稱（ASCII）| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | 應用程序依賴的數據... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + APP數據包旨在做爲新的應用程序的實驗使用 而且開發了新的功能，而不須要包類型值 註冊。具備沒法識別名稱的APP數據包應該被忽略。 通過測試，若是更普遍的使用是合理的，建議 每一個APP包都被從新定義，而沒有子類型和名稱字段 使用RTCP數據包類型向IANA註冊。 版本（V），填充（P），長度： 如SR數據包所述（見第6.4.1節）。 子類型：5位 能夠用做子類型來容許一組APP數據包 在一個惟一的名稱下定義，或者用於任何依賴於應用程序 數據。 分組類型（PT）：8比特 包含常量204以將其標識爲RTCP APP分組。 Schulzrinne等人 標準跟蹤[頁52]
RFC 3550 RTP 2003年7月 名稱：4個八位字節 定義一組APP數據包的人選擇的名字 對於這個應用程序可能的其餘APP數據包是惟一的 接收。應用程序建立者可能會選擇使用 應用程序名稱，而後協調子類型的分配 值給其餘想要定義新數據包類型的人 應用。或者，建議其餘人選擇 基於它們所表明的實體的名稱，而後協調使用 該實體內的名稱。名字被解釋爲a 四個ASCII字符序列，大寫和小寫 被視爲不一樣的字符。 應用程序相關數據：可變長度 應用程序相關的數據可能會或可能不會出如今APP數據包中。 它由應用程序解釋，而不是RTP自己。它必須 是32位長的倍數。 。 除了終端系統以外，RTP還支持「翻譯員」的概念， 和「攪拌機」，能夠被視爲「中間系統」 RTP級別。雖然這種支持增長了一些複雜性 議定書，對這些職能的需求已經明確肯定 經過在多播音頻和視頻應用中的實驗 互聯網。第 2.3 節中給出的翻譯器和混音器的使用例子來自防火牆和低帶寬 鏈接，這二者均可能保持。 概述 RTP轉換器/混頻器鏈接兩個或更多的傳輸級別 「雲」。一般，每一個雲由一個公共網絡定義 傳輸協議（如IP / UDP）加上一個多播地址和 傳輸級別目標端口或一對單播地址和 端口。（網絡級協議翻譯器，如IP版本4到 IP版本6，可能沒法在RTP中呈如今雲中） 系統能夠做爲多個RTP的翻譯器或混音器 會議，但每一個會議都被視爲一個邏輯上獨立的實體。 爲了不在翻譯器或混音器時產生循環 安裝，必須遵照如下規則： o由翻譯器和混音器鏈接的每一個雲 參與一個RTP會話必須與全部的不一樣 至少其中一個參數（協議，地址， 端口），或者必須與其餘網絡隔離。 Schulzrinne等人 標準跟蹤[第53頁]
RFC 3550 RTP 2003年7月 o第一條規則的衍生物不能是多重的 翻譯器或混音器並聯，除非有一些 他們安排他們劃分要轉發的來源的集合。 一樣，全部能夠經過一個或多個通訊進行通訊的RTP終端系統 更多的RTP轉換器或混音器共享相同的SSRC空間，也就是說， 全部這些終端系統中的SSRC標識符必須是惟一的。 8.2節描述了由哪一個碰撞解決算法 SSRC標識符保持惟一，並檢測到循環。 可能有許多品種的翻譯和攪拌機設計 不一樣的目的和應用。一些例子是添加或 刪除加密，更改數據或底層的編碼 協議，或在多播地址和一個或多個地址之間複製 單播地址。譯員和混音師之間的區別是 翻譯者經過不一樣的數據流 分別來源，而混音器結合起來，造成一個新的 流： 轉換器：使用SSRC標識符轉發RTP數據包 完整; 這使接收機可以識別 即便來自全部來源的數據包經過 經過同一位譯者並攜帶翻譯者的網絡 源地址。有些翻譯會經過翻譯 數據不變，但其餘人可能會改變數據的編碼 所以RTP數據淨荷類型和時間戳。若是有多個數據 數據包被從新編碼爲一個，反之亦然，一個翻譯器必須 分配新的序列號到傳出的數據包。損失 傳入的分組流可能引發相應的間隙 傳出序號。接收器沒法檢測到存在 除非他們經過其餘手段知道什麼有效載荷 類型或傳輸地址被原始源使用。 混音器：接收來自一個或多個RTP數據包的流 來源，可能會改變數據格式，合併流入 以某種方式，而後轉發組合的流。自從 多個輸入源之間的時序一般不會 同步，調音臺之間會進行定時調節 併爲合併流生成本身的時間，因此它 是同步源。所以，全部的數據包轉發 由混頻器必須標記混頻器本身的SSRC標識符。 爲了保留原始來源的身份 有助於混合包，攪拌機應該插入他們的 SSRC標識符進入CSRC標識符列表後的固定 數據包的RTP頭。攪拌機也是本身的 某些數據包的貢獻源應該明確地包含它 在該CSRC列表中擁有SSRC標識符。 Schulzrinne等人 標準跟蹤[第54頁]
RFC 3550 RTP 2003年7月 對於某些應用來講，混音器可能不被接受 肯定中國證監會名單上的來源。不過，這個介紹了 涉及這些來源的循環的危險沒法被發現。 一個混音器的優勢，而不是翻譯器的應用程序 音頻是輸出帶寬被限制到一個源的輸出帶寬 即便在輸入端有多個源是活動的。這多是 對於低帶寬鏈路很重要。缺點是這樣的 輸出端的接收器不能控制哪一個接收器 來源是經過或靜音，除非有一些機制 實施用於調音臺的遠程控制。再生的 混音器的同步信息也意味着接收器不能 作原始流的媒體間同步。多層次 媒體混音器能夠作到。 [ E1 ] [E6] | | E1：17 | E6：15 | | | E6：15 V M1：48（1,17）M1：48（1,17）V M1：48（1,17） （M1）-------------> <T1> -----------------> <T2> --------- -----> [E7] ^ ^ E4：47 ^ E4：47 E2：1 | E4：47 | | M3：89（64,45） | | | [E2] [E4] M3：89（64,45）| | 傳說： [E3] --------->（M2）----------->（M3）------------ | [結束系統] E3：64M2:12（64）^（混合器） | E5：45 <譯者> | [E5]來源：SSRC（中國證監會） -------------------> 圖3：帶終端系統，混音器和轉換器的示例RTP網絡 混合器和翻譯器的集合如圖3所示 說明它們對SSRC和CSRC標識符的影響。在圖中， 最終系統顯示爲矩形（名爲E），譯者爲 三角形（名爲T）和混合器（橢圓形）（名爲M）。符號「M1： 48（1,17）「表示發起混頻器M1的數據包，由標識 M1的（隨機）SSRC值48和兩個CSRC標識符1和17， 從E1和E2的分組的SSRC標識符中複製。 翻譯器中的RTCP處理 除了轉發數據包，也許是修改過的翻譯 混音器也必須處理RTCP數據包。在不少狀況下，他們會 把從終端系統接收到的複合RTCP分組拆開 Schulzrinne等人 標準跟蹤[第55頁]
RFC 3550 RTP 2003年7月 聚合SDES信息並修改SR或RR數據包。 該信息的重傳能夠由分組觸發 到達或經過翻譯器或混音器的RTCP間隔定時器 自己。 不修改數據包的翻譯器，例如一個 只是在多播地址和單播之間進行復制 地址，也能夠簡單地轉發RTCP數據包。一個 翻譯器以某種方式轉換有效載荷必須作出 在SR和RR信息中進行相應的轉換使之成爲可能 仍然反映了數據和接待的特色 質量。這些轉換器不能簡單地轉發RTCP數據包。在 通常來講，翻譯者不該該從中聚合SR和RR數據包 不一樣的來源到一個數據包，由於這會減小 基於LSR和LSR的傳播時延測量精度 DLSR字段。 SR發件人信息：譯員不會自行生成 發送者信息，但轉發從一個接收到的SR數據包 雲對其餘人。SSRC保持不變，但發件人 若是翻譯須要，信息必須修改。若是一個 翻譯者改變數據編碼，它必須改變「發件人的 字節計數「字段，若是它也將幾個數據包合併成的話 一個輸出包，它必須改變「發送者的包計數」 領域。若是它改變時間戳頻率，它必須改變 SR包中的「RTP時間戳」字段。 SR / RR接收報告塊：轉換器轉發接收 從一個雲收到的報告給其餘人。請注意這些 流向與數據相反的方向。SSRC離開了 完整。若是一個翻譯器將多個數據包合併爲一個 輸出數據包，所以改變序列號，它必須 對數據包丟失字段進行逆操做 「擴展的最後序號」字段。這多是複雜的。在 極端的狀況下，可能沒有有意義的翻譯方式了 接待報告，因此翻譯可能沒有接收 根據本身的接待報告或綜合報告。 通常的規則是作一些有意義的事情 翻譯。 翻譯者不須要本身的SSRC標識符，可是 能夠選擇分配一個用於發送報告 關於它收到了什麼。這些將被髮送到全部的 鏈接雲，每一個對應的翻譯 數據流發送到該雲，由於接收報告 一般多播給全部參與者。 Schulzrinne等人 標準跟蹤[第56頁]
RFC 3550 RTP 2003年7月 SDES：翻譯者一般在不改變SDES的狀況下轉發 他們收到的信息從一個雲到另外一個，但可能， 例如，若是決定過濾非CNAME SDES信息 帶寬有限。CNAME必須被轉發以容許SSRC 標識符碰撞檢測工做。一位翻譯 生成本身的RR數據包必須發送SDES CNAME信息 關於它本身到相同的雲發送那些RR數據包。 BYE：轉換器轉發BYE數據包不變。翻譯者 即將中止轉發數據包應發送BYE數據包 到包含全部SSRC標識符的每一個鏈接的雲 之前被轉發到那個雲，包括 翻譯者本身的SSRC標識符，若是它發送本身的報告。 APP：翻譯器轉發APP數據包不變。 混音器中的RTCP處理 因爲混音器本身產生一個新的數據流，因此沒有 經過SR或RR數據包，而不是產生新的 雙方信息。 SR發送者信息：調音臺不經過發送者 來自它所混合的來源的信息，由於這些特徵 的源流在混合中丟失。做爲同步 源，混頻器應該與發送者生成本身的SR數據包 有關混合數據流的信息並將其發送到相同的位置 方向做爲混合流。 SR / RR接收報告塊：一個混頻器產生它本身的 接收每一個雲中源的報告並將其發送出去 只對同一個雲。它不能發送這些接收報告 到其餘雲端，不得轉發接收報告 一個雲，由於來源不會是SSRC 那裏（只有中國證監會）。 SDES：攪拌機一般在沒有改變SDES的狀況下前進 他們收到的信息從一個雲到另外一個，但可能， 例如，若是決定過濾非CNAME SDES信息 帶寬有限。CNAME必須被轉發以容許SSRC 標識符碰撞檢測工做。（中國證監會的一個標識符 由混頻器生成的列表可能與SSRC標識符衝突 由一個終端系統生成）。混音器必須發送SDES CNAME 關於它本身的信息到它發送SR或RR的相同的雲 數據包。 Schulzrinne等人 標準跟蹤[第57頁]
RFC 3550 RTP 2003年7月 因爲混頻器不轉發SR或RR數據包，它們一般會 從複合RTCP數據包中提取SDES數據包。至 儘可能減小開銷，能夠聚合來自SDES分組的塊 轉換成單個SDES分組，而後將其堆疊在SR或RR上 來自混音器的數據包。一個混合器，聚合SDES 數據包將使用比單個源更多的RTCP帶寬 由於複合包將會更長，可是 由於混合器表明多個來源。 相似地，一個混合器按原樣穿過SDES包 收到的將會傳輸高於RTCP的數據包 單一來源的速率，可是這也是正確的，由於數據包 來自多個來源。RTCP數據包速率可能不一樣 在攪拌機的每一邊。 不插入CSRC標識符的混音器也能夠不作 從轉發SDES CNAMEs。在這種狀況下，SSRC標識符 兩個雲中的空間是獨立的。如前面提到的， 這種操做模式會產生循環不能的危險 檢測。 BYE：混音器必須轉發BYE數據包。一個即將到來的混音器 中止轉發數據包應該向每一個發送一個BYE數據包 所鏈接的雲包含全部的SSRC標識符 之前被轉發到該雲，包括混音器 若是它發送本身的報告，則擁有SSRC標識符。 APP：經過混音器處理APP數據包是特定於應用程序的。 級聯攪拌機 RTP會話可能涉及一系列混音器和翻譯器 如圖3所示。若是兩個混頻器級聯，如M2和M3中 這個數字，混音器收到的數據包可能已經混合在一塊兒了 而且能夠包括具備多個標識符的CSRC列表。第二 調音臺應該創建傳出的數據包使用CSRC列表 來自已經混合的輸入數據包和SSRC的CSRC標識符 標識符來自未混合的輸入數據包。這在輸出中顯示 來自M3中標記爲M3：89（64,45）的混頻器M3。正如在這種狀況下 若是由此產生的CSRC清單有更多，則不會級聯 超過15個標識符，其他不能包含在內。 Schulzrinne等人 標準跟蹤[頁碼58]
RFC 3550 RTP 2003年7月 。 在RTP頭和各個字段中攜帶的SSRC標識符 的RTCP數據包是一個隨機的32位數字是必需的 在RTP會話中是全球惟一的。這個數字是相當重要的 請慎重選擇，以便參與者在同一個網絡上 同時開始不可能選擇相同的號碼。 這是不足以使用本地網絡地址（如一個 IPv4地址）做爲標識符，由於地址可能不是 獨特。因爲RTP轉換器和混音器可以實現互操做 具備不一樣地址空間的多個網絡，分配 在兩個空間內的地址模式可能會致使不少 與隨機分配相比，更高的碰撞率。 在一臺主機上運行的多個源也會發生衝突。 簡單地經過得到SSRC標識符也是不夠的 調用random（）而不仔細初始化狀態。一個 介紹如何生成一個隨機標識符的例子 附錄A.6。 碰撞的可能性 因爲標識符是隨機選擇的，因此有多是兩個或者兩個 更多的來源將選擇相同的號碼。碰撞發生了 全部來源同時開始的最高几率 例如某些會話管理自動觸發 事件。若是N是來源的數量和L的長度 標識符（這裏是32位），兩個來源的機率 獨立選取相同的值能夠近似爲大N [ 26 ]如1 - EXP（-N **2分之2**（L + 1））。對於N = 1000，機率是 大約10 ** - 4。 典型的碰撞機率遠低於最壞的狀況 以上。當一個新的源加入一個RTP會話時， 其餘來源已經有惟一的標識符的機率 碰撞只是空間中使用的數字的一小部分。 再次，若是N是來源的數量和L的長度 標識符，碰撞的機率是N / 2 ** L。對於N = 1000， 機率大概是2 * 10 ** - 7。 機會進一步減小了碰撞的可能性 用於接收來自其餘參與者的數據包的新來源 發送它的第一個數據包（數據或控制）。若是新來源 跟蹤其餘參與者（經過SSRC標識符），而後 Schulzrinne等人 標準跟蹤[第59頁]
RFC 3550 RTP 2003年7月 在發送第一個數據包以前，新的源能夠驗證 它的標識符不會與任何已經收到的相沖突，或者 不然再選擇。 碰撞分辨率和迴路檢測 儘管SSRC標識符衝突的機率很低，但全部的RTP 實現必須準備好檢測碰撞並採起行動 採起適當的行動來解決它們 若是一個來源發現任何 另外一個來源正在使用與其相同的SSRC標識符 本身，它必須發送一個RTCP BYE包的舊標識符和 選擇另外一個隨機的。（以下所述，這一步是採起的 只有一次，若是一個循環。）若是一個接收器發現了另外兩個 來源正在衝突，它能夠保持來自一個和丟棄的數據包 來自其餘的數據包時，這能夠被檢測到不一樣的 源傳輸地址或CNAME。預計這兩個來源 解決衝突，使狀況不會持續下去。 由於隨機的SSRC標識符是全局惟一的 RTP會話，它們也能夠用來檢測可能的循環 由混音師或翻譯員介紹。循環致使重複 數據和控制信息，不管是未修改的仍是可能的混合的 在下面的例子中： o轉換器可能會錯誤地將數據包轉發到相同的地方 從中接收到數據包的多播組 直接或經過一連串的翻譯。在這種狀況下， 相同的數據包出現幾回，源自不一樣 網絡來源。 o兩名譯員錯誤地並行設置，即與 兩邊相同的組播組都會轉發報文 從一個多播組到另外一個多播組。單向翻譯器 會產生兩份; 雙向翻譯將造成一個 循環。 o調音臺能夠經過發送到相同的傳輸器來關閉一個循環 直接或間接接收數據包的目的地 經過另外一個混音器或翻譯器。在這種狀況下，一個來源可能 在一個數據包和一個混合的CSRC中都顯示SSRC 數據包。 源可能會發現它本身的數據包正在循環，或者 來自另外一個來源的數據包正在循環（第三方循環）。 循環和碰撞在隨機選擇一個源 標識符致使分組以相同的SSRC標識符到達 可是一個不一樣的源碼傳輸地址，多是這個地址的 終端系統始發數據包或中間系統。 Schulzrinne等人 標準跟蹤[頁碼60]
RFC 3550 RTP 2003年7月 所以，若是源更改其源傳輸地址，則可能 也選擇一個新的SSRC標識符，以免被解釋爲一個 循環的來源。（這不是必須的，由於在RTP的一些應用中 來源可能會在會議期間改變地址。）注意 若是翻譯者從新啓動並所以改變源 傳輸地址（例如，更改UDP源端口號） 它轉發數據包，而後全部這些數據包將出如今接收者 因爲SSRC標識符是由原始的應用而被循環的 來源並不會改變。保持這個問題是能夠避免的 在從新啓動時固定的源傳輸地址，但不管如何 將在接收器超時後解決。 在翻譯者或者翻譯者的另外一邊出現循環或者碰撞 若是所有使用源傳輸地址，則不能檢測到混頻器 數據包的副本經過翻譯器或混音器，可是， 當來自兩個RTCP SDES的塊時仍可能檢測到衝突 數據包包含相同的SSRC標識符但不一樣的CNAME。 爲了檢測和解決這些衝突，一個RTP實現必須 包括一個相似於下面描述的算法，雖然 實現能夠選擇一個不一樣的包來自哪一個策略 相沖突的第三方來源保存。所描述的算法 下面忽略來自與源相沖突的新源或循環的數據包 肯定來源。它解決了與參與者的衝突 經過爲舊的標識符發送一個RTCP BYE來擁有SSRC標識符 選擇一個新的。可是，當碰撞被誘導時 循環參與者本身的數據包，算法將選擇一個 新的標識符只有一次，而後忽略數據包 循環源傳輸地址。這是爲了不洪水 的BYE數據包。 這個算法須要保留一個由源索引的表 標識符幷包含源傳輸地址 第一RTP分組和用該標識符接收的第一RTCP分組， 連同其餘國家的來源。兩源運輸 由於例如UDP源端口，因此須要地址 RTP和RTCP數據包的號碼可能不一樣。可是，它多是 假定兩個源傳輸中的網絡地址是相同的 地址。 在RTP或RTCP包中收到的每一個SSRC或CSRC標識符是 在源標識符表中查找，以便處理它 數據或控制信息。源傳輸地址 數據包與中對應的源傳輸地址進行比較 該表檢測循環或碰撞，若是他們不匹配。對於 控制數據包，每一個元素都有本身的SSRC標識符 例如SDES塊，須要單獨的查找。（SSRC 接收報告塊中的標識符是一個例外，由於它 Schulzrinne等人 標準跟蹤[頁碼61]
RFC 3550 RTP 2003年7月 肯定了記者聽到的來源，以及SSRC標識符 與發送的RTCP數據包的源傳輸地址無關 由記者。）若是SSRC或證監會沒有找到，一個新的條目是 建立。這些表項在RTCP BYE包被刪除時被刪除 接收到相應的SSRC標識符並通過驗證 匹配源傳輸地址，或在沒有數據包到達以後 相對較長時間（見第6.2.1節）。 請注意，若是同一主機上的兩個信號源正在傳輸 在接收機開始操做時，它是相同的源標識符 將有可能收到的第一個RTP包來自其中一個 第一個RTCP數據包收到來自另外一個來源。 這會致使錯誤的RTCP信息與 RTP數據，可是這種狀況應該足夠罕見和無害 這可能會被忽視。 爲了跟蹤參與者本身的數據包的循環， 實現也必須保留一個單獨的源碼傳輸列表 地址（而不是標識符）已經被發現有衝突。 如源標識符表中那樣，有兩個源傳輸地址 務必保持分開跟蹤衝突的RTP和RTCP數據包。 請注意，衝突的地址列表一般應該很短 空。此列表中的每一個元素都存儲源地址加 接收到最近衝突的數據包的時間。一個 元素能夠在沒有衝突的分組時從列表中移除 10 RTCP報告的順序來自該來源一段時間 間隔（見第6.2節）。 對於所示的算法，假定參與者本身的 源標識符和狀態被包括在源標識符中 表。該算法能夠重構，首先作一個單獨的 與參與者本身的源標識符進行比較。 若是（SSRC或CSRC標識符未在源中找到 標識符表）{ 建立一個存儲數據或控制源的新條目 運輸地址，SSRC或者CSRC等國家; } / *標識符在表格中找到* / 不然若是（表項是在收到控制包時建立的 這是第一個數據包，反之亦然）{ 從這個包中存儲源傳輸地址; } 不然若是（來自數據包的源傳輸地址不匹配 保存在這個標識符的表項中的那個）{ Schulzrinne等人 標準跟蹤[第62頁]
RFC 3550 RTP 2003年7月 / *標識符衝突或循環被指示* / 若是（源標識符不是參與者本身的）{ / *可選的錯誤計數器步驟* / 若是（源標識符來自RTCP SDES塊 包含與CNAME不一樣的CNAME項目 在表格中）{ 計算第三方碰撞; } else { 統計第三方循環; } 停止數據包或控制元素的處理; / *能夠選擇不一樣的政策來保持新的來源* / } / *參與者本身的數據包的衝突或循環* / 不然若是（源傳輸地址在列表中找到 衝突的數據或控制源傳輸 地址）{ / *可選的錯誤計數器步驟* / 若是（源標識符不是來自RTCP SDES塊 包含一個CNAME項目或CNAME是 參與者本身的）{ 統計本身的交通事件的發生; } 在衝突的地址列表條目中標記當前時間; 停止數據包或控制元素的處理; } / *新的碰撞，更改SSRC標識符* / else { 日誌發生碰撞; 在衝突的數據或控件中建立一個新條目 源傳輸地址列表並標記當前時間; 用舊的SSRC標識符發送一個RTCP BYE包; 選擇一個新的SSRC標識符; 在源標識符表中建立一個新條目 舊的SSRC加上源傳輸地址 正在處理的數據或控制分組; } } 在這個算法中，來自新衝突的源地址的數據包 將被忽略，而且來自原始源地址的分組將被忽略 保持。若是沒有數據包從原始源到達擴展 期間，表格條目將被超時而且新的來源將是 Schulzrinne等人 標準跟蹤[頁63]
RFC 3550 RTP 2003年7月 可以接管。若是原始來源檢測到這可能會發生 碰撞和移動到一個新的源標識符，但在平時 若是一個RTCP BYE包將從原始源接收到 刪除狀態而沒必要等待超時。 若是經過混音器接收到原始源地址（即， 做爲中國證監會學習），後來直接收到同一來源， 建議接收方切換到新的源地址 除非混合中的其餘來源將會丟失。並且，由於 諸如移動電話之類的應用，諸如電話 實體可能會在RTP會話過程當中更改地址， RTP實現應該修改碰撞檢測 算法來接受來自新源傳輸地址的分組。 爲了防止地址之間的翻轉若是真的 碰撞確實發生，算法應該包括一些手段 檢測到這種狀況並避免切換。 當因爲碰撞而選擇新的SSRC標識符時， 候選人標識符應首先在源代碼中查找 標識符表來查看它是否已經被其餘人使用 資源。若是是這樣，則必須生成另外一個候選者和過程 重複。 數據包到組播目的地的循環會致使嚴重 網絡氾濫。全部的混音器和轉換器必須執行一個循環 像這樣的檢測算法，以便它們能夠打破循環。 這應該限制多餘的流量不超過一個重複 原始流量的副本，這可能會讓會話繼續 這樣能夠找到並修復循環的緣由。可是，在 極端的狀況下，混音器或翻譯不能正確地打破 循環和高流量水平的結果，多是必要的 系統徹底中止傳輸數據或控制數據包。這個 決定可能取決於應用程序。一個錯誤條件應該 應適當代表。傳輸可能會再次嘗試 按期在一個漫長的隨機時間以後（大約幾分鐘）。 使用分層編碼 對於在單獨的RTP會話中傳輸的分層編碼（請參閱 第2.4節），一個單一的SSRC標識符空間應該被使用 應該使用全部圖層和核心（基礎）層的會話 用於SSRC標識符分配和衝突解決。當一個 源發現它已經發生了衝突，它發送一個RTCP BYE 數據包僅在基本層上，但將SSRC標識符更改成 全部層面的新價值。 Schulzrinne等人 標準跟蹤[頁碼64]
RFC 3550 RTP 2003年7月 。 低層協議可能最終提供全部的安全性 包括RTP應用程序可能須要的服務 認證，完整性和機密性。這些服務有 在[ 27 ]中被指定爲IP 。自從最初的音頻和視頻 在此以前，使用RTP的應用程序須要保密服務 服務可用於IP層，保密服務 在下一節中描述的被定義爲與RTP和RTCP一塊兒使用。 這裏的描述包含在現有的實踐中。新 RTP的應用能夠實現這個RTP特有的機密性 爲了向後兼容服務，和/或他們能夠實現 替代安全服務。在RTP協議上的開銷 這個保密服務是低的，因此罰款將是最小的 若是這個服務未來被其餘服務所淘汰。 或者，其餘服務，服務的其餘實現 其餘算法可能在將來爲RTP定義。在 特別是一個名爲安全實時傳輸協議的RTP配置文件 （SRTP）[ 28 ]正在開發中，以提供RTP的機密性 有效載荷，同時使RTP頭部保持清晰，以便鏈路級別 頭壓縮算法仍然能夠運行。預計 SRTP將是許多應用程序的正確選擇。SRTP是基於的 在高級加密標準（AES）和提供更強大的 安全性比這裏描述的服務。沒有人聲稱是 這裏介紹的方法適用於特定的安全性 須要。配置文件能夠指定哪些服務和算法應該是 由應用程序提供，並可能爲其提供指導 適當的使用。 密鑰分發和證書不在此範圍以內 文件。 保密 機密性意味着只有預期的接收機才能解碼 接收到的數據包; 對於其餘人來講，數據包沒有用處 信息。內容的保密性是經過 加密。 當須要根據該方法對RTP或RTCP進行加密時 在本節中指定，將被封裝的全部八位字節 在一個單一的低層數據包傳輸做爲一個加密 單元。對於RTCP，必須爲每一個單元從新繪製一個32位的隨機數 在加密以前添加到本機。對於RTP，沒有前綴 前置; 而是序列號和時間戳字段 用隨機偏移初始化。這被認爲是一個弱點 Schulzrinne等人 標準跟蹤[第65頁]
RFC 3550 RTP 2003年7月 初始化矢量（IV）因爲隨機性較差。在 此外，若是後來的領域，SSRC，能夠被操縱 敵人，加密方法還有進一步的弱點。 對於RTCP，一個實現能夠分離單獨的RTCP數據包 在一個複合RTCP包中分紅兩個獨立的複合RTCP包， 一個要加密，一個要明文發送。例如， 接收報告發送時，SDES信息可能會被加密 明確地容納不知道的第三方監視器 到加密密鑰。在這個例子中，如圖4所示，SDES 信息必須附加到沒有報告的RR數據包（和 隨機數）來知足全部複合RTCP的要求 數據包以SR或RR數據包開始。SDES CNAME項目是 須要在加密或未加密的數據包中，但不能同時使用。 相同的SDES信息不該該被攜帶在兩個數據包中 這可能會危及加密。 UDP數據包UDP數據包 ----------------------------- --------------------- --------- [random] [RR] [SDES #CNAME ...] [SR #senderinfo＃site1＃site2] ----------------------------- --------------------- --------- 加密不加密 ＃：SSRC標識符 圖4：加密和未加密的RTCP數據包 加密的存在和使用正確的密鑰是 由接收器經過報頭或有效載荷有效性檢查來確認。 給出了RTP和RTCP頭的這種有效性檢查的例子 在附錄A.1和A.2中。 與現有的初始實現一致 在RFC 1889中規定了RTP ，默認的加密算法是 數據加密標準（DES）算法在密碼塊鏈中 （CBC）模式，如RFC 1423 [ 29 ] 第1.1節所述，除了 填充到8個八位字節的倍數如P所述 位於5.1節。初始化矢量由於隨機而爲零 值在RTP頭部或由隨機前綴提供 複合RTCP分組。有關使用CBC初始化的詳細信息 載體，參見[ 30 ]。 支持這裏指定的加密方法的實現 應該始終支持CBC模式下的DES算法做爲默認值 密碼爲這個方法最大化互操做性。這個方法是 由於它已被證實是簡單實用的 用於實驗音頻和視頻工具的操做上 互聯網。然而，從那之後，DES被發現太容易被破壞。 Schulzrinne等人 標準跟蹤[頁碼66]
RFC 3550 RTP 2003年7月 推薦使用更強的加密算法，如 使用Triple-DES代替默認算法。此外， 安全的CBC模式要求每一個數據包的第一個塊被異或 與密碼塊大小相同的隨機獨立IV 尺寸。對於RTCP，這是（部分）經過預先分配來實現的 數據包與一個32位隨機數，每一個獨立選擇 包。對於RTP，時間戳和序列號從隨機開始 值，但連續的數據包不會被獨立隨機化。 應該指出，在這兩種狀況下的隨機性（RTP和RTCP） 是有限的。高安全性的應用程序應該考慮其餘，更多 常規，保護手段。其餘加密算法能夠 經過非RTP方式爲會話動態指定。尤爲是，基於AES 的SRTP協議[ 28 ]正在開發中 賬戶已知的明文和CBC明文操做的擔心，和 將是將來的正確選擇。 做爲IP級別或RTP級別加密的替代方案 如上所述，配置文件能夠定義額外的有效載荷類型 加密的編碼。這些編碼必須指定如何填充和 加密的其餘方面將被處理。這種方法 容許只加密數據，同時保留頭文件 在須要的地方清除應用程序。這多是特別的 有用的硬件設備，將處理解密和 解碼。這對連接級別的應用程序也頗有價值 RTP和下層頭部的壓縮是指望的 有效載荷的機密性（但不是地址）就足夠了 由於標題的加密排除了壓縮。 身份驗證和消息完整性 身份驗證和消息完整性服務沒有定義在 RTP級別，由於這些服務沒有沒有直接的可行性 關鍵的管理基礎設施 預計認證 完整性服務將由低層協議提供。 。 Internet上使用的全部傳輸協議都須要解決 擁塞控制在某種程度上[ 31 ]。RTP不是例外，可是 由於經過RTP傳輸的數據一般是非彈性的（生成的 以固定或控制的速度），控制擁堵的手段 RTP可能與其餘傳輸協議的RTP很不相同 如TCP。從某種意義上說，非彈性下降了風險 擁塞，由於RTP流不會擴展到消耗所有 可用帶寬做爲TCP流能夠。可是，也是非彈性的 意味着RTP流不能任意減小其負載 網絡在發生擁塞時消除。 Schulzrinne等人 標準跟蹤[第67頁]
RFC 3550 RTP 2003年7月 因爲RTP可能在許多應用中被普遍使用 不一樣的上下文，沒有單一的擁塞控制機制 這將爲全部人工做。因此擁塞控制應該是 在每一個RTP配置文件中定義。對於一些配置文件，它 可能足以包含適用性聲明的限制 將該配置文件用於避免擁塞的環境 經過工程。對於其餘配置文件，具體方法如數據 可能須要基於RTCP反饋的速率適配。 。 本部分描述了在內部攜帶RTP數據包的具體問題 特定的網絡和傳輸協議。如下規則 除非在此以外被特定於協議的定義取代 規範。 RTP依賴底層協議來提供多路分解 RTP數據和RTCP控制流。對於UDP和相似的協議， RTP應該使用一個偶數目的端口號和相應的 RTCP流應該使用下一個更高（奇數）的目的端口號。 對於將單個端口號做爲參數的應用程序和 若是是奇數，則從該數字派生RTP和RTCP端口對 被提供，那麼應用程序應該用該替換該數字 下一個較低（偶數）做爲端口對的基礎。對於 RTP和RTCP目標端口號的應用程序 經過明確的，單獨的參數指定（使用信令 協議或其餘方式），應用程序可能會忽略 限制端口號是偶數/連續的 儘管使用偶數/奇數端口對仍然受到鼓勵。該 RTP和RTCP端口號不能相同，由於RTP依賴 用於解複用RTP數據和RTCP控制的端口號 流。 在單播會話中，兩個參與者都須要識別一個端口對 用於接收RTP和RTCP數據包。兩位參與者均可以使用 相同的端口對。參與者不得假定源端口 傳入的RTP或RTCP數據包能夠用做目的地 端口用於傳出RTP或RTCP數據包。當RTP數據包是 在兩個方向發送，每一個參與者的RTCP SR數據包 必須發送到其餘參與者指定的端口 接收RTCP。RTCP SR數據包組合了發送者信息 爲傳出數據加接收報告信息 傳入數據。若是一方不主動發送數據（見第 6.4 節），則發送一個RTCP RR數據包。 建議分層編碼應用程序（見第 2.4 節）使用一組連續的端口號。端口號必須是 因爲現有經營中廣泛存在的缺陷而顯着 Schulzrinne等人 標準跟蹤[頁碼68]
RFC 3550 RTP 2003年7月 阻止使用同一個端口與多個多播的系統 地址，而對於單播，只有一個容許的地址。 所以，對於層n，數據端口是P + 2n，控制端口是P + 2n + 1。當使用IP多播時，地址必須也是 因組播路由和組成員資格被管理而不一樣 在地址粒度。可是，分配連續的IP 多播地址不能被假定，由於一些組可能須要 不一樣的範圍，所以能夠從不一樣的分配 地址範圍。 前一段與SDP規範（RFC 2327 [ 15 ]）衝突，該規範說明多個地址和多個地址都是非法的 在同一會話描述中指定多個端口 由於地址與端口的關聯多是模糊的。 這個限制的目的是在修改版本時放寬 RFC 2327容許相同數量的地址和端口 隱含的一對一映射指定。 RTP數據包不包含長度字段或其餘描述， 所以RTP依賴底層協議來提供一個 長度指示。RTP包的最大長度是有限的 由底層協議。 若是RTP數據包將被攜帶在一個底層協議中 提供了連續八位字節流的抽象，而不是 消息（數據包），RTP數據包的封裝必須是 定義爲提供一個框架機制。若是還須要構築 底層的協議可能會包含填充以便擴展的範圍 RTP負載沒法肯定。框架機制不是 這裏定義。 配置文件能夠指定即便在RTP時也使用的成幀方法 進行協議，提供框架，以便容許 在一個低層協議數據單元中攜帶幾個RTP分組， 如UDP數據包。在一個網絡或者一個網絡中攜帶幾個RTP數據包 傳輸分組減小了頭部開銷而且能夠簡化 不一樣流之間的同步。 。 本部分包含在中定義的常量的總結列表 這個規範。 RTP負載類型（PT）常量在配置文件中定義 比這個文件。可是，RTP頭的八位字節是哪一個 包含標記位和有效載荷類型務必避免保留 值200和201（十進制）來區分來自RTCP的RTP數據包 用於所描述的頭部驗證過程的SR和RR分組類型 Schulzrinne等人 標準跟蹤[頁碼69]
RFC 3550 RTP 2003年7月 在附錄A.1。對於一個標記位和a的標準定義 7位有效載荷類型字段，如本規範所示 限制意味着有效載荷類型72和73被保留。 RTCP分組類型 縮寫。名稱值 SR發件人報告200 RR接收器報告201 SDES源描述202 BYE再見203 APP應用程序定義204 這些類型值被選擇在200-204範圍內進行改進 RTCP包的報頭有效性檢查與RTP包相比較 其餘不相關的數據包。當比較RTCP分組類型字段時 到RTP頭的相應字節，這個範圍對應 標記位爲1（一般不在數據包中） 而且標準有效載荷類型字段的高位是1（由於 靜態有效載荷類型一般定義在低一半）。 這個範圍也被選爲從0和數字的一些距離 255，由於全零和全是通用的數據模式。 因爲全部複合RTCP分組必須以SR或RR開始，這些代碼 被選爲偶數/奇數對以容許RTCP有效性檢查 用掩碼和值測試最大位數。 額外的RTCP數據包類型可能經過IANA註冊（見 第15節）。 SDES類型 縮寫。名稱值 SDES列表0的END結束 CNAME規範名稱1 NAME用戶名2 EMAIL用戶的電子郵件地址3 PHONE用戶的電話號碼4 LOC地理用戶位置5 工具名稱的應用程序或工具6 注意有關來源的通知7 PRIV專用擴展8 其餘SDES類型能夠經過IANA註冊（參見第 15 節）。 Schulzrinne等人 標準跟蹤[頁70]
RFC 3550 RTP 2003年7月 。 一個完整的規範RTP爲特定的應用程序將 須要一個或多個這裏描述的兩種類型的伴隨文件： 配置文件和有效負載格式規範。 RTP能夠用於多種應用，但有些不一樣 要求。適應這些要求的靈活性是 經過在主協議中容許多種選擇來提供 規範，而後選擇適當的選擇或定義 在特定環境和應用程序類別的擴展 一個單獨的配置文件。一般應用程序將運行 在一個特定的RTP會話中只有一個配置文件，因此沒有 在RTP協議自己內部明確指示哪一個 我的資料正在使用中。音頻和視頻應用程序的配置文件多是 在伴侶RFC 3551中找到。配置文件一般標題爲「RTP」 我的資料...「。 第二種伴隨文檔是有效載荷格式 規範，它定義了一種特定類型的有效載荷數據， 如H.261編碼的視頻，應該在RTP中攜帶。這些 文件一般標題爲「XYZ的RTP有效載荷格式」 音頻/視頻編碼「。有效載荷格式可能在多個下有用 配置文件，所以能夠獨立於任何特定來定義 我的資料。配置文件而後負責分配一個 若是須要，將該格式的默認映射到有效載荷類型值。 在本規範中，下列項目已被肯定 在配置文件中可能的定義，但這個列表並不意味着 詳盡： RTP數據頭：RTP數據頭中包含的八位字節 標記位和有效載荷類型字段能夠由a從新定義 配置文件，以適應不一樣的要求，例如與更多或 更少的標記位（5.3節，第18頁）。 有效載荷類型：假設包含有效載荷類型字段， 該配置文件一般會定義一組有效載荷格式（例如， 媒體編碼）以及這些格式的默認靜態映射 有效載荷類型值。一些有效載荷格式可能被定義 經過參考單獨的有效載荷格式規範。每一個 有效載荷類型定義，配置文件必須指定RTP時間戳 時鐘頻率（第5.1節，第14頁）。 RTP數據頭添加：附加字段能夠附加到 固定的RTP數據頭，若是一些額外的功能是 跨越我的資料的獨立的應用程序類別 有效載荷類型（5.3節，第18頁）。 Schulzrinne等人 標準跟蹤[頁碼71]
RFC 3550 RTP 2003年7月 RTP數據頭擴展名：前16位的內容 RTP數據頭擴展結構必須定義若是使用 這個機制是容許的 特定於實現的擴展（第5.3.1節，第18頁）。 RTCP數據包類型：新的特定於應用程序類的RTCP數據包 類型能夠被定義並向IANA註冊。 RTCP報告間隔：一個配置文件應該指定的值 在第6.2節中提到的常量用於 將使用RTCP報告間隔的計算。那些是 會話帶寬的RTCP部分，最小報告 間隔以及發送者和接收者之間的帶寬分配。 一個配置文件能夠指定替代值，若是他們已經 表現出可擴展的工做方式。 SR / RR擴展：能夠爲擴展部分定義擴展部分 RTCP SR和RR數據包，若是有附加信息的話 應按期報告發件人或收件人 （第6.4.3節，第42和43頁）。 SDES使用：配置文件能夠指定相對優先級 RTCP SDES項目徹底傳輸或排除（第 6.3.9 節）; CNAME項目的替代語法或語義 （6.5.1節）; LOC項目的格式（第6.5.5節）; 該 註釋項的語義和使用（6.5.7節）; 或新的SDES 要向IANA註冊的項目類型。 安全：配置文件能夠指定哪些安全服務和 算法應該由應用程序提供，而且能夠提供 指導其適當使用（第9節，第65頁）。 字符串到鍵映射：配置文件能夠指定用戶提供的方式 密碼或密碼短語被映射到加密密鑰。 擁塞：配置文件應該指定擁塞控制 適合該配置文件的行爲。 底層協議：使用特定的底層網絡或 傳輸層協議可能須要攜帶RTP包。 傳輸映射：RTP和RTCP到傳輸級別的映射 地址，例如UDP端口，而不是標準映射 在第11節中定義。68可能被指定。 Schulzrinne等人 標準跟蹤[頁碼72]
RFC 3550 RTP 2003年7月 封裝：能夠定義RTP封裝的封裝 容許在一個較低層攜帶多個RTP數據包 數據包或提供不支持的底層協議的幀 已經這樣作了（第11節，第69頁）。 預計每一個人都不須要一個新的配置文件 應用。在一個應用程序類中，最好是 擴展示有的配置文件，而不是作一個新的 促進應用程序之間的互操做 一般只在一個配置文件下運行。簡單的擴展，如 附加有效載荷類型值或RTCP分組類型的定義能夠 經過IANA註冊併發布它們來完成 描述在配置文件的附錄或有效負載格式中 規範。 。 RTP遭受與底層相同的安全責任 協議。例如，冒名頂替者能夠僞造來源或目的地 網絡地址，或更改標頭或有效負載。在RTCP中， CNAME和NAME信息可能被用來冒充另外一個 參與者。另外，RTP能夠經過IP多播發送， 沒有提供發送者知道全部接收者的直接手段 數據發送，所以沒有措施的隱私。沒錯， 用戶可能對音頻和視頻的隱私問題更爲敏感 溝通比以往更傳統的形式 網絡通訊[ 33 ]。因此使用安全 RTP機制很重要。這些機制在討論中 第9節。 能夠使用RTP級別的轉換器或混合器來容許RTP流量 到達防火牆後面的主機。適當的防火牆安全 原則和作法，這超出了這個範圍 文件，在設計和安裝這些應該遵循 設備和在RTP應用程序的入場許可以後使用 防火牆。 。 額外的RTCP數據包類型和SDES項目類型能夠被註冊 經過互聯網號碼分配機構（IANA）。因爲這些 號碼空間很小，容許不受限制地註冊新的 價值觀不會審慎。方便審查請求和 促進多種應用程序，請求中的新類型的共享使用 新值的註冊必須在RFC或其餘文件中記錄 永久的和現成的參考，如產品 另外一個合做標準組織（如ITU-T）。其餘請求可能 也能夠在「指定專家」的建議下被接受。 Schulzrinne等人 標準跟蹤[頁碼73]
RFC 3550 RTP 2003年7月 （請聯繫IANA獲取當前專家的聯繫信息。） RTP配置文件規範應該向IANA註冊一個名稱 以「RTP / xxx」的形式表示，其中xxx是簡短的縮寫 我的資料標題。這些名稱供上級控制使用 協議，如會話描述協議（SDP），RFC 2327 [ 15 ]，來引用傳輸方法。 。 IETF對任何的有效性或範圍不做任何表態 知識產權或其餘可能要求的權利 屬於實施或使用所述的技術 本文件或在此權利下的任何許可證的程度 可能或可能不可用; 它也不表明它 已經努力肯定任何這樣的權利。有關的信息 IETF關於標準跟蹤權的程序 標準相關的文件能夠在BCP-11中找到。副本 權利主張能夠發表和任何保證 可用的許可證，或嘗試的結果 得到通常許可或使用許可 本規範的實現者或使用者的專有權利能夠 從IETF祕書處得到。 IETF邀請任何有關方面提請其注意 版權，專利或專利申請或其餘專有權利 權利可能涵蓋可能須要實踐的技術 這個標準。請向IETF執行官提供信息 導向器。 。 本備忘錄基於IETF音頻/視頻內的討論 運輸工做組由Stephen Casner和Colin Perkins主持。 目前的協議起源於網絡語音協議 和分組視頻協議（Danny Cohen和Randy Cole）等 協議實施的增值稅申請（範雅各布森和史蒂夫 McCanne）。Christian Huitema提供了隨機標識符的想法 發電機。定時器的普遍的分析和模擬 Jonathan Rosenberg完成了複議算法。該 Michael Speer和Michael指定了分層編碼的補充 史蒂夫·麥凱恩 Schulzrinne等人 標準跟蹤[頁碼74]
RFC 3550 RTP 2003年7月 附錄A - 算法 咱們提供了RTP發送方和接收方的C代碼示例 算法。可能有其餘的實現方法 在特定的操做環境下更快或具備其餘優勢。 這些實現說明僅供參考 是爲了澄清RTP規範。 如下定義用於全部示例; 爲了清晰和 簡潔，結構定義只適用於32位big- endian（最重要的八位字節第一）體系結構。位字段是 假定以大端位順序牢牢包裝，沒有 額外的填充。修改將須要構建一個 便攜式實施。 / * * rtp.h - RTP頭文件 * / #include <sys / types.h> / * *下面的類型定義適用於32位體系結構和 *可能須要調整爲16位或64位體系結構。 * / typedef unsigned char u_int8; typedef unsigned short u_int16; typedef unsigned int u_int32; typedef short int16; / * *當前的協議版本。 * / #define RTP_VERSION 2 #define RTP_SEQ_MOD（1 << 16） #define RTP_MAX_SDES 255 / * SDES的最大文本長度* / typedef enum { RTCP_SR = 200， RTCP_RR = 201， RTCP_SDES = 202， RTCP_BYE = 203， RTCP_APP = 204 } rtcp_type_t; typedef enum { RTCP_SDES_END = 0， RTCP_SDES_CNAME = 1， Schulzrinne等人 標準跟蹤[頁碼75]
RFC 3550 RTP 2003年7月 RTCP_SDES_NAME = 2， RTCP_SDES_EMAIL = 3， RTCP_SDES_PHONE = 4， RTCP_SDES_LOC = 5， RTCP_SDES_TOOL = 6， RTCP_SDES_NOTE = 7， RTCP_SDES_PRIV = 8 } rtcp_sdes_type_t; / * * RTP數據頭 * / typedef struct { 無符號整數版本：2; / *協議版本* / unsigned int p：1; / *填充標誌* / unsigned int x：1; / *標題擴展標誌* / unsigned int cc：4; / *證監會統計* / 無符號整數m：1; / *標記位* / unsigned int pt：7; / *有效載荷類型* / unsigned int seq：16; /* 序列號 */ u_int32 ts; / *時間戳* / u_int32 ssrc; / *同步源* / u_int32 csrc [1]; / *可選的CSRC名單* / } rtp_hdr_t; / * * RTCP公共標題字 * / typedef struct { 無符號整數版本：2; / *協議版本* / unsigned int p：1; / *填充標誌* / 無符號整數計數：5; / *因數據包類型而異* / unsigned int pt：8; / * RTCP數據包類型* / u_int16長度; / * pkt len在文字中，沒有這個詞* / } rtcp_common_t; / * *版本，填充位和分組類型對的大端掩碼 * / #define RTCP_VALID_MASK（0xc000 | 0x2000 | 0xfe） #define RTCP_VALID_VALUE（（RTP_VERSION << 14）| RTCP_SR） / * *接待報告塊 * / typedef struct { u_int32 ssrc; / *正在報告數據源* / 無符號整數分數：8; / *自上次SR / RR丟失的分數* / Schulzrinne等人 標準跟蹤[頁碼76]
RFC 3550 RTP 2003年7月 詮釋失落：24; / * cumul。沒有。丟失（簽名！）* / u_int32 last_seq; / *延長最後一個seq。沒有。收到* / u_int32抖動; / *到達間隔抖動* / u_int32 lsr; / *來自此源的最後一個SR數據包* / u_int32 dlsr; / *自上次SR數據包以來的延遲* / } rtcp_rr_t; / * * SDES項目 * / typedef struct { u_int8類型; / *項目類型（rtcp_sdes_type_t）* / u_int8長度; / *項目的長度（以字節爲單位）* / char數據[1]; / *文本，不以null結尾* / } rtcp_sdes_item_t; / * *一個RTCP數據包 * / typedef struct { rtcp_common_t common; / *公共標題* / 聯合{ / *發件人報告（SR）* / struct { u_int32 ssrc; / *發件人生成這個報告* / u_int32 ntp_sec; / * NTP時間戳* / u_int32 ntp_frac; u_int32 rtp_ts; / * RTP時間戳* / u_int32 psent; / *發送的數據包* / u_int32 osent; / *八位組發送* / rtcp_rr_t rr [1]; / *可變長度列表* / } sr; / *接待報告（RR）* / struct { u_int32 ssrc; / *接收器產生這個報告* / rtcp_rr_t rr [1]; / *可變長度列表* / } rr; / *源描述（SDES）* / struct rtcp_sdes { u_int32 src; / *第一次SSRC / CSRC * / rtcp_sdes_item_t item [1]; / * SDES項目清單* / } sdes; / * BYE * / struct { u_int32 src [1]; / *來源清單* / Schulzrinne等人 標準跟蹤[頁碼77]
RFC 3550 RTP 2003年7月 / *因爲緣由，不能表達結尾的文本* / 再見; } r; } rtcp_t; typedef struct rtcp_sdes rtcp_sdes_t; / * *每一個源的狀態信息 * / typedef struct { u_int16 max_seq; / *最高seq。看到的數字* / u_int32個週期; / *移位的seq計數。數字週期* / u_int32 base_seq; / *基地序號* / u_int32 bad_seq; / *最後'壞'seq號碼+ 1 * / u_int32緩刑; / * sequ。包到源有效* / u_int32收到; / *收到的數據包* / u_int32 expected_prior; / *預計在最後的時間間隔* / u_int32 received_prior; / *最近一次收到的數據包* / u_int32過境 / * prev pkt的相對傳輸時間* / u_int32抖動; / *估計的抖動* / / * ... * / } 資源; RTP數據報頭有效性檢查 RTP接收機應該檢查RTP報頭的有效性 傳入的數據包，由於它們可能被加密或可能來自一個 不一樣的應用程序碰巧是錯誤的。一樣，若是 根據章節9中描述的方法進行加密， 頭部有效性檢查是須要驗證傳入的數據包 已被正確解密，儘管頭部失敗 有效性檢查（例如，未知的有效載荷類型）可能不必定 指示解密失敗。 只有對來自某個RTP數據包的弱有效性檢查是可能的 之前沒有聽過的來源： o RTP版本字段必須等於2。 o有效載荷類型必須是已知的，特別是不能 等於SR或RR。 o若是P位置位，那麼數據包的最後一個八位組必須 包含有效的八位字節計數，特別是小於總數 數據包長度減去頭部大小。 Schulzrinne等人 標準跟蹤[頁碼78]
RFC 3550 RTP 2003年7月 若是配置文件沒有指定，則X位必須爲零 能夠使用頭擴展機制。不然，擴展名 長度字段必須小於總包大小減去 固定的頭部長度和填充。 o數據包的長度必須與CC和有效載荷一致 類型（若是有效載荷具備已知的長度）。 最後三項檢查有些複雜，並不老是可能的， 只留下前兩個總共只有幾位。若是SSRC 而後，數據包中的標識符是以前已經接收到的標識符 該數據包多是有效的，並檢查序列號是不是 在預期的範圍內提供進一步的驗證。若是SSRC 標識符以前沒有被看見，而後數據包承載 標識符可能被認爲是無效的，直到其中的一小部分 以連續的序號到達。那些無效的數據包可能 被丟棄，或者一旦驗證，它們能夠被存儲和交付 若是由此形成的延誤是能夠接受的 下面顯示的例程update_seq確保聲明一個源 只有在收到MIN_SEQUENTIAL包後纔有效 序列。它也驗證了一個新的序列號seq 接收到的數據包並更新數據包的序列狀態 來源於s點的結構。 當第一次聽到新的來源，即SSRC 標識符不在表格中（見第8.2節）和每一個來源 狀態被分配給它，s->緩刑被設置爲數量 在聲明源有效以前須要順序數據包 （參數MIN_SEQUENTIAL）和其餘變量被初始化： init_seq（s，seq）; s-> max_seq = seq-1; s->緩刑= MIN_SEQUENTIAL; 一個非零的s->緩刑標誌着來源還沒有有效，因此 狀態可能會在短暫超時而不是長時間以後被丟棄， 如6.2.1節所述。 在源被認爲有效以後，序列號被考慮 若是在s-> max_seq以前不超過MAX_DROPOUT，則爲有效 比MAX_MISORDER落後。若是新的序列號超前 max_seq取模RTP序號範圍（16位），可是 小於max_seq，它已經繞過和（移位）的計數 序號循環的次數遞增。值爲1返回 以指示有效的序列號。 Schulzrinne等人 標準跟蹤[第79頁]
RFC 3550 RTP 2003年7月 不然，返回零值以指示驗證 失敗，而且存儲了錯誤的序號加1。若是下一個 接收到的數據包攜帶下一個更高的序列號 考慮了推測可能致使的新分組序列的有效開始 經過延長丟失或從新啓動。因爲多個完整 丟失的序列號週期可能已經丟失 統計被重置。 顯示參數的典型值，基於最大值 以50包/秒和最大值2秒的無序次數 輟學1分鐘。丟失參數MAX_DROPOUT應該是a 給出一個16位序列號空間的小部分 從新啓動後的新序列號的合理可能性 不在可接受的範圍以內 從新開始。 void init_seq（source * s，u_int16 seq） { s-> base_seq = seq; s-> max_seq = seq; s-> bad_seq = RTP_SEQ_MOD + 1; / * so seq == bad_seq爲false * / s-> cycles = 0; s-> received = 0; s-> received_prior = 0; s-> expected_prior = 0; / *其餘初始化* / } int update_seq（source * s，u_int16 seq） { u_int16 udelta = seq - s-> max_seq; const int MAX_DROPOUT = 3000; const int MAX_MISORDER = 100; const int MIN_SEQUENTIAL = 2; / * *直到MIN_SEQUENTIAL包與源無效 *已經收到序列號。 * / 若是（s->緩刑）{ / *包是按順序* / if（seq == s-> max_seq + 1）{ S-> probation--; s-> max_seq = seq; if（s-> probation == 0）{ init_seq（s，seq）; S->接收++; 返回1; Schulzrinne等人 標準跟蹤[第80頁]
RFC 3550 RTP 2003年7月 } } else { s->緩刑= MIN_SEQUENTIAL - 1; s-> max_seq = seq; } 返回0; } else if（udelta <MAX_DROPOUT）{ / *爲了容許差距* / if（seq <s-> max_seq）{ / * *包裝的序列號 - 計算另外一個64K週期。 * / s-> cycles + = RTP_SEQ_MOD; } s-> max_seq = seq; } else if（udelta <= RTP_SEQ_MOD - MAX_MISORDER）{ / *序列號跳轉很是大* / if（seq == s-> bad_seq）{ / * *兩個連續的數據包 - 假設對方 *從新啓動而不告訴咱們只是從新同步 *（即僞裝這是第一個數據包）。 * / init_seq（s，seq）; } else { s-> bad_seq =（seq + 1）＆（RTP_SEQ_MOD-1）; 返回0; } } else { / *重複或從新排序的數據包* / } S->接收++; 返回1; } 有效性檢查能夠作得更強，須要兩個以上 數據包順序。缺點是數量較多 初始數據包將被丟棄（或在隊列中被延遲） 高包丟失率可能會阻止驗證。可是，由於 若是一個RTCP數據包是RTCP頭驗證相對較強 從數據包以前收到一個數據包，計數就能夠了 調整，以便只有兩個數據包是必需的順序。若是 初始數據丟失幾秒鐘是能夠容忍的，一個應用程序 能夠選擇丟棄來自源的全部數據包直到有效 已經從該源收到RTCP數據包。 Schulzrinne等人 標準跟蹤[頁碼81]
RFC 3550 RTP 2003年7月 根據應用和編碼，算法可能會被利用 關於有效載荷格式的額外知識以進一步驗證。 對於全部時間戳增量相同的有效內容類型 數據包，時間戳值能夠從以前的預測 數據包使用序列號從同一個源接收 差別（假設有效載荷類型沒有變化）。 因爲可能性很高，所以能夠進行強有力的「快速路徑」檢查 新收到的RTP數據的頭部中的前四個八比特組 數據包將與以前數據包的數據包相同 相同的SSRC，但序列號將增長1。 相似地，單條目緩存能夠用於更快的SSRC查找 在一般從一個來源接收數據的應用程序中 時間。 RTCP報頭有效性檢查 如下檢查應該應用於RTCP數據包。 o RTP版本字段必須等於2。 o化合物中第一個RTCP數據包的有效載荷類型字段 數據包必須等於SR或RR。 o填充位（P）應該爲0的第一個數據包 複合RTCP數據包，由於填充只能應用，若是它 是須要的，到最後一個數據包。 o單個RTCP數據包的長度字段必須加起來 接收到的複合RTCP分組的總長度。這個 是一個至關強大的檢查。 下面的代碼段執行全部這些檢查。包 類型不會檢查後來的數據包，由於未知的數據包類型 可能存在，應該被忽略。 u_int32 len; / *以字爲單位的複合RTCP分組的長度* / rtcp_t * r; / * RTCP標頭* / rtcp_t * end; / *複合RTCP數據包的結尾* / 若是（（*（u_int16 *）r＆RTCP_VALID_MASK）！= RTCP_VALID_VALUE）{ / *數據包格式錯誤* / } end =（rtcp_t *）（（u_int32 *）r + len）; do r =（rtcp_t *）（（u_int32 *）r + r-> common.length + 1）; while（r <end && r-> common.version == 2）; Schulzrinne等人 標準跟蹤[第82頁]
RFC 3550 RTP 2003年7月 if（r！= end）{ / *數據包格式錯誤* / } 肯定預期和丟失的數據包數量 爲了計算丟包率，RTP數據包的數量 預期和實際上從每一個來源接收須要知道， 使用struct source中定義的每一個源的狀態信息 在下面的代碼中經過指針s引用。數據包的數量 收到的數據包就是數據包的數量，包括任何數據 延遲或重複的數據包。數據包的數量能夠是 由接收機計算出最高的差值 接收的序列號（s-> max_seq）和第一個序列號 收到（s-> base_seq）。因爲序列號只有16位 並將環繞，有必要延長最高的順序 編號與（移位的）序列號重疊計數 （S->個循環）。接收到的數據包數和週期數 維護附錄A.1中的RTP頭部有效性檢查程序。 extended_max = s-> cycles + s-> max_seq; expected = extended_max - s-> base_seq + 1; 丟包的數量被定義爲包的數量 預計實際收到的數據包數量減小： 丟失=預期 - s->收到; 因爲這個有符號的數字是在24位進行的，因此應該被鉗位 在0x7fffff爲正面損失或0x800000爲負面損失 比包裹。 在上一個報告間隔期間丟失的數據包部分 （自從以前的SR或RR分組被髮送）是從中計算的 在預期的和收到的數據包計數的差別 間隔，其中expected_prior和received_prior是值 之前的接收報告生成時保存： expected_interval =預期 - s-> expected_prior; s-> expected_prior =預期; received_interval = s-> received - s-> received_prior; s-> received_prior = s->收到; lost_interval = expected_interval - received_interval; if（expected_interval == 0 || lost_interval <= 0）fraction = 0; else fraction =（lost_interval << 8）/ expected_interval; 獲得的分數是二進制的8位定點數 指向左邊緣。 Schulzrinne等人 標準跟蹤[頁碼83]
RFC 3550 RTP 2003年7月 生成RTCP SDES包 這個函數將一個SDES塊創建到由argc組成的緩衝區b中 以數組類型，值和長度提供的項目。它返回一個 指向b中下一個可用位置的指針。 char * rtp_write_sdes（char * b，u_int32 src，int argc， rtcp_sdes_type_t類型[]，char *值[]， int length []） { rtcp_sdes_t * s =（rtcp_sdes_t *）b; rtcp_sdes_item_t * rsp; int i; int len; int pad; / * SSRC標頭* / s-> src = src; rsp =＆s-> item [0]; / * SDES項目* / for（i = 0; i <argc; i ++）{ rsp-> type = type [i]; len = length [i]; if（len> RTP_MAX_SDES）{ / *長度無效，可能要採起其餘行動* / len = RTP_MAX_SDES; } rsp-> length = len; memcpy（rsp-> data，value [i]，len）; rsp =（rtcp_sdes_item_t *）＆rsp-> data [len]; } / *以結束標記結束並填充到下一個4字節邊界* / len =（（char *）rsp） - b; pad = 4 - （len＆0x3）; b =（char *）rsp; while（pad--）* b ++ = RTCP_SDES_END; 回報b; } Schulzrinne等人 標準跟蹤[頁碼84]
RFC 3550 RTP 2003年7月 解析RTCP SDES數據包 這個函數解析一個SDES包，調用函數find_member（） 找到給會員的信息指針 SSRC標識符和member_sdes（）來存儲新的SDES信息 爲那個成員。這個函數須要一個指向頭部的指針 RTCP數據包。 void rtp_read_sdes（rtcp_t * r） { int count = r-> common.count; rtcp_sdes_t * sd =＆r-> r.sdes; rtcp_sdes_item_t * rsp，* rspn; rtcp_sdes_item_t * end =（rtcp_sdes_item_t *） （（u_int32 *）r + r-> common.length + 1）; 源* s; while（--count> = 0）{ rsp =＆sd-> item [0]; if（rsp> = end）break; s = find_member（sd-> src）; for（; rsp-> type; rsp = rspn）{ rspn =（rtcp_sdes_item_t *）（（char *）rsp + rsp-> length + 2）; if（rspn> = end）{ rsp = rspn; 打破; } member_sdes（s，rsp-> type，rsp-> data，rsp-> length）; } sd =（rtcp_sdes_t *） （（u_int32 *）sd +（（（char *）rsp - （char *）sd）>> 2）+1）; } if（count> = 0）{ / *無效的數據包格式* / } } 生成一個隨機的32位標識符 如下子程序使用隨機生成一個32位標識符 在RFC 1321 [ 32 ]中發佈的MD5例程。系統例程可能 不是在全部的操做系統上都存在，而是應該做爲 提示能夠使用什麼樣的信息。其餘系統 可能適當的呼叫包括 Schulzrinne等人 標準跟蹤[頁85]
RFC 3550 RTP 2003年7月 o getdomainname（）， getwd（）或者 o getrusage（）。 「現場」視頻或音頻樣本也是隨機的一個很好的來源 數字，但必須當心避免使用關閉 麥克風或盲目相機做爲來源[ 17 ]。 建議使用這個或相似的程序來生成 產生RTCP的隨機數發生器的初始種子 期間（如附錄A.7所示）），以生成初始值 序列號和時間戳，並生成SSRC值。 因爲這個例程極可能是CPU密集型的，因此它的直接使用 生成RTCP時段是不合適的，由於可預測性不是 一個問題。請注意，此例程產生相同的結果 重複的呼叫，直到系統時鐘的值改變，除非 爲類型參數提供了不一樣的值。 / * *生成一個隨機的32位數量。 * / #include <sys / types.h> / * u_long * / #include <sys / time.h> / * gettimeofday（）* / #include <unistd.h> / * get ..（）* / #include <stdio.h> / * printf（）* / #include <time.h> / * clock（）* / #include <sys / utsname.h> / * uname（）* / 從RFC 1321 #include「global.h」/ * * / #include「md5.h」/ * RFC 1321 * / #define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final 靜態u_long md_32（char *字符串，int長度） { MD_CTX上下文; 聯合{ char c [16]; u_long x [4]; } 消化; u_long r; int i; MDInit（＆context）; Schulzrinne等人 標準跟蹤[頁86]
RFC 3550 RTP 2003年7月 MDUpdate（＆context，string，length）; MDFinal（（unsigned char *）＆digest，＆context）; r = 0; for（i = 0; i <3; i ++）{ r ^ = digest.x [i]; } 返回r; } / * md_32 * / / * *返回隨機無符號的32位數量。若是使用'type'參數 *您須要緊密連續生成幾個不一樣的值。 * / u_int32 random32（int型） { struct { int類型; 結構timeval電視; clock_t cpu; pid_t pid; u_long hid; uid_t uid; gid_t gid; struct utsname name; } s; gettimeofday（＆s.tv，0）; UNAME（＆s.name）; s.type = type; s.cpu = clock（）; s.pid = getpid（）; s.hid = gethostid（）; s.uid = getuid（）; s.gid = getgid（）; / *還有：系統正常運行時間* / 返回md_32（（char *）＆s，sizeof（s））; } / * random32 * / 計算RTCP傳輸間隔 如下功能實現了RTCP的發送和接收6.2節中 描述的規則。這些規則被編碼在幾個 功能： rtcp_interval（）計算肯定性的計算間隔， 以秒爲單位。參數在6.3節中定義。 Schulzrinne等人 標準跟蹤[頁碼87]
RFC 3550 RTP 2003年7月 OnExpire（）在RTCP傳輸定時器到期時被調用。 OnReceive（）在接收到RTCP數據包時被調用。 OnExpire（）和OnReceive（）都有事件e做爲參數。這是 該參與者的下一個計劃事件，即RTCP報告 或BYE包。假定如下功能是 可供選擇： o時間表（時間t，事件e）安排事件e在時間t發生。 當時間t到達時，函數OnExpire被稱爲e 論據。 o從新計劃（時間t，事件e）從新計劃先前的計劃 事件e的時間t。 SendRTCPReport（事件e）發送一個RTCP報告。 SendBYEPacket（事件e）發送一個BYE包。 TypeOfEvent（event e）若是事件正在返回EVENT_BYE 處理的是一個BYE包發送，不然返回 EVENT_REPORT。 PacketType（p）返回PACKET_RTCP_REPORT，若是數據包p是一個RTCP 報告（不是BYE），PACKET_BYE若是是BYE RTCP包， PACKET_RTP，若是它是一個常規的RTP數據包。 ReceivedPacketSize（）和SentPacketSize（）返回的大小 以八比特組爲單位的引用分組。 o若是發送數據包p的參與者是，則NewMember（p）返回1 目前不在成員列表中，不然爲0。注意這個功能 由於每一箇中國證監會都是不夠的 RTP包中的標識符和BYE包中的每一個SSRC 被處理。 o若是發送數據包p的參與者是，則NewSender（p）返回1 目前不在成員列表的發件人子列表中，0 除此之外。 AddMember（）和RemoveMember（）添加和刪除參與者 成員列表。 AddSender（）和RemoveSender（）添加和刪除參與者 成員列表的發件人子列表。 Schulzrinne等人 標準跟蹤[第88頁]
RFC 3550 RTP 2003年7月 這些功能將不得不延長執行 容許發送者和非發送者的RTCP帶寬分數是 指定爲顯式參數而不是25％的固定值 75％。rtcp_interval（）的擴展實現將須要 若是其中一個參數爲零，則避免被零除。 雙rtcp_interval（int成員， int發件人， 雙rtcp_bw， int we_sent， 雙avg_rtcp_size， int初始） { / * *來自本站點的RTCP數據包之間的最短平均時間（in *秒）。這個時候能夠防止「彙集」報告 *會議規模小，大量的法律沒有幫助 *消除流量。它也保持報告間隔 *在短暫的停電期間變得好笑的小 *網絡分區。 * / double const RTCP_MIN_TIME = 5。 / * *活躍的RTCP帶寬共享部分 *發件人。（這個分數被選中，以便在一個典型的 *與一個或兩個主動發送者的會話，計算的報告 *時間大體等於最小報告時間 *咱們不會沒必要要地拖慢收件人的報告 *接收器分數必須是1 - 發件人分數。 * / double const RTCP_SENDER_BW_FRACTION = 0.25; double const RTCP_RCVR_BW_FRACTION =（1-RTCP_SENDER_BW_FRACTION）; / * / *爲了彌補「定時器從新考慮」收斂到一個 *值低於預期的平均值。 * / double const COMPENSATION = 2.71828 - 1.5; 成對的東西; / *間隔* / double rtcp_min_time = RTCP_MIN_TIME; int n; / *不。成員計算* / / * *應用程序啓動時的第一個通話使用半分鐘 *延遲更快的通知，同時仍然容許一段時間 *報告隨機前和了解其餘 *來源，因此報告間隔會收斂到正確的 *間隔更快。 Schulzrinne等人 標準跟蹤[第89頁]
RFC 3550 RTP 2003年7月 * / 若是（初始）{ rtcp_min_time / = 2; } / * *將RTCP帶寬的一小部分分配給發送者，除非 *發件人的數量足夠大，他們的份額是 *超過這個分數。 * / n =成員; 若是（發件人<=成員* RTCP_SENDER_BW_FRACTION）{ if（we_sent）{ rtcp_bw * = RTCP_SENDER_BW_FRACTION; n =發件人; } else { rtcp_bw * = RTCP_RCVR_BW_FRACTION; n - =發件人; } } / * *站點的有效數量乘以平均數據包大小 *每一個站點發送報告時發送的八位字節總數。 *除以有效帶寬給出的時間 *必須發送這些數據包的時間間隔 *知足帶寬目標，最低強制執行。在那裏面 *咱們發送一份報告的時間間隔，因此此次也是咱們的 *報告之間的平均時間。 * / t = avg_rtcp_size * n / rtcp_bw; 若是（t <rtcp_min_time）t = rtcp_min_time; / * *避免流量忽然意外同步 *其餘網站，咱們而後選擇咱們的實際下一個報告間隔做爲一個 *隨機數均勻分佈在0.5 * t和1.5 * t之間。 * / t = t *（drand48（）+ 0.5）; t = t /補償; 返回t; } void OnExpire（event e， int成員， int發件人， 雙rtcp_bw， int we_sent， double * avg_rtcp_size， Schulzrinne等人 標準跟蹤[第90頁]
RFC 3550 RTP 2003年7月 int *初始， time_tp tc， time_tp * tp， int * pmembers） { / *這個函數負責決定是否發送一個 *如今RTCP報告或BYE包，或從新安排傳輸。 *它也負責更新pmembers，initial，tp， *和avg_rtcp_size狀態變量。這個功能應該是 調用Schedule（）使用的事件計時器到期。 * / 成對的東西; / *間隔* / 雙tn; / *下一次傳輸時間* / / *在BYE的狀況下，使用「定時器從新考慮」 *必要時從新安排BYE的傳輸* / if（TypeOfEvent（e）== EVENT_BYE）{ t = rtcp_interval（成員， 發件人， rtcp_bw， 咱們發送， * avg_rtcp_size， *初始）; tn = * tp + t; 若是（tn <= tc）{ SendBYEPacket（E）; 出口（1）; } else { 附表（tn，e）; } （else）if（TypeOfEvent（e）== EVENT_REPORT）{ t = rtcp_interval（成員， 發件人， rtcp_bw， 咱們發送， * avg_rtcp_size， *初始）; tn = * tp + t; 若是（tn <= tc）{ SendRTCPReport（E）; * avg_rtcp_size =（1./16.)*SentPacketSize（e）+ （15./16.)*(*avg_rtcp_size）; * tp = tc; / *咱們必須重畫間隔。不要重複使用 Schulzrinne等人 標準跟蹤[第91頁]
RFC 3550 RTP 2003年7月 一個以上計算，由於它不是實際 分發同樣，由於咱們是有條件的 它是足夠小，致使一個數據包 被髮送* / t = rtcp_interval（成員， 發件人， rtcp_bw， 咱們發送， * avg_rtcp_size， *初始）; 附表（T + TC，E）; * initial = 0; } else { 附表（tn，e）; } * pmembers =成員; } } void OnReceive（packet p， 事件e， int *成員， int * pmembers， int *發送者， double * avg_rtcp_size， 雙* tp， 雙tc， 雙tn） { / *咱們作什麼取決於咱們是否已經離開了這個組織 *等待發送一個BYE（TypeOfEvent（e）== EVENT_BYE）或一個RTCP *報告。p表示剛收到的數據包。* / if（PacketType（p）== PACKET_RTCP_REPORT）{ if（NewMember（p）&&（TypeOfEvent（e）== EVENT_REPORT））{ 使用addMember（P）; *會員+ = 1; } * avg_rtcp_size =（1./16.)*ReceivedPacketSize（p）+ （15./16.)*(*avg_rtcp_size）; } else if（PacketType（p）== PACKET_RTP）{ if（NewMember（p）&&（TypeOfEvent（e）== EVENT_REPORT））{ 使用addMember（P）; *會員+ = 1; } if（NewSender（p）&&（TypeOfEvent（e）== EVENT_REPORT））{ Schulzrinne等人 標準跟蹤[第92頁]
RFC 3550 RTP 2003年7月 AddSender（P）; *發件人+ = 1; } } else if（PacketType（p）== PACKET_BYE）{ * avg_rtcp_size =（1./16.)*ReceivedPacketSize（p）+ （15./16.)*(*avg_rtcp_size）; if（TypeOfEvent（e）== EVENT_REPORT）{ if（NewSender（p）== FALSE）{ RemoveSender（P）; *發件人 - = 1; } if（NewMember（p）== FALSE）{ RemoveMember（P）; *會員 - = 1; } if（* members <* pmembers）{ tn = tc + （（（double）* members）/（* pmembers））*（tn - tc）; * tp = tc - （（（double）* members）/（* pmembers））*（tc - * tp）; / *從新安排時間tn的下一個報告* / 從新安排（tn，e）; * pmembers = *會員; } （else）if（TypeOfEvent（e）== EVENT_BYE）{ *會員+ = 1; } } } Schulzrinne等人 標準跟蹤[第93頁]
RFC 3550 RTP 2003年7月 估計到達間隔抖動 下面的代碼段實現了6.4.1 節 給出的算法用於計算的統計方差的估計 RTP數據到達間隔時間被插入到間隔抖動中 接待領域的報道。輸入是r-> ts，來自的時間戳 傳入的數據包和到達，當前時間在相同的單位。 這裏要指出來源; s->中轉持有親屬 前一個數據包的傳輸時間，以及s-> jitter保存 估計抖動。接收報告的抖動字段是 以時間戳單位測量並表示爲無符號整數，可是 抖動估計保持在浮點。做爲每一個數據包 到達時，抖動估計值被更新： int transit = arrival - r-> ts; int d = transit - s-> transit; s-> transit = transit; 若是（d <0）d = -d; s-> jitter + =（1./16。）*（（double）d - s-> jitter）; 接收報告塊（rr點數）生成時 這個成員，當前的抖動估計被返回： rr-> jitter =（u_int32）s-> jitter; 或者，抖動估計能夠保持爲整數，可是 縮小以減小舍入偏差。除了計算是相同的 最後一行： s-> jitter + = d - （（s-> jitter + 8）>> 4）; 在這種狀況下，接收報告的估計值被採樣爲： rr-> jitter = s-> jitter >> 4; Schulzrinne等人 標準跟蹤[第94頁]
RFC 3550 RTP 2003年7月 附錄B - RFC 1889的變化 這個RFC的大部分與RFC 1889相同。有沒有變化 線上的數據包格式，只改變規則和 管理如何使用協議的算法。最大的變化是 對可擴展定時器算法進行加強以計算什麼時候 發送RTCP數據包： 計算RTCP傳輸間隔的算法 在6.2節和6.3節中有規定，並在附錄A.7中說明 被增長以包括「從新考慮」以最小化傳輸 當許多參與者加入時，超過預期的費率 會議同時進行，「逆向從新考慮」減小 虛假參與者超時的發生率和持續時間 參與者人數迅速降低。反向重審是 也用於在發送RTCP SR以前可能縮短延遲 當從被動接收器轉換到主動發送器模式時。 o 第6.3.7節指定新的規則控制RTCP BYE時 應該發送數據包，以免數據包氾濫 許多參與者同時離開會議。 o要求爲非活動的參與者保留狀態 足夠長的時間跨越典型的網絡分區被刪除 來自第6.2.1節。在許多參與者加入的會議中 短暫的時間和不能發送BYE，這個要求會致使一個 顯着高估了參與者的人數。該 本修訂中增長的複議算法能夠補償 當大量的新參與者同時加入時 分區治癒。 應該指出，這些加強只有一個重要的 當會議參與者數量很大時（千） 大部分參與者同時參加或離開。這個 使現場網絡測試困難。可是，算法 進行了完全的分析和模擬驗證 性能。此外，加強算法的設計 與RFC 1889中的算法互操做， 在一個步驟中減小過多的RTCP帶寬是成比例的 到實施加強的參與者的一小部分 算法。兩種算法的互操做性已獲得驗證 在實時網絡上進行實驗。 其餘功能變化是： o 第6.2.1節指定實現可能只存儲一個 對參與者的SSRC標識符進行抽樣以容許縮放 很是大的會議。算法在RFC 2762 [ 21 ] 中指定。 Schulzrinne等人 標準跟蹤[第95頁]
RFC 3550 RTP 2003年7月 o在6.2節，規定了RTCP發送者和非發送者 帶寬能夠被設置爲會話的單獨參數 比會話帶寬的嚴格百分比，而且能夠被設置 歸零。RTP會話必須使用RTCP 使用IP多播被放寬。然而，澄清也是 補充說，關閉RTCP不推薦。 ○在第6.2，6.3.1和附錄A.7，它是指定的 參與者的分數低於發送者的專用RTCP 帶寬從固定1/4變化到基於RTCP的比率 發送者和非發送者帶寬參數。 在那裏沒有帶寬專用於發件人的條件 沒有發件人被刪除，由於這是預期的 過渡狀態。它也讓非發件人使用發件人 RTCP帶寬時，這是否是打算。 o也在第6.2節也規定了最小的RTCP時間間隔 對於高帶寬會話能夠縮放到更小的值，而且 對於單播，初始RTCP延遲可能被設置爲零 會話。 o指定參與者的時間應以不活動爲基礎 的使用接收方RTCP計算的RTCP報告間隔 即便對於主動發送者也是如此。 o 7.2和7.3節規定了譯員和混音師應該這樣作 發送BYE數據包爲他們再也不轉發的來源。 o分層編碼的規則更改在2.4節中定義， 6.3.9,8.3和11.在最後這些，注意到 地址和端口分配規則與SDP衝突 規範，RFC 2327 [ 15 ]，但它的目的是這樣的 在RFC 2327的修訂中將會放寬限制。 o在RTP和RTCP中使用偶數/奇數端口對的慣例 第11條澄清了指的是目的港。該 若是使用偶數/奇數端口對的要求被刪除 端口是明確指定的。對於單播RTP會話， 可用於兩個端部不一樣的端口對（第3，7.1 和11）。 o增長了新的第10節來解釋要求 使用RTP的應用程序擁塞控制。 o在8.2節中，新SSRC標識符必須是的要求 每當源傳輸地址被改變時被選擇 輕鬆地說能夠選擇一個新的SSRC標識符。 相應地，澄清了一個實現可能 Schulzrinne等人 標準跟蹤[第96頁]
RFC 3550 RTP 2003年7月 選擇保留新的源地址而不是數據包 現有的源地址在兩個SSRC衝突發生之間 其餘參與者，並應該這樣作的應用程序，如 電話，其中一些來源，如移動實體可能會改變 RTP會話過程當中的地址。 o 在僞造代碼的RFC 1889打印中的縮進錯誤8.2節中 的碰撞檢測和解決算法 已經經過將語法翻譯成僞C語言來糾正， 並修改了算法以消除這個限制 RTP和RTCP必須從相同的源端口號發送。 o對RTCP數據包的填充機制的描述是 澄清，並指定填充必須只適用於 複合RTCP分組的最後一個分組。 o在A.1節中，base_seq的初始化被糾正爲seq 而不是seq - 1，文字糾正說很差 序號加1存儲。max_seq的初始化 和其餘變量的算法是從文本中分離出來的 要明確這個初始化必須除了作 調用init_seq（）函數（並在RFC 1889中丟失了一些單詞 當處理文件從源文件到輸出文件時 恢復）。 o在A.3節中丟失的數據包數量被糾正爲 使用正面和負面的限制。 o RTCP SR中「相對」NTP時間戳的規範 如今將這些時間戳定義爲基於最多的時間戳 常見的系統專用時鐘，好比系統正常運行時間，而不是 在會議上經歷的時間將不會是相同的多個 應用程序在不一樣的時間在同一臺機器上啓動。 非功能性更改： o指定接收者必須忽略有效載荷的數據包 類型它不明白。 o在圖2中，浮點NTP時間戳值被校訂， 一些丟失的前導零被添加在一個十六進制數和UTC 時區被指定。 o NTP時間戳在一年中的不合時宜 2036解釋。 Schulzrinne等人 標準跟蹤[第97頁]
RFC 3550 RTP 2003年7月 o RTCP分組類型和SDES類型的註冊策略 在新的第15條中獲得澄清 IANA考慮事項。該 建議實驗者註冊他們須要的數字 那麼取消註冊那些證實不須要的東西已被刪除 同意使用APP和PRIV。配置文件名稱的註冊是 也指定了。 o UTF-8字符集的引用從 X / Open初步規範是RFC 2279。 o RFC 1597的參考更新爲RFC 1918和RFC 2543的 參考更新爲RFC 3261。 RFC 1889中 引入的最後一段， 警告實施者限制在互聯網上的部署 被刪除，由於它被認爲再也不相關。 o關於使用與特定源相關的RTP的非規範性說明 組播（SSM）在第6節中添加。 o 第3節中「RTP會話」的定義擴展到了 認可單個會話可能會使用多個目標 運輸地址（翻譯者老是如此） 混音器），並解釋一個RTP的顯着特色 會話是每一個對應於一個單獨的SSRC標識符 空間。增長了「多媒體會議」的新定義 減小對「會話」一詞的混淆。 o「採樣即時」的含義已經詳細解釋爲 部分RTP頭部的時間戳字段的定義 第5.1節。 o在幾個地方對文本做了小的澄清， 有的回答了讀者的提問。尤爲是： - 在RFC 1889中，第2.2節第二句的前五個單詞 在處理源文件到文檔時丟失了 輸出形式，但如今恢復。 -在溶液中加入一種「RTP媒體類型」的定義第3節至 容許在5.2 節中 解釋複用RTP會話方面更加清楚 媒體。這部分如今也解釋了複用 基於SSRC標識符的相同介質的多個來源 多是適當的，而且是組播會話的標準。 - 「非RTP手段」的定義擴大到包括 構成非RTP手段的其餘協議的例子。 Schulzrinne等人 標準跟蹤[頁98]
RFC 3550 RTP 2003年7月 - 擴展了會話帶寬參數的描述 在第6.2節，包括說明控制權 流量帶寬是除了會話帶寬以外的 數據流量。 - 不一樣的數據包持續時間對抖動計算的影響 在第6.4.4節中有解釋。 - 終止和填充一系列SDES項目的方法 在第6.5節中獲得澄清。 - 在SDES的描述中添加了IPv6地址示例第6.5.1節中的 CNAME 代替了「example.com」 其餘示例域名。 - 安所有分如今增長了對IPSEC的正式引用 它是可用的，並說保密的方法 在本規範中定義的主要是編纂現有的 實踐。建議更強的加密 諸如Triple-DES之類的算法可用於代替默認值 算法，並指出基於AES的SRTP配置文件將是 將來的正確選擇。對弱點謹慎 添加了做爲初始化向量的RTP頭。它 還注意到有效載荷加密是必要的 容許標題壓縮。 - 明確了RTCP的部分加密方法; 在 特別是，SDES CNAME只在一個部分被攜帶 複合RTCP分組被拆分。 - 明確只有一個複合RTCP數據包應該是 發送每一個報告間隔，若是有太多 報告的主動來源適合MTU，而後是一個子集 的來源應該選擇多輪循環 間隔。 - 附錄A.1中增長了一個說明，能夠保存數據包 在RTP頭部驗證期間，並在成功後交付。 - 7.3節如今解釋一個混合器聚合SDES數據包 因爲更長的數據包和混頻器，使用更多的RTCP帶寬 經過RTCP天然發送的數據包高於 單一的來源率，但這兩種行爲是有效的。 - 第13節澄清了一個RTP應用程序可能使用多個 配置文件，但一般只有一個給定的會話。 Schulzrinne等人 標準跟蹤[頁99]
RFC 3550 RTP 2003年7月 - 術語必須，應該，能夠等，如RFC 2119中所定義。 - 參考書目分爲規範和信息 引用。
相關文章
- 1. RFC3550
- 2. python中文版-python有中文版嗎
- 3. CorelDraw2020中文版
- 4. Matlab2018a中文版
- 5. Mastercam2021中文版
- 6. mastercam2020中文版
- 7. ANSYS2019中文版
- 8. Fiddler中文版
- 9. ECMAScript5.1中文版
- 10. UEStudio20中文版
- 更多相關文章...
- • R 繪圖 - 中文支持 - R 語言教程
- • MySQL的版本以及版本號 - MySQL教程
- • Scala 中文亂碼解決
- • SpringBoot中properties文件不能自動提示解決方法
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. RFC3550
- 2. python中文版-python有中文版嗎
- 3. CorelDraw2020中文版
- 4. Matlab2018a中文版
- 5. Mastercam2021中文版
- 6. mastercam2020中文版
- 7. ANSYS2019中文版
- 8. Fiddler中文版
- 9. ECMAScript5.1中文版
- 10. UEStudio20中文版