Internet Engineering Task Force (IETF) Q. Wu, Ed.
Request for Comments: 6642 F. Xia
Category: Standards Track R. Even
ISSN: 2070-1721 Huawei
June 2012
Internet Engineering Task Force (IETF) Q. Wu, Ed.
Request for Comments: 6642 F. Xia
Category: Standards Track R. Even
ISSN: 2070-1721 Huawei
June 2012
RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report
第三方丢失报告的RTP控制协议（RTCP）扩展
Abstract
摘要
In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated Session Description Protocol (SDP) signaling is also defined.
在使用RFC 4585中定义的RTP控制协议（RTCP）反馈机制的大型RTP会话中，如果某个事件导致大量接收器同时发送反馈，则反馈目标可能会经历瞬时过载。通常通过确保将反馈报告转发给所有接收者来避免这种过载，从而使他们避免发送重复的反馈报告。但是，在某些情况下，不建议转发反馈报告，这可能会导致反馈内爆。本备忘录讨论了这些情况，并定义了一份新的RTCP第三方损失报告，该报告可用于通知接收者反馈目标意识到某些损失事件，从而允许接收者抑制反馈。还定义了相关会话描述协议（SDP）信令。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6642.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6642.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Requirements Notation ......................................3
2.2. Glossary ...................................................4
3. Example Use Cases ...............................................4
3.1. Source-Specific Multicast (SSM) Use Case ...................4
3.2. Unicast-Based Rapid Acquisition of Multicast Stream
(RAMS) Use Case ............................................5
3.3. RTP Transport Translator Use Case ..........................5
3.4. Multipoint Control Unit (MCU) Use Case .....................6
3.5. Mixer Use Case .............................................6
4. Protocol Overview ...............................................6
5. Format of RTCP Feedback Messages ................................7
5.1. Transport-Layer Feedback: Third-Party Loss Report (TPLR) ...8
5.2. Payload-Specific Feedback: Third-Party Loss Report (TPLR) .8
6. SDP Signaling ...................................................9
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgments ................................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Requirements Notation ......................................3
2.2. Glossary ...................................................4
3. Example Use Cases ...............................................4
3.1. Source-Specific Multicast (SSM) Use Case ...................4
3.2. Unicast-Based Rapid Acquisition of Multicast Stream
(RAMS) Use Case ............................................5
3.3. RTP Transport Translator Use Case ..........................5
3.4. Multipoint Control Unit (MCU) Use Case .....................6
3.5. Mixer Use Case .............................................6
4. Protocol Overview ...............................................6
5. Format of RTCP Feedback Messages ................................7
5.1. Transport-Layer Feedback: Third-Party Loss Report (TPLR) ...8
5.2. Payload-Specific Feedback: Third-Party Loss Report (TPLR) .8
6. SDP Signaling ...................................................9
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgments ................................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
The RTP Control Protocol (RTCP) feedback messages [RFC4585] allow the receivers in an RTP session to report events and ask for action from the media source (or a delegated feedback target when using unicast RTCP feedback with Source-Specific Multicast (SSM) [RFC5760]). There are cases where multiple receivers may initiate the same, or an equivalent, message towards the same media source or the same feedback target. When the receiver count is large, this behavior may cause transient overload of the media source, the network, or both. This is known as a "feedback storm" or a "NACK storm".
RTP控制协议（RTCP）反馈消息[RFC4585]允许RTP会话中的接收者报告事件并请求媒体源（或使用源特定多播（SSM）的单播RTCP反馈时的委托反馈目标）[RFC5760]采取行动。在某些情况下，多个接收器可向同一媒体源或同一反馈目标发起相同或等效的消息。当接收器计数较大时，此行为可能导致媒体源、网络或两者的瞬时过载。这被称为“反馈风暴”或“NACK风暴”。
One scenario that can cause such feedback storms involves video Fast Update requests. A storm of these feedback messages can occur in conversational multimedia scenarios like multipoint video switching conference [RFC4587], where many receivers may simultaneously lose synchronization with the video stream when the speaker is changed in the middle of a session. Receivers that issue Fast Update requests (i.e., Full Intra Request (FIR) described in RFC 5104 [RFC5104]), can cause an implosion of FIR requests from receivers to the same media source since these requests must currently be made blind, without knowledge of requests made by other receivers.
一个可能导致此类反馈风暴的场景涉及视频快速更新请求。这些反馈消息的风暴可能发生在会话多媒体场景中，如多点视频切换会议[RCFC88]，其中当在会话的中间改变说话者时，许多接收机可能同时失去与视频流的同步。发出快速更新请求（即RFC 5104[RFC5104]中描述的完整帧内请求（FIR））的接收器可能会导致接收器对同一媒体源的FIR请求内爆，因为这些请求当前必须是盲的，而不知道其他接收器发出的请求。
RTCP feedback storms may cause short-term overload and, in extreme cases, pose a possible risk of increasing network congestion on the control channel (e.g., RTCP feedback), the data channel, or both. It is therefore desirable to provide a way of suppressing unneeded feedback. This document specifies a new Third-Party Loss Report for this function. It supplements the existing use of RTCP NACK packets and is also more precise in the uses where the network is active to suppress feedback. It tells receivers explicitly that feedback for a particular packet or frame loss is not needed and can provide an early indication before the receiver reacts to the loss and invokes its packet loss repair machinery. Section 3 provides some example use cases of when to send the Third-Party Loss Report message.
RTCP反馈风暴可能会导致短期过载，在极端情况下，可能会增加控制通道（如RTCP反馈）、数据通道或两者的网络拥塞风险。因此，希望提供一种抑制不必要反馈的方法。本文档为此功能指定了新的第三方损失报告。它补充了现有的RTCP NACK数据包的使用，并且在网络处于活动状态以抑制反馈的情况下更精确。它明确地告诉接收机，不需要针对特定分组或帧丢失的反馈，并且可以在接收机对丢失作出反应并调用其分组丢失修复机制之前提供早期指示。第3节提供了一些关于何时发送第三方损失报告消息的示例用例。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
TPLR - Third-Party Loss Report
TPLR-第三方损失报告
TLLEI - Transport-Layer Third-Party Loss Early Indication
TLLEI-传输层第三方丢失早期指示
PSLEI - Payload-Specific Third-Party Loss Early Indication
PSLEI-有效载荷特定的第三方损失早期指示
PT - Payload Type
PT-有效载荷类型
FMT - Feedback Message Type
FMT-反馈消息类型
FCI - Feedback Control Information [RFC4585]
FCI-反馈控制信息[RFC4585]
AVPF - Audio-Visual Profile with RTCP-based feedback [RFC4585]
AVPF-基于RTCP反馈的视听配置文件[RFC4585]
SSRC - Synchronization Source
同步源
BRS - Burst/Retransmission Source [RFC6285]
BRS-突发/重传源[RFC6285]
FIR - Full Intra Request [RFC5104]
FIR-全帧内请求[RFC5104]
PLI - Picture Loss Indication [RFC4585]
PLI-图像丢失指示[RFC4585]
SSM - Source-Specific Multicast [RFC5760]
SSM-源特定多播[RFC5760]
RAMS - Unicast-based Rapid Acquisition of Multicast Stream [RFC6285]
RAMS-基于单播的多播流快速捕获[RFC6285]
MCU - Multipoint Control Unit [RFC5117]
MCU-多点控制单元[RFC5117]
The operation of feedback suppression is similar for all types of RTP sessions and topologies [RFC5117]; however, the exact messages used and the scenarios in which suppression is employed differ for various use cases. The following sections outline some of the intended use cases for using the Third-Party Loss Report for feedback suppression and give an overview of each.
反馈抑制的操作与所有类型的RTP会话和拓扑相似[RFC5117]；然而，所使用的确切消息和使用抑制的场景对于不同的用例是不同的。以下各节概述了使用第三方损失报告进行反馈抑制的一些预期用例，并对每个用例进行了概述。
In SSM RTP sessions as described in "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback" [RFC5760], one or more media sources send RTP packets to a distribution source. The distribution source relays the RTP packets to the receivers using a source-specific multicast group.
在SSM RTP会话中，如“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”[RFC5760]所述，一个或多个媒体源向分发源发送RTP数据包。分发源使用特定于源的多播组将RTP分组中继到接收机。
As outlined in RFC 5760 [RFC5760], there are two Unicast Feedback models that may be used for reporting: the Simple Feedback Model and the Distribution Source Feedback Summary Model. In the Simple Feedback Model, there's no need for the distribution source to create the RTCP TPLRs; instead, RTCP NACKs are reflected by the distribution source to the other receivers. However, in the Distribution Source Feedback Summary Model, the distribution source will not redistribute the NACK for some reason (e.g., to prevent revealing the identity or existence of a system sending NACK) and may send an RTCP TPLR message to the systems that were unable to receive the NACK and won't receive the NACK via other means. The RTCP TPLR can be generated at the distribution source when downstream loss is reported (e.g., downstream loss report is received), which indicates to the receivers that they should not transmit feedback messages for the same loss event for a certain time. Therefore, the distribution source in the Distribution Source Feedback Summary Model can be reasonably certain that it will help the situation (i.e., the distribution source is unable receive the NACK) by sending this RTCP TPLR message to all the relevant receivers impacted by the packet loss.
如RFC 5760[RFC5760]所述，有两种单播反馈模型可用于报告：简单反馈模型和分发源反馈摘要模型。在简单反馈模型中，分发源不需要创建RTCP TPLR；相反，RTCP NACK由分发源反射到其他接收器。然而，在分发源反馈摘要模型中，分发源出于某种原因（例如，为了防止泄露发送NACK的系统的身份或存在），不会重新分发NACK，并且可能会向无法接收NACK且不会通过其他方式接收NACK的系统发送RTCP TPLR消息。报告下游损失（例如，收到下游损失报告）时，可在分发源生成RTCP TPLR，这向接收者表明，他们在一定时间内不应发送同一损失事件的反馈消息。因此，分发源反馈汇总模型中的分发源可以合理地确定，它将通过向受数据包丢失影响的所有相关接收方发送此RTCP TPLR消息来帮助解决这种情况（即，分发源无法接收NACK）。
3.2. Unicast-Based Rapid Acquisition of Multicast Stream (RAMS) Use Case
3.2. 基于单播的多播流快速捕获（RAMS）用例
The typical RAMS architecture [RFC6285] may have several Burst/ Retransmission Sources (BRSs) behind the multicast source placed at the same level. These BRSs will receive the primary multicast RTP stream from the media source and cache the most recent packets after joining the multicast session. If packet loss happens at the upstream of all the BRSs or the downstream of BRSs, one or all of the BRSs may send an RTCP NACK or RTCP TPLR message to the distribution source, where the SSRC in this RTCP NACK or RTCP TPLR message is the BRS that is sending the message. The distribution source forwards/ reflects this message down on the primary SSM. The details on how the distribution source deals with this message are specified in [RETRANS-FOR-SSM].
典型的RAMS体系结构[RFC6285]在多播源后面可能有多个突发/重传源（BRS），它们位于同一级别。这些BRS将从媒体源接收主多播RTP流，并在加入多播会话后缓存最近的数据包。如果在所有BRS的上游或下游发生分组丢失，则一个或所有BRS可向分发源发送RTCP NACK或RTCP TPLR消息，其中该RTCP NACK或RTCP TPLR消息中的SSRC是发送该消息的BRS。分发源在主SSM上转发/反映此消息。[RETRANS-FOR-SSM]中指定了分发源如何处理此消息的详细信息。
A Transport Translator (Topo-Trn-Translator), as defined in RFC 5117 [RFC5117], is typically forwarding the RTP and RTCP traffic between RTP clients, for example, converting from multicast to unicast for domains that do not support multicast. The translator may suffer a loss of important video packets. In this case, the translator may forward an RTCP TPLR message received from upstream in the same way it forwards other RTCP traffic. If the translator acting as the monitor [MONARCH] is aware of packet loss, it may use the SSRC of the monitor as the SSRC of the packet sender to create a NACK message and send it to the receivers that are not aware of packet loss.
RFC 5117[RFC5117]中定义的传输转换器（拓扑Trn转换器）通常在RTP客户端之间转发RTP和RTCP通信量，例如，对于不支持多播的域，将多播转换为单播。译者可能会丢失重要的视频数据包。在这种情况下，转换器可以转发从上游接收的RTCP TPLR消息，转发方式与转发其他RTCP流量相同。如果充当监视器[monar]的翻译器意识到分组丢失，它可以使用监视器的SSRC作为分组发送器的SSRC来创建NACK消息并将其发送给不知道分组丢失的接收器。
When the speaker is changed in a voice-activated multipoint video switching conference [RFC4587], an RTP mixer can be used to select the available input streams and forward them to each participant. If the MCU is doing a blind switch without waiting for a synchronization point on the new stream, it can send a FIR to the new video source. In this case, the MCU should send a FIR suppression message to the new receivers. For example, when the RTP mixer starts to receive FIR from some participants, it can suppress the remaining session participants from sending FIR by sending out an RTCP TPLR message.
在语音激活多点视频交换会议[RFC4587]中更换扬声器时，可以使用RTP混音器选择可用的输入流并将其转发给每个参与者。如果MCU在不等待新流上的同步点的情况下进行盲切换，它可以向新视频源发送FIR。在这种情况下，MCU应向新接收器发送FIR抑制消息。例如，当RTP混合器开始从一些参与者接收FIR时，它可以通过发送RTCP TPLR消息来禁止其余会话参与者发送FIR。
A mixer, in accordance with RFC 5117 [RFC5117], aggregates multiple RTP streams from other session participants and generates a new RTP stream sent to the session participants. In some cases, the delivery of video frames delivery may get damaged, for example, due to packet loss or delayed delivery, between the media source and the mixer. In such cases, the mixer needs to check if the packet loss will result in PLI or FIR transmissions from most of the group by analyzing the received video. If so, the mixer may initiate FIR or PLI towards the media source on behalf of all the session participants and send out an RTCP TPLR message to the session participants that may or are expected to send a PLI or FIR. Alternatively, when the mixer starts to receive FIR or PLI from some participants and would like to suppress the remaining session participants from sending FIR or PLI, it can just forward the FIR/PLI from one session participant to others.
根据RFC 5117[RFC5117]，混合器聚合来自其他会话参与者的多个RTP流，并生成发送给会话参与者的新RTP流。在某些情况下，视频帧传送的传送可能受到损害，例如，由于媒体源和混频器之间的分组丢失或延迟传送。在这种情况下，混频器需要通过分析接收到的视频来检查分组丢失是否会导致来自大多数组的PLI或FIR传输。如果是这样，混合器可以代表所有会话参与者向媒体源发起FIR或PLI，并向会话参与者发送可能或预期发送PLI或FIR的RTCP TPLR消息。或者，当混频器开始从一些参与者接收FIR或PLI，并且希望禁止其余会话参与者发送FIR或PLI时，它可以将FIR/PLI从一个会话参与者转发给其他会话参与者。
This document extends the RTCP feedback messages defined in the RTP/ AVPF [RFC4585] by defining an RTCP Third-Party Loss Report (TPLR) message. The RTCP TPLR message can be used by the intermediaries to inform the receiver that the sender of the RTCP TPLR has received reports that the indicated packets were lost and ask the receiver not to send feedback to it regarding these packets. Intermediaries are variously referred to as distribution sources, Burst/Retransmission Sources, MCUs, RTP translators, or RTP mixers, depending on the precise use case described Section 3.
本文件通过定义RTCP第三方损失报告（TPLR）消息扩展了RTP/AVPF[RFC4585]中定义的RTCP反馈消息。中介机构可使用RTCP TPLR消息通知接收方RTCP TPLR的发送方已收到指示数据包丢失的报告，并要求接收方不要向其发送有关这些数据包的反馈。根据第3节描述的确切用例，中介被不同地称为分发源、突发/重传源、MCU、RTP转换器或RTP混频器。
RTCP TPLR follows a similar message type format as RTCP NACK or Full Intra Request Command. However, RTCP TPLR is defined as an indication that the sender of the feedback has received reports that the indicated packets were lost, while NACK [RFC4585] just indicates that the sender of the NACK observed that these packets were lost. The RTCP TPLR message is generated by an intermediary that may not
RTCP TPLR遵循与RTCP NACK或完整内部请求命令类似的消息类型格式。然而，RTCP TPLR被定义为反馈发送方已收到所指示数据包丢失的报告的指示，而NACK[RFC4585]仅指示NACK发送方已观察到这些数据包丢失。RTCP TPLR消息由中间层生成，该中间层可能不会
have seen the actual packet loss. It is sent following the same timing rule as sending NACK, defined in RFC 4585 [RFC4585]. The RTCP TPLR message may be sent in a regular full compound RTCP packet or in an early RTCP packet, as per the RTP/AVPF rules. Intermediaries in the network that receive an RTCP TPLR MUST NOT send their own additional Third-Party Loss Report messages for the same packet sequence numbers. They SHOULD simply forward the RTCP TPLR message received from upstream to the receiver(s). Additionally, they may generate their own RTCP TPLR that reports a set of the losses they see, which are different from ones reported in the RTCP TPLR they received. The RTCP TPLR does not have retransmission request [RFC4588] semantics.
已经看到了实际的数据包丢失。它按照RFC 4585[RFC4585]中定义的发送NACK的相同定时规则发送。根据RTP/AVPF规则，RTCP TPLR消息可在常规完整复合RTCP数据包或早期RTCP数据包中发送。网络中接收RTCP TPLR的中介机构不得针对相同的数据包序列号发送其自己的附加第三方丢失报告消息。他们只需将从上游接收到的RTCP TPLR消息转发给接收方即可。此外，他们可以生成自己的RTCP TPLR，报告他们看到的一组损失，这与他们收到的RTCP TPLR中报告的损失不同。RTCP TPLR没有重传请求[RFC4588]语义。
When a receiver gets an RTCP TPLR message, it MUST follow the rules for NACK suppression in RFC 4585 [RFC4585] and refrain from sending a feedback request (e.g., NACK or FIR) for the missing packets reported in the message, which is dealt with in the same way as receiving a NACK.
当接收器收到RTCP TPLR消息时，它必须遵循RFC 4585[RFC4585]中的NACK抑制规则，并且不对消息中报告的丢失数据包发送反馈请求（例如，NACK或FIR），其处理方式与接收NACK相同。
To increase the robustness to the loss of a TPLR, the RTCP TPLR may be retransmitted. If the additional TPLR arrives at the receiver, the receiver SHOULD deal with the additional TPLR in the same way as receiving the first TPLR for the same packet, and no additional behavior for receiver is required.
为了增加对TPLR丢失的鲁棒性，可以重新传输RTCP TPLR。如果附加TPLR到达接收器，则接收器应以与接收同一数据包的第一个TPLR相同的方式处理附加TPLR，并且不需要接收器的附加行为。
A receiver may have sent a feedback message according to the RTP/AVPF scheduling algorithm of RFC 4585 [RFC4585] before receiving an RTCP TPLR message, but further feedback messages for those sequence numbers SHOULD be suppressed after receiving the RTCP TPLR. Nodes that do not understand the RTCP TPLR message will ignore it and might therefore still send feedback according to the AVPF scheduling algorithm of RFC 4585 [RFC4585]. The media source or intermediate nodes cannot be certain that the use of an RTCP TPLR message actually reduces the amount of feedback they receive.
在接收RTCP TPLR消息之前，接收机可能已经根据RFC 4585[RFC4585]的RTP/AVPF调度算法发送了反馈消息，但是在接收RTCP TPLR消息之后，应该抑制针对这些序列号的进一步反馈消息。不理解RTCP TPLR消息的节点将忽略该消息，因此仍可能根据RFC 4585[RFC4585]的AVPF调度算法发送反馈。媒体源或中间节点无法确定RTCP TPLR消息的使用是否确实减少了它们收到的反馈量。
This document introduces two new RTCP feedback messages for Third-Party Loss Report. Applications that are employing one or more loss-repair methods MAY use the RTCP TPLR together with their existing loss-repair methods either for every packet they expect to receive or for an application-specific subset of the RTP packets in a session.
本文档介绍了第三方损失报告的两条新RTCP反馈消息。采用一种或多种丢失修复方法的应用程序可将RTCP TPLR与其现有的丢失修复方法一起用于其预期接收的每个分组或会话中RTP分组的特定于应用程序的子集。
The following two sections each define an RTCP TPLR message. Both messages are feedback messages as defined in Section 6.1 of RFC 4585 [RFC4585] and use the header format defined there. Each section defines how to populate the PT, FMT, length, SSRC of packet sender, SSRC of media source, and FCI fields in that header.
以下两部分分别定义RTCP TPLR消息。这两条消息都是RFC 4585[RFC4585]第6.1节中定义的反馈消息，并使用其中定义的标头格式。每个部分定义如何填充该报头中的PT、FMT、长度、数据包发送方的SSRC、媒体源的SSRC和FCI字段。
This TPLR message is identified by RTCP packet type values PT=RTPFB and FMT=7.
此TPLR消息由RTCP数据包类型值PT=RTPFB和FMT=7标识。
Within the common packet header for feedback messages (as defined in Section 6.1 of RFC 4585 [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" field denotes the media sender of the flow for which the indicated losses are being suppressed.
在反馈消息的公共分组报头中（如RFC 4585[RFC4585]第6.1节中的定义），“分组发送者的SSRC”字段表示请求的来源，“媒体源的SSRC”字段表示流的媒体发送者，对于该流，指示的丢失被抑制。
The FCI field MUST contain one or more entries of Transport-Layer Third-Party Loss Early Indication (TLLEI). Each entry applies to the same media source identified by the SSRC contained in the "SSRC of media source" field of the Feedback header. The length field in the TLLEI feedback message MUST be set to N+2, where N is the number of FCI entries.
FCI字段必须包含传输层第三方早期丢失指示（TLLEI）的一个或多个条目。每个条目适用于由反馈标题“媒体源的SSRC”字段中包含的SSRC标识的相同媒体源。TLLEI反馈消息中的长度字段必须设置为N+2，其中N是FCI条目数。
The FCI field for TLLEI uses a similar message type format to that defined in the Section 6.2.1 of RFC 4585 [RFC4585]. The format is shown in Figure 1.
TLLEI的FCI字段使用与RFC 4585[RFC4585]第6.2.1节中定义的类似的消息类型格式。格式如图1所示。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Syntax of an FCI Entry in the TLLEI Feedback Message
图1:TLLEI反馈消息中FCI条目的语法
Packet ID (PID): 16 bits
数据包ID（PID）：16位
The PID field is used to specify a lost packet. The PID field refers to the RTP sequence number of the lost packet.
PID字段用于指定丢失的数据包。PID字段是指丢失数据包的RTP序列号。
bitmask of lost packets (BLP): 16 bits
丢失数据包的位掩码（BLP）：16位
The BLP allows for reporting losses of any of the 16 RTP packets immediately following the RTP packet indicated by the PID. The BLP's definition is identical to that given in Section 6.2.1 of [RFC4585].
BLP允许在PID指示的RTP数据包之后立即报告16个RTP数据包中的任何一个的丢失。BLP的定义与[RFC4585]第6.2.1节中给出的定义相同。
This TPLR message is identified by RTCP packet type values PT=PSFB and FMT=8, which are used to suppress FIR [RFC5104] and PLI [RFC4585].
该TPLR消息由RTCP数据包类型值PT=PSFB和FMT=8标识，用于抑制FIR[RFC5104]和PLI[RFC4585]。
Within the common packet header for feedback messages (as defined in Section 6.1 of RFC 4585 [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which this message apply are in the corresponding FCI entries.
在反馈消息的公共数据包头中（如RFC 4585[RFC4585]第6.1节中的定义），“数据包发送方的SSRC”字段表示请求的来源，“媒体源的SSRC”未使用，应设置为0。此消息适用的媒体发件人的SSRC位于相应的FCI条目中。
The FCI field for a Payload-Specific Third-Party Loss Early Indication (PSLEI) consists one or more FCI entries. Each entry applies to a different media source, identified by its SSRC, the content of which is depicted in Figure 2. The length field in the PSLEI feedback message MUST be set to N+2, where N is the number of FCI entries.
有效负载特定第三方损失早期指示（PSLEI）的FCI字段由一个或多个FCI条目组成。每个条目适用于不同的媒体源，由其SSRC标识，其内容如图2所示。PSLEI反馈消息中的长度字段必须设置为N+2，其中N是FCI条目数。
The format is shown in Figure 2.
格式如图2所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Syntax of an FCI Entry in the PSLEI Feedback Message
图2:PSLEI反馈消息中FCI条目的语法
Synchronization source (SSRC): 32 bits
同步源（SSRC）：32位
The SSRC value of the media source that is already aware, or in the process of being made aware, that some receiver lost synchronization with the media stream and for which the PSLEI receiver's own response to any such error is suppressed.
媒体源的SSRC值，该媒体源已经意识到或正在意识到某些接收器与媒体流失去同步，并且PSLEI接收器自身对任何此类错误的响应被抑制。
The Session Description Protocol (SDP) [RFC4566] attribute, rtcp-fb, is defined in Section 4 of RFC 4585 [RFC4585] and may be used to negotiate the capability to handle specific AVPF commands and indications. The ABNF for rtcp-fb is described in Section 4.2 of RFC 4585 [RFC4585]. In this section, we extend the rtcp-fb attribute to include the commands and indications that are described for Third-Party Loss Reports in the present document.
会话描述协议（SDP）[RFC4566]属性rtcp fb在RFC 4585[RFC4585]第4节中定义，可用于协商处理特定AVPF命令和指示的能力。rtcp fb的ABNF在RFC 4585[RFC4585]第4.2节中进行了描述。在本节中，我们扩展了rtcp fb属性，以包括本文档中为第三方损失报告描述的命令和指示。
In the ABNF [RFC5234] for rtcp-fb-val defined in RFC 4585 [RFC4585], the feedback type "nack", without parameters, indicates use of the Generic NACK feedback format as defined in Section 6.2.1 of RFC 4585 [RFC4585]. In this document, we define two parameters that indicate the third-party loss supported for use with "nack", namely:
在RFC 4585[RFC4585]中定义的rtcp fb val的ABNF[RFC5234]中，无参数的反馈类型“nack”表示使用RFC 4585[RFC4585]第6.2.1节中定义的通用nack反馈格式。在本文件中，我们定义了两个参数，表示支持与“nack”一起使用的第三方损失，即：
o "tllei" denotes support of Transport-Layer Third-Party Loss Early Indication.
o “tllei”表示支持传输层第三方丢失早期指示。
o "pslei" denotes support of Payload-Specific Third-Party Loss Early Indication.
o “pslei”表示支持特定于有效载荷的第三方损失早期指示。
The ABNF for these two parameters for use with "nack" is defined here (please refer to Section 4.2 of RFC4585 [RFC4585] for complete ABNF syntax).
此处定义了与“nack”一起使用的这两个参数的ABNF（有关完整的ABNF语法，请参阅RFC4585[RFC4585]第4.2节）。
rtcp-fb-val =/ "nack" rtcp-fb-nack-param
rtcp-fb-nack-param = SP "tllei"
;Transport-Layer Third-Party
; Loss Early Indication
/ SP "pslei"
;Payload-Specific Third-Party
; Loss Early Indication
/ SP token [SP byte-string]
; for future commands/indications
token = <as defined in Section 9 of [RFC4566]>
byte-string = <as defined in Section 9 of [RFC4566]>
rtcp-fb-val =/ "nack" rtcp-fb-nack-param
rtcp-fb-nack-param = SP "tllei"
;Transport-Layer Third-Party
; Loss Early Indication
/ SP "pslei"
;Payload-Specific Third-Party
; Loss Early Indication
/ SP token [SP byte-string]
; for future commands/indications
token = <as defined in Section 9 of [RFC4566]>
byte-string = <as defined in Section 9 of [RFC4566]>
The security considerations documented in [RFC4585] are also applicable for the TPLR messages defined in this document.
[RFC4585]中记录的安全注意事项也适用于本文件中定义的TPLR消息。
More specifically, spoofed or maliciously created TPLR feedback messages cause missing RTP packets to not be repaired in a timely fashion and add risk of (undesired) feedback suppression at RTCP receivers that accept such TPLR messages. Any packet loss detected by a receiver that also receives a TPLR message for the same missing packet(s) will negatively impact the application that relies on the (timely) RTP retransmission capabilities.
更具体地说，伪造或恶意创建的TPLR反馈消息会导致丢失的RTP数据包无法及时修复，并增加接收此类TPLR消息的RTCP接收器的（不期望的）反馈抑制风险。同时接收相同丢失数据包的TPLR消息的接收器检测到的任何数据包丢失将对依赖（及时）RTP重传能力的应用程序产生负面影响。
A solution to prevent such attack with maliciously sent TPLR messages is to apply an authentication and integrity protection framework for the feedback messages. This can be accomplished using the RTP profile that combines Secure RTP [RFC3711] and AVPF into SAVPF [RFC5124].
防止恶意发送TPLR消息的此类攻击的解决方案是为反馈消息应用身份验证和完整性保护框架。这可以通过将安全RTP[RFC3711]和AVPF组合到SAVPF[RFC5124]中的RTP配置文件来实现。
Note that intermediaries that are not visible at the RTP layer that wish to send the Third-Party Loss Reports on behalf of the media source can only do so if they spoof the SSRC of the media source. This is difficult if SRTP is in use. If the intermediary is visible at the RTP layer, this is not an issue, provided the intermediary is part of the security context for the session.
请注意，在RTP层不可见的、希望代表媒体源发送第三方丢失报告的中介机构只有在欺骗媒体源的SSRC时才能这样做。如果使用SRTP，这是很困难的。如果中介体在RTP层可见，则这不是问题，前提是中介体是会话安全上下文的一部分。
Per this document, IANA has added two values to the '"ack" and "nack" Attribute Values' sub-registry [RFC4585] of the 'Session Description Protocol (SDP) Parameters' registry.
根据本文件，IANA向“会话描述协议（SDP）参数”注册表的“ack”和“nack”属性值子注册表[RFC4585]添加了两个值。
The value registration for the attribute value "nack":
属性值“nack”的值注册：
Value name: tllei Long name: Transport-Layer Third-Party Loss Early Indication Usable with: nack Reference: RFC 6642
值名称：tllei Long name:传输层第三方丢失早期指示可用于：nack参考：RFC 6642
Value name: pslei Long name: Payload-Specific Third-Party Loss Early Indication Usable with: nack Reference: RFC 6642
值名称：pslei长名称：有效负载特定的第三方损失早期指示可用于：nack参考：RFC 6642
The following value has been registered as one FMT value in the "FMT Values for RTPFB Payload Types" registry (http://www.iana.org/assignments/rtp-parameters).
以下值已在“RTPFB有效负载类型的FMT值”注册表中注册为一个FMT值(http://www.iana.org/assignments/rtp-parameters).
RTPFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
TLLEI Transport-Layer Third-Party 7 [RFC6642]
Loss Early Indication
RTPFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
TLLEI Transport-Layer Third-Party 7 [RFC6642]
Loss Early Indication
The following value has been registered as one FMT value in the "FMT Values for PSFB Payload Types" registry (http://www.iana.org/assignments/rtp-parameters).
以下值已在“PSFB有效负载类型的FMT值”注册表中注册为一个FMT值(http://www.iana.org/assignments/rtp-parameters).
PSFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
PSLEI Payload-Specific Third-Party 8 [RFC6642]
Loss Early Indication
PSFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
PSLEI Payload-Specific Third-Party 8 [RFC6642]
Loss Early Indication
The authors would like to thank David R. Oran, Magnus Westerlund, Colin Perkins, Ali C. Begen, Tom Van Caenegem, Francis Dupont, Ingemar Johansson, Bill Ver Steeg, Jonathan Lennox, and WeeSan Lee for their valuable comments and suggestions on this document.
作者感谢David R.Oran、Magnus Westerlund、Colin Perkins、Ali C.Begen、Tom Van Caenegem、Francis Dupont、Ingemar Johansson、Bill Ver Steeg、Jonathan Lennox和WeeSan Lee对本文件提出的宝贵意见和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，2008年2月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 51242008年2月。
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011.
[RFC6285]Ver Steeg，B.，Begen，A.，Van Caenegem，T.，和Z.Vax，“基于单播的多播RTP会话的快速获取”，RFC 62852011年6月。
[MONARCH] Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures for RTP", Work in Progress, May 2012.
[Monar]Wu，Q.，Hunt，G.，和P.Arden，“RTP的监控架构”，正在进行的工作，2012年5月。
[RETRANS-FOR-SSM] Van Caenegem, T., Ver Steeg, B., and A. Begen, "Retransmission for Source-Specific Multicast (SSM) Sessions", Work in Progress, May 2011.
[RETRANS-FOR-SSM]Van Caenegem，T.，Ver Steeg，B.，和A.Begen，“源特定多播（SSM）会话的重传”，正在进行的工作，2011年5月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 51172008年1月。
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006.
[RFC4587]偶数，R.，“H.261视频流的RTP有效负载格式”，RFC4587，2006年8月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 57602010年2月。
Authors' Addresses
作者地址
Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
秦武（编辑）中国江苏省南京市雨花区华为软件大道101号210012
EMail: sunseawq@huawei.com
EMail: sunseawq@huawei.com
Frank Xia Huawei 1700 Alma Dr., Suite 500 Plano, TX 75075 USA
Frank Xia华为1700阿尔玛博士，美国德克萨斯州普莱诺500号套房75075
Phone: +1 972-509-5599
EMail: xiayangsong@huawei.com
Phone: +1 972-509-5599
EMail: xiayangsong@huawei.com
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
Roni甚至华为14 David Hamelech特拉维夫64953以色列
EMail: even.roni@huawei.com
EMail: even.roni@huawei.com