[要約] RFC 6828は、RTPセッションのためのコンテンツスプライシングに関する仕様です。その目的は、RTPパケットのスプライシングを可能にし、複数のメディアストリームを効率的に組み合わせることです。
Internet Engineering Task Force (IETF) J. Xia
Request for Comments: 6828 Huawei
Category: Informational January 2013
ISSN: 2070-1721
Content Splicing for RTP Sessions
RTPセッションのコンテンツスプライシング
Abstract
概要
Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.
コンテンツのスプライシングは、メインのマルチメディアストリームのコンテンツを他のマルチメディアコンテンツで置き換え、代替マルチメディアコンテンツを受信者に一定期間配信するプロセスです。スプライシングは、ケーブル事業者によるローカル広告の挿入に一般的に使用され、全国的な広告コンテンツがローカル広告に置き換えられます。
This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing.
このメモは、コンテンツスプライシングのいくつかの使用例と、RTPによって配信されるコンテンツをスプライシングするための一連の要件について説明しています。 RTPミキサーを使用してコンテンツのスプライシングを処理する方法の具体的なガイドラインを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6828.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6828で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 ....................................................2
2. System Model and Terminology ....................................3
3. Requirements for RTP Splicing ...................................6
4. Content Splicing for RTP Sessions ...............................7
4.1. RTP Processing in RTP Mixer ................................7
4.2. RTCP Processing in RTP Mixer ...............................8
4.3. Considerations for Handling Media Clipping at the
RTP Layer .................................................10
4.4. Congestion Control Considerations .........................11
4.5. Considerations for Implementing Undetectable Splicing .....13
5. Implementation Considerations ..................................13
6. Security Considerations ........................................14
7. Acknowledgments ................................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
Appendix A. Why Mixer Is Chosen ...................................17
This document outlines how content splicing can be used in RTP sessions. Splicing, in general, is a process where part of a multimedia content is replaced with other multimedia content and delivered to the receivers for a period of time. The substitutive content can be provided, for example, via another stream or via local media file storage. One representative use case for splicing is local advertisement insertion. This allows content providers to replace national advertising content with their own regional advertising content prior to delivering the regional advertising content to the receivers. Besides the advertisement insertion use case, there are other use cases in which the splicing technology can be applied, for example, splicing a recorded video into a video conferencing session or implementing a playlist server that stitches pieces of video together.
このドキュメントでは、RTPセッションでコンテンツスプライシングを使用する方法について説明します。一般的に、スプライシングは、マルチメディアコンテンツの一部が他のマルチメディアコンテンツに置き換えられ、一定期間レシーバに配信されるプロセスです。代替コンテンツは、たとえば、別のストリームを介して、またはローカルメディアファイルストレージを介して提供できます。スプライシングの代表的な使用例の1つは、ローカル広告の挿入です。これにより、コンテンツプロバイダーは、地域の広告コンテンツを受信者に配信する前に、国の広告コンテンツを独自の地域の広告コンテンツに置き換えることができます。広告挿入の使用例の他に、スプライシング技術を適用できる他の使用例があります。たとえば、録画したビデオをビデオ会議セッションにスプライスしたり、ビデオの断片をつなぎ合わせるプレイリストサーバーを実装したりします。
Content splicing is a well-defined operation in MPEG-based cable TV systems. Indeed, the Society for Cable Telecommunications Engineers (SCTE) has created two standards, [SCTE30] and [SCTE35], to standardize MPEG2-TS splicing procedures. SCTE 30 creates a standardized method for communication between advertisement server and splicer, and SCTE 35 supports splicing of MPEG2 transport streams.
コンテンツのスプライシングは、MPEGベースのケーブルテレビシステムで明確に定義された操作です。実際、Society for Cable Telecommunications Engineers（SCTE）は、MPEG2-TSスプライシング手順を標準化するために、[SCTE30]と[SCTE35]の2つの標準を作成しました。 SCTE 30は、広告サーバーとスプライサー間の通信の標準化された方法を作成し、SCTE 35は、MPEG2トランスポートストリームのスプライシングをサポートします。
When using multimedia splicing into the Internet, the media may be transported by RTP. In this case, the original media content and substitutive media content will use the same time period but may contain different numbers of RTP packets due to different media codecs and entropy coding. This mismatch may require some adjustments of the RTP header sequence number to maintain consistency. [RFC3550] provides the tools to enable seamless content splicing in RTP sessions, but to date there have been no clear guidelines on how to use these tools.
マルチメディアスプライシングを使用してインターネットに接続する場合、メディアはRTPによって転送されることがあります。この場合、元のメディアコンテンツと代替メディアコンテンツは同じ期間を使用しますが、メディアコーデックとエントロピーコーディングが異なるため、RTPパケットの数が異なる場合があります。この不一致では、一貫性を維持するために、RTPヘッダーシーケンス番号の調整が必要になる場合があります。 [RFC3550]は、RTPセッションでシームレスなコンテンツのスプライシングを可能にするツールを提供しますが、これまでこれらのツールの使用方法に関する明確なガイドラインはありませんでした。
This memo outlines the requirements for content splicing in RTP sessions and describes how an RTP mixer can be used to meet these requirements.
このメモは、RTPセッションでのコンテンツスプライシングの要件の概要を示し、RTPミキサーを使用してこれらの要件を満たす方法を説明します。
In this document, the splicer, an intermediary network element, handles RTP splicing. The splicer can receive main content and substitutive content simultaneously but will send one of them at one point of time.
このドキュメントでは、中間ネットワーク要素であるスプライサーがRTPスプライシングを処理します。スプライサーはメインコンテンツと代替コンテンツを同時に受信できますが、そのうちの1つを一度に送信します。
When RTP splicing begins, the splicer sends the substitutive content to the RTP receiver instead of the main content for a period of time. When RTP splicing ends, the splicer switches back to sending the main content to the RTP receiver.
RTPスプライシングが開始されると、スプライサーは一定期間、メインコンテンツではなく代替コンテンツをRTPレシーバーに送信します。 RTPスプライシングが終了すると、スプライサーはメインコンテンツをRTPレシーバーに送信するように切り替わります。
A simplified RTP splicing diagram is depicted in Figure 1, in which only one main content flow and one substitutive content flow are given. Actually, the splicer can handle multiple splicing for multiple RTP sessions simultaneously. RTP splicing may happen more than once in multiple time slots during the lifetime of the main RTP stream. The methods by which the splicer learns when to start and end the splicing are out of scope for this document.
簡略化されたRTPスプライシング図を図1に示します。この図では、1つのメインコンテンツフローと1つの代替コンテンツフローのみが示されています。実際には、スプライサーは複数のRTPセッションの複数のスプライシングを同時に処理できます。 RTPスプライシングは、メインRTPストリームの存続期間中に複数のタイムスロットで複数回発生する可能性があります。スプライサーがスプライシングを開始および終了するタイミングを学習する方法は、このドキュメントの範囲外です。
+---------------+
| | Main Content +-----------+
| Main RTP |------------->| | Output Content
| Content | | Splicer |--------------->
+---------------+ ---------->| |
| +-----------+
|
| Substitutive Content
|
|
+-----------------------+
| Substitutive RTP |
| Content |
| or |
| Local File Storage |
+-----------------------+
Figure 1: RTP Splicing Architecture
図1：RTPスプライシングアーキテクチャ
This document uses the following terminologies.
このドキュメントでは、次の用語を使用しています。
Output RTP Stream
出力RTPストリーム
The RTP stream that the RTP receiver is currently receiving. The content of the output of the RTP stream can be either main content or substitutive content.
RTPレシーバーが現在受信しているRTPストリーム。 RTPストリームの出力のコンテンツは、メインコンテンツまたは代替コンテンツのいずれかです。
Main Content
メインコンテンツ
The multimedia content that is conveyed in the main RTP stream. Main content will be replaced by the substitutive content during splicing.
メインRTPストリームで伝達されるマルチメディアコンテンツ。メインのコンテンツは、スプライシング中に代替コンテンツに置き換えられます。
Main RTP Stream
メインRTPストリーム
The RTP stream that the splicer is receiving. The content of the main RTP stream can be replaced by substitutive content for a period of time.
スプライサーが受信しているRTPストリーム。メインRTPストリームのコンテンツは、一定期間、代替コンテンツで置き換えることができます。
Main RTP Sender
メインRTP送信者
The sender of RTP packets carrying the main RTP stream.
メインRTPストリームを運ぶRTPパケットの送信者。
Substitutive Content
代替コンテンツ
The multimedia content that replaces the main content during splicing. The substitutive content can, for example, be contained in an RTP stream from a media sender or fetched from local media file storage.
スプライシング中にメインコンテンツを置き換えるマルチメディアコンテンツ。代替コンテンツは、たとえば、メディアセンダーからのRTPストリームに含めるか、ローカルメディアファイルストレージからフェッチできます。
Substitutive RTP Stream
代替RTPストリーム
An RTP stream with new content that will replace the content in the main RTP stream. The substitutive RTP stream and main RTP stream are two separate streams. If the substitutive content is provided via a substitutive RTP stream, the substitutive RTP stream must pass through the splicer before the substitutive content is delivered to the receiver.
メインRTPストリームのコンテンツを置き換える新しいコンテンツのRTPストリーム。代替RTPストリームとメインRTPストリームは、2つの別々のストリームです。代替コンテンツが代替RTPストリームを介して提供される場合、代替コンテンツがレシーバーに配信される前に、代替RTPストリームがスプライサーを通過する必要があります。
Substitutive RTP Sender
代替RTP送信者
The sender of RTP packets carrying the substitutive RTP stream.
代替RTPストリームを運ぶRTPパケットの送信者。
Splicing-In Point
スプライスインポイント
A virtual point in the RTP stream, suitable for substitutive content entry, typically in the boundary between two independently decodable frames.
RTPストリーム内の仮想ポイント。代替コンテンツエントリに適しています。通常、2つの独立してデコード可能なフレーム間の境界にあります。
Splicing-Out Point
スプライシングアウトポイント
A virtual point in the RTP stream, suitable for substitutive content exit, typically in the boundary between two independently decodable frames.
RTPストリーム内の仮想ポイントで、代替コンテンツの出口に適しています。通常、2つの独立してデコード可能なフレーム間の境界にあります。
Splicer
スプライサー
An intermediary node that inserts substitutive content into a main RTP stream. The splicer sends substitutive content to the RTP receiver instead of main content during splicing. It is also responsible for processing RTP Control Protocol (RTCP) traffic between the RTP sender and the RTP receiver.
代替コンテンツをメインRTPストリームに挿入する中間ノード。スプライサーは、スプライシング中にメインコンテンツの代わりに代替コンテンツをRTPレシーバーに送信します。また、RTP送信側とRTP受信側の間のRTP制御プロトコル（RTCP）トラフィックを処理します。
In order to allow seamless content splicing at the RTP layer, the following requirements must be met. Meeting these will also allow, but not require, seamless content splicing at layers above RTP.
RTPレイヤーでシームレスなコンテンツのスプライシングを可能にするには、次の要件を満たす必要があります。これらを満たすことで、RTP上のレイヤーでのシームレスなコンテンツのスプライシングも可能になりますが、必須ではありません。
REQ-1:
REQ-1：
The splicer should be agnostic about the network and transport-layer protocols used to deliver the RTP streams.
スプライサーは、RTPストリームの配信に使用されるネットワークおよびトランスポート層プロトコルにとらわれない必要があります。
REQ-2:
REQ-2：
The splicing operation at the RTP layer must allow splicing at any point required by the media content and must not constrain when splicing-in or splicing-out operations can take place.
RTPレイヤーでのスプライシング操作は、メディアコンテンツに必要な任意のポイントでスプライシングを許可する必要があり、スプライシングイン操作またはスプライシングアウト操作を実行できる場合に制約してはなりません。
REQ-3:
REQ-3：
Splicing of RTP content must be backward compatible with the RTP/RTCP protocol, associated profiles, payload formats, and extensions.
RTPコンテンツのスプライシングは、RTP / RTCPプロトコル、関連するプロファイル、ペイロード形式、および拡張機能と下位互換性がある必要があります。
REQ-4:
REQ-4：
The splicer will modify the content of RTP packets and thus break the end-to-end security, at a minimum, breaking the data integrity and source authentication. If the splicer is designated to insert substitutive content, it must be trusted, i.e., be in the security context(s) with the main RTP sender, the substitutive RTP sender, and the receivers. If encryption is employed, the splicer commonly must decrypt the inbound RTP packets and re-encrypt the outbound RTP packets after splicing.
スプライサーはRTPパケットの内容を変更し、少なくともエンドツーエンドのセキュリティを破壊し、データの整合性とソース認証を破壊します。スプライサーが代替コンテンツを挿入するように指定されている場合、スプライサーは信頼されている必要があります。つまり、メインRTP送信者、代替RTP送信者、および受信者とセキュリティコンテキスト内にある必要があります。暗号化が採用されている場合、スプライサーは通常、インバウンドRTPパケットを復号化し、スプライシング後にアウトバウンドRTPパケットを再暗号化する必要があります。
REQ-5:
REQ-5：
The splicer should rewrite as necessary and forward RTCP messages (e.g., including packet loss, jitter, etc.) sent from a downstream receiver to the main RTP sender or the substitutive RTP sender, and thus allow the main RTP sender or substitutive RTP sender to learn the performance of the downstream receiver when its content is being passed to an RTP receiver. In addition, the splicer should rewrite RTCP messages from the main RTP sender or substitutive RTP sender to the receiver.
スプライサーは必要に応じて書き換え、ダウンストリームレシーバーから送信されたRTCPメッセージ（パケット損失、ジッターなどを含む）をメインRTP送信者または代替RTP送信者に転送し、メインRTP送信者または代替RTP送信者がコンテンツがRTPレシーバーに渡されているときのダウンストリームレシーバーのパフォーマンスを学習します。さらに、スプライサーは、メインのRTP送信者または代替のRTP送信者から受信者へのRTCPメッセージを書き換える必要があります。
REQ-6:
REQ-6：
The splicer must not affect other RTP sessions running between the RTP sender and the RTP receiver and must be transparent for the RTP sessions it does not splice.
スプライサーは、RTP送信者とRTP受信者の間で実行されている他のRTPセッションに影響を与えてはならず、接続しないRTPセッションに対して透過的でなければなりません。
REQ-7:
REQ-7：
The RTP receiver should not be able to detect any splicing points in the RTP stream produced by the splicer on the RTP protocol level. For the advertisement insertion use case, it is important to make it difficult for the RTP receiver to detect where an advertisement insertion is starting or ending from the RTP packets, and thus avoiding the RTP receiver from filtering out the advertisement content. This memo only focuses on making the splicing undetectable at the RTP layer. The corresponding processing is depicted in Section 4.5.
RTPレシーバーは、RTPプロトコルレベルでスプライサーによって生成されたRTPストリーム内のスプライシングポイントを検出できません。広告挿入の使用例の場合、RTPレシーバーが広告挿入がRTPパケットからどこで開始または終了するかを検出しにくくし、RTP受信機が広告コンテンツをフィルターで除外しないようにすることが重要です。このメモは、RTP層でスプライシングを検出不可能にすることにのみ焦点を当てています。対応する処理は、セクション4.5に示されています。
The RTP specification [RFC3550] defines two types of middleboxes: RTP translators and RTP mixers. Splicing is best viewed as a mixing operation. The splicer generates a new RTP stream that is a mix of the main RTP stream and the substitutive RTP stream. An RTP mixer is therefore an appropriate model for a content splicer. In the next four subsections (from Section 4.1 to Section 4.4), the document analyzes how the mixer handles RTP splicing and how it satisfies the general requirements listed in Section 3. In Section 4.5, the document looks at REQ-7 in order to hide the fact that splicing takes place.
RTP仕様[RFC3550]では、RTPトランスレータとRTPミキサーの2種類のミドルボックスが定義されています。スプライシングは、ミキシング操作として最適です。スプライサーは、メインRTPストリームと代替RTPストリームの混合である新しいRTPストリームを生成します。したがって、RTPミキサーはコンテンツスプライサーに適したモデルです。次の4つのサブセクション（セクション4.1からセクション4.4まで）では、ミキサーがRTPスプライシングを処理する方法と、セクション3にリストされている一般的な要件をどのように満たすかを分析します。セクション4.5では、非表示にするためにREQ-7を調べますスプライシングが行われるという事実。
A splicer could be implemented as a mixer that receives the main RTP stream and the substitutive content (possibly via a substitutive RTP stream), and sends a single output RTP stream to the receiver(s). That output RTP stream will contain either the main content or the substitutive content. The output RTP stream will come from the mixer and will have the synchronization source (SSRC) of the mixer rather than the main RTP sender or the substitutive RTP sender.
スプライサーは、メインRTPストリームと代替コンテンツ（おそらく代替RTPストリームを介して）を受信し、単一の出力RTPストリームをレシーバーに送信するミキサーとして実装できます。その出力RTPストリームには、メインコンテンツまたは代替コンテンツのいずれかが含まれます。出力RTPストリームはミキサーから送信され、メインRTP送信者や代替RTP送信者ではなく、ミキサーの同期ソース（SSRC）を持ちます。
The mixer uses its own SSRC, sequence number space, and timing model when generating the output stream. Moreover, the mixer may insert the SSRC of the main RTP stream into the contributing source (CSRC) list in the output media stream.
ミキサは、出力ストリームを生成するときに、独自のSSRC、シーケンス番号スペース、およびタイミングモデルを使用します。さらに、ミキサーはメインRTPストリームのSSRCを出力メディアストリームのコントリビューティングソース（CSRC）リストに挿入する場合があります。
At the splicing-in point, when the substitutive content becomes active, the mixer chooses the substitutive RTP stream as the input stream and extracts the payload data (i.e., substitutive content). If the substitutive content comes from local media file storage, the mixer directly fetches the substitutive content. After that, the mixer encapsulates substitutive content instead of main content as the payload of the output media stream and then sends the output RTP media stream to the receiver. The mixer may insert the SSRC of the substitutive RTP stream into the CSRC list in the output media stream. If the substitutive content comes from local media file storage, the mixer should leave the CSRC list blank.
スプライシングインポイントで、代替コンテンツがアクティブになると、ミキサーは代替RTPストリームを入力ストリームとして選択し、ペイロードデータ（つまり、代替コンテンツ）を抽出します。代替コンテンツがローカルメディアファイルストレージからのものである場合、ミキサーは代替コンテンツを直接フェッチします。その後、ミキサーはメインコンテンツの代わりに代替コンテンツを出力メディアストリームのペイロードとしてカプセル化し、出力RTPメディアストリームをレシーバーに送信します。ミキサは、代替RTPストリームのSSRCを出力メディアストリームのCSRCリストに挿入できます。代替コンテンツがローカルメディアファイルストレージからのものである場合、ミキサーはCSRCリストを空白のままにする必要があります。
At the splicing-out point, when the substitutive content ends, the mixer retrieves the main RTP stream as the input stream and extracts the payload data (i.e., main content). After that, the mixer encapsulates main content instead of substitutive content as the payload of the output media stream and then sends the output media stream to the receivers. Moreover, the mixer may insert the SSRC of the main RTP stream into the CSRC list in the output media stream as before.
スプライシングアウトポイントで、代替コンテンツが終了すると、ミキサーはメインRTPストリームを入力ストリームとして取得し、ペイロードデータ（メインコンテンツ）を抽出します。その後、ミキサーは、代替コンテンツの代わりにメインコンテンツを出力メディアストリームのペイロードとしてカプセル化し、出力メディアストリームをレシーバーに送信します。さらに、ミキサーは、以前と同様に、メインRTPストリームのSSRCを出力メディアストリームのCSRCリストに挿入できます。
Note that if the content is too large to fit into RTP packets sent to the RTP receiver, the mixer needs to transcode or perform application-layer fragmentation. Usually the mixer is deployed as part of a managed system and MTU will be carefully managed by this system. This document does not raise any new MTU related issues compared to a standard mixer described in [RFC3550].
コンテンツが大きすぎてRTPレシーバーに送信されるRTPパケットに収まらない場合、ミキサーはアプリケーション層の断片化をトランスコードまたは実行する必要があることに注意してください。通常、ミキサーは管理対象システムの一部として展開され、MTUはこのシステムによって慎重に管理されます。このドキュメントでは、[RFC3550]で説明されている標準ミキサーと比較して、新しいMTU関連の問題は発生しません。
Splicing may occur more than once during the lifetime of the main RTP stream. This means the mixer needs to send main content and substitutive content in turn with its own SSRC identifier. From receiver point of view, the only source of the output stream is the mixer regardless of where the content is coming from.
スプライシングは、メインRTPストリームの存続期間中に複数回発生する可能性があります。これは、ミキサーがメインコンテンツと代替コンテンツを独自のSSRC識別子と共に送信する必要があることを意味します。レシーバーの観点から見ると、コンテンツがどこから来ているかに関係なく、出力ストリームの唯一のソースはミキサーです。
By monitoring available bandwidth and buffer levels and by computing network metrics such as packet loss, network jitter, and delay, an RTP receiver can learn the network performance and communicate this to the RTP sender via RTCP reception reports.
利用可能な帯域幅とバッファレベルを監視し、パケット損失、ネットワークジッタ、遅延などのネットワークメトリックを計算することにより、RTP受信者はネットワークパフォーマンスを学習し、これをRTCP受信レポートを介してRTP送信者に伝達できます。
According to the description in Section 7.3 of [RFC3550], the mixer splits the RTCP flow between the sender and receiver into two separate RTCP loops; the RTP sender has no idea about the situation on the receiver. But splicing is a process where the mixer selects one media stream from multiple streams rather than mixing them, so the mixer can leave the SSRC identifier in the RTCP report intact (i.e., the SSRC of the downstream receiver). This enables the main RTP sender or the substitutive RTP sender to learn the situation on the receiver.
[RFC3550]のセクション7.3の説明によると、ミキサーは送信者と受信者の間のRTCPフローを2つの別々のRTCPループに分割します。 RTP送信側は、受信側の状況を知りません。ただし、スプライシングは、ミキサーが複数のストリームから1つのメディアストリームを選択するプロセスであり、それらを混合するのではなく、ミキサーがRTCPレポートのSSRC識別子をそのまま残すことができます（つまり、ダウンストリームレシーバーのSSRC）。これにより、メインRTP送信者または代替RTP送信者が受信者の状況を知ることができます。
If the RTCP report corresponds to a time interval that is entirely main content or entirely substitutive content, the number of output RTP packets containing substitutive content is equal to the number of input substitutive RTP packets (from the substitutive RTP stream) during splicing. In the same manner, the number of output RTP packets containing main content is equal to the number of input main RTP packets (from the main RTP stream) during non-splicing unless the mixer fragments the input RTP packets. This means that the mixer does not need to modify the loss packet fields in reception report blocks in RTCP reports. But, if the mixer fragments the input RTP packets, it may need to modify the loss packet fields to compensate for the fragmentation. Whether the input RTP packets are fragmented or not, the mixer still needs to change the SSRC field in the report block to the SSRC identifier of the main RTP sender or the substitutive RTP sender and rewrite the extended highest sequence number field to the corresponding original extended highest sequence number before forwarding the RTCP report to the main RTP sender or the substitutive RTP sender.
RTCPレポートが完全にメインコンテンツまたは完全に代替コンテンツである時間間隔に対応している場合、代替コンテンツを含む出力RTPパケットの数は、スプライシング中の（代替RTPストリームからの）入力代替RTPパケットの数と等しくなります。同様に、ミキサーが入力RTPパケットをフラグメント化しない限り、メインコンテンツを含む出力RTPパケットの数は、非スプライシング中の（メインRTPストリームからの）入力メインRTPパケットの数と同じです。これは、ミキサーがRTCPレポートの受信レポートブロックの損失パケットフィールドを変更する必要がないことを意味します。ただし、ミキサーが入力RTPパケットをフラグメント化する場合は、損失パケットフィールドを変更して、フラグメント化を補正する必要がある場合があります。入力RTPパケットがフラグメント化されているかどうかに関係なく、ミキサーはレポートブロックのSSRCフィールドをメインRTP送信者または代替RTP送信者のSSRC識別子に変更し、拡張された最大シーケンス番号フィールドを対応する元の拡張された値に書き換える必要がありますRTCPレポートをメインRTP送信者または代替RTP送信者に転送する前の最大シーケンス番号。
If the RTCP report spans the splicing-in point or the splicing-out point, it reflects the characteristics of the combination of main RTP packets and substitutive RTP packets. In this case, the mixer needs to divide the RTCP report into two separate RTCP reports and send them to their original RTP senders, respectively. For each RTCP report, the mixer also needs to make the corresponding changes to the packet loss fields in the report block besides the SSRC field and the extended highest sequence number field.
RTCPレポートがスプライシングインポイントまたはスプライシングアウトポイントにまたがる場合、メインRTPパケットと代替RTPパケットの組み合わせの特性を反映しています。この場合、ミキサーはRTCPレポートを2つの個別のRTCPレポートに分割し、それぞれを元のRTP送信者に送信する必要があります。各RTCPレポートについて、ミキサーは、SSRCフィールドと拡張された最大シーケンス番号フィールドのほかに、レポートブロックのパケット損失フィールドにも対応する変更を加える必要があります。
If the mixer receives an RTCP extended report (XR) block, it should rewrite the XR report block in a similar way to the reception report block in the RTCP report.
ミキサーがRTCP拡張レポート（XR）ブロックを受信した場合、RTCPレポートの受信レポートブロックと同様の方法でXRレポートブロックを書き換える必要があります。
Besides forwarding the RTCP reports sent from the RTP receiver, the mixer can also generate its own RTCP reports to inform the main RTP sender, or the substitutive RTP sender, of the reception quality of content not sent to the RTP receiver when it reaches the mixer. These RTCP reports use the SSRC of the mixer. If the substitutive content comes from local media file storage, the mixer does not need to generate RTCP reports for the substitutive stream.
RTPレシーバーから送信されたRTCPレポートを転送するほかに、ミキサーは独自のRTCPレポートを生成して、ミキサーに到達したときにRTPレシーバーに送信されなかったコンテンツの受信品質をメインRTPセンダーまたは代替RTPセンダーに通知することもできます。 。これらのRTCPレポートは、ミキサーのSSRCを使用します。代替コンテンツがローカルメディアファイルストレージからのものである場合、ミキサーは代替ストリームのRTCPレポートを生成する必要はありません。
Based on the above RTCP operating mechanism, the RTP sender whose content is being passed to a receiver will see the reception quality of its stream as received by the mixer and the reception quality of the spliced stream as received by the receiver. The RTP sender whose content is not being passed to a receiver will only see the reception quality of its stream as received by the mixer.
上記のRTCP動作メカニズムに基づいて、コンテンツがレシーバーに渡されるRTPセンダーは、ミキサーが受信したストリームの受信品質と、レシーバーが受信したスプライスされたストリームの受信品質を確認します。コンテンツがレシーバーに渡されていないRTPセンダーには、ミキサーが受信したストリームの受信品質しか表示されません。
The mixer must forward RTCP source description (SDES) and BYE packets from the receiver to the sender and may forward them in inverse direction as defined in Section 7.3 of [RFC3550].
ミキサーは、RTCPソース記述（SDES）とBYEパケットをレシーバーからセンダーに転送する必要があり、[RFC3550]のセクション7.3で定義されているように、それらを逆方向に転送できます。
Once the mixer receives an RTP/Audio-Visual Profile with Feedback (AVPF) [RFC4585] transport-layer feedback packet, it must handle it carefully, as the feedback packet may contain the information of the content that comes from different RTP senders. In this case, the mixer needs to divide the feedback packet into two separate feedback packets and process the information in the feedback control information (FCI) in the two feedback packets, just as in the RTCP report process described above.
フィードバックパケットにさまざまなRTP送信者からのコンテンツの情報が含まれている可能性があるため、ミキサーはRTP / Audio-Visual Profile with Feedback（AVPF）[RFC4585]トランスポート層フィードバックパケットを受信すると、慎重に処理する必要があります。この場合、ミキサーはフィードバックパケットを2つの個別のフィードバックパケットに分割し、2つのフィードバックパケット内のフィードバック制御情報（FCI）の情報を、上記のRTCPレポートプロセスと同様に処理する必要があります。
If the substitutive content comes from local media file storage (i.e., the mixer can be regarded as the substitutive RTP sender), any RTCP packets received from downstream related to the substitutive content must be terminated on the mixer without any further processing.
代替コンテンツがローカルメディアファイルストレージからのものである場合（つまり、ミキサーが代替RTP送信者と見なされる場合）、代替コンテンツに関連してダウンストリームから受信したRTCPパケットは、それ以上の処理なしでミキサーで終了する必要があります。
This section provides informative guidelines on how to handle media substitution at the RTP layer to minimize media impact. Dealing well with the media substitution at the RTP layer is necessary for quality implementations. To perfectly erase any media impact needs more considerations at the higher layers. How the media substitution is erased at the higher layers is outside of the scope of this memo.
このセクションでは、RTP層でのメディア置換を処理してメディアへの影響を最小限に抑える方法についての有益なガイドラインを提供します。 RTP層でのメディア置換にうまく対処することは、高品質の実装に必要です。メディアの影響を完全に消去するには、上位層でさらに検討する必要があります。上位層でメディア置換がどのように消去されるかは、このメモの範囲外です。
If the time duration for any substitutive content mismatches, i.e., shorter or longer than the duration of the main content to be replaced, then media degradations may occur at the splicing point and thus impact the user's experience.
代替コンテンツの不一致の持続時間が、つまり、メインコンテンツが置換される期間よりも短いか長い場合、接続ポイントでメディアの劣化が発生し、ユーザーのエクスペリエンスに影響を与える可能性があります。
If the substitutive content has shorter duration from the main content, then there could be a gap in the output RTP stream. The RTP sequence number will be contiguous across this gap, but there will be an unexpected jump in the RTP timestamp. Such a gap would cause the receiver to have nothing to play. This may be unavoidable, unless the mixer can adjusts the splice in or splice out point to compensate. This assumes the splicing mixer can send more of the main RTP stream in place of the shorter substitutive stream or vary the length of the substitutive content. It is the responsibility of the higher-layer protocols and the media providers to ensure that the substitutive content is of very similar duration as the main content to be replaced.
代替コンテンツの期間がメインコンテンツより短い場合、出力RTPストリームにギャップがある可能性があります。 RTPシーケンス番号はこのギャップ全体で連続していますが、RTPタイムスタンプに予期しないジャンプが発生します。このようなギャップがあると、レシーバーは何も再生できなくなります。これは、ミキサーがスプライスインポイントまたはスプライスアウトポイントを調整して補正できる場合を除いて、避けられない場合があります。これは、スプライシングミキサーが、より短い置換ストリームの代わりに、より多くのメインRTPストリームを送信したり、置換コンテンツの長さを変更したりできることを前提としています。代替コンテンツが、置き換えられるメインコンテンツと非常に類似した長さであることを保証するのは、上位層のプロトコルとメディアプロバイダーの責任です。
If the substitute content has longer duration than the reserved gap duration, there will be an overlap between the substitutive RTP stream and the main RTP stream at the splicing-out point. A straightforward approach is that the mixer performs an ungraceful action and terminates the splicing and switches back to the main RTP stream even if this may cause media stuttering on the receiver. Alternatively, the mixer may transcode the substitutive content to play at a faster rate than normal, to adjust it to the length of the gap in the main content and generate a new RTP stream for the transcoded content. This is a complex operation and very specific to the content and media codec used. Additional approaches exist; these types of issues should be taken into account in both mixer implementors and media generators to enable smooth substitutions.
代替コンテンツの期間が予約済みのギャップ期間よりも長い場合、スプライシングアウトポイントで代替RTPストリームとメインRTPストリームの間にオーバーラップが生じます。簡単なアプローチは、ミキサーが不自然なアクションを実行し、スプライシングを終了し、これによりレシーバーでメディアが途切れる可能性がある場合でも、メインのRTPストリームに戻ることです。または、ミキサーは代替コンテンツをトランスコードして通常よりも速いレートで再生し、メインコンテンツのギャップの長さに合わせて調整し、トランスコードされたコンテンツ用の新しいRTPストリームを生成します。これは複雑な操作であり、使用するコンテンツとメディアコーデックに非常に固有です。追加のアプローチが存在します。この種の問題は、スムーズな置換を可能にするために、ミキサーインプリメンターとメディアジェネレーターの両方で考慮する必要があります。
If the substitutive content has somewhat different characteristics from the main content it replaces, or if the substitutive content is encoded with a different codec or has different encoding bitrate, it might overload the network and might cause network congestion on the path between the mixer and the RTP receiver(s) that would not have been caused by the main content.
代替コンテンツが、それが置き換えるメインコンテンツとは多少異なる特性を持っている場合、または代替コンテンツが異なるコーデックでエンコードされているか、異なるエンコードビットレートを持っている場合、ネットワークに過負荷をかけ、ミキサーとの間のパスでネットワークの輻輳を引き起こす可能性がありますメインコンテンツが原因ではなかったはずのRTPレシーバー。
To be robust to network congestion and packet loss, a mixer that is performing splicing must continuously monitor the status of a downstream network by monitoring any of the following RTCP reports that are used:
ネットワークの輻輳およびパケット損失に対して堅牢であるためには、スプライシングを実行しているミキサーは、使用される次のRTCPレポートのいずれかを監視することにより、ダウンストリームネットワークのステータスを継続的に監視する必要があります。
1. RTCP receiver reports indicate packet loss [RFC3550].
1. RTCPレシーバーレポートはパケット損失を示します[RFC3550]。
2. RTCP NACKs for lost packet recovery [RFC4585].
2. 失われたパケットを回復するためのRTCP NACK [RFC4585]。
3. RTCP Explicit Congestion Notification (ECN) Feedback information [RFC6679].
3. RTCP明示的輻輳通知（ECN）フィードバック情報[RFC6679]。
Once the mixer detects congestion on its downstream link, it will treat these reports as follows:
ミキサーがダウンストリームリンクの輻輳を検出すると、これらのレポートは次のように処理されます。
1. If the mixer receives the RTCP receiver reports with packet loss indication, it will forward the reports to the substitutive RTP sender or the main RTP sender as described in Section 4.2.
1. セクション4.2で説明されているように、ミキサーがパケット損失を示すRTCPレシーバーレポートを受信すると、代替RTPセンダーまたはメインRTPセンダーにレポートが転送されます。
2. If mixer receives the RTCP NACK packets defined in [RFC4585] from the RTP receiver for packet loss recovery, it first identifies the content category of lost packets to which the NACK corresponds. Then, the mixer will generate new RTCP NACKs for the lost packets with its own SSRC and make corresponding changes to their sequence numbers to match original, pre-spliced, packets. If the lost substitutive content comes from local media file storage, the mixer acting as the substitutive RTP sender will directly fetch the lost substitutive content and retransmit it to the RTP receiver. The mixer may buffer the sent RTP packets and do the retransmission.
2. ミキサーが[RFC4585]で定義されたRTCP NACKパケットをRTPレシーバーからパケット損失回復のために受信すると、最初にNACKが対応する失われたパケットのコンテンツカテゴリを識別します。次に、ミキサーは、独自のSSRCを使用して失われたパケットに対して新しいRTCP NACKを生成し、シーケンス番号に対応する変更を加えて、元の事前接続されたパケットと一致させます。失われた代替コンテンツがローカルメディアファイルストレージからのものである場合、代替RTP送信側として機能するミキサーは、失われた代替コンテンツを直接フェッチし、RTP受信側に再送信します。ミキサは送信されたRTPパケットをバッファリングして、再送信を実行します。
It is somewhat complex that the lost packets requested in a single RTCP NACK message not only contain the main content but also the substitutive content. To address this, the mixer must divide the RTCP NACK packet into two separate RTCP NACK packets: one requests for the lost main content, and another requests for the lost substitutive content.
単一のRTCP NACKメッセージで要求された失われたパケットに、メインコンテンツだけでなく代替コンテンツも含まれていることはやや複雑です。これに対処するために、ミキサーはRTCP NACKパケットを2つの別々のRTCP NACKパケットに分割する必要があります。1つは失われたメインコンテンツを要求し、もう1つは失われた代替コンテンツを要求します。
3. If an ECN-aware mixer receives RTCP ECN feedback (RTCP ECN feedback packets or RTCP XR summary reports) defined in [RFC6679] from the RTP receiver, it must process them in a similar way to the RTP/AVPF feedback packet or RTCP XR process described in Section 4.2 of this memo.
3. ECN認識ミキサーは、[RFC6679]で定義されたRTCP ECNフィードバック（RTCP ECNフィードバックパケットまたはRTCP XRサマリーレポート）をRTPレシーバーから受信する場合、RTP / AVPFフィードバックパケットまたはRTCP XRプロセスと同様の方法で処理する必要があります。このメモのセクション4.2で説明されています。
These three methods require the mixer to run a congestion control loop and bitrate adaptation between itself and the RTP receiver. The mixer can thin or transcode the main RTP stream or the substitutive RTP stream, but such operations are very inefficient and difficult, and they also bring undesirable delay. Fortunately, as noted in this memo, the mixer acting as a splicer can rewrite the RTCP packets sent from the RTP receiver and forward them to the RTP sender, thus letting the RTP sender knows that congestion is being experienced on the path between the mixer and the RTP receiver. Then, the RTP sender applies its congestion control algorithm and reduces the media bitrate to a value that is in compliance with congestion control principles for the slowest link. The congestion control algorithm may be a TCP-friendly bitrate adaptation algorithm specified in [RFC5348] or a Datagram Congestion Control Protocol (DCCP) congestion control algorithm defined in [RFC5762].
これらの3つの方法では、ミキサーで輻輳制御ループを実行し、それ自体とRTP受信機の間でビットレートを調整する必要があります。ミキサーはメインRTPストリームまたは代替RTPストリームをシン化またはトランスコードできますが、そのような操作は非常に非効率的で困難であり、望ましくない遅延も引き起こします。幸いにも、このメモに記載されているように、スプライサーとして機能するミキサーは、RTPレシーバーから送信されたRTCPパケットを書き換えてRTP送信者に転送できるため、RTP送信者はミキサーとミキサーの間のパスで輻輳が発生していることを認識できます。 RTPレシーバー。次に、RTP送信側はその輻輳制御アルゴリズムを適用し、メディアビットレートを、最も遅いリンクの輻輳制御の原則に準拠した値に減らします。輻輳制御アルゴリズムは、[RFC5348]で指定されたTCPフレンドリーなビットレート適応アルゴリズム、または[RFC5762]で定義されたデータグラム輻輳制御プロトコル（DCCP）輻輳制御アルゴリズムです。
If the substitutive content comes from local media file storage, the mixer must directly reduce the bitrate as if it were the substitutive RTP sender.
代替コンテンツがローカルメディアファイルストレージからのものである場合、ミキサーは、代替RTP送信者であるかのように、ビットレートを直接削減する必要があります。
From the above analysis, to reduce the risk of congestion and maintain the bandwidth consumption stable over time, the substitutive RTP stream is recommended to be encoded at an appropriate bitrate to match that of the main RTP stream. If the substitutive RTP stream comes from the substitutive RTP sender, this sender should have some knowledge about the media encoding bitrate of the main content in advance. Acquiring such knowledge is out of scope in this document.
上記の分析から、輻輳のリスクを軽減し、帯域幅の消費を長期にわたって安定させるには、代替RTPストリームをメインRTPストリームのビットレートと一致する適切なビットレートでエンコードすることをお勧めします。代替RTPストリームが代替RTP送信者からのものである場合、この送信者は、メインコンテンツのメディアエンコーディングビットレートについて事前に知っている必要があります。そのような知識を取得することは、このドキュメントでは範囲外です。
If it is desirable to prevent receivers from detecting that splicing is occurring at the RTP layer, the mixer must not include a CSRC list in outgoing RTP packets and must not forward RTCP messages from the main RTP sender or from the substitutive RTP sender. Due to the absence of a CSRC list in the output RTP stream, the RTP receiver only initiates SDES, BYE, and Application-specific functions (APP) packets to the mixer without any knowledge of the main RTP sender and the substitutive RTP sender.
RTPレイヤーでスプライシングが発生していることをレシーバーが検出しないようにすることが望ましい場合、ミキサーは発信RTPパケットにCSRCリストを含めてはならず、メインRTP送信者または代替RTP送信者からのRTCPメッセージを転送してはなりません。出力RTPストリームにCSRCリストが存在しないため、RTPレシーバーは、メインRTP送信者と代替RTP送信者を認識せずに、SDES、BYE、およびアプリケーション固有機能（APP）パケットのみをミキサーに開始します。
The CSRC list identifies the contributing sources; these SSRC identifiers of contributing sources are kept globally unique for each RTP session. The uniqueness of the SSRC identifier is used to resolve collisions and to detect RTP-level forwarding loops as defined in Section 8.2 of [RFC3550]. A danger that loops involving those contributing sources will not be detected will be created by the absence of a CSRC list in this case. The loops could occur if either the mixer is misconfigured to form a loop or a second mixer/translator is added, causing packets to loop back to upstream of the original mixer. An undetected RTP packet loop is a serious denial-of-service threat, which can consume all available bandwidth or mixer processing resources until the looped packets are dropped as a result of congestion. So, non-RTP means must be used to detect and resolve loops if the mixer does not add a CSRC list.
CSRCリストは、貢献しているソースを識別します。これらの貢献ソースのSSRC IDは、RTPセッションごとにグローバルに一意に保たれます。 [RFC3550]のセクション8.2で定義されているように、SSRC識別子の一意性は、衝突を解決し、RTPレベルの転送ループを検出するために使用されます。この場合、CSRCリストが存在しないため、これらの原因となるソースに関連するループが検出されない危険が生じます。ミキサーがループを形成するように誤って構成されているか、2番目のミキサー/トランスレーターが追加されていると、ループが発生し、パケットが元のミキサーの上流にループバックします。検出されないRTPパケットループは深刻なサービス拒否の脅威であり、輻輳の結果としてループパケットがドロップされるまで、利用可能なすべての帯域幅またはミキサー処理リソースを消費する可能性があります。したがって、ミキサーがCSRCリストを追加しない場合は、RTP以外の手段を使用してループを検出および解決する必要があります。
When the mixer is used to handle RTP splicing, the RTP receiver does not need any RTP/RTCP extension for splicing. As a trade-off, additional overhead could be induced on the mixer, which uses its own sequence number space and timing model. So the mixer will rewrite the RTP sequence number and timestamp, whatever splicing is active or not, and generate RTCP flows for both sides. In case the mixer serves multiple main RTP streams simultaneously, this may lead to more overhead on the mixer.
ミキサーを使用してRTPスプライシングを処理する場合、RTPレシーバーはスプライシングにRTP / RTCP拡張を必要としません。トレードオフとして、独自のシーケンス番号スペースとタイミングモデルを使用するミキサーで追加のオーバーヘッドが発生する可能性があります。したがって、スプライシングがアクティブかどうかに関係なく、ミキサーはRTPシーケンス番号とタイムスタンプを書き換え、両側にRTCPフローを生成します。ミキサーが複数のメインRTPストリームを同時に処理する場合、これによりミキサーのオーバーヘッドが増える可能性があります。
If an undetectable splicing requirement is required, the CSRC list is not included in the outgoing RTP packet; this brings a potential issue with loop detection as briefly described in Section 4.5.
検出できないスプライシング要件が必要な場合、CSRCリストは発信RTPパケットに含まれません。これにより、セクション4.5で簡単に説明したように、ループ検出で潜在的な問題が発生します。
The splicing application is subject to the general security considerations of the RTP specification [RFC3550].
スプライシングアプリケーションは、RTP仕様[RFC3550]の一般的なセキュリティの考慮事項に従います。
The mixer acting as splicer replaces some content with other content in RTP packets, thus breaking any RTP-level end-to-end security, such as integrity protection and source authentication. Thus, any RTP-level or outside security mechanism, such as IPsec [RFC4301] or Datagram Transport Layer Security [RFC6347], will use a security association between the splicer and the receiver. When using the Secure Real-Time Transport Protocol (SRTP) [RFC3711], the splicer could be provisioned with the same security association as the main RTP sender. Using a limitation in the SRTP security services regarding source authentication, the splicer can modify and re-protect the RTP packets without enabling the receiver to detect if the data comes from the original source or from the splicer.
スプライサーとして機能するミキサーは、RTPパケット内の一部のコンテンツを他のコンテンツに置き換えます。これにより、整合性保護やソース認証など、RTPレベルのエンドツーエンドのセキュリティが破られます。したがって、IPsec [RFC4301]やデータグラムトランスポート層セキュリティ[RFC6347]などのRTPレベルまたは外部のセキュリティメカニズムは、スプライサーとレシーバーの間のセキュリティアソシエーションを使用します。セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]を使用する場合、スプライサーにメインRTP送信者と同じセキュリティアソシエーションをプロビジョニングできます。ソース認証に関するSRTPセキュリティサービスの制限を使用すると、スプライサーは、データが元のソースからのものか、スプライサーからのものかを受信者が検出できないように、RTPパケットを変更して再保護できます。
Security goals to have source authentication all the way from the RTP main sender to the receiver through the splicer is not possible with splicing and any existing solutions. A new solution can theoretically be developed that enables identifying the participating entities and what each provides, i.e., the different media sources, main and substituting, and the splicer providing the RTP-level integration of the media payloads in a common timeline and synchronization context. Such a solution would obviously not meet REQ-7 and will be detectable on the RTP level.
RTPメインセンダーからスプライサーを介してレシーバーまでソース認証を行うというセキュリティ目標は、スプライシングや既存のソリューションでは不可能です。理論的には、関与するエンティティと、それぞれが提供するもの、つまりメインと代替の異なるメディアソース、および共通のタイムラインと同期コンテキストでメディアペイロードのRTPレベルの統合を提供するスプライサーを特定できる新しいソリューションを開発できます。このようなソリューションは明らかにREQ-7に適合せず、RTPレベルで検出可能です。
The nature of this RTP service offered by a network operator employing a content splicer is that the RTP-layer security relationship is between the receiver and the splicer, and between the sender and the splicer, but is not end-to-end between the receiver and the sender. This appears to invalidate the undetectability goal, but in the common case, the receiver will consider the splicer as the main media source.
コンテンツスプライサーを使用するネットワークオペレーターが提供するこのRTPサービスの性質は、RTPレイヤーのセキュリティ関係がレシーバーとスプライサーの間、およびセンダーとスプライサーの間であるが、レシーバーの間ではエンドツーエンドではないということです。と送信者。これは検出不能の目標を無効にするように見えますが、一般的なケースでは、レシーバーはスプライサーをメインメディアソースと見なします。
Some RTP deployments use RTP payload security mechanisms (e.g., ISMACryp [ISMACryp]). If any payload internal security mechanisms are used, only the RTP sender and the RTP receiver establish that security context, in which case any middlebox (e.g., splicer) between the RTP sender and the RTP receiver will not get such keying material. This may impact the splicer's ability to perform splicing if it is dependent on RTP payload-level hints for finding the splice in and out points. However, other potential solutions exist to specify or mark where the splicing points exist in the media streams. When using RTP payload security mechanisms, SRTP or other security mechanisms at RTP or lower layers can be used to provide integrity and source authentication between the splicer and the RTP receiver.
一部のRTP展開では、RTPペイロードセキュリティメカニズム（ISMACryp [ISMACryp]など）を使用します。ペイロードの内部セキュリティメカニズムが使用されている場合、RTP送信者とRTP受信者のみがそのセキュリティコンテキストを確立します。その場合、RTP送信者とRTP受信者の間のミドルボックス（スプライサーなど）はそのようなキー情報を取得しません。これは、スプライスのインポイントとアウトポイントを見つけるためのRTPペイロードレベルのヒントに依存している場合、スプライサーのスプライシング機能に影響を与える可能性があります。ただし、メディアストリームのどこにスプライシングポイントが存在するかを指定またはマークするための、他の潜在的な解決策が存在します。 RTPペイロードセキュリティメカニズムを使用する場合、RTPまたは下位層のSRTPまたはその他のセキュリティメカニズムを使用して、スプライサーとRTPレシーバーの間に整合性とソース認証を提供できます。
The following individuals have reviewed the earlier versions of this specification and provided very valuable comments: Colin Perkins, Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R. Oran, Cullen Jennings, Ali C. Begen, Charles Eckel, and Ning Zong.
次の個人は、この仕様の以前のバージョンをレビューし、非常に貴重なコメントを提供しました：コリンパーキンス、マグナスウェスタールンド、ロニイーブン、トムヴァンケーネジェム、ジョルグオット、デビッドR.オラン、カレンジェニングス、アリC.ベゲン、チャールズエッケル、寧宗。
[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月。
[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月。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, August 2012.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、2012年8月。
[ISMACryp] Internet Streaming Media Alliance (ISMA), "ISMA Encryption and Authentication Specification 2.0", November 2007.
[ISMACryp]インターネットストリーミングメディアアライアンス（ISMA）、「ISMA暗号化および認証仕様2.0」、2007年11月。
[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月。
[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月。
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, April 2010.
[RFC5762]パーキンス、C。、「RTPおよびデータグラム輻輳制御プロトコル（DCCP）」、RFC 5762、2010年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月。
[SCTE30] Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Splicing API", 2009.
[SCTE30]ケーブル通信技術者協会（SCTE）、「Digital Program Insertion Splicing API」、2009年。
[SCTE35] Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Cueing Message for Cable", 2011.
[SCTE35]ケーブル通信技術者協会（SCTE）、「ケーブル用デジタルプログラム挿入キューメッセージ」、2011年。
Both a translator and mixer can realize splicing by changing a set of RTP parameters.
トランスレーターとミキサーの両方が、RTPパラメーターのセットを変更することでスプライシングを実現できます。
A translator has no SSRC; hence it is transparent to the RTP sender and receiver. Therefore, the RTP sender sees the full path to the receiver when the translator is passing its content. When a translator inserts the substitutive content, the RTP sender could get a report on the path up to the translator itself. Additionally, if splicing does not occur yet, the translator does not need to rewrite the RTP header, and the overhead on the translator can be avoided.
翻訳者にはSSRCがありません。したがって、RTPの送信側と受信側には透過的です。したがって、RTP送信者は、トランスレータがコンテンツを渡すときに、受信者へのフルパスを確認します。翻訳者が代替コンテンツを挿入すると、RTP送信者は、翻訳者までのパスに関するレポートを取得できます。さらに、スプライシングがまだ発生していない場合、トランスレーターはRTPヘッダーを書き換える必要がなく、トランスレーターのオーバーヘッドを回避できます。
If a mixer is used to do splicing, it can also allow the RTP sender to learn the situation of its content on the receiver or on the mixer just like the translator does, which is specified in Section 4.2. Compared to the translator, the mixer's outstanding benefit is that it is pretty straightforward to do with RTCP messages, for example, bit-rate adaptation to handle varying network conditions. But the translator needs more considerations, and its implementation is more complex.
ミキサーを使用してスプライシングを行う場合、RTPセンダーは、セクション4.2で指定されているトランスレーターのように、レシーバーまたはミキサーでコンテンツの状況を学習することもできます。トランスレータと比較すると、ミキサーの顕著な利点は、RTCPメッセージを処理するのが非常に簡単であるということです。たとえば、さまざまなネットワーク条件を処理するためのビットレート適応です。しかし、翻訳者はより多くの考慮事項を必要とし、その実装はより複雑です。
From the above analysis, both the translator and mixer have their own advantages: less overhead or less complexity on handling RTCP. After long and sophisticated discussions, the avtext WG members decided that they prefer less complexity rather than less overhead and are inclined to choose a mixer to do splicing.
上記の分析から、トランスレーターとミキサーの両方に独自の利点があります。RTCPの処理のオーバーヘッドや複雑さが少ないことです。長く洗練された議論の後、avtext WGメンバーは、オーバーヘッドを減らすのではなく、複雑さを減らすことを希望し、スプライシングを行うミキサーを選択する傾向にあります。
If one chooses a mixer as splicer, the overhead on the mixer must be taken into account even if the splicing has not occurred yet.
ミキサーをスプライサーとして選択する場合、スプライシングがまだ発生していない場合でも、ミキサーのオーバーヘッドを考慮する必要があります。
Author's Address
著者のアドレス
Jinwei Xia Huawei Software No.101 Nanjing, Yuhuatai District 210012 China
jin is X IA hu A is software no.101 Nanjing、Y U Huatai District 210012 China
Phone: +86-025-86622310
EMail: xiajinwei@huawei.com