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
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ネットワークアドレス変換（NAT）のマッピングを維持するためにリアルタイム転送プロトコル（RTP）およびRTP制御プロトコル（RTCP）を使用してアプリケーションを有効に異なるメカニズムを示しています。また、推奨メカニズムのための勧告を行います。この文書では、インタラクティブ接続確立（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
[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、セッション開始プロトコル（SIP）[RFC3261]などのいくつかのRTPの用途において、薬剤は、セッション記述プロトコル（SDP）を使用して、一方向メディアストリームを交渉することができる[RFC4566]つの薬剤の「recvonlyで」属性と「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同様に、双方向のメディアストリームは、「保留」することができます。これは、「非アクティブ」、「sendonlyで」SDPかを使用することによって達成される属性。再び、[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、テキストの会話[RFC4103]のためのペイロード・フォーマットのようないくつかのRTPペイロードフォーマットは、間隔が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.
これらの問題を解決するために、エージェントは、そのため、定期的に関係なく、メディアストリームがsendonlyで、recvonlyで、またはSENDRECV、とに関わらずの存在又は値の、現在非アクティブであるかどうかの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キープアライブに加えて、対称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キープアライブのために推奨される解決策を述べています。第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]のエージェントには適用されません。確かに、NAT（TURN）[RFC5766]の周りにリレーを使用してNAT（STUN）[RFC5389]とトラバーサルのために一緒にセッショントラバーサルユーティリティとICEプロトコルは、メディアストリームの全体的なネットワークアドレス変換（NAT）トラバーサルメカニズムを解決します。 RTPメディアストリームの文脈では、いくつかのエージェントは、すべてのICEの機能を必要としないかもしれないとだけキープアライブメカニズムが必要な場合があります。この文書では、このような物質に適用され、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.
与えられたメディアが既にキープアライブ機構を統合コーデックを使用する場合、追加のキープアライブ機構は、RTPレベルで必要とされないことに留意されたいです。
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節で述べたように、「キープアライブメッセージは、一般的な使用は推奨されないことに注意することが重要である - 彼らは多くのアプリケーションには不要であり、システムやネットワークのリソースを大量に消費することができます」。
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].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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 RTPキープアライブのサポートはSDPで記述されるべきです。
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メディアストリームの中にキープアライブメッセージを実行します。
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].
アプリケーションは、快適雑音ペイロード[RFC3389]でRTPパケットを送信します。
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メディア経路自体（RTPとRTCPパケットの両方のために、すなわち、同じタプル）[RFC5761]にRTCPパケットを送信します。 RTCPパケットは、したがって、NATマッピングがいる限り、セクション8で説明したように、パラメータ選択のための要件が満たされているとして開いたまま。
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.
多重RTPとRTCP oは、リモートピアによってサポートされなければなりません。
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.
Tminの値[RFC3550]は以下Trの間隔と等しくなるようにO RTCPを設定する必要があります。
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の有効性チェックのおかげで、STUNパケットは、RTPスタックによって無視されます。
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のみ4バージョン番号が可能です。 RTPキープアライブのためにそれらのいずれかを使用することは無駄になります。
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]がrecvonly非アクティブとしてメディアが送信されない属性[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).
アプリケーションは、ピア（例えば、SDPオファー/アンサー内でネゴシエートされないので、任意のメディア形式にマッピングされていない）によってネゴシエートされていないダイナミックペイロードタイプと長さ0のRTPパケットを送信します。
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セッション内で送信されるシーケンス番号は、各パケットに対して1つずつインクリメントされます。タイムスタンプは、メディアパケットは、この時点で持っているのと同じ値が含まれています。マーカービットは、キープアライブパケットのために重要ではないので、ゼロに設定されています。
The synchronization source (SSRC) is the same as for the media for which keepalive is sent.
同期ソース（SSRC）は、キープアライブが送信されたメディアの場合と同じです。
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]がrecvonly非アクティブとしてメディアが送信されない属性[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キープアライブパケットにはRTCPのレポートは、受信機が理解していないペイロードタイプとRTPパケットは無視され、[RFC3550]の任務として、ありません。
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.
推奨メカニズムは、「RTPパケットとRTCPパケット多重化」（セクション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で推奨キープアライブ溶液を許可しない場合、別の機構は、このメディアフォーマットのペイロードフォーマット仕様で定義されるべきです。
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.
この仕様をサポートするアプリケーションは、メディアセッションの全期間中に少なくとも1回ごとのTr秒キープアライブパケットまたはメディアパケットのどちらかを伝えなければなりません。
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].
キープアライブの溶液（4.3節）、「RTPパケットに多重化RTCPパケット」を使用する場合、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セッション内でキープアライブパケットは、通常のRTPパケットの（送信元IPアドレス、送信元TCP / UDPポート、IPアドレスを標的とする、TCP / UDPポートをターゲット）タプルを使用しなければなりません。
The agent SHOULD only send RTP keepalive when it does not send regular RTP packets.
それは、通常のRTPパケットを送信しないときに、エージェントにのみRTPキープアライブを送るべきです。
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マッピングがいる限り、彼らが十分な頻度で送信されたとして開いたままにすることができます。そのための2つの条件があります。まず、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は、十分な頻度で送信されることを保証するために考慮する必要がある2つの要因があります。送信が最長許容されるパケットの送信間隔（TR）よりも頻繁に発生するように第一、RTCP帯域幅が十分に大きくする必要があります。最悪の場合RTCP間隔（TWC）は、以下のパラメータの最大値を挿入することによって、この式を用いて計算することができます。
o Maximum RTCP packet size (avg_rtcp_size_max)
O最大RTCPパケットサイズ（avg_rtcp_size_max）
o Maximum number of participants (members_max)
参加者のOの最大数（members_max）
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帯域幅の値が1以外のすべてのメンバーが送信者でない場合は、本機の割合となり、最悪の場合、ためのものです。これは、すべてのメンバーであると近似することができます。したがって、RRとRS値[RFC3556]が使用されているセッションのために、次にrtcp_bwはRRに設定されなければなりません。 [RFC3550]はRTCP帯域幅の割合を-definedセッション（すなわち、送信者のための帯域幅の1/4と受信機の帯域幅の3/4）を使用しているため、その後rtcp_bwは、ASの3/4の5％になります秒当たりのビットの値[RFC4566]。
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:
第2の要因は、RTCP間隔Tminとは、[RFC3550]で定義された最小値です。そのベース値は5秒ですが、それはまた、kbps単位でのセッション帯域幅で割った360にスケーリングされることがあります。リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバック（RTP / AVPF）[RFC4585]の拡張RTPプロファイルはまた、定期的なRTCPパケットの最小のRTCP間隔であるTRR-INTパラメータの設定を可能にします。また、定期的な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:
キープアライブを機能させるため、次のようにこのように、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.十分なRTCP帯域幅は、TWCを計算することによって提供されていることを確認し、得られた値は以下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).
AVPまたはSAVP [RFC3711]を使用する場合は2、Tminの値は、1.5 /（E-3/2）で割った値Trより大きくすることはできません。
3. If AVPF or SAVPF [RFC5124] is to be used, trr-min must not be set to a value greater than Tr / 3.
AVPFまたはSAVPF [RFC5124]を使用する場合は3は、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キープアライブパケットは、通常のRTPメディアパケットと同じパス上で送信され、ピアによって攻撃として知覚することができます。しかし、ピアは「それは理解していないペイロードタイプを持つパケットを無視する」[RFC3550]義務付け。キープアライブメッセージを理解していないピアは、このように適切に受信されたパケットをドロップします。
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.
ジョナサン・ローゼンバーグは、ICEの仕様を経て、この文書のための主要なインプットを提供します。マグヌスウェスターは、RTCPフローキープアライブセクションのテキストを提供します。また、彼らの役に立つ入力とコメントのアルフレッドE. Heggestad、コリンパーキンス、ダン・ウィング、グンナー・ヘルストローム、Hadrielカプラン、ランデルジェサップ、レミデニス・Courmont、ロバート・スパークス、とスティーブCasnerのおかげ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]ウイング、D.、 "対称RTP / RTP制御プロトコル（RTCP）"、BCP 131、RFC 4961、2007年7月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]エッゲルト、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]パーキンス、C.とM.ウェスター、 "シングルポートの多重化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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389] Zopf、R.、RFC 3389、2002年9月 "コンフォートノイズ（CN）のためのリアルタイムトランスポートプロトコル（RTP）ペイロード"。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556] Casner、S.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のためのRTPペイロード"、RFC 4103、2005年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル」、RFC 4585、2006年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.、エド。、およびC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、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]オット、J.およびE.カララ、RFC 5124、2008年2月 "リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバック（RTP / SAVPF）にSecure RTPプロファイル拡張"。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年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]グハ、S.、エド。、ビスワス、K.、フォード、B.、シバクマー、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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサルNAT（TURN）の周りにリレーを使用してリレー拡張NAT（STUN）のセッショントラバーサルユーティリティに"、RFC 5766、2010年4月。
Authors' Addresses
著者のアドレス
Xavier Marjou France Telecom Orange 2, avenue Pierre Marzin Lannion 22307 France
ザビエルMarjouフランステレコムオレンジ2、大通りピエールMarzin 22307ラニオンフランス
EMail: xavier.marjou@orange-ftgroup.com
メールアドレス：xavier.marjou@orange-ftgroup.com
Aurelien Sollaud France Telecom Orange 2, avenue Pierre Marzin Lannion 22307 France
オーレリアンSollaudフランステレコムオレンジ2、大通りピエールMarzin 22307ラニオンフランス
EMail: aurelien.sollaud@orange-ftgroup.com
メールアドレス：aurelien.sollaud@orange-ftgroup.com