[要約] RFC 7198は、RTPストリームの複製に関するガイドラインを提供するものであり、主な目的は、ネットワーク上でのRTPストリームの効率的な複製を可能にすることです。
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7198 Cisco
Category: Standards Track C. Perkins
ISSN: 2070-1721 University of Glasgow
April 2014
Duplicating RTP Streams
RTPストリームの複製
Abstract
概要
Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.
パケット損失は、リアルタイムのマルチメディアセッションには望ましくありませんが、計画外のネットワークの停止など、さまざまな理由で発生する可能性があります。ユニキャスト送信では、失われる可能性のあるパケットが多数になる可能性があるため、停止期間によっては、このような停止からの回復が困難になる場合があります。マルチキャスト送信では、多くのレシーバーが停止の影響を受ける可能性があるため、リカバリーはさらに困難です。この課題に対して、無限の遅延を発生させないソリューションの1つは、基盤となるネットワークが特定の要件を満たしている場合に、パケットを複製して個別の冗長ストリームで送信することです。このドキュメントでは、RTPまたはRTP制御プロトコル（RTCP）のルールに違反せずに、リアルタイムトランスポートプロトコル（RTP）ストリームを複製する方法について説明します。
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/rfc7198.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7198で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements Notation . . . . . . . . . . . . 4
3. Use Cases for Dual Streaming . . . . . . . . . . . . . . . . 4
3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 4
3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 5
3.3. Dual Streaming over a Single Path or Multiple Paths . . . 5
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 7
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 7
4.2. Signaling Considerations . . . . . . . . . . . . . . . . 7
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 9
5.2. Signaling Considerations . . . . . . . . . . . . . . . . 9
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 10
7. Congestion Control Considerations . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
The Real-time Transport Protocol (RTP) [RFC3550] is widely used today for delivering IPTV traffic and other real-time multimedia sessions. Many of these applications support very large numbers of receivers and rely on intra-domain UDP/IP multicast for efficient distribution of traffic within the network.
リアルタイムトランスポートプロトコル（RTP）[RFC3550]は、IPTVトラフィックやその他のリアルタイムマルチメディアセッションを配信するために今日広く使用されています。これらのアプリケーションの多くは、非常に多数のレシーバーをサポートし、ネットワーク内のトラフィックを効率的に配信するためにドメイン内UDP / IPマルチキャストに依存しています。
While this combination has proved successful, there does exist a weakness. As [RFC2354] noted, packet loss is not avoidable. This loss might be due to congestion; it might also be a result of an unplanned outage caused by a flapping link, a link or interface failure, a software bug, or a maintenance person accidentally cutting the wrong fiber. Since UDP/IP flows do not provide any means for detecting loss and retransmitting packets, it is left up to the RTP layer and the applications to detect, and recover from, packet loss.
この組み合わせは成功していることが証明されていますが、弱点もあります。 [RFC2354]が述べたように、パケット損失は避けられません。この損失は、輻輳が原因である可能性があります。また、フラッピングリンク、リンクまたはインターフェイスの障害、ソフトウェアのバグ、または保守担当者が誤って間違ったファイバを切断したことが原因で、計画外の停止が発生した可能性もあります。 UDP / IPフローは、損失を検出してパケットを再送信する手段を提供しないため、RTPレイヤーとアプリケーションに任され、パケット損失を検出して回復します。
In a carefully managed network, congestion should not normally happen; however, network outages can still happen due to the reasons listed above. In such a managed network, one technique to recover from packet loss without incurring unbounded delay is to duplicate the packets and send them in separate redundant streams. As described later in this document, the probability that two copies of the same packet are lost in cases of non-congestive packet loss is quite small.
注意深く管理されたネットワークでは、通常、輻輳は発生しません。ただし、上記の理由により、ネットワークが停止する可能性があります。このような管理されたネットワークで、無制限の遅延を発生させずにパケット損失から回復する1つの方法は、パケットを複製して、別々の冗長ストリームで送信することです。このドキュメントで後述するように、非輻輳パケット損失の場合に同じパケットの2つのコピーが失われる可能性は非常に小さいです。
Variations on this idea have been implemented and deployed today [IC2011]. However, duplication of RTP streams without breaking the RTP and RTCP functionality has not been documented properly. This document discusses the most common use cases and explains how duplication can be achieved for RTP streams in such use cases to address the immediate market needs. In the future, if there will be a different use case that is not covered by this document, a new specification that explains how RTP duplication should be done in such a scenario may be needed.
このアイデアのバリエーションが今日実装され、展開されています[IC2011]。ただし、RTPおよびRTCP機能を損なうことなくRTPストリームを複製することは、適切に文書化されていません。このドキュメントでは、最も一般的なユースケースについて説明し、そのようなユースケースでRTPストリームを複製して、当面の市場ニーズに対処する方法を説明します。今後、このドキュメントで取り上げられていない別のユースケースが発生する場合は、そのようなシナリオでRTPの複製をどのように行うべきかを説明する新しい仕様が必要になる可能性があります。
Stream duplication offers a simple way to protect media flows from packet loss. It has a comparatively high overhead in terms of bandwidth, since everything is sent twice, but with a low overhead in terms of processing. It is also very predictable in its overheads. Alternative approaches, for example, retransmission-based recovery [RFC4588] or Forward Error Correction [RFC6363], may be suitable in some other cases.
ストリームの複製は、メディアフローをパケット損失から保護する簡単な方法を提供します。すべてが2回送信されるため、帯域幅に関してはオーバーヘッドが比較的高くなりますが、処理に関してはオーバーヘッドが低くなります。オーバーヘッドも非常に予測可能です。他のいくつかのケースでは、たとえば、再送信ベースのリカバリ[RFC4588]やフォワードエラー訂正[RFC6363]などの代替アプローチが適している場合があります。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Dual streaming refers to a technique that involves transmitting two redundant RTP streams (the original plus its duplicate) of the same content, with each stream capable of supporting the playback when there is no packet loss. Therefore, adding an additional RTP stream provides a protection against packet loss. The level of protection depends on how the packets are sent and transmitted inside the network.
デュアルストリーミングとは、同じコンテンツの2つの冗長RTPストリーム（オリジナルとその複製）を送信する技術を指し、各ストリームはパケット損失がない場合に再生をサポートできます。したがって、追加のRTPストリームを追加すると、パケット損失に対する保護が提供されます。保護のレベルは、パケットがネットワーク内でどのように送受信されるかに依存します。
It is important to note that dual streaming can easily be extended to support cases when more than two streams are desired. However, using three or more streams is rare in practice, due to the high overhead that it incurs and the little additional protection it provides.
デュアルストリーミングは、3つ以上のストリームが必要な場合をサポートするように簡単に拡張できることに注意することが重要です。ただし、3つ以上のストリームを使用しても、オーバーヘッドが高く、追加の保護がほとんどないため、実際にはまれです。
From a routing perspective, two streams are considered identical if the following two IP header fields are the same (in addition to the transport ports), since they will be both routed over the same path:
ルーティングの観点からは、次の2つのIPヘッダーフィールドが同じである場合（トランスポートポートに加えて）、2つのストリームは同じパスでルーティングされるため、同一であると見なされます。
o IP Source Address
o IPソースアドレス
o IP Destination Address
o IP宛先アドレス
Two routing-plane identical RTP streams might carry the same payload but can use different Synchronization Sources (SSRCs) to differentiate the RTP packets belonging to each stream. In the context of dual RTP streaming, we assume that the sender duplicates the RTP packets and sends them in separate RTP streams, each with a unique SSRC. All the redundant streams are transmitted in the same RTP session.
2つのルーティングプレーンの同一のRTPストリームは同じペイロードを運ぶかもしれませんが、各ストリームに属するRTPパケットを区別するために異なる同期ソース（SSRC）を使用できます。デュアルRTPストリーミングのコンテキストでは、送信者がRTPパケットを複製し、それぞれが一意のSSRCを持つ個別のRTPストリームで送信すると想定しています。すべての冗長ストリームは同じRTPセッションで送信されます。
For example, one main stream and its duplicate stream can be sent to the same IP destination address and UDP destination port with a certain delay between them [RFC7197]. The streams carry the same payload in their respective RTP packets with identical sequence numbers. This allows receivers (or other nodes responsible for gap filling and duplicate suppression) to identify and suppress the duplicate packets, and subsequently produce a hopefully loss-free and duplication-free output stream. This process is commonly called "stream merging" or "de-duplication".
たとえば、1つのメインストリームとその複製ストリームは、同じIP宛先アドレスとUDP宛先ポートに送信できますが、それらの間には一定の遅延があります[RFC7197]。ストリームは、同じシーケンス番号を持つそれぞれのRTPパケットで同じペイロードを伝送します。これにより、レシーバー（またはギャップフィルと重複抑制を担当する他のノード）が重複パケットを識別して抑制し、その後、損失のない、重複のない出力ストリームを生成できます。このプロセスは一般に「ストリームのマージ」または「重複除外」と呼ばれます。
An RTP source might be associated with multiple network interfaces, allowing it to send two redundant streams from two separate source addresses. Such streams can be routed over diverse or identical paths, depending on the routing algorithm used inside the network. At the receiving end, the node responsible for duplicate suppression can look into various RTP header fields, for example, SSRC and sequence number, to identify and suppress the duplicate packets.
RTPソースは複数のネットワークインターフェイスに関連付けられている場合があり、2つの別個のソースアドレスから2つの冗長ストリームを送信できます。このようなストリームは、ネットワーク内で使用されるルーティングアルゴリズムに応じて、多様なパスまたは同一のパスを介してルーティングできます。受信側で、重複抑制を担当するノードは、SSRCやシーケンス番号などのさまざまなRTPヘッダーフィールドを調べて、重複パケットを識別および抑制できます。
If source-specific multicast (SSM) transport is used to carry such redundant streams, there will be a separate SSM session for each redundant stream since the streams are sourced from different interfaces (i.e., IP addresses). Thus, the receiving host has to join each SSM session separately.
ソース固有のマルチキャスト（SSM）トランスポートがそのような冗長ストリームを運ぶために使用される場合、ストリームは異なるインターフェース（つまり、IPアドレス）から供給されるため、冗長ストリームごとに個別のSSMセッションが存在します。したがって、受信ホストは各SSMセッションに個別に参加する必要があります。
Alternatively, the destination host could also have multiple IP addresses for an RTP source to send the redundant streams to.
または、宛先ホストは、RTPソースが冗長ストリームを送信するための複数のIPアドレスを持つこともできます。
Having described the characteristics of the streams, one can reach the following conclusions:
ストリームの特性について説明したので、次の結論に達することができます。
1. When two routing-plane identical streams are used, the flow labels will be the same. This makes it impractical to forward the packets onto different paths. In order to minimize packet loss, the packets belonging to one stream are often interleaved with packets belonging to its duplicate stream, and with a delay, so that if there is a packet loss, such a delay would allow the same packet from the duplicate stream to reach the receiver because the chances that the same packet is lost in transit again are often small. This is what is also known as "time-shifted redundancy", "temporal redundancy" or simply "delayed duplication" [RFC7197] [IC2011]. This approach can be used with both types of dual streaming, described in Sections 3.1 and 3.2.
1. 2つのルーティングプレーンの同一のストリームが使用される場合、フローラベルは同じになります。このため、パケットを異なるパスに転送することは現実的ではありません。パケット損失を最小限に抑えるために、1つのストリームに属するパケットは、その複製ストリームに属するパケットと遅延してインタリーブされることが多いため、パケット損失がある場合、そのような遅延により、複製ストリームからの同じパケットが許可されます。同じパケットが転送中に再び失われる可能性は少ないため、受信者に到達することはしばしばあります。これは、「タイムシフト冗長性」、「時間的冗長性」、または単に「遅延複製」としても知られているものです[RFC7197] [IC2011]。このアプローチは、セクション3.1と3.2で説明されている両方のタイプのデュアルストリーミングで使用できます。
2. If the two streams have different IP headers, an additional opportunity arises in that one is able to build a network, with physically diverse paths, to deliver the two streams concurrently to the intended receivers. This reduces the delay when packet loss occurs and needs to be recovered. Additionally, it also further reduces chances for packet loss. An unrecoverable loss happens only when two network failures happen in such a way that the same packet is affected on both paths. This is referred to as Spatial Diversity or Spatial Redundancy [IC2011]. The techniques used to build diverse paths are beyond the scope of this document.
2. 2つのストリームのIPヘッダーが異なる場合、物理的に多様なパスを持つネットワークを構築して、2つのストリームを同時に目的の受信者に配信できるという追加の機会が生じます。これにより、パケット損失が発生し、回復する必要がある場合の遅延が減少します。さらに、パケット損失の可能性をさらに減らします。回復不能な損失が発生するのは、2つのネットワーク障害が発生して、両方のパスで同じパケットが影響を受ける場合のみです。これは、空間多様性または空間冗長性と呼ばれます[IC2011]。多様なパスを構築するために使用される手法は、このドキュメントの範囲を超えています。
Note that spatial redundancy often offers less delay in recovering from packet loss, provided that the forwarding delay of the network paths are more or less the same. (This is often ensured through careful network design.) For both temporal and spatial redundancy approaches, packet misordering might still happen and needs to be handled using the sequence numbers of some sort (e.g., RTP sequence numbers).
ネットワークパスの転送遅延がほぼ同じであれば、空間的冗長性により、パケット損失からの回復の遅延が少なくなることがよくあります。 （これは多くの場合、慎重なネットワーク設計によって保証されます。）時間的および空間的冗長アプローチの両方で、パケットの順序の乱れが依然として発生する可能性があり、ある種のシーケンス番号（RTPシーケンス番号など）を使用して処理する必要があります。
Temporal and spatial redundancy deal with different patterns of packet loss. The former helps with transient loss (within the duplication window), while the latter helps with longer-term packet loss that affects only one of the two redundant paths.
時間的および空間的冗長性は、パケット損失のさまざまなパターンを扱います。前者は一時的な損失（複製ウィンドウ内）に役立ち、後者は2つの冗長パスの1つにのみ影響する長期的なパケット損失に役立ちます。
To summarize, dual streaming allows an application and a network to work together to provide a near-zero-loss transport with a bounded or minimum delay. The additional advantage includes a predictable bandwidth overhead that is proportional to the minimum bandwidth needed for the multimedia session, but independent of the number of receivers experiencing a packet loss and requesting a retransmission. For a survey and comparison of similar approaches, refer to [IC2011].
要約すると、デュアルストリーミングを使用すると、アプリケーションとネットワークが連携して、損失がゼロに近いトランスポートを制限付きまたは最小の遅延で提供できます。追加の利点には、マルチメディアセッションに必要な最小帯域幅に比例する予測可能な帯域幅オーバーヘッドが含まれますが、パケット損失が発生し、再送信を要求するレシーバーの数とは無関係です。同様のアプローチの調査と比較については、[IC2011]を参照してください。
One of the following conditions is currently REQUIRED to hold in applications using this specification:
現在、この仕様を使用するアプリケーションで保持するには、次のいずれかの条件が必要です。
o The original and duplicate RTP streams are carried (with their own SSRCs) in the same "m" line. (There could be other RTP streams listed in the same "m" line.)
o 元のRTPストリームと重複するRTPストリームは、同じ「m」行で（独自のSSRCとともに）伝送されます。 （同じ "m"行にリストされている他のRTPストリームが存在する可能性があります。）
o The original and duplicate RTP streams are carried in separate "m" lines, and there is no other RTP stream listed in either "m" line.
o 元のRTPストリームと複製のRTPストリームは別々の「m」行で運ばれ、どちらの「m」行にも他のRTPストリームはリストされていません。
When the original and duplicate RTP streams are carried in separate "m" lines in a Session Description Protocol (SDP) description and if the SDP description has one or more other RTP streams listed in either "m" line, duplication grouping is not trivial and further signaling will be needed; this is left for future standardization.
元のRTPストリームと重複するRTPストリームがセッション記述プロトコル（SDP）記述の別々の「m」行で運ばれ、SDP記述にいずれかの「m」行にリストされた1つ以上の他のRTPストリームがある場合、複製のグループ化は簡単ではなくさらなるシグナリングが必要になります。これは将来の標準化のために残されています。
To achieve temporal redundancy, the main and duplicate RTP streams SHOULD be sent using the sample 5-tuple of transport protocol, source and destination IP addresses, and source and destination transport ports. Due to the possible presence of network address and port translation (NAPT) devices, load balancers, or other middleboxes, use of anything other than an identical 5-tuple and flow label might also cause spatial redundancy (which might introduce an additional delay due to the delta between the path delays), and so it is NOT RECOMMENDED unless the path is known to be free of such middleboxes.
一時的な冗長性を実現するために、メインと複製のRTPストリームは、トランスポートプロトコルのサンプル5タプル、送信元と宛先のIPアドレス、および送信元と宛先のトランスポートポートを使用して送信する必要があります（SHOULD）。ネットワークアドレスとポート変換（NAPT）デバイス、ロードバランサー、またはその他のミドルボックスが存在する可能性があるため、同一の5タプルとフローラベル以外のものを使用すると、空間的な冗長性が生じる可能性があります（これにより、パス遅延間のデルタ）、したがって、パスにそのようなミドルボックスがないことがわかっている場合を除き、推奨されません。
Since the main and duplicate RTP streams follow an identical path, they are part of the same RTP session. Accordingly, the sender MUST choose a different SSRC for the duplicate RTP stream than it chose for the main RTP stream, following the rules in Section 8 of [RFC3550].
メインと複製のRTPストリームは同じパスをたどるので、それらは同じRTPセッションの一部です。したがって、送信者は[RFC3550]のセクション8のルールに従って、メインRTPストリームに対して選択したものとは異なるSSRCを複製RTPストリームに対して選択する必要があります。
If RTCP is being sent for the main RTP stream, then the sender MUST also generate RTCP for the duplicate RTP stream. The RTCP for the duplicate RTP stream is generated exactly as if the duplicate RTP stream were a regular media stream. The sender MUST NOT duplicate the RTCP packets sent for the main RTP stream when sending the duplicate stream; instead, it MUST generate new RTCP reports for the duplicate stream. The sender MUST use the same RTCP CNAME in the RTCP reports it sends for both streams, so that the receiver can synchronize them.
メインのRTPストリームにRTCPが送信されている場合、送信者は重複するRTPストリームのRTCPも生成する必要があります。複製RTPストリームのRTCPは、複製RTPストリームが通常のメディアストリームであるかのように生成されます。送信者は、複製ストリームを送信するときに、メインRTPストリームに送信されるRTCPパケットを複製してはなりません（MUST NOT）。代わりに、重複するストリームの新しいRTCPレポートを生成する必要があります。送信者は、受信者がそれらを同期できるように、両方のストリームに対して送信するRTCPレポートで同じRTCP CNAMEを使用する必要があります。
The main and duplicate streams are conceptually synchronized using the standard mechanism based on RTCP Sender Reports, deriving a mapping between their timelines. However, the RTP timestamps and sequence numbers MUST be identical in the main and duplicate streams, making the mapping quite trivial.
メインストリームと複製ストリームは、RTCP送信者レポートに基づく標準メカニズムを使用して概念的に同期され、タイムライン間のマッピングを導出します。ただし、RTPタイムスタンプとシーケンス番号は、メインストリームと複製ストリームで同一でなければならず、マッピングは非常に簡単です。
Both the main and duplicate RTP streams, and their corresponding RTCP reports, will be received. If RTCP is used, receivers MUST generate RTCP reports for both the main and duplicate streams in the usual way, treating them as entirely separate media streams.
メインと複製の両方のRTPストリーム、および対応するRTCPレポートが受信されます。 RTCPを使用する場合、受信者は通常の方法でメインストリームと複製ストリームの両方のRTCPレポートを生成し、完全に別個のメディアストリームとして扱う必要があります。
Signaling is needed to allow the receiver to determine that an RTP stream is a duplicate of another, rather than a separate stream that needs to be rendered in parallel. There are two parts to this: an SDP extension is needed in the offer/answer exchange to negotiate support for temporal redundancy; and signaling is needed to indicate which stream is the duplicate. (The latter can be done in-band using an RTCP extension or out-of-band in the SDP description.)
RTPストリームが並列にレンダリングする必要のある個別のストリームではなく、別のRTPストリームであることを受信者が判断できるようにするには、シグナリングが必要です。これには2つの部分があります。一時的な冗長性のサポートをネゴシエートするには、オファー/アンサー交換でSDP拡張が必要です。また、どのストリームが重複しているかを示すためにシグナリングが必要です。 （後者は、RTCP拡張を使用してインバンドで実行することも、SDP記述でアウトオブバンドで実行することもできます。）
Out-of-band signaling is needed for both features. The SDP attribute to signal duplication in the SDP offer/answer exchange ('duplication-delay') is defined in [RFC7197]. The required SDP grouping semantics are defined in [RFC7104].
両方の機能で帯域外シグナリングが必要です。 SDPオファー/アンサー交換（ 'duplication-delay'）における信号の複製に対するSDP属性は[RFC7197]で定義されています。必要なSDPグループ化セマンティクスは、[RFC7104]で定義されています。
In the following SDP example, a video stream is duplicated, and the main and duplicate streams are transmitted in two separate SSRCs (1000 and 1010):
次のSDPの例では、ビデオストリームが複製され、メインストリームと複製ストリームが2つの別々のSSRC（1000と1010）で送信されます。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:50
a=mid:Ch1
Section 3.2 of [RFC7104] states that it is advisable that the SSRC listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent first, with the other SSRC (i.e., SSRC of 1010) being the time-delayed duplicate. This is not critical, however, and a receiving host should size its playout buffer based on the 'duplication-delay' attribute and play the stream that arrives first in preference, with the other stream acting as a repair stream, irrespective of the order in which they are signaled.
[RFC7104]のセクション3.2では、「a = ssrc-group：」行の最初にリストされているSSRC（つまり、1000のSSRC）が最初に送信され、他のSSRC（つまり、1010のSSRC）が時間遅れの複製。ただし、これは重要ではありません。受信ホストは、「duplication-delay」属性に基づいてプレイアウトバッファのサイズを設定し、優先的に最初に到着したストリームを再生し、他のストリームは修復ストリームとして機能し、順序に関係なく彼らに合図します。
Assuming the network is structured appropriately, when using spatial redundancy, the duplicate RTP stream is sent using a different source and/or destination address/port pair. This will be a separate RTP session from the session conveying the main RTP stream. Thus, the SSRCs used for the main and duplicate streams MUST be chosen randomly, following the rules in Section 8 of [RFC3550]. Accordingly, they will almost certainly not match each other. The sender MUST, however, use the same RTCP CNAME for both the main and duplicate streams. An "a=group:DUP" line or "a=ssrc-group:DUP" line is used to indicate duplication.
ネットワークが適切に構成されていると仮定すると、空間冗長性を使用する場合、重複するRTPストリームは、異なる送信元および/または宛先アドレス/ポートのペアを使用して送信されます。これは、メインRTPストリームを伝達するセッションとは別のRTPセッションになります。したがって、メインストリームと複製ストリームに使用されるSSRCは、[RFC3550]のセクション8のルールに従って、ランダムに選択する必要があります。したがって、それらはほぼ確実に互いに一致しません。ただし、送信者はメインストリームと複製ストリームの両方に同じRTCP CNAMEを使用する必要があります。 「a = group：DUP」行または「a = ssrc-group：DUP」行は、重複を示すために使用されます。
If RTCP is being sent for the main RTP stream, then the sender MUST also generate RTCP for the duplicate RTP stream. The RTCP for the duplicate RTP stream is generated exactly as if the duplicate RTP stream were a regular media stream. The sender MUST NOT duplicate the RTCP packets sent for the main RTP stream when sending the duplicate stream; instead, it MUST generate new RTCP reports for the duplicate stream. The sender MUST use the same RTCP CNAME in the RTCP reports it sends for both streams, so that the receiver can synchronize them.
メインのRTPストリームにRTCPが送信されている場合、送信者は重複するRTPストリームのRTCPも生成する必要があります。複製RTPストリームのRTCPは、複製RTPストリームが通常のメディアストリームであるかのように生成されます。送信者は、複製ストリームを送信するときに、メインRTPストリームに送信されるRTCPパケットを複製してはなりません（MUST NOT）。代わりに、重複するストリームの新しいRTCPレポートを生成する必要があります。送信者は、受信者がそれらを同期できるように、両方のストリームに対して送信するRTCPレポートで同じRTCP CNAMEを使用する必要があります。
The main and duplicate streams are conceptually synchronized using the standard mechanism based on RTCP Sender Reports, deriving a mapping between their timelines. However, the RTP timestamps and sequence numbers MUST be identical in the main and duplicate streams, making the mapping quite trivial.
メインストリームと複製ストリームは、RTCP送信者レポートに基づく標準メカニズムを使用して概念的に同期され、タイムライン間のマッピングを導出します。ただし、RTPタイムスタンプとシーケンス番号は、メインストリームと複製ストリームで同一でなければならず、マッピングは非常に簡単です。
Both the main and duplicate RTP streams, and their corresponding RTCP reports, will be received. If RTCP is used, receivers MUST generate RTCP reports for both the main and duplicate streams in the usual way, treating them as entirely separate media streams.
メインと複製の両方のRTPストリーム、および対応するRTCPレポートが受信されます。 RTCPを使用する場合、受信者は通常の方法でメインストリームと複製ストリームの両方のRTCPレポートを生成し、完全に別個のメディアストリームとして扱う必要があります。
The required SDP grouping semantics have been defined in [RFC7104]. In the following example, the redundant streams have different IP destination addresses. The example shows the same UDP port number and IP source address for each stream, but either or both could have been different for the two streams.
必要なSDPグループ化セマンティクスは、[RFC7104]で定義されています。次の例では、冗長ストリームのIP宛先アドレスが異なります。この例では、各ストリームの同じUDPポート番号とIP送信元アドレスを示していますが、2つのストリームでどちらかまたは両方が異なっている可能性があります。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=mid:S1b
This uses the same RTP/RTCP mechanisms from Sections 4 and 5, plus a combination of signaling provided in each of these sections.
これは、セクション4および5と同じRTP / RTCPメカニズムを使用し、さらにこれらのセクションのそれぞれで提供されるシグナリングの組み合わせを使用します。
Duplicating RTP streams has several considerations in the context of congestion control. First of all, RTP duplication MUST NOT be used in cases where the primary cause of packet loss is congestion since duplication can make congestion only worse. Furthermore, RTP duplication SHOULD NOT be used where there is a risk of congestion upon duplicating an RTP stream. Duplication is RECOMMENDED only to be used for protection against network outages due to a temporary link or network element failure and where it is known (e.g., through explicit operator configuration) that there is sufficient network capacity to carry the duplicated traffic. The capacity requirement constrains the use of duplication to managed networks and makes it unsuitable for use on unmanaged public networks.
RTPストリームの複製には、輻輳制御のコンテキストでいくつかの考慮事項があります。まず第一に、RTPの複製は、パケットの損失の主な原因が輻輳である場合には使用してはならない（MUST NOT）。さらに、RTPストリームの複製時に輻輳のリスクがある場合は、RTP複製を使用しないでください。複製は、一時的なリンクまたはネットワーク要素の障害によるネットワークの停止と、複製されたトラフィックを伝送するのに十分なネットワーク容量があることが（たとえば、明示的なオペレーター構成によって）わかっている場合の保護のためにのみ使用することをお勧めします。キャパシティ要件により、管理対象ネットワークへの複製の使用が制限され、管理対象外のパブリックネットワークでの使用には適さなくなります。
It is essential that the nodes responsible for the duplication and de-duplication are aware of the original stream's requirements and the available capacity inside the network. If there is an adaptation capability for the original stream, these nodes have to assume the same adaptation capability for the duplicated stream, too. For example, if the source doubles the bitrate for the original stream, the bitrate of the duplicate stream will also be doubled.
複製と重複排除を担当するノードが、元のストリームの要件とネットワーク内で利用可能な容量を認識していることが重要です。元のストリームに適応機能がある場合、これらのノードは複製されたストリームにも同じ適応機能を想定する必要があります。たとえば、ソースが元のストリームのビットレートを2倍にすると、複製ストリームのビットレートも2倍になります。
Depending on where de-duplication takes place, there could be different scenarios. When the duplication and de-duplication take place inside the network before the ultimate endpoints that will consume the RTP media, the whole process is transparent to these endpoints. Thus, these endpoints will apply any congestion control, if applicable, on the de-duplicated RTP stream. This output stream will have fewer losses than either the original or duplicated stream will have, and the endpoint will make congestion control decisions accordingly. However, if de-duplication takes place at the ultimate endpoint, this endpoint MUST consider the aggregate of the original and duplicated RTP stream in any congestion control it wants to apply. The endpoint will observe the losses in each stream separately, and this information can be used to fine-tune the duplication process. For example, the duplication interval can be adjusted based on the duration of a common packet loss in both streams. In these scenarios, the RTP Monitoring Framework [RFC6792] can be used to monitor the duplicated streams in the same way an ordinary RTP would be monitored.
重複除外が行われる場所に応じて、さまざまなシナリオが考えられます。 RTPメディアを消費する最終的なエンドポイントの前にネットワーク内で複製と重複排除が行われる場合、プロセス全体はこれらのエンドポイントに対して透過的です。したがって、これらのエンドポイントは、重複排除されたRTPストリームに該当する場合、輻輳制御を適用します。この出力ストリームは、元のストリームまたは複製されたストリームよりも損失が少なく、エンドポイントはそれに応じて輻輳制御の決定を行います。ただし、重複排除が最終的なエンドポイントで行われる場合、このエンドポイントは、適用したいすべての輻輳制御で、元のRTPストリームと複製されたRTPストリームの集約を考慮する必要があります。エンドポイントは各ストリームの損失を個別に観察し、この情報を使用して複製プロセスを微調整できます。たとえば、両方のストリームでの一般的なパケット損失の期間に基づいて複製間隔を調整できます。これらのシナリオでは、RTP監視フレームワーク[RFC6792]を使用して、通常のRTPが監視されるのと同じ方法で複製されたストリームを監視できます。
The security considerations of [RFC3550], [RFC7104], [RFC7197], and any RTP profiles and payload formats in use apply.
[RFC3550]、[RFC7104]、[RFC7197]、および使用中のすべてのRTPプロファイルとペイロード形式のセキュリティに関する考慮事項が適用されます。
Duplication can be performed end-to-end, with the media sender generating a duplicate RTP stream, and the receiver(s) performing de-duplication. In such cases, if the original media stream is to be authenticated (e.g., using Secure RTP (SRTP) [RFC3711]), then the duplicate stream also needs to be authenticated, and duplicate packets that fail the authentication check need to be discarded.
複製はエンドツーエンドで実行でき、メディア送信者は複製のRTPストリームを生成し、受信者は重複排除を実行します。このような場合、元のメディアストリームを認証する場合（たとえば、Secure RTP（SRTP）[RFC3711]を使用）、重複するストリームも認証する必要があり、認証チェックに失敗した重複するパケットは破棄する必要があります。
Stream duplication and de-duplication can also be performed by in-network middleboxes. Such middleboxes will need to rewrite the RTP SSRC such that the RTP packets in the duplicate stream have a different SSRC to the original stream, and such middleboxes will need to generate and respond to RTCP packets corresponding to the duplicate stream. This sort of in-network duplication service has the potential to act as an amplifier for denial-of-service attacks if the attacker can cause attack traffic to be duplicated. To prevent this, middleboxes providing the duplication service need to authenticate the traffic to be duplicated as being from a legitimate source, for example, using the SRTP profile [RFC3711]. This requires the middlebox to be part of the security context of the media session being duplicated, so it has access to the necessary keying material for authentication. To do this, the middlebox will need to be privy to the session setup signaling. Details of how that is done will depend on the type of signaling used (SIP, Real Time Streaming Protocol (RTSP), WebRTC, etc.), and is not specified here.
ストリームの複製と重複排除は、ネットワーク内のミドルボックスでも実行できます。そのようなミドルボックスは、複製ストリームのRTPパケットが元のストリームとは異なるSSRCを持つようにRTP SSRCを書き換える必要があり、そのようなミドルボックスは、複製ストリームに対応するRTCPパケットを生成して応答する必要があります。この種のネットワーク内複製サービスは、攻撃者が攻撃トラフィックを複製させることができる場合、サービス拒否攻撃の増幅器として機能する可能性があります。これを防ぐために、複製サービスを提供するミドルボックスは、たとえばSRTPプロファイル[RFC3711]を使用して、複製されるトラフィックを正当なソースからのものとして認証する必要があります。これには、ミドルボックスが複製されるメディアセッションのセキュリティコンテキストの一部である必要があるため、認証に必要なキー情報にアクセスできます。これを行うには、ミドルボックスがセッションセットアップシグナリングに対応している必要があります。その方法の詳細は、使用されるシグナリングのタイプ（SIP、リアルタイムストリーミングプロトコル（RTSP）、WebRTCなど）によって異なり、ここでは指定しません。
Similarly, to prevent packet injection attacks, a de-duplication middlebox needs to authenticate original and duplicate streams, and ought not use non-authenticated packets that are received. Again, this requires the middlebox to be part of the security context and to have access to the appropriate signaling and keying material.
同様に、パケットインジェクション攻撃を防ぐために、重複除外ミドルボックスは元のストリームと重複するストリームを認証する必要があり、受信した認証されていないパケットを使用しないでください。この場合も、ミドルボックスがセキュリティコンテキストの一部であり、適切なシグナリングおよびキー情報にアクセスできる必要があります。
The use of the encryption features of SRTP does not affect stream de-duplication middleboxes, since the RTP headers are sent in the clear.
RTPヘッダーはクリアテキストで送信されるため、SRTPの暗号化機能を使用しても、ストリーム重複除外ミドルボックスには影響しません。
Thanks to Magnus Westerlund for his suggestions.
Magnus Westerlundの提案に感謝します。
[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月。
[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月。
[RFC7197] Begen, A., Cai, Y., and H. Ou, "Duplication Delay Attribute in the Session Description Protocol", RFC 7197, April 2014.
[RFC7197] Begen、A.、Cai、Y。、およびH. Ou、「Session Description Protocolの複製遅延属性」、RFC 7197、2014年4月。
[RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", RFC 7104, January 2014.
[RFC7104] Begen、A.、Cai、Y。、およびH. Ou、「Session Description Protocolの重複グループ化セマンティクス」、RFC 7104、2014年1月。
[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月。
[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[RFC2354]パーキンス、C。およびO.ホドソン、「ストリーミングメディアの修復オプション」、RFC 2354、1998年6月。
[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月。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、2011年10月。
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, November 2012.
[RFC6792] Wu、Q.、Hunt、G。、およびP. Arden、「RTPモニタリングフレームワークの使用に関するガイドライン」、RFC 6792、2012年11月。
[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, "Toward Lossless Video Transport", IEEE Internet Computing, Vol. 15, No. 6, pp. 48-57, November 2011.
[IC2011] Evans、J.、Begen、A.、Greengrass、J.、and C. Filsfils、 "Toward Lossless Video Transport"、IEEE Internet Computing、Vol。 15、No。6、pp。48-57、2011年11月。
Authors' Addresses
著者のアドレス
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Streetトロント、ON M5J 2T3カナダ
EMail: abegen@cisco.com
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ UK
コリンパーキンスグラスゴー大学コンピューティングサイエンススクールグラスゴーG12 8QQイギリス
EMail: csp@csperkins.org
URI: http://csperkins.org/