Internet Engineering Task Force (IETF) X. Marjou
Request for Comments: 6263 A. Sollaud
Category: Standards Track France Telecom Orange
ISSN: 2070-1721 June 2011
Internet Engineering Task Force (IETF) X. Marjou
Request for Comments: 6263 A. Sollaud
Category: Standards Track France Telecom Orange
ISSN: 2070-1721 June 2011
Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows
用于保持与RTP/RTP控制协议（RTCP）流关联的NAT映射活动的应用机制
Abstract
摘要
This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents.
本文档列出了使用实时传输协议（RTP）和RTP控制协议（RTCP）的应用程序保持其RTP网络地址转换器（NAT）映射活动的不同机制。它还对首选机制提出了建议。本文件不适用于交互式连接建立（ICE）代理。
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/rfc6263.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6263.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Requirements ....................................................4
4. List of Alternatives for Performing RTP Keepalive ...............4
4.1. Empty (0-Byte) Transport Packet ............................4
4.2. RTP Packet with Comfort Noise Payload ......................5
4.3. RTCP Packets Multiplexed with RTP Packets ..................5
4.4. STUN Indication Packet .....................................6
4.5. RTP Packet with Incorrect Version Number ...................6
4.6. RTP Packet with Unknown Payload Type .......................6
5. Recommended Solution for Keepalive Mechanism ....................7
6. Media Format Exceptions .........................................7
7. Timing and Transport Considerations .............................7
8. RTCP Flow Keepalive .............................................8
9. Security Considerations .........................................9
10. Acknowledgements ...............................................9
11. References ....................................................10
11.1. Normative References .....................................10
11.2. Informative References ...................................10
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Requirements ....................................................4
4. List of Alternatives for Performing RTP Keepalive ...............4
4.1. Empty (0-Byte) Transport Packet ............................4
4.2. RTP Packet with Comfort Noise Payload ......................5
4.3. RTCP Packets Multiplexed with RTP Packets ..................5
4.4. STUN Indication Packet .....................................6
4.5. RTP Packet with Incorrect Version Number ...................6
4.6. RTP Packet with Unknown Payload Type .......................6
5. Recommended Solution for Keepalive Mechanism ....................7
6. Media Format Exceptions .........................................7
7. Timing and Transport Considerations .............................7
8. RTCP Flow Keepalive .............................................8
9. Security Considerations .........................................9
10. Acknowledgements ...............................................9
11. References ....................................................10
11.1. Normative References .....................................10
11.2. Informative References ...................................10
[RFC4787] and [RFC5382] describe Network Address Translator (NAT) behaviors and point out that two key aspects of NAT are mappings (a.k.a. bindings) and keeping them refreshed. This introduces a derived requirement for applications engaged in a multimedia session involving NAT traversal: they need to generate a minimum of flow activity in order to create NAT mappings and maintain them.
[RFC4787]和[RFC5382]描述了网络地址转换器（NAT）的行为，并指出NAT的两个关键方面是映射（也称为绑定）和保持更新。这为参与涉及NAT遍历的多媒体会话的应用程序引入了一个派生需求：它们需要生成最少的流活动，以便创建和维护NAT映射。
When applied to applications using the Real-time Transport Protocol (RTP) [RFC3550], the RTP media stream packets themselves normally fulfill this requirement. However, there exist some cases where RTP does not generate the minimum required flow activity.
当应用于使用实时传输协议（RTP）[RFC3550]的应用程序时，RTP媒体流数据包本身通常满足此要求。然而，在某些情况下，RTP不能生成所需的最小流量活动。
The examples are:
例如：
o In some RTP usages, such as the Session Initiation Protocol (SIP) [RFC3261], agents can negotiate a unidirectional media stream by using the Session Description Protocol (SDP) [RFC4566] "recvonly" attribute on one agent and "sendonly" on the peer, as defined in [RFC3264]. [RFC3264] directs implementations not to transmit media on the receiving agent. If the agent receiving the media is located on the private side of a NAT, it will never receive RTP packets from the public peer if the NAT mapping has not been created.
o 在一些RTP使用中，例如会话发起协议（SIP）[RFC3261]，代理可以通过在一个代理上使用会话描述协议（SDP）[RFC4566]“RecvoOnly”属性和在对等方上使用“sendonly”属性协商单向媒体流，如[RFC3264]中所定义。[RFC3264]指示实现不在接收代理上传输媒体。如果接收媒体的代理位于NAT的私有端，则如果尚未创建NAT映射，它将永远不会从公共对等方接收RTP数据包。
o Similarly, a bidirectional media stream can be "put on hold". This is accomplished by using the SDP "sendonly" or "inactive" attributes. Again, [RFC3264] directs implementations to cease transmission of media in these cases. However, doing so may cause NAT bindings to time out, and media won't be able to come off hold.
o 类似地，双向媒体流可以被“搁置”。这是通过使用SDP“sendonly”或“inactive”属性实现的。在这些情况下，[RFC3264]再次指示实现停止媒体传输。但是，这样做可能会导致NAT绑定超时，媒体将无法停止。
o Some RTP payload formats, such as the payload format for text conversation [RFC4103], may send packets so infrequently that the interval exceeds the NAT binding timeouts.
o 一些RTP有效负载格式，例如文本会话的有效负载格式[RFC4103]，可能发送数据包的频率非常低，以至于间隔超过NAT绑定超时。
To solve these problems, an agent therefore needs to periodically send keepalive data within the outgoing RTP session of an RTP media stream regardless of whether the media stream is currently inactive, sendonly, recvonly, or sendrecv, and regardless of the presence or value of the bandwidth attribute.
为了解决这些问题，代理因此需要在RTP媒体流的传出RTP会话内周期性地发送保留数据，而不管媒体流当前是非活动的、仅发送的、仅接收的或发送的，也不管带宽属性的存在或值。
It is important to note that NAT traversal constraints also usually require that the agents use Symmetric RTP / RTP Control Protocol (RTCP) [RFC4961] in addition to RTP keepalive.
需要注意的是，NAT遍历约束通常还要求代理除了使用RTP keepalive外，还使用对称RTP/RTP控制协议（RTCP）[RFC4961]。
This document first states the requirements that must be supported to perform RTP keepalives (Section 3). In a second step, the document reports the different mechanisms to overcome this problem (Section 4). Section 5 finally states the recommended solution for RTP keepalive. Section 6 discusses some media format exceptions. Section 7 adds details about timing and transport considerations. Section 8 documents how to maintain NAT bindings for RTCP.
本文件首先说明了执行RTP保留所必须支持的要求（第3节）。在第二步中，该文件报告了克服这一问题的不同机制（第4节）。第5节最后陈述了RTP keepalive的推荐解决方案。第6节讨论了一些媒体格式例外情况。第7节增加了有关时间和运输注意事项的详细信息。第8节介绍了如何维护RTCP的NAT绑定。
This document is not applicable to Interactive Connectivity Establishment (ICE) [RFC5245] agents. Indeed, the ICE protocol, together with Session Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766], solves the overall Network Address Translator (NAT) traversal mechanism of media streams. In the context of RTP media streams, some agents may not require all ICE functionalities and may only need a keepalive mechanism. This document thus applies to such agents, and does not apply to agents implementing ICE.
本文件不适用于交互式连接建立（ICE）[RFC5245]代理。事实上，ICE协议与NAT（STUN）[RFC5389]的会话遍历实用程序以及使用NAT（TURN）[RFC5766]周围的中继进行的遍历一起，解决了媒体流的整体网络地址转换器（NAT）遍历机制。在RTP媒体流的上下文中，一些代理可能不需要所有ICE功能，并且可能只需要keepalive机制。因此，本文件适用于此类代理，不适用于实施ICE的代理。
Note that if a given media uses a codec that already integrates a keepalive mechanism, no additional keepalive mechanism is required at the RTP level.
请注意，如果给定媒体使用已集成keepalive机制的编解码器，则在RTP级别不需要额外的keepalive机制。
As mentioned in Section 3.5 of [RFC5405], "It is important to note that keepalive messages are NOT RECOMMENDED for general use -- they are unnecessary for many applications and can consume significant amounts of system and network resources".
如[RFC5405]第3.5节所述，“需要注意的是，keepalive消息不建议用于一般用途——它们对于许多应用程序都是不必要的，并且可能会消耗大量的系统和网络资源”。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
This section outlines the key requirements that need to be satisfied in order to provide RTP media keepalive.
本节概述了提供RTP介质保持所需满足的关键要求。
REQ-1 Some data is sent periodically within the outgoing RTP session for the whole duration of the RTP media stream.
REQ-1在RTP媒体流的整个持续时间内，在传出RTP会话中定期发送一些数据。
REQ-2 Any type of transport (e.g., UDP, TCP) MUST be supported.
REQ-2必须支持任何类型的传输（如UDP、TCP）。
REQ-3 Any media type (e.g., audio, video, text) MUST be supported.
REQ-3必须支持任何媒体类型（如音频、视频、文本）。
REQ-4 Any media format (e.g., G.711, H.263) MUST be supported.
REQ-4必须支持任何媒体格式（如g.711、H.263）。
REQ-5 Session signaling protocols SHOULD NOT be impacted.
REQ-5会话信令协议不应受到影响。
REQ-6 Impacts on existing software SHOULD be minimized.
REQ-6对现有软件的影响应最小化。
REQ-7 The remote peer SHOULD NOT be impacted.
REQ-7远程对等方不应受到影响。
REQ-8 The support for RTP keepalive SHOULD be described in the SDP.
REQ-8应在SDP中描述对RTP keepalive的支持。
REQ-9 The solution SHOULD cover the integration with RTCP.
REQ-9解决方案应包括与RTCP的集成。
This section lists, in no particular order, some alternatives that can be used to perform a keepalive message within RTP media streams.
本节不按特定顺序列出了可用于在RTP媒体流中执行keepalive消息的一些备选方案。
The application sends an empty transport packet (e.g., UDP packet, Datagram Congestion Control Protocol (DCCP) packet).
应用程序发送空的传输数据包（例如，UDP数据包、数据报拥塞控制协议（DCCP）数据包）。
Con:
反对的论点：
o This alternative is specific to each transport protocol.
o 此备选方案特定于每个传输协议。
The application sends an RTP packet with a comfort noise payload [RFC3389].
应用程序发送带有舒适噪声有效载荷的RTP数据包[RFC3389]。
Cons:
欺骗：
o This alternative is limited to audio formats only.
o 此选项仅限于音频格式。
o Comfort noise needs to be supported by the remote peer.
o 舒适性噪音需要远程对等方的支持。
o Comfort noise needs to be signaled in SDP offer/answer.
o 舒适性噪音需要在SDP提供/应答中发出信号。
o The peer is likely to render comfort noise at the other side, so the content of the payload (the noise level) needs to be carefully chosen.
o 对等方可能会在另一侧发出舒适的噪声，因此需要仔细选择有效载荷的内容（噪声级）。
The application sends RTCP packets in the RTP media path itself (i.e., the same tuples for both RTP and RTCP packets) [RFC5761]. RTCP packets therefore keep the NAT mappings open as long as the requirements for parameter selection are fulfilled as discussed in Section 8.
应用程序在RTP媒体路径本身中发送RTCP数据包（即，RTP和RTCP数据包的元组相同）[RFC5761]。因此，只要满足第8节中讨论的参数选择要求，RTCP数据包就会保持NAT映射打开。
Note: The "on hold" procedures of [RFC3264] do not impact RTCP transmissions.
注：[RFC3264]的“暂停”程序不影响RTCP传输。
Cons:
欺骗：
o Multiplexing RTP and RTCP must be supported by the remote peer.
o 远程对等方必须支持多路复用RTP和RTCP。
o Some RTCP monitoring tools expect that RTCP packets are not multiplexed.
o 一些RTCP监控工具预期RTCP数据包不会被多路复用。
o RTCP must be configured so that the Tmin value [RFC3550] is less than or equal to the Tr interval.
o RTCP的配置必须确保Tmin值[RFC3550]小于或等于Tr间隔。
The application sends a STUN [RFC5389] Binding Indication packet as specified in ICE [RFC5245].
应用程序按照ICE[RFC5245]中的规定发送STUN[RFC5389]绑定指示数据包。
Thanks to the RTP validity check, STUN packets will be ignored by the RTP stack.
由于RTP有效性检查，RTP堆栈将忽略STUN数据包。
Con:
反对的论点：
o The sending agent needs to support STUN.
o 发送代理需要支持STUN。
The application sends an RTP packet with a version number set to zero (i.e., an incorrect version number).
应用程序发送版本号设置为零的RTP数据包（即，不正确的版本号）。
Based on the RTP specification [RFC3550], the peer should perform a header validity check and therefore ignore these types of packets.
根据RTP规范[RFC3550]，对等方应执行报头有效性检查，因此忽略这些类型的数据包。
Cons:
欺骗：
o Only four version numbers are possible. Using one of them for RTP keepalive would be wasteful.
o 只有四个版本号是可能的。将其中一个用于RTP keepalive将是浪费。
o [RFC4566] and [RFC3264] mandate that media with inactive and recvonly attributes not be sent; however, this is mitigated, as no real media is sent with this mechanism.
o [RFC4566]和[RFC3264]要求不发送具有非活动和可恢复属性的媒体；但是，由于没有使用此机制发送真实媒体，因此这一点得到了缓解。
The application sends an RTP packet of 0 length with a dynamic payload type that has not been negotiated by the peers (e.g., not negotiated within the SDP offer/answer, and thus not mapped to any media format).
应用程序发送长度为0的RTP数据包，其动态有效负载类型未经对等方协商（例如，未在SDP提供/应答中协商，因此未映射到任何媒体格式）。
The sequence number is incremented by one for each packet, as it is sent within the same RTP session as the actual media. The timestamp contains the same value that a media packet would have at this time. The marker bit is not significant for the keepalive packets and is thus set to zero.
序列号对于每个数据包递增一，因为它是在与实际媒体相同的RTP会话中发送的。时间戳包含的值与媒体数据包此时的值相同。标记位对于keepalive数据包不重要，因此设置为零。
The synchronization source (SSRC) is the same as for the media for which keepalive is sent.
同步源（SSRC）与发送keepalive的介质的同步源相同。
Normally, the peer will ignore this packet, as RTP [RFC3550] states that "a receiver MUST ignore packets with payload types that it does not understand".
通常，对等方将忽略此数据包，因为RTP[RFC3550]声明“接收方必须忽略其不理解的有效负载类型的数据包”。
Cons:
欺骗：
o [RFC4566] and [RFC3264] mandate that media with inactive and recvonly attributes not be sent; however, this is mitigated, as no real media is sent with this mechanism.
o [RFC4566]和[RFC3264]要求不发送具有非活动和可恢复属性的媒体；但是，由于没有使用此机制发送真实媒体，因此这一点得到了缓解。
o [RFC3550] does not preclude examination of received packets by the peer in an attempt to determine if it is under attack.
o [RFC3550]不排除对等方检查接收到的数据包以确定其是否受到攻击。
o The statement "a receiver MUST ignore packets with payload types that it does not understand" of [RFC3550] is not always observed in real life.
o [RFC3550]中的语句“接收方必须忽略其不了解的有效负载类型的数据包”，在现实生活中并不总是可以观察到。
o There is no RTCP reporting for the keepalive packets, as [RFC3550] mandates that RTP packets with payload types that the receiver does not understand be ignored.
o keepalive数据包没有RTCP报告，因为[RFC3550]要求忽略具有接收方不了解的有效负载类型的RTP数据包。
o Some RTP payload formats do not handle gaps in RTP sequence number well.
o 一些RTP有效负载格式不能很好地处理RTP序列号中的间隙。
The RECOMMENDED mechanism is that discussed in "RTCP Packets Multiplexed with RTP Packets" (Section 4.3). This mechanism is desirable because it reduces the number of ports when RTP and RTCP are used. It also has the advantage of taking into account RTCP aspects, which is not the case with other mechanisms.
推荐的机制如“RTCP数据包与RTP数据包复用”（第4.3节）所述。这种机制是可取的，因为它减少了使用RTP和RTCP时的端口数。它还具有考虑RTCP方面的优势，这与其他机制不同。
Other mechanisms (Sections 4.1, 4.2, 4.4, 4.5, and 4.6) are NOT RECOMMENDED.
不建议使用其他机制（第4.1、4.2、4.4、4.5和4.6节）。
When a given media format does not allow the keepalive solution recommended in Section 5, an alternative mechanism SHOULD be defined in the payload format specification for this media format.
当给定的媒体格式不允许第5节中推荐的keepalive解决方案时，应在该媒体格式的有效负载格式规范中定义替代机制。
An application supporting this specification MUST transmit either keepalive packets or media packets at least once every Tr seconds during the whole duration of the media session.
在整个媒体会话期间，支持此规范的应用程序必须至少每Tr秒发送一次keepalive数据包或媒体数据包。
Tr has different value according to the transport protocol.
根据传输协议，Tr具有不同的值。
For UDP, the minimum RECOMMENDED Tr value is 15 seconds, and Tr SHOULD be configurable to larger values.
对于UDP，建议的最小Tr值为15秒，Tr应可配置为更大的值。
For TCP, the recommended Tr value is 7200 seconds.
对于TCP，建议的Tr值为7200秒。
When using the "RTCP packets multiplexed with RTP packets" solution (Section 4.3) for keepalive, Tr MUST comply with the RTCP timing rules of [RFC3550].
为keepalive使用“RTCP数据包与RTP数据包多路复用”解决方案（第4.3节）时，Tr必须遵守[RFC3550]的RTCP定时规则。
Keepalive packets within a particular RTP session MUST use the tuple (source IP address, source TCP/UDP port, target IP address, target TCP/UDP port) of the regular RTP packets.
特定RTP会话中的Keepalive数据包必须使用常规RTP数据包的元组（源IP地址、源TCP/UDP端口、目标IP地址、目标TCP/UDP端口）。
The agent SHOULD only send RTP keepalive when it does not send regular RTP packets.
代理只应在不发送常规RTP数据包时发送RTP keepalive。
RTCP packets are sent periodically and can thus normally keep the NAT mappings open as long as they are sent frequently enough. There are two conditions for that. First, RTCP needs to be used bidirectionally and in a symmetric fashion, as described in [RFC4961]. Secondly, RTCP needs to be sent frequently enough. However, there are certain configurations that can break this latter assumption.
RTCP数据包定期发送，因此只要发送频率足够高，通常可以保持NAT映射打开。这有两个条件。首先，RTCP需要双向对称使用，如[RFC4961]所述。其次，RTCP需要足够频繁地发送。然而，某些配置可能会打破后一种假设。
There are two factors that need to be considered to ensure that RTCP is sent frequently enough. First, the RTCP bandwidth needs to be sufficiently large so that transmission will occur more frequently than the longest acceptable packet transmission interval (Tr). The worst-case RTCP interval (Twc) can be calculated using this formula by inserting the max value of the following parameters:
有两个因素需要考虑，以确保RTCP发送足够频繁。首先，RTCP带宽需要足够大，以使传输发生的频率高于最长可接受的分组传输间隔（Tr）。通过插入以下参数的最大值，可以使用此公式计算最坏情况下的RTCP间隔（Twc）：
o Maximum RTCP packet size (avg_rtcp_size_max)
o 最大RTCP数据包大小（平均RTCP大小最大值）
o Maximum number of participants (members_max)
o 最大参与人数（成员人数）
o RTCP receiver bandwidth (rtcp_bw)
o RTCP接收机带宽（RTCP_bw）
The RTCP bandwidth value to use here is for a worst case, which will be the receiver proportion when all members except one are not senders. This can be approximated to be all members. Thus, for sessions where RR and RS values [RFC3556] are used, then rtcp_bw shall be set to RR. For sessions where the [RFC3550]-defined proportions of RTCP bandwidth are used (i.e., 1/4 of the bandwidth for senders and 3/4 of the bandwidth for receivers), then rtcp_bw will be 5% of 3/4 of the AS value [RFC4566] in bits per second.
此处使用的RTCP带宽值适用于最坏情况，即除一个成员外的所有成员都不是发送方时的接收方比例。这可以近似为所有成员。因此，对于使用RR和RS值[RFC3556]的会话，rtcp_bw应设置为RR。对于使用[RFC3550]定义的RTCP带宽比例的会话（即，发送方为带宽的1/4，接收方为带宽的3/4），RTCP_bw将为AS值[RFC4566]的3/4的5%，单位为比特/秒。
Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8
Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8
The second factor is the minimum RTCP interval Tmin defined in [RFC3550]. Its base value is 5 seconds, but it might also be scaled to 360 divided by the session bandwidth in kbps. The Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] also allows for the setting of a trr-int parameter, which is a minimal RTCP interval for regular RTCP packets. It is also used as the Tmin value in the regular Td calculation. An analysis of the algorithm shows that the longest possible regular RTCP interval is:
第二个因素是[RFC3550]中定义的最小RTCP间隔Tmin。它的基本值是5秒，但也可以按360除以会话带宽（以kbps为单位）。基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）[RFC4585]的扩展RTP配置文件还允许设置trr int参数，这是常规RTCP数据包的最小RTCP间隔。它也用作常规Td计算中的Tmin值。对算法的分析表明，最长可能的规则RTCP间隔为：
RTCP_int_max = trr-int * 1.5 + Td * 1.5 / 1.21828
RTCP_int_max = trr-int * 1.5 + Td * 1.5 / 1.21828
And as long as there is sufficient bandwidth according to criteria 1 below, then the algorithm can be simplified by setting Td = trr-int, giving
根据下面的标准1，只要有足够的带宽，那么可以通过设置Td=trr int来简化算法，给出
RTCP_int_max = trr-int * (1.5 + 1.5 / 1.21828) = 2.73123 * trr-int
RTCP_int_max = trr-int * (1.5 + 1.5 / 1.21828) = 2.73123 * trr-int
Thus, the requirements for the RTCP parameters are as follows for functioning keepalive:
因此，运行keepalive时，RTCP参数的要求如下：
1. Ensure that sufficient RTCP bandwidth is provided by calculating Twc, and ensure that the resulting value is less than or equal to Tr.
1. 通过计算Twc确保提供足够的RTCP带宽，并确保结果值小于或等于Tr。
2. If AVP or SAVP [RFC3711] is used, the Tmin value can't be greater than Tr divided by 1.5 / (e-3/2).
2. 如果使用AVP或SAVP[RFC3711]，Tmin值不能大于Tr除以1.5/（e-3/2）。
3. If AVPF or SAVPF [RFC5124] is to be used, trr-min must not be set to a value greater than Tr / 3.
3. 如果要使用AVPF或SAVPF[RFC5124]，则不得将trr min设置为大于Tr/3的值。
The RTP keepalive packets are sent on the same path as regular RTP media packets and may be perceived as an attack by a peer. However, [RFC3550] mandates that a peer "ignore packets with payload types that it does not understand". A peer that does not understand the keepalive message will thus appropriately drop the received packets.
RTP keepalive数据包与常规RTP媒体数据包在同一路径上发送，并且可能被对等方视为攻击。然而，[RFC3550]要求对等方“忽略其不了解的负载类型的数据包”。因此，不理解keepalive消息的对等方将适当地丢弃接收到的数据包。
Jonathan Rosenberg provided the major inputs for this document via the ICE specification. Magnus Westerlund provided the text for the RTCP flow keepalive section. In addition, thanks to Alfred E. Heggestad, Colin Perkins, Dan Wing, Gunnar Hellstrom, Hadriel Kaplan, Randell Jesup, Remi Denis-Courmont, Robert Sparks, and Steve Casner for their useful inputs and comments.
Jonathan Rosenberg通过ICE规范为本文件提供了主要输入。Magnus Westerlund为RTCP流保持部分提供了文本。此外，感谢阿尔弗雷德·赫格斯塔德、科林·帕金斯、丹·温、古纳尔·赫尔斯特罗姆、哈德里尔·卡普兰、兰德尔·杰苏普、雷米·丹尼斯·库尔蒙、罗伯特·斯帕克斯和史蒂夫·卡斯纳提供的有用信息和评论。
[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月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]Wing，D，“对称RTP/RTP控制协议（RTCP）”，BCP 131，RFC 49612007年7月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路传输RTP数据和控制数据包”，RFC 5761，2010年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389]Zopf，R.，“舒适噪声（CN）的实时传输协议（RTP）有效载荷”，RFC 3389，2002年9月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556]Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[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月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103]Hellstrom，G.和P.Jones，“文本对话的RTP有效负载”，RFC 4103，2005年6月。
[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月。
[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月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[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月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
Authors' Addresses
作者地址
Xavier Marjou France Telecom Orange 2, avenue Pierre Marzin Lannion 22307 France
Xavier Marjou法国电信橙2号，皮埃尔马津兰宁大道22307号法国
EMail: xavier.marjou@orange-ftgroup.com
EMail: xavier.marjou@orange-ftgroup.com
Aurelien Sollaud France Telecom Orange 2, avenue Pierre Marzin Lannion 22307 France
法国皮埃尔·马津·拉尼翁大街橙2号奥雷林·索洛德法国电信22307
EMail: aurelien.sollaud@orange-ftgroup.com
EMail: aurelien.sollaud@orange-ftgroup.com