RFC 4585 基於實時傳輸控制協議(RTCP)反饋的擴展RTP(RTP/AVPF)配置文件

 

 

 

Network Working Group J. Ott
Request for Comments: 4585 Helsinki University of Technology
Category: Standards Track S. Wenger
Nokia
N. Sato
Oki
C. Burmeister
J. Rey
Matsushita
July 2006

基於實時傳輸控制協議(RTCP)反饋的擴展RTP(RTP/AVPF)配置文件

本備忘錄的狀態

本文檔爲Internet社區指定了Internet標準跟蹤協議，並請求討論和改進建議。有關本協議
的標準化程度和文檔狀態，請參閱當前版本的「Internet官方協議標準」（STD 1）。本備忘
錄的發佈是無限制的。

版權聲明

版權全部（C）互聯網協會（2006年）。

摘要

使用RTP的實時媒體流在某種程度上能夠抵禦分組丟失。接收器可使用實時傳輸控制協議
（RTCP）的基本機制來報告分組接收統計，從而容許發送者在中期調整其傳輸行爲。這是反饋
和基於反饋的錯誤修復的惟一手段（除了一些特定於編解碼器的機制）。該文檔定義了音視頻配
置文件（AVP）的擴展，使得接收器可以在統計上向發送者提供更即時的反饋，從而容許實現短
期適應和更有效的基於反饋的修復機制。這種早期反饋配置文件（AVPF）維護了RTCP的AVP帶
寬限制，並保留了大型組的可擴展性。

 

 

 

 

Ott, et al. Standards Track [Page 1]

RFC 4585 RTP/AVPF July 2006

Table of Contents

1. Introduction ....................................................3
1.1. Definitions ................................................3
1.2. Terminology ................................................5
2. RTP and RTCP Packet Formats and Protocol Behavior ...............6
2.1. RTP ........................................................6
2.2. Underlying Transport Protocols .............................6
3. Rules for RTCP Feedback .........................................7
3.1. Compound RTCP Feedback Packets .............................7
3.2. Algorithm Outline ..........................................8
3.3. Modes of Operation .........................................9
3.4. Definitions and Algorithm Overview ........................11
3.5. AVPF RTCP Scheduling Algorithm ............................14
3.5.1. Initialization .....................................15
3.5.2. Early Feedback Transmission ........................15
3.5.3. Regular RTCP Transmission ..........................18
3.5.4. Other Considerations ...............................19
3.6. Considerations on the Group Size ..........................20
3.6.1. ACK Mode ...........................................20
3.6.2. NACK Mode ..........................................20
3.7. Summary of Decision Steps .................................22
3.7.1. General Hints ......................................22
3.7.2. Media Session Attributes ...........................22
4. SDP Definitions ................................................23
4.1. Profile Identification ....................................23
4.2. RTCP Feedback Capability Attribute ........................23
4.3. RTCP Bandwidth Modifiers ..................................27
4.4. Examples ..................................................27
5. Interworking and Coexistence of AVP and AVPF Entities ..........29
6. Format of RTCP Feedback Messages ...............................31
6.1. Common Packet Format for Feedback Messages ................32
6.2. Transport Layer Feedback Messages .........................34
6.2.1. Generic NACK .......................................34
6.3. Payload-Specific Feedback Messages ........................35
6.3.1. Picture Loss Indication (PLI) ......................36
6.3.2. Slice Loss Indication (SLI) ........................37
6.3.3. Reference Picture Selection Indication (RPSI) ......39
6.4. Application Layer Feedback Messages .......................41
7. Early Feedback and Congestion Control ..........................41
8. Security Considerations ........................................42
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................47
11. References ....................................................48
11.1. Normative References .....................................48
11.2. Informative References ...................................48

 

 

Ott, et al. Standards Track [Page 2]

RFC 4585 RTP/AVPF July 2006

1. 介紹

使用RTP的實時媒體流在某種程度上能夠抵禦數據包丟失。RTP [1]提供了全部必要的機制來恢
復發送者處的順序和時序，以便在接收者處正確地再現媒體流。RTP還提供全部相關接收器的整
體接收質量的連續反饋，從而容許發送器在中途（大約幾秒到幾分鐘）將其編碼方案和傳輸行爲
與觀察到的網絡服務質量（QoS）相適配。可是，除少數特定於有效載荷的機制[6]外，RTP沒
有規定容許發送者當即修復媒體流的及時反饋：如經過重傳，追溯前向糾錯（FEC）控制或對於
某些視頻編解碼器的特定媒體機制，例如參考圖像選擇等。

當前可用於RTP的提升錯誤恢復能力的機制包括音頻冗餘編碼[13]，視頻冗餘編碼[14]，RTP級
FEC [11]，以及爲實現更穩定的媒體流傳輸的通常注意事項[12]。能夠主動應用這些機制（從
而增長給定媒體流的帶寬）。或者，在具備小往返時間（RTT）的足夠小的組中，發送者可使
用上述機制和/或媒體編碼特定方法按需執行修復。請注意，「小組」和「足夠小的RTT」都是高度
依賴於應用的。

本文檔經過兩個修改和補充，爲基於[1]和[2]的最小控制規定了音視頻會議的改進版RTP配置
文件：首先，爲了實現及時反饋，引入早期RTCP消息的概念，以及在小型組播組中實現低延遲
反饋（並防止在大型組中發生反饋消息內爆）的算法。特別考慮了點對點場景。其次，定義少許
通用反饋消息，以及用於編解碼器和特定於應用的反饋信息格式，以在RTCP有效載荷中進行傳
輸。

1.1. 定義

在RTP/RTCP [1]協議文檔和」具備最小控制的音視頻會議RTP配置文件」[2]中的定義適用於本
文。此外，本文檔中使用瞭如下定義：

 

 

 

Ott, et al. Standards Track [Page 3]

RFC 4585 RTP/AVPF July 2006

早期RTCP模式：
媒體流的接收者一般（但不老是）可以將感興趣的事件在接近其發生時間內報告給發送者的
操做模式。在早期RTCP模式下，RTCP分組根據本文檔中定義的時序規則進行傳輸。

早期RTCP分組：
早期RTCP分組是指比在遵循參考文檔[1]的調度算法容許的時間更早發送的分組，其緣由是
接收方觀察到的「事件」。早期RTCP分組能夠以即時反饋模式和以早期RTCP模式發送。發送
早期RTCP分組在本文檔中也稱爲發送早期反饋。

事件：
媒體流的接收者對發送者（可能）感興趣的事件的觀察，例如丟包、分組接收或者丟幀等等，
所以經過反饋信息手段向發送者報告是有用的。

反饋（FB）消息：
本文檔中定義的RTCP消息用於將除了在RTCP接收方報告（RR）中攜帶的接收方長期狀態信
息以外的，在接收方觀察到的事件的相關信息傳送回媒體流發送方。爲清楚起見，反饋消息
在本文檔中稱爲FB消息。

反饋（FB）閾值：
FB閾值表示在當即反饋模式和早期RTCP模式之間的切換點。對於多方會話場景，FB閾值表
示平均每一個接收器可以當即將每一個事件報告給發送方的最大組大小，即經過早期RTCP分組
而沒必要等待其安排的按期RTCP時間間隔。該閾值高度依賴於提供的反饋的類型，網絡QoS
（例如，分組丟失機率和分佈），使用的編解碼器和分組方案，會話帶寬和應用需求。請注
意，算法不依賴於全部發送方和接收方贊成相同的閾值。它僅用於嚮應用程序設計者提供概
念性指導，不用於任何計算。爲清楚起見，術語反饋閾值在本文檔中稱爲FB閾值。

 

 

Ott, et al. Standards Track [Page 4]

RFC 4585 RTP/AVPF July 2006

即時反饋模式：
一種操做模式，其中媒體流的每一個接收器在統計上可以當即將每一個感興趣的事件報告回媒體
流發送器。在即時反饋模式下，RTCP FB消息根據本文檔中定義的時序規則進行傳輸。

媒體分組：
媒體分組是RTP分組。

常規RTCP模式：
不容許優先傳輸FB消息的操做模式。相反地，RTCP消息是按照參考文檔[1]的規則發送的，
雖然此類RTCP消息可能包含本文檔中定義的反饋信息。

常規RTCP分組：
不做爲早期RTCP分組發送的RTCP分組。

RTP發送方：
RTP發送方是RTP實體，其發送媒體分組以及RTCP分組，並接收常規分組以及早期RTCP（即，
反饋）分組。注意，RTP發送方是邏輯角色，而且同一RTP實體能夠同時充當RTP接收方。

RTP接收方：
RTP接收方是RTP實體，其接收媒體分組以及RTCP分組，併發送常規分組以及早期RTCP（即，
反饋）分組。注意，RTP接收方是邏輯角色，而且相同的RTP實體能夠同時充當RTP發送方。

1.2. 術語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].

 

 

 

 

 

 

Ott, et al. Standards Track [Page 5]

RFC 4585 RTP/AVPF July 2006

2. RTP和RTCP分組格式和協議行爲

2.1. RTP

參考文獻[2]中定義的規則也適用於此配置文件，但如下提到的規則除外：

RTCP分組類型：
本備忘錄的第6節中註冊了兩個附加的RTCP分組類型，並定義了傳輸反饋信息的相應FB消息。

RTCP報告間隔：
本文檔描述了影響RTCP報告間隔的三種操做模式（參見本備忘錄的第3.2節）。 在常規RTCP
模式中，除了來自同一RTP實體的兩個RTCP報告之間的建議最小間隔5秒以外，參考文獻[1]
中的全部規則都適用。在當即反饋和早期RTCP模式中，兩個RTCP報告之間的最小間隔爲5秒
的規則被去除，此外，若是傳輸的RTCP分組包含FB消息（如本備忘錄的第4節中所定義），
本備忘錄第3節中指定的規則也適用。

參考文獻[1]中提出的規則能夠被指定不一樣參數（例如，分別分配發送者和接收者的RTCP的
帶寬份額）的會話描述覆蓋。對於使用會話描述協議（SDP）[3]定義的會話，適用參考文獻
[4]的規則。

擁塞控制：
在參考文獻[2]中詳述的相同的基本規則也適用。除此以外，在第7節中，進一步考慮了反饋
的影響以及發送方對FB消息的反應。

2.2. 基礎傳輸協議

RTP旨在用於不可靠的傳輸協議，包括UDP協議和數據報擁塞控制協議（DCCP）。本節簡要介紹
本備忘錄中規定的RTCP反饋引入的普通RTP操做以外的細節。

UDP: UDP爲點對點和多播通訊提供盡力傳輸數據報。UDP不支持擁塞控制或錯誤修復。本備忘
錄中定義的基於RTCP的反饋可以爲有限的錯誤修復提供最小的支持。因爲RTCP反饋不能保
證在足夠小的時間尺度上運行（按RTT的順序），所以RTCP反饋不適合支持擁塞控制。此備
忘錄同時處理單播和多播操做。

 

Ott, et al. Standards Track [Page 6]

RFC 4585 RTP/AVPF July 2006

DCCP: DCCP [19]爲單播通訊提供了擁塞控制但不可靠的數據報流。使用基於TCP友好速率控
制（TFRC）的[20]擁塞控制（CCID 3），DCCP特別適用於音視頻通訊。DCCP的確認消息
能夠提供關於接收和丟失的數據報（以及所以關於擁塞）的詳細反饋報告。

當在DCCP上運行RTP時，在DCCP層執行擁塞控制，不須要RTP層提供額外的機制。此外，
具備RTCP反饋能力的發送方能夠利用更頻繁的基於DCCP的反饋，所以接收方能夠在適當的
狀況下避免使用（附加的）通用反饋消息。

3. RTCP反饋規則

3.1. 複合RTCP反饋分組

如本文檔所述，兩個組件構成基於RTCP的反饋：

o 狀態報告包含在發送方報告（SR）和接收報告（RR）數據包中，並做爲複合RTCP數據包
（也包括源描述（SDES）和可能的其餘消息）的一部分按期發送; 這些狀態報告提供了媒體
流最近接收質量的整體狀況。

o 本文檔中定義的FB消息表示媒體流特定分片的丟失或接收（或者對所接收的數據提供其餘形
式的至關即時的反饋）。本文檔中新引入了FB消息傳輸規則。

RTCP FB消息只是某種RTCP分組類型（參見第4節）。所以，能夠將多個FB消息組合在單個複合
RTCP分組中，而且它們也能夠與其餘RTCP分組複合一塊兒發送。

包含本文檔中定義的FB消息的複合RTCP數據包必須按照[1]中定義的順序包含RTCP數據包：

o 若是要根據[1]的第9.1節加密RTCP分組，必須存在可選的加密前綴。
o 必須包含SR或者RR.

 

Ott, et al. Standards Track [Page 7]

RFC 4585 RTP/AVPF July 2006

o 必須包含SDES, 必須包含CNAME項目; 全部其餘SDES項目都是可選的。
o 一條或多條FB消息。

在複合分組中FB消息必須放在參考文獻[1]中定義的RR和SDES RTCP分組以後。關於其餘相關
的RTCP擴展的順序未定義。

本文檔中使用了兩種攜帶反饋分組的複合RTCP分組：

a) 最小複合RTCP反饋分組

一個最小複合RTCP反饋分組必須僅包含上面列出的強制信息：必要時加密前綴，剛好一個
RR或SR，剛好只有一個存在CNAME項的SDES，以及一個或者多個FB消息。這是爲了最小化
傳輸的傳送反饋的RTCP分組的大小，從而最大化能夠提供反饋的頻率，同時仍然遵照RTCP
帶寬限制。

當RTCP FB消息做爲早期RTCP分組的一部分發送時，應該使用這種分組格式。此分組類型在
本文檔中稱爲最小複合RTCP分組。

b) （完整）複合RTCP反饋分組

（完整）複合RTCP反饋分組能夠包含任何額外數量的RTCP分組（額外的RR，還有SDES項
等）。必須遵照上述訂購規則。

只要RTCP FB消息是做爲常規RTCP分組的一部分發送，或者是在常規RTCP模式中發送，就
必須使用此分組格式。它還可用於在當即反饋或早期RTCP模式下發送RTCP FB消息。此分
組類型在本文檔中稱爲完整複合RTCP分組。

不包含FB消息的RTCP分組被稱爲非FB RTCP分組。這些分組必須遵循參考文獻[1]中的格式規
則。

3.2. 算法概述

FB消息是RTCP控制流的一部分，所以受RTCP帶寬限制。這尤爲意味着可能沒法將在接收者處觀
察到的事件當即報告給發送者。然而，給予發送者的反饋的價值一般隨着時間的推移而下降，就
用戶在接收端感知的媒體質量和/或實現媒體流修復所需的成本而言。

 

 

Ott, et al. Standards Track [Page 8]

RFC 4585 RTP/AVPF July 2006

 

RTP [1]和經常使用的RTP配置文件[2]指定發送複合RTCP分組的規則。該文檔修改了這些規則，
以便容許應用程序及時報告事件（例如，丟失或接收RTP數據包），並適應使用FB消息的算法。

修改後的RTCP傳輸算法概述以下：只要不傳送FB消息，複合RTCP數據包就按照RTP [1]的規則
發送，除了不強制要求RTCP報告之間的最小間隔爲5秒。所以，RTCP報告之間的間隔僅來自RTP
/RTCP實體可用的平均RTCP分組大小和RTCP帶寬分配。可選地，能夠強行規定常規RTCP分組之
間的最小時間間隔。

若是接收器檢測到須要發送FB消息，則它能夠比下一常規RTCP報告間隔（遵循上述常規RTCP算
法排期）更早地進行。反饋抑制用於避免多方會話中的反饋內爆：接收器等待（短）隨機抖動間
隔，以檢查它是否從任何其餘接收器看到報告相同事件的相應FB消息。請注意，對於點對點會話，
沒有這樣的延遲。若是接收到來自另外一成員的相應FB消息，則該接收器避免發送FB消息並繼續遵
循常規RTCP傳輸調度。若是接收方還沒有看到來自任何其餘成員的相應FB消息，則它檢查是否容許
發送早期反饋。若是容許發送早期反饋，則接收器將FB消息做爲最小複合RTCP分組的一部分發送。
發送早期反饋的權限取決於此接收器先前發送的RTCP分組的類型，以及發送上一個早期反饋消息
的時間。

FB消息也能夠做爲完整複合RTCP分組的一部分發送，其按照參考文檔[1]（除了5秒下限規則）
以規定間隔發送。

3.3. 運做模式

基於RTCP的反饋能夠以三種模式之一（圖1）操做，以下所述。操做模式僅表示接收方在通常情
況下是否可以及時向發送方報告全部事件; 該模式不影響用於調度FB消息傳輸的算法。

 

Ott, et al. Standards Track [Page 9]

RFC 4585 RTP/AVPF July 2006

而且，取決於接收質量和RTP會話的本地監視狀態，各個接收器可能不會（也沒必要）就當前操做
模式達成一致。

a) 當即反饋模式：在此模式下，組大小低於FB閾值，這爲每一個接收方提供足夠的帶寬，以便爲
預期目的傳輸RTCP反饋分組。這意味着，對於每一個接收方，有足夠的帶寬經過虛擬的「即時」
RTCP反饋分組報告每一個事件。

組大小閾值是許多參數的函數，包括（但不限於）：所使用的反饋類型（例如，ACK與NACK），
帶寬，分組速率，分組丟失機率和分佈，媒體類型，編解碼類型，和（最壞狀況下或觀察到
的）報告事件的發生頻率（例如，接收幀，分組丟失）。

做爲粗略估計，令N是接收器每一個間隔T報告的平均事件數，B是該特定接收器的RTCP帶寬分
數，R是平均RTCP分組大小，那麼只要N<=B*T/R，接收器以當即反饋模式操做。

b) 早期RTCP模式：在此模式下，組大小和其餘參數再也不容許每一個接收器對每一個值得報告（或需
要報告）的事件作出反應。可是仍然能夠充分地給出反饋，以便它容許發送者相應地調整媒
體流傳輸，從而提升總體媒體播放質量。

使用上述表示法，早期RTCP模式可粗略地表徵爲以 N > B*T/R 爲「下限」。 對上限的估
計更加困難。 使N = 1，便可獲得對於給定的R和B，間隔 T = R/B 做爲要報告的事件之
間的平均間隔。該信息可用於提示以肯定是否採用RTCP分組的早期傳輸。

c) 常規RTCP模式：當組的大小超出某個值時，根據接收器的個別事件提供反饋再也不有用。由於
能夠提供反饋的時間有限，還有在大組中發送者沒有機會對個體反饋作出反應。

此模式不能指定精確的組大小閾值，但顯然，此邊界與上面b）項中指定的早期RTCP模式的
上限匹配。

 

Ott, et al. Standards Track [Page 10]

RFC 4585 RTP/AVPF July 2006

因爲本文檔中描述的反饋算法能夠平滑地擴展，所以不須要參與者之間就組內各個FB閾值的精
確值達成一致。 所以，全部這些模式之間的邊界是軟的。

     ACK
   feedback
     V
     :<- - - - NACK feedback - - - ->//
     :
     :   Immediate   ||
     : Feedback mode ||Early RTCP mode Regular RTCP mode
     :<=============>||<=============>//<=================>
     :               ||
    -+---------------||---------------//------------------> group size
     2               ||
      Application-specific FB Threshold
        = f(data rate, packet loss, codec, ...)

                          圖1：操做模式

如前所述，相應的FB閾值取決於許多技術參數（編解碼器，傳輸，所使用的反饋的類型等），但
也取決於相應的應用場景。第3.6節提供了估算這些閾值的一些有用的提示（但沒有精確的計算）。

3.4. 定義和算法概述

每一個接收器須要維護如下狀態信息（主要取自[1]）。請注意，全部變量（下面的項目h除外）都
是在每一個接收器上獨立計算的。所以，它們的本地值可能在任何給定的時間點都不一樣。

a) 令「發送方」爲RTP會話中活動的發送器的數量。

b) 令「成員」爲當前RTP會話中接收者數量的估計。

c) 令tn和tp爲下一個（最後一個）調度的RTCP RR傳輸的時間，該傳輸時間在計時器從新考慮
以前計算。

d) 令Tmin爲RTCP包之間的最小間隔[1]。與[1]不一樣，初始Tmin設置爲1秒，以容許在發送第
一個RTCP數據包以前進行某些組大小採樣。發送第一個RTCP數據包後，Tmin設置爲0。

 

 

Ott, et al. Standards Track [Page 11]

RFC 4585 RTP/AVPF July 2006

e) 令T_rr爲在剛發送了按期調度的RTCP分組以後，接收器將調度其下一個常規RTCP分組的傳
輸的時間間隔。該值是按照[1]的規則得到的，可是使用本文件中定義的Tmin：T_rr = T
（[1]中定義的「計算間隔」），tn = tp + T。T_rr老是指已計算的T的最後一個值（由
於從新考慮或肯定tn）。T_rr在本文檔中也稱爲常規RTCP間隔。

f) 令 t0 爲接收器檢測到要報告的事件的時間。

g) 令T_dither_max是能夠額外延遲RTCP反饋包以防止多方會話發生內爆的最大間隔;
T_dither_max的值是基於T_rr動態計算的（或者能夠經過未來要指定的全部RTP接收器共
用的另外一種機制來導出）。對於點對點會話（即，具備剛好兩個成員而沒有預期的組大小改
變的會話，如，單播流會話），T_dither_max被設置爲0。

h) 令T_max_fb_delay是一個上限，須要在該時間上限內將對事件的反饋報告給發送方以使其
有價值。此值是特定於應用程序的，而且在本文檔中未做任何定義。

i) 令te是排期發送反饋分組的時間。

j) 令T_fd是響應時間t0發生的事件而發送FB消息的實際（隨機）延遲。

k) 令allow_early爲布爾變量，指示接收器當前是否能夠在其下一個按期調度的RTCP間隔tn
以前發送FB消息。此變量用於限制單個接收器發送的反饋。在早期反饋傳輸以後，
allow_early設置爲FALSE，並在下一次常規RTCP傳輸發生後當即設置爲TRUE。

l) 令avg_rtcp_size爲[1]中定義的RTCP數據包大小的移動平均值。

m) 令T_rr_interval爲常規RTCP數據包之間使用的可選最小間隔。
若是T_rr_interval == 0，則該變量對RTCP反饋算法的總體操做沒有任何影響。
若是T_rr_interval != 0，則在最後一次常規RTCP傳輸的T_rr時間以後
（即，在tp + T_rr），將不調度下一個常規RTCP分組。相反，下一個常規RTCP分組將
被延遲，直到最後一次常規RTCP傳輸以後至少T_rr_interval，即，它將被安排在
tp + T_rr_interval或以後。注意，T_rr_interval不影響T_rr和tp的計算; 相反，
若是例如它們不包含任何FB消息，則將抑制在tp + T_rr_interval以前調度傳輸的常規
RTCP分組。 T_rr_interval不影響早期RTCP分組的傳輸調度。

 

Ott, et al. Standards Track [Page 12]

RFC 4585 RTP/AVPF July 2006

注意：將T_rr_interval做爲獨立變量提供意味着根據應用程序的須要最小化常規RTCP反
饋（以及帶寬消耗），同時另外容許使用更頻繁的早期RTCP分組來提供及時反饋。因爲RTCP
帶寬減小也會影響早期反饋的頻率，所以沒法經過下降總體RTCP帶寬來實現此目標。

n) 令t_rr_last爲最後一個常規RTCP包被調度和發送的時間點，即未因爲T_rr_interval
而被抑制。

o) 設T_retention是AVPF實體存儲過去FB消息的時間窗口。這是爲了確保反饋抑制也適用於
在注意到反饋事件自己以前已從其餘實體接收到FB消息的實體。T_retention必須設置爲
至少2秒。

p) 令M * Td爲接收器被視爲無效的超時值（如[1]中所定義）。

在接收器處報告事件的反饋狀況以下圖2所示。在時間t0，在接收器處檢測到這樣的事件（例如，
分組丟失）。接收器根據當前帶寬，組大小和其餘特定於應用程序的參數決定須要發送FB消息
回發送方。

爲了不多方會話中反饋分組的內爆，接收方必須將RTCP反饋分組的傳輸延遲隨機時間量T_fd
（隨機數均勻分佈在區間[0，T_dither_max]中）。而後必須在te = t0 + T_fd調度複合
RTCP分組的傳輸。

T_dither_max參數是從常規RTCP間隔T_rr導出的，而T_rr又基於組大小。若是能夠確保所
有RTP接收器將使用相同的機制來計算T_dither_max，則將來文檔可能指定T_dither_max
的其餘計算方式（例如，基於RTT）。

 

Ott, et al. Standards Track [Page 13]

RFC 4585 RTP/AVPF July 2006

對於某種應用場景，接收器能夠肯定FB消息的可接受的本地延遲的上限：T_max_fb_delay。
若是先驗估計或T_dither_max的實際計算指示能夠違反該上限（例如，由於
T_dither_max> T_max_fb_delay），則接收器能夠決定不發送任何反饋，由於可實現的增
益被認爲是不足的。

若是調度了早期RTCP分組，則必須相應地更新下一個常規RTCP分組的時隙，以便以後具備新的
tn（tn = tp + 2 * T_rr）和新的tp（tp = tp + T_rr）。這是爲了確保早期反饋使用
的短時間平均RTCP帶寬不超過沒有早期反饋的帶寬。

             event to
             report
             detected
                |
                | RTCP feedback range
                |  (T_max_fb_delay)
                vXXXXXXXXXXXXXXXXXXXXXXXXXXX     ) )
   |---+--------+-------------+-----+------------| |--------+--->
       |        |             |     |            ( (        |
       |       t0            te                             |
       tp                                                   tn
                 \_______  ________/
                         \/
                    T_dither_max

                    圖2：早期RTCP調度的事件報告和參數

3.5. AVPF RTCP調度算法

設S0爲某一活動發送方（S個發送方中的一個），而且設N爲接收方的數量，其中R爲這些接收方
之一。

假設R已經證明在當前環境中使用反饋機制是合理的（這是高度特定於應用的，所以在本文檔中
沒有指定）。

進一步假設T_rr_interval爲0，若是沒有設置執行常規RTCP分組之間的最小間隔，或者
T_rr_interval設置爲某個有意義的值，如應用程序所給出的。那麼，該值表示常規RTCP分組
之間的最小間隔。

由此，接收機R必須使用如下規則來傳輸一個或多個FB消息，以最小或徹底符合RTCP分組的形式。

 

Ott, et al. Standards Track [Page 14]

RFC 4585 RTP/AVPF July 2006

3.5.1. 初始化

最初，R必須設置allow_early = TRUE和t_rr_last = NaN（非數字的意思，便可以與有效
時間值區分的某個無效值）。

此外，除了Tmin的初始值以外，按照[1]初始化RTCP變量。對於點對點會話，初始Tmin設置爲0。
對於多方會話，Tmin初始化爲1.0秒。

3.5.2. 早期反饋傳輸

假設R已經調度了最後的常規RTCP RR分組以便在tp發送（而且在tp發送或抑制該分組），而且
已經安排下一次發送時間 tn= tp+T_rr（包括根據[1]的可能從新考慮）。還假設最後的常規
RTCP分組傳輸發生在t_rr_last。

而後，早期反饋算法包括如下步驟：

1. 在時間t0，R檢測到須要發送一個或多個FB消息，例如，由於媒體「單元」須要被ACK或NACK，
而且發現提供反饋信息對於發送者多是有用的。

2. R首先檢查是否已經存在包含一個或多個調度用於傳輸的FB消息的複合RTCP分組（做爲早期
或常規RTCP分組）。

2a) 若是是這樣，新的FB消息必須包含在調度的分組中; 等待複合RTCP分組的調度必須保
持不變。這樣作時，應該合併可用的反饋信息以產生儘量少的FB消息。這樣就達成了
當即採起的行動。

2b) 若是沒有調度複合RTCP分組進行傳輸，則必須建立一個新的（最小或完整）複合RTCP
分組，而且必須按以下方式選擇T_dither_max的最小間隔：

i) 若是會話是點對點會話，那麼

T_dither_max = 0.

 

 

Ott, et al. Standards Track [Page 15]

RFC 4585 RTP/AVPF July 2006

ii) 若是會話是多方會話，那麼

T_dither_max = l * T_rr

其中 l=0.5.

T_dither_max的值能夠不一樣地計算（例如，基於RTT），而後必須在將來的文檔中指
定。這樣的將來規範必須確保全部RTP接收器使用相同的機制來計算T_dither_max。

上面給出的T_dither_max值是最小值。特定於應用程序的反饋計算可能使得
T_dither_max增長到超過此值。這取決於實施者的決定。

3. 而後，R必須對在t0觸發的早期RTCP分組，檢查其下一個常規RTCP分組是否將在時間範圍內
發出，即，是否 t0 + T_dither_max > tn。

3a) 若是是這樣，則不得安排早期RTCP數據分組; 相反，必須將FB消息存儲在於tn調度的
常規RTCP分組中。 這樣就完成了當即執行的行爲。

3b) 不然，執行如下步驟。

4. R務必檢查是否容許發送早期RTCP數據分組，即allow_early == TRUE。

4a) 若是allow_early == FALSE，則R必須檢查調度下一個常規RTCP分組的時間：

1. 若是tn -t0 <T_max_fb_delay，那麼儘管報告遲到，反饋對於發送者仍然有
用。所以，R能夠建立一個RTCP FB消息，將其包含在常規RTCP數據包中，以便
在tn進行傳輸。

2. 不然，R必須丟棄RTCP FB消息。

這樣就完成了即將採起的行動。

4b) 若是allow_early == TRUE，則R必須爲te = t0 + RND * T_dither_max調度
早期RTCP分組，其中RND是均勻分佈在0和1之間的僞隨機函數。

 

 

Ott, et al. Standards Track [Page 16]

RFC 4585 RTP/AVPF July 2006

5. R必須檢測從RTP會話的其餘成員發來的FB消息與R想要發送的FB消息之間的重疊。所以，做
爲RTP會話的成員，R必須持續監視（最小）複合RTCP分組的到達，並將這些RTCP分組中包
含的每一個FB消息存儲至少T_retention時間。當按照上面的步驟1到4調度其自身的FB消息
的傳輸時，R必須檢查在 [t0 - T_retention; te] 間隔期間接收到的每一個RTCP分組中
存儲的和新接收的FB消息，並採起如下行動：

5a) 若是R理解收到的FB消息的語義，而且消息內容是R想要發送的反饋的超集，則R必須丟
棄其本身的FB消息，而且必須將在時間tn（如以前計算的）傳輸的下一個常規RTCP分
組從新排期。

5b) 若是R理解收到的FB消息的語義，而且消息內容不是R想要發送的反饋的超集，那麼R應
該按計劃發送它本身的FB消息。若是要發送的反饋信息與收到的反饋信息之間存在重疊，
則發送反饋的數量取決於R：R能夠保持不變發送其反饋信息，R也能夠消除其自身的反
饋與到目前爲止收到的其餘會員的反饋之間的任何冗餘。

5c) 若是R不理解收到的FB消息的語義，則R能夠將其本身的FB消息調度爲早期RTCP分組，
或者R能夠從新調度tn的下一個常規RTCP分組傳輸（如前文所計算），而且能夠將FB
消息附加到如今按期調度的RTCP消息。

注意：對於5c），接收未知的FB消息可能不會致使特定接收器的反饋抑制。做爲結果，
給定事件可能致使M個不一樣類型的FB消息（它們都是適當的可是相互之間不能理解）被
調度，使得」大型」接收器組能夠事實上被劃分爲最多M個組。在這些M組中的每一組的
成員中，根據5a和5b反饋抑制將會發生，可是不會在組之間發生抑制。結果，發送者
能夠接收O(M)個RTCP FB消息。所以，反饋內爆的可能性很是有限。可是，因爲組成
同一應用程序的發送方和全部接收方在同一個RTP會話中使用相同的（一組）編解碼器，
所以能夠安全地假設FB消息的語義差別很小，所以假設M在通常狀況下很小。

 

Ott, et al. Standards Track [Page 17]

RFC 4585 RTP/AVPF July 2006

進一步假設O(M) FB消息在T_dither_max的時間間隔內隨機分佈，咱們發現產生的
有限數量的額外複合RTCP分組 (a) 被認爲不會使發送者不堪重負，而且 (b) 應該
被做爲全包含補充信息傳輸。

6. 如參考文獻[5]，若是R的FB消息沒有被其餘接收器FB消息抑制，則當到時間te時，R必須
發送包含其FB消息的（最小）複合分組。而後R必須設置allow_early = FALSE，必須
從新計算tn = tp + 2*T_rr，而且必須將tp設置爲前一個tn。一旦到新計算的時間tn，
不管R是否因爲T_rr_interval而發送其下一個常規RTCP分組或抑制它，它必須再次設置
allow_early = TRUE。

3.5.3. 按期RTCP傳輸

必須按期發送完整的複合RTCP分組。這些分組可能包含一個或多個FB消息。常規RTCP分組的
傳輸安排以下：

若是T_rr_interval == 0，則傳輸必須遵循本文檔第3.2和3.4節中規定的規則，而且必須遵
守第3.5.2節中規定的tn的調整（即，若是已經傳輸過早期RTCP分組，則跳過一次常規分組的傳
輸）。根據參考文檔[1]，時間到tn時進行定時器從新計算。定時器從新計算以後發送常規RTCP
分組。每當發送或抑制常規RTCP分組時，allow_early必須設置爲TRUE，而且必須根據參考文
檔[1]更新tp和tn。在第一次傳輸常規RTCP分組以後，Tmin必須設置爲0。

若是T_rr_interval != 0，那麼傳輸時間的計算必須遵循本文第3.2和3.4節中規定的規則，
而且必須遵照第3.5.2節中規定的對tn的調整（即若是已經傳輸過早期的RTCP分組，則跳過一個
常規分組傳輸）。根據參考文檔[1]，時間到tn時進行定時器從新計算。從新計算計時器後，將
採起如下措施：

1. 若是以前沒有發送常規RTCP分組（即，若是t_rr_last == NaN），則必須調度常規RTCP
分組。存儲的FB消息能夠包含在常規RTCP分組中。在發送按期的分組以後，必須將
t_rr_last設置爲tn。Tmin必須設置爲0。

 

 

Ott, et al. Standards Track [Page 18]

RFC 4585 RTP/AVPF July 2006

2. 不然，臨時值T_rr_current_interval計算以下：

T_rr_current_interval = RND*T_rr_interval

RND是一個均勻分佈在0.5和1.5之間的僞隨機函數。此抖動值用於肯定如下備選方案之一：

2a) 若是t_rr_last + T_rr_current_interval <= tn，則必須調度常規RTCP分
組。存儲的RTCP FB消息能夠包含在常規RTCP分組中。在發送預約的分組以後，必須
將t_rr_last設置爲tn。

2b) 若是t_rr_last + T_rr_current_interval> tn，並已經存儲RTCP FB消息正在
等待傳輸，則必須安排在tn傳輸RTCP分組。該RTCP分組能夠是最小或常規RTCP分組
（由實現者決定），而且複合RTCP分組必須包括存儲的RTCP FB消息。 t_rr_last
必須保持不變。

2c) 不然（若是t_rr_last + T_rr_current_interval> tn但沒有正在等待傳輸的存
儲的RTCP FB消息），則必須抑制複合RTCP分組（即不能調度它）。t_rr_last必須
保持不變。

在上述四種狀況（1，2a，2b和2c）中，allow_early必須設置爲TRUE（可能在發送常規RTCP
分組以後），而且必須按照[1]的規則更新tp和tn，除了最小5秒規則。

3.5.4. 其餘考慮因素

若是T_rr_interval != 0，則必須修改RTP/AVPF實體的超時計算（文檔[1]的第6.3.5節），
以使用T_rr_interval而不是Tmin來計算Td，從而使用M*Td來計時輸出RTP實體。

每當發送或接收復合RTCP分組 - 最小或徹底複合，早期或常規 - 必須相應地更新
avg_rtcp_size變量（參見[1]），而且tn的後續計算必須使用新的avg_rtcp_size。

 

 

 

Ott, et al. Standards Track [Page 19]

RFC 4585 RTP/AVPF July 2006

3.6. 會話組大小考慮因素

本節提供了可使用各類反饋模式的組大小的一些指導。

3.6.1. ACK 模式

RTP會話必須只有兩個成員，且這個組大小不得增加，即它必須是點對點通訊。應該在會話描述
中使用單播地址。

對於雙方之間的單向和雙向通訊，2.5％的RTP會話帶寬可用於來自接收器的RTCP流量，包括反
饋。對於64 kbit/s的流，RTCP佔用1,600 bit/s。若是咱們假設平均每一個RTCP分組有96個
字節（= 768 bits），則接收方能夠每秒向發送方報告2次事件。若是在每一個FB消息中收集了
10次事件的確認，則每秒能夠確認20次事件。在256 kbit/s時，每秒可報告8次事件; 所以，
能夠以更精細的粒度發送ACK（例如，每一個FB消息僅符合三個ACK）。

從1 Mbit/s以上，接收器將可以在30 fps視頻流中確認每一個幀（而不是每一個分組！）。

必須定義ACK策略以正常使用這些帶寬限制。是否容許在會話中使用ACK，若是是，應該使用哪
種ACK策略，能夠經過帶外機制來傳達，例如，使用SDP的會話描述中的媒體特定屬性。

3.6.2. NACK 模式

否認確認（以及表現出相似報告特徵的其餘類型的反饋）必須用於組大小可能大於2的全部會話。
固然，NACK也能夠用於點對點通訊。

是否應該考慮使用早期RTCP分組取決於許多參數，包括會話帶寬，編解碼器，特殊類型的反饋，
以及發送器和接收器的數量。

肯定操做模式時最重要的參數，是兩個複合RTCP分組之間容許的最小間隔（T_rr），和每一個時
間間隔可能須要報告的平均事件數（固然還有它們隨時間的分佈）。最小間隔能夠從可用的RTCP
帶寬和RTCP分組的預期平均大小導出。要報告的事件的數量（例如，每秒）能夠從分組丟失率
和發送者的分組傳輸速率導出。根據這兩個值，能夠計算當即反饋模式容許的組大小。

 

Ott, et al. Standards Track [Page 20]

RFC 4585 RTP/AVPF July 2006

 

如第3.3節所述：

設N是接收器每一個間隔T報告的平均事件數，B是該特定接收器的RTCP帶寬分數，R是平均
RTCP分組大小，而後只要N <= B*T/R，接收器就以當即反饋模式工做。

那麼，早期RTCP模式的上限僅取決於可接受的質量降級，即，每一個時間間隔容許的未報告事件
數量。

如第3.3節所述：

使用上述表示法，早期RTCP模式可粗略地表徵爲以 N > B*T/R 爲「下限」。對上限的估計
更加困難。設置N = 1，咱們爲給定的R和B得到間隔 T = R/B 爲要報告的事件之間的平
均時間間隔。該信息可用做肯定RTCP分組的早期傳輸是否有用的提示。

示例：若是經過MTU大小約爲1,500字節的網絡傳輸30 fps的256 kbit/s視頻，則在大多數
狀況下，每一個幀適配一個分組，從而致使分組速率達到30個分組每秒。若是在網絡中發生5％的
分組丟失（均勻分佈，接收器之間沒有相互依賴性），那麼每一個接收器平均必須每2秒報告丟失
3個分組。假設一個發送器和三個以上的接收器，這致使3.75％的RTCP帶寬分配給接收器，也
就是9.6kbit/s。假設平均複合RTCP分組的大小爲120字節，則容許每秒發送10個RTCP分組
或在兩秒內發送20個RTCP分組。若是每一個接收器須要每2秒報告3個丟失的分組，則推導出若是
要報告全部丟失事件，最大組大小爲6-7個接收器。傳輸早期RTCP分組的規則應該提供足夠的
靈活性，以便及時發生大多數報告。

擴展此示例以肯定早期RTCP模式的上限可能會致使如下考量：假設底層編碼方案和應用程序
（以及容錯用戶）每兩秒容許丟失一次分組而不修復。所以，每一個接收器報告的分組數量減小到
每2秒2個，而且組大小增長到10。假設進一步某些數量的分組丟失是相互相關的，則反饋流量進
一步減小，使用早期RTCP模式能夠至關好地支持的組大小能夠增進到12至16 （甚至20）。請
注意，全部這些考慮都基於統計數據，而且在某些狀況下將不成立。

 

Ott, et al. Standards Track [Page 21]

RFC 4585 RTP/AVPF July 2006

3.7. 決策步驟總結

3.7.1. 通常提示

在考慮是否發送RTCP反饋信息以前，應用程序必須肯定此機制是否適用：

1) 應用程序必須決定是否能夠應用反饋機制，基於當前分組速率與相關（特定於應用程序的）
最大反饋延遲的比率，以及當前觀察到的網絡往返時間（若是可用） 。

該決定能夠基於（而且隨後動態地修改）RTCP接收統計以及帶外機制。

2) 應用程序必須決定是否能夠應用（和哪些）反饋機制，基於觀察到的錯誤率，分配的帶寬，
幀/分組速率，和組大小 。

常規RTCP接收統計信息也爲此步驟提供了有價值的輸入。

3) 若是應用程序決定發送反饋，則應用程序必須遵循發送早期RTCP分組或包含FB消息的常規
RTCP分組的規則。

4) 發送的RTCP反饋類型不該與發送方從下層傳輸協議可得到的信息重複。也就是說，若是傳
輸協議可以提供關於分組是否接收的確認（例如DCCP），則接收器應避免在RTCP層重複相
同的信息（即，避免發送通用NACK）。

3.7.2. 媒體會話屬性

一般使用帶外機制來描述媒體會話，以在發送者和接收者之間傳送傳輸地址，編解碼器等信息。
這種機制包含兩層：一個格式用於描述媒體會話，另外一個機制用於傳輸該描述。

 

Ott, et al. Standards Track [Page 22]

RFC 4585 RTP/AVPF July 2006

在IETF中，會話描述協議（SDP）當前用於描述媒體會話，而諸如SIP，會話通告協議（SAP），
實時流協議（RTSP）和HTTP（以及其餘）之類的協議用於傳送描述。

媒體會話描述格式能夠包括用於指示在該會話中支持RTCP反饋機制以及能夠應用哪些反饋機制
的參數。

爲此，必須指示配置文件「AVPF」而不是「AVP」。能夠定義其餘屬性以表示支持哪一種類型的反饋。

第4節包含SDP協議支持RTCP反饋的語法規範。其餘媒體會話描述格式的相似規範超出了本文
檔的範圍。

4. SDP 定義

本節定義了許多用於描述會話的附加SDP參數。全部這些都被定義爲媒體級屬性。

4.1. 配置文件標識

在[4]中定義的AV配置文件在會話描述協議（SDP）[3]的環境中稱爲「AVP」。本文檔中指定的
配置文件稱爲「AVPF」。

除非此會話的描述代表使用「AVPF」配置文件（獨佔或與其餘AV配置文件一塊兒使用），不然不得
爲特定媒體會話發送遵循本文檔中指定的修改時序規則的反饋信息。

4.2. RTCP 反饋能力屬性

定義一個新的特定有效載荷格式SDP屬性以表示使用本文檔指定的RTCP反饋能力:
「a = rtcp-fb」。「rtcp-fb」屬性必須僅用做SDP媒體屬性，不得在會話級別提供。
「rtcp-fb」屬性必須僅用於指定了「AVPF」的媒體會話。

「rtcp-fb」屬性應該用於指示哪一個RTCP FB消息能夠在該媒體會話中用於指定的有效載荷類型。
有效負載類型通配符（「*」）可用於指示RTCP反饋屬性適用於全部有效負載類型。若是支持多種
類型的反饋，和/或應爲有效載荷類型的子集指定相同的反饋，則必須使用多個「a = rtcp-fb」
行。

 

Ott, et al. Standards Track [Page 23]

RFC 4585 RTP/AVPF July 2006

若是沒有指定「rtcp-fb」屬性，則RTP接收器可使用爲相應媒體類型定義的其餘合適的RTCP
反饋分組來發送反饋。RTP接收器毫不能依賴RTP發送器對任何FB消息做出反應。RTP發送方可
能選擇忽略某些反饋消息。

若是媒體會話描述中存在一個或多個「rtcp-fb」屬性，則包含「rtcp-fb」的媒體會話的RTCP
接收器

o 必須忽略他們不能徹底理解語義的全部「rtcp-fb」屬性（即，他們不理解「a=rtcp-fb」
行中全部值的含義）;

o 應該使用本媒體會話的「rtcp-fb」屬性之中指定的任何RTCP反饋分組提供本文檔中指定的
反饋信息；和

o 不得使用除「rtcp-fb」屬性行之中列出的FB消息以外的其餘FB消息。

當與offer/answer模型[8]結合使用時，詢問者能夠向其對端提供這樣一組AVPF屬性。應答
者必須刪除它不理解的全部屬性，以及它通常不支持或不但願在此特定媒體會話中使用的屬性。
應答者不得將反饋參數添加到媒體描述中，而且不得改變這些參數的值。應答是對媒體會話的約
束，而且詢問者和應答者必須僅使用以這種方式協商的反饋機制。詢問者和應答者能夠獨立決定
僅發送協商反饋機制子集的RTCP FB消息，可是他們應該對接收到的全部類型的協商FB消息作
出適當的反應。

RTP發送者必須準備接收任何類型的RTCP FB消息，而且必須靜默地丟棄全部他們不理解的RTCP
FB消息。

「rtcp-fb」屬性的語法以下（反饋類型和可選參數都區分大小寫）：

（在下面的ABNF中，fmt，SP和CRLF按照[3]中的定義使用。）

 

 

Ott, et al. Standards Track [Page 24]

RFC 4585 RTP/AVPF July 2006

      rtcp-fb-句法 = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF

      rtcp-fb-pt         = "*" ; 通配符：適用於全部格式
                         / fmt ; 如SDP規範中所定義

      rtcp-fb-val        = "ack" rtcp-fb-ack-param
                         / "nack" rtcp-fb-nack-param
                         / "trr-int" SP 1*DIGIT
                         / rtcp-fb-id rtcp-fb-param

      rtcp-fb-id         = 1*(alpha-numeric / "-" / "_")

      rtcp-fb-param      = SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty

      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty

      rtcp-fb-nack-param = SP "pli"
                         / SP "sli"
                         / SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty

上述語法的文字具備如下語義：

反饋類型 「ack」:

此反饋類型表示支持反饋的確定確認。

只有在容許媒體會話在第3.6.1節中定義的ACK模式下操做時，才能使用反饋類型 「ack」。

必須提供參數以進一步區分不一樣類型的確定確認反饋。

參數 「rpsi」 表示使用6.3.3節中定義的參考圖像選擇指示反饋。

 

 

 

Ott, et al. Standards Track [Page 25]

RFC 4585 RTP/AVPF July 2006

若是指定參數 「app」，則表示使用應用程序層反饋。 在這種狀況下，「app」 以後的附加
參數可用於進一步區分各類類型的應用層反饋。本文檔未定義特定於 「app」 的任何參數。

「ack」 的其餘參數能夠在其餘文件中定義。

反饋類型 "nack":

此反饋類型表示支持反饋的否認確認。

不帶參數的反饋類型 「nack」 表示使用6.2.1節中定義的通常NACK反饋格式。

本文檔中定義瞭如下三個參數，以便 「nack」 與媒體類型 「video」 結合使用：

o 「pli」 表示使用6.3.1節中定義的圖像丟失指示反饋。

o "sli" 表示使用第6.3.2節中定義的切片丟失指示反饋。

o "rpsi" 表示使用6.3.3節中定義的參考圖片選擇指示反饋。

「app」 表示使用應用層反饋。「app」 後面能夠提供附加參數以區分不一樣類型的應用層反
饋。本文檔中未定義特定於 「app」 的參數。

「nack」 的其餘參數能夠在其餘文檔中定義。

其餘反饋類型 <rtcp-fb-id>:

能夠在其餘文件中定義其餘類型的反饋; 爲了保持語法對這些狀況的可擴展性，引入
rtcp-fb-id做爲佔位符。新的反饋方案名稱必須是惟一的（所以必須在IANA註冊）。除了
新名稱外，還必須指定其語義，分組格式（若是須要），以及其操做規則。

 

 

 

Ott, et al. Standards Track [Page 26]

RFC 4585 RTP/AVPF July 2006

按期RTCP最小間隔 "trr-int":

屬性 「trr-int」 用於指定此媒體會話的兩個常規（徹底複合）RTCP分組之間的最小間隔
T_rr_interval（以毫秒爲單位）。若是未指定 「trr-int」，則假定默認值爲0。

請注意，假設有關應用層反饋的更具體信息（如第6.4節中所定義）將做爲反饋類型和參數在其
他地方定義。所以，本文件再也不對任何類型和參數做出規定。

能夠在其餘文檔中定義其餘類型的反饋和參數。

是否發送反饋信息取決於接收者，（如何）使用所提供的反饋取決於發送者。

4.3. RTCP 帶寬修改器

[1]和[2]中定義的標準RTCP帶寬分配能夠被明肯定義最大RTCP帶寬的帶寬修改器覆蓋。爲了與
SDP一塊兒使用，在[4]中指定了這些修飾符："b=RS:<bw>" 和 "b=RR:<bw>" 可用於給發送者
和接收者分配不一樣的RTP帶寬（以每秒位數爲單位） 。[4]的優先規則適用於肯定發送者和接收
者使用的實際帶寬。

故意在高度不對稱鏈路（例如衛星鏈路）上運行的應用程序應該使用這種機制來下降高帶寬流的
反饋速率，以防止反饋路徑的肯定性擁塞。

4.4. 例子

例1: 如下會話描述表示由音頻和DTMF [18]組成的用於點對點通訊的會話，其中DTMF流使用
通用NACK。該會話描述能夠包含在SIP INVITE，200 OK或ACK消息中，以指示其發送方
可以而且願意接收其發送的DTMF流的反饋。

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Ott, et al. Standards Track [Page 27]

RFC 4585 RTP/AVPF July 2006

這容許發送器和接收器在音頻會話中提供DTMF事件的可靠傳輸。 假設一個接收器具備64kbit/s
的音頻流，接收器有2.5％RTCP帶寬可用於否認確認流，即每秒250字節或每秒2個RTCP反饋消
息。所以，接收器每秒能夠個別傳達最多兩個丟失的DTMF音頻分組。

例2: 如下會話描述表示多播視頻會話（使用H.261或H.263 +），視頻源接受編解碼器和
H.263的參考圖像選擇兩種通用NACK。可使用會話通告協議（SAP）來傳達這樣的描述。

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi

發送方可使用傳入的通用NACK做爲提示，以儘快發送新的幀內幀（擁塞控制容許）。接收參
考圖片選擇指示（RPSI）消息容許發送者避免發送大的幀內幀; 相反，它能夠繼續發送幀間幀，
然而，選擇所指示的幀做爲新的編碼參考。

例3: 如下會話描述定義了與示例2相同的媒體會話，但容許AVP RTP實體和AVPF RTP實體的
混合模式運行（另請參見下一節）。請注意，兩個媒體描述都使用相同的地址; 可是，須要
兩個 m= 行來傳達它們倆適用的相關RTP配置文件信息。

 

Ott, et al. Standards Track [Page 28]

RFC 4585 RTP/AVPF July 2006

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi

請注意，這兩個 m= 行應該經過一些適當的機制進行分組，以指示二者都是實際傳達相同內容的
替代方案。能夠實現這一目標的示例框架在[10]中定義。

在此示例中，啓用RTCP反饋的接收器將偶爾得到將事件更早地報告給發送方的優點（這可能使整
個組受益）。可是，平均而言，全部RTP接收器都將提供相同數量的反饋。AVP和AVPF實體之間
的互通將在下一節中深刻討論。

5. AVP和AVPF實體的互通和共存

本文檔中定義的AVPF配置文件是[2]中定義的AVP配置文件的擴展。兩個配置文件遵循相同的基
本規則（包括RTCP的帶寬上限和發送器與接收器的帶寬分配）。所以，使用兩個配置文件中的任
何一個的發送器與接收器能夠在一個會話中混合（參見第4.5節中的示例3）。

AVP和AVPF以這樣的方式定義：從魯棒性的觀點來看，RTP實體不須要知道相應的使用其餘配置
文件的實體：它們不會干擾彼此的功能。可是，所呈現的媒體質量可能會受到影響。

在組合會話中使用時，如下注意事項適用於發送器與接收器。

 

Ott, et al. Standards Track [Page 29]

RFC 4585 RTP/AVPF July 2006

o AVP實體（發送者和接收者）

AVP發送器將從AVPF接收器接收RTCP反饋分組並忽略這些分組。他們將發現AVPF實體偶爾
以更密的時間間隔發送RTCP消息（例如，違反5秒規則）。因爲兩種類型的實體都遵照整體
帶寬限制，所以它們仍然能夠得到RTCP帶寬份額。然而，雖然AVP實體受到5秒規則的約束，
可是取決於組大小和會話帶寬，AVPF實體可能提供比AVP實體更頻繁的RTCP報告。此外，
總體報告可能會略微減小，由於AVPF實體可能會發送更大的複合RTCP分組（因爲額外的
RTCP分組）。

若是T_rr_interval用做常規RTCP分組之間的下限，且T_rr_interval足夠大（例如，
根據[1]的第6.3.5節，T_rr_interval> M*Td），而且AVPF實體不發送早期RTCP分組，
AVP實體可能意外地將那些AVPF小組成員超時，並所以低估小組的規模。所以，若是媒體會
話可能涉及AVP實體，T_rr_interval不該大於5秒。

o AVPF實體（發送者和接收者）

若是動態計算的T_rr足夠小（例如，小於一秒），則AVPF實體可能意外地將AVP組成員超時，
並所以低估組大小。所以，若是媒體會話可能涉及AVP實體，則應該使用T_rr_interval，
而且應該將其設置爲5秒。

總之，若是媒體會話可能涉及AVP實體而且要使用T_rr_interval，則T_rr_interval應
該設置爲五秒。

o AVPF 發送者

AVPF發送器將僅從AVPF接收器接收反饋信息。若是他們依靠反饋來提供目標媒體質量，則
AVP接收器實現的質量可能不是最理想的。

o AVPF 接收者

只有當媒體會話中的全部發送實體都支持AVPF時，AVPF接收器才應該發送早期RTCP反饋分
組。AVPF接收器能夠按照[1]和[2]的時序規則，也能夠在混合模式下運行的媒體會話中，
發送反饋信息做爲按期調度的複合RTCP分組的一部分。可是，提供反饋的接收器毫不能依賴
發送器對反饋作出的反應。

 

 

Ott, et al. Standards Track [Page 30]

RFC 4585 RTP/AVPF July 2006

6. RTCP反饋消息的格式

本節定義了低延遲RTCP反饋消息的格式。 這些消息分爲如下三類：

- 傳輸層FB消息
- 特定有效負載的FB消息
- 應用層FB消息

傳輸層FB消息旨在傳輸通用反饋信息，即獨立於特定編解碼器或使用中的應用的信息。預計信
息將在傳輸層/RTP層生成和處理。目前，僅定義了通用否認確認（NACK）消息。

特定於有效載荷的FB消息傳輸特定於某種有效載荷類型的信息，而且將在編解碼「層」處生成並
做用。本文檔定義了與全部特定於有效負載的FB消息一塊兒使用的公共標頭。特定消息的定義留
給RTP有效載荷格式規範或其餘反饋格式文檔。

應用層FB消息提供了一種方法，能夠透明地將反饋從接收方傳送到發送方的應用程序。這種消
息中包含的信息不是預期在傳輸層/RTP層或者編解碼器層上起做用的。要在兩個應用程序實例
之間交換的數據一般在應用程序協議規範中定義，所以能夠由應用程序識別，所以不須要額外
的外部信息。所以，該文檔僅定義了與全部應用層FB消息一塊兒使用的公共標頭。從協議的角度
來看，應用層FB消息被視爲特定於有效負載的FB消息的特殊狀況。

注意：在媒體發送方正確處理某些FB消息可能須要發送方知道FB消息所指的有效負載類型。
大多數狀況下，這個信息極可能能夠從僅使用單一有效載荷類型媒體流中得到。然而，若是
同時使用多個編解碼器（例如，同時使用音頻和DTMF）或者當發生編解碼器改變時，有效
載荷類型信息可能須要做爲FB消息的一部分被明確地傳送。這適用於全部特定於有效負載
FB消息以及應用層FB消息。由FB消息的規範來定義如何傳輸有效載荷類型信息。

 

Ott, et al. Standards Track [Page 31]

RFC 4585 RTP/AVPF July 2006

本文檔定義了兩個傳輸層FB消息和三個特定於（視頻）有效負載的FB消息，以及應用層FB消
息的單獨容器。其餘傳輸層和特定於有效負載的FB消息能夠在其餘文檔中定義，而且必須經過
IANA註冊（參見第9節「IANA注意事項」）。

上述RTCP FB消息類型的通常語法和語義在如下小節中描述。

6.1. 反饋消息的通用分組格式

全部FB消息必須使用如圖3所示的通用分組格式：

    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|   FMT   |       PT      |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   SSRC of packet sender                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   SSRC of media source                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            Feedback Control Information (FCI)                 :
   :                                                               :

                         圖3：反饋消息的通用分組格式

字段V，P，SSRC和length在RTP規範[2]中定義，各自的含義總結以下：

版本 (V): 2 bits
該字段標識RTP版本。目前的版本是2。

填充 (P): 1 bit
若是置位，則填充位指示該分組在末尾包含不屬於控制信息的一部分但包括在長度字段中的
附加填充8位字節。

 

 

 

 

Ott, et al. Standards Track [Page 32]

RFC 4585 RTP/AVPF July 2006

反饋消息類型 (FMT): 5 bits
此字段標識FB消息的類型，並根據類型（傳輸層，特定於有效負載或應用程序層反饋）進行
解釋。三種反饋類型中的值在下面的相應部分中定義。

有效載荷類型 (PT): 8 bits
T這是RTCP分組類型，將分組標識爲RTCP FB消息。 IANA定義了兩個值：

            Name   | Value | 簡要描述
         ----------+-------+------------------------------------
            RTPFB  | 205   | 傳輸層FB消息
            PSFB   | 206   | 有效負載特定的FB消息

長度: 16 bits
該分組的長度爲32位word減去1，包括協議頭和填充字節。這與RTCP發送器和接收器報告中
使用的長度字段的定義一致[3]。

分組發送方的SSRC: 32 bits
此分組發送者的同步源標識符。

媒體來源的SSRC: 32 bits
該段反饋信息所涉及的媒體源的同步源標識符。

反饋控制信息 (FCI): 可變長度
如下三節定義了FB消息中能夠包含哪些附加信息，用於每種類型的反饋：傳輸層反饋，特定
於有效負載的反饋，或應用層反饋。請注意，能夠在其餘文檔中指定其餘FCI內容。

每一個RTCP反饋分組必須在FCI字段中包含至少一個FB消息。第6.2和6.3節定義了每種FCI類型，
不管是否能夠將多個FB消息壓縮到單個FCI字段中。若是是這種狀況，它們必須是相同的類型，
即相同的FMT。若是須要傳送多種類型的反饋消息，即幾個FMT，則必須生成若干RTCP FB消息，
而且應該在同一複合RTCP分組中鏈接。

 

 

 

Ott, et al. Standards Track [Page 33]

RFC 4585 RTP/AVPF July 2006

6.2. 傳輸層反饋消息

傳輸層FB消息由值RTPFB標識爲RTCP消息類型。

本文檔中定義了單個通用傳輸層FB消息：通用NACK。它經過FMT參數識別以下：

0: 未分配
1: 通用 NACK
2-30: 未分配
31: 保留用於未來擴展標識符號空間

如下小節定義了此類FB消息的FCI字段的格式。能夠在未來進一步定義通用反饋消息。

6.2.1. 通用 NACK

通用NACK消息由 PT=RTPFB 和 FMT=1 標識。

FCI字段必須至少包含一個，而且能夠包含多個通用NACK。

通用NACK用於指示一個或多個RTP分組的丟失。經過分組標識符和比特掩碼來識別丟失的分組。

若是底層傳輸協議可以向發送方提供相似的反饋信息，則不該使用通用NACK反饋（例如，多是
使用DCCP的狀況）。

反饋控制信息（FCI）字段具備如下語法（圖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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            PID                |              BLP              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       圖4：通用NACK消息的語法

分組標識 (PID): 16 bits
PID字段用於表示丟失的分組。PID字段指的是丟失分組的RTP序列號。

 

Ott, et al. Standards Track [Page 34]

RFC 4585 RTP/AVPF July 2006

後繼丟失分組的位掩碼 (BLP): 16 bits
BLP容許在PID指示的RTP分組以後當即報告16個RTP分組中的任何一個的丟失。BLP的定
義與[6]中給出的定義相同。將BLP的最低有效位表示爲位1，將其最高有效位表示爲位16，
若是接收器未接收到RTP分組序號(PID+i) (模2^16)，則將位掩碼的位i設置爲1表示此
分組丟失; 不然，將位i 設置爲0。請注意，發送方不得由於其位掩碼設置爲0而假設接收
方已收到數據包。例如，BLP的最低有效位將設置爲1，若是PID對應的和後續分組丟失。
然而，發送者不能僅僅由於BLP的位2到位15是0而推斷PID+2到PID+16分組已經被接收;
此時全部發送者都知道是，接收者尚未報告它們丟失。

FB消息的長度必須設置爲 2+n，其中n是FCI字段中包含的通用NACK的數量。

通用NACK消息經過序列號隱式地引用有效載荷類型。

6.3. 有效負載反饋消息

有效負載特定的FB消息由值 PT=PSFB 標識爲RTCP消息類型。

到目前爲止，定義了三個特定於有效負載的FB消息以及應用層FB消息。它們經過以下FMT參數
識別：

     0:     未分配
     1:     圖像丟失指示 (Picture Loss Indication, PLI)
     2:     切片丟失指示 (Slice Loss Indication, SLI)
     3:     參考圖片選擇指示 (Reference Picture Selection Indication, RPSI)
     4-14:  未分配
     15:    應用層FB (Application layer FB, AFB) message
     16-30: 未分配
     31:    保留用於未來擴展序列號空間

如下小節定義了特定於有效負載的FB消息的FCI格式，第6.4節定義了應用層FB消息的FCI格式。

 

 

 

Ott, et al. Standards Track [Page 35]

RFC 4585 RTP/AVPF July 2006

6.3.1. 圖像丟失指示 (Picture Loss Indication, PLI)

PLI FB消息由 PT=PSFB 和 FMT=1 標識。

FCI字段中必須只包含一個PLI。

6.3.1.1. 語義

利用圖像丟失指示消息，解碼器通知編碼器屬於一個或多個圖像的未定義數量的編碼視頻數據丟
失。當與基於圖片間預測的任何視頻編碼方案結合使用時，接收到PLI的編碼器知道預測鏈可能
被破壞。發送方能夠經過發送一個幀內圖像來對PLI做出反應以實現從新同步（該消息至關相似
於[6]中定義的FIR消息）; 可是，發送方必須考慮第7節中描述的擁塞控制，這可能會限制其
發送幀內幀的能力。

其餘RTP有效載荷規範（如RFC 2032 [6]）已經爲某些編解碼器定義了一些反饋機制。支持兩
種方案的應用程序在發送反饋時必須使用本規範中定義的反饋機制。出於向後兼容性的緣由，如
果有效載荷格式須要，這樣的應用程序也應該可以接收並響應在相應RTP有效載荷格式中定義的
反饋方案。

6.3.1.2. 消息格式

PLI不須要參數。所以，長度字段必須是2，而且不得有任何反饋控制信息。

此FB消息的語義與有效負載類型無關。

6.3.1.3. 時序規則

時序遵循第3節中概述的規則。在採用PLI和其餘類型反饋的系統中，建議PLI遵循常規的RTCP
RR時序規則，由於PLI不像其餘FB類型那樣具備延遲關鍵性。

6.3.1.4. 備註

PLI messages typically trigger the sending of full intra-pictures.
Intra-pictures are several times larger then predicted (inter-)
pictures. Their size is independent of the time they are generated.
In most environments, especially when employing bandwidth-limited
links, the use of an intra-picture implies an allowed delay that is a

 

Ott, et al. Standards Track [Page 36]

RFC 4585 RTP/AVPF July 2006

PLI消息一般觸發發送完整的幀內圖像。幀內圖像比預測（幀間）圖像大幾倍。它們的大小與它
們產生的時間無關。在大多數環境中，特別是當採用帶寬受限的鏈路時，使用幀內圖像意味着允
許延遲是典型幀持續時間的幾倍。例如：若是發送幀率是10 fps，而且假設幀內圖像是幀間圖
像的10倍，則必須接受整整一秒的延遲。在這樣的環境中，發送FB消息不須要特別短的延遲。
所以，如[2]所示設置Tmin=0等待RTCP時序規則容許的下一個可能的時隙，不會對系統性能產
生負面影響。

6.3.2. 切片丟失指示 (Slice Loss Indication, SLI)

SLI FB消息由 PT=PSFB 和 FMT=2 標識。

FCI字段必須包含至少一個而且能夠包含多個SLI。

6.3.2.1. 語義

利用切片丟失指示，解碼器能夠通知編碼器它已經以掃描順序檢測到一個或多個連續宏塊的丟失
或損壞（見下文）。該FB消息不得用於具備非均勻、動態可變宏塊大小的視頻編解碼器，例如
啓用Annex Q的H.263。在這種狀況下，編碼器不能保證總能識別損壞的空間區域。

6.3.2.2. 格式

切片丟失指示使用一個額外的FCI字段，其內容如圖6所示。FB消息的長度必須設置爲 2+n，其
中n是FCI字段中包含的SLI數。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            First        |        Number           | PictureID |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       圖6：切片丟失指示（SLI）的語法

First: 13 bits
第一個丟失宏塊的宏塊（MB）地址。進行MB編號，使圖片左上角的宏塊爲是宏塊編號1，並
且宏塊的編號按光柵掃描順序從左到右而後從上到下增長（若是在圖片中總共有N個宏塊，
右下角的宏塊被認爲是宏塊編號N）。

 

Ott, et al. Standards Track [Page 37]

RFC 4585 RTP/AVPF July 2006

Number: 13 bits
丟失宏塊的數量，按照上面討論的掃描順序。

PictureID: 6 bits
編解碼器特定標識符的6個最低有效位，用於引用已發生宏塊丟失的圖像。對於許多視頻編
解碼器，PictureID與時間參考相同。

該FB消息的適用性僅限於一小組視頻編解碼器; 所以，未提供明確的有效載荷類型信息。

6.3.2.3. 時間規則

當指示未及時傳輸時，使用切片丟失指示的算法的效率大大下降。運動補償放大了未報告爲已損
壞的已損壞像素。所以，強烈建議使用第3節中討論的算法。

6.3.2.4. 備註

術語「切片」按其在MPEG-1中的意義在此處定義並使用——按掃描順序排列的必定數量的連續宏塊。
最新的視頻編碼標準有時對術語切片（Slice）有不一樣的理解。例如，在H.263（1998）中，存
在稱爲「矩形切片」的概念。一個矩形切片的丟失可能致使必須發送多於一個SLI以便精確地識別
丟失/損壞的MB（宏塊）的區域。

FCI的第一個字段將圖像的第一個宏塊定義爲1，而不像人們可能猜想的那樣將其定義爲0。這樣
作是爲了使該規範與ITU-T Rec. H.245 [24]中可用的可比機制保持一致。圖像中的最大宏
塊數（2 ** 13或8192）對應於大多數ITU-T和ISO/IEC視頻編解碼器的最大圖像尺寸。若是
將來的視頻編解碼器提供更大的圖像尺寸和/或更小的宏塊尺寸，則必須定義補充的FB消息。時
間參考字段的6個最低有效位被認爲足以指示發生丟失的圖像。

對SLI的反應不是本規範的一部分。對SLI做出反應的一種典型方式是對受影響的空間區域使用
幀內刷新。

 

 

Ott, et al. Standards Track [Page 38]

RFC 4585 RTP/AVPF July 2006

報告的算法是跟蹤受運動補償影響的區域，以便容許將幀內宏塊傳輸到全部這些區域，而無論
FB的時間安排如何（見H.263（2000）附錄I [17]和[15]）。儘管使用這些算法時FB的時間
不那麼重要，但必須注意到這些算法能夠糾正圖像的大部分，所以必須在FB延遲的狀況下傳輸
更高的數據量。

6.3.3. 參考圖片選擇指示（RPSI）

RPSI FB消息由 PT=PSFB 和 FMT=3 標識。

FCI字段中必須只包含一個RPSI。

6.3.3.1. 語義

諸如 MPEG-4 visual version 2 [16]或H.263版本2 [17]的現代視頻編碼標準容許使用
比最近的參考圖像更早的參考圖像進行預測編碼。一般，維持一個參考圖像的先進先出隊列。如
果編碼器已經瞭解到編解碼器同步性的丟失，則可使用已知正確的參考圖像。因爲該參考圖像
的使用在時間上比一般更久，所獲得的預測編碼圖像將使用更多比特。

MPEG-4和H.263都定義了RPSI消息的「有效載荷」的二進制格式，其包括諸如損壞圖像的時間ID
和損壞區域的大小之類的信息。該比特串一般很小（幾十比特），具備可變長度和自包含性，即
包含執行參考圖像選擇所需的全部信息。

MPEG-4和H.263都容許使用具備正反饋信息的RPSI。也就是報告解碼無錯誤的圖像（或切片）。
請注意，在多方會話中不得使用任何形式的正反饋（隨RTCP間隔報告各參考圖像的正反饋預計不
會有太大用處）。

 

 

 

 

 

Ott, et al. Standards Track [Page 39]

RFC 4585 RTP/AVPF July 2006

6.3.3.2. 格式

RPSI消息的FCI遵循圖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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PB       |0| Payload Type|    Native RPSI bit string     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   defined per codec          ...                | Padding (0) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     圖7：參考圖片選擇指示（RPSI）的語法

PB: 8 bits
將RPSI消息的長度填充到32位的倍數須要的未使用位數。

0: 1 bit
傳輸時必須設置爲零，在接收時忽略。

有效負載類型: 7 bits
指示RTP有效載荷類型，原生RPSI位串必須在其環境中解釋。

原生RPSI位串: 長度可變
由視頻編解碼器原生定義的RPSI信息。

填充位: #PB bits
設置爲零的多個位，以將RPSI消息的內容填充到下一個32位邊界。填充位的數量必須由PB
字段指示。

6.3.3.3. 時序規則

與使用SLI的算法相比，RPSI對延遲更爲重要。這是由於RPSI消息越舊，編碼器必須花費更多
的比特來從新創建編碼器與解碼器的同步。有關某些比特率/幀速率/丟失率狀況下RPSI開銷的
一些信息，請參見[15]。

所以，一般應使用第3節的算法儘快發送RPSI消息。

 

 

 

Ott, et al. Standards Track [Page 40]

RFC 4585 RTP/AVPF July 2006

6.4. 應用層反饋消息

應用層FB消息是特定於有效負載的消息的特殊狀況，由 PT=PSFB 和 FMT=15 標識。除非應
用層FB消息結構自己容許堆疊（例如，經過固定大小或顯式長度指示符），不然FCI字段中必須
包含剛好一個應用層FB消息。

這些消息用於將應用程序定義的數據直接從接收方傳輸到發送方的應用程序。FB消息不識別傳輸
的數據。所以，應用程序必須可以識別消息的有效負載。

一般，應用程序定義它們本身的消息集，例如，MPEG-4 [16]中的NEWPRED消息（根據RFC
3016 [23]在RTP數據包中攜帶）或H.263/附件N，U [17]中的FB消息（按照RFC 2429 [14]
進行打包）。這些消息不須要RTCP消息中的任何其餘信息。所以，應用消息簡單地以下放入FCI
字段中，並相應地設置長度字段。

應用程序消息 (FCI): 可變長度
該字段包含應從接收器傳輸到源的原始應用程序消息。格式取決於應用程序。 該字段的長度
是可變的。若是應用程序數據不是32位對齊，則必須添加填充位和字節以實現32位對齊。填
充的標識取決於應用層，而且未在本規範中定義。

應用層FB消息規範必須定義是否須要在某個編解碼器的上下文中特別地解釋消息（由RTP有效載
荷類型標識）。若是正確處理須要引用有效載荷類型，則應用層FB消息規範必須定義一種將有效
載荷類型信息做爲應用層FB消息自己的一部分進行通訊的方法。

7. 早期反饋和擁塞控制

在前面的部分中，定義了FB消息，以及發送這些消息的時間規則。對收到的反饋作出反應的方式，
取決於使用反饋機制的應用程序，所以超出了本文檔的範圍。可是，全部應用程序，當在盡力而
爲的網絡環境中操做時，在[1]和[2]中定義的媒體流上存在對（TCP友好的）擁塞控制的共同要
求。

 

 

Ott, et al. Standards Track [Page 41]

RFC 4585 RTP/AVPF July 2006

應當注意，RTCP反饋自己不足以用於擁塞控制目的，由於它可能在比其餘傳輸層反饋機制（通
常以RTT的順序操做）慢得多的時間尺度下操做。所以，須要額外的機制來執行適當的擁塞控制。

與競爭TCP鏈接合理公平地共享可用帶寬的擁塞控制算法，例如TFRC [7]，必須在RTP發送方
和媒體會話的能力範圍以內，用於肯定媒體流的數據速率，若是RTP/AVPF會話在盡力而爲的環
境中傳輸。

8. 安全考慮因素

以建議的有效載荷格式傳輸信息的RTP分組受RTP規範[1]和RTP/AVP配置文件規範[2]中討論
的安全考慮因素的影響。此配置文件未指定任何其餘安全服務。

此配置文件修改了RTCP的時序行爲，並消除了5秒的最小RTCP間隔，並容許接收器提供更早的
反饋。相關聯的RTP會話的組成員（可能僞裝表明大量實體）可能經過發送大量RTCP分組來幹
擾RTCP的操做，從而減小可用於常規RTCP報告以及早期FB消息的RTCP帶寬。（請注意，實體
沒必要是多播組的成員就會產生這些影響。）一樣，惡意成員可能會發送很是大的RTCP消息，從
而增長avg_rtcp_size變量並減小可用的有效RTCP帶寬。

若是接收到未知的RTCP反饋分組，則能夠抑制反饋信息。這引入了這樣的風險，惡意組成員可
以經過簡單地發送具備任何接收器（所以它們將抑制反饋）或發送者（所以不會採起修復操做）
都沒法識別的、內容隨機的特定有效負載RTCP反饋分組，來減小早期反饋。

惡意組成員還能夠在反饋信息中報告任意高的丟失率，以使發送方限制數據傳輸並增長冗餘信
息量，或採起其餘措施來處理僞裝的丟包（例如，發送更少幀或下降音視頻質量）。這可能導
致再現媒體流的質量降低。

 

Ott, et al. Standards Track [Page 42]

RFC 4585 RTP/AVPF July 2006

最後，惡意組成員能夠充當大量的組成員，從而人爲地得到大部分早期反饋帶寬，並下降其餘
組成員的反應——甚至可能致使他們再也不以當即模式或早期反饋模式運做，從而破壞此配置文件
的整個目的。

在觀察奇怪的報告行爲時，發送者和接收者應該謹慎行事。對於來自一個或幾個接收器的過分
故障報告，發送者能夠決定在調整其媒體流的傳輸行爲時再也不考慮該反饋。在任何狀況下，發
送者和接收者應該仍然遵照最大RTCP帶寬，但要確保它們至少可以發送按期調度的RTCP分組。
發送者應該在遇到奇怪的報告行爲時仔細考慮如何調整傳輸帶寬；即便忽略了可疑的反饋，他
們也不能增長傳輸帶寬。

經過驗證全部RTCP消息，能夠避免經過使用錯誤的RTCP分組（常規分組和早期分組）進行的攻
擊。這能夠經過將AVPF配置文件與[22]中定義的安全RTP配置文件一塊兒使用來實現；做爲必須
條件，正在指定這兩個配置文件（名爲SAVPF）的適當組合[21]。注意，當採用組認證（與源
認證相反）時，上述攻擊能夠由擁有正確密鑰資料的惡意或故障組成員執行。

9. IANA注意事項

如下聯繫信息應被用於全部此處包含的註冊：

聯繫人: Joerg Ott
電子郵件:jo@acm.org
電話:+358-9-451-2460

反饋簡檔做爲對具備最小控制的音視頻會議的簡檔的擴展已經爲會話描述協議（特別是類型
「proto」）註冊爲：RTP/AVPF。

 

 

 

 

Ott, et al. Standards Track [Page 43]

RFC 4585 RTP/AVPF July 2006

SDP 協議 ("proto"):

名稱: RTP/AVPF
完整形式: 基於RTCP的反饋擴展RTP簡檔
名稱類型: proto
屬性類型: 僅限媒體級別
目的: RFC 4585
參考: RFC 4585

SDP 屬性 ("att-field"):

Attribute name: rtcp-fb
Long form: RTCP Feedback parameter
Type of name: att-field
Type of attribute: Media level only
Subject to charset: No
Purpose: RFC 4585
Reference: RFC 4585
Values: See this document and registrations below

已爲 rtcp-fb 屬性設置了一個新的記錄，建立了如下幾個最初註冊：
ack，nack，trr-int和本文檔中定義的app。

屬性 rtcp-fb 的初始值註冊

Value name: ack
Long name: Positive acknowledgement
Reference: RFC 4585.

Value name: nack
Long name: Negative Acknowledgement
Reference: RFC 4585.

Value name: trr-int
Long name: Minimal receiver report interval
Reference: RFC 4585.

Value name: app
Long name: Application-defined parameter
Reference: RFC 4585.

能夠按先到先得的原則註冊更多的條目。每一個新的註冊都須要指明參數名稱和可能的附加參數的
語法。對於每一個新的註冊，必須存在永久、穩定且可公開訪問的文檔，指定其註冊參數的語義、
其參數的語法和語義，以及相應的反饋分組格式（若是須要）。適用[3]的通用註冊流程。

 

Ott, et al. Standards Track [Page 44]

RFC 4585 RTP/AVPF July 2006

 

爲了與 ack 和 nack 一塊兒使用，已經創建了一個聯合子記錄，它最初註冊瞭如下值：

屬性值 ack 和 nack 的初始值註冊：

Value name: sli
Long name: Slice Loss Indication
Usable with: nack
Reference: RFC 4585.

Value name: pli
Long name: Picture Loss Indication
Usable with: nack
Reference: RFC 4585.

Value name: rpsi
Long name: Reference Picture Selection Indication
Usable with: ack, nack
Reference: RFC 4585.

Value name: app
Long name: Application layer feedback
Usable with: ack, nack
Reference: RFC 4585.

能夠按先到先得的原則註冊更多的條目。每一個註冊須要指明參數名稱，可能的附加參數的語法，
以及參數是否適用於 ack 或 nack 反饋之一，或者同時適用於二者，或某些不一樣的rtcp-fb
屬性參數。對於每一個新註冊，必須存在永久、穩定且可公開訪問的文檔，其指定註冊參數的語
義，其參數的語法和語義，以及相應的分組格式（若是須要）。適用[3]的通用註冊流程。

有兩種RTCP控制分組類型：用於傳輸層FB消息類（RTPFB），和用於特定於有效負載的FB消息
類（PSFB）。根據第6節，RTCP註冊表中已添加了 RTPFB=205 和 PSFB=206。

 

 

 

Ott, et al. Standards Track [Page 45]

RFC 4585 RTP/AVPF July 2006

RTP RTCP Control Packet types (PT):

Name: RTPFB
Long name: Generic RTP Feedback
Value: 205
Reference: RFC 4585.

Name: PSFB
Long name: Payload-specific
Value: 206
Reference: RFC 4585.

因爲AVPF定義了額外的RTCP有效載荷類型，所以相應地擴展了對應的「保留」RTP有效載荷類型
空間（72-76，如[2]中所定義）。

已爲 RTPFB 有效載荷類型和 PSFB 有效載荷類型的 FMT 值設置了新的子註冊表，最初建立
瞭如下注冊：

在 RTPFB 範圍內，最初註冊如下兩種格式（FMT）值：

Name: Generic NACK
Long name: Generic negative acknowledgement
Value: 1
Reference: RFC 4585.

Name: Extension
Long name: Reserved for future extensions
Value: 31
Reference: RFC 4585.

在 PSFB 範圍內，最初註冊如下五種格式（FMT）值：

Name: PLI
Long name: Picture Loss Indication
Value: 1
Reference: RFC 4585.

Name: SLI
Long name: Slice Loss Indication
Value: 2
Reference: RFC 4585.

 

 

Ott, et al. Standards Track [Page 46]

RFC 4585 RTP/AVPF July 2006

Name:      RPSI
Long name: Reference Picture Selection Indication
Value:     3
Reference: RFC 4585.

Name:      AFB
Long name: Application Layer Feedback
Value:     15
Reference: RFC 4585.

Name:      Extension
Long name: Reserved for future extensions.
Value:     31
Reference: RFC 4585.

能夠聽從RFC 2434 [9]中定義的「規範要求」的規則註冊更多條目。每一個註冊須要指明FMT值，
若是要在FCI字段存放的特定FB消息，而且不管是否能夠在單個FCI字段中堆疊多個FB消息。對
於每一個新的註冊條目，必須存在永久、穩定且可公開訪問的文檔，該文檔指定已註冊參數的語義，
以及關聯FB消息（若是有）的語法和語義。適用[3]的通用註冊程序。

10. 致謝

本文檔是IETF的音視頻傳輸（AVT）工做組的做品。做者要感謝Steve Casner和Colin
Perkins的意見和建議，以及他們對衆多問題的迴應。做者還要特別感謝Magnus Westerlund
的評論和他的寶貴建議，以及Shigeru Fukunaga對FB消息格式和語義的貢獻。

咱們還要感謝Andreas Buesching和Panasonic的工做人員進行模擬以及首次獨立實現反饋
配置文件。

 

 

 

 

 

 

Ott, et al. Standards Track [Page 47]

RFC 4585 RTP/AVPF July 2006

11. 參考

11.1. 規範性參考文獻

[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.

[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.

[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.

[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[6] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video
Streams", RFC 2032, October 1996.

[7] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.

[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.

[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

11.2. 信息參考

[10] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.

[11] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.

[12] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.

 

 

Ott, et al. Standards Track [Page 48]

RFC 4585 RTP/AVPF July 2006

[13] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.

[14] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C.,
Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP
Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
(H.263+)", RFC 2429, October 1998.

[15] B. Girod, N. Faerber, "Feedback-based error control for mobile
video transmission", Proceedings IEEE, Vol. 87, No. 10, pp.
1707 - 1723, October, 1999.

[16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology -
Coding of audio-visual objects - Part2: Visual", 2001.

[17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate
Communication", November 2000.

[18] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.

[19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.

[20] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.

[21] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)", Work in Progress, December 2005.

[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.

[23] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H.
Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams",
RFC 3016, November 2000.

[24] ITU-T Recommendation H.245, "Control protocol for multimedia
communication", May 2006.

 

 

 

 

Ott, et al. Standards Track [Page 49]

RFC 4585 RTP/AVPF July 2006

Authors' Addresses

Joerg Ott
Helsinki University of Technology (TKK)
Networking Laboratory
PO Box 3000
FIN-02015 TKK
Finland

EMail: jo@acm.org

Stephan Wenger
Nokia Research Center
P.O. Box 100
33721 Tampere
Finland

EMail: stewe@stewe.org

Noriyuki Sato
Oki Electric Industry Co., Ltd.
1-16-8 Chuo, Warabi-city, Saitama 335-8510
Japan

Phone: +81 48 431 5932
Fax: +81 48 431 9115
EMail: sato652@oki.com

Carsten Burmeister
Panasonic R&D Center Germany GmbH

EMail: carsten.burmeister@eu.panasonic.com

Jose Rey
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany

EMail: jose.rey@eu.panasonic.com

 

 

 

Ott, et al. Standards Track [Page 50]

RFC 4585 RTP/AVPF July 2006

Full Copyright Statement

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

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.

Intellectual Property

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
ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

 

 

 

Ott, et al. Standards Track [Page 51]