螞蚱google中文翻譯版
Network Working Group J. Rey
Request for Comments: 4588 Panasonic
Category: Standards Track D. Leon
Consultant
A. Miyazaki
Panasonic
V. Varsa
Nokia
R. Hakenberg
Panasonic
July 2006
RTP重傳有效載荷格式
本備忘錄的狀态
本文檔為Internet社群指定了Internet标準跟蹤協定，并請求讨論和改進建議。請參閱目前
版本的“Internet官方協定标準”（STD 1）檢視标準化狀态和該協定的狀态。本備忘錄的發
布是無限制的。
版權聲明
版權所有（C）網際網路協會（2006年）。
摘要
RTP重傳是一種有效的丢包恢複技術，适用于具有寬松延遲界限的實時應用。該文檔描述了用于
執行重傳的RTP有效載荷格式。重傳的RTP分組在與原始RTP流分開的流中發送。假設從接收器
到發送器的回報是可用的。特别是，本備忘錄中假設提供了實時傳輸控制協定（RTCP）回報，
該RTCP回報在基于RTCP的回報（表示為RTP/AVPF）的擴充RTP配置檔案中定義。
Rey, et al. Standards Track [Page 1]
RFC 4588 RTP Retransmission Payload Format July 2006
Table of Contents
1. 簡介 .............................................................3
2. 術語 .............................................................3
3. 重傳方案的需求和設計理由 ............................................4
3.1. 多路複用方案選擇 ..............................................4
4. 重傳有效載荷格式 ...................................................5
5. 重傳流與原始流的關聯 ................................................6
5.1. 重傳會話共享 ..................................................6
5.2. CNAME使用 ....................................................7
5.3. 接收端關聯 ....................................................7
6. 将擴充RTP配置用于基于RTCP的回報 ......................................7
6.1. 發送端的RTCP .................................................7
6.2. RTCP接收端報告 ...............................................8
6.3. 重傳請求 .....................................................8
6.4. 時間規則 .....................................................9
7. 擁塞控制 ..........................................................9
8. 重傳有效載荷格式的MIME類型注冊 .......................................9
8.1. 介紹 ........................................................9
8.2. 注冊audio/rtx ..............................................10
8.3. 注冊video/rtx ..............................................11
8.4. 注冊text/rtx ...............................................12
8.5. 注冊application/rtx ........................................13
8.6. 映射到SDP ..................................................14
8.7. 使用會話多路複用的SDP描述 .....................................14
8.8. 使用SSRC多路複用的SDP描述 ....................................15
9. RTSP注意事項 .....................................................15
9.1. 使用SSRC多路複用的RTSP控制 ...................................15
9.2. 使用會話複用的RTSP控制 .......................................16
9.3. 重傳流的RTSP控制 ............................................16
9.4. 緩存控制 ....................................................16
10. 實作範例 ........................................................16
10.1. 最小接收器實作示例 ...........................................17
10.2. 多點傳播中分層編碼媒體的重傳 ......................................17
11. IANA 注意事項 ...................................................18
12. 安全考慮因素 .....................................................18
13. 緻謝 ...........................................................18
14. 參考 ...........................................................19
14.1. 規範性參考文獻 ..............................................19
14.2. 資訊參考文獻 ................................................19
附錄A. 如何控制每個分組的重傳次數 .......................................20
Rey, et al. Standards Track [Page 2]
RFC 4588 RTP Retransmission Payload Format July 2006
1. 簡介
RTP發送器和接收器之間的分組丢失可能顯著降低所接收媒體的品質。可以考慮若幹技術，例如
前向糾錯（FEC），分組重傳或交織，以增加分組丢失彈性。RFC 2354 [8]讨論了不同的選擇。
在為特定應用程式選擇修複技術時，必須考慮應用程式的可容忍延遲。在多媒體會議的情況下，
端到端延遲必須至多幾百毫秒才能保證互動性，這通常不包括使用分組重傳。
足夠的延遲時間，可以提高修複方案的效率。發送方可以使用接收方回報，以便在接收方的播放
時間之前對損失作出反應。
在多媒體流的情況下，使用者可以容忍作為會話建立的一部分的初始等待時間，是以可以接受幾秒
的端到端延遲。本文檔中定義的RTP重傳針對此類應用程式。
此外，這裡定義的RTP重傳方法适用于單點傳播和（小）多點傳播組。本檔案定義了重傳的RTP分組的有效
載荷格式，并為重傳中涉及的發送方和接收方提供了協定規則。
此重傳有效載荷格式設計用于擴充RTP配置檔案，用于基于RTCP的回報，AVPF [1]。它也可以
與将來定義的其他RTP配置檔案一起使用。
AVPF配置檔案允許更頻繁的回報和早期回報。它定義了通用回報消息，即NACK，以及編解碼器
和特定于應用程式的回報消息。有關詳細資訊，請參見[1]。
2. 術語
本文檔中使用以下術語：
CSRC: 貢獻來源。 見[3]。
原始資料包：一個RTP資料包，它攜帶RTP發送者第一次發送的使用者資料。
原始流：原始資料包的RTP流。
重傳資料包：接收器使用的替代丢失的原始分組的RTP資料包。據說這種重傳分組與原始RTP分
組相關聯。
重傳請求：RTP接收器能夠請求RTP發送器應該發送給定原始分組的重傳分組的手段。通常，
[1]中指定的RTCP NACK分組用作丢失分組的重傳請求。
重傳流：與原始流相關聯的重傳分組流。
會話複用：将原始流和相關的重傳流發送到兩個不同的RTP會話的方案。
SSRC: 同步源。 見[3]。
SSRC複用：在具有不同SSRC值的相同RTP會話中發送原始流和重傳流的方案。
Rey, et al. Standards Track [Page 3]
RFC 4588 RTP Retransmission Payload Format July 2006
本檔案中的關鍵詞“必須”，“不得”，“需要”，“應當”，“不應當”，“應該”，“不應該”，“推薦”，
“可以”和“可選” 按照RFC 2119 [2]中的描述進行解釋。
3. 重傳方案的需求和設計理由
在具有寬松延遲界限且不需要完全可靠性的場景中，在RTP中使用重傳作為流媒體的修複方法是
适當的。更具體地說，RTP重傳允許人們在可靠性與延遲之間進行權衡; 即，在給定的緩沖時間
過去之後，端點可以放棄重傳丢失的分組。與TCP協定不同，沒有由RTP重傳引起的隊列頭阻塞。
實施者應該意識到，在需要完全可靠性或可以容忍更高延遲和抖動的情況下，應考慮TCP或其他
傳輸選項。
本文檔中定義的RTP重傳方案旨在滿足以下要求：
1. 它不能破壞通用的RTP和RTCP機制。
2. 它必須适用于單點傳播和小型多點傳播組。
3. 它必須能夠與混音器和翻譯器一起使用。
4. 它必須适用于所有已知的有效負載類型。
5. 它不能阻止在會話中使用多個有效負載類型。
6. 為了支援最大種類的有效載荷格式，RTP接收器必須能夠推導出由于接收到的RTP序列号中
的間隙而丢失了多少和哪些RTP分組。該要求稱為序列号儲存。如果沒有這樣的要求，就不
可能使用有效載荷格式的重傳，例如會話文本[9]或大多數音頻/視訊流應用，它們使用RTP
序列号來檢測丢失的資料包。
在設計用于RTP重傳的解決方案時，可以考慮若幹方法用于複用原始RTP分組和重傳的RTP分組。
一種方法可以是以其原始序列号重傳RTP分組，并在同一RTP流中發送原始和重傳分組。然後，
重傳分組将與原始RTP分組相同，即，相同的報頭（并且是以相同的序列号）和相同的有效載荷。
但是，這種方法是不可接受的，因為它會破壞RTCP統計資料。是以，不符合要求1。正确的RTCP
統計要求對于RTP流中的每個RTP分組，序列号增加1。
另一種方法可以是使用不同的有效載荷類型值在相同的RTP流中複用原始RTP分組和重傳分組。
利用這種方法，原始分組和重傳分組将共享相同的序列号空間。結果，RTP接收器将無法推斷丢
失了多少和哪些原始分組（哪個序列号）。
換句話說，該方法不滿足序列号保留要求（要求6）。這反過來意味着不滿足要求4。如果他們不
了解發送方RTP流中的這種新的重傳有效載荷類型，則與混合器和轉換器的互操作性也将更加困難。
由于這些原因，排除了基于相同RTP流中的原始分組和重傳分組的有效載荷類型複用的解決方案。
最後，原始和重傳分組可以在兩個單獨的流中發送。這兩個流可以通過在兩個不同的會話中發送
它們來進行多路複用，即，會話多路複用，或者在使用不同SSRC值的相同會話中，即SSRC多路
複用。由于原始資料包和重傳資料包攜帶相同類型的媒體，是以RTP[3]第5.2節中對RTP複用的
反對意見不适用于此情況。
混音器和翻譯器可以處理原始流，如果它們無法使用，則簡單地丢棄重傳流。
另一方面，在兩個單獨的流中發送原始資料包和重發資料包并不單獨滿足要求1和6。為此，本
文檔包含重發資料包中的原始序列号。
以這種方式，使用兩個單獨的流滿足本節中列出的所有要求。
3.1. 多路複用方案選擇
會話複用和SSRC複用具有不同的優缺點：
Rey, et al. Standards Track [Page 4]
RFC 4588 RTP Retransmission Payload Format July 2006
會話複用基于在與原始流的RTP會話（如RTP [3]中定義的）不同的RTP會話中發送重傳流;
即，原始和重傳流被發送到不同的網絡位址和/或端口号。單獨的會話允許更多的靈活性。在多
播中，對原始流和重傳流使用兩個單獨的會話允許接收器選擇是否訂閱攜帶重傳流的RTP會話。
原始會話也可以是單源多點傳播，而單獨的單點傳播會話用于向每個接收器傳送重傳，結果隻接收它們請
求的重傳分組。
單獨會話的使用還有助于網絡的差異處理，并且可以簡化混音器、轉換器和分組高速緩存中的處
理。
利用SSRC複用，原始和重傳流需要單個會話。 這允許涉及大量并發會話的流伺服器和中間件最
小化其端口使用。
該重傳有效載荷格式允許會話複用和用于單點傳播會話的SSRC複用。從實施的角度來看，這兩種方法
之間幾乎沒有差別。是以，為了最大化互操作性，發送器和接收器應該支援兩種多路複用方法。
對于多點傳播會話，必須使用會話多路複用，因為如果SSRC多路複用與多點傳播會話一起使用，原始流和
重傳流的關聯是有問題的（動機參見5.3節）。
4. 重傳有效載荷格式
重傳資料包的格式如下所示：
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 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP頭使用情況如下：
在會話多路複用的情況下，必須将相同的SSRC值用于原始流和重傳流。 在原始會話或重傳會話中
發生SSRC沖突的情況下，RTP規範要求必須在發生沖突的會話中發送RTCP BYE資料包。 此外，
還必須在其自己的會話中為相關流發送RTCP BYE資料包。 獲得新的SSRC辨別符後，兩個流的
SSRC必須設定為該值。
在SSRC複用的情況下，必須根據RTP的要求将兩個不同的SSRC值用于原始流和重傳流。如果檢測到
原始流或重傳流的SSRC沖突，則RTP規範要求必須為該流發送RTCP BYE分組。不得為關聯的流發
送RTCP BYE資料包。是以，隻有經曆過SSRC沖突的流必須選擇新的SSRC值。有關接收器上原始流
和重傳流SSRC關聯的含義，請參閱第5.3節。
Rey, et al. Standards Track [Page 5]
RFC 4588 RTP Retransmission Payload Format July 2006
對于任一複用方案，序列号具有标準定義; 即，它必須比重發流中發送的在前一分組的序列号大一。
重傳分組時間戳必須設定為原始時間戳，即原始分組的時間戳。結果，重傳流的第一個分組的初始
RTP時間戳不是随機的，而是等于重傳的第一個分組的原始時間戳。有關安全隐患，請參閱本文檔中
的“安全注意事項”部分。
實施者必須意識到重傳流的RTCP抖動值不能反映實際的網絡抖動，因為重傳資料包的時間與其原始
時間戳之間幾乎沒有相關性。
有效負載類型是動态的。如果在原始流中存在使用重傳的多個有效載荷類型，則對于這些中的每一個，
必須将動态有效載荷類型映射到重傳有效載荷格式。有關如何使用會話描述協定（SDP）完成原始和
重傳有效負載類型之間的映射的規範，請參閱第8.1節。
由于重傳分組時間戳攜帶原始媒體時間戳，重傳有效載荷類型使用的時間戳時鐘速率必須與相關原始
有效載荷類型使用的時間戳相同。是以，如果RTP流攜帶不同時鐘速率的有效載荷類型，則相關重傳
流也将是這種情況。注意，RTP流通常不攜帶不同時鐘速率的有效載荷類型。
RTP重傳分組的有效載荷包括重傳有效載荷頭部，後跟原始RTP分組的有效載荷。重傳有效載荷報頭
的長度是2個八位位元組。該有效載荷頭僅包含一個字段OSN（原始序列号），該字段必須設定為相關
原始RTP分組的序列号。原始RTP分組有效載荷（包括特定于原始有效載荷類型的任何可能的有效載
荷報頭）必須緊接在重傳有效載荷報頭之後。
對于支援多速率編碼的有效載荷格式，發送方可以重傳以較低速率編碼的相同資料，而不是重發與原
始RTP分組相同的有效載荷。這旨在限制重傳流的帶寬使用。當這樣做時，發送方必須確定接收方仍
然能夠解碼已經發送的原始分組的有效載荷，該原始分組可能已經基于丢失的原始分組的有效載荷進
行了編碼。另外，如果發送方選擇以較低的速率重新發送，則原始RTP分組的有效載荷報頭中的值可
能不再适用于重發分組，并且可能需要在重發分組中修改以反映速率的變化。發送方應該将帶寬使用
量的減少與因以較低速率重新發送而引起的品質下降進行權衡。
如果原始RTP報頭攜帶任何特定于配置檔案的擴充，則重傳資料包應該包括緊跟在固定RTP報頭之後的
相同擴充，正如在此配置檔案下運作的應用程式所期望的那樣。在這種情況下，重傳有效載荷頭必須
放在特定于配置檔案的擴充之後。
如果原始RTP報頭攜帶RTP報頭擴充，則重傳分組應該攜帶相同的報頭擴充。此标頭擴充必須緊跟在
固定RTP标頭之後，如RTP [3]中所指定。在這種情況下，重傳有效載荷頭必須放在頭擴充之後。
如果原始RTP資料包包含RTP位填充，則必須在構造重傳資料包之前删除該填充。如果需要填充重傳
分組，則必須像其他RTP分組一樣執行位填充，并且必須設定填充位。
标記位（M），CSRC計數（CC）和原始RTP報頭的CSRC清單必須“原樣”複制到重發分組的RTP報頭中。
5. 重傳流與原始流的關聯
5.1. 重傳會話共享
在會話複用的情況下，重傳會話必須映射到恰好一個原始會話; 即，相同的重傳會話不能用于不同
的原始會話。
Rey, et al. Standards Track [Page 6]
RFC 4588 RTP Retransmission Payload Format July 2006
如果允許重傳會話共享，則對于接收者來說這将是一個問題，因為他們将接收他們可能未加入的原始
會話的重傳。例如，如果音頻和視訊會話共享相同的重傳會話，則希望僅接收音頻的接收器也将接收
重傳的視訊分組。
5.2. CNAME使用
在會話多路複用和SSRC多路複用情況下，發送方必須對原始流及其關聯的重傳流使用相同的
RTCP CNAME [3]。
5.3. 接收端關聯
接收多個原始流和重傳流的接收端需要将每個重傳流與其原始流相關聯。根據是使用會話複用還是
SSRC複用，以不同方式完成關聯。
如果使用會話複用，則接收器将兩個會話中具有相同SSRC的兩個流相關聯。注意，有效載荷類型字段
不能用于執行關聯，因為若幹媒體流可能具有相同的有效載荷類型值。這兩個會話本身是帶外關聯的。
有關如何使用SDP完成兩個會話的分組，請參閱第8節。
如果使用SSRC複用，接收器首先應該在會話中尋找具有相同CNAME的兩個流。在某些情況下，CNAME
可能不足以确定關聯，因為同一會話中的多個原始流可能共享相同的CNAME。例如，在同一視訊會話
中可以存在映射到不同SSRC并且仍然使用相同CNAME并且可能使用相同有效載荷類型（PT）值的多個
視訊流。這些流中的每個（或一些）可以具有關聯的重傳流。
在這種情況下，為了找出具有相同CNAME的原始流和重傳流之間的關聯，接收器應該表現如下。
當接收端接收到與之前發送的重傳請求比對的重傳分組時，通常可以解決該關聯。在接收到先前已經
請求了其原始序列号的重發分組時，接收端可以推導出重發分組的SSRC與之前發送請求分組的發送端
SSRC相關聯。
但是，如果在會話的兩個不同原始流中存在兩個針對相同分組序列号的未完成請求，則該機制可能會失
敗。注意，由于初始分組序列号是随機的，是以對相同分組序列号具有兩個未完成請求的機率将非常小。
然而，為了避免單點傳播情況下的模糊性，接收器在解決關聯之前不得對兩個不同原始流中的相同分組序列
号有兩個未完成的請求。在多點傳播中，不能完全避免這種模糊性，因為另一個接收器可能已經從另一個流
請求了相同的序列号。是以，SSRC複用絕不能用于多點傳播會話。
如果接收方發現兩個發送方正在使用相同的SSRC或接收到RTCP BYE資料包，它必須停止請求該SSRC
的重傳。在接收到具有新SSRC的原始RTP分組時，接收器必須再次執行SSRC關聯，如本節所述。
6. 将擴充RTP配置用于基于RTCP的回報
本節給出了此有效載荷格式與基于RTCP的回報的擴充RTP配置（表示為AVPF [1]）一起使用的
一般提示。請注意，除了AVPF配置引入的更改之外，RTP中指定的一般RTCP發送和接收規則，
以及RTCP資料包格式均适用。簡而言之，AVPF配置檔案放寬了RTCP時序規則，并指定了額外的
通用RTCP回報消息。有關詳細資訊，請參見[1]。
6.1. 發送端的RTCP
在會話複用的情況下，根據RTP的規則，原始流的發送者報告（SR）分組在原始會話中發送，重
傳流的SR分組在重傳會話中發送。
Rey, et al. Standards Track [Page 7]
RFC 4588 RTP Retransmission Payload Format July 2006
在SSRC複用的情況下，根據RTP的規則，原始流和重傳流的SR分組在同一會話中發送。就RTCP帶
寬計算而言，原始流和重傳流被看作屬于相同RTP會話的獨立發送者，是以均等地共享配置設定給發送
者的RTCP帶寬。
請注意，在兩種情況下，會話複用和SSRC複用，如RTP中指定的那樣，必須為的兩個流都發送BYE
分組。換句話說，僅為原始流發送BYE分組是不夠的。
6.2. RTCP接收端報告
在會話多路複用的情況下，接收端将在屬于單獨的RTP會話的單獨的接收端報告（RR）分組中發送
原始流和重傳流的報告分組。在原始流上報告的RR分組在原始RTP會話中發送，而在重發流上報告
的RR分組在重傳會話中發送。可以獨立地選擇這兩個會話的RTCP帶寬（例如，通過RTCP帶寬修改
器[4]）。
在SSRC複用的情況下，接收端在同一RR分組中發送原始流和重傳流的報告，因為隻存在單個會話。
6.3. 重傳請求
AVPF配置檔案中定義的NACK回報消息格式應該被接收器用來發送重傳請求。接收器是否選擇請
求分組是一個實作問題。實際的接收器實作應考慮諸如可容忍的應用延遲，網絡環境和媒體類型
之類的因素。
接收方通常應評估重傳的資料包在接收時是否仍然有用。可以根據由原始流中的丢失分組引起的
序列号間隙之前和/或之後的分組的時間戳來估計丢失分組的時間戳。在大多數情況下，對時間
戳的某種形式的線性估計已足夠好。
此外，接收方應計算到發送方的往返時間（RTT）的估計。例如，這可以通過測量重傳延遲，即
在為該分組發送NACK之後多久接收到重傳分組來完成。該估計也可以從過去的觀察中，例如
RTCP報告往返時間（如果可用），或任何其他手段獲得。 接收方估計RTT的标準機制在“RTP控
制協定擴充報告（RTCP XR）”[11]中規定。
接收端不應該一檢測到丢失的序列号就發送重傳請求，而應該添加一些額外的延遲來補償分組重
新排序耗費的時間。例如，該額外延遲可以基于過去對已經曆的分組重新排序的觀察。應當注意，
在分組重新排序很少或不發生的環境中，例如，如果基礎資料鍊路層提供有序傳送，則延遲可能
非常低或者甚至為零。在這種情況下，适當的“重新排序延遲”算法實際上可能不是基于定時器的，
而是基于分組的。例如，如果在檢測到間隙之後接收到n個分組，則可以假設分組确實丢失而不是
亂序。與基于定時器的機制相反，在某些平台上作為非常短的固定FIFO分組緩沖器進行編碼可能
更容易。
為了增加對NACK或重傳分組的丢失的魯棒性，接收器可以為相同的分組發送新的NACK。這被稱
為多次重傳。在為丢失的分組發送新的NACK之前，接收器應該依賴于定時器以合理地确定先前的
重傳嘗試已經失敗并且是以避免不必要的重傳。定時器值應基于觀察到的往返時間。可以使用靜
态或自适應值。例如，自适應定時器可以是随着對同一分組的每個新請求而改變其值的定時器。
本文檔未提供有關如何計算此自适應值的指導，原因是因為尚未為如何找出它進行任何實驗。
必須僅為原始RTP流發送NACK。否則，如果接收器想要通過在重傳流中發送NACK來執行多次重傳，
則它将不能知道其請求的分組的原始序列号和時間戳估計。
附錄A給出了如何控制重傳次數的一些指導。
Rey, et al. Standards Track [Page 8]
RFC 4588 RTP Retransmission Payload Format July 2006
6.4. 時間規則
根據AVPF [1]，NACK回報消息可以在正常的完整複合RTCP分組或早期RTCP分組中發送。在早期
資料包中發送NACK可以更快地對給定的資料包丢失做出反應。然而，在這種情況下，如果在發送
早期RTCP分組之後立即發生新的分組丢失，則接收器将必須在早期分組之後等待下一個正常RTCP
複合分組。僅在正常RTCP複合分組中發送NACK會減少檢測到原始資料包丢失與能夠為該資料包發
送NACK之間的最大延遲。實作者應該為使用的應用程式考慮這個因素的可能影響。
此外，接收端可以利用正常RTCP複合分組之間的最小間隔。該間隔可用于将正常接收端報告降至
最小，同時仍允許接收端在需要更頻繁回報的時段期間發送早期RTCP分組，例如，發生更高分組
丢失率期間。請注意，雖然RTCP資料包可以因為不包含NACK而被抑制，但是需要提供與如果發送
時相同的RTCP帶寬。有關如何使用最小間隔的詳細資訊，請參閱AVPF [1]。
7. 擁塞控制
RTP重傳會增加網絡擁塞的風險。在盡力而為的環境中，分組丢失是由擁塞引起的。在不降低原始
流的碼率的情況下，通過重傳舊資料來對丢失作出反應将進一步增加擁塞。實施應該遵循以下建議，
以便使用重傳。
使用重傳方案的RTP配置檔案定義了不同環境中的恰當擁塞控制機制。遵循配置檔案下的規則，
RTP應用程式可以确定其可接受的比特率和資料包速率，以對其他TCP或RTP流公平。
如果RTP應用程式使用重傳，則可接受的分組速率和比特率包括原始資料和重傳資料。這保證了
使用重傳的應用程式實作了與不重傳的應用程式相同的公平性。這樣的規則在實踐中會轉化為以
下行動：
如果使用增強型服務，則應確定總比特率和資料包速率不超過所請求服務的比特率和資料包速率。
應進一步監測所請求的服務是否實際傳遞。在盡力而為的環境中，發送方不應該在不降低原始流
的分組速率和比特率的情況下發送重傳分組（例如，通過以較低的速率編碼資料）。
另外，發送方可以選擇性地僅重傳它認為重要的分組，并忽略其他分組的NACK消息以限制比特率。
這些擁塞控制機制應将丢包率保持在可接受的參數範圍内。在擁塞控制的情況下，如果跨越相同
網絡路徑并且經曆相同網絡條件的TCP流将在合理的時間尺度上實作不小于RTP流所達到的平均吞
吐量，則認為分組丢失是可接受的。如果沒有控制擁塞，那麼不應該使用重傳。
在某些情況下仍可以發送重傳，例如，在資料包丢失不是由擁塞引起的無線鍊路中，如果伺服器
（或發出重傳請求的用戶端）評估特定資料包或幀對于繼續播放很重要， 或者假如已發出RTSP
PAUSE以允許填充緩沖區（RTSP PAUSE不影響重傳分組的發送）。
最後，可能還需要調整傳輸速率（或訂閱分層多點傳播會話的層數），或者安排接收方離開會話。
8. 重傳有效載荷格式的MIME類型注冊
8.1. 介紹
本文檔中引入了以下MIME子類型名稱和參數：“rtx”，“rtx-time”和“apt”。
用rtpmap屬性訓示重傳流到有效載荷類型值的綁定。綁定中使用的MIME子類型名稱是“rtx”。
Rey, et al. Standards Track [Page 9]
RFC 4588 RTP Retransmission Payload Format July 2006
必須使用“apt”（關聯的有效載荷類型）參數将重傳有效載荷類型映射到關聯的原始流有效載荷
類型。如果使用多個原始有效載荷類型，則必須包括多個“apt”參數以将每個原始有效載荷類型
映射到不同的重傳有效載荷類型。
可選的有效載荷格式特定參數“rtx-time”表示發送方将其原始RTP分組保留在其可用于重傳的
緩沖區中的最大時間。此時間從資料包的第一次傳輸開始計算。
文法如下：
a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>
其中
<number>: 表示在rtpmap屬性中配置設定給重傳有效載荷格式的動态有效載荷類型編号。
<apt-value>: 是與此重新傳輸流有效負載類型關聯的原始流有效負載類型的值。
<rtx-time-val>: 指定發送方将RTP資料包保留在其可用于重新傳輸的緩沖區中的以毫秒
為機關的時間（從資料包首次發送的時間開始計算）。缺少重傳流的rtx-time參數意味着
沒有定義最大重傳時間，但可以通過其他方式協商。
8.2. 注冊audio/rtx
MIME type: audio
MIME subtype: rtx
必需參數：
rate: RTP時間戳時鐘速率，等于重傳媒體的RTP時間戳時鐘速率。
apt: 關聯的有效載荷類型。此參數的值是關聯的原始流的有效載荷類型。
可選參數：
rtx-time: 表示發送方将RTP資料包保留在可用于重新傳輸的緩沖區中的以毫秒為機關的
時間（以資料包首次發送的時間為機關）。
編碼注意事項：此類型僅定義為通過RTP傳輸。
安全注意事項：請參閱RFC 4588的第12節
互操作性考慮因素：無
釋出規範：RFC 4588
使用此媒體類型的應用程式：多媒體流應用程式
附加資訊：無
Rey, et al. Standards Track [Page 10]
RFC 4588 RTP Retransmission Payload Format July 2006
聯系人和電子郵件位址以擷取更多資訊：
[email protected]
[email protected]
[email protected]
預期用途：COMMON
作者:
Jose Rey
David Leon
改變控制者:
IETF AVT WG delegated from the IESG
8.3. 注冊video/rtx
MIME type: video
MIME subtype: rtx
必需參數：
rate: RTP時間戳時鐘速率，等于重傳媒體的RTP時間戳時鐘速率。
apt: 關聯的有效載荷類型。此參數的值是關聯的原始流的有效載荷類型。
可選參數：
rtx-time: 表示發送方将RTP資料包保留在可用于重新傳輸的緩沖區中的以毫秒為機關的
時間（以資料包首次發送的時間為機關）。
編碼注意事項：此類型僅定義為通過RTP傳輸。
安全注意事項：請參閱RFC 4588的第12節
互操作性考慮因素：無
釋出規範：RFC 4588
使用此媒體類型的應用程式：多媒體流應用程式
附加資訊：無
聯系人和電子郵件位址以擷取更多資訊：
[email protected]
[email protected]
[email protected]
預期用途：COMMON
Rey, et al. Standards Track [Page 11]
RFC 4588 RTP Retransmission Payload Format July 2006
作者:
Jose Rey
David Leon
改變控制者:
IETF AVT WG delegated from the IESG
8.4. 注冊text/rtx
MIME type: text
MIME subtype: rtx
必需參數：
rate: RTP時間戳時鐘速率，等于重傳媒體的RTP時間戳時鐘速率。
apt: 關聯的有效載荷類型。此參數的值是關聯的原始流的有效載荷類型。
可選參數：
rtx-time: 表示發送方将RTP資料包保留在可用于重新傳輸的緩沖區中的以毫秒為機關的
時間（以資料包首次發送的時間為機關）。
編碼注意事項：此類型僅定義為通過RTP傳輸。
安全注意事項：請參閱RFC 4588的第12節
互操作性考慮因素：無
釋出規範：RFC 4588
使用此媒體類型的應用程式：多媒體流應用程式
附加資訊：無
聯系人和電子郵件位址以擷取更多資訊：
[email protected]
[email protected]
[email protected]
預期用途：COMMON
作者:
Jose Rey
David Leon
改變控制者:
IETF AVT WG delegated from the IESG
Rey, et al. Standards Track [Page 12]
RFC 4588 RTP Retransmission Payload Format July 2006
8.5. 注冊application/rtx
MIME type: application
MIME subtype: rtx
必需參數：
rate: RTP時間戳時鐘速率，等于重傳媒體的RTP時間戳時鐘速率。
apt: 關聯的有效載荷類型。此參數的值是關聯的原始流的有效載荷類型。
可選參數：
rtx-time: 表示發送方将RTP資料包保留在可用于重新傳輸的緩沖區中的以毫秒為機關的
時間（以資料包首次發送的時間為機關）。
編碼注意事項：此類型僅定義為通過RTP傳輸。
安全注意事項：請參閱RFC 4588的第12節
互操作性考慮因素：無
釋出規範：RFC 4588
使用此媒體類型的應用程式：多媒體流應用程式
附加資訊：無
聯系人和電子郵件位址以擷取更多資訊：
[email protected]
[email protected]
[email protected]
預期用途：COMMON
作者:
Jose Rey
David Leon
改變控制者:
IETF AVT WG delegated from the IESG
Rey, et al. Standards Track [Page 13]
RFC 4588 RTP Retransmission Payload Format July 2006
8.6. 映射到SDP
MIME媒體類型規範中攜帶的資訊具有SDP [5]中字段的特定映射，SDP [5]通常用于描述RTP
會話。當SDP用于指定RTP流的重傳時，映射完成如下：
- MIME類型（“video”），（“audio”），（“text”）和（“application”）在SDP“m=”
中作為媒體名稱。
- MIME子類型（“rtx”）在SDP“a=rtpmap”中作為編碼名稱。“a=rtpmap”中的RTP時鐘速率
必須是重傳有效載荷類型的時鐘速率。有關詳細資訊，請參閱第4節。
- AVPF特定于配置檔案的參數“ack”和“nack”在SDP中表示為“a = rtcp-fb”。幾個SDP
“a=rtcp-fb”用于幾種類型的回報。詳細資訊請參閱AVPF配置檔案[1]。
- 重傳有效載荷格式特定參數“apt”和“rtx-time”在SDP“a=fmtp”中作為以分号分隔的
parameter=value清單。
- 任何剩餘參數都在SDP的“a=fmtp”屬性中，通過直接從MIME媒體類型字元串複制它們作為
以分号分隔的parameter=value清單。
在以下部分中，将介紹一些SDP描述示例。在這些示例中的一些示例中，折疊長行以滿足本文檔
的列寬限制; 行尾的反斜杠（“\”）和後面的回車應該被忽略。
8.7. 使用會話多路複用的SDP描述
在會話多路複用的情況下，SDP描述的每個RTP會話包含一個媒體規範“m”行。SDP必須使用RFC
3388 [6]中定義的流辨別（FID）語義，提供原始和相關重傳會話的“m”行的分組。
以下示例分别在端口49170和49174上指定兩個原始AMR和MPEG-4流以及它們在端口49172和
49176上的相應重傳流：
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
a=group:FID 1 2
a=group:FID 3 4
m=audio 49170 RTP/AVPF 96
a=rtpmap:96 AMR/8000
a=fmtp:96 octet-align=1
a=rtcp-fb:96 nack
a=mid:1
m=audio 49172 RTP/AVPF 97
a=rtpmap:97 rtx/8000
a=fmtp:97 apt=96;rtx-time=3000
a=mid:2
m=video 49174 RTP/AVPF 98
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F
Rey, et al. Standards Track [Page 14]
RFC 4588 RTP Retransmission Payload Format July 2006
a=mid:3
m=video 49176 RTP/AVPF 99
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
a=mid:4
SDP描述的特殊情況是僅包含一個原始會話“m”行和一個重傳會話“m”行的描述，如何分組顯而易
見，在這種特殊情況下可以省略FID文法。
這在以下示例中做了示範，該示例是單個原始MPEG-4流及其相應重傳會話的SDP描述：
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
m=video 49172 RTP/AVPF 97
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
8.8. 使用SSRC多路複用的SDP描述
以下是使用SSRC複用的RTP視訊會話的SDP描述示例，該複用具有與上述單會話示例中類似的
參數：
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
9. RTSP注意事項
實時流協定（RTSP）RFC 2326 [7]，是一種應用程式級協定，用于控制具有實時屬性的資料
傳輸。本節介紹控制支援分組重傳的RTP會話所涉及的問題。
9.1. 使用SSRC多路複用的RTSP控制
在SSRC複用的情況下，“m”行包括原始和重傳有效載荷類型，并且具有單個RTSP“control”屬
性。接收器使用“m”行來請求整個媒體會話的SETUP和TEARDOWN。傳輸頭中包含的RTP配置檔案
必須是AVPF配置檔案或允許擴充回報的其他合适的配置檔案。如果SSRC值包含在SETUP響應的
傳輸頭中，則它必須是原始流的值。
Rey, et al. Standards Track [Page 15]
RFC 4588 RTP Retransmission Payload Format July 2006
為了控制會話原始媒體流的發送，接收器像往常一樣向發送者發送PLAY和PAUSE請求以進行會
話。用于在PLAY響應中設定RTP特定參數的RTP-info報頭必須根據原始流的RTP資訊進行設定。
當接收器開始接收原始流時，它可以通過RTCP NACK請求重傳，而無需額外的RTSP信令。
9.2. 使用會話複用的RTSP控制
在會話多路複用的情況下，每個SDP“m”行具有RTSP“control”屬性。是以，當使用重傳時，
原始會話和重傳都具有它們自己的“control”屬性。接收方可以通過第8節中規定的FID語義将
原始會話和重傳會話相關聯。
原始和重傳流通過它們各自的媒體“control”屬性分别建立和拆除。傳輸頭中包含的RTP配置
檔案必須是AVPF配置檔案或其他合适的允許原始會話和重傳會話擴充回報的配置檔案。
RTSP示範應該支援聚合控制，并且應該包含會話級RTSP URL。接收方應該對原始會話及其相
關的重傳會話使用聚合控制。否則，将需要兩個不同的“session-id”值，即原始會話和重傳
會話的不同值，并且發送者将不知道如何關聯它們。
通常使用會話級“control”屬性來控制原始流的播放。當接收器開始接收原始流時，它可以通
過RTCP請求重傳，而無需額外的RTSP信令。
9.3. 重傳流的RTSP控制
由于重傳的性質，重傳資料包的發送不應該通過RTSP PLAY和PAUSE請求來控制。PLAY和
PAUSE請求不應該影響重傳流。無論狀态如何，重傳分組都根據接收器在原始RTCP流中請求時
發送。
9.4. 緩存控制
重傳流不應該被緩存。
在會話多路複用的情況下，“Cache-Control”頭應該為重傳流設定為“no-cache”。
在SSRC多路複用的情況下，RTSP不能為重傳流指定獨立的緩存，因為SDP中隻有單個“m”行。
是以，實作者在決定是否緩存SSRC多路複用會話時，應該考慮這個事實。
10. 實作範例
本文檔僅規定了互操作性所必需的發送方和接收方行為。此外還規定了某些可以增強重傳效率算
法，例如針對特定環境時的速率控制或緩沖管理。
本節概述了本規範中允許的不同實作選項。
第一個示例描述了最小接收器實作。通過該實作，如果需要，可以重傳丢失的RTP分組，有效地
檢測重傳分組的丢失，并執行多次重傳。 大多數必要的處理都是在伺服器上完成的。
第二個示例顯示了如何在（小）多點傳播組中結合分層編碼使用重傳。它說明重傳和分層編碼在技術
上可以是互補的。
Rey, et al. Standards Track [Page 16]
RFC 4588 RTP Retransmission Payload Format July 2006
10.1. 最小接收器實作示例
本節給出了支援多次重傳的實作示例。發送方使用MPEG-4視訊RTP有效載荷格式在RTP分組中發
送原始資料。假設使用NACK回報消息，如[1]所示。下面給出使用了SSRC多路複用的SDP描述示
例：
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
特定于格式的參數“rtx-time”表示伺服器将在重發緩沖區中緩沖發送的資料包3.0秒，之後數
據包将從重發緩沖區中删除，永遠不會再次發送。
在該實作示例中，處理重傳所需的RTP接收器處理被減到最小。接收器從接收到的序列号中觀察
間隙檢測分組的丢失。它通過AVPF配置檔案[1]中定義的NACK向發送方通知丢失的分組。接收
器應考慮已通知的發送器重傳緩沖區長度，以确定自己的接收緩沖區長度。它還應該從緩沖區長
度導出可以重新請求重傳分組的最大次數。
發送方應選擇性地重新發送資料包; 即，它應該根據分組重要性，觀察到的服務品質（QoS）和
到接收器的網絡連接配接的擁塞狀态來選擇是否重傳所請求的分組。顯然，發送器處理随着接收器的
數量而增加，因為必須為每個接收器配置設定狀态資訊和處理負載。
10.2. 多點傳播中分層編碼媒體的重傳
本節介紹如何在多點傳播會話中将重新傳輸與分層編碼相結合。請注意，重傳架構僅适用于小型多點傳播
應用。請參閱RFC 2887 [10]查找有關在大組可靠多點傳播應用中因回報流量引起的NACK爆炸，嚴
重擁塞問題的讨論。
重要性不同的分組在不同的RTP會話中傳送。對應于不同層的重傳流本身可以被視為不同的重傳
層。不同重傳流的相對重要性應反映不同原始流的相對重要性。
根據本文檔的第5.3節，在多點傳播中不允許對原始流和重傳流進行SSRC複用。是以，必須使用會話
複用，在不同的RTP會話中發送重傳流。
下面給出了分層編碼媒體的多點傳播重傳的SDP描述示例：
m=video 8000 RTP/AVPF 98
c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99
c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000
Rey, et al. Standards Track [Page 17]
RFC 4588 RTP Retransmission Payload Format July 2006
伺服器和接收器可以實作先前示例中所示的重傳方法。此外，他們可以根據其所屬的層選擇請求
和重新傳輸丢失的資料包。
11. IANA 注意事項
已經為四種不同的媒體類型注冊了新的MIME子類型名稱“rtx”，如下所示：“video”，“audio”，
“text”和“application”。還定義了附加的REQUIRED參數“apt”和OPTIONAL參數“rtx-time”。
詳見第8節。
12. 安全考慮因素
使用本規範中定義的有效載荷格式的RTP分組遵從RTP [3]第9節中讨論的通用安全考慮。
在常見的流傳輸方案中都希望實作消息認證、資料完整性、重播保護和機密性。
缺少身份驗證可能會導緻中途人為修改資料攻擊和重播攻擊，這對RTP分組重傳非常有害。例如：
被篡改的RTCP分組可能觸發不适當的重傳，顯著地減少配置設定給原始資料流的實際比特率份額，
被篡改的RTP重傳分組可能導緻用戶端的解碼器崩潰，并且篡改的重傳請求可能使本文第5節中描
述的SSRC關聯機制失效。另一方面，重播的分組可能導緻錯誤的重新排序和RTT測量（重傳請求
政策所需），并可能導緻接收器緩沖區溢出。
此外，為了確定資料的機密性，需要加密原始有效載荷資料。實際上不需要加密2位元組重傳有效載
荷報頭，因為它沒有提供關于資料内容的任何提示。
此外，建議用于此有效載荷格式的加密機制提供針對已知明文攻擊的保護。RTP建議初始RTP時間
戳應該是随機的，以保護流免受已知的明文攻擊。此有效載荷格式不遵循此建議，因為初始時間戳
将是第一個重新傳輸分組的媒體時間戳。但是，由于原始流的初始時間戳本身是随機的，如果原始
流被加密，則第一個重新發送的分組時間戳對于攻擊者也是随機的。是以，保密性不會受到損害。
如果使用加密技術在原始流上提供安全服務，則必須在重傳流上提供具有相同加密強度的相同服務。
對重傳的流和原始流使用相同的密鑰可能導緻安全問題，例如，兩次性密鑰。有關兩次性密鑰的含
義以及如何避免它們的讨論，請參閱安全實時傳輸協定（SRTP）[12]的第9.1節。
在撰寫本文檔時，SRTP不提供所提及的所有安全服務。 至少有兩個原因：1）兩次性密鑰的出現，
和2）這種有效載荷格式通常在RTP/AVPF配置檔案下工作而SRTP僅支援RTP/AVP的事實。SRTP
的改編版本将在未來解決這些缺點。
使用重傳的擁塞控制考慮因素在本檔案的第7節中讨論。
13. 緻謝
我們要感謝Carsten Burmeister參與本檔案的制定。我們還要感謝Koichi Hata，Colin
Perkins，Stephen Casner，Magnus Westerlund，Go Hori和Rahul Agarwal的有益評
論。
Rey, et al. Standards Track [Page 18]
RFC 4588 RTP Retransmission Payload Format July 2006
14. 參考
14.1. 規範性參考文獻
[1] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP profile for Real-time Transport Control Protocol
(RTCP)-Based feedback", RFC 4585, July 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[7] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
14.2. 資訊參考文獻
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[9] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[10] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L.,
and M. Luby, "The Reliable Multicast Design Space for Bulk Data
Transfer", RFC 2887, August 2000.
[11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003.
[12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
Rey, et al. Standards Track [Page 19]
RFC 4588 RTP Retransmission Payload Format July 2006
附錄A. 如何控制每個分組的重傳次數
找出每個分組的重傳次數（rtxs）以實作可能的最優傳輸是一項艱巨的任務。當然，最小值應為1;
否則請勿使用此有效負載格式。此外，截至本文釋出之日，作者尚未發現任何用于獲得最佳性能的
每分組重傳次數的研究。為了幫助實施者和研究人員，本節描述了實作給定數量的重傳所需的緩沖
時間的估計。計算完這段時間後，可以通過SDP參數“rtx-time”将其傳送給用戶端，如本文檔中
所定義。
A.1. 情景和假設
* 具有寬松延遲界限的流式場景。用戶端和伺服器具有緩沖空間，如SDP中的參數“rtx-time”
所示。
* 使用的RTP AVPF配置的SSRC複用重傳方案：一個SSRC用于原始分組，另一個SSRC用于重傳
分組。
* 預設RTCP帶寬份額用于SR和RR報告，即SR+RR=0.05。我們有發送端（2）和接收端（1）。
接收端和發送端同等地獲得RTCP帶寬份額的1/3，因為發送方的比例大于會話成員的1/4。
* avg-rtcp-size近似為120個位元組 這是2個SR的舍入平均值，每個SSRC一個，包含
40/8/28/32個位元組，用于帶有CNAME的IPv6/UDP/SR/SDES，是以每個共105個位元組;
對于IPv6/UDP/2*RR/SDES，具有40/8/64/32位元組的RR，共157個位元組。由于發送端和接收
端共享RTCP帶寬，是以avg-rtcp-size=(157+105+105)/3=117.3~=120位元組。這個值的
重要特征是它超過100個位元組，這似乎是典型配置的代表性數字。
* 使用的配置檔案是AVPF [1]，使用通用NACK請求重傳。這讓每個NACK增加了16個位元組的開銷，
每個附加的NACK回報控制資訊（FCI）字段并且增加了4個位元組的開銷。
* 我們假設一種最壞情況，其中每個分組在被接收之前耗盡其對應的可用重傳次數N。這意味着
如果請求分組重傳最多2次，則相應的請求該特定分組的通用NACK報告請求 在兩個連續的
RTCP複合包中發送。同樣地，如果要求重傳10次，則通用NACK被發送10次。該假設使得
RTCP分組大小在N*RTCP間隔（秒）之後大緻恒定，即，對于
avg-rtcp-size=120+(receiver-RTCP-bw-share)*(12 + 4*N)。在我們的例子中，
接收器RTCP帶寬份額是1/3，是以，avg-rtcp-size = 124 + 4*N/3。
* 兩個延遲參數難以近似，并且可能依賴于實作。是以，我們在此明确列出它們而不為它們配置設定
特定值：一個是丢包檢測時間（T2），另一個是回報處理和重傳排隊時間（T5）。實施者應
為這兩個參數配置設定适當的值。
Rey, et al. Standards Track [Page 20]
RFC 4588 RTP Retransmission Payload Format July 2006
從圖形上看，我們有以下内容：
Sender
+-+---------------------------------^-----\-----------------
\ \ / \
\ \ | |
SN=0 \ \ SN=1 / \ RTX(SN=0)
\ \ / \
X \ / \
`. / \
\ / \
\ | |
\ / \ ......
\ / \
-------------V----D--------/-----------------------V--------
T1 T2 T3 T4 T5 T1 ........
Receiver
說明：
=======
DL: 下行鍊路（發送端->接收端）
UL: 上行鍊路（接收端->發送端）
時間機關是秒，s。
比特率機關是位每秒，bps。
下行鍊路傳輸時間: T1 = physical-delay-DL +
tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter
丢包檢測時間: T2 = pkt-loss-detect-time
報告丢包時間: T3 = time-to-next-rtcp-report
上行鍊路傳輸時間: T4 = physical-delay-UL +
transmission-delay-UL + interarrival-delay-jitter
重傳處理時間: T5 = feedback-processing-time + rtx-queuing-time
A.2. 目标
為了得到緩沖時間T()的估計值，流伺服器使用該值 為每個分組啟用給定數量的重傳N。如果假
設用戶端在T1秒後開始緩沖，則該時間在伺服器和用戶端大緻相等。
A.3. 解決方案
首先，我們找到1次重傳的估計值，
T(1)=T:
T = T1 + T2 + T3 + T4 + T5
Rey, et al. Standards Track [Page 21]
RFC 4588 RTP Retransmission Payload Format July 2006
因為 T1 + T4 ~= RTT,
T = RTT + T2 + T3 + T5
T3的最壞情況是我們假設報告必須等待整個RTCP間隔并且應用最大随機因子1.5。是以，在采取
後續補償以避免突發流量後（參見RTP [3]的附錄A.7），我們得到
T3 = 1.5 / 1.21828 * RTCP-Interval。進而，
T = RTT + 1.2312*RTCP-Interval + T2 + T5
另一方面，RTCP-Interval = avg-rtcp-size*8*(senders + receivers)/(RR+RS)。
在這種情況下：sender + receivers = 3; RR + RS是接收方報告加上發送方報告帶寬份額，
在這種情況下，等于預設會話帶寬bw的5％。 我們假設平均RTCP資料包大小，
avg-rtcp-size = 120位元組。 進而，一次重傳的時間為：
T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5
為了啟用N次重傳，流伺服器或用戶端中的可用緩沖時間大約為：
T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5)
如上所述，
avg-rtcp-size = 120 + (receiver-RTCP-bw-share)*(12 + 4*N)
= 120 + (1/3)*(12 + 4*N)
= 124 + 4*N/3.
Rey, et al. Standards Track [Page 22]
RFC 4588 RTP Retransmission Payload Format July 2006
A.4. Numbers
如果我們忽略T2和T5的影響，即假設立即檢測到所有丢失，并且由于回報處理或重傳排隊沒有
額外的延遲，我們對于不同的N值有以下緩沖時間：
RTCP w/ several Generic NACKs; variable packet size = 124 + 4*N/3
bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
64000 0,05 1,21 2,44 6,28 8,97 13,18
128000 0,05 0,63 1,27 3,27 4,66 6,84
256000 0,05 0,34 0,68 1,76 2,50 3,67
512000 0,05 0,19 0,39 1,00 1,43 2,09
1024000 0,05 0,12 0,25 0,63 0,89 1,29
5000000 0,05 0,06 0,13 0,33 0,46 0,66
10000000 0,05 0,06 0,11 0,29 0,41 0,58
64000 0,2 1,36 2,74 7,03 10,02 14,68
128000 0,2 0,78 1,57 4,02 5,71 8,34
256000 0,2 0,49 0,98 2,51 3,55 5,17
512000 0,2 0,34 0,69 1,75 2,48 3,59
1024000 0,2 0,27 0,55 1,38 1,94 2,79
5000000 0,2 0,21 0,43 1,08 1,51 2,16
10000000 0,2 0,21 0,41 1,04 1,46 2,08
64000 1 2,16 4,34 11,03 15,62 22,68
128000 1 1,58 3,17 8,02 11,31 16,34
256000 1 1,29 2,58 6,51 9,15 13,17
512000 1 1,14 2,29 5,75 8,08 11,59
1024000 1 1,07 2,15 5,38 7,54 10,79
5000000 1 1,01 2,03 5,08 7,11 10,16
10000000 1 1,01 2,01 5,04 7,06 10,08
Rey, et al. Standards Track [Page 23]
RFC 4588 RTP Retransmission Payload Format July 2006
為了量化不考慮Generic NACKS的錯誤，我們可以用相同的數值，但忽略Generic NACK的
影響，avg-rtcp-size~ = 120位元組。正如我們從下面看到的，對于較低的帶寬值和較高的
重傳次數場景，這可能導緻1-1.5秒（5-10％）的緩沖區估計誤差。在該場景下影響并不大。
不管怎麼說，應針對特定情況仔細評估，這就是公式包含它的原因。
RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
|============|=====|======================================|
| RTP BW | RTT | N value |
|============|=====| 1 2 5 7 10 |
|======================================|
64000 0,05 1,16 2,32 5,79 8,11 11,58
128000 0,05 0,60 1,21 3,02 4,23 6,04
256000 0,05 0,33 0,65 1,64 2,29 3,27
512000 0,05 0,19 0,38 0,94 1,32 1,89
1024000 0,05 0,12 0,24 0,60 0,83 1,19
5000000 0,05 0,06 0,13 0,32 0,45 0,64
10000000 0,05 0,06 0,11 0,29 0,40 0,57
64000 0,2 1,31 2,62 6,54 9,16 13,08
128000 0,2 0,75 1,51 3,77 5,28 7,54
256000 0,2 0,48 0,95 2,39 3,34 4,77
512000 0,2 0,34 0,68 1,69 2,37 3,39
1024000 0,2 0,27 0,54 1,35 1,88 2,69
5000000 0,2 0,21 0,43 1,07 1,50 2,14
10000000 0,2 0,21 0,41 1,04 1,45 2,07
64000 1 2,11 4,22 10,54 14,76 21,08
128000 1 1,55 3,11 7,77 10,88 15,54
256000 1 1,28 2,55 6,39 8,94 12,77
512000 1 1,14 2,28 5,69 7,97 11,39
1024000 1 1,07 2,14 5,35 7,48 10,69
5000000 1 1,01 2,03 5,07 7,10 10,14
10000000 1 1,01 2,01 5,04 7,05 10,07
Rey, et al. Standards Track [Page 24]
RFC 4588 RTP Retransmission Payload Format July 2006
Authors' Addresses
Jose Rey
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-134
Fax: +49-6103-766-166
EMail: [email protected]
David Leon
Consultant
EMail: [email protected]
Akihiro Miyazaki
Matsushita Electric Industrial Co., Ltd
1006, Kadoma, Kadoma City, Osaka, Japan
Phone: +81-6-6900-9172
Fax: +81-6-6900-9173
EMail: [email protected]
Viktor Varsa
Nokia Research Center
6000 Connection Drive
Irving, TX. USA
Phone: 1-972-374-1861
EMail: [email protected]
Rolf Hakenberg
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
Phone: +49-6103-766-162
Fax: +49-6103-766-166
EMail: [email protected]
Rey, et al. Standards Track [Page 25]
RFC 4588 RTP Retransmission Payload Format July 2006
完整的版權聲明
版權所有（C）網際網路協會（2006年）。
本檔案受BCP 78中包含的權利，許可和限制的限制，除非其中規定，作者保留其所有權利。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
知識産權
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[email protected].
緻謝
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rey, et al. Standards Track [Page 26]
RFC 4588 RTP Retransmission Payload Format July 2006
轉載于:https://www.cnblogs.com/swordc007/p/10718519.html
![【網絡篇】第五篇——網絡套接字程式設計(一)(socket詳解)socket程式設計LINUX下socket程式的示範[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)