[要約] RFC 6679は、RTP over UDPにおける明示的な輻輳通知（ECN）に関する規格であり、ECNの使用方法とRTPフローの輻輳制御を提供します。目的は、RTPセッションのパフォーマンスを向上させ、ネットワークの輻輳を適切に制御することです。
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 6679 I. Johansson
Category: Standards Track Ericsson
ISSN: 2070-1721 C. Perkins
University of Glasgow
P. O'Hanlon
University of Oxford
K. Carlberg
G11
August 2012
Explicit Congestion Notification (ECN) for RTP over UDP
RTP over UDPの明示的輻輳通知（ECN）
Abstract
概要
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined.
このメモは、RTP制御プロトコル（RTCP）をフィードバックメカニズムとして使用して、UDPで実行されているリアルタイムトランスポートプロトコル（RTP）で明示的輻輳通知（ECN）を使用する方法を指定します。定期的なECNフィードバック用の新しいRTCP拡張レポート（XR）ブロック、輻輳イベントのタイムリーなレポート用の新しいRTCPトランスポートフィードバックメッセージ、およびInteractive Connectivity Establishmentを使用したオプションの初期化メソッドで使用されるNAT（STUN）拡張用のセッショントラバーサルユーティリティを定義します。 （氷）。機能と初期化方法の交渉のためのシグナリングと手順も定義されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6679.
このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6679で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions, Definitions, and Acronyms ..........................5
3. Discussion, Requirements, and Design Rationale ..................6
3.1. Requirements ...............................................8
3.2. Applicability ..............................................8
3.3. Interoperability ..........................................12
4. Overview of Use of ECN with RTP/UDP/IP .........................13
5. RTCP Extensions for ECN Feedback ...............................16
5.1. RTP/AVPF Transport-Layer ECN Feedback Packet ..............16
5.2. RTCP XR Report Block for ECN Summary Information ..........19
6. SDP Signalling Extensions for ECN ..............................21
6.1. Signalling ECN Capability Using SDP .......................21
6.2. RTCP ECN Feedback SDP Parameter ...........................26
6.3. XR Block ECN SDP Parameter ................................26
6.4. ICE Parameter to Signal ECN Capability ....................27
7. Use of ECN with RTP/UDP/IP .....................................27
7.1. Negotiation of ECN Capability .............................27
7.2. Initiation of ECN Use in an RTP Session ...................28
7.3. Ongoing Use of ECN within an RTP Session ..................35
7.4. Detecting Failures ........................................38
8. Processing ECN in RTP Translators and Mixers ...................42
8.1. Transport Translators .....................................42
8.2. Fragmentation and Reassembly in Translators ...............43
8.3. Generating RTCP ECN Feedback in Media Transcoders .........45
8.4. Generating RTCP ECN Feedback in Mixers ....................46
9. Implementation Considerations ..................................47
10. IANA Considerations ...........................................47
10.1. SDP Attribute Registration ...............................47
10.2. RTP/AVPF Transport-Layer Feedback Message ................47
10.3. RTCP Feedback SDP Parameter ..............................48
10.4. RTCP XR Report Blocks ....................................48
10.5. RTCP XR SDP Parameter ....................................48
10.6. STUN Attribute ...........................................48
10.7. ICE Option ...............................................48
11. Security Considerations .......................................48
12. Examples of SDP Signalling ....................................51
12.1. Basic SDP Offer/Answer ...................................52
12.2. Declarative Multicast SDP ................................54
13. Acknowledgments ...............................................54
14. References ....................................................55
14.1. Normative References .....................................55
14.2. Informative References ...................................56
This memo outlines how Explicit Congestion Notification (ECN) [RFC3168] can be used for Real-time Transport Protocol (RTP) [RFC3550] flows running over UDP/IP that use the RTP Control Protocol (RTCP) as a feedback mechanism. The solution consists of feedback of ECN congestion experienced markings to the sender using RTCP, verification of ECN functionality end-to-end, and procedures for how to initiate ECN usage. Since the initiation process has some dependencies on the signalling mechanism used to establish the RTP session, a specification for signalling mechanisms using the Session Description Protocol (SDP) [RFC4566] is included.
このメモは、RTP制御プロトコル（RTCP）をフィードバックメカニズムとして使用するUDP / IPで実行されているリアルタイムトランスポートプロトコル（RTP）[RFC3550]フローに対して、明示的輻輳通知（ECN）[RFC3168]をどのように使用できるかを概説しています。このソリューションは、RTCPを使用した送信者へのECN輻輳の発生したマーキングのフィードバック、エンドツーエンドのECN機能の検証、およびECNの使用を開始する方法の手順で構成されています。開始プロセスは、RTPセッションの確立に使用されるシグナリングメカニズムにいくつかの依存関係があるため、Session Description Protocol（SDP）[RFC4566]を使用するシグナリングメカニズムの仕様が含まれています。
ECN can be used to minimise the impact of congestion on real-time multimedia traffic. The use of ECN provides a way for the network to send congestion control signals to the media transport without having to impair the media. Unlike packet loss, ECN signals unambiguously indicate congestion to the transport as quickly as feedback delays allow and without confusing congestion with losses that might have occurred for other reasons such as transmission errors, packet-size errors, routing errors, badly implemented middleboxes, policy violations, and so forth.
ECNを使用すると、リアルタイムのマルチメディアトラフィックに対する輻輳の影響を最小限に抑えることができます。 ECNを使用すると、ネットワークがメディアを損なわずにメディアトランスポートに輻輳制御信号を送信する方法が提供されます。パケット損失とは異なり、ECN信号は、伝送遅延、パケットサイズエラー、ルーティングエラー、不適切に実装されたミドルボックス、ポリシー違反などの他の理由で発生した損失と混雑を混同することなく、フィードバック遅延が許す限り迅速にトランスポートへの混雑を明確に示しますなど。
The introduction of ECN into the Internet requires changes to both the network and transport layers. At the network layer, IP forwarding has to be updated to allow routers to mark packets, rather than discarding them in times of congestion [RFC3168]. In addition, transport protocols have to be modified to inform the sender that ECN-marked packets are being received, so it can respond to the congestion. The Transmission Control Protocol (TCP) [RFC3168], Stream Control Transmission Protocol (SCTP) [RFC4960], and Datagram Congestion Control Protocol (DCCP) [RFC4340] have been updated to support ECN, but to date, there is no specification describing how UDP-based transports, such as RTP [RFC3550], can use ECN. This is due to the lack of feedback mechanisms in UDP. Instead, the signalling control protocol on top of UDP needs to provide that feedback. For RTP, that feedback is provided by RTCP.
ECNをインターネットに導入するには、ネットワーク層とトランスポート層の両方に変更を加える必要があります。ネットワーク層では、輻輳時にパケットを破棄するのではなく、ルーターがパケットをマークできるようにIP転送を更新する必要があります[RFC3168]。さらに、ECNマークの付いたパケットが受信されていることを送信者に通知して、輻輳に応答できるように、トランスポートプロトコルを変更する必要があります。伝送制御プロトコル（TCP）[RFC3168]、ストリーム制御伝送プロトコル（SCTP）[RFC4960]、およびデータグラム輻輳制御プロトコル（DCCP）[RFC4340]は、ECNをサポートするように更新されていますが、現在のところ、仕様を示す方法はありませんRTP [RFC3550]などのUDPベースのトランスポートは、ECNを使用できます。これは、UDPにフィードバックメカニズムがないためです。代わりに、UDP上のシグナリング制御プロトコルがそのフィードバックを提供する必要があります。 RTPの場合、そのフィードバックはRTCPによって提供されます。
The remainder of this memo is structured as follows. We start by describing the conventions, definitions, and acronyms used in this memo in Section 2 and the design rationale and applicability in Section 3. Section 4 gives an overview of how ECN is used with RTP over UDP. RTCP extensions for ECN feedback are defined in Section 5 and SDP signalling extensions in Section 6. The details of how ECN is used with RTP over UDP are defined in Section 7. In Section 8, we describe how ECN is handled in RTP translators and mixers. Section 9 discusses some implementation considerations; Section 10 lists IANA considerations; and Section 11 discusses security considerations.
このメモの残りの部分は、次のように構成されています。このメモで使用されている規則、定義、頭字語をセクション2で説明し、設計の根拠と適用性をセクション3で説明することから始めます。セクション4では、ECNがRTP over UDPでどのように使用されるかの概要を示します。 ECNフィードバックのRTCP拡張はセクション5で定義され、SDPシグナリング拡張はセクション6で定義されます。ECNがRTP over UDPでどのように使用されるかの詳細はセクション7で定義されます。セクション8では、RTPトランスレータとミキサーでECNがどのように処理されるかを説明します。セクション9では、実装に関する考慮事項について説明します。セクション10にIANAの考慮事項を示します。セクション11では、セキュリティの考慮事項について説明します。
Finally, Section 12 provides some examples of SDP signalling for ECN feedback
最後に、セクション12では、ECNフィードバック用のSDPシグナリングの例をいくつか示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
Definitions and Abbreviations:
定義と略語：
Sender: A sender of RTP packets carrying an encoded media stream. The sender can change how the media transmission is performed by varying the media coding or packetisation. It is one endpoint of the ECN control loop.
送信者：エンコードされたメディアストリームを運ぶRTPパケットの送信者。送信者は、メディアコーディングまたはパケット化を変更することにより、メディア送信の方法を変更できます。これは、ECN制御ループの1つのエンドポイントです。
Receiver: A receiver of RTP packets with the intention to consume the media stream. It sends RTCP feedback on the received stream. It is the other endpoint of the ECN control loop.
レシーバー：メディアストリームを消費するためのRTPパケットのレシーバー。受信したストリームでRTCPフィードバックを送信します。これは、ECN制御ループのもう一方のエンドポイントです。
ECN-Capable Host: A sender or receiver of a media stream that is capable of setting and/or processing ECN marks.
ECN対応ホスト：ECNマークを設定または処理できるメディアストリームの送信者または受信者。
ECN-Capable Transport (ECT): A transport flow where both sender and receiver are ECN-capable hosts. Packets sent by an ECN-capable transport will be marked as ECT(0) or ECT(1) on transmission. See [RFC3168] for the definition of the ECT(0) and ECT(1) marks.
ECN対応トランスポート（ECT）：送信者と受信者の両方がECN対応ホストであるトランスポートフロー。 ECN対応のトランスポートによって送信されたパケットは、送信時にECT（0）またはECT（1）としてマークされます。 ECT（0）およびECT（1）マークの定義については、[RFC3168]を参照してください。
ECN-CE: ECN Congestion Experienced mark (see [RFC3168]).
ECN-CE：ECN Congestion Experiencedマーク（[RFC3168]を参照）。
ECN-Capable Packets: Packets with ECN mark set to either ECT(0), ECT(1), or ECN-CE.
ECN対応パケット：ECNマークがECT（0）、ECT（1）、またはECN-CEのいずれかに設定されたパケット。
Not-ECT packets: Packets that are not sent by an ECN-capable transport and are not ECN-CE marked.
Not-ECTパケット：ECN対応のトランスポートによって送信されず、ECN-CEマークが付けられていないパケット。
ECN-Capable Queue: A queue that supports ECN-CE marking of ECN-capable packets to indicate congestion.
ECN対応キュー：輻輳を示すECN対応パケットのECN-CEマーキングをサポートするキュー。
ECN-Blocking Middlebox: A middlebox that discards ECN-capable packets.
ECNブロッキングミドルボックス：ECN対応パケットを破棄するミドルボックス。
ECN-Reverting Middlebox: A middlebox that changes ECN-capable packets to not-ECT packets by removing the ECN mark.
ECN-Reverting Middlebox：ECNマークを削除することにより、ECN対応パケットを非ECTパケットに変更するミドルボックス。
Note that RTP mixers or translators that operate in such a manner that they terminate or split the ECN control loop will take on the role of receivers or senders. This is further discussed in Section 3.2.
ECN制御ループを終了または分割するように動作するRTPミキサーまたはトランスレーターは、レシーバーまたはセンダーの役割を担うことに注意してください。これについては、セクション3.2で詳しく説明します。
ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], and DCCP [RFC4340] transports. These are all unicast protocols that negotiate the use of ECN during the initial connection establishment handshake (supporting incremental deployment and checking if ECN-marked packets pass all middleboxes on the path). ECN-CE marks are immediately echoed back to the sender by the receiving endpoint using an additional bit in feedback messages, and the sender then interprets the mark as equivalent to a packet loss for congestion control purposes.
ECNは、TCP [RFC3168]、SCTP [RFC4960]、およびDCCP [RFC4340]トランスポートで使用するように指定されています。これらはすべて、初期接続確立ハンドシェイク中にECNの使用をネゴシエートするユニキャストプロトコルです（増分展開をサポートし、ECNマークの付いたパケットがパス上のすべてのミドルボックスを通過するかどうかをチェックします）。 ECN-CEマークは、フィードバックメッセージの追加ビットを使用して受信エンドポイントによって直ちに送信者にエコーバックされ、送信者はそのマークを輻輳制御の目的でパケット損失と同等と解釈します。
If RTP is run over TCP, SCTP, or DCCP, it can use the native ECN support provided by those protocols. This memo does not concern itself further with these use cases. However, RTP is more commonly run over UDP. This combination does not currently support ECN, and we observe that it has significant differences from the other transport protocols for which ECN has been specified. These include:
RTPがTCP、SCTP、またはDCCPで実行されている場合、これらのプロトコルによって提供されるネイティブECNサポートを使用できます。このメモは、これらの使用例については、それ自体には関係ありません。ただし、RTPは一般的にUDPで実行されます。この組み合わせは現在ECNをサポートしておらず、ECNが指定されている他のトランスポートプロトコルとの大きな違いがあることがわかります。これらには以下が含まれます：
Signalling: RTP relies on separate signalling protocols to negotiate parameters before a session can be created and doesn't include an in-band handshake or negotiation at session setup time (i.e., there is no equivalent to the TCP three-way handshake in RTP).
シグナリング：RTPは、セッションを作成する前に個別のシグナリングプロトコルに依存してパラメータをネゴシエートし、インバンドハンドシェイクやセッションセットアップ時のネゴシエーションを含みません（つまり、RTPにはTCP 3ウェイハンドシェイクに相当するものはありません）。 。
Feedback: RTP does not explicitly acknowledge receipt of datagrams. Instead, the RTP Control Protocol (RTCP) provides reception quality feedback, and other back channel communication, for RTP sessions. The feedback interval is generally on the order of seconds, rather than once per network round-trip time (RTT) (although the RTP Audio-Visual Profile with Feedback (RTP/AVPF) profile [RFC4585] allows more rapid feedback in most cases). RTCP is also very much oriented around counting packets, which makes byte-counting congestion algorithms difficult to utilise.
フィードバック：RTPはデータグラムの受信を明示的に確認しません。代わりに、RTP制御プロトコル（RTCP）は、RTPセッションに受信品質フィードバックと他のバックチャネル通信を提供します。フィードバック間隔は、ネットワークラウンドトリップ時間（RTT）ごとに1回ではなく、一般的に秒単位です（フィードバック付きのRTPオーディオビジュアルプロファイル（RTP / AVPF）プロファイル[RFC4585]により、ほとんどの場合、より迅速なフィードバックが可能になります）。 。 RTCPは、パケットのカウントを中心にしています。これにより、バイトカウントの輻輳アルゴリズムを利用することが困難になります。
Congestion Response: While it is possible to adapt the transmission of many audio/visual streams in response to network congestion, and such adaptation is required by [RFC3550], the dynamics of the congestion response may be quite different to that of TCP or other transport protocols.
輻輳応答：ネットワークの輻輳に応答して多くのオーディオ/ビジュアルストリームの送信を適応させることは可能であり、そのような適応は[RFC3550]によって要求されますが、輻輳応答のダイナミクスはTCPまたは他のトランスポートのダイナミクスとはかなり異なる場合がありますプロトコル。
Middleboxes: The RTP framework explicitly supports the concept of mixers and translators, which are middleboxes that are involved in media transport functions.
ミドルボックス：RTPフレームワークは、メディアトランスポート機能に関係するミドルボックスであるミキサーとトランスレーターの概念を明示的にサポートします。
Multicast: RTP is explicitly a group communication protocol and was designed from the start to support IP multicast (primarily Any-Source Multicast (ASM) [RFC1112], although a recent extension supports Source-Specific Multicast (SSM) [RFC3569] with unicast feedback [RFC5760]).
マルチキャスト：RTPは明示的にグループ通信プロトコルであり、最初からIPマルチキャスト（主にAny-Source Multicast（ASM）[RFC1112]をサポートするように設計されましたが、最近の拡張機能はユニキャストフィードバック付きのSource-Specific Multicast（SSM）[RFC3569]をサポートします[RFC5760]）。
Application Awareness: When ECN support is provided within the transport protocol, the ability of the application to react to congestion is limited, since it has little visibility into the transport layer. By adding support of ECN to RTP using RTCP feedback, the application is made aware of congestion, allowing a wider range of reactions in response to that congestion indication.
アプリケーションの認識：トランスポートプロトコル内でECNサポートが提供されている場合、アプリケーションはトランスポート層をほとんど認識できないため、輻輳に反応するアプリケーションの機能は制限されます。 RTCPフィードバックを使用してRCNにECNのサポートを追加することにより、アプリケーションは輻輳を認識し、その輻輳の指示に応じてより幅広い反応を可能にします。
Counting vs. Detecting Congestion: TCP, and the protocols derived from it, are mainly designed to respond in the same way whether they experience a burst of congestion indications within one RTT or just a single congestion indication, whereas real-time applications may be concerned with the amount of congestion experienced and whether it is distributed smoothly or in bursts. When feedback of ECN was added to TCP [RFC3168], the receiver was designed to flip the echo congestion experienced (ECE) flag to 1 for a whole RTT then flop it back to zero. ECN feedback in RTCP, however, will need to report a count of how much congestion has been experienced within an RTCP reporting period, irrespective of round-trip times.
輻輳のカウントと検出：TCPおよびTCPから派生したプロトコルは、リアルタイムアプリケーションが懸念する可能性があるのに対し、主に1つのRTT内で輻輳表示のバーストが発生するか、単一の輻輳表示が発生するかにかかわらず、同じ方法で応答するように設計されています。経験された輻輳の量とそれがスムーズに配信されるか、バースト的に配信されるか。 ECNのフィードバックがTCP [RFC3168]に追加されたとき、受信機は、RTT全体に対してエコー輻輳経験（ECE）フラグを1にフリップし、それをゼロに戻すように設計されていました。ただし、RTCPのECNフィードバックでは、往復時間に関係なく、RTCPレポート期間内に発生した輻輳の数を報告する必要があります。
These differences significantly alter the shape of ECN support in RTP over UDP compared to ECN support in TCP, SCTP, and DCCP but do not invalidate the need for ECN support.
これらの違いにより、TCP、SCTP、およびDCCPでのECNサポートと比較して、RTP over UDPでのECNサポートの形が大幅に変わりますが、ECNサポートの必要性が無効になることはありません。
ECN support is more important for RTP sessions than, for instance, is the case for many applications over TCP. This is because the impact of packet loss in real-time audio-visual media flows is highly visible to users. For TCP-based applications, however, TCP will retransmit lost packets, and while extra delay is incurred by having packets dropped rather than ECN-CE marked, the loss is repaired. Effective ECN support for RTP flows running over UDP will allow real-time audio-visual applications to respond to the onset of congestion before routers are forced to drop packets, allowing those applications to control how they reduce their transmission rate and hence media quality, rather than responding to and trying to conceal the effects of unpredictable packet loss. Furthermore, widespread deployment for ECN and active queue management in routers, should it occur, can potentially reduce unnecessary queuing delays in routers, lowering the round-trip time and benefiting interactive applications of RTP, such as voice telephony.
ECNサポートは、たとえば、TCPを介した多くのアプリケーションの場合よりも、RTPセッションにとってより重要です。これは、リアルタイムのオーディオビジュアルメディアフローでのパケット損失の影響がユーザーに非常に目立つためです。ただし、TCPベースのアプリケーションの場合、TCPは失われたパケットを再送信します。ECN-CEマークが付けられるのではなく、パケットがドロップされることによって余分な遅延が発生しますが、損失は修復されます。 UDPを介して実行されるRTPフローの効果的なECNサポートにより、リアルタイムオーディオビジュアルアプリケーションは、ルーターがパケットを強制的にドロップする前に輻輳の発生に応答できるようになり、これらのアプリケーションは、伝送速度を低下させてメディア品質を低下させる方法を制御できます。予測できないパケット損失の影響に対応して隠そうとするよりも。さらに、ルーターでのECNおよびアクティブキュー管理の広範な展開により、ルーターでの不要なキューイング遅延が削減され、ラウンドトリップ時間が短縮され、音声テレフォニーなどのRTPのインタラクティブアプリケーションにメリットがもたらされる可能性があります。
Considering ECN, transport protocols supporting ECN, and RTP-based applications, one can create a set of requirements that must be satisfied to at least some degree if ECN is to be used by RTP over UDP.
ECN、ECNをサポートするトランスポートプロトコル、およびRTPベースのアプリケーションを考慮すると、RTP over UDPでECNを使用する場合、少なくともある程度満たす必要がある一連の要件を作成できます。
o REQ 1: A mechanism must exist to negotiate and initiate the use of ECN for RTP/UDP/IP sessions so that an RTP sender will not send packets with ECT in the IP header unless it knows that all potential receivers will understand any ECN-CE indications they might receive.
o REQ 1：RTP / UDP / IPセッションのECNの使用をネゴシエートして開始するメカニズムが存在する必要がある彼らが受け取るかもしれない兆候。
o REQ 2: A mechanism must exist to feed back the reception of any packets that are ECN-CE marked to the packet sender.
o REQ 2：ECN-CEでマークされたパケットの受信をパケット送信者にフィードバックするメカニズムが存在する必要があります。
o REQ 3: The provided mechanism should minimise the possibility of cheating (either by the sender or receiver).
o REQ 3：提供されたメカニズムは、（送信者または受信者による）不正行為の可能性を最小限に抑える必要があります。
o REQ 4: Some detection and fallback mechanism should exist to avoid loss of communication due to the attempted usage of ECN in case an intermediate node clears ECT or drops packets that are ECT marked.
o REQ 4：中間ノードがECTをクリアしたり、ECTマークが付いたパケットをドロップした場合にECNの使用を試みたことによる通信の損失を回避するために、いくつかの検出およびフォールバックメカニズムが存在する必要があります。
o REQ 5: Negotiation of ECN should not significantly increase the time taken to negotiate and set up the RTP session (an extra RTT before the media can flow is unlikely to be acceptable for some use cases).
o REQ 5：ECNのネゴシエーションによって、RTPセッションのネゴシエーションとセットアップにかかる時間が大幅に増加することはありません（メディアが流れる前の余分なRTTは、一部のユースケースでは受け入れられない可能性があります）。
o REQ 6: Negotiation of ECN should not cause media clipping at the start of a session.
o REQ 6：ECNのネゴシエーションによって、セッションの開始時にメディアクリッピングが発生することはありません。
The following sections describe how these requirements can be met for RTP over UDP.
次のセクションでは、RTP over UDPでこれらの要件を満たす方法について説明します。
The use of ECN with RTP over UDP is dependent on negotiation of ECN capability between the sender and receiver(s) and validation of ECN support in all elements on the network path(s) traversed. RTP is used in a heterogeneous range of network environments and topologies, with different signalling protocols. The mechanisms defined here make it possible to verify support for ECN in each of these environments, irrespective of the topology.
RTP over UDPでのECNの使用は、送信者と受信者の間のECN機能のネゴシエーションと、通過するネットワークパス上のすべての要素でのECNサポートの検証に依存します。 RTPは、さまざまなシグナリングプロトコルを使用して、さまざまなネットワーク環境とトポロジで使用されます。ここで定義されたメカニズムにより、トポロジーに関係なく、これらの各環境でのECNのサポートを検証できます。
Due to the need for each RTP sender that intends to use ECN with RTP to track all participants in the RTP session, the sub-sampling of the group membership as specified by "Sampling of the Group Membership in RTP" [RFC2762] MUST NOT be used.
RTPでECNを使用してRTPセッションのすべての参加者を追跡する予定の各RTP送信者が必要であるため、「RTPのグループメンバーシップのサンプリング」[RFC2762]で指定されているグループメンバーシップのサブサンプリングは、中古。
The use of ECN is further dependent on a capability of the RTP media flow to react to congestion signalled by ECN-marked packets. Depending on the application, media codec, and network topology, this adaptation can occur in various forms and at various nodes. As an example, the sender can change the media encoding, the receiver can change the subscription to a layered encoding, or either reaction can be accomplished by a transcoding middlebox. [RFC5117] identifies seven topologies in which RTP sessions may be configured and which may affect the ability to use ECN:
ECNの使用は、RTPメディアフローがECNマークの付いたパケットによって通知された輻輳に反応する機能にさらに依存します。アプリケーション、メディアコーデック、およびネットワークトポロジに応じて、この適応はさまざまな形式およびさまざまなノードで発生します。例として、送信者はメディアエンコーディングを変更でき、受信者はサブスクリプションを階層化エンコーディングに変更できます。または、トランスコーディングミドルボックスによっていずれかの反応を実行できます。 [RFC5117]は、RTPセッションが構成され、ECNを使用する機能に影響を与える可能性がある7つのトポロジを識別します。
Topo-Point-to-Point: This utilises standard unicast flows. ECN may be used with RTP in this topology in an analogous manner to its use with other unicast transport protocols, with RTCP conveying ECN feedback messages.
トポポイントツーポイント：これは標準のユニキャストフローを利用します。 ECNは、他のユニキャストトランスポートプロトコルでの使用と同様に、このトポロジでRTPと共に使用でき、RTCPはECNフィードバックメッセージを伝達します。
Topo-Multicast: This is either an Any-Source Multicast (ASM) group [RFC3569] with potentially several active senders and multicast RTCP feedback or a Source-Specific Multicast (SSM) group [RFC4607] with a single distribution source and unicast RTCP feedback from receivers. RTCP is designed to scale to large group sizes while avoiding feedback implosion (see Section 6.2 of [RFC3550], [RFC4585], and [RFC5760]) and can be used by a sender to determine if all its receivers, and the network paths to those receivers, support ECN (see Section 7.2). It is somewhat more difficult to determine if all network paths from all senders to all receivers support ECN. Accordingly, we allow ECN to be used by an RTP sender using multicast UDP provided the sender has verified that the paths to all its known receivers support ECN, irrespective of whether the paths from other senders to their receivers support ECN ("all its known receivers" are all the synchronisation sources (SSRCs) from which the RTP sender has received RTP or RTCP in the last five reporting intervals, i.e., they have not timed out). Note that group membership may change during the lifetime of a multicast RTP session, potentially introducing new receivers that are not ECN capable or have a path that doesn't support ECN. Senders must use the mechanisms described in Section 7.4 to check that all receivers, and the network paths traversed to reach those receivers, continue to support ECN, and they need to fallback to non-ECN use if any receivers join that do not.
Topo-Multicast：これは、複数のアクティブな送信者とマルチキャストRTCPフィードバックが含まれる可能性のあるAny-Source Multicast（ASM）グループ[RFC3569]、または単一の配布ソースとユニキャストRTCPフィードバックが含まれるSource-Specific Multicast（SSM）グループ[RFC4607]のいずれかです。受信機から。 RTCPは、フィードバックの急増を回避しながら（[RFC3550]、[RFC4585]、および[RFC5760]のセクション6.2を参照）、大規模なグループサイズにスケーリングするように設計されており、送信者がそのすべての受信者とネットワークパスを確認するために使用できます。これらのレシーバーは、ECNをサポートします（セクション7.2を参照）。すべての送信者からすべての受信者へのすべてのネットワークパスがECNをサポートしているかどうかを判断するのはやや困難です。したがって、他の送信者から受信者へのパスがECNをサポートしているかどうかに関係なく、送信者がすべての既知の受信者へのパスがECNをサポートすることを確認した場合、マルチキャストUDPを使用してRTP送信者がECNを使用できるようにします（「すべての既知の受信者"は、RTP送信者が最後の5つのレポート間隔でRTPまたはRTCPを受信したすべての同期ソース（SSRC）です（つまり、タイムアウトしていません）。グループメンバーシップはマルチキャストRTPセッションの存続期間中に変更される可能性があり、ECNに対応していないか、ECNをサポートしないパスを持つ新しいレシーバーが導入される可能性があることに注意してください。送信者は、セクション7.4で説明されているメカニズムを使用して、すべての受信者、およびそれらの受信者に到達するために通過するネットワークパスが引き続きECNをサポートしていることを確認する必要があり、受信者が参加しない場合、ECN以外の使用にフォールバックする必要があります。
SSM groups that use unicast RTCP feedback [RFC5760] do need a few extra considerations. This topology can have multiple media senders that provide traffic to the distribution source (DS) and are separated from the DS. There can also be multiple feedback targets. The requirement for using ECN for RTP in this topology is that the media sender must be provided the feedback from the receivers. It may be in aggregated form from the feedback targets. We will not mention this SSM use case in the below text specifically, but when actions are required by the media source, they also apply to the case of SSM where the RTCP feedback goes to the feedback target.
ユニキャストRTCPフィードバックを使用するSSMグループ[RFC5760]には、いくつかの追加の考慮事項が必要です。このトポロジには、配布ソース（DS）にトラフィックを提供し、DSから分離された複数のメディアセンダーを含めることができます。複数のフィードバックターゲットが存在する場合もあります。このトポロジでRTPにECNを使用するための要件は、メディア送信者に受信者からのフィードバックを提供する必要があることです。フィードバックターゲットから集約された形式である場合があります。以下のテキストではこのSSMの使用例については特に触れませんが、メディアソースでアクションが必要な場合は、RTCPフィードバックがフィードバックターゲットに送信されるSSMのケースにも適用されます。
The mechanisms defined in this memo support multicast groups but are known to be conservative and don't scale to large groups. This is primarily because we require all members of the group to demonstrate that they can make use of ECN before the sender is allowed to send ECN-marked packets, since allowing some non-ECN-capable receivers causes fairness issues when the bottleneck link is shared by ECN and non-ECN flows that we have not (yet) been able to satisfactorily address. The rules regarding Determination of ECN Support in Section 7.2.1 may be relaxed in a future version of this specification to improve scaling once these issues have been resolved.
このメモで定義されているメカニズムはマルチキャストグループをサポートしていますが、保守的であることが知られており、大規模なグループには拡張できません。これは主に、送信者がECNマーク付きのパケットを送信できるようになる前に、グループのすべてのメンバーがECNを利用できることを示すことを要求するためです。ECN非対応の受信者を許可すると、ボトルネックリンクが共有されると公平性の問題が発生するためです。 ECNおよび非ECNフローでは、（まだ）十分に対応できていません。セクション7.2.1のECNサポートの決定に関するルールは、この仕様の将来のバージョンで緩和され、これらの問題が解決されるとスケーリングが改善される可能性があります。
Topo-Translator: An RTP translator is an RTP-level middlebox that is invisible to the other participants in the RTP session (although it is usually visible in the associated signalling session). There are two types of RTP translators: those that do not modify the media stream and are concerned with transport parameters, for example, a multicast to unicast gateway; and those that do modify the media stream, for example, transcoding between different media codecs. A single RTP session traverses the translator, and the translator must rewrite RTCP messages passing through it to match the changes it makes to the RTP data packets. A legacy, ECN-unaware, RTP translator is expected to ignore the ECN bits on received packets and to set the ECN bits to not-ECT when sending packets, thus causing ECN negotiation on the path containing the translator to fail (any new RTP translator that does not wish to support ECN may do so similarly). An ECN-aware RTP translator may act in one of three ways:
Topo-Translator：RTPトランスレーターは、RTPレベルのミドルボックスであり、RTPセッションの他の参加者には見えません（通常、関連するシグナリングセッションには表示されます）。 RTPトランスレータには2つのタイプがあります。メディアストリームを変更せず、トランスポートパラメータに関係するものです。たとえば、マルチキャストからユニキャストへのゲートウェイです。異なるメディアコーデック間のトランスコーディングなど、メディアストリームを変更するもの。単一のRTPセッションがトランスレータを通過し、トランスレータはRTPデータパケットに加えた変更と一致するように、トランスレータを通過するRTCPメッセージを書き換える必要があります。従来のECN非対応のRTPトランスレータは、受信したパケットのECNビットを無視し、パケットを送信するときにECNビットをECT以外に設定するため、トランスレータを含むパスでのECNネゴシエーションが失敗します（新しいRTPトランスレータはすべてECNをサポートしたくない場合も同様にサポートします）。 ECN対応のRTPトランスレータは、次の3つの方法のいずれかで動作します。
* If the translator does not modify the media stream, it should copy the ECN bits unchanged from the incoming to the outgoing datagrams, unless it is overloaded and experiencing congestion, in which case it may mark the outgoing datagrams with an ECN-CE mark. Such a translator passes RTCP feedback unchanged. See Section 8.1.
* トランスレータがメディアストリームを変更しない場合は、過負荷で輻輳が発生していない限り、ECNビットを変更せずに着信データグラムから発信データグラムにコピーする必要があります。この場合、発信データグラムにECN-CEマークが付けられることがあります。このようなトランスレータは、RTCPフィードバックを変更せずに渡します。セクション8.1を参照してください。
* If the translator modifies the media stream to combine or split RTP packets but does not otherwise transcode the media, it must manage the ECN bits in a way analogous to that described in Section 5.3 of [RFC3168]. See Section 8.2 for details.
* トランスレータがRTPパケットを結合または分割するようにメディアストリームを変更しても、それ以外の方法でメディアをトランスコードしない場合は、[RFC3168]のセクション5.3で説明されている方法と同様の方法でECNビットを管理する必要があります。詳細については、セクション8.2を参照してください。
* If the translator is a media transcoder, or otherwise modifies the content of the media stream, the output RTP media stream may have radically different characteristics than the input RTP media stream. Each side of the translator must then be considered as a separate transport connection, with its own ECN processing. This requires the translator to interpose itself into the ECN negotiation process, effectively splitting the connection into two parts with their own negotiation. Once negotiation has been completed, the translator must generate RTCP ECN feedback back to the source based on its own reception and must respond to RTCP ECN feedback received from the receiver(s) (see Section 8.3).
*トランスレータがメディアトランスコーダの場合、またはメディアストリームのコンテンツを変更する場合、出力RTPメディアストリームは、入力RTPメディアストリームとは根本的に異なる特性を持つ場合があります。トランスレータの各サイドは、独自のECN処理を備えた個別のトランスポート接続と見なす必要があります。これには、トランスレーターがECNネゴシエーションプロセスに介入し、独自のネゴシエーションで接続を2つの部分に効果的に分割する必要があります。ネゴシエーションが完了すると、トランスレータは自身の受信に基づいてソースへのRTCP ECNフィードバックを生成し、レシーバから受信したRTCP ECNフィードバックに応答する必要があります（セクション8.3を参照）。
It is recognised that ECN and RTCP processing in an RTP translator that modifies the media stream is non-trivial.
メディアストリームを変更するRTPトランスレータでのECNおよびRTCP処理は重要です。
Topo-Mixer: A mixer is an RTP-level middlebox that aggregates multiple RTP streams, mixing them together to generate a new RTP stream. The mixer is visible to the other participants in the RTP session and is also usually visible in the associated signalling session. The RTP flows on each side of the mixer are treated independently for ECN purposes, with the mixer generating its own RTCP ECN feedback and responding to ECN feedback for data it sends. Since unicast transport between the mixer and any endpoint are treated independently, it would seem reasonable to allow the transport on one side of the mixer to use ECN, while the transport on the other side of the mixer is not ECN capable, if this is desired. See Section 8.4 for details on how mixers should process ECN.
Topo-Mixer：ミキサーは、RTPレベルのミドルボックスであり、複数のRTPストリームを集約し、それらを混合して新しいRTPストリームを生成します。ミキサーは、RTPセッションの他の参加者に表示され、通常、関連するシグナリングセッションにも表示されます。ミキサーの両側のRTPフローは、ECNの目的で個別に処理され、ミキサーは独自のRTCP ECNフィードバックを生成し、送信するデータのECNフィードバックに応答します。ミキサーと任意のエンドポイント間のユニキャストトランスポートは独立して扱われるため、ミキサーの片側のトランスポートでECNを使用できるようにするのが妥当と思われますが、ミキサーの反対側のトランスポートはECNに対応していません（必要な場合）。 。ミキサーがECNを処理する方法の詳細については、セクション8.4を参照してください。
Topo-Video-switch-MCU: A video-switching Multipoint Control Unit (MCU) receives several RTP flows, but forwards only one of those flows onwards to the other participants at a time. The flow that is forwarded changes during the session, often based on voice activity. Since only a subset of the RTP packets generated by a sender are forwarded to the receivers, a video-switching MCU can break ECN negotiation (the success of the ECN negotiation may depend on the voice activity of the participant at the instant the negotiation takes place - shout if you want ECN). It also breaks congestion feedback and response, since RTP packets are dropped by the MCU depending on voice activity rather than network congestion. This topology is widely used in legacy products but is NOT RECOMMENDED for new implementations and SHALL NOT be used with ECN.
Topo-Video-switch-MCU：ビデオスイッチングマルチポイントコントロールユニット（MCU）は複数のRTPフローを受信しますが、一度に他の参加者に転送するのはこれらのフローの1つだけです。転送されるフローは、多くの場合音声アクティビティに基づいて、セッション中に変更されます。送信者によって生成されたRTPパケットのサブセットのみが受信者に転送されるため、ビデオスイッチングMCUはECNネゴシエーションを中断できます（ECNネゴシエーションの成功は、ネゴシエーションが行われた瞬間の参加者の音声アクティビティに依存する場合があります-ECNが必要な場合は叫んでください）。また、RTPパケットはネットワークの輻輳ではなく音声アクティビティに応じてMCUによってドロップされるため、輻輳のフィードバックと応答も中断されます。このトポロジは、レガシー製品で広く使用されていますが、新しい実装には推奨されておらず、ECNで使用することはできません。
Topo-RTCP-terminating-MCU: In this scenario, each participant runs an RTP point-to-point session between itself and the MCU. Each of these sessions is treated independently for the purposes of ECN and RTCP feedback, potentially with some using ECN and some not.
Topo-RTCP-terminating-MCU：このシナリオでは、各参加者は自分とMCUの間でRTPポイントツーポイントセッションを実行します。これらの各セッションは、ECNおよびRTCPフィードバックの目的で個別に処理され、場合によってはECNを使用する場合と使用しない場合があります。
Topo-Asymmetric: It is theoretically possible to build a middlebox that is a combination of an RTP mixer in one direction and an RTP translator in the other. To quote [RFC5117], "This topology is so problematic and it is so easy to get the RTCP processing wrong, that it is NOT RECOMMENDED to implement this topology".
非対称トポグラフィー：一方向のRTPミキサーと他方向のRTPトランスレーターの組み合わせであるミドルボックスを構築することは理論的に可能です。 [RFC5117]を引用すると、「このトポロジは問題が多く、RTCP処理が間違っている可能性が非常に高いため、このトポロジを実装することはお勧めしません」。
These topologies may be combined within a single RTP session.
これらのトポロジーは、単一のRTPセッション内で組み合わせることができます。
The ECN mechanism defined in this memo is applicable to both sender-and receiver-controlled congestion algorithms. The mechanism ensures that both senders and receivers will know about ECN-CE markings and any packet losses. Thus, the actual decision point for the congestion control is not relevant. This is a great benefit as the rate of an RTP session can be varied in a number of ways, for example, a unicast media sender might use TCP Friendly Rate Control (TFRC) [RFC5348] or some other algorithm, while a multicast session could use a sender-based scheme adapting to the lowest common supported rate or a receiver-driven mechanism using layered coding to support more heterogeneous paths.
このメモで定義されているECNメカニズムは、送信者と受信者の両方が制御する輻輳アルゴリズムに適用できます。このメカニズムにより、送信者と受信者の両方がECN-CEマーキングとパケット損失について確実に知ることができます。したがって、輻輳制御の実際の決定ポイントは重要ではありません。 RTPセッションのレートはさまざまな方法で変更できるため、これは大きな利点です。たとえば、マルチキャストセッションでは、ユニキャストメディア送信者がTCPフレンドリーレートコントロール（TFRC）[RFC5348]またはその他のアルゴリズムを使用できます。最も一般的なサポートされているレートに適応する送信者ベースのスキーム、またはレイヤードコーディングを使用する受信者主導のメカニズムを使用して、より異種のパスをサポートします。
To ensure timely feedback of ECN-CE-marked packets when needed, this mechanism requires support for the RTP/AVPF profile [RFC4585] or any of its derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/ AVP profile [RFC3551] does not allow any early or immediate transmission of RTCP feedback and has a minimal RTCP interval whose default value (5 seconds) is many times the normal RTT between sender and receiver.
必要なときにECN-CEマークの付いたパケットをタイムリーにフィードバックするには、このメカニズムでRTP / AVPFプロファイル[RFC4585]またはその派生物（RTP / SAVPF [RFC5124]など）のサポートが必要です。標準のRTP / AVPプロファイル[RFC3551]は、RTCPフィードバックの早期または即時の送信を許可せず、デフォルト値（5秒）が送信者と受信者の間の通常のRTTの何倍かである最小のRTCP間隔を持っています。
To ensure interoperability for this specification, there is need for at least one common initialisation method for all implementations. Since initialisation using RTP and RTCP (Section 7.2.1) is the one method that works in all cases, although it is not optimal for all uses, it is selected as the mandatory-to-implement initialisation method. This method requires both the RTCP XR extension and the ECN feedback format, which require the RTP/AVPF profile to ensure timely feedback.
この仕様の相互運用性を確保するには、すべての実装に少なくとも1つの共通の初期化メソッドが必要です。 RTPとRTCPを使用した初期化（セクション7.2.1）はすべてのケースで機能する1つの方法であるため、すべての用途に最適ではありませんが、必須から実装への初期化方法として選択されます。この方法では、RTCP XR拡張とECNフィードバック形式の両方が必要です。これらの形式では、タイムリーなフィードバックを確保するためにRTP / AVPFプロファイルが必要です。
When one considers all the uses of ECN for RTP, it is clear that congestion control mechanisms exist that are receiver driven only (Section 7.3.3). These congestion control mechanisms do not require timely feedback of congestion events to the sender. If such a congestion control mechanism is combined with an initialisation method that also doesn't require timely feedback using RTCP, like the leap-of-faith method (Section 7.2.3) or the ICE-based method (Section 7.2.2), then neither the ECN feedback format nor the RTP/ AVPF profile would appear to be needed. However, fault detection can be greatly improved by using receiver-side detection (Section 7.4.1) and early reporting of such cases using the ECN feedback mechanism.
RTPでのECNのすべての使用法を検討すると、レシーバーのみで駆動される輻輳制御メカニズムが存在することは明らかです（セクション7.3.3）。これらの輻輳制御メカニズムは、送信者への輻輳イベントのタイムリーなフィードバックを必要としません。そのような輻輳制御メカニズムが、Leap-of-Faithメソッド（セクション7.2.3）またはICEベースのメソッド（セクション7.2.2）などの、RTCPを使用したタイムリーなフィードバックを必要としない初期化メソッドと組み合わされている場合、その場合、ECNフィードバック形式もRTP / AVPFプロファイルも必要ないようです。ただし、障害検出は、受信側検出（セクション7.4.1）を使用し、ECNフィードバックメカニズムを使用してそのようなケースを早期に報告することにより、大幅に改善できます。
For interoperability, we mandate the implementation of the RTP/AVPF profile, with both RTCP extensions and the necessary signalling to support a common operations mode. This specification recommends the use of RTP/AVPF in all cases as negotiation of the common interoperability point requires RTP/AVPF, mixed negotiation of RTP/ AVP and RTP/AVPF depending on other SDP attributes in the same media block is difficult, and the fact that fault detection can be improved when using RTP/AVPF.
相互運用性のために、RTP / AVPFプロファイルの実装を義務付け、RTCP拡張と、共通の操作モードをサポートするために必要なシグナリングの両方を使用します。共通の相互運用性ポイントのネゴシエーションにはRTP / AVPFが必要であり、同じメディアブロック内の他のSDP属性に応じたRTP / AVPとRTP / AVPFの混合ネゴシエーションは困難であり、事実この障害検出は、RTP / AVPFを使用すると改善できます。
The use of the ECN feedback format is also recommended, but cases exist where its use is not required because timely feedback is not needed. These will be explicitly noted using the phrase "no timely feedback required" and generally occur in combination with receiver-driven congestion control and with the leap-of-faith and ICE-based initialisation methods. We also note that any receiver-driven congestion control solution that still requires RTCP for signalling of any adaptation information to the sender will still require RTP/ AVPF for timeliness.
ECNフィードバック形式の使用も推奨されますが、タイムリーなフィードバックが必要ないために使用する必要がない場合もあります。これらは、「タイムリーなフィードバックは不要」というフレーズを使用して明示的に示され、一般に、レシーバー主導の輻輳制御と、信頼の飛躍およびICEベースの初期化方法と組み合わせて発生します。また、適応情報を送信者にシグナリングするためにRTCPを必要とする受信者主導の輻輳制御ソリューションでは、適時性のためにRTP / AVPFも必要です。
The solution for using ECN with RTP over UDP/IP consists of four different pieces that together make the solution work:
UDP / IP上のRTPでECNを使用するためのソリューションは、ソリューションを機能させる4つの異なる部分で構成されています。
1. Negotiation of the capability to use ECN with RTP/UDP/IP
1. RTP / UDP / IPでECNを使用する機能の交渉
2. Initiation and initial verification of ECN-capable transport
2. ECN対応トランスポートの開始と初期検証
3. Ongoing use of ECN within an RTP session
3. RTPセッション内でのECNの継続的な使用
4. Handling of dynamic behaviour through failure detection, verification, and fallback
4. 障害の検出、検証、およびフォールバックによる動的動作の処理
Before an RTP session can be created, a signalling protocol is used to negotiate or at least configure session parameters (see Section 7.1). In some topologies, the signalling protocol can also be used to discover the other participants. One of the parameters that must be agreed is the capability of a participant to support ECN. Note that all participants having the capability of supporting ECN does not necessarily imply that ECN is usable in an RTP session, since there may be middleboxes on the path between the participants that don't pass ECN-marked packets (for example, a firewall that blocks traffic with the ECN bits set). This document defines the information that needs to be negotiated and provides a mapping to SDP for use in both declarative and offer/answer contexts.
RTPセッションを作成する前に、シグナリングプロトコルを使用して、セッションパラメータのネゴシエートまたは少なくとも構成を行います（セクション7.1を参照）。一部のトポロジでは、シグナリングプロトコルを使用して他の参加者を検出することもできます。合意する必要があるパラメーターの1つは、ECNをサポートする参加者の能力です。 ECNでマークされたパケットを渡さない参加者間のパス上にミドルボックスが存在する可能性があるため（たとえば、ファイアウォールECNビットが設定されたトラフィックをブロックします）。このドキュメントでは、交渉が必要な情報を定義し、宣言的コンテキストとオファー/アンサーコンテキストの両方で使用するSDPへのマッピングを提供します。
When a sender joins a session for which all participants claim to support ECN, it needs to verify that the ECN support is usable. There are three ways in which this verification can be done:
送信者が、すべての参加者がECNをサポートすると主張するセッションに参加する場合、ECNサポートが使用可能であることを確認する必要があります。この検証を行う方法は3つあります。
o The sender may generate a (small) subset of its RTP data packets with the ECN field of the IP header set to ECT(0) or ECT(1). Each receiver will then send an RTCP feedback packet indicating the reception of the ECT-marked RTP packets. Upon reception of this feedback from each receiver it knows of, the sender can consider ECN functional for its traffic. Each sender does this verification independently. When a new receiver joins an existing RTP session, it will send RTCP reports in the usual manner. If those RTCP reports include ECN information, verification will have succeeded, and sources can continue to send ECT packets. If not, verification fails, and each sender MUST stop using ECN (see Section 7.2.1 for details).
o 送信者は、ECT（0）またはECT（1）に設定されたIPヘッダーのECNフィールドを使用して、RTPデータパケットの（小さい）サブセットを生成できます。次に、各レシーバーは、ECTマークの付いたRTPパケットの受信を示すRTCPフィードバックパケットを送信します。知っている各受信者からこのフィードバックを受信すると、送信者はそのトラフィックのECN機能を検討できます。各送信者はこの検証を個別に行います。新しいレシーバーが既存のRTPセッションに参加すると、通常の方法でRTCPレポートを送信します。これらのRTCPレポートにECN情報が含まれている場合、検証は成功し、ソースはECTパケットを送信し続けることができます。そうでない場合、検証は失敗し、各送信者はECNの使用を停止する必要があります（詳細については、セクション7.2.1を参照してください）。
o Alternatively, ECN support can be verified during an initial end-to-end STUN exchange (for example, as part of ICE connection establishment). After having verified connectivity without ECN capability, an extra STUN exchange, this time with the ECN field set to ECT(0) or ECT(1), is performed on the candidate path that is about to be used. If successful, the path's capability to convey ECN-marked packets is verified. A new STUN attribute is defined to convey feedback that the ECT-marked STUN request was received (see Section 7.2.2), along with an ICE signalling option (Section 6.4) to indicate that the check is to be performed.
o または、最初のエンドツーエンドのSTUN交換中に（たとえば、ICE接続確立の一部として）ECNサポートを確認できます。 ECN機能のない接続を確認した後、今度はECNフィールドがECT（0）またはECT（1）に設定された追加のSTUN交換が、使用されようとしている候補パスで実行されます。成功した場合、ECNマーク付きのパケットを伝達するパスの機能が検証されます。 ECTマークの付いたSTUNリクエストが受信されたというフィードバック（セクション7.2.2を参照）と、チェックが実行されることを示すICEシグナリングオプション（セクション6.4）を伝えるために、新しいSTUN属性が定義されています。
o Thirdly, the sender may make a leap of faith that ECN will work. This is only recommended for applications that know they are running in controlled environments where ECN functionality has been verified through other means. In this mode, it is assumed that ECN works, and the system reacts to failure indicators if the assumption proved wrong. The use of this method relies on a high confidence that ECN operation will be successful or an application where failure is not serious. The impact on the network and other users must be considered when making a leap of faith, so there are limitations on when this method is allowed (see Section 7.2.3).
o 第3に、送信者はECNが機能するという確信を飛躍的に高める可能性があります。これは、ECN機能が他の方法で検証されている制御された環境で実行されていることがわかっているアプリケーションにのみ推奨されます。このモードでは、ECNが機能すると想定され、想定が間違っていることが判明した場合、システムは障害インジケータに反応します。この方法の使用は、ECN操作が成功するという高い信頼性、または障害が深刻でないアプリケーションに依存しています。信頼を飛躍させるときは、ネットワークと他のユーザーへの影響を考慮する必要があるため、この方法を使用できる場合には制限があります（セクション7.2.3を参照）。
The first mechanism, using RTP with RTCP feedback, has the advantage of working for all RTP sessions, but the disadvantages of potential clipping if ECN-marked RTP packets are discarded by middleboxes and slow verification of ECN support. The STUN-based mechanism is faster to verify ECN support but only works in those scenarios supported by end-to-end STUN, such as within an ICE exchange. The third one, leap of faith, has the advantage of avoiding additional tests or complexities and enabling ECN usage from the first media packet. The downside is that if the end-to-end path contains middleboxes that do not pass ECN, the impact on the application can be severe: in the worst case, all media could be lost if a middlebox that discards ECN-marked packets is present. A less severe effect, but still requiring reaction, is the presence of a middlebox that re-marks ECT-marked packets to not-ECT, possibly marking packets with an ECN-CE mark as not-ECT. This could result in increased levels of congestion due to non-responsiveness and impact media quality as applications end up relying on packet loss as an indication of congestion.
RTPとRTCPフィードバックを使用する最初のメカニズムには、すべてのRTPセッションで機能するという利点がありますが、ミドルボックスとECNサポートの検証が遅いためにECNマークの付いたRTPパケットが破棄された場合にクリッピングが発生する可能性があるという欠点があります。 STUNベースのメカニズムはECNサポートの検証が高速ですが、ICE交換内など、エンドツーエンドのSTUNによってサポートされるシナリオでのみ機能します。 3番目の方法は、信頼の飛躍であり、追加のテストや複雑さを回避し、最初のメディアパケットからECNを使用できるという利点があります。欠点は、エンドツーエンドパスにECNを渡さないミドルボックスが含まれている場合、アプリケーションへの影響が深刻になる可能性があります。最悪の場合、ECNマーク付きのパケットを破棄するミドルボックスが存在すると、すべてのメディアが失われる可能性があります。それほど深刻ではないが、依然として反応が必要な影響は、ECTマークの付いたパケットをnot-ECTに再マークするミドルボックスの存在であり、ECN-CEマークの付いたパケットをnot-ECTとしてマークする可能性があります。これは、アプリケーションが輻輳の兆候としてパケット損失に依存することになるため、無応答性のために輻輳レベルが増加し、メディア品質に影響を与える可能性があります。
Once ECN support has been verified (or assumed) to work for all receivers, a sender marks all its RTP packets as ECT packets, while receivers rapidly feed back reports on any ECN-CE marks to the sender using RTCP in RTP/AVPF immediate or early feedback mode, unless no timely feedback is required. Each feedback report indicates the receipt of new ECN-CE marks since the last ECN feedback packet and also counts the total number of ECN-CE-marked packets as a cumulative sum. This is the mechanism to provide the fastest possible feedback to senders about ECN-CE marks. On receipt of an ECN-CE-marked packet, the system must react to congestion as if packet loss has been reported. Section 7.3 describes the ongoing use of ECN within an RTP session.
ECNサポートがすべての受信者に対して機能することが確認（または想定）されると、送信者はすべてのRTPパケットをECTパケットとしてマークし、受信者はRTP / AVPFでRTCPを使用してECN-CEマークに関するレポートを送信者に迅速にフィードバックします。早期フィードバックモード（タイムリーなフィードバックが必要でない場合を除く）。各フィードバックレポートは、最後のECNフィードバックパケット以降の新しいECN-CEマークの受信を示し、ECN-CEマーク付きパケットの総数を累積合計としてカウントします。これは、ECN-CEマークに関する送信者に可能な限り最速のフィードバックを提供するメカニズムです。 ECN-CEでマークされたパケットを受信すると、システムは、パケット損失が報告されたかのように輻輳に反応する必要があります。セクション7.3では、RTPセッション内でのECNの継続的な使用について説明します。
This rapid feedback is not optimised for reliability, so another mechanism, RTCP XR ECN Summary Reports, is used to ensure more reliable, but less timely, reporting of the ECN information. The ECN Summary Report contains the same information as the ECN feedback format, only packed differently for better efficiency with reports for many sources. It is sent in a compound RTCP packet, along with regular RTCP reception reports. By using cumulative counters for observed ECN-CE, ECT, not-ECT, packet duplication, and packet loss, the sender can determine what events have happened since the last report, independently of any RTCP packets having been lost.
この迅速なフィードバックは信頼性が最適化されていないため、別のメカニズムであるRTCP XR ECNサマリーレポートを使用して、ECN情報のレポートの信頼性は向上しますが、タイムリーではなくなります。 ECN要約レポートには、ECNフィードバック形式と同じ情報が含まれていますが、多くのソースのレポートで効率を高めるために異なる方法でのみパックされています。これは、通常のRTCP受信レポートとともに、複合RTCPパケットで送信されます。観測されたECN-CE、ECT、not-ECT、パケット重複、およびパケット損失の累積カウンターを使用することにより、送信者は、RTCPパケットの損失とは関係なく、最後のレポート以降に発生したイベントを判別できます。
RTCP reports MUST NOT be ECT marked, since ECT-marked traffic may be dropped if the path is not ECN compliant. RTCP is used to provide feedback about what has been transmitted and what ECN markings that are received, so it is important that it is received in cases when ECT-marked traffic is not getting through.
パスがECNに準拠していない場合、ECTマークの付いたトラフィックがドロップされる可能性があるため、RTCPレポートにECTマークを付けてはなりません（MUST NOT）。 RTCPは、送信されたものと受信されたECNマーキングについてのフィードバックを提供するために使用されるため、ECTマークの付いたトラフィックが通過しない場合に受信されることが重要です。
There are numerous reasons why the path the RTP packets take from the sender to the receiver may change, e.g., mobility and link failure followed by re-routing around it. Such an event may result in the packet being sent through a node that is ECN non-compliant, thus re-marking or dropping packets with ECT set. To prevent this from impacting the application for longer than necessary, the operation of ECN is constantly monitored by all senders (Section 7.4). Both the RTCP XR ECN Summary Reports and the ECN feedback packets allow the sender to compare the number of ECT(0), ECT(1), and not-ECT-marked packets received with the number that were sent, while also reporting ECN-CE-marked and lost packets. If these numbers do not agree, it can be inferred that the path does not reliably pass ECN-marked packets. A sender detecting a possible ECN non-compliance issue should then stop sending ECT-marked packets to determine if that allows the packets to be correctly delivered. If the issues can be connected to ECN, then ECN usage is suspended.
RTPパケットが送信側から受信側へとたどる経路が変化する理由は数多くあります。たとえば、モビリティやリンク障害、それに続く再ルーティングなどです。このようなイベントが発生すると、パケットはECN非準拠のノードを介して送信されるため、ECTが設定されたパケットを再マーキングまたはドロップします。これが必要以上にアプリケーションに影響を与えるのを防ぐために、ECNの動作はすべての送信者によって常に監視されています（セクション7.4）。 RTCP XR ECNサマリーレポートとECNフィードバックパケットの両方により、送信者は、受信したECT（0）、ECT（1）、および非ECTマーク付きのパケットの数を、送信された数と比較しながら、ECN- CEマークの付いたパケットと失われたパケット。これらの数が一致しない場合は、パスがECNマークの付いたパケットを確実に通過していないと推測できます。 ECNの非準拠の問題の可能性を検出した送信者は、ECTマークの付いたパケットの送信を停止して、パケットが正しく配信されるかどうかを判断する必要があります。問題をECNに関連付けることができる場合、ECNの使用は一時停止されます。
This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585] transport-layer feedback format for reporting urgent ECN information and one RTCP XR [RFC3611] ECN Summary Report block type for regular reporting of the ECN marking information.
このメモは、2つの新しいRTCP拡張を定義します。緊急のECN情報を報告するための1つのRTP / AVPF [RFC4585]トランスポート層フィードバック形式と、ECNマーキング情報を定期的に報告するための1つのRTCP XR [RFC3611] ECN Summary Reportブロックタイプ
This RTP/AVPF transport-layer feedback format is intended for use in RTP/AVPF early or immediate feedback modes when information needs to urgently reach the sender. Thus, its main use is to report reception of an ECN-CE-marked RTP packet so that the sender may perform congestion control or to speed up the initiation procedures by rapidly reporting that the path can support ECN-marked traffic. The feedback format is also defined with reduced-size RTCP [RFC5506] in mind, where RTCP feedback packets may be sent without accompanying Sender or Receiver Reports that would contain the extended highest sequence number and the accumulated number of packet losses. Both are important for ECN to verify functionality and keep track of when CE marking does occur.
このRTP / AVPFトランスポート層フィードバック形式は、情報が送信者に緊急に到達する必要がある場合に、RTP / AVPF初期または即時フィードバックモードで使用することを目的としています。したがって、その主な用途は、ECN-CEマークの付いたRTPパケットの受信を報告して、送信者が輻輳制御を実行できるようにするか、パスがECNマークの付いたトラフィックをサポートできることを迅速に報告して開始手順を高速化することです。フィードバック形式は、縮小サイズのRTCP [RFC5506]も考慮して定義されます。RTCPフィードバックパケットは、拡張された最大シーケンス番号と累積パケット損失数を含む送信者レポートまたは受信者レポートを伴わずに送信できます。 ECNが機能を検証し、CEマーキングがいつ発生するかを追跡するには、どちらも重要です。
The RTP/AVPF transport-layer feedback packet starts with the common header defined by the RTP/AVPF profile [RFC4585], which is reproduced in Figure 1. The FMT field takes the value 8 to indicate that the Feedback Control Information (FCI) contains an ECN Feedback Report, as defined in Figure 2.
RTP / AVPFトランスポート層フィードバックパケットは、RTP / AVPFプロファイル[RFC4585]で定義された共通ヘッダーで始まります。これは、図1に再現されています。FMTフィールドは、フィードバック制御情報（FCI）に図2で定義されているECNフィードバックレポート
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=8 | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 1: RTP/AVPF Common Packet Format for Feedback Messages
図1：フィードバックメッセージのRTP / AVPF共通パケット形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Highest Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ECN Feedback Report Format
図2：ECNフィードバックレポートの形式
The ECN Feedback Report contains the following fields:
ECNフィードバックレポートには、次のフィールドが含まれています。
Extended Highest Sequence Number: The 32-bit extended highest sequence number received, as defined by [RFC3550]. Indicates the highest RTP sequence number to which this report relates.
拡張最大シーケンス番号：[RFC3550]で定義されている、受信した32ビット拡張最大シーケンス番号。このレポートが関係する最大のRTPシーケンス番号を示します。
ECT(0) Counter: The 32-bit cumulative number of RTP packets with ECT(0) received from this SSRC.
ECT（0）カウンター：このSSRCから受信したECT（0）のRTPパケットの32ビット累積数。
ECT(1) Counter: The 32-bit cumulative number of RTP packets with ECT(1) received from this SSRC.
ECT（1）カウンター：このSSRCから受信したECT（1）のRTPパケットの32ビット累積数。
ECN-CE Counter: The cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that were ECN-CE marked, including ECN-CE marks in any duplicate packets. The receiver should keep track of this value using a local representation that is at least 32 bits and only include the 16 bits with least significance. In other words, the field will wrap if more than 65535 ECN-CE-marked packets have been received.
ECN-CEカウンター：重複パケット内のECN-CEマークを含め、ECN-CEマークが付けられたRTPセッションに受信者が参加してからこのSSRCから受信したRTPパケットの累積数。受信者は、少なくとも32ビットのローカル表現を使用してこの値を追跡し、重要度の最も低い16ビットのみを含める必要があります。つまり、65535を超えるECN-CEマークの付いたパケットを受信した場合、フィールドは折り返されます。
not-ECT Counter: The cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that had an ECN field value of not-ECT. The receiver should keep track of this value using a local representation that is at least 32 bits and only include the 16 bits with least significance. In other words, the field will wrap if more than 65535 not-ECT packets have been received.
not-ECTカウンター：ECNフィールド値がnot-ECTのRTPセッションに受信者が参加してから、このSSRCから受信したRTPパケットの累積数。受信者は、少なくとも32ビットのローカル表現を使用してこの値を追跡し、重要度の最も低い16ビットのみを含める必要があります。つまり、65535を超えるnot-ECTパケットが受信された場合、フィールドは折り返されます。
Lost Packets Counter: The cumulative number of RTP packets that the receiver expected to receive minus the number of packets it actually received that are not a duplicate of an already received packet, from this SSRC since the receiver joined the RTP session. Note that packets that arrive late are not counted as lost. The receiver should keep track of this value using a local representation that is at least 32 bits and only include the 16 bits with least significance. In other words, the field will wrap if more than 65535 packets are lost.
Lost Packets Counter：レシーバーがRTPセッションに参加してから、このSSRCから受信した、受信したと予想されるRTPパケットの数から、実際に受信したパケットの数から、既に受信したパケットの複製ではない数を引いたもの。遅れて到着したパケットは失われたものとして数えられないことに注意してください。受信者は、少なくとも32ビットのローカル表現を使用してこの値を追跡し、重要度の最も低い16ビットのみを含める必要があります。つまり、65535を超えるパケットが失われた場合、フィールドは折り返されます。
Duplication Counter: The cumulative number of RTP packets received that are a duplicate of an already received packet from this SSRC since the receiver joined the RTP session. The receiver should keep track of this value using a local representation that is at least 32 bits and only include the 16 bits with least significance. In other words, the field will wrap if more than 65535 duplicate packets have been received.
重複カウンター：受信者がRTPセッションに参加してから、このSSRCから既に受信したパケットの複製である受信RTPパケットの累積数。受信者は、少なくとも32ビットのローカル表現を使用してこの値を追跡し、重要度の最も低い16ビットのみを含める必要があります。つまり、65535を超える重複パケットを受信した場合、フィールドは折り返されます。
All fields in the ECN Feedback Report are unsigned integers in network byte order. Each ECN Feedback Report corresponds to a single RTP source (SSRC). Multiple sources can be reported by including multiple ECN Feedback Report packets in an compound RTCP packet.
ECNフィードバックレポートのすべてのフィールドは、ネットワークバイトオーダーの符号なし整数です。各ECNフィードバックレポートは、単一のRTPソース（SSRC）に対応しています。複合RTCPパケットに複数のECNフィードバックレポートパケットを含めることで、複数のソースを報告できます。
The counters SHALL be initiated to 0 for each new SSRC received. This enables detection of ECN-CE marks or packet loss on the initial report from a specific participant.
カウンターは、新しいSSRCが受信されるたびに0に開始される必要があります（SHALL）。これにより、特定の参加者からの最初のレポートでECN-CEマークまたはパケット損失を検出できます。
The use of at least 32-bit counters allows even extremely high packet volume applications to not have wrapping of counters within any timescale close to the RTCP reporting intervals. However, 32 bits are not sufficiently large to disregard the fact that wrappings may happen during the lifetime of a long-lived RTP session, and implementations need to be written to handle wrapping of the counters. It is recommended that implementations use local representation of these counters that are longer than 32 bits to enable easy handling of wraps.
少なくとも32ビットのカウンターを使用すると、非常に大きなパケットボリュームのアプリケーションでも、RTCPレポート間隔に近いタイムスケール内でカウンターを折り返すことができなくなります。ただし、32ビットは、長命のRTPセッションの存続期間中にラッピングが発生する可能性があるという事実を無視するのに十分な大きさではなく、カウンターのラッピングを処理する実装を作成する必要があります。実装では、ラップを簡単に処理できるように、32ビットより長いこれらのカウンターのローカル表現を使用することをお勧めします。
There is a difference in packet duplication reports between the packet loss counter that is defined in the Receiver Report Block [RFC3550] and that defined here. To avoid holding state for what RTP sequence numbers have been received, [RFC3550] specifies that one can count packet loss by counting the number of received packets and comparing that to the number of packets expected. As a result, a packet duplication can hide a packet loss. However, when populating the ECN Feedback Report, a receiver needs to track the sequence numbers actually received and count duplicates and packet loss separately to provide a more reliable indication. Reordering may, however, still result in packet loss being reported in one report and then removed in the next.
レシーバレポートブロック[RFC3550]で定義されているパケット損失カウンタと、ここで定義されているパケット損失カウンタの間には、パケット重複レポートに違いがあります。受信したRTPシーケンス番号の状態の保持を回避するために、[RFC3550]は、受信したパケットの数をカウントし、それを予想されるパケットの数と比較することにより、パケット損失をカウントできると規定しています。その結果、パケットの重複により、パケット損失を隠すことができます。ただし、ECNフィードバックレポートに入力する場合、受信者は実際に受信したシーケンス番号を追跡し、重複とパケット損失を個別にカウントして、より信頼性の高い指標を提供する必要があります。ただし、並べ替えを行うと、パケット損失が1つのレポートで報告され、次のレポートで削除される可能性があります。
The ECN-CE counter is robust for packet duplication. Adding each received ECN-CE-marked packet to the counter is not an issue; in fact, it is required to ensure complete tracking of the ECN state. If one of the clones was ECN-CE marked, that is still an indication of congestion. Packet duplication has a potential impact on the ECN verification, and there is thus a need to count the duplicates.
ECN-CEカウンターは、パケットの複製に対して堅牢です。受信した各ECN-CEマーク付きパケットをカウンターに追加することは問題ではありません。実際には、ECN状態を完全に追跡する必要があります。クローンの1つにECN-CEマークが付いていた場合は、それでも輻輳の兆候です。パケットの重複は、ECN検証に影響を与える可能性があるため、重複をカウントする必要があります。
This unilateral XR report block combined with RTCP SR or RR report blocks carries the same information as the ECN Feedback Report and is based on the same underlying information. However, the ECN Feedback Report is intended to report an ECN-CE mark as soon as possible, while this extended report is for the regular RTCP reporting and continuous verification of the ECN functionality end-to-end.
RTCP SRまたはRRレポートブロックと組み合わせたこの一方的なXRレポートブロックは、ECNフィードバックレポートと同じ情報を伝達し、同じ基礎情報に基づいています。ただし、ECNフィードバックレポートは、ECN-CEマークをできるだけ早く報告することを目的としていますが、この拡張レポートは、定期的なRTCPレポートとエンドツーエンドのECN機能の継続的な検証を目的としています。
The ECN Summary Report block consists of one RTCP XR report block header, shown in Figure 3 followed by one or more ECN Summary Report data blocks, as defined in Figure 4.
ECNサマリーレポートブロックは、図3に示す1つのRTCP XRレポートブロックヘッダーで構成され、その後に、図4で定義されている1つ以上のECNサマリーレポートデータブロックが続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=13 | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RTCP XR Report Header
図3：RTCP XRレポートヘッダー
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTCP XR ECN Summary Report
図4：RTCP XR ECN要約レポート
The RTCP XR ECN Summary Report contains the following fields:
RTCP XR ECN要約レポートには、次のフィールドが含まれています。
BT: Block Type identifying the ECN Summary Report block. Value is 13.
BT：ECNサマリーレポートブロックを識別するブロックタイプ。値は13です。
Reserved: All bits SHALL be set to 0 on transmission and ignored on reception.
予約済み：すべてのビットは送信時に0に設定され、受信時に無視される必要があります（SHALL）。
Block Length: The length of this XR report block, including the header, in 32-bit words minus one. Used to indicate the number of ECN Summary Report data blocks present in the ECN Summary Report. This length will be 5*n, where n is the number of ECN Summary Report blocks, since blocks are a fixed size. The block length MAY be zero if there is nothing to report. Receivers MUST discard reports where the block length is not a multiple of five, since these cannot be valid.
ブロック長：32ビットワードから1を引いた、ヘッダーを含むこのXRレポートブロックの長さ。 ECN要約レポートに存在するECN要約レポートデータブロックの数を示すために使用されます。ブロックは固定サイズであるため、この長さは5 * nになります。nはECNサマリーレポートブロックの数です。報告するものがない場合、ブロック長はゼロになる場合があります。レシーバーは、ブロック長が5の倍数でないレポートを破棄する必要があります。これらは有効ではないためです。
SSRC of Media Sender: The SSRC identifying the media sender this report is for.
メディア送信者のSSRC：このレポートの対象となるメディア送信者を識別するSSRC。
ECT(0) Counter: as in Section 5.1.
ECT（0）カウンター：セクション5.1と同様。
ECT(1) Counter: as in Section 5.1.
ECT（1）カウンター：セクション5.1と同様。
ECN-CE Counter: as in Section 5.1.
ECN-CEカウンター：セクション5.1と同様。
not-ECT Counter: as in Section 5.1.
not-ECTカウンター：セクション5.1と同様。
Lost Packets Counter: as in Section 5.1.
Lost Packets Counter：セクション5.1と同様。
Duplication Counter: as in Section 5.1.
複製カウンター：セクション5.1と同様。
The extended highest sequence number counter for each SSRC is not present in an RTCP XR report, in contrast to the feedback version. The reason is that this summary report will rely on the information sent in the Sender Report (SR) or Receiver Report (RR) blocks part of the same RTCP compound packet. The extended highest sequence number is available from the SR or RR.
各SSRCの拡張された最大シーケンス番号カウンターは、フィードバックバージョンとは異なり、RTCP XRレポートには存在しません。その理由は、この要約レポートが送信者レポート（SR）または受信者レポート（RR）で送信された情報に依存するため、同じRTCP複合パケットの一部がブロックされるためです。拡張された最大シーケンス番号は、SRまたはRRから取得できます。
All the SSRCs that are present in the SR or RR SHOULD also be included in the RTCP XR ECN Summary Report. In cases where the number of senders are so large that the combination of SR/RR and the ECN summary for all the senders exceed the MTU, then only a subset of the senders SHOULD be included so that the reports for the subset fits within the MTU. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are periodically reported. In case there are no SSRCs that currently are counted as senders in the session, the report block SHALL still be sent with no report block entry and a zero report block length to continuously indicate to the other participants the receiver capability to report ECN information.
SRまたはRRに存在するすべてのSSRCも、RTCP XR ECN要約レポートに含める必要があります（SHOULD）。送信者の数が非常に多く、すべての送信者のSR / RRとECNサマリーの組み合わせがMTUを超える場合、サブセットのレポートがMTU内に収まるように、送信者のサブセットのみを含める必要があります（SHOULD）。 。すべてのソースが定期的に報告されるように、サブセットは複数の間隔でラウンドロビンで選択する必要があります（SHOULD）。現在セッションで送信者としてカウントされているSSRCがない場合でも、レポートブロックエントリは送信されず、レポートブロック長が0のレポートブロックが送信されて、ECN情報をレポートする受信機能を他の参加者に継続的に示します。
This section defines a number of SDP signalling extensions used in the negotiation of the ECN for RTP support when using SDP. This includes one SDP attribute "a=ecn-capable-rtp:" that negotiates the actual operation of ECN for RTP. Two SDP signalling parameters are defined to indicate the use of the RTCP XR ECN summary block and the RTP/AVPF feedback format for ECN. One ICE option SDP representation is also defined.
このセクションでは、SDP使用時のRTPサポートのためのECNのネゴシエーションで使用されるSDPシグナリング拡張の数を定義します。これには、RTPのECNの実際の操作をネゴシエートする1つのSDP属性「a = ecn-capable-rtp：」が含まれます。 RTCP XR ECNサマリーブロックとECNのRTP / AVPFフィードバック形式の使用を示すために、2つのSDPシグナリングパラメータが定義されています。 1つのICEオプションSDP表現も定義されています。
One new SDP attribute, "a=ecn-capable-rtp:", is defined. This is a media-level attribute and MUST NOT be used at the session level. It is not subject to the character set chosen. The aim of this signalling is to indicate the capability of the sender and receivers to support ECN, and to negotiate the method of ECN initiation to be used in the session. The attribute takes a list of initiation methods, ordered in decreasing preference. The defined values for the initiation method are:
1つの新しいSDP属性「a = ecn-capable-rtp：」が定義されています。これはメディアレベルの属性であり、セッションレベルで使用してはなりません。選択した文字セットの影響を受けません。このシグナリングの目的は、ECNをサポートする送信側と受信側の機能を示し、セッションで使用されるECN開始の方法をネゴシエートすることです。この属性は、優先順位の高い順に並べられた開始メソッドのリストを取ります。開始メソッドに定義されている値は次のとおりです。
rtp: Using RTP and RTCP as defined in Section 7.2.1.
rtp：セクション7.2.1で定義されているRTPおよびRTCPの使用。
ice: Using STUN within ICE as defined in Section 7.2.2.
ice：セクション7.2.2で定義されているように、ICE内でSTUNを使用します。
leap: Using the leap-of-faith method as defined in Section 7.2.3.
leap：セクション7.2.3で定義されているleap-of-faithメソッドを使用します。
Further methods may be specified in the future, so unknown methods MUST be ignored upon reception.
今後さらにメソッドが指定される可能性があるため、不明なメソッドは受信時に無視する必要があります。
In addition, a number of OPTIONAL parameters may be included in the "a=ecn-capable-rtp:" attribute as follows:
さらに、次のように、「a = ecn-capable-rtp：」属性にいくつかのオプションパラメータを含めることができます。
mode: This parameter signals the endpoint's capability to set and read ECN marks in UDP packets. An examination of various operating systems has shown that end-system support for ECN marking of UDP packets may be symmetric or asymmetric. By this, we mean that some systems may allow endpoints to set the ECN bits in an outgoing UDP packet but not read them, while others may allow applications to read the ECN bits but not set them. This either/or case may produce an asymmetric support for ECN and thus should be conveyed in the SDP signalling. The "mode=setread" state is the ideal condition where an endpoint can both set and read ECN bits in UDP packets. The "mode=setonly" state indicates that an endpoint can set the ECT bit but cannot read the ECN bits from received UDP packets to determine if upstream congestion occurred. The "mode=readonly" state indicates that the endpoint can read the ECN bits to determine if congestion has occurred for incoming packets, but it cannot set the ECT bits in outgoing UDP packets. When the "mode=" parameter is omitted, it is assumed that the node has "setread" capabilities. This option can provide for an early indication that ECN cannot be used in a session. This would be the case when both the offerer and answerer set the "mode=" parameter to "setonly" or both set it to "readonly".
mode：このパラメーターは、UDPパケットでECNマークを設定および読み取るエンドポイントの機能を示します。さまざまなオペレーティングシステムを調べたところ、UDPパケットのECNマーキングに対するエンドシステムサポートは対称的または非対称的である可能性があることがわかりました。つまり、一部のシステムでは、エンドポイントが発信UDPパケットのECNビットを設定して読み取ることはできないが、アプリケーションがECNビットを読み取ることはできるが設定できない場合があります。このいずれかまたは両方のケースは、ECNの非対称サポートを生成する可能性があるため、SDPシグナリングで伝達する必要があります。 「mode = setread」状態は、エンドポイントがUDPパケットのECNビットを設定および読み取ることができる理想的な状態です。 「mode = setonly」状態は、エンドポイントはECTビットを設定できますが、受信したUDPパケットからECNビットを読み取って、アップストリームの輻輳が発生したかどうかを判断できないことを示します。 「mode = readonly」状態は、エンドポイントはECNビットを読み取って、着信パケットに輻輳が発生しているかどうかを判別できますが、発信UDPパケットにECTビットを設定できないことを示します。 「mode =」パラメーターを省略すると、ノードに「setread」機能があると見なされます。このオプションは、ECNがセッションで使用できないことを早期に示すことができます。これは、申し出者と回答者の両方が「mode =」パラメーターを「setonly」に設定した場合、または両方が「readonly」に設定した場合に当てはまります。
ect: This parameter makes it possible to express the preferred ECT marking. This is either "random", "0", or "1", with "0" being implied if not specified. The "ect" parameter describes a receiver preference and is useful in the case where the receiver knows it is behind a link using IP header compression, the efficiency of which would be seriously disrupted if it were to receive packets with randomly chosen ECT marks. It is RECOMMENDED that ECT(0) marking be used.
ect：このパラメーターは、優先ECTマーキングを表現することを可能にします。これは「ランダム」、「0」、または「1」のいずれかであり、指定されていない場合は「0」が暗黙指定されます。 「ect」パラメータは、受信者の設定を示し、IPヘッダー圧縮を使用してリンクの背後にあることが受信者にわかっている場合に役立ちます。ランダムに選択されたECTマークのあるパケットを受信すると、効率が著しく低下します。 ECT（0）マーキングを使用することをお勧めします。
The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp:" attribute is shown in Figure 5.
「a = ecn-capable-rtp：」属性のABNF [RFC5234]文法を図5に示します。
ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list]
init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token
parm-list = parm-value *(";" SP parm-value)
parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly")
ect = "ect=" ("0" / "1" / "random")
parm-ext = parm-name "=" parm-value-ext
parm-name = token
parm-value-ext = token / quoted-string
quoted-string = ( DQUOTE *qdtext DQUOTE )
qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII
; No DQUOTE and no "\"
quoted-pair = "\\" / ( "\" DQUOTE )
UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
; external references:
; token from RFC 4566
; SP and DQUOTE from RFC 5234
; UTF8-1, UTF8-2, UTF8-3, and UTF8-4 from RFC 3629
Figure 5: ABNF Grammar for the "a=ecn-capable-rtp:" Attribute
Note the above quoted string construct has an escaping mechanism for strings containing ". This uses \ (backslash) as an escaping mechanism, i.e., a " is replaced by \" (backslash double quote) and any \ (backslash) is replaced by \\ (backslash backslash) when put into the double quotes as defined by the above syntax. The string in a quoted string is UTF-8 [RFC3629].
上記の引用文字列構成には、 "を含む文字列のエスケープメカニズムがあります。これはエスケープメカニズムとして\（バックスラッシュ）を使用します。つまり、"は\に置き換えられます（バックスラッシュの二重引用符）。\（バックスラッシュ）は\に置き換えられます。 \（バックスラッシュバックスラッシュ）上記の構文で定義されているように二重引用符で囲まれている場合引用符で囲まれた文字列の文字列はUTF-8 [RFC3629]です。
When SDP is used with the offer/answer model [RFC3264], the party generating the SDP offer MUST insert an "a=ecn-capable-rtp:" attribute into the media section of the SDP offer of each RTP session for which it wishes to use ECN. The attribute includes one or more ECN initiation methods in a comma-separated list in decreasing order of preference, with any number of optional parameters following. The answering party compares the list of initiation methods in the offer with those it supports in order of preference. If there is a match and if the receiver wishes to attempt to use ECN in the session, it includes an "a=ecn-capable-rtp:" attribute containing its single preferred choice of initiation method, and any optional parameters, in the media sections of the answer. If there is no matching initiation method capability, or if the receiver does not wish to attempt to use ECN in the session, it does not include an "a=ecn-- capable-rtp:" attribute in its answer. If the attribute is removed in the answer, then ECN MUST NOT be used in any direction for that media flow. If there are initialisation methods that are unknown, they MUST be ignored on reception and MUST NOT be included in an answer.
SDPがオファー/アンサーモデル[RFC3264]で使用される場合、SDPオファーを生成するパーティは、「a = ecn-capable-rtp：」属性を、それが望む各RTPセッションのSDPオファーのメディアセクションに挿入する必要があります。 ECNを使用する。この属性には、1つ以上のECN開始メソッドが、優先順位の降順でコンマ区切りのリストに含まれ、その後に任意の数のオプションパラメーターが続きます。応答側は、オファー内の開始方法のリストを、サポートする方法と優先順に比較します。一致があり、受信者がセッションでECNを使用しようとする場合は、「a = ecn-capable-rtp：」属性が含まれます。これには、開始方法の1つの優先選択と、オプションのパラメーターが含まれます。答えのセクション。一致する開始メソッド機能がない場合、または受信者がセッションでECNを使用しようとしない場合は、その回答に「a = ecn--capable-rtp：」属性は含まれません。回答で属性が削除された場合、ECNはそのメディアフローのどの方向にも使用してはなりません（MUST NOT）。不明な初期化メソッドがある場合、それらは受信時に無視する必要があり、応答に含めてはなりません（MUST NOT）。
The endpoints' capability to set and read ECN marks, as expressed by the optional "mode=" parameter, determines whether ECN support can be negotiated for flows in one or both directions:
ECNマークを設定して読み取るエンドポイントの機能は、オプションの「mode =」パラメーターで表され、フローのECNサポートを一方向または双方向でネゴシエートできるかどうかを決定します。
o If the "mode=setonly" parameter is present in the "a=ecn-capable-rtp:" attribute of the offer and the answering party is also "mode=setonly", then there is no common ECN capability, and the answer MUST NOT include the "a=ecn-capable-rtp:" attribute. Otherwise, if the offer is "mode=setonly", then ECN may only be initiated in the direction from the offering party to the answering party.
o 「mode = setonly」パラメーターがオファーの「a = ecn-capable-rtp：」属性に存在し、応答側も「mode = setonly」である場合、共通のECN機能はなく、回答は必須です。 「a = ecn-capable-rtp：」属性を含めないでください。それ以外の場合、オファーが「mode = setonly」の場合、ECNはオファー側から応答側への方向でのみ開始できます。
o If the "mode=readonly" parameter is present in the "a=ecn-capable-rtp:" attribute of the offer and the answering party is "mode=readonly", then there is no common ECN capability, and the answer MUST NOT include the "a=ecn-capable-rtp:" attribute. Otherwise, if the offer is "mode=readonly", then ECN may only be initiated in the direction from the answering party to the offering party.
o 「mode = readonly」パラメーターがオファーの「a = ecn-capable-rtp：」属性に存在し、応答側が「mode = readonly」である場合、共通のECN機能はなく、回答は「a = ecn-capable-rtp：」属性を含めます。それ以外の場合、オファーが「mode = readonly」の場合、ECNは応答側から提供側への方向でのみ開始できます。
o If the "mode=setread" parameter is present in the "a=ecn-capable-rtp:" attribute of the offer and the answering party is "setonly", then ECN may only be initiated in the direction from the answering party to the offering party. If the offering party is "mode=setread" but the answering party is "mode=readonly", then ECN may only be initiated in the direction from the offering party to the answering party. If both offer and answer are "mode=setread", then ECN may be initiated in both directions. Note that "mode=setread" is implied by the absence of a "mode=" parameter in the offer or the answer.
o 「mode = setread」パラメーターがオファーの「a = ecn-capable-rtp：」属性に存在し、応答側が「setonly」の場合、ECNは応答側から提供パーティー。提供側が「mode = setread」で、応答側が「mode = readonly」の場合、ECNは、提供側から応答側への方向でのみ開始できます。オファーとアンサーの両方が "mode = setread"の場合、ECNは両方向で開始できます。 「mode = setread」は、オファーまたはアンサーに「mode =」パラメーターがないことを意味していることに注意してください。
o An offer that does not include a "mode=" parameter MUST be treated as if a "mode=setread" parameter had been included.
o 「mode =」パラメーターを含まないオファーは、「mode = setread」パラメーターが含まれているかのように扱わなければなりません（MUST）。
In an RTP session using multicast and ECN, participants that intend to send RTP packets SHOULD support setting ECT marks in RTP packets (i.e., should be "mode=setonly" or "mode=setread"). Participants receiving data need the capability to read ECN marks on incoming packets. It is important that receivers can read ECN marks ("mode=readonly" or "mode=setread"), since otherwise no sender in the multicast session would be able to enable ECN. Accordingly, receivers that are "mode=setonly" SHOULD NOT join multicast RTP sessions that use ECN. If session participants that are not aware of the ECN for RTP signalling are invited to a multicast session and simply ignore the signalling attribute, the other party in the offer/ answer exchange SHOULD terminate the SDP dialogue so that the participant leaves the session.
マルチキャストとECNを使用するRTPセッションでは、RTPパケットを送信するつもりの参加者は、RTPパケットでのECTマークの設定をサポートする必要があります（つまり、「mode = setonly」または「mode = setread」である必要があります）。データを受信する参加者には、着信パケットのECNマークを読み取る機能が必要です。受信者がECNマークを読み取ることができることが重要です（ "mode = readonly"または "mode = setread"）。そうしないと、マルチキャストセッションの送信者はECNを有効にできません。したがって、「mode = setonly」である受信者は、ECNを使用するマルチキャストRTPセッションに参加してはなりません（SHOULD NOT）。 RTPシグナリングのECNを認識していないセッション参加者がマルチキャストセッションに招待され、シグナリング属性を単に無視する場合、オファー/アンサー交換の相手はSDPダイアログを終了して、参加者がセッションを離れるようにする必要があります（SHOULD）。
The "ect=" parameter in the "a=ecn-capable-rtp:" attribute is set independently in the offer and the answer. Its value in the offer indicates a preference for the sending behaviour of the answering party, and its value in the answer indicates a sending preference for the behaviour of the offering party. It will be the sender's choice to honour the receiver's preference for what to receive or not. In multicast sessions, all senders SHOULD set the ECT marks using the value declared in the "ect=" parameter.
「a = ecn-capable-rtp：」属性の「ect =」パラメーターは、オファーとアンサーで個別に設定されます。オファー内のその値は、応答側の送信動作の優先を示し、アンサー内のその値は、提供側の動作の送信優先を示します。何を受信するかしないかの受信者の設定を尊重するのは送信者の選択になります。マルチキャストセッションでは、すべての送信者が「ect =」パラメーターで宣言された値を使用してECTマークを設定する必要があります（SHOULD）。
Unknown optional parameters MUST be ignored on reception and MUST NOT be included in the answer. That way, a new parameter may be introduced and verified as supported by the other endpoint by having the endpoint include it in any answer.
不明なオプションパラメータは、受信時に無視する必要があり、応答に含めることはできません。このようにして、エンドポイントに回答に含めさせることで、新しいパラメーターを導入し、他のエンドポイントでサポートされているように検証できます。
When SDP is used in a declarative manner, for example, in a multicast session using the Session Announcement Protocol (SAP) [RFC2974], negotiation of session description parameters is not possible. The "a=ecn-capable-rtp:" attribute MAY be added to the session description to indicate that the sender will use ECN in the RTP session. The attribute MUST include a single method of initiation. Participants MUST NOT join such a session unless they have the capability to receive ECN-marked UDP packets, implement the method of initiation, and generate RTCP ECN feedback. The mode parameter MAY also be included in declarative usage, to indicate the minimal capability is required by the consumer of the SDP. So, for example, in an SSM session, the participants configured with a particular SDP will all be in a media receive-only mode; thus, "mode=readonly" may be used as the receiver only needs to be able to report on the ECN markings. In ASM sessions, using "mode=readonly" is also reasonable, unless all senders are required to attempt to use ECN for their outgoing RTP data traffic, in which case the mode needs to be set to "setread".
SDPが宣言的な方法で使用されている場合、たとえば、Session Announcement Protocol（SAP）[RFC2974]を使用したマルチキャストセッションでは、セッション記述パラメータのネゴシエーションは不可能です。 「a = ecn-capable-rtp：」属性をセッションの説明に追加して、送信者がRTPセッションでECNを使用することを示すことができます。属性には、単一の開始方法を含める必要があります。参加者は、ECNマークの付いたUDPパケットを受信し、開始方法を実装し、RTCP ECNフィードバックを生成する機能がない限り、そのようなセッションに参加してはなりません（MUST NOT）。 SDPのコンシューマーが必要とする最小限の機能を示すために、モードパラメーターも宣言的な使用法に含めることができます。したがって、たとえば、SSMセッションでは、特定のSDPで構成された参加者はすべてメディア受信専用モードになります。したがって、「mode = readonly」は、受信者がECNマーキングについてレポートできる必要があるだけなので、使用できます。 ASMセッションでは、すべての送信者が発信RTPデータトラフィックにECNを使用する必要がある場合を除き、「mode = readonly」を使用することも妥当です。この場合、モードを「setread」に設定する必要があります。
The "a=ecn-capable-rtp:" attribute MAY be used with RTP media sessions using UDP/IP transport. It MUST NOT be used for RTP sessions using TCP, SCTP, or DCCP transport or for non-RTP sessions.
「a = ecn-capable-rtp：」属性は、UDP / IPトランスポートを使用するRTPメディアセッションで使用できます。 TCP、SCTP、またはDCCPトランスポートを使用するRTPセッション、またはRTP以外のセッションには使用しないでください。
As described in Section 7.3.3, RTP sessions using ECN require rapid RTCP ECN feedback, unless timely feedback is not required due to a receiver-driven congestion control. To ensure that the sender can react to ECN-CE-marked packets, timely feedback is usually required. Thus, the use of the Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] or another profile that inherits RTP/AVPF's signalling rules MUST be signalled unless timely feedback is not required. If timely feedback is not required, it is still RECOMMENDED to use RTP/AVPF. The signalling of an RTP/AVPF-based profile is likely to be required even if the preferred method of initialisation and the congestion control do not require timely feedback, as the common interoperable method is likely to be signalled or the improved fault reaction is desired.
セクション7.3.3で説明されているように、ECNを使用するRTPセッションでは、受信者主導の輻輳制御のためにタイムリーなフィードバックが必要でない限り、迅速なRTCP ECNフィードバックが必要です。送信者がECN-CEマークの付いたパケットに確実に反応できるようにするには、通常、タイムリーなフィードバックが必要です。したがって、RTCPベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF）[RFC4585]またはRTP / AVPFのシグナリングルールを継承する別のプロファイルの使用は、タイムリーなフィードバックが必要でない限り、通知する必要があります。タイムリーなフィードバックが必要ない場合でも、RTP / AVPFを使用することをお勧めします。一般的な相互運用可能な方法が通知される可能性が高い、または改善された障害反応が望まれるため、初期化の好ましい方法と輻輳制御がタイムリーなフィードバックを必要としない場合でも、RTP / AVPFベースのプロファイルの通知が必要になる可能性があります。
A new "nack" feedback parameter "ecn" is defined to indicate the usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF [RFC5234] definition of the SDP parameter extension is:
新しい「nack」フィードバックパラメータ「ecn」は、RTCP ECNフィードバックパケット形式の使用を示すために定義されています（セクション5.1）。 SDPパラメータ拡張のABNF [RFC5234]定義は次のとおりです。
rtcp-fb-nack-param = <See Section 4.2 of [RFC4585]>
rtcp-fb-nack-param =/ ecn-fb-par
ecn-fb-par = SP "ecn"
The offer/answer rules for these SDP feedback parameters are specified in the RTP/AVPF profile [RFC4585].
これらのSDPフィードバックパラメータのオファー/アンサールールは、RTP / AVPFプロファイル[RFC4585]で指定されています。
A new unilateral RTCP XR block for ECN summary information is specified; thus, the XR block SDP signalling also needs to be extended with a parameter. This is done in the same way as for the other XR blocks. The XR block SDP attribute as defined in Section 5.1 of the RTCP XR specification [RFC3611] is defined to be extensible. As no parameter values are needed for this ECN summary block, this parameter extension consists of a simple parameter name used to indicate support and intent to use the XR block.
ECNサマリー情報用の新しい一方的なRTCP XRブロックが指定されています。したがって、XRブロックSDPシグナリングもパラメータで拡張する必要があります。これは、他のXRブロックの場合と同じ方法で行われます。 RTCP XR仕様[RFC3611]のセクション5.1で定義されているXRブロックSDP属性は、拡張可能であると定義されています。このECNサマリーブロックにはパラメーター値は必要ないため、このパラメーター拡張は、XRブロックを使用するサポートと意図を示すために使用される単純なパラメーター名で構成されています。
xr-format = <See Section 5.1 of [RFC3611]>
xr-format =/ ecn-summary-par
ecn-summary-par = "ecn-sum"
For SDP declarative and offer/answer usage, see the RTCP XR specification [RFC3611] and its description of how to handle unilateral parameters.
SDP宣言およびオファー/アンサーの使用法については、RTCP XR仕様[RFC3611]と、一方的なパラメーターの処理方法の説明を参照してください。
One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used with the SDP session level "a=ice-options" attribute in an SDP offer to indicate that the initiator of the ICE exchange has the capability to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). The answering party includes this same attribute at the session level in the SDP answer if it also has the capability and removes the attribute if it does not wish to use ECN or doesn't have the capability to use ECN. If the ICE initiation method (Section 7.2.2) is actually going to be used, it is also needs to be explicitly negotiated using the "a=ecn-capable-rtp:" attribute. This ICE option SHALL be included when the ICE initiation method is offered or declared in the SDP.
1つの新しいICE [RFC5245]オプション「rtp + ecn」が定義されています。これは、SDPオファーのSDPセッションレベルの「a = ice-options」属性で使用され、ICE交換の開始者がRTP-over-UDPフローのECNをサポートする機能を持っていることを示します（「a = ice-options ：rtp + ecn "）。応答側には、SDP応答の機能もある場合はセッションレベルでこの同じ属性がSDP応答に含まれ、ECNを使用しない場合やECNを使用する機能がない場合は属性が削除されます。 ICE開始メソッド（セクション7.2.2）が実際に使用される場合は、「a = ecn-capable-rtp：」属性を使用して明示的にネゴシエートする必要もあります。このICEオプションは、ICE開始メソッドがSDPで提供または宣言されている場合に含める必要があります。
Note: This signalling mechanism is not strictly needed as long as the STUN ECN testing capability is used within the context of this document. It may, however, be useful if the ECN verification capability is used in additional contexts.
注：このシグナリングメカニズムは、STUN ECNテスト機能がこのドキュメントのコンテキスト内で使用されている限り、厳密には必要ありません。ただし、ECN検証機能が追加のコンテキストで使用されている場合は便利です。
In the detailed specification of the behaviour below, the different functions in the general case will first be discussed. In case special considerations are needed for middleboxes, multicast usage, etc., those will be specially discussed in related subsections.
以下の動作の詳細な仕様では、一般的な場合のさまざまな機能について最初に説明します。ミドルボックス、マルチキャストの使用などに特別な考慮事項が必要な場合は、関連するサブセクションで特に説明します。
The first stage of ECN negotiation for RTP over UDP is to signal the capability to use ECN. An RTP system that supports ECN and uses SDP for its signalling MUST implement the SDP extension to signal ECN capability as described in Section 6.1, the RTCP ECN feedback SDP parameter defined in Section 6.2, and the XR Block ECN SDP parameter defined in Section 6.3. It MAY also implement alternative ECN capability negotiation schemes, such as the ICE extension described in Section 6.4. Other signalling systems will need to define signalling parameters corresponding to those defined for SDP.
RTP over UDPのECNネゴシエーションの最初の段階は、ECNを使用する機能を通知することです。 ECNをサポートし、そのシグナリングにSDPを使用するRTPシステムは、セクション6.1で説明されているECN機能、セクション6.2で定義されているRTCP ECNフィードバックSDPパラメータ、およびセクション6.3で定義されているXRブロックECN SDPパラメータをシグナリングするSDP拡張を実装する必要があります。セクション6.4で説明されているICE拡張など、代替のECN機能ネゴシエーションスキームも実装できます（MAY）。他の信号システムは、SDPに定義されたものに対応する信号パラメータを定義する必要があります。
The "ecn-capable-rtp:" SDP attribute MUST be used when employing ECN for RTP according to this specification in systems using SDP. As the RTCP XR ECN Summary Report is required independently of the initialisation method or congestion control scheme, the "rtcp-xr" attribute with the "ecn-sum" parameter MUST also be used. The "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used whenever the initialisation method or a congestion control algorithm requires timely sender-side knowledge of received CE markings. If the congestion control scheme requires additional signalling, this should be indicated as appropriate.
SDPを使用するシステムでこの仕様に従ってRTPにECNを使用する場合、「ecn-capable-rtp：」SDP属性を使用する必要があります。 RTCP XR ECNサマリーレポートは、初期化方法や輻輳制御方式とは無関係に必要なので、「ecn-sum」パラメータを指定した「rtcp-xr」属性も使用する必要があります。 「nack」パラメータ「ecn」を含む「rtcp-fb」属性は、初期化方法または輻輳制御アルゴリズムが受信したCEマーキングのタイムリーな送信側の知識を必要とする場合は常に使用する必要があります。輻輳制御方式で追加のシグナリングが必要な場合は、これを適切に示す必要があります。
Once the sender and the receiver(s) have agreed that they have the capability to use ECN within a session, they may attempt to initiate ECN use. All session participants connected over the same transport MUST use the same initiation method. RTP mixers or translators can use different initiation methods to different participants that are connected over different underlying transports. The mixer or translator will need to do individual signalling with each participant to ensure it is consistent with the ECN support in those cases where it does not function as one endpoint for the ECN control loop.
送信者と受信者は、セッション内でECNを使用する機能があることに同意すると、ECNの使用を開始しようとすることがあります。同じトランスポートを介して接続されたすべてのセッション参加者は、同じ開始メソッドを使用する必要があります。 RTPミキサーまたはトランスレーターは、基礎となるさまざまなトランスポートを介して接続されているさまざまな参加者に対して、さまざまな開始方法を使用できます。ミキサーまたはトランスレーターは、ECN制御ループの1つのエンドポイントとして機能しない場合に、ECNサポートとの整合性を確保するために、各参加者と個別にシグナリングする必要があります。
At the start of the RTP session, when the first few packets with ECT are sent, it is important to verify that IP packets with ECN field values of ECT or ECN-CE will reach their destination(s). There is some risk that the use of ECN will result in either reset of the ECN field or loss of all packets with ECT or ECN-CE markings. If the path between the sender and the receivers exhibits either of these behaviours, the sender needs to stop using ECN immediately to protect both the network and the application.
RTPセッションの開始時に、ECTを含む最初のいくつかのパケットが送信されるとき、ECTまたはECN-CEのECNフィールド値を持つIPパケットが宛先に到達することを確認することが重要です。 ECNを使用すると、ECNフィールドがリセットされるか、ECTまたはECN-CEマーキングのあるすべてのパケットが失われるリスクがあります。送信者と受信者の間のパスがこれらの動作のいずれかを示している場合、送信者はネットワークとアプリケーションの両方を保護するためにECNの使用をすぐに停止する必要があります。
The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic at any time. This is to ensure that packet loss due to ECN marking will not effect the RTCP traffic and the necessary feedback information it carries.
RTPの送信者と受信者は、いつでもRTCPトラフィックにマークを付けてはなりません。これは、ECNマーキングによるパケット損失がRTCPトラフィックとそれが運ぶ必要なフィードバック情報に影響を与えないようにするためです。
An RTP system that supports ECN MUST implement the initiation of ECN using in-band RTP and RTCP described in Section 7.2.1. It MAY also implement other mechanisms to initiate ECN support, for example, the STUN-based mechanism described in Section 7.2.2, or use the leap-of-faith option if the session supports the limitations provided in Section 7.2.3. If support for both in-band and out-of-band mechanisms is signalled, the sender when negotiating SHOULD offer detection of ECT using STUN with ICE with higher priority than detection of ECT using RTP and RTCP.
ECNをサポートするRTPシステムは、セクション7.2.1で説明されているインバンドRTPおよびRTCPを使用してECNの開始を実装する必要があります。また、セクション7.2.2で説明されているSTUNベースのメカニズムなど、ECNサポートを開始する他のメカニズムを実装することも、セッションがセクション7.2.3で提供される制限をサポートしている場合は、リープオブフェイスオプションを使用することもできます。帯域内メカニズムと帯域外メカニズムの両方のサポートが通知された場合、ネゴシエーション時に送信者は、RTPおよびRTCPを使用したECTの検出よりも優先度の高い、ICEを使用したSTUNを使用したECTの検出を提供する必要があります（SHOULD）。
No matter how ECN usage is initiated, the sender MUST continually monitor the ability of the network, and all its receivers, to support ECN, following the mechanisms described in Section 7.4. This is necessary because path changes or changes in the receiver population may invalidate the ability of the system to use ECN.
ECNの使用がどのように開始されても、送信者は、セクション7.4で説明されているメカニズムに従って、ネットワークとそのすべての受信者がECNをサポートする能力を継続的に監視する必要があります。これは、パスの変更またはレシーバーの母集団の変更によって、システムがECNを使用する機能が無効になる可能性があるために必要です。
The ECN initiation phase using RTP and RTCP to detect if the network path supports ECN comprises three stages. First, the RTP sender generates some small fraction of its traffic with ECT marks to act as a probe for ECN support. Then, on receipt of these ECT-marked packets, the receivers send RTCP ECN feedback packets and RTCP ECN Summary Reports to inform the sender that their path supports ECN. Finally, the RTP sender makes the decision to use ECN or not, based on whether the paths to all RTP receivers have been verified to support ECN.
ネットワークパスがECNをサポートしているかどうかを検出するためにRTPおよびRTCPを使用するECN開始フェーズは、3つのステージで構成されます。まず、RTP送信者は、ECTマークを使用してトラフィックの一部を生成し、ECNサポートのプローブとして機能します。次に、これらのECTマークの付いたパケットを受信すると、受信者はRTCP ECNフィードバックパケットとRTCP ECNサマリーレポートを送信して、パスがECNをサポートしていることを送信者に通知します。最後に、RTP送信者は、すべてのRTP受信者へのパスがECNをサポートすることが確認されているかどうかに基づいて、ECNを使用するかどうかを決定します。
Generating ECN Probe Packets: During the ECN initiation phase, an RTP sender SHALL mark a small fraction of its RTP traffic as ECT, while leaving the reminder of the packets unmarked. The main reason for only marking some packets is to maintain usable media delivery during the ECN initiation phase in those cases where ECN is not supported by the network path. A secondary reason to send some not-ECT packets is to ensure that the receivers will send RTCP reports on this sender, even if all ECT-marked packets are lost in transit. The not-ECT packets also provide a baseline to compare performance parameters against. Another reason for only probing with a small number of packets is to reduce the risk that significant numbers of congestion markings might be lost if ECT is cleared to not-ECT by an ECN-reverting Middlebox. Then, any resulting lack of congestion response is likely to have little damaging effect on others. An RTP sender is RECOMMENDED to send a minimum of two packets with ECT markings per RTCP reporting interval. In case a random ECT pattern is intended to be used, at least one packet with ECT(0) and one with ECT(1) should be sent per reporting interval; in case a single ECT marking is to be used, only that ECT value SHOULD be sent. The RTP sender SHALL continue to send some ECT-marked traffic as long as the ECN initiation phase continues. The sender SHOULD NOT mark all RTP packets as ECT during the ECN initiation phase.
ECNプローブパケットの生成：ECN開始フェーズ中に、RTP送信者はRTPトラフィックのごく一部をECTとしてマークし、パケットのリマインダーはマークしないままにします。一部のパケットのみをマーキングする主な理由は、ECNがネットワークパスでサポートされていない場合に、ECN開始フェーズ中に使用可能なメディア配信を維持するためです。一部のECT以外のパケットを送信する2番目の理由は、ECTマークの付いたパケットがすべて送信中に失われた場合でも、受信者がこの送信者にRTCPレポートを送信するようにするためです。 not-ECTパケットは、パフォーマンスパラメータを比較するためのベースラインも提供します。少数のパケットでのみプローブするもう1つの理由は、ECNを元に戻すミドルボックスによってECTが非ECTにクリアされた場合に、かなりの数の輻輳マーキングが失われるリスクを減らすためです。次に、結果として生じる輻輳応答の欠如は、他の人にほとんど悪影響を与えない可能性があります。 RTP送信者は、RTCPレポート間隔ごとにECTマーキングを含む最低2つのパケットを送信することをお勧めします。ランダムなECTパターンを使用する場合、レポート間隔ごとに、ECT（0）とECT（1）の少なくとも1つのパケットを送信する必要があります。単一のECTマーキングを使用する場合、そのECT値のみを送信する必要があります（SHOULD）。 RTP送信者は、ECN開始フェーズが続く限り、ECTでマークされたトラフィックを送信し続ける必要があります（SHALL）。送信者は、ECN開始フェーズ中にすべてのRTPパケットをECTとしてマークするべきではありません（SHOULD NOT）。
This memo does not mandate which RTP packets are marked with ECT during the ECN initiation phase. An implementation should insert ECT marks in RTP packets in a way that minimises the impact on media quality if those packets are lost. The choice of packets to mark is very media dependent. For audio formats, it would make sense for the sender to mark comfort noise packets or similar. For video formats, packets containing P- or B-frames (rather than I-frames) would be an appropriate choice. No matter which RTP packets are marked, those packets MUST NOT be sent in duplicate, with and without ECT, since the RTP sequence number is used to identify packets that are received with ECN markings.
このメモは、ECN開始フェーズ中にどのRTPパケットがECTでマークされるかを規定していません。実装では、RTPパケットが失われた場合にメディア品質への影響を最小限に抑える方法で、ECTマークをRTPパケットに挿入する必要があります。マークするパケットの選択は、メディアに大きく依存します。オーディオ形式の場合、送信者がコンフォートノイズパケットなどにマークを付けることは理にかなっています。ビデオ形式の場合、（Iフレームではなく）PフレームまたはBフレームを含むパケットが適切な選択です。 RTPシーケンス番号はECNマーキングで受信されたパケットを識別するために使用されるため、どのRTPパケットがマークされていても、ECTの有無にかかわらず、それらのパケットを重複して送信してはなりません（MUST NOT）。
Generating RTCP ECN Feedback: If ECN capability has been negotiated in an RTP session, the receivers in the session MUST listen for ECT or ECN-CE-marked RTP packets and generate RTCP ECN feedback packets (Section 5.1) to mark their receipt. An immediate or early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD be generated on receipt of the first ECT- or ECN-CE-marked packet from a sender that has not previously sent any ECT traffic. Each regular RTCP report MUST also contain an ECN Summary Report (Section 5.2). Reception of subsequent ECN-CE-marked packets MUST result in additional early or immediate ECN feedback packets being sent unless no timely feedback is required.
RTCP ECNフィードバックの生成：RTPセッションでECN機能がネゴシエートされている場合、セッションの受信者はECTまたはECN-CEでマークされたRTPパケットをリッスンし、受信をマークするためにRTCP ECNフィードバックパケット（セクション5.1）を生成する必要があります。即時または早期（RTP / AVPFモードによって異なります）のECNフィードバックパケットは、以前にECTトラフィックを送信したことがない送信者から最初のECTまたはECN-CEでマークされたパケットを受信すると生成される必要があります。通常の各RTCPレポートには、ECN要約レポート（セクション5.2）も含める必要があります。後続のECN-CEマーク付きパケットを受信すると、タイムリーなフィードバックが必要でない限り、追加の早期または即時のECNフィードバックパケットが送信される必要があります。
Determination of ECN Support: RTP is a group communication protocol, where members can join and leave the group at any time. This complicates the ECN initiation phase, since the sender must wait until it believes the group membership has stabilised before it can determine if the paths to all receivers support ECN (group membership changes after the ECN initiation phase has completed are discussed in Section 7.3).
ECNサポートの決定：RTPはグループ通信プロトコルであり、メンバーはいつでもグループに参加したりグループから脱退したりできます。これは、すべてのレシーバーへのパスがECNをサポートするかどうかを判断する前に、送信者がグループメンバーシップが安定するまで待機する必要があるため、ECN開始フェーズが複雑になります（ECN開始フェーズが完了した後のグループメンバーシップの変更については、セクション7.3で説明します）。
An RTP sender shall consider the group membership to be stable after it has been in the session and sending ECT-marked probe packets for at least three RTCP reporting intervals (i.e., after sending its third regularly scheduled RTCP packet) and when a complete RTCP reporting interval has passed without changes to the group membership. ECN initiation is considered successful when the group membership is stable and all known participants have sent one or more RTCP ECN feedback packets or RTCP XR ECN Summary Reports indicating correct receipt of the ECT-marked RTP packets generated by the sender.
RTP送信者は、セッションに参加し、ECTマークの付いたプローブパケットを少なくとも3つのRTCPレポート間隔（つまり、3番目の定期的にスケジュールされたRTCPパケットを送信した後）送信した後、完全なRTCPレポートを送信した後、グループメンバーシップが安定していると見なします。グループメンバーシップを変更せずに間隔が経過しました。 ECNの開始は、グループメンバーシップが安定していて、既知のすべての参加者が1つ以上のRTCP ECNフィードバックパケットまたはRTCP XR ECNサマリーレポートを送信して、送信者によって生成されたECTマーク付きRTPパケットの正しい受信を示している場合に、成功したと見なされます。
As an optimisation, if an RTP sender is initiating ECN usage towards a unicast address, then it MAY treat the ECN initiation as provisionally successful if it receives an RTCP ECN Feedback Report or an RTCP XR ECN Summary Report indicating successful receipt of the ECT-marked packets, with no negative indications, from a single RTP receiver (where a single RTP receiver is considered as all SSRCs used by a single RTCP CNAME). After declaring provisional success, the sender MAY generate ECT-marked packets as described in Section 7.3, provided it continues to monitor the RTCP reports for a period of three RTCP reporting intervals from the time the ECN initiation started, to check if there are any other participants in the session. Thus, as long as any additional SSRC that report on the ECN usage are using the same RTCP CNAME as the previous reports and they are all indicating functional ECN, the sender may continue. If other participants are detected, i.e., other RTCP CNAMEs, the sender MUST fallback to only ECT-marking a small fraction of its RTP packets, while it determines if ECN can be supported following the full procedure described above. Different RTCP CNAMEs received over a unicast transport may occur when using translators in a multi-party RTP session (e.g., when using a centralised conference bridge).
最適化として、RTP送信者がユニキャストアドレスに向けてECNの使用を開始している場合、ECTマークの付いたRTCP ECNフィードバックレポートまたはRTCP XR ECNサマリーレポートを受信すると、ECNの開始を暫定的に成功として扱うことができます（MAY）。単一のRTPレシーバーからの否定的な指示のないパケット（単一のRTPレシーバーは、単一のRTCP CNAMEによって使用されるすべてのSSRCと見なされます）。暫定的な成功を宣言した後、送信者は、セクション7.3で説明されているように、ECTマークの付いたパケットを生成できます（ただし、ECN開始の開始時から3つのRTCPレポート間隔でRTCPレポートを監視し続け、他に何かがあるかどうかを確認します）。セッションの参加者。したがって、ECNの使用状況をレポートする追加のSSRCが前のレポートと同じRTCP CNAMEを使用しており、それらがすべて機能的なECNを示している限り、送信者は続行できます。他の参加者、つまり他のRTCP CNAMEが検出された場合、送信者は、上記の完全な手順に従ってECNをサポートできるかどうかを判断しながら、RTPパケットのごく一部をECTマーキングするだけにフォールバックする必要があります。マルチパーティRTPセッションでトランスレータを使用している場合（たとえば、集中型会議ブリッジを使用している場合）、ユニキャストトランスポートを介して受信されるさまざまなRTCP CNAMEが発生する可能性があります。
Note: The above optimisation supports peer-to-peer unicast transport with several SSRCs multiplexed onto the same flow (e.g., a single participant with two video cameras or SSRC multiplexed RTP retransmission [RFC4588]). It is desirable to be able to rapidly negotiate ECN support for such a session, but the optimisation above can fail if there are implementations that use the same CNAME for different parts of a distributed implementation that have different transport characteristics (e.g., if a single logical endpoint is split across multiple hosts).
注：上記の最適化は、複数のSSRCが同じフローに多重化されたピアツーピアユニキャストトランスポートをサポートします（たとえば、2つのビデオカメラを持つ単一の参加者またはSSRC多重化されたRTP再送信[RFC4588]）。このようなセッションのECNサポートを迅速にネゴシエートできることが望ましいですが、トランスポート特性が異なる分散実装の異なる部分に同じCNAMEを使用する実装がある場合（たとえば、単一の論理エンドポイントは複数のホストに分割されます）。
ECN initiation is considered to have failed at the instant the initiating RTP sender received an RTCP packet that doesn't contain an RTCP ECN Feedback Report or ECN Summary Report from any RTP session participant that has an RTCP RR with an extended RTP sequence number field that indicates that it should have received multiple (>3) ECT-marked RTP packets. This can be due to failure to support the ECN feedback format by the receiver or some middlebox or the loss of all ECT-marked packets. Both indicate a lack of ECN support.
ECN開始は、開始RTP送信者が、拡張RTPシーケンス番号フィールドを持つRTCP RRを持つRTPセッション参加者から、RTCP ECNフィードバックレポートまたはECN要約レポートを含まないRTCPパケットを受信した瞬間に失敗したと見なされます。複数（> 3）のECTマークの付いたRTPパケットを受信する必要があることを示します。これは、レシーバーまたはミドルボックスによるECNフィードバック形式のサポートの失敗、またはすべてのECTマーク付きパケットの損失が原因である可能性があります。どちらもECNサポートがないことを示しています。
If the ECN negotiation succeeds, this indicates that the path can pass some ECN-marked traffic and that the receivers support ECN feedback. This does not necessarily imply that the path can robustly convey ECN feedback; Section 7.3 describes the ongoing monitoring that must be performed to ensure the path continues to robustly support ECN.
ECNネゴシエーションが成功した場合、これはパスが一部のECNマーク付きトラフィックを通過できること、および受信者がECNフィードバックをサポートしていることを示しています。これは、パスがECNフィードバックを確実に伝達できることを必ずしも意味しません。セクション7.3では、パスがECNを確実にサポートし続けることを保証するために実行する必要がある継続的な監視について説明します。
When a sender or receiver detects ECN failures on paths, they should log these to enable follow up and statistics gathering regarding broken paths. The logging mechanism used is implementation dependent.
送信者または受信者がパスでECN障害を検出した場合、それらをログに記録して、壊れたパスに関するフォローアップと統計収集を有効にする必要があります。使用されるロギングメカニズムは実装に依存します。
This section describes an OPTIONAL method that can be used to avoid media impact and also ensure an ECN-capable path prior to media transmission. This method is considered in the context where the session participants are using ICE [RFC5245] to find working connectivity. We need to use ICE rather than STUN only, as the verification needs to happen from the media sender to the address and port on which the receiver is listening.
このセクションでは、メディアへの影響を回避し、メディア送信前にECN対応パスを確保するために使用できるオプションの方法について説明します。この方法は、セッションの参加者がICE [RFC5245]を使用して機能する接続を見つける状況で考慮されます。検証はメディアセンダーからレシーバーがリッスンしているアドレスとポートに対して行われる必要があるため、STUNのみではなくICEを使用する必要があります。
Note that this method is only applicable to sessions when the remote destinations are unicast addresses. In addition, transport translators that do not terminate the ECN control loop and may distribute received packets to more than one other receiver must either disallow this method (and use the RTP/RTCP method instead) or implement additional handling as discussed below. This is because the ICE initialisation method verifies the underlying transport to one particular address and port. If the receiver at that address and port intends to use the received packets in a multi-point session, then the tested capabilities and the actual session behaviour are not matched.
このメソッドは、リモート宛先がユニキャストアドレスであるセッションにのみ適用できることに注意してください。さらに、ECN制御ループを終了せず、受信したパケットを他の複数のレシーバーに配信する可能性のあるトランスポートトランスレーターは、このメソッドを許可しない（または代わりにRTP / RTCPメソッドを使用する）か、以下で説明する追加の処理を実装する必要があります。これは、ICE初期化メソッドが特定の1つのアドレスとポートへの基になるトランスポートを検証するためです。そのアドレスとポートのレシーバーがマルチポイントセッションで受信したパケットを使用する場合、テストされた機能と実際のセッションの動作は一致しません。
To minimise the impact of setup delay, and to prioritise the fact that one has working connectivity rather than necessarily finding the best ECN-capable network path, this procedure is applied after having performed a successful connectivity check for a candidate, which is nominated for usage. At that point, an additional connectivity check is performed, sending the "ECN-CHECK" attribute in a STUN packet that is ECT marked. On reception of the packet, a STUN server supporting this extension will note the received ECN field value and send a STUN/UDP/IP packet in reply with the ECN field set to not-ECT and an ECN-CHECK attribute included. A STUN server that doesn't understand the extension, or is incapable of reading the ECN values on incoming STUN packets, should follow the rule in the STUN specification for unknown comprehension-optional attributes and ignore the attribute, resulting in the sender receiving a STUN response without the ECN-CHECK STUN attribute.
セットアップ遅延の影響を最小限に抑え、最良のECN対応ネットワークパスを必ずしも見つけるのではなく、接続が機能しているという事実を優先するために、この手順は、候補の接続チェックが正常に実行された後に適用されます。 。その時点で、追加の接続性チェックが実行され、ECTマークが付いたSTUNパケットで「ECN-CHECK」属性が送信されます。パケットを受信すると、この拡張機能をサポートするSTUNサーバーは、受信したECNフィールド値を記録し、ECNフィールドをnot-ECTに設定し、ECN-CHECK属性を含めて、STUN / UDP / IPパケットを返信します。拡張機能を認識しないか、着信STUNパケットのECN値を読み取ることができないSTUNサーバーは、不明な内包オプション属性のSTUN仕様のルールに従い、属性を無視する必要があります。その結果、送信者はSTUNを受信します。 ECN-CHECK STUN属性のない応答。
The ECN STUN checks can be lost on the path, for example, due to the ECT marking but also due to various other non ECN-related reasons causing packet loss. The goal is to detect when the ECT markings are rewritten or if it is the ECT marking that causes packet loss so that the path can be determined as not-ECT. Other reasons for packet loss should not result in a failure to verify the path as ECT. Therefore, a number of retransmissions should be attempted. But, the sender of ECN STUN checks will also have to set a criteria for when it gives up testing for ECN capability on the path. Since the ICE agent has successfully verified the path, an RTT measurement for this path can be performed. To have a high probability of successfully verifying the path, it is RECOMMENDED that the client retransmit the ECN STUN check at least 4 times. The transmission for that flow is stopped when an ECN-CHECK STUN response has been received, which doesn't indicate a retransmission of the request due to a temporary error, or the maximum number of retransmissions has been sent. The ICE agent is recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms) after the last ECN STUN check was sent.
たとえば、ECTマーキングのためだけでなく、パケット損失の原因となる他のさまざまな非ECN関連の理由のために、ECN STUNチェックがパスで失われる可能性があります。目標は、ECTマーキングが書き換えられたとき、またはECTマーキングがパケット損失の原因であるかどうかを検出して、パスがECTでないと判断できるようにすることです。パケット損失の他の理由により、ECTとしてのパスの検証が失敗することはありません。したがって、いくつかの再送信を試行する必要があります。ただし、ECN STUNチェックの送信者は、パス上のECN機能のテストをいつ中止するかの基準も設定する必要があります。 ICEエージェントはパスの検証に成功したため、このパスのRTT測定を実行できます。パスの検証に成功する可能性を高くするには、クライアントがECN STUNチェックを少なくとも4回再送信することをお勧めします。そのフローの送信は、一時的なエラーによる要求の再送信を示さないECN-CHECK STUN応答を受信したとき、または最大数の再送信が送信されたときに停止されます。 ICEエージェントは、最後のECN STUNチェックが送信された後、ECN検証MAX（1.5 * RTT、20 ms）をあきらめることをお勧めします。
The transmission of the ECT-marked STUN connectivity checks containing the ECN-CHECK attribute can be done prior as well in parallel to actual media transmission. Both cases are supported, where the main difference is how aggressively the transmission of the STUN checks are done. The reason for this is to avoid adding additional startup delay until media can flow. If media is required immediately after nomination has occurred, the STUN checks SHALL be done in parallel. If the application does not require media transmission immediately, the verification of ECT SHOULD start using the aggressive mode. At any point in the process until ECT has been verified or found to not work, media transmission MAY be started, and the ICE agent SHALL transition from the aggressive mode to the parallel mode.
ECN-CHECK属性を含むECTマークの付いたSTUN接続性チェックの送信は、実際のメディア送信と並行して、事前に実行することもできます。両方のケースがサポートされており、主な違いは、STUNチェックの送信がいかに積極的に行われるかです。これは、メディアが流れるまでの起動遅延を追加しないようにするためです。指名が行われた直後にメディアが必要な場合、STUNチェックは並行して行われる必要があります（SHALL）。アプリケーションがメディア送信をすぐに必要としない場合、ECTの検証はアグレッシブモードの使用を開始する必要があります。 ECTが検証されるか機能しないことが判明するまでのプロセスの任意の時点で、メディア送信を開始することができ（MAY）、ICEエージェントはアグレッシブモードからパラレルモードに移行する必要があります（SHALL）。
The aggressive mode uses an interval between the retransmissions based on the Ta timer as defined in Section 16.1 for RTP Media Streams in ICE [RFC5245]. The number of ECN STUN checks needing to be sent will depend on the number of ECN-capable flows (N) that is to be established. The interval between each transmission of an ECN-CHECK packet MUST be Ta. In other words, for a given flow being verified for ECT, the retransmission timeout (RTO) is set to Ta*N.
アグレッシブモードでは、ICEのRTPメディアストリームのセクション16.1で定義されているように、Taタイマーに基づいて再送信の間隔を使用します[RFC5245]。送信する必要があるECN STUNチェックの数は、確立されるECN対応フロー（N）の数によって異なります。 ECN-CHECKパケットの各送信間の間隔はTaでなければなりません。つまり、ECTで検証される特定のフローでは、再送信タイムアウト（RTO）がTa * Nに設定されます。
The parallel mode uses transmission intervals in order to prevent the ECT verification checks from increasing the total bitrate more than 10%. As ICE's regular transmission schedule is mimicking a common voice call in amount, to meet that goal for most media flows, setting the retransmission interval to Ta*N*k where k=10 fulfills that goal. Thus, the default behaviour SHALL be to use k=10 when in parallel mode. In cases where the bitrate of the STUN connectivity checks can be determined, they MAY be sent with smaller values of k, but k MUST NOT be smaller than 1, as long as the total bitrate for the connectivity checks are less than 10% of the used media bitrate. The RTP media packets being sent in parallel mode SHALL NOT be ECT marked prior to verification of the path as ECT.
パラレルモードでは、ECT検証チェックによって合計ビットレートが10％を超えないようにするために、送信間隔が使用されます。 ICEの通常の送信スケジュールは一般的な音声通話を模倣しているため、ほとんどのメディアフローでその目標を達成するには、再送信間隔をTa * N * kに設定します。ここで、k = 10はその目標を満たします。したがって、デフォルトの振る舞いは、並列モードでk = 10を使用することです。 STUN接続性チェックのビットレートを決定できる場合は、kの値を小さくして送信できますが、接続性チェックの合計ビットレートが10％未満である限り、kを1より小さくすることはできません。使用されたメディアのビットレート。パラレルモードで送信されるRTPメディアパケットは、パスをECTとして検証する前にECTマークを付けてはなりません（SHALL NOT）。
The STUN ECN-CHECK attribute contains one field and a flag, as shown in Figure 6. The flag indicates whether the echo field contains a valid value or not. The field is the ECN echo field and, when valid, contains the two ECN bits from the packet it echoes back. The ECN-CHECK attribute is a comprehension optional attribute.
図6に示すように、STUN ECN-CHECK属性には1つのフィールドとフラグが含まれています。フラグは、エコーフィールドに有効な値が含まれているかどうかを示します。このフィールドはECNエコーフィールドであり、有効な場合、エコーバックするパケットからの2つのECNビットが含まれます。 ECN-CHECK属性は、オプションの包括的属性です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ECN-CHECK STUN Attribute
図6：ECN-CHECK STUN属性
V: Valid (1 bit) ECN Echo value field is valid when set to 1 and invalid when set 0.
V：有効（1ビット）ECNエコー値フィールドは、1に設定すると有効になり、0に設定すると無効になります。
ECF: ECN Echo value field (2 bits) contains the ECN field value of the STUN packet it echoes back when the field is valid. If invalid, the content is arbitrary.
ECF：ECNエコー値フィールド（2ビット）には、フィールドが有効な場合にエコーバックするSTUNパケットのECNフィールド値が含まれます。無効な場合、コンテンツは任意です。
Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission and SHALL be ignored on reception.
予約済み：予約済みビット（29ビット）は送信時に0に設定し、受信時に無視する必要があります。
This attribute MAY be included in any STUN request to request the ECN field to be echoed back. In STUN requests, the V bit SHALL be set to 0. A compliant STUN server receiving a request with the ECN-CHECK attribute SHALL read the ECN field value of the IP/UDP packet in which the request was received. Upon forming the response, the server SHALL include the ECN-CHECK attribute setting the V bit to valid and include the read value of the ECN field into the ECF field. If the STUN responder was unable to ascertain, due to temporary errors, the ECN value of the STUN request, it SHALL set the V bit in the response to 0. The STUN client may retry immediately.
この属性は、ECNフィールドをエコーバックするように要求するために、STUN要求に含めることができます。 STUN要求では、Vビットを0に設定する必要があります。ECN-CHECK属性を含む要求を受信する準拠STUNサーバーは、要求が受信されたIP / UDPパケットのECNフィールド値を読み取る必要があります。応答を形成すると、サーバーは、Vビットを有効に設定するECN-CHECK属性を含め、ECNフィールドの読み取り値をECFフィールドに含める必要があります（SHALL）。 STUNレスポンダが、STUNリクエストのECN値を一時的なエラーのために確認できなかった場合、レスポンスのVビットを0に設定する必要があります。STUNクライアントはすぐに再試行できます。
The ICE-based initialisation method does require some special consideration when used by a translator. This is especially for transport translators and translators that fragment or reassemble packets, since they do not separate the ECN control loops between the endpoints and the translator. When using ICE-based initiation, such a translator must ensure that any participants joining an RTP session for which ECN has been negotiated are successfully verified in the direction from the translator to the joining participant. Alternatively, it must correctly handle remarking of ECT RTP packets towards that participant. When a new participant joins the session, the translator will perform a check towards the new participant. If that is successfully completed, the ECT properties of the session are maintained for the other senders in the session. If the check fails, then the existing senders will now see a participant that fails to receive ECT. Thus, the failure detection in those senders will eventually detect this. However, to avoid misusing the network on the path from the translator to the new participant, the translator SHALL remark the traffic intended to be forwarded from ECT to not-ECT. Any packets intended to be forwarded that are ECN-CE marked SHALL be discarded and not sent. In cases where the path from a new participant to the translator fails the ECT check, then only that sender will not contribute any ECT-marked traffic towards the translator.
ICEベースの初期化方法では、翻訳者が使用するときに特別な考慮が必要です。これは、エンドポイントとトランスレータの間のECN制御ループを分離しないため、特にトランスポートトランスレータおよびパケットをフラグメント化または再構成するトランスレータに当てはまります。 ICEベースの開始を使用する場合、そのようなトランスレーターは、ECNがネゴシエートされたRTPセッションに参加するすべての参加者が、トランスレーターから参加する参加者への方向で正常に検証されることを確認する必要があります。または、その参加者へのECT RTPパケットのリマーキングを正しく処理する必要があります。新しい参加者がセッションに参加すると、翻訳者は新しい参加者に向けてチェックを実行します。それが正常に完了すると、セッションのECTプロパティがセッション内の他の送信者に対して維持されます。チェックが失敗した場合、既存の送信者には、ECTの受信に失敗した参加者が表示されます。したがって、これらの送信側の障害検出は、最終的にこれを検出します。ただし、トランスレータから新しい参加者へのパス上のネットワークの誤用を回避するために、トランスレータは、ECTからNOT-ECTに転送されることを目的としたトラフィックに注意を払う必要があります。 ECN-CEのマークが付けられた転送対象のパケットは破棄され、送信されません。新しい参加者からトランスレータへのパスがECTチェックに失敗した場合、その送信者のみが、ECTでマークされたトラフィックをトランスレータに送信しません。
This method for initiating ECN usage is a leap of faith that assumes that ECN will work on the used path(s). The method is to go directly to "ongoing use of ECN" as defined in Section 7.3. Thus, all RTP packets MAY be marked as ECT, and the failure detection MUST be used to detect any case when the assumption that the path is ECT capable is wrong. This method is only recommended for controlled environments where the whole path(s) between sender and receiver(s) has been built and verified to be ECT.
ECNの使用を開始するためのこの方法は、ECNが使用されたパスで機能することを前提としています。その方法は、セクション7.3で定義されている「ECNの継続的な使用」に直接進むことです。したがって、すべてのRTPパケットはECTとしてマークされる場合があり、パスがECT対応であるという仮定が間違っている場合は、障害検出を使用してケースを検出する必要があります（MUST）。この方法は、送信者と受信者の間のパス全体が構築され、ECTであることが確認されている制御された環境でのみ推奨されます。
If the sender marks all packets as ECT while transmitting on a path that contains an ECN-blocking middlebox, then receivers downstream of that middlebox will not receive any RTP data packets from the sender and hence will not consider it to be an active RTP SSRC. The sender can detect this and revert to sending packets without ECT marks, since RTCP SR/RR packets from such receivers will either not include a report for the sender's SSRC or will report that no packets have been received, but this takes at least one RTCP reporting interval. It should be noted that a receiver might generate its first RTCP packet immediately on joining a unicast session, or very shortly after joining an RTP/AVPF session, before it has had chance to receive any data packets. A sender that receives an RTCP SR/RR packet indicating lack of reception by a receiver SHOULD therefore wait for a second RTCP report from that receiver to be sure that the lack of reception is due to ECT-marking. Since this recovery process can take several tens of seconds, during which time the RTP session is unusable for media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation method be used in environments where ECN-blocking middleboxes are likely to be present.
送信者がECNブロッキングミドルボックスを含むパスで送信中にすべてのパケットをECTとしてマークすると、そのミドルボックスのダウンストリームの受信者は送信者からRTPデータパケットを受信しないため、アクティブなRTP SSRCとは見なされません。このような受信者からのRTCP SR / RRパケットには送信者のSSRCのレポートが含まれていないか、パケットが受信されなかったと報告されるため、送信者はこれを検出してECTマークなしのパケット送信に戻ることができますが、これには少なくとも1つのRTCPが必要ですレポート間隔。受信側は、ユニキャストセッションに参加した直後に、またはRTP / AVPFセッションに参加した直後に、データパケットを受信する前に、最初のRTCPパケットを生成する場合があることに注意してください。したがって、受信者による受信の欠如を示すRTCP SR / RRパケットを受信する送信者は、その受信者からの2番目のRTCPレポートを待って、受信の欠如がECTマーキングによるものであることを確認する必要があります。この回復プロセスには数十秒かかることがあり、その間RTPセッションはメディアで使用できません。そのため、ECNブロッキングミドルボックスが存在する可能性が高い環境では、Leap-of-Faith ECTの開始方法を使用することはお勧めしません。 。
Once ECN has been successfully initiated for an RTP sender, that sender begins sending all RTP data packets as ECT-marked, and its receivers send ECN feedback information via RTCP packets. This section describes procedures for sending ECT-marked data, providing ECN feedback information via RTCP, and responding to ECN feedback information.
RTP送信者に対してECNが正常に開始されると、その送信者はすべてのRTPデータパケットをECTマーク付きとして送信し始め、その受信者はRTCPパケットを介してECNフィードバック情報を送信します。このセクションでは、ECTマークの付いたデータを送信し、RTCPを介してECNフィードバック情報を提供し、ECNフィードバック情報に応答する手順について説明します。
After a sender has successfully initiated ECN use, it SHOULD mark all the RTP data packets it sends as ECT. The sender SHOULD mark packets as ECT(0) unless the receiver expresses a preference for ECT(1) or for a random ECT value using the "ect" parameter in the "a=ecn-- capable-rtp:" attribute.
送信側がECNの使用を正常に開始した後、送信するすべてのRTPデータパケットをECTとしてマークする必要があります（SHOULD）。送信者は、受信者が「a = ecn--capable-rtp：」属性の「ect」パラメーターを使用してECT（1）またはランダムなECT値の設定を表明しない限り、パケットをECT（0）としてマークする必要があります。
The sender SHALL NOT include ECT marks on outgoing RTCP packets and SHOULD NOT include ECT marks on any other outgoing control messages (e.g., STUN [RFC5389] packets, Datagram Transport Layer Security (DTLS) [RFC6347] handshake packets, or ZRTP [RFC6189] control packets) that are multiplexed on the same UDP port. For control packets there might be exceptions, like the STUN-based ECN-CHECK defined in Section 7.2.2.
送信者は、発信RTCPパケットにECTマークを含めないでください（SHOULD NOT）、他の発信制御メッセージ（たとえば、STUN [RFC5389]パケット、データグラムトランスポート層セキュリティ（DTLS）[RFC6347]ハンドシェイクパケット、またはZRTP [RFC6189]にECTマークを含めないでください。制御パケット）同じUDPポートで多重化されます。制御パケットの場合、セクション7.2.2で定義されたSTUNベースのECN-CHECKのような例外が存在する可能性があります。
An RTP receiver that receives a packet with an ECN-CE mark, or that detects a packet loss, MUST schedule the transmission of an RTCP ECN feedback packet as soon as possible (subject to the constraints of [RFC4585] and [RFC3550]) to report this back to the sender unless no timely feedback is required. The feedback RTCP packet SHALL consist of at least one ECN feedback packet (Section 5.1) reporting on the packets received since the last ECN feedback packet and will contain (at least) an RTCP SR/RR packet and an SDES packet, unless reduced-size RTCP [RFC5506] is used. The RTP/AVPF profile in early or immediate feedback mode SHOULD be used where possible, to reduce the interval before feedback can be sent. To reduce the size of the feedback message, reduced-size RTCP [RFC5506] MAY be used if supported by the endpoints. Both RTP/AVPF and reduced-size RTCP MUST be negotiated in the session setup signalling before they can be used.
ECN-CEマークが付いたパケットを受信する、またはパケット損失を検出するRTP受信機は、RTCP ECNフィードバックパケットの送信をできるだけ早くスケジュールする必要があります（[RFC4585]および[RFC3550]の制約に従います）。タイムリーなフィードバックが必要でない限り、これを送信者に報告してください。フィードバックRTCPパケットは、最後のECNフィードバックパケット以降に受信されたパケットについて報告する少なくとも1つのECNフィードバックパケット（セクション5.1）で構成され、サイズが縮小されない限り、（少なくとも）RTCP SR / RRパケットとSDESパケットを含みますRTCP [RFC5506]が使用されます。フィードバックを送信するまでの間隔を短縮するために、早期または即時フィードバックモードのRTP / AVPFプロファイルを可能な限り使用する必要があります（SHOULD）。フィードバックメッセージのサイズを減らすために、エンドポイントでサポートされている場合は、縮小サイズのRTCP [RFC5506]を使用できます。 RTP / AVPFと縮小サイズのRTCPの両方を使用する前に、セッションセットアップシグナリングでネゴシエートする必要があります。
Every time a regular compound RTCP packet is to be transmitted, an ECN-capable RTP receiver MUST include an RTCP XR ECN Summary Report as described in Section 5.2 as part of the compound packet.
通常の複合RTCPパケットが送信されるたびに、ECN対応RTP受信機は、セクション5.2で説明されているように、複合パケットの一部としてRTCP XR ECN要約レポートを含める必要があります。
The multicast feedback implosion problem, which occurs when many receivers simultaneously send feedback to a single sender, must be considered. The RTP/AVPF transmission rules will limit the amount of feedback that can be sent, avoiding the implosion problem but also delaying feedback by varying degrees from nothing up to a full RTCP reporting interval. As a result, the full extent of a congestion situation may take some time to reach the sender, although some feedback should arrive in a reasonably timely manner, allowing the sender to react on a single or a few reports.
多くの受信者が同時に単一の送信者にフィードバックを送信するときに発生するマルチキャストフィードバックの内破の問題を考慮する必要があります。 RTP / AVPF送信ルールは、送信可能なフィードバックの量を制限し、内破の問題を回避しますが、何もない状態から完全なRTCPレポート間隔まで、程度を変えることによってフィードバックを遅らせます。その結果、一部のフィードバックは合理的にタイムリーに到着し、送信者が1つまたはいくつかのレポートに反応できるようにする必要がありますが、輻輳状況の全範囲が送信者に到達するまでに時間がかかる場合があります。
The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred. There should be no difference in congestion response if ECN-CE marks or packet drops are detected.
IPヘッダーにECN-CEマークが付いたRTPパケットを受信すると、輻輳が発生していることが通知されます。これらのECN-CEマークの付いたパケットの受信に対するデフォルトの反応は、輻輳制御アルゴリズムに、パケット損失が発生したかのようにアルゴリズムが反応するようにトリガーする輻輳通知を提供するものでなければなりません（MUST）。 ECN-CEマークまたはパケットドロップが検出された場合、輻輳応答に違いはありません。
Other reactions to ECN-CE may be specified in the future, following IETF Review. Detailed designs of such alternative reactions MUST be specified in a Standards Track RFC and be reviewed to ensure they are safe for deployment under any restrictions specified. A potential example for an alternative reaction could be emergency communications (such as that generated by first responders, as opposed to the general public) in networks where the user has been authorised. A more detailed description of these other reactions, as well as the types of congestion control algorithms used by end-nodes, is outside the scope of this document.
ECN-CEに対する他の反応は、IETFレビューに従って、将来指定される可能性があります。そのような代替反応の詳細な設計は、Standards Track RFCで指定されなければならず、指定された制限の下での展開に対して安全であることを確認するためにレビューされなければなりません。代替の反応の潜在的な例は、ユーザーが許可されているネットワークでの緊急通信（一般市民ではなく、最初の応答者によって生成されるものなど）です。これらの他の反応の詳細、およびエンドノードで使用される輻輳制御アルゴリズムのタイプは、このドキュメントの範囲外です。
Depending on the media format, type of session, and RTP topology used, there are several different types of congestion control that can be used:
メディアフォーマット、セッションのタイプ、および使用するRTPトポロジに応じて、使用できる輻輳制御にはいくつかの異なるタイプがあります。
Sender-Driven Congestion Control: The sender is responsible for adapting the transmitted bitrate in response to RTCP ECN feedback. When the sender receives the ECN feedback data, it feeds this information into its congestion control or bitrate adaptation mechanism so that it can react as if packet loss was reported. The congestion control algorithm to be used is not specified here, although TFRC [RFC5348] is one example that might be used.
送信者主導の輻輳制御：送信者は、RTCP ECNフィードバックに応答して、送信されたビットレートを適応させる責任があります。送信者はECNフィードバックデータを受信すると、この情報を輻輳制御またはビットレート適応メカニズムに送り、パケット損失が報告されたかのように対応できるようにします。 TFRC [RFC5348]は使用される可能性がある1つの例ですが、使用される輻輳制御アルゴリズムはここでは指定されていません。
Receiver-Driven Congestion Control: In a receiver-driven congestion control mechanism, the receivers can react to the ECN-CE marks themselves without providing ECN-CE feedback to the sender. This may allow faster response than sender-driven congestion control in some circumstances and also scale to large number of receivers and multicast usage. One example of receiver-driven congestion control is implemented by providing the content in a layered way, with each layer providing improved media quality but also increased bandwidth usage. The receiver locally monitors the ECN-CE marks on received packets to check if it experiences congestion with the current number of layers. If congestion is experienced, the receiver drops one layer, thus reducing the resource consumption on the path towards itself. For example, if a layered media encoding scheme such as H.264 Scalable Video Coding (SVC) is used, the receiver may change its layer subscription and so reduce the bitrate it receives. The receiver MUST still send an RTCP XR ECN Summary to the sender, even if it can adapt without contact with the sender, so that the sender can determine if ECN is supported on the network path. The timeliness of RTCP feedback is less of a concern with receiver-driven congestion control, and regular RTCP reporting of ECN summary information is sufficient (without using RTP/AVPF immediate or early feedback).
受信者主導の輻輳制御：受信者主導の輻輳制御メカニズムでは、受信者はECN-CEフィードバックを送信者に提供せずに、ECN-CEマーク自体に反応できます。これにより、一部の状況では送信者主導の輻輳制御よりも高速な応答が可能になるだけでなく、多数の受信者とマルチキャストの使用にも対応できるようになります。受信者主導の輻輳制御の1つの例は、コンテンツを階層的に提供することで実装されます。各層では、メディア品質が向上しますが、帯域幅の使用量も増加します。レシーバーは、受信したパケットのECN-CEマークをローカルで監視して、現在のレイヤー数で輻輳が発生しているかどうかを確認します。輻輳が発生した場合、レシーバーは1つのレイヤーをドロップし、それ自体へのパス上のリソース消費を削減します。たとえば、H.264スケーラブルビデオコーディング（SVC）などの階層化メディアエンコーディングスキームが使用されている場合、レシーバーはそのレイヤーサブスクリプションを変更し、受信するビットレートを減らすことができます。送信者がネットワークパスでECNがサポートされているかどうかを送信者が判断できるように、受信者はRTCP XR ECNサマリーを送信者に送信する必要があります。 RTCPフィードバックの適時性は、受信者主導の輻輳制御ではそれほど問題ではなく、ECN要約情報の定期的なRTCPレポートで十分です（RTP / AVPF即時フィードバックまたは早期フィードバックを使用しなくても）。
Hybrid: There might be mechanisms that utilise both some receiver behaviours and some sender-side monitoring, thus requiring both feedback of congestion events to the sender and taking receiver decisions and possible signalling to the sender. In this case, the congestion control algorithm needs to use the signalling to indicate which features of ECN for RTP are required.
ハイブリッド：一部の受信者の動作と一部の送信者側の監視の両方を利用するメカニズムがあるため、送信者への輻輳イベントのフィードバックと受信者の決定と送信者への可能なシグナリングの両方が必要です。この場合、輻輳制御アルゴリズムはシグナリングを使用して、RTPのECNのどの機能が必要かを示す必要があります。
Responding to congestion indication in the case of multicast traffic is a more complex problem than for unicast traffic. The fundamental problem is diverse paths, i.e., when different receivers don't see the same path and thus have different bottlenecks, so the receivers may get ECN-CE-marked packets due to congestion at different points in the network. This is problematic for sender-driven congestion control, since when receivers are heterogeneous in regards to capacity, the sender is limited to transmitting at the rate the slowest receiver can support. This often becomes a significant limitation as group size grows. Also, as group size increases, the frequency of reports from each receiver decreases, which further reduces the responsiveness of the mechanism. Receiver-driven congestion control has the advantage that each receiver can choose the appropriate rate for its network path, rather than all receivers having to settle for the lowest common rate.
マルチキャストトラフィックの場合の輻輳表示への対応は、ユニキャストトラフィックの場合よりも複雑な問題です。基本的な問題は多様なパスです。つまり、異なるレシーバーが同じパスを認識せず、ボトルネックが異なるため、ネットワーク内の異なるポイントでの輻輳が原因で、レシーバーがECN-CEマークの付いたパケットを受信する場合があります。これは、送信側主導の輻輳制御にとって問題です。容量に関して受信側が異質である場合、送信側は最も遅い受信側がサポートできる速度での送信に制限されるためです。グループのサイズが大きくなると、これは多くの場合大きな制限になります。また、グループのサイズが大きくなると、各レシーバーからのレポートの頻度が減少し、メカニズムの応答性がさらに低下します。レシーバー主導の輻輳制御には、すべてのレシーバーが最低の共通レートに落ち着く必要がなく、各レシーバーがネットワークパスに適切なレートを選択できるという利点があります。
We note that ECN support is not a silver bullet to improving performance. The use of ECN gives the chance to respond to congestion before packets are dropped in the network, improving the user experience by allowing the RTP application to control how the quality is reduced. An application that ignores ECN Congestion Experienced feedback is not immune to congestion: the network will eventually begin to discard packets if traffic doesn't respond. To avoid packet loss, it is in the best interest of an application to respond to ECN congestion feedback promptly.
ECNのサポートは、パフォーマンスを向上させるための特効薬ではないことに注意してください。 ECNを使用すると、ネットワークでパケットがドロップされる前に輻輳に応答する機会が得られ、RTPアプリケーションが品質の低下を制御できるようにすることでユーザーエクスペリエンスが向上します。 ECN Congestion Experiencedフィードバックを無視するアプリケーションは、輻輳の影響を受けません。トラフィックが応答しない場合、ネットワークは最終的にパケットを破棄し始めます。パケット損失を回避するために、ECN輻輳フィードバックに迅速に応答することがアプリケーションの最善の利益になります。
Senders and receivers can deliberately ignore ECN-CE and thus get a benefit over behaving flows (cheating). The ECN nonce [RFC3540] is an addition to TCP that attempts to solve this issue as long as the sender acts on behalf of the network. The assumption that senders act on behalf of the network may be false due to the nature of peer-to-peer use of RTP. Still, a significant portion of RTP senders are infrastructure devices (for example, streaming media servers) that do have an interest in protecting both service quality and the network. Even though there may be cases where the nonce may be applicable for RTP, it is not included in this specification. This is because a receiver interested in cheating would simply claim to not support the nonce, or even ECN itself. It is, however, worth mentioning that, as real-time media is commonly sensitive to increased delay and packet loss, it will be in the interest of both the media sender and receivers to minimise the number and duration of any congestion events as they will adversely affect media quality.
送信者と受信者は意図的にECN-CEを無視できるため、フローの動作（チート）よりもメリットがあります。 ECN nonce [RFC3540]は、送信者がネットワークに代わって動作する限り、この問題を解決しようとするTCPへの追加です。 RTPのピアツーピア使用の性質上、送信者がネットワークの代わりに行動するという仮定は誤っている可能性があります。それでも、RTP送信者のかなりの部分は、サービス品質とネットワークの両方を保護することに関心があるインフラストラクチャデバイス（たとえば、ストリーミングメディアサーバー）です。 nonceはRTPに適用できる場合がありますが、この仕様には含まれていません。これは、不正行為に関心のある受信者がナンス、またはECN自体さえもサポートしないと主張するだけだからです。ただし、リアルタイムメディアは通常、遅延とパケット損失の増加に敏感であるため、輻輳イベントの数と期間を最小限に抑えることは、メディアの送信者と受信者の両方にとって重要であることを言及する価値があります。メディアの品質に悪影響を及ぼします。
RTP sessions can also suffer from path changes resulting in a non-ECN-compliant node becoming part of the path. That node may perform either of two actions that has an effect on the ECN and application functionality. The gravest is if the node drops packets with the ECN field set to ECT(0), ECT(1), or ECN-CE. This can be detected by the receiver when it receives an RTCP SR packet indicating that a sender has sent a number of packets that it has not received. The sender may also detect such a middlebox based on the receiver's RTCP RR packet, when the extended sequence number is not advanced due to the failure to receive packets. If the packet loss is less than 100%, then packet loss reporting in either the ECN feedback information or RTCP RR will indicate the situation. The other action is to re-mark a packet from ECT or ECN-CE to not-ECT. That has less dire results; however, it should be detected so that ECN usage can be suspended to prevent misusing the network.
また、RTPセッションは、パスの変更の影響を受ける可能性があり、その結果、ECN非準拠のノードがパスの一部になります。そのノードは、ECNとアプリケーション機能に影響を与える2つのアクションのいずれかを実行できます。最も重大なのは、ノードがECNフィールドがECT（0）、ECT（1）、またはECN-CEに設定されたパケットをドロップした場合です。これは、受信者がRTCP SRパケットを受信したときに、送信者が受信していない多数のパケットを送信したことを示すときに検出できます。送信側は、パケットの受信に失敗したために拡張シーケンス番号が進んでいない場合、受信側のRTCP RRパケットに基づいてこのようなミドルボックスを検出することもあります。パケット損失が100％未満の場合は、ECNフィードバック情報またはRTCP RRのいずれかで報告されたパケット損失が状況を示します。もう1つのアクションは、ECTまたはECN-CEからnot-ECTにパケットを再マークすることです。悲惨な結果は少なくなります。ただし、ネットワークの誤用を防ぐためにECNの使用を一時停止できるように、それを検出する必要があります。
The RTCP XR ECN summary packet and the ECN feedback packet allow the sender to compare the number of ECT-marked packets of different types received with the number it actually sent. The number of ECT packets received, plus the number of ECN-CE-marked and lost packets, should correspond to the number of sent ECT-marked packets plus the number of received duplicates. If these numbers don't agree, there are two likely reasons: a translator changing the stream or not carrying the ECN markings forward or some node re-marking the packets. In both cases, the usage of ECN is broken on the path. By tracking all the different possible ECN field values, a sender can quickly detect if some non-compliant behaviour is happening on the path.
RTCP XR ECNサマリーパケットとECNフィードバックパケットを使用すると、送信者は、受信したさまざまなタイプのECTマーク付きパケットの数を、実際に送信した数と比較できます。受信したECTパケットの数とECN-CEでマークされたパケットおよび失われたパケットの数は、送信されたECTでマークされたパケットの数と受信した重複の数に対応する必要があります。これらの数値が一致しない場合は、2つの理由が考えられます。トランスレータがストリームを変更するか、ECNマーキングを転送しないか、一部のノードがパケットを再マーキングします。どちらの場合も、ECNの使用はパス上で壊れています。可能なすべてのECNフィールド値を追跡することにより、送信者は、パスで非準拠の動作が発生しているかどうかをすばやく検出できます。
Thus, packet losses and non-matching ECN field value statistics are possible indications of issues with using ECN over the path. The next section defines both sender and receiver reactions to these cases.
したがって、パケット損失と一致しないECNフィールド値の統計は、パス上でECNを使用する際の問題を示している可能性があります。次のセクションでは、これらのケースに対する送信者と受信者の両方の反応を定義します。
Upon the detection of a potential failure, both the sender and the receiver can react to mitigate the situation.
潜在的な障害を検出すると、送信者と受信者の両方が対応して状況を緩和できます。
A receiver that detects a packet loss burst MAY schedule an early feedback packet that includes at least the RTCP RR and the ECN feedback message to report this to the sender. This will speed up the detection of the loss at the sender, thus triggering sender-side mitigation.
パケット損失バーストを検出する受信機は、少なくともRTCP RRとECNフィードバックメッセージを含む早期フィードバックパケットをスケジュールして、これを送信者に報告してもよい（MAY）。これにより、送信側での損失の検出が高速化され、送信側の緩和策がトリガーされます。
A sender that detects high packet loss rates for ECT-marked packets SHOULD immediately switch to sending packets as not-ECT to determine if the losses are potentially due to the ECT markings. If the losses disappear when the ECT-marking is discontinued, the RTP sender should go back to initiation procedures to attempt to verify the apparent loss of ECN capability of the used path. If a re-initiation fails, then two possible actions exist:
ECTマークの付いたパケットの高いパケット損失率を検出する送信者は、ECTマーキングによる損失の可能性があるかどうかを判断するために、ECT以外のパケットの送信に直ちに切り替える必要があります（SHOULD）。 ECTマーキングが中止されたときに損失が消えた場合、RTP送信者は開始手順に戻って、使用されているパスのECN機能の明らかな損失を確認する必要があります。再初期化が失敗した場合、2つの可能なアクションが存在します。
1. Periodically retry the ECN initiation to detect if a path change occurs to a path that is ECN capable.
1. 定期的にECNの開始を再試行して、ECN対応のパスにパス変更が発生したかどうかを検出します。
2. Renegotiate the session to disable ECN support. This is a choice that is suitable if the impact of ECT probing on the media quality is noticeable. If multiple initiations have been successful, but the following full usage of ECN has resulted in the fallback procedures, then disabling of the ECN support is RECOMMENDED.
2. セッションを再交渉して、ECNサポートを無効にします。これは、ECTプローブのメディア品質への影響が顕著である場合に適しています。複数の開始は成功したが、次のECNの完全な使用によりフォールバック手順が発生した場合は、ECNサポートを無効にすることをお勧めします。
We foresee the possibility of flapping ECN capability due to several reasons: video-switching MCU or similar middleboxes that select to deliver media from the sender only intermittently; load-balancing devices that may in worst case result in some packets taking a different network path than the others; mobility solutions that switch the underlying network path in a transparent way for the sender or receiver; and membership changes in a multicast group. It is, however, appropriate to mention that there are also issues such as re-routing of traffic due to a flappy route table or excessive reordering and other issues that are not directly ECN related but nevertheless may cause problems for ECN.
いくつかの理由により、ECN機能がフラッピングする可能性が予想されます。送信側からのメディアを断続的にのみ配信することを選択するビデオスイッチングMCUまたは同様のミドルボックス。最悪の場合、ロードバランシングデバイスによって、一部のパケットが他のパケットとは異なるネットワークパスを使用する可能性があります。送信者または受信者に対して透過的な方法で基盤となるネットワークパスを切り替えるモビリティソリューション。マルチキャストグループのメンバーシップの変更。ただし、ゆるいルートテーブルや過度の並べ替えによるトラフィックの再ルーティングなどの問題や、ECNに直接関連していないがECNに問題を引き起こす可能性のあるその他の問題もあることに言及することは適切です。
This section contains discussion on how the ECN Summary Report information can be used to detect various types of ECN path issues. We first review the information the RTCP reports provide on a per-source (SSRC) basis: ECN-CE Counter: The number of RTP packets received so far in the session with an ECN field set to CE.
このセクションでは、ECNサマリーレポート情報を使用して、さまざまなタイプのECNパスの問題を検出する方法について説明します。最初に、RTCPレポートがソース（SSRC）ごとに提供する情報を確認します。ECN-CEカウンター：ECNフィールドがCEに設定されているセッションでこれまでに受信されたRTPパケットの数。
ECT (0/1) Counters: The number of RTP packets received so far in the session with an ECN field set to ECT (0) and ECT (1) respectively.
ECT（0/1）カウンター：ECNフィールドがそれぞれECT（0）およびECT（1）に設定されたセッションでこれまでに受信されたRTPパケットの数。
not-ECT Counter: The number of RTP packets received so far in the session with an ECN field set to not-ECT.
not-ECTカウンター：ECNフィールドがnot-ECTに設定されているセッションでこれまでに受信されたRTPパケットの数。
Lost Packets Counter: The number of RTP packets that where expected based on sequence numbers but never received.
Lost Packets Counter：シーケンス番号に基づいて予測されたが受信されなかったRTPパケットの数。
Duplication Counter: The number of received RTP packets that are duplicates of already received ones.
重複カウンター：既に受信したものの複製である受信RTPパケットの数。
Extended Highest Sequence number: The highest sequence number seen when sending this report, but with additional bits, to handle disambiguation when wrapping the RTP sequence number field.
拡張最大シーケンス番号：このレポートを送信するときに表示される最大シーケンス番号ですが、RTPシーケンス番号フィールドをラップするときに明確化を処理するためにビットが追加されています。
The counters will be initialised to zero to provide values for the RTP stream sender from the first report. After the first report, the changes between the last received report and the previous report are determined by simply taking the values of the latest minus the previous, taking wrapping into account. This definition is also robust to packet losses, since if one report is missing, the reporting interval becomes longer, but is otherwise equally valid.
カウンターはゼロに初期化され、最初のレポートからのRTPストリーム送信者に値を提供します。最初のレポートの後、最後に受信したレポートと前のレポートの間の変更は、ラッピングを考慮して、最新の値から前のレポートを差し引いた値を単に使用することによって決定されます。この定義は、1つのレポートが欠落している場合、レポートの間隔が長くなりますが、それ以外は同等に有効であるため、パケット損失に対しても堅牢です。
In a perfect world, the number of not-ECT packets received should be equal to the number sent minus the Lost Packets Counter, and the sum of the ECT(0), ECT(1), and ECN-CE counters should be equal to the number of ECT-marked packet sent. Two issues may cause a mismatch in these statistics: severe network congestion or unresponsive congestion control might cause some ECT-marked packets to be lost, and packet duplication might result in some packets being received and counted in the statistics multiple times (potentially with a different ECN-mark on each copy of the duplicate).
完全な世界では、受信された非ECTパケットの数は、送信された数から失われたパケットカウンターを引いた数に等しく、ECT（0）、ECT（1）、およびECN-CEカウンターの合計は、送信されたECTマーク付きパケットの数。 2つの問題がこれらの統計の不一致を引き起こす可能性があります。深刻なネットワークの輻輳または無応答の輻輳制御により、ECTマークの付いたパケットが失われる可能性があり、パケットの重複により、一部のパケットが統計で複数回受信およびカウントされる可能性があります（異なる複製の各コピーにECNマーク）。
The rate of packet duplication is tracked, allowing one to take the duplication into account. The value of the ECN field for duplicates will also be counted, and when comparing the figures, one needs to take into account in the calculation that some fraction of packet duplicates are not-ECT and some are ECT. Thus, when only sending not-ECT, the number of sent packets plus reported duplicates equals the number of received not-ECT. When sending only ECT, the number of sent ECT packets plus duplicates will equal ECT(0), ECT(1), ECN-CE, and packet loss. When sending a mix of not-ECT and ECT, there is an uncertainty if any duplicate or packet loss was an not-ECT or ECT. If the packet duplication is completely independent of the usage of ECN, then the fraction of packet duplicates should be in relation to the number of not-ECT vs. ECT packets sent during the period of comparison. This relation does not hold for packet loss, where higher rates of packet loss for not-ECT is expected than for ECT traffic.
パケットの重複率が追跡され、重複を考慮に入れることができます。重複のECNフィールドの値もカウントされます。数値を比較する場合、パケットの重複の一部がECTではなく、一部がECTであることを計算で考慮する必要があります。したがって、not-ECTのみを送信する場合、送信されたパケットと報告された重複の数は、受信されたnot-ECTの数と等しくなります。 ECTのみを送信する場合、送信されるECTパケットと重複の数は、ECT（0）、ECT（1）、ECN-CE、およびパケット損失と等しくなります。 not-ECTとECTの混合を送信する場合、重複またはパケット損失がnot-ECTまたはECTであったかどうかは不確実です。パケットの重複がECNの使用とは完全に独立している場合、パケットの重複の割合は、比較期間中に送信されたnot-ECTパケットとECTパケットの数に関連しているはずです。この関係は、ECTトラフィックよりもNOT ECTの方がパケット損失率が高いと予想されるパケット損失には当てはまりません。
Detecting clearing of ECN field: If the ratio between ECT and not-ECT transmitted in the reports has become all not-ECT, or has substantially changed towards not-ECT, then this is clearly an indication that the path results in clearing of the ECT field.
ECNフィールドのクリアの検出：レポートで送信されたECTとnot-ECTの比率がすべてnot-ECTになった場合、または大幅にnot-ECTに変化した場合、これは明らかに、パスによってECTがクリアされたことを示しています。フィールド。
Dropping of ECT packets: To determine if the packet-drop ratio is different between not-ECT and ECT-marked transmission requires a mix of transmitted traffic. The sender should compare if the delivery percentage (delivered/transmitted) between ECT and not-ECT is significantly different. Care must be taken if the number of packets is low in either of the categories. One must also take into account the level of CE marking. A CE-marked packet would have been dropped unless it was ECT marked. Thus, the packet loss level for not-ECT should be approximately equal to the loss rate for ECT when counting the CE-marked packets as lost ones. A sender performing this calculation needs to ensure that the difference is statistically significant.
ECTパケットのドロップ：非ECTとECTマーク付きの送信でパケットドロップ率が異なるかどうかを判別するには、送信トラフィックの混合が必要です。送信者は、ECTと非ECTの間の配信率（配信/送信）が大幅に異なるかどうかを比較する必要があります。いずれかのカテゴリでパケット数が少ない場合は注意が必要です。 CEマーキングのレベルも考慮する必要があります。 ECTマークが付けられていない限り、CEマークの付いたパケットはドロップされます。したがって、NOT ECTのパケット損失レベルは、CEマークの付いたパケットを損失したものとしてカウントするときのECTの損失率とほぼ等しくなるはずです。この計算を実行する送信者は、差が統計的に有意であることを確認する必要があります。
If erroneous behaviour is detected, it should be logged to enable follow up and statistics gathering.
誤った動作が検出された場合は、ログに記録して、フォローアップと統計収集を有効にする必要があります。
RTP translators and mixers that support ECN for RTP are required to process and potentially modify or generate ECN marking in RTP packets. They also need to process and potentially modify or generate RTCP ECN feedback packets for the translated and/or mixed streams. This includes both downstream RTCP reports generated by the media sender and also reports generated by the receivers, flowing upstream back towards the sender.
RTPのECNをサポートするRTPトランスレータとミキサーは、RTPパケットのECNマーキングを処理し、場合によっては変更または生成する必要があります。また、変換されたストリームや混合されたストリームのRTCP ECNフィードバックパケットを処理し、場合によっては変更または生成する必要もあります。これには、メディア送信者によって生成されたダウンストリームRTCPレポートと、受信者によって生成されたレポートの両方が含まれ、送信者に向かって上流に流れます。
Some translators only perform transport-level translations, such as copying packets from one address domain, like from unicast to multicast. They may also perform relaying like copying an incoming packet to a number of unicast receivers. This section details the ECN-related actions for RTP and RTCP.
一部のトランスレータは、ユニキャストからマルチキャストなど、1つのアドレスドメインからパケットをコピーするなど、トランスポートレベルの変換のみを実行します。また、着信パケットを多数のユニキャストレシーバーにコピーするようなリレーも実行できます。このセクションでは、RTPおよびRTCPのECN関連のアクションについて詳しく説明します。
For RTP data packets, the translator, which does not modify the media stream, SHOULD copy the ECN bits unchanged from the incoming to the outgoing datagrams, unless the translator itself is overloaded and experiencing congestion, in which case it may mark the outgoing datagrams with an ECN-CE mark.
RTPデータパケットの場合、トランスレータはメディアストリームを変更しませんが、トランスレータ自体が過負荷で輻輳が発生していない限り、ECNビットを変更せずに着信データグラムから発信データグラムにコピーする必要があります。この場合、発信データグラムはECN-CEマーク。
A transport translator does not modify RTCP packets. However, it MUST perform the corresponding transport translation of the RTCP packets as it does with RTP packets being sent from the same source/ endpoint.
トランスポートトランスレータはRTCPパケットを変更しません。ただし、RTPパケットが同じソース/エンドポイントから送信される場合と同様に、RTCPパケットの対応するトランスポート変換を実行する必要があります。
An RTP translator may fragment or reassemble RTP data packets without changing the media encoding and without reference to the congestion state of the networks it bridges. An example of this might be to combine packets of a voice-over-IP stream coded with one 20 ms frame per RTP packet into new RTP packets with two 20 ms frames per packet, thereby reducing the header overhead and thus stream bandwidth, at the expense of an increase in latency. If multiple data packets are re-encoded into one, or vice versa, the RTP translator MUST assign new sequence numbers to the outgoing packets. Losses in the incoming RTP packet stream may also induce corresponding gaps in the outgoing RTP sequence numbers. An RTP translator MUST rewrite RTCP packets to make the corresponding changes to their sequence numbers and to reflect the impact of the fragmentation or reassembly. This section describes how that rewriting is to be done for RTCP ECN feedback packets. Section 7.2 of [RFC3550] describes general procedures for other RTCP packet types.
RTPトランスレータは、メディアエンコーディングを変更することなく、またそれがブリッジするネットワークの輻輳状態を参照することなく、RTPデータパケットをフラグメント化または再構成できます。この例としては、RTPパケットごとに1つの20ミリ秒フレームでコード化されたVoice-over-IPストリームのパケットを、パケットごとに2つの20ミリ秒フレームを持つ新しいRTPパケットに結合し、ヘッダーオーバーヘッドを削減して、ストリーム帯域幅を待ち時間の増加の費用。複数のデータパケットが1つに再エンコードされる場合、またはその逆の場合、RTPトランスレータは、発信パケットに新しいシーケンス番号を割り当てる必要があります。着信RTPパケットストリームの損失は、発信RTPシーケンス番号に対応するギャップを引き起こす可能性もあります。 RTPトランスレータは、RTCPパケットを書き換えて、シーケンス番号に対応する変更を加え、フラグメンテーションまたは再構成の影響を反映する必要があります。このセクションでは、RTCP ECNフィードバックパケットに対してその書き換えを行う方法について説明します。 [RFC3550]のセクション7.2では、他のRTCPパケットタイプの一般的な手順について説明しています。
The processing of arriving RTP packets for this case is as follows. If an ECN-marked packet is split into two, then both the outgoing packets MUST be ECN marked identically to the original; if several ECN-marked packets are combined into one, the outgoing packet MUST be either ECN-CE marked or dropped if any of the incoming packets are ECN-CE marked. If the outgoing combined packet is not ECN-CE marked, then it MUST be ECT marked if any of the incoming packets were ECT marked.
この場合のRTPパケットの到着処理は次のとおりです。 ECNでマークされたパケットが2つに分割される場合、両方の発信パケットは元のパケットと同じようにECNでマークされている必要があります。複数のECNマーク付きパケットが1つに結合されている場合、送信パケットはECN-CEマークが付いているか、着信パケットのいずれかにECN-CEマークが付いている場合はドロップする必要があります。発信結合パケットにECN-CEマークが付いていない場合、着信パケットのいずれかにECTマークが付いていれば、ECTマークが付いている必要があります。
RTCP ECN feedback packets (Section 5.1) contain seven fields that are rewritten in an RTP translator that fragments or reassembles packets: the extended highest sequence number, the duplication counter, the Lost Packets Counter, the ECN-CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1) counter. The RTCP XR report block for ECN summary information (Section 5.2) includes all of these fields except the extended highest sequence number, which is present in the report block in an SR or RR packet. The procedures for rewriting these fields are the same for both the RTCP ECN feedback packet and the RTCP XR ECN summary packet.
RTCP ECNフィードバックパケット（セクション5.1）には、パケットをフラグメント化または再構成するRTPトランスレーターで書き換えられる7つのフィールドが含まれます。拡張最大シーケンス番号、複製カウンター、Lost Packetsカウンター、ECN-CEカウンター、not-ECTカウンター、ECT（0）カウンター、およびECT（1）カウンター。 ECNサマリー情報のRTCP XRレポートブロック（セクション5.2）には、SRまたはRRパケットのレポートブロックに存在する拡張最大シーケンス番号を除く、これらのフィールドがすべて含まれています。これらのフィールドを書き換える手順は、RTCP ECNフィードバックパケットとRTCP XR ECNサマリーパケットの両方で同じです。
When receiving an RTCP ECN feedback packet for the translated stream, an RTP translator first determines the range of packets to which the report corresponds. The extended highest sequence number in the RTCP ECN feedback packet (or in the RTCP SR/RR packet contained within the compound packet, in the case of RTCP XR ECN Summary Reports) specifies the end sequence number of the range. For the first RTCP ECN feedback packet received, the initial extended sequence number of the range may be determined by subtracting the sum of the Lost Packets Counter, the ECN-CE counter, the not-ECT counter, the ECT(0) counter and the ECT(1) counter minus the duplication counter, from the extended highest sequence number. For subsequent RTCP ECN feedback packets, the starting sequence number may be determined as being one after the extended highest sequence number of the previous RTCP ECN feedback packet received from the same SSRC. These values are in the sequence number space of the translated packets.
変換されたストリームのRTCP ECNフィードバックパケットを受信すると、RTPトランスレータは最初に、レポートが対応するパケットの範囲を決定します。 RTCP ECNフィードバックパケット（またはRTCP XR ECNサマリーレポートの場合は複合パケット内に含まれるRTCP SR / RRパケット）の拡張された最大シーケンス番号は、範囲の終了シーケンス番号を指定します。受信した最初のRTCP ECNフィードバックパケットについて、範囲の初期拡張シーケンス番号は、Lost Packetsカウンター、ECN-CEカウンター、not-ECTカウンター、ECT（0）カウンター、および拡張最大シーケンス番号からのECT（1）カウンターから重複カウンターを引いたもの。後続のRTCP ECNフィードバックパケットの場合、開始シーケンス番号は、同じSSRCから受信した前のRTCP ECNフィードバックパケットの拡張された最大シーケンス番号の後に1つとして決定されます。これらの値は、変換されたパケットのシーケンス番号スペースにあります。
Based on its knowledge of the translation process, the translator determines the sequence number range for the corresponding original, pre-translation, packets. The extended highest sequence number in the RTCP ECN feedback packet is rewritten to match the final sequence number in the pre-translation sequence number range.
トランスレータは、変換プロセスに関する知識に基づいて、対応する元の事前変換パケットのシーケンス番号の範囲を決定します。 RTCP ECNフィードバックパケットの拡張された最大シーケンス番号は、変換前のシーケンス番号の範囲の最終シーケンス番号と一致するように書き換えられます。
The translator then determines the ratio, R, of the number of packets in the translated sequence number space (numTrans) to the number of packets in the pre-translation sequence number space (numOrig) such that R = numTrans / numOrig. The counter values in the RTCP ECN Feedback Report are then scaled by dividing each of them by R. For example, if the translation process combines two RTP packets into one, then numOrig will be twice numTrans, giving R=0.5, and the counters in the translated RTCP ECN feedback packet will be twice those in the original.
次に、トランスレーターは、R = numTrans / numOrigとなるように、変換済みシーケンス番号スペース（numTrans）のパケット数と変換前シーケンス番号スペース（numOrig）のパケット数の比率Rを決定します。次に、RTCP ECNフィードバックレポートのカウンター値は、それぞれをRで除算することでスケーリングされます。たとえば、変換プロセスで2つのRTPパケットを1つに結合すると、numOrigはnumTransの2倍になり、R = 0.5となり、カウンターは変換されたRTCP ECNフィードバックパケットは、元のパケットの2倍になります。
The ratio, R, may have a value that leads to non-integer multiples of the counters when translating the RTCP packet. For example, a Voice over IP (VoIP) translator that combines two adjacent RTP packets into one if they contain active speech data, but passes comfort noise packets unchanged, would have an R value of between 0.5 and 1.0 depending on the amount of active speech. Since the counter values in the translated RTCP report are integer values, rounding will be necessary in this case.
比率Rは、RTCPパケットを変換するときにカウンターの整数以外の倍数につながる値を持つ場合があります。たとえば、アクティブな音声データが含まれている場合に2つの隣接するRTPパケットを1つに結合し、コンフォートノイズパケットは変更せずに渡すVoice over IP（VoIP）トランスレーターは、アクティブな音声の量に応じてR値が0.5から1.0になります。 。変換されたRTCPレポートのカウンター値は整数値であるため、この場合は丸めが必要になります。
When rounding counter values in the translated RTCP packet, the translator should try to ensure that they sum to the number of RTP packets in the pre-translation sequence number space (numOrig). The translator should also try to ensure that no non-zero counter is rounded to a zero value, unless the pre-translated values are zero, since that will lose information that a particular type of event has occurred. It is recognised that it may be impossible to satisfy both of these constraints; in such cases, it is better to ensure that no non-zero counter is mapped to a zero value, since this preserves congestion adaptation and helps the RTCP-based ECN initiation process.
変換されたRTCPパケットのカウンター値を丸める場合、トランスレーターは、それらが合計されて変換前のシーケンス番号スペース（numOrig）のRTPパケットの数になるようにしてください。トランスレーターは、事前変換された値がゼロでない限り、ゼロ以外のカウンターがゼロ値に丸められないようにする必要もあります。これは、特定のタイプのイベントが発生したという情報を失うためです。これらの制約の両方を満たすことは不可能かもしれないことが認識されています。このような場合、輻輳の適応を維持し、RTCPベースのECN開始プロセスを支援するため、ゼロ以外のカウンターがゼロ値にマップされないようにすることをお勧めします。
One should be aware of the impact this type of translator has on the measurement of packet duplication. A translator performing aggregation and most likely also an fragmenting translator will suppress any duplication happening prior to itself. Thus, the reports and what is being scaled will only represent packet duplication happening from the translator to the receiver reporting on the flow.
このタイプのトランスレータがパケット重複の測定に与える影響を認識する必要があります。集約を実行するトランスレータ、およびおそらくフラグメント化トランスレータは、それ自体の前に発生する重複を抑制します。したがって、レポートとスケーリングされているものは、フローについてレポートしているトランスレータからレシーバへのパケットの複製のみを表します。
It should be noted that scaling the RTCP counter values in this way is meaningful only on the assumption that the level of congestion in the network is related to the number of packets being sent. This is likely to be a reasonable assumption in the type of environment where RTP translators that fragment or reassemble packets are deployed, as their entire purpose is to change the number of packets being sent to adapt to known limitations of the network, but is not necessarily valid in general.
この方法でRTCPカウンタ値をスケーリングすることは、ネットワークの輻輳レベルが送信されるパケットの数に関連しているという前提でのみ意味があることに注意してください。これは、パケットの断片化または再構成を行うRTPトランスレータが展開されている環境のタイプでは、ネットワークの既知の制限に適応するために送信されるパケットの数を変更することを目的としているため、妥当な仮定と思われますが、必ずしもそうではありません。一般的に有効です。
The rewritten RTCP ECN Feedback Report is sent from the other side of the translator to that from which it arrived (as part of a compound RTCP packet containing other translated RTCP packets, where appropriate).
書き換えられたRTCP ECNフィードバックレポートは、トランスレータの反対側から到着元に送信されます（必要に応じて、他の変換されたRTCPパケットを含む複合RTCPパケットの一部として）。
An RTP translator that acts as a media transcoder cannot directly forward RTCP packets corresponding to the transcoded stream, since those packets will relate to the non-transcoded stream and will not be useful in relation to the transcoded RTP flow. Such a transcoder will need to interpose itself into the RTCP flow, acting as a proxy for the receiver to generate RTCP feedback in the direction of the sender relating to the pre-transcoded stream and acting in place of the sender to generate RTCP relating to the transcoded stream to be sent towards the receiver. This section describes how this proxying is to be done for RTCP ECN feedback packets. Section 7.2 of [RFC3550] describes general procedures for other RTCP packet types.
メディアトランスコーダとして機能するRTPトランスレータは、トランスコードされたストリームに対応するRTCPパケットを直接転送できません。これらのパケットは非トランスコードされたストリームに関連し、トランスコードされたRTPフローに関しては役に立たないためです。このようなトランスコーダーは、RTCPフローに自分自身を挿入する必要があります。これは、トランスコード済みストリームに関連する送信者の方向にRTCPフィードバックを生成する受信者のプロキシとして機能し、レシーバーに向けて送信されるトランスコードされたストリーム。このセクションでは、RTCP ECNフィードバックパケットに対してこのプロキシを行う方法について説明します。 [RFC3550]のセクション7.2では、他のRTCPパケットタイプの一般的な手順について説明しています。
An RTP translator acting as a media transcoder in this manner does not have its own SSRC and hence is not visible to other entities at the RTP layer. RTCP ECN feedback packets and RTCP XR report blocks for ECN summary information that are received from downstream relate to the translated stream and so must be processed by the translator as if they were the original media source. These reports drive the congestion control loop and media adaptation between the translator and the downstream receiver. If there are multiple downstream receivers, a logically separate transcoder instance must be used for each receiver and must process RTCP ECN Feedback and Summary Reports independently of the other transcoder instances. An RTP translator acting as a media transcoder in this manner MUST NOT forward RTCP ECN feedback packets or RTCP XR ECN Summary Reports from downstream receivers in the upstream direction.
この方法でメディアトランスコーダーとして機能するRTPトランスレーターには独自のSSRCがないため、RTPレイヤーの他のエンティティーからは見えません。ダウンストリームから受信したRCN ECNフィードバックパケットおよびECNサマリー情報のRTCP XRレポートブロックは、変換されたストリームに関連するため、元のメディアソースであるかのようにトランスレータで処理する必要があります。これらのレポートは、トランスレータとダウンストリームレシーバー間の輻輳制御ループとメディア適応を推進します。複数のダウンストリームレシーバーがある場合は、論理的に個別のトランスコーダーインスタンスを各レシーバーに使用し、他のトランスコーダーインスタンスとは無関係にRTCP ECNフィードバックおよびサマリーレポートを処理する必要があります。この方法でメディアトランスコーダーとして機能するRTPトランスレーターは、RTCP ECNフィードバックパケットまたはRTCP XR ECNサマリーレポートをダウンストリームレシーバーからアップストリーム方向に転送してはなりません（MUST NOT）。
An RTP translator acting as a media transcoder will generate RTCP reports upstream towards the original media sender, based on the reception quality of the original media stream at the translator. The translator will run a separate congestion control loop and media adaptation between itself and the media sender for each of its downstream receivers and must generate RTCP ECN feedback packets and RTCP XR ECN Summary Reports for that congestion control loop using the SSRC of that downstream receiver.
メディアトランスコーダーとして機能するRTPトランスレーターは、トランスレーターでの元のメディアストリームの受信品質に基づいて、元のメディアセンダーに向かってRTCPレポートを上流に生成します。トランスレータは、ダウンストリームレシーバーごとに、独立した輻輳制御ループとそれ自体とメディアセンダー間のメディア適応を実行し、そのダウンストリームレシーバーのSSRCを使用して、その輻輳制御ループのRTCP ECNフィードバックパケットとRTCP XR ECNサマリーレポートを生成する必要があります。
An RTP mixer terminates one-or-more RTP flows, combines them into a single outgoing media stream, and transmits that new stream as a separate RTP flow. A mixer has its own SSRC and is visible to other participants in the session at the RTP layer.
RTPミキサーは、1つ以上のRTPフローを終了し、それらを単一の発信メディアストリームに結合して、その新しいストリームを個別のRTPフローとして送信します。ミキサーには独自のSSRCがあり、RTPレイヤーでセッションの他の参加者に表示されます。
An ECN-aware RTP mixer must generate RTCP ECN feedback packets and RTCP XR report blocks for ECN summary information relating to the RTP flows it terminates, in exactly the same way it would if it were an RTP receiver. These reports form part of the congestion control loop between the mixer and the media senders generating the streams it is mixing. A separate control loop runs between each sender and the mixer.
ECN認識RTPミキサーは、RTP ECNフィードバックパケットと、それがRTPレシーバーである場合とまったく同じ方法で、終了するRTPフローに関するECNサマリー情報のRTCP XRレポートブロックを生成する必要があります。これらのレポートは、ミキサーと、混合しているストリームを生成するメディアセンダーとの間の輻輳制御ループの一部を形成します。各センダーとミキサーの間で個別の制御ループが実行されます。
An ECN-aware RTP mixer will negotiate and initiate the use of ECN on the mixed RTP flows it generates and will accept and process RTCP ECN Feedback Reports and RTCP XR report blocks for ECN relating to those mixed flows as if it were a standard media sender. A congestion control loop runs between the mixer and its receivers, driven in part by the ECN reports received.
ECN対応のRTPミキサーは、生成する混合RTPフローでECNの使用をネゴシエートして開始し、それらの混合フローに関連するECNのRTCP ECNフィードバックレポートとRTCP XRレポートブロックを、標準のメディア送信者であるかのように受け入れて処理します。 。輻輳制御ループは、受信したECNレポートによって部分的に駆動される、ミキサーとそのレシーバーの間で実行されます。
An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR ECN Summary Reports from downstream receivers in the upstream direction.
RTPミキサーは、RTCP ECNフィードバックパケットまたはRTCP XR ECNサマリーレポートをダウンストリームレシーバーからアップストリーム方向に転送してはなりません（MUST NOT）。
To allow the use of ECN with RTP over UDP, an RTP implementation desiring to support receiving ECN-controlled media streams must support reading the value of the ECT bits on received UDP datagrams, and an RTP implementation desiring to support sending ECN-controlled media streams must support setting the ECT bits in outgoing UDP datagrams. The standard Berkeley sockets API pre-dates the specification of ECN and does not provide the functionality that is required for this mechanism to be used with UDP flows, making this specification difficult to implement portably.
RTP over UDPでECNを使用できるようにするには、ECN制御のメディアストリームの受信をサポートするRTP実装が、受信したUDPデータグラムのECTビットの値の読み取りをサポートし、ECN制御のメディアストリームの送信をサポートするRTP実装をサポートする必要があります。発信UDPデータグラムのECTビットの設定をサポートする必要があります。標準のBerkeleyソケットAPIは、ECNの仕様よりも古いものであり、このメカニズムをUDPフローで使用するために必要な機能を提供していないため、この仕様を移植して実装することは困難です。
Following the guidelines in [RFC4566], the IANA has registered one new media-level SDP attribute:
[RFC4566]のガイドラインに従って、IANAは1つの新しいメディアレベルのSDP属性を登録しました：
o Contact name, email address and telephone number: Authors of RFC 6679
o 連絡先の名前、メールアドレス、電話番号：RFC 6679の作成者
o Attribute-name: ecn-capable-rtp
o 属性名：ecn-capable-rtp
o Type of attribute: media-level
o 属性のタイプ：メディアレベル
o Subject to charset: no
o 文字セットの対象：いいえ
This attribute defines the ability to negotiate the use of ECT (ECN-capable transport) for RTP flows running over UDP/IP. This attribute is put in the SDP offer if the offering party wishes to receive an ECT flow. The answering party then includes the attribute in the answer if it wishes to receive an ECT flow. If the answerer does not include the attribute, then ECT MUST be disabled in both directions.
この属性は、UDP / IPで実行されているRTPフローのECT（ECN対応トランスポート）の使用をネゴシエートする機能を定義します。この属性は、提供側がECTフローの受信を希望する場合、SDPオファーに入れられます。応答側は、ECTフローの受信を希望する場合、応答に属性を含めます。回答者が属性を含まない場合、ECTは両方向で無効にする必要があります。
The IANA has registered one new RTP/AVPF Transport-Layer Feedback Message in the table of FMT values for RTPFB Payload Types [RFC4585] as defined in Section 5.1:
セクション5.1で定義されているように、IANAはRTPFBペイロードタイプ[RFC4585]のFMT値のテーブルに1つの新しいRTP / AVPFトランスポート層フィードバックメッセージを登録しました。
Name: RTCP-ECN-FB Long name: RTCP ECN Feedback Value: 8 Reference: RFC 6679
名前：RTCP-ECN-FB長い名前：RTCP ECNフィードバック値：8参照：RFC 6679
The IANA has registered one new SDP "rtcp-fb" attribute "nack" parameter "ecn" in the SDP ("ack" and "nack" Attribute Values) registry.
IANAは、SDP（ "ack"および "nack"属性値）レジストリに1つの新しいSDP "rtcp-fb"属性 "nack"パラメータ "ecn"を登録しました。
Value name: ecn Long name: Explicit Congestion Notification Usable with: nack Reference: RFC 6679
値の名前：ecnロングネーム：明示的な輻輳通知使用可能：nack参照：RFC 6679
The IANA has registered one new RTCP XR Block Type as defined in Section 5.2:
IANAは、セクション5.2で定義されているように、1つの新しいRTCP XRブロックタイプを登録しています。
Block Type: 13 Name: ECN Summary Report Reference: RFC 6679
ブロックタイプ：13名前：ECN要約レポート参照：RFC 6679
The IANA has registered one new RTCP XR SDP Parameter "ecn-sum" in the "RTCP XR SDP Parameters" registry.
IANAは、「RTCP XR SDPパラメータ」レジストリに1つの新しいRTCP XR SDPパラメータ「ecn-sum」を登録しました。
Parameter name XR block (block type and name)
-------------- ------------------------------------
ecn-sum 13 ECN Summary Report
A new STUN [RFC5389] attribute in the comprehension-optional range under IETF Review (0x8000-0xFFFF) has been assigned to the ECN-CHECK STUN attribute (0x802D) defined in Section 7.2.2. The STUN attribute registry can currently be found at: http://www.iana.org/assignments/stun-parameters.
IETFレビュー（0x8000-0xFFFF）のcomprehension-optional範囲の新しいSTUN [RFC5389]属性が、セクション7.2.2で定義されたECN-CHECK STUN属性（0x802D）に割り当てられました。 STUN属性レジストリは、現在http://www.iana.org/assignments/stun-parametersにあります。
A new ICE option "rtp+ecn" has been registered in the "ICE Options" registry created by [RFC6336].
新しいICEオプション「rtp + ecn」が、[RFC6336]によって作成された「ICEオプション」レジストリに登録されました。
The use of ECN with RTP over UDP as specified in this document has the following known security issues that need to be considered.
このドキュメントで指定されているRTP over UDPでのECNの使用には、以下の既知のセキュリティ問題を考慮する必要があります。
External threats to the RTP and RTCP traffic:
RTPおよびRTCPトラフィックに対する外部の脅威：
Denial of Service affecting RTCP: An attacker that can modify the traffic between the media sender and a receiver can achieve either of two things: 1) report a lot of packets as being congestion experience marked, thus forcing the sender into a congestion response; or 2) ensure that the sender disables the usage of ECN by reporting failures to receive ECN by changing the counter fields. This can also be accomplished by injecting false RTCP packets to the media sender. Reporting a lot of ECN-CE-marked traffic is likely the more efficient denial-of-service tool as that may likely force the application to use the lowest possible bitrates. The prevention against an external threat is to integrity protect the RTCP feedback information and authenticate the sender.
RTCPに影響を与えるサービス拒否：メディアの送信者と受信者の間のトラフィックを変更できる攻撃者は、次の2つのいずれかを達成できます。1）輻輳の経験がマークされているとして大量のパケットを報告し、送信者に輻輳応答を強制する。または2）カウンターフィールドを変更してECNの受信の失敗を報告することにより、送信者がECNの使用を無効にするようにします。これは、メディアセンダーに偽のRTCPパケットを注入することでも実現できます。 ECN-CEでマークされた大量のトラフィックを報告することは、アプリケーションに可能な限り低いビットレートを使用するよう強制する可能性があるため、より効率的なサービス拒否ツールである可能性があります。外部の脅威に対する防止策は、RTCPフィードバック情報を完全に保護し、送信者を認証することです。
Information leakage: The ECN feedback mechanism exposes the receiver's perceived packet loss and the packets it considers to be ECN-CE marked. This is mostly not considered sensitive information. If it is considered sensitive, the RTCP feedback should be encrypted.
情報漏洩：ECNフィードバックメカニズムは、受信者の認識されたパケット損失と、ECN-CEマークが付けられていると見なされるパケットを公開します。これはほとんど機密情報とは見なされません。機密と見なされる場合は、RTCPフィードバックを暗号化する必要があります。
Changing the ECN bits: An on-path attacker that sees the RTP packet flow from sender to receiver and who has the capability to change the packets can rewrite ECT into ECN-CE, thus leading to erroneous congestion response in the sender or receiver. This denial of service against the media quality in the RTP session is impossible for an endpoint to protect itself against. Only network infrastructure nodes can detect this illicit re-marking. It will be mitigated by turning off ECN; however, if the attacker can modify its response to drop packets, the same vulnerability exist.
ECNビットの変更：送信者から受信者へのRTPパケットフローを見て、パケットを変更する機能を持っているパス上の攻撃者は、ECTをECN-CEに書き換えることができるため、送信者または受信者で誤った輻輳応答が発生する可能性があります。 RTPセッションのメディア品質に対するこのサービス拒否は、エンドポイントが自分自身を保護することは不可能です。この不正な再マーキングを検出できるのは、ネットワークインフラストラクチャノードだけです。 ECNをオフにすることで軽減されます。ただし、攻撃者が応答を変更してパケットをドロップできる場合、同じ脆弱性が存在します。
Denial of Service affecting the session setup signalling: If an attacker can modify the session signalling, it can prevent the usage of ECN by removing the signalling attributes used to indicate that the initiator is capable and willing to use ECN with RTP/UDP. This attack can be prevented by authentication and integrity protection of the signalling. We do note that any attacker that can modify the signalling has more interesting attacks they can perform than prevent the usage of ECN, like inserting itself as a middleman in the media flows enabling wire-tapping also for an off-path attacker.
セッションセットアップシグナリングに影響するサービス拒否：攻撃者がセッションシグナリングを変更できる場合、イニシエーターがRTP / UDPでECNを使用できることを示すために使用されているシグナリング属性を削除することにより、ECNの使用を防ぐことができます。この攻撃は、シグナリングの認証と整合性保護により防止できます。シグナリングを変更できる攻撃者は、メディアフローに仲介者として自分自身を挿入してパス外の攻撃者も盗聴できるようにするなど、ECNの使用を防ぐよりも興味深い攻撃を実行できることに注意してください。
Threats that exist from misbehaving senders or receivers:
不正な送信者または受信者からの脅威：
Receivers cheating: A receiver may attempt to cheat and fail to report reception of ECN-CE-marked packets. The benefit for a receiver cheating in its reporting would be to get an unfair bitrate share across the resource bottleneck. It is far from certain that a receiver would be able to get a significant larger share of the resources. That assumes a high enough level of aggregation that there are flows to acquire shares from. The risk of cheating is that failure to react to congestion results in packet loss and increased path delay.
受信者の不正行為：受信者は、ECN-CEでマークされたパケットの受信をだまし、報告に失敗する場合があります。レポートで不正行為をしている受信者にとっての利点は、リソースのボトルネック全体で不当なビットレート共有が行われることです。レシーバーがリソースのかなり大きなシェアを獲得できるとはほど遠い。これは、シェアを取得するフローが存在するほど十分に高いレベルの集約を想定しています。不正行為のリスクは、輻輳への対応に失敗すると、パケット損失が発生し、パス遅延が増加することです。
Receivers misbehaving: A receiver may prevent the usage of ECN in an RTP session by reporting itself as non-ECN capable, forcing the sender to turn off usage of ECN. In a point-to-point scenario, there is little incentive to do this as it will only affect the receiver, thus failing to utilise an optimisation. For multi-party sessions, some motivation exists for why a receiver would misbehave as it can prevent the other receivers from using ECN. As an insider into the session, it is difficult to determine if a receiver is misbehaving or simply incapable, making it basically impossible in the incremental deployment phase of ECN for RTP usage to determine this. If additional information about the receivers and the network is known, it might be possible to deduce that a receiver is misbehaving. If it can be determined that a receiver is misbehaving, the only response is to exclude it from the RTP session and ensure that it no longer has any valid security context to affect the session.
レシーバーの誤動作：レシーバーは、自身を非ECN対応として報告し、センダーにECNの使用をオフにすることを強制することにより、RTPセッションでのECNの使用を妨げることがあります。ポイントツーポイントのシナリオでは、レシーバーにのみ影響を及ぼし、最適化を利用できないため、これを行うインセンティブはほとんどありません。マルチパーティセッションの場合、他の受信者がECNを使用できなくなるため、受信者が誤動作する理由には、いくつかの動機があります。セッションの内部関係者として、レシーバーが正しく動作していないか、単に動作していないかを判断することは困難であり、ECPの増分展開フェーズでは、RTPの使用についてこれを判断することは基本的に不可能です。レシーバーとネットワークに関する追加情報がわかっている場合は、レシーバーの動作に問題があると推測できる可能性があります。レシーバーの動作に問題があると判断できる場合、唯一の応答は、RTPセッションからレシーバーを除外し、セッションに影響を与える有効なセキュリティコンテキストがなくなったことを確認することです。
Misbehaving senders: The enabling of ECN gives the media packets a higher degree of probability to reach the receiver compared to not-ECT-marked ones on an ECN-capable path. However, this is no magic bullet, and failure to react to congestion will most likely only slightly delay a network buffer over-run, in which its session also will experience packet loss and increased delay. There is some possibility that the media sender's traffic will push other traffic out of the way without being affected too negatively. However, we do note that a media sender still needs to implement congestion control functions to prevent the media from being badly affected by congestion events. Thus, the misbehaving sender is getting an unfair share. This can only be detected and potentially prevented by network monitoring and administrative entities. See Section 7 of [RFC3168] for more discussion of this issue.
送信者の誤動作：ECNを有効にすると、ECN対応のパスでECTがマークされていないものと比較して、メディアパケットが受信者に到達する確率が高くなります。ただし、これは特効薬ではありません。輻輳に反応しないと、ネットワークバッファーのオーバーランがわずかに遅延するだけで、セッションでパケット損失が発生し、遅延が増加します。メディア送信者のトラフィックが他のトラフィックに悪影響を与えることなく押しのける可能性があります。ただし、メディア送信者は、メディアが輻輳イベントによって悪影響を受けないように、輻輳制御機能を実装する必要があることに注意してください。したがって、不正な送信者は不当なシェアを得ています。これは、ネットワークモニタリングおよび管理エンティティによってのみ検出され、潜在的に防止できます。この問題の詳細については、[RFC3168]のセクション7をご覧ください。
We note that the endpoint security functions needed to prevent an external attacker from interfering with the signalling are source authentication and integrity protection. To prevent information leakage from the feedback packets, encryption of the RTCP is also needed. For RTP, multiple possible solutions exist depending on the application context. Secure RTP (SRTP) [RFC3711] does satisfy the requirement to protect this mechanism. Note, however, that when using SRTP in group communication scenarios, different parties might share the same security context; in this case, the authentication mechanism only shows that one of those parties is involved, not necessarily which one. IPsec [RFC4301] and DTLS [RFC6347] can also provide the necessary security functions.
外部の攻撃者がシグナリングに干渉するのを防ぐために必要なエンドポイントセキュリティ機能は、送信元認証と整合性保護であることに注意してください。フィードバックパケットからの情報漏洩を防ぐために、RTCPの暗号化も必要です。 RTPの場合、アプリケーションコンテキストに応じて複数の可能なソリューションが存在します。 Secure RTP（SRTP）[RFC3711]は、このメカニズムを保護するための要件を満たしています。ただし、グループ通信シナリオでSRTPを使用する場合、異なるパーティが同じセキュリティコンテキストを共有する場合があることに注意してください。この場合、認証メカニズムはそれらの当事者の1つが関与していることのみを示し、必ずしもどちらが関与しているのかを示しているわけではありません。 IPsec [RFC4301]およびDTLS [RFC6347]も、必要なセキュリティ機能を提供できます。
The signalling protocols used to initiate an RTP session also need to be source authenticated and integrity protected to prevent an external attacker from modifying any signalling. An appropriate mechanism to protect the used signalling needs to be used. For SIP/ SDP, ideally Secure MIME (S/MIME) [RFC5751] would be used. However, with the limited deployment, a minimal mitigation strategy is to require use of SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop-by-hop protection.
RTPセッションを開始するために使用されるシグナリングプロトコルは、外部の攻撃者がシグナリングを変更できないように、ソース認証され、整合性が保護されている必要があります。使用されているシグナリングを保護する適切なメカニズムを使用する必要があります。 SIP / SDPの場合、理想的には安全なMIME（S / MIME）[RFC5751]が使用されます。ただし、展開が制限されているため、最小限の緩和戦略はSIPS（SIP over TLS）[RFC3261] [RFC5630]を使用して少なくともホップごとの保護を実現することを要求することです。
We do note that certain mitigation methods will require network functions.
特定の緩和方法ではネットワーク機能が必要になることに注意してください。
This section contains a few different examples of the signalling mechanism defined in this specification in an SDP context. If there are discrepancies between these examples and the specification text, the specification text is definitive.
このセクションには、SDPコンテキストでこの仕様で定義されているシグナリングメカニズムのいくつかの異なる例が含まれています。これらの例と仕様テキストの間に矛盾がある場合は、仕様テキストが決定的です。
This example is a basic offer/answer SDP exchange, assumed done by SIP (not shown). The intention is to establish a basic audio session point-to-point between two users.
この例は、SIP（図示せず）によって実行されることを前提とした基本的なオファー/アンサーSDP交換です。その目的は、2人のユーザー間でポイントツーポイントの基本的なオーディオセッションを確立することです。
The Offer:
オファー：
v=0
o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
a=ice-options:rtp+ecn
t=0 0
m=audio 45664 RTP/AVPF 97 98 99
c=IN IP4 192.0.2.3
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice rtp ect=0 mode=setread
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=rtcp-rsize
a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.4 rport 8998
This SDP offer presents a single media stream with 3 media payload types. It proposes to use ECN with RTP, with the ICE-based initialisation being preferred over the RTP/RTCP one. Leap of faith is not suggested to be used. The offerer is capable of both setting and reading the ECN bits. In addition, the use of both the RTCP ECN feedback packet and the RTCP XR ECN Summary Report are supported. ICE is also proposed with two candidates. It also supports reduced-size RTCP and can use it.
このSDPオファーは、3つのメディアペイロードタイプを持つ単一のメディアストリームを提供します。 RTPでECNを使用することを提案し、ICEベースの初期化がRTP / RTCPよりも優先されます。信仰の飛躍を使用することはお勧めしません。提供者は、ECNビットの設定と読み取りの両方が可能です。さらに、RTCP ECNフィードバックパケットとRTCP XR ECNサマリーレポートの両方の使用がサポートされています。 ICEも2人の候補者とともに提案されています。縮小サイズのRTCPもサポートしており、使用できます。
The Answer:
答え：
v=0
o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=ice-options:rtp+ecn
t=0 0
m=audio 53879 RTP/AVPF 97 99
c=IN IP4 198.51.100.235
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice ect=0 mode=readonly
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ host
The answer confirms that only one media stream will be used. One RTP payload type was removed. ECN capability was confirmed, and the initialisation method will be ICE. However, the answerer is only capable of reading the ECN bits, which means that ECN can only be used for RTP flowing from the offerer to the answerer. ECT always set to 0 will be used in both directions. Both the RTCP ECN feedback packet and the RTCP XR ECN Summary Report will be used. Reduced-size RTCP will not be used as the answerer has not indicated support for it in the answer.
答えは、1つのメディアストリームのみが使用されることを確認しています。 1つのRTPペイロードタイプが削除されました。 ECN機能が確認され、初期化方法はICEになります。ただし、回答者はECNビットを読み取ることしかできません。つまり、ECNは、提供者から回答者に流れるRTPにのみ使用できます。 ECTを常に0に設定すると、両方向で使用されます。 RTCP ECNフィードバックパケットとRTCP XR ECNサマリーレポートの両方が使用されます。回答者が回答でそれに対するサポートを示していないため、縮小サイズのRTCPは使用されません。
The session below describes an Any-Source Multicast using a session with a single media stream.
以下のセッションでは、単一のメディアストリームを使用したセッションを使用したAny-Source Multicastについて説明します。
v=0
o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235
s=Multicast SDP session using ECN for RTP
i=Multicasted audio chat using ECN for RTP
b=AS:128
t=3502892703 3502910700
m=audio 56144 RTP/AVPF 97
c=IN IP4 233.252.0.212/127
a=rtpmap:97 g719/48000/1
a=fmtp:97 maxred=160
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: rtp mode=readonly; ect=0
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1500
a=rtcp-xr:ecn-sum
This is a declarative SDP example and indicates required functionality in the consumer of the SDP. The initialisation method required is the RTP/RTCP-based one, indicated by the "a=ecn-capable-rtp: rtp ..." line. Receivers are required to be able to read ECN marks ("mode=readonly"), and the ECT value is recommended to be set to 0 always ("ect=0"). The ECN usage in this session requires both ECN feedback and RTCP XR ECN Summary Reports, and their use is indicated through the "a=rtcp-fb:" and "a=rtcp-xr:ecn-sum" lines.
これは宣言的なSDPの例であり、SDPのコンシューマーに必要な機能を示しています。必要な初期化方法は、RTP / RTCPベースの初期化方法で、「a = ecn-capable-rtp：rtp ...」の行で示されています。受信者はECNマークを読み取ることができる必要があり（ "mode = readonly"）、ECT値は常に0に設定することをお勧めします（ "ect = 0"）。このセッションでのECNの使用には、ECNフィードバックとRTCP XR ECNサマリーレポートの両方が必要です。これらの使用は、「a = rtcp-fb：」および「a = rtcp-xr：ecn-sum」行で示されます。
The authors wish to thank the following individuals for their reviews and comments: Thomas Belling, Bob Briscoe, Roni Even, Kevin P. Flemming, Tomas Frankkila, Christian Groves, Christer Holmgren, Cullen Jennings, Tom Van Caenegem, Simo Veikkolainen, Bill Ver Steeg, Dan Wing, Qin Wu, and Lei Zhu.
著者は、レビューとコメントについて次の個人に感謝したいと思います：Thomas Belling、Bob Briscoe、Roni Even、Kevin P. Flemming、Tomas Frankkila、Christian Groves、Christer Holmgren、Cullen Jennings、Tom Van Caenegem、Simo Veikkolainen、Bill Ver Steeg 、ダンウィング、キンウー、レイジュ。
[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月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[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：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T。、カセレス、R。、およびA.クラーク、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[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。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、2008年9月。
[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月。
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for Interactive Connectivity Establishment (ICE) Options", RFC 6336, July 2011.
[RFC6336] Westerlund、M。、およびC. Perkins、「IANA Registry for Interactive Connectivity Establishment（ICE）Options」、RFC 6336、2011年7月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
[RFC2762] Rosenberg、J。およびH. Schulzrinne、「RTPのグループメンバーシップのサンプリング」、RFC 2762、2000年2月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、2000年10月。
[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：Session Initiation Protocol」 、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月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Ronce Explicit Congestion Notification（ECN）Signaling with Nonces」、RFC 3540、2003年6月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、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]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V。、およびR. Hakenberg、「RTP Retransmission Payload Format」、RFC 4588、2006年7月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「ソース固有のIPマルチキャスト」、RFC 4607、2006年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 5117、2008年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 5124、2008年2月。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[RFC5506] Johansson、I。およびM. Westerlund、「Reduced-Size Real-Time Transport Control Protocol（RTCP）：Opportunities and Consequences」、RFC 5506、2009年4月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630]オーデットF.、「セッション開始プロトコル（SIP）でのSIPS URIスキームの使用」、RFC 5630、2009年10月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760] Ott、J.、Chesterfield、J。、およびE. Schooler、「ユニキャストフィードバックのある単一ソースマルチキャストセッション用のRTP制御プロトコル（RTCP）拡張」、RFC 5760、2010年2月。
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, April 2011.
[RFC6189] Zimmermann、P.、Johnston、A。、およびJ. Callas、「ZRTP：Media Path Key Agreement for Unicast Secure RTP」、RFC 6189、2011年4月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
Authors' Addresses
著者のアドレス
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 EMail: magnus.westerlund@ericsson.com
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden電話：+46 10 714 82 87メール：magnus.westerlund@ericsson.com
Ingemar Johansson Ericsson Laboratoriegrand 11 SE-971 28 Lulea Sweden Phone: +46 73 0783289 EMail: ingemar.s.johansson@ericsson.com
Ingemar Johansson Ericsson Laboratoriegrand 11 SE-971 28 Lulea Sweden電話：+46 73 0783289メール：ingemar.s.johansson@ericsson.com
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom EMail: csp@csperkins.org
コリンパーキンスグラスゴー大学コンピューティングサイエンススクールグラスゴーG12 8QQイギリスEメール：csp@csperkins.org
Piers O'Hanlon University of Oxford Oxford Internet Institute 1 St Giles Oxford OX1 3JS United Kingdom EMail: piers.ohanlon@oii.ox.ac.uk
ピアスオハンロンオックスフォード大学オックスフォードインターネットインスティテュート1セントジャイルズオックスフォードOX1 3JSイギリスEメール：piers.ohanlon@oii.ox.ac.uk
Ken Carlberg G11 1600 Clarendon Blvd Arlington, VA USA EMail: carlberg@g11.org.uk
ケンカールバーグG11 1600 Clarendon Blvdアーリントン、バージニアアメリカ合衆国メール：carlberg@g11.org.uk