Internet Engineering Task Force (IETF) L. Miniero
Request for Comments: 8079 Meetecho
Category: Standards Track S. Garcia Murillo
ISSN: 2070-1721 Medooze
V. Pascual
Oracle
February 2017
Internet Engineering Task Force (IETF) L. Miniero
Request for Comments: 8079 Meetecho
Category: Standards Track S. Garcia Murillo
ISSN: 2070-1721 Medooze
V. Pascual
Oracle
February 2017
Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)
背对背用户代理（B2BUAs）中RTP控制协议（RTCP）的端到端支持指南
Abstract
摘要
SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol (RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data.
SIP背靠背用户代理（B2BUA）通常设计为也位于媒体路径上，而不仅仅是拦截信令。这意味着B2BUA通常也实现RTP或RTP控制协议（RTCP）堆栈，从而导致B2BUA关联并桥接在一起的单独多媒体会话。如果不加以规范，这种行为可能会严重影响通信体验，尤其是当RTCP消息中包含的统计信息和反馈信息由于报告数据中的不匹配而丢失时。
This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP.
本文件定义了B2BUAs在信令平面和媒体平面上采取行动时应遵循的正确行为，以保持RTCP的端到端功能。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8079.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8079.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 4
3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Media-Aware Relay . . . . . . . . . . . . . . . . . . . . 6
3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 4
3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Media-Aware Relay . . . . . . . . . . . . . . . . . . . . 6
3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Session Initiation Protocol (SIP) [RFC3261] Back-to-Back User Agents (B2BUAs) are SIP entities that can act as a logical combination of both a User Agent Server (UAS) and a User Agent Client (UAC). As such, their behaviour is not always completely adherent to standards and can lead to unexpected situations. [RFC7092] presents a taxonomy of the most commonly deployed B2BUA implementations and describes how they differ in terms of the functionality and features they provide.
会话发起协议（SIP）[RFC3261]背对背用户代理（B2BUA）是SIP实体，可以充当用户代理服务器（UAS）和用户代理客户端（UAC）的逻辑组合。因此，他们的行为并不总是完全符合标准，并可能导致意外情况。[RFC7092]介绍了最常用的部署B2BUA实现的分类，并描述了它们在提供的功能和特性方面的差异。
Such components often do not only act on the signalling plane (intercepting and possibly modifying SIP messages), but also on the media plane. This means that, in order to receive and manage all RTP and RTCP [RFC3550] packets in a session, these components also manipulate the session descriptions [RFC4566] in the related offer/ answer exchanges [RFC3264]. The reasons for such behaviour can be different. The B2BUA may want, for instance, to provide transcoding
此类组件通常不仅作用于信令平面（拦截并可能修改SIP消息），而且作用于媒体平面。这意味着，为了接收和管理会话中的所有RTP和RTCP[RFC3550]数据包，这些组件还操纵相关提供/应答交换[RFC3264]中的会话描述[RFC4566]。这种行为的原因可能不同。例如，B2BUA可能想要提供转码
functionality for participants with incompatible codecs, or it may need the traffic to be directly handled for different reasons. This can lead to several different topologies for RTP-based communication, as documented in [RFC7667].
为具有不兼容编解码器的参与者提供的功能，或者由于不同的原因可能需要直接处理流量。如[RFC7667]中所述，这可能导致基于RTP的通信采用几种不同的拓扑结构。
Whatever the reason, such behaviour does not come without a cost. In fact, whenever a media-aware component is placed on the path between two or more participants that want to communicate by means of RTP/ RTCP, the end-to-end nature of such protocols is broken. While this may not be a problem for RTP packets, which can be quite easily relayed, it definitely can cause serious issue for RTCP messages, which carry important information and feedback on the communication quality the participants are experiencing. Consider, for instance, the simple scenario only involving two participants and a single RTP session depicted in Figure 1:
不管是什么原因，这种行为都不是没有代价的。事实上，只要将媒体感知组件放置在希望通过RTP/RTCP进行通信的两个或多个参与者之间的路径上，这种协议的端到端特性就会被打破。虽然这对于RTP数据包来说可能不是问题，因为RTP数据包很容易中继，但它肯定会导致RTCP消息出现严重问题，因为RTCP消息包含重要信息和参与者正在经历的通信质量反馈。例如，考虑仅涉及两个参与者的简单场景和图1所示的单个RTP会话：
+--------+ +---------+ +---------+
| |=== SSRC1 ===>| |=== SSRC3 ===>| |
| Alice | | B2BUA | | Bob |
| |<=== SSRC2 ===| |<=== SSRC4 ===| |
+--------+ +---------+ +---------+
+--------+ +---------+ +---------+
| |=== SSRC1 ===>| |=== SSRC3 ===>| |
| Alice | | B2BUA | | Bob |
| |<=== SSRC2 ===| |<=== SSRC4 ===| |
+--------+ +---------+ +---------+
Figure 1: B2BUA Modifying RTP Headers
图1:B2BUA修改RTP头
In this common scenario, a participant (Alice) is communicating with another participant (Bob) as a result of a signalling session managed by a B2BUA: this B2BUA is also on the media path between the two and is acting as a Media Relay. This means that two separate RTP sessions are involved (one per side), each carrying two RTP streams (one per media direction). As part of this process, the B2BUA is also rewriting some of the RTP header information on the way. In this example, just the Synchronization Source (SSRC) of the incoming RTP streams is changed, but more information may be modified as well (e.g., sequence numbers, timestamps, etc.). In particular, whenever Alice sends an RTP packet, she sets her SSRC (SSRC1) in the RTP header of her RTP source stream. The B2BUA rewrites the SSRC (SSRC3) before relaying the packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) get their SSRC rewritten as well (SSRC2) before being relayed to Alice.
在此常见场景中，参与者（Alice）通过B2BUA管理的信令会话与另一参与者（Bob）通信：该B2BUA也位于两者之间的媒体路径上，并充当媒体中继。这意味着涉及两个独立的RTP会话（每侧一个），每个会话承载两个RTP流（每媒体方向一个）。作为该过程的一部分，B2BUA还在途中重写一些RTP报头信息。在此示例中，仅更改传入RTP流的同步源（SSRC），但也可以修改更多信息（例如，序列号、时间戳等）。特别是，每当Alice发送RTP数据包时，她都会在RTP源流的RTP报头中设置她的SSRC（SSRC1）。B2BUA在将数据包转发给Bob之前重写SSRC（SSRC3）。同时，Bob（SSRC4）发送的RTP数据包在被转发到Alice之前也会被重写（SSRC2）。
Assuming now that Alice needs to inform Bob that she has lost several packets in the last few seconds, she will place the related received RTP stream SSRC she is aware of (SSRC2) together with her own (SSRC1) in RTCP Reports and/or NACKs. Since the B2BUA is making use of different SSRCs for the RTP streams in the RTP session it established with each participant, blindly relaying Alice's incoming RTCP messages to Bob would cause issues. These RTCP messages would reference SSRCs Bob doesn't know about, which would result in
假设Alice现在需要通知Bob她在过去几秒钟内丢失了几个数据包，她将把她知道的相关接收到的RTP流SSRC（SSRC2）与她自己的（SSRC1）一起放入RTCP报告和/或NACK中。由于B2BUA在与每个参与者建立的RTP会话中为RTP流使用不同的SSRC，盲目地将Alice传入的RTCP消息中继给Bob将导致问题。这些RTCP消息将引用Bob不知道的SSRC，这将导致
precious feedback being dropped. In fact, Bob is only aware of SSRC4 (the one his source RTP stream uses) and SSRC3 (the one he's receiving from the B2BUA in the received RTP stream) and knows nothing about SSRC1 and SSRC2 in the messages he received instead. Considering the feedback being dropped because of this may contain precious information (e.g., related to packet loss, congestion, and other network issues or considerations), the inability to take them into account may lead to severe issues. For instance, Bob may flood Alice with more media packets she can handle and/or not retransmit the packets she missed and asked for. This may easily lead to a very bad communication experience, if not eventually to an unwanted termination of the communication itself.
宝贵的反馈被丢弃。事实上，Bob只知道SSRC4（他的源RTP流使用的那个）和SSRC3（他在接收到的RTP流中从B2BUA接收的那个），而对他接收到的消息中的SSRC1和SSRC2一无所知。考虑到由于此原因而丢弃的反馈可能包含宝贵的信息（例如，与数据包丢失、拥塞和其他网络问题或考虑因素有关），无法考虑这些信息可能会导致严重的问题。例如，Bob可能会向Alice发送更多的媒体数据包，而Alice可以处理和/或不重新传输丢失和请求的数据包。这可能很容易导致非常糟糕的通信体验，如果不是最终导致通信本身的意外终止的话。
This is just a trivial example that, together with additional scenarios, will be addressed in the following sections. Nevertheless, it is a valid example of how such a simple mishandling of precious information may lead to serious consequences. This is especially true if we picture more complex scenarios involving several participants at the same time, multiple RTP sessions (e.g., a video stream along audio) rather than a single one, redundancy RTP streams, SSRC multiplexing, and so on. Considering how common B2BUA deployments are, it is very important for them to properly address RTCP messages in order to be sure that their activities on the media plane do not break or interfere with anything relevant to the session.
这只是一个简单的示例，下面几节将讨论它以及其他场景。然而，这是一个有效的例子，说明如此简单的对宝贵信息的错误处理可能导致严重后果。如果我们同时描绘涉及多个参与者、多个RTP会话（例如，沿音频的视频流）而不是单个RTP会话、冗余RTP流、SSRC多路复用等更复杂的场景，则情况尤其如此。考虑到B2BUA部署的普遍性，正确处理RTCP消息对于他们来说非常重要，以确保他们在媒体平面上的活动不会中断或干扰与会话相关的任何内容。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In addition, this document uses, where relevant, the RTP-related terminology defined in [RFC7656].
此外，本文件在相关情况下使用了[RFC7656]中定义的RTP相关术语。
As described in the Introduction (Section 1), it's very common for B2BUA deployments to act on the media plane rather than just on the signalling plane alone. In particular, [RFC7092] describes three different categories of such B2BUAs: (1) a simple Media Relay that is effectively unaware of anything that is transported; (2) a Media-aware Relay that inspects and/or modifies RTP and RTCP messages as they flow by; and (3) a full-fledged media termination entity that terminates and generates RTP and RTCP messages as needed.
如引言（第1节）所述，B2BUA部署通常在媒体平面上进行，而不仅仅是在信令平面上。具体而言，[RFC7092]描述了三种不同类别的B2BUA：（1）一种简单的媒体中继，实际上不知道传输的任何内容；（2） 媒体感知中继，在RTP和RTCP消息经过时检查和/或修改它们；（3）根据需要终止并生成RTP和RTCP消息的成熟媒体终止实体。
[RFC3550] and [RFC7667] already mandate some specific behaviours in the presence of certain topologies. However, due to their mixed nature, B2BUAs sometimes can't or won't implement all relevant specifications. This means that it's not rare to encounter issues that may be avoided with more disciplined behaviour in that regard, that is, if the B2BUAs followed at least a set of guidelines to ensure no known problems occur. For this reason, the following subsections describe the proper behaviour that B2BUAs, whatever above category they fall in, should follow in order not to impact any end-to-end RTCP effectiveness.
[RFC3550]和[RFC7667]已经规定了某些拓扑中的某些特定行为。然而，由于其混合性质，B2BUAs有时不能或不会实现所有相关规范。这意味着，在这方面，如果B2BUA至少遵循了一套指导原则以确保不发生已知问题，那么遇到可以通过更严格的行为避免的问题并不罕见。因此，以下小节描述了B2BUA应遵循的适当行为，无论其属于何种上述类别，以免影响任何端到端RTCP的有效性。
A Media Relay, as identified in [RFC7092], simply forwards all RTP and RTCP messages it receives without either inspecting or modifying them. Using the terminology in "RTP Topologies" [RFC7667], this can be seen as an RTP Transport Translator. As such, B2BUAs acting as Media Relays are not aware of what traffic they're handling. This means that both packet payloads and packet headers are opaque to them. Many Session Border Controllers (SBCs) implement this kind of behaviour, e.g., when acting as a bridge between an inner and outer network.
[RFC7092]中标识的媒体中继只转发它接收的所有RTP和RTCP消息，而不检查或修改它们。使用“RTP拓扑”[RFC7667]中的术语，可以将其视为RTP传输转换器。因此，作为媒体中继的B2BUA不知道他们正在处理什么流量。这意味着数据包有效负载和数据包头对它们来说都是不透明的。许多会话边界控制器（SBC）实现这种行为，例如，当充当内部和外部网络之间的桥梁时。
Considering that all headers and identifiers in both RTP and RTCP are left untouched, issues like the SSRC mismatch described in the previous section would not occur. However, similar problems could still happen for different reasons, for instance, if the session description prepared by the B2BUA, whether it has been modified or not, ends up providing incorrect information. This may happen, for example, if the Session Description Protocol (SDP) on either side contains 'ssrc' [RFC5576] attributes that don't match the actual SSRC being advertised on the media plane or if the B2BUA advertised support for NACK because it implements it while the original INVITE didn't. Such issues might occur, for instance, when the B2BUA acting as a Media Relay is generating a new session description when bridging an incoming call rather than using the original session description. This may cause participants to find a mismatch between the SSRCs advertised in the SDP and the ones actually observed in RTP and RTCP messages or to have them either ignore or generate RTCP feedback packets that were not explicitly advertised as supported.
考虑到RTP和RTCP中的所有头和标识符都保持不变，不会出现上一节中描述的SSRC不匹配等问题。然而，由于不同的原因，类似的问题仍然可能发生，例如，如果B2BUA准备的会话描述（无论是否已修改）最终提供了不正确的信息。例如，如果任何一方的会话描述协议（SDP）包含与媒体平面上播发的实际ssrc不匹配的“ssrc”[RFC5576]属性，或者如果B2BUA播发了对NACK的支持，因为它实现了NACK，而原始INVITE没有。例如，当充当媒体中继的B2BUA在桥接传入呼叫而不是使用原始会话描述时生成新会话描述时，可能会发生这样的问题。这可能会导致参与者发现SDP中公布的SSRC与RTP和RTCP消息中实际观察到的SSRC不匹配，或者让他们忽略或生成未明确公布为受支持的RTCP反馈数据包。
In order to prevent such an issue, a Media Relay B2BUA SHOULD forward all the SSRC- and RTCP-related SDP attributes when handling a multimedia session setup between participants: this includes attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-attrib' [RFC3611], and others. However, certain SDP attributes may lead to call failures when forwarded by a Media Relay, as they have an implied assumption that the attribute describes the immediate
为了防止此类问题，媒体中继B2BUA在处理参与者之间的多媒体会话设置时应转发所有与SSRC和RTCP相关的SDP属性：这包括诸如“SSRC”[RFC3261]、“RTCP fb”[RFC4585]、“RTCP xr attrib”[RFC3611]等属性。但是，某些SDP属性在由媒体中继转发时可能会导致呼叫失败，因为它们隐含着这样一种假设，即该属性描述即时消息
peer. A clear example of this is the 'rtcp' [RFC3605] attribute, which describes the expected RTCP peer port. Other attributes might include the immediate peer's IP address, preferred transport, etc. In general, the guideline is to require rewriting of attributes that are implicitly describing the immediate peer. B2BUAs SHOULD forward all other SDP attributes in order to avoid breaking additional functionality that endpoints may be relying on. If implementors have doubts about whether this guidance applies to a specific attribute, they should test to determine if call failures occur.
同龄人一个明显的例子是“rtcp”[RFC3605]属性，它描述了预期的rtcp对等端口。其他属性可能包括直接对等方的IP地址、首选传输等。一般来说，指南要求重写隐式描述直接对等方的属性。B2BUAs应转发所有其他SDP属性，以避免破坏端点可能依赖的其他功能。如果实现者对本指南是否适用于特定属性有疑问，他们应该进行测试以确定是否发生调用失败。
The cited 'rtcp' example is also relevant whenever RTP/RTCP multiplexing [RFC5761] support is being negotiated. If the B2BUA acting as a Media Relay is unaware of the specifics of the traffic it is handling, and as such may not have RTP/RTCP parsing capabilities, it SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP attribute. If instead the Media Relay is able to parse RTP/RTCP, and can verify that demultiplexing can be performed without any RTP Payload Type rewrites (i.e., no overlap between any RTP Payload Types and the RTCP Payload Type space has been detected), then the B2BUA SHOULD negotiate RTP/RTCP multiplexing support if advertised.
每当正在协商RTP/rtcp多路复用[RFC5761]支持时，所引用的“rtcp”示例也是相关的。如果充当媒体中继的B2BUA不知道其正在处理的流量的具体情况，因此可能没有RTP/RTCP解析功能，则应通过删除“RTCP mux”SDP属性来拒绝RTP/RTCP多路复用。相反，如果媒体中继能够解析RTP/RTCP，并且能够验证在没有任何RTP有效负载类型重写的情况下可以执行解复用（即，未检测到任何RTP有效负载类型和RTCP有效负载类型空间之间的重叠），则B2BUA应协商RTP/RTCP复用支持（如果公布）。
It is worth mentioning that, by leaving RTCP messages untouched, a Media Relay may also leak information that, according to policies, may need to be hidden or masqueraded, e.g., domain names in CNAME items. Besides, these CNAME items may actually contain IP addresses: this means that, should a NAT be involved in the communication, this may actually result in CNAME collisions, which could indeed break the end-to-end RTCP behaviour. While [RFC7022] can prevent this from happening, there may be implementations that don't make use of it. As such, a B2BUA MAY rewrite CNAME items if any potential collision is detected, even in the Media Relay case. If a B2BUA does indeed decide to rewrite CNAME items, then it MUST generate new CNAMEs following [RFC7022]. The same SHOULD be done if RTP extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]). If that is not possible, e.g., because the Media Relay does not have RTP header editing capabilities or does not support these extensions, then the B2BUA MUST reject the negotiation of such extensions when negotiating the session.
值得一提的是，通过保持RTCP消息不变，媒体中继还可能泄漏根据策略可能需要隐藏或伪装的信息，例如CNAME项目中的域名。此外，这些CNAME项目实际上可能包含IP地址：这意味着，如果通信中涉及NAT，这实际上可能会导致CNAME冲突，这确实可能会破坏端到端RTCP行为。虽然[RFC7022]可以防止这种情况发生，但可能有一些实现没有利用它。因此，即使在媒体中继情况下，如果检测到任何潜在冲突，B2BUA也可以重写CNAME项。如果B2BUA确实决定重写CNAME项，那么它必须按照[RFC7022]生成新的CNAME。如果涉及涉及cname的RTP扩展（例如，“urn:ietf:params:RTP hdrext:sdes:cname”[RFC7941]），也应该这样做。如果这是不可能的，例如，因为媒体中继不具有RTP报头编辑功能或不支持这些扩展，那么B2BUA在协商会话时必须拒绝此类扩展的协商。
A Media-aware Relay, unlike the Media Relay addressed in the previous section, is aware of the media traffic it is handling. This means it inspects RTP and RTCP messages flowing by and may even modify their headers. Using the terminology in [RFC3550], this can be seen as an RTP Translator. A B2BUA implementing this role typically does not inspect the RTP payloads, which would be opaque to them: this means that the actual media would not be manipulated (e.g., transcoded).
与上一节中介绍的媒体中继不同，媒体感知中继可以感知它正在处理的媒体流量。这意味着它检查流经的RTP和RTCP消息，甚至可能修改它们的头。使用[RFC3550]中的术语，可以将其视为RTP转换器。实现此角色的B2BUA通常不检查RTP有效负载，这对它们来说是不透明的：这意味着不会操纵实际介质（例如，转码）。
This makes them quite different from the Media Relays previously discussed, especially in terms of the potential issues that may occur at the RTCP level. In fact, being able to modify the RTP and RTCP headers, such B2BUAs may end up modifying RTP-related information like SSRC / Contributing Source (CSRC), sequence numbers, timestamps, and others in an RTP stream before forwarding the modified packets to the other interested participants. This means that, if not properly disciplined, such behaviour may easily lead to issues like the one described in the introductory section. For this reason, it is very important for a B2BUA modifying RTP-related information across two related RTP streams to also modify, in a coherent way, the same information in RTCP messages.
这使得它们与前面讨论的媒体中继完全不同，特别是在RTCP级别可能出现的潜在问题方面。事实上，由于能够修改RTP和RTCP报头，在将修改后的分组转发给其他感兴趣的参与者之前，诸如b2bua可能最终修改RTP流中的RTP相关信息，例如SSRC/贡献源（csc）、序列号、时间戳等。这意味着，如果没有适当的约束，这种行为可能很容易导致导言部分所述的问题。因此，B2BUA在两个相关RTP流之间修改RTP相关信息时，以一致的方式修改RTCP消息中的相同信息非常重要。
It is worthwhile to point out that such a B2BUA may not necessarily forward all the packets it receives. Selective Forwarding Units (SFUs) [RFC7667], for instance, may be implemented to aggregate or drop incoming RTCP messages while at the same time originating new ones on their own. It is important to clarify that a B2BUA SHOULD NOT randomly drop or forward RTCP feedback of the same type (e.g., a specific XR block type or specific Feedback messages) within the context of the same session as that may lead to confusing, if not broken, feedback to the recipients of the message due to gaps in the communication. As to the messages that are forwarded and/or aggregated, it's important to make sure the information is coherent.
值得指出的是，这样的B2BUA不一定转发它接收的所有分组。例如，可以实现选择性转发单元（SFU）[RFC7667]来聚合或丢弃传入的RTCP消息，同时自己发起新的RTCP消息。重要的是要澄清，B2BUA不应在同一会话的上下文中随机丢弃或转发相同类型的RTCP反馈（例如，特定XR块类型或特定反馈消息），因为这可能会由于通信中的间隙而导致对消息接收者的反馈混淆（如果没有中断）。对于转发和/或聚合的消息，确保信息一致性很重要。
Besides the behaviour already mandated for RTCP translators in Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming RTCP messages to forward following these guidelines:
除了[RFC3550]第7.2节中规定的RTCP翻译人员的行为外，媒体感知B2BUA必须按照以下指南处理传入的RTCP消息：
Sender Report (SR) [RFC3550]: If the B2BUA has changed the SSRC of the sender RTP stream a Sender Report refers to, it MUST update the SSRC in the SR packet header as well. If the B2BUA has changed the SSRCs of other RTP streams too, and any of these streams are addressed in any of the SR Report Blocks, it MUST update the related values in the SR Report Blocks as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change MUST be reflected in the 'extended highest sequence number received' field in the Report Blocks. In case the B2BUA is acting as a Selective Forwarding Unit (SFU) [RFC7667], it needs to track in the outgoing SR, the relevant number of packets sent, and the total amount of bytes sent to the receiver.
发送方报告（SR）[RFC3550]：如果B2BUA更改了发送方报告引用的发送方RTP流的SSRC，则它还必须更新SR数据包头中的SSRC。如果B2BUA也更改了其他RTP流的SSRC，并且这些流中的任何一个在任何SR报告块中寻址，则B2BUA还必须更新SR报告块中的相关值。如果B2BUA在转发RTP数据包时也更改了基本RTP序列号，则此更改必须反映在报告块中的“已接收的扩展最高序列号”字段中。在B2BUA充当选择性转发单元（SFU）[RFC7667]的情况下，它需要跟踪传出SR、发送的相关数据包数量以及发送到接收器的总字节数。
Receiver Report (RR) [RFC3550]: The guidelines for SR apply to RR as well.
接收方报告（RR）[RFC3550]：SR指南也适用于RR。
Source Description (SDES) [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in any of the chunks of an incoming SDES message, it MUST update the related SSRCs in all the chunks. The same considerations made with respect to CNAME collisions at the end of Section 3.1 apply here as well.
源描述（SDES）[RFC3550]：如果B2BUA已更改传入SDES消息的任何区块中寻址的任何RTP流的SSRC，则必须更新所有区块中的相关SSRC。第3.1节末尾关于CNAME冲突的相同考虑也适用于此处。
BYE [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in the SSRC/CSRC identifiers included in a BYE packet, it MUST update them in the message.
BYE[RFC3550]：如果B2BUA更改了BYE数据包中包含的SSRC/CSC标识符中寻址的任何RTP流的SSRC，则必须在消息中对其进行更新。
APP [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in the header of an APP packet, it MUST update the identifier in the message. Should the B2BUA be aware of any specific APP message format that contains additional information related to SSRCs, it SHOULD update them accordingly as well.
APP[RFC3550]：如果B2BUA更改了APP数据包报头中寻址的任何RTP流的SSRC，则必须更新消息中的标识符。如果B2BUA知道任何特定的应用程序消息格式包含与SSRC相关的附加信息，则B2BUA也应相应地更新它们。
Extended Reports (XRs) [RFC3611]: If the B2BUA has changed the SSRC of the RTP stream associated with the originator of an XR packet, it MUST update the SSRC in the XR message header. The same guidelines given for SR/RR, with respect to SSRC identifiers in Report Blocks, apply to all the Report Block types in the XR message as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change MUST be reflected in the 'begin_seq' and 'end_seq' fields that are available in most of the Report Block types that are part of the XR specification.
扩展报告（XRs）[RFC3611]：如果B2BUA已更改与XR数据包的发起人关联的RTP流的SSRC，则必须更新XR消息头中的SSRC。关于报告块中的SSRC标识符，为SR/RR提供的相同准则也适用于XR消息中的所有报告块类型。如果B2BUA在转发RTP数据包时也更改了基本RTP序列号，则此更改必须反映在作为XR规范一部分的大多数报告块类型中可用的“开始顺序”和“结束顺序”字段中。
Receiver Summary Information (RSI) [RFC5760]: If the B2BUA has changed any SSRC of RTP streams addressed in an RSI packet, it MUST update the SSRC identifiers in the message. This includes the distribution source SSRC, which MUST be rewritten with the one the B2BUA uses to send RTP packets to each sender participant, the summarized SSRC, and when a Collision Sub-Report Block is available, the SSRCs in the related list.
接收器摘要信息（RSI）[RFC5760]：如果B2BUA已更改RSI数据包中寻址的RTP流的任何SSRC，则必须更新消息中的SSRC标识符。这包括分发源SSRC，必须使用B2BUA用于向每个发送方参与者发送RTP数据包的SSRC（汇总的SSRC）重写，并且当冲突子报告块可用时，相关列表中的SSRC。
Port Mapping (TOKEN) [RFC6284]: If the B2BUA has changed any SSRC of RTP streams addressed in a TOKEN packet, it MUST update the SSRC identifiers in the message. This includes the Packet Sender SSRC, which MUST be rewritten with the one the B2BUA uses to send RTP packets to each sender participant, and the Requesting Client SSRC when the message is a response, which MUST be rewritten using the related sender participant(s) SSRC.
端口映射（令牌）[RFC6284]：如果B2BUA已更改令牌数据包中寻址的RTP流的任何SSRC，则必须更新消息中的SSRC标识符。这包括数据包发送方SSRC（必须使用B2BUA用于向每个发送方参与者发送RTP数据包的SSRC进行重写），以及当消息是响应时的请求客户端SSRC（必须使用相关发送方参与者SSRC进行重写）。
Feedback Messages [RFC4585]: All Feedback messages have a common packet format, which includes the SSRC identifier of the Packet Sender and the SSRC identifier of the media source the feedback is related to. Just as described for the previous messages, these SSRC identifiers MUST be updated in the message if the B2BUA has changed the SSRC of the RTP streams addressed there. It MUST NOT, however, change a media source SSRC that was originally set to zero, unless zero is actually the SSRC that was chosen by one of the involved endpoints, in which case the above-mentioned rules as to SSRC rewriting apply. Considering that many Feedback messages also include additional data as part of their specific Feedback Control Information (FCI), a media-aware B2BUA MUST take care of them accordingly, if it can parse and regenerate them, according to the following guidelines:
反馈消息[RFC4585]：所有反馈消息都有一个通用的数据包格式，包括数据包发送方的SSRC标识符和反馈相关媒体源的SSRC标识符。正如前面的消息所述，如果B2BUA已经更改了在那里寻址的RTP流的SSRC，则必须在消息中更新这些SSRC标识符。但是，不得更改最初设置为零的媒体源SSRC，除非零实际上是由一个相关端点选择的SSRC，在这种情况下，上述SSRC重写规则适用。考虑到许多反馈消息还包括作为其特定反馈控制信息（FCI）一部分的附加数据，媒体感知B2BUA必须根据以下准则相应地处理这些信息，如果它能够解析和重新生成这些信息：
NACK [RFC4585]: A media-aware B2BUA MUST properly rewrite the Packet ID (PID) of all addressed lost packets in the NACK FCI if it changed the RTP sequence numbers.
NACK[RFC4585]：如果媒体感知B2BUA更改RTP序列号，则必须正确重写NACK FCI中所有已寻址丢失数据包的数据包ID（PID）。
TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM [RFC5104]: A media-aware B2BUA MUST properly rewrite the additional SSRC identifier in the specific FCI if it changed the related RTP SSRC of the media sender.
TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM[RFC5104]：如果媒体感知B2BUA更改了媒体发送器的相关RTP SSRC，则必须在特定FCI中正确重写附加SSRC标识符。
Receiver Estimated Max Bitrate (REMB) [RTCP-REMB]: [RTCP-REMB] describes an RTCP payload-specific Feedback message that reports the receiver's available bandwidth to the sender. As of the time of this writing, REMB has been widely deployed but has not been standardized. The REMB mechanism will not function correctly across a media-aware B2BUA that changes the SSRC of the media sender unless it also changes the SSRC values in the REMB packet.
接收机估计最大比特率（REMB）[RTCP-REMB]：[RTCP-REMB]描述一条RTCP有效负载特定的反馈消息，该消息向发送方报告接收机的可用带宽。截至撰写本文之时，REMB已被广泛部署，但尚未标准化。REMB机制将无法在改变媒体发送方SSRC的媒体感知B2BUA中正常工作，除非它也改变REMB数据包中的SSRC值。
Explicit Congestion Notification (ECN) [RFC6679]: The same guidelines given for SR/RR management apply, considering the presence of sequence numbers in the ECN Feedback Report format. For the management of RTCP XR ECN Summary Report messages, the same guidelines given for generic XR messages apply.
显式拥塞通知（ECN）[RFC6679]：考虑到ECN反馈报告格式中存在序列号，适用于SR/RR管理的相同指南。对于RTCP XR ECN摘要报告消息的管理，适用于通用XR消息的相同指南。
Apart from the generic guidelines related to Feedback messages, no additional modifications are needed for Picture Loss Indication (PLI), Slice Lost Indication (SLI), and Reference Picture Selection Indication (RPSI) Feedback messages.
除了与反馈信息相关的通用指南外，无需对图片丢失指示（PLI）、切片丢失指示（SLI）和参考图片选择指示（RPSI）反馈信息进行额外修改。
Of course, the same considerations about the need for SDP and RTP/ RTCP information to be coherent applies to media-aware B2BUAs. This means that, if a B2BUA changes any SSRC, it MUST update the related 'ssrc' attributes, if present, before sending it to the recipient. Besides, it MUST rewrite the 'rtcp' attribute if provided. At the same time, while a media-aware B2BUA is typically able to inspect/ modify RTCP messages, it may not support all RTCP messages. This means that a B2BUA may choose to drop RTCP messages it can't parse. In that case, a media-aware B2BUA MUST advertise its RTCP level of support in the SDP in a coherent way in order to prevent, for instance, a UAC from sending NACK messages that would never reach the intended recipients. It's important to point out that, in case a compound RTCP packet was received and any RTCP message in it needs to be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP packet, but only the selected messages.
当然，关于SDP和RTP/RTCP信息需要一致性的考虑同样适用于媒体感知B2BUA。这意味着，如果B2BUA更改了任何SSRC，则必须在将其发送给收件人之前更新相关的“SSRC”属性（如果存在）。此外，如果提供，它必须重写“rtcp”属性。同时，虽然媒体感知B2BUA通常能够检查/修改RTCP消息，但它可能不支持所有RTCP消息。这意味着B2BUA可以选择删除它无法解析的RTCP消息。在这种情况下，媒体感知B2BUA必须以一致的方式在SDP中公布其RTCP支持级别，以防止（例如）UAC发送永远无法到达预期收件人的NACK消息。需要指出的是，如果接收到复合RTCP数据包且其中的任何RTCP消息需要丢弃，则B2BUA不应丢弃整个复合RTCP数据包，而应仅丢弃选定的消息。
The same considerations on CNAMEs made in regard to Media Relays apply to Media-aware Relays as well. Specifically, if RTP extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]) and negotiated because the B2BUA supports them, then the B2BUA MUST update the CNAME value in there as well, if it was changed. It is worth pointing out that, if the new CNAME is larger than the old one, this would result in a larger RTP packet than originally received. If the length of the updated packet exceeds the MTU of any of the networks the packet will traverse, this can result in the packet being dropped and lost by the recipient.
关于媒体继电器的CNAMEs考虑同样适用于媒体感知继电器。具体地说，如果涉及涉及cname的RTP扩展（例如，“urn:ietf:params:RTP hdrext:sdes:cname”[RFC7941]），并且由于B2BUA支持这些扩展而进行协商，那么B2BUA也必须更新其中的cname值（如果更改了）。值得指出的是，如果新的CNAME比旧的CNAME大，这将导致比最初接收到的RTP数据包更大。如果更新的数据包的长度超过数据包将穿越的任何网络的MTU，这可能导致数据包被接收方丢弃和丢失。
A different set of considerations is worthwhile for RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506]. While the former allows for a better management of network resources by multiplexing RTP packets and RTCP messages over the same transport, the latter allows for a compression of RTCP messages, thus leading to less network traffic. For RTP/RTCP multiplexing, a B2BUA acting as a Media Relay may use it on either RTP session independently. This means that, for instance, a Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the communication and not use it on the other side, if the endpoint does not support it. This allows for a better management of network resources on the side that does support it. In case any of the parties in the communications supports it and the B2BUA does too, the related 'rtcp-mux' SDP attribute MUST be forwarded on the other side(s). If the B2BUA detects that any of the parties in the communication do not support the feature, it may decide to either disable it entirely or still advertise it for the RTP sessions with parties that do support it. In case the B2BUA decides to involve RTP/RTCP multiplexing, it MUST ensure that there are no conflicting RTP Payload Type numbers on either side. When there are, it MUST rewrite RTP Payload Type numbers to prevent
对于RTP/RTCP多路复用[RFC5761]和减小尺寸的RTCP[RFC5506]，有一组不同的注意事项是值得考虑的。前者允许通过在同一传输上多路复用RTP数据包和RTCP消息来更好地管理网络资源，后者允许压缩RTCP消息，从而减少网络流量。对于RTP/RTCP多路复用，作为媒体中继的B2BUA可以在任一RTP会话上独立使用它。这意味着，例如，如果端点不支持，媒体中继B2BUA可以在通信的一侧使用RTP/RTCP多路复用，而在另一侧不使用它。这允许更好地管理支持它的网络资源。如果通信中的任何一方支持，且B2BUA也支持，则必须在另一端转发相关的“rtcp mux”SDP属性。如果B2BUA检测到通信中的任何一方不支持该特性，则B2BUA可以决定完全禁用该特性，或者仍然为与确实支持该特性的各方的RTP会话播发该特性。如果B2BUA决定涉及RTP/RTCP多路复用，则必须确保任何一方都没有冲突的RTP有效负载类型号。如果存在，则必须重写RTP有效负载类型编号，以防止
conflicts in the session where the RTP/RTCP multiplexing is applied. Should RTP Payload Types be rewritten, the related information in the SDP MUST be updated accordingly.
应用RTP/RTCP多路复用的会话中存在冲突。如果要重写RTP有效负载类型，则必须相应地更新SDP中的相关信息。
For Reduced-Size RTCP, the considerations are a bit different. In fact, while a Media Relay B2BUA may choose to use it on the side that supports it and not on the side that doesn't, there are several reasons for discouraging such behaviour. While Reduced-Size allows for less network traffic related to RTCP messaging in general, this gain may lead a Reduced-Size RTCP implementation to also issue a higher rate of RTCP Feedback messages. This would result in increased RTCP traffic on the side that does not support Reduced-Size and could, as a consequence, actually be counterproductive if the available bandwidth is different on the two sides. Negotiating a session with both sides would allow the B2BUA to discover which one supports Reduced-Size and which doesn't and decide whether or not to allow the sides to independently use Reduced-Size. Should the B2BUA decide to disable the feature on all sides, which is suggested in case Reduced-Size is not supported by all parties involved, it MUST NOT advertise support for the Reduced-Size RTCP functionality on either side, by removing the 'rtcp-rsize' attribute from the SDP.
对于较小的RTCP，考虑因素有点不同。事实上，虽然媒体中继B2BUA可能会选择在支持它的一方而不是不支持它的一方使用它，但有几个理由阻止这种行为。虽然减小的大小通常允许减少与RTCP消息相关的网络通信量，但这一增益可能会导致减小的RTCP实现也会发出更高速率的RTCP反馈消息。这将导致不支持缩减大小的一侧的RTCP通信量增加，因此，如果两侧的可用带宽不同，则实际上可能适得其反。与双方协商会议将允许B2BUA发现哪一方支持缩小尺寸，哪一方不支持缩小尺寸，并决定是否允许双方独立使用缩小尺寸。如果B2BUA决定在所有方面禁用该功能（如果所有相关方均不支持缩小尺寸），则不得通过从SDP中删除“RTCP rsize”属性，在任何方面公布对缩小尺寸RTCP功能的支持。
A Media Terminator B2BUA, unlike simple Media Relays and media-aware ones, is able to terminate media itself. As such, it can inspect and/or modify RTP payloads as well. This means that such components, for instance, can act as media transcoders and/or originate specific RTP media. Using the terminology in "RTP Topologies" [RFC7667], this can be seen as an RTP Media Translator. Such a topology can also be seen as a back-to-back RTP session through a middlebox, as described in Section 3.2.2 of [RFC7667]. Such a capability makes them quite different from the previously introduced B2BUA typologies. Since such a B2BUA would terminate RTP itself, it can take care of the related statistics and feedback functionality directly, with no need to simply relay any message between the participants in the multimedia session.
与简单的媒体中继和媒体感知中继不同，媒体终止器B2BUA能够终止媒体本身。因此，它也可以检查和/或修改RTP有效载荷。这意味着，例如，这些组件可以充当媒体转码器和/或发起特定的RTP媒体。使用“RTP拓扑”[RFC7667]中的术语，可以将其视为RTP媒体转换器。如[RFC7667]第3.2.2节所述，这种拓扑结构也可以看作是通过中间盒的背对背RTP会话。这样的功能使它们与之前引入的B2BUA类型截然不同。由于这样的B2BUA将终止RTP本身，因此它可以直接处理相关的统计和反馈功能，而不需要在多媒体会话的参与者之间简单地中继任何消息。
For this reason, no specific guideline is needed to ensure a proper end-to-end RTCP behaviour in such scenarios, because most of the time, there would be no end-to-end RTCP interaction among the involved participants in the first place. Nevertheless, should any RTCP message actually need to be forwarded to another participant in the multimedia session, the same guidelines provided for the media-aware B2BUA case apply.
因此，无需特定指南来确保此类场景中的端到端RTCP行为正确，因为大多数情况下，相关参与者之间首先不存在端到端RTCP交互。然而，如果任何RTCP消息实际上需要转发给多媒体会话中的另一参与者，则适用为媒体感知B2BUA案例提供的相同指南。
For RTP/RTCP multiplexing support, the same considerations already given for the Media Relay management also apply to Media Terminators.
对于RTP/RTCP多路复用支持，已经为媒体中继管理给出的相同注意事项也适用于媒体终端。
Some different considerations might be given as to the Reduced-Size RTCP functionality instead. In fact, in the Media Terminator case, it is safe to use the feature independently on each side, as the B2BUA would terminate RTCP. In that case, the B2BUA SHOULD advertise and negotiate support for Reduced-Size if available and MUST NOT otherwise.
对于减小的RTCP功能，可能会给出一些不同的考虑。事实上，在介质终止器的情况下，在每侧独立使用该功能是安全的，因为B2BUA将终止RTCP。在这种情况下，B2BUA应宣传并协商对缩小尺寸的支持（如有），不得以其他方式。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
The discussion in the previous sections on the management of RTCP messages by a B2BUA worked under the assumption that the B2BUA has actual access to the RTP/RTCP information itself. This is indeed true if we assume that plain RTP and RTCP are being handled, but they may not be once any security is enforced on RTP packets and RTCP messages by means of Secure RTP (SRTP) [RFC3711].
前几节中关于B2BUA管理RTCP消息的讨论是在假设B2BUA能够实际访问RTP/RTCP信息本身的情况下进行的。如果我们假设正在处理普通RTP和RTCP，则这确实是正确的，但一旦通过安全RTP（SRTP）[RFC3711]对RTP数据包和RTCP消息实施了任何安全性，则它们可能不会被处理。
While typically not an issue in the Media Relay case, where RTP and RTCP packets are forwarded without any modification regardless of whether or not security is involved, this could definitely have an impact on Media-aware Relays and Media Terminator B2BUAs. As simple example, if we envisage an SRTP / Secure RTCP (SRTCP) session across a B2BUA where the B2BUA itself has no access to the keys used to secure the session, there would be no way to manipulate SRTP headers without violating the hashing on the packet. At the same time, there would be no way to rewrite the RTCP information accordingly either.
虽然在媒体中继情况下通常不是问题，其中RTP和RTCP数据包在不进行任何修改的情况下转发，无论是否涉及安全性，但这肯定会对媒体感知中继和媒体终止器B2BUAs产生影响。举个简单的例子，如果我们设想一个跨B2BUA的SRTP/Secure RTCP（SRTCP）会话，其中B2BUA本身无法访问用于保护会话的密钥，那么在不违反数据包哈希的情况下，将无法操作SRTP头。同时，也无法相应地重写RTCP信息。
For this reason, it is important to point out that the operations described in the previous sections are only possible if the B2BUA has a way to effectively manipulate the packets and messages flowing by. This means that, when media security is involved, only the Media Relay scenario can be properly addressed. Attempting to cover Media-aware Relay and Media Termination scenarios when involving secure sessions will inevitably lead to the B2BUA acting as a man in the middle; consequently, its behaviour is unspecified and discouraged. More considerations on this are provided in [RFC7879].
因此，重要的是要指出，只有当B2BUA具有有效地操纵经过的分组和消息的方式时，前面部分中描述的操作才是可能的。这意味着，当涉及媒体安全时，只有媒体中继场景才能得到正确解决。当涉及安全会话时，试图覆盖媒体感知的中继和媒体终止场景将不可避免地导致B2BUA充当中间人；因此，它的行为是不明确和不受鼓励的。[RFC7879]中提供了有关这方面的更多注意事项。
It is also worth pointing out that there are scenarios where an improper management of RTCP messaging across a B2BUA may lead, willingly or not, to situations not unlike an attack. As a simple example, improper management of an REMB Feedback message containing, e.g., information on the limited bandwidth availability for a user, may lead to missing or misleading information to its peer. This may cause the peer to increase the encoder bitrate, maybe up to a point where a user with poor connectivity will inevitably be choked by an
还值得指出的是，在某些情况下，跨B2BUA对RTCP消息的不当管理可能会导致（自愿或不自愿）类似于攻击的情况。作为一个简单的例子，对包含例如关于用户的有限带宽可用性的信息的REMB反馈消息的不当管理可能导致对其对等方的信息丢失或误导。这可能会导致对等方增加编码器比特率，可能会导致连接不良的用户不可避免地被编码器阻塞
amount of data it cannot process. This scenario may thus result in what looks like a Denial-of-Service (DoS) attack towards the user.
无法处理的数据量。这种情况可能导致对用户的拒绝服务（DoS）攻击。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，DOI 10.17487/RFC36112003年11月<http://www.rfc-editor.org/info/rfc3611>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[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, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，DOI 10.17487/RFC5104，2008年2月<http://www.rfc-editor.org/info/rfc5104>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5506]Johansson，I.和M.Westerlund，“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”，RFC 5506，DOI 10.17487/RFC5506，2009年4月<http://www.rfc-editor.org/info/rfc5506>.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, February 2010, <http://www.rfc-editor.org/info/rfc5760>.
[RFC5760]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 5760，DOI 10.17487/RFC5760，2010年2月<http://www.rfc-editor.org/info/rfc5760>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路复用RTP数据和控制数据包”，RFC 5761，DOI 10.17487/RFC5761，2010年4月<http://www.rfc-editor.org/info/rfc5761>.
[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, DOI 10.17487/RFC6284, June 2011, <http://www.rfc-editor.org/info/rfc6284>.
[RFC6284]Begen，A.，Wing，D.，和T.Van Caenegem，“单播和多播RTP会话之间的端口映射”，RFC 6284，DOI 10.17487/RFC6284，2011年6月<http://www.rfc-editor.org/info/rfc6284>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679]Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，RFC 6679，DOI 10.17487/RFC66792012年8月<http://www.rfc-editor.org/info/rfc6679>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7022]Begen，A.，Perkins，C.，Wing，D.，和E.Rescorla，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 7022，DOI 10.17487/RFC7022，2013年9月<http://www.rfc-editor.org/info/rfc7022>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<http://www.rfc-editor.org/info/rfc7656>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, August 2016, <http://www.rfc-editor.org/info/rfc7941>.
[RFC7941]Westerlund，M.，Burman，B.，Even，R.，和M.Zanaty，“RTP控制协议（RTCP）源描述项的RTP头扩展”，RFC 7941，DOI 10.17487/RFC79412016年8月<http://www.rfc-editor.org/info/rfc7941>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <http://www.rfc-editor.org/info/rfc3605>.
[RFC3605]Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC 3605，DOI 10.17487/RFC3605，2003年10月<http://www.rfc-editor.org/info/rfc3605>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 5576，DOI 10.17487/RFC5576，2009年6月<http://www.rfc-editor.org/info/rfc5576>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>.
[RFC7092]Kaplan，H.和V.Pascual，“会话启动协议（SIP）背对背用户代理的分类”，RFC 7092，DOI 10.17487/RFC7092，2013年12月<http://www.rfc-editor.org/info/rfc7092>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.
[RFC7667]Westerlund，M.和S.Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 7667，DOI 10.17487/RFC7667，2015年11月<http://www.rfc-editor.org/info/rfc7667>.
[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, <http://www.rfc-editor.org/info/rfc7879>.
[RFC7879]Ravindranath，R.，Reddy，T.，Salgueiro，G.，Pascual，V.，和P.Ravindran，“SIP背靠背用户代理中的DTLS-SRTP处理”，RFC 7879，DOI 10.17487/RFC7879，2016年5月<http://www.rfc-editor.org/info/rfc7879>.
[RTCP-REMB] Alvestrand, H., Ed., "RTCP message for Receiver Estimated Maximum Bitrate", Work in Progress, draft-alvestrand-rmcat-remb-03, October 2013.
[RTCP-REMB]Alvestrand，H.，Ed.，“接收机估计最大比特率的RTCP消息”，正在进行的工作，草稿-Alvestrand-rmcat-REMB-032013年10月。
Acknowledgements
致谢
The authors would like to thank Flavio Battimo and Pierluigi Palma for their invaluable feedback in the early stages of this document. The authors would also like to thank Colin Perkins, Bernard Aboba, Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox, Stephen Farrell, Magnus Westerlund, Simon Perreault, and Ben Campbell for their constructive comments, suggestions, and reviews that were critical to the formulation and refinement of this document.
作者要感谢Flavio Battimo和Pierluigi Palma在本文件早期阶段提供的宝贵反馈。作者还要感谢Colin Perkins、Bernard Aboba、Albrecht Schwarz、Hadriel Kaplan、Keith Drage、Jonathan Lennox、Stephen Farrell、Magnus Westerlund、Simon Perreault和Ben Campbell提出的建设性意见、建议和评论，这些意见、建议和评论对本文件的制定和完善至关重要。
Authors' Addresses
作者地址
Lorenzo Miniero Meetecho
洛伦佐·米尼罗·梅特科
Email: lorenzo@meetecho.com
Email: lorenzo@meetecho.com
Sergio Garcia Murillo Medooze
塞尔吉奥·加西亚·穆里洛·梅杜泽
Email: sergio.garcia.murillo@gmail.com
Email: sergio.garcia.murillo@gmail.com
Victor Pascual Oracle
维克多·帕斯夸尔
Email: victor.pascual.avila@oracle.com
Email: victor.pascual.avila@oracle.com