[要約] RFC 8286は、RTP/RTCP拡張を使用してRTPスプライシング通知を行うための仕様です。その目的は、RTPストリームの途中でのスプライシング操作を通知し、受信者に正確なメディア再生を可能にすることです。
Internet Engineering Task Force (IETF) J. Xia
Request for Comments: 8286 R. Even
Category: Standards Track R. Huang
ISSN: 2070-1721 Huawei
L. Deng
China Mobile
October 2017
RTP/RTCP Extension for RTP Splicing Notification
RTPスプライシング通知用のRTP / RTCP拡張
Abstract
概要
Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing.
コンテンツのスプライシングは、メインのマルチメディアストリームのコンテンツを他のマルチメディアコンテンツに置き換え、代替マルチメディアコンテンツを受信者に一定期間配信するプロセスです。スプライサーはRTPスプライシングを処理するように設計されており、スプライシングの開始と終了のタイミングを知る必要があります。
This memo defines two RTP/RTCP extensions to indicate the splicing-related information to the splicer: an RTP header extension that conveys the information "in band" and an RTP Control Protocol (RTCP) packet that conveys the information out of band.
このメモは、スプライサーにスプライシング関連情報を示す2つのRTP / RTCP拡張を定義します。「インバンド」で情報を伝達するRTPヘッダー拡張と、バンド外で情報を伝達するRTPコントロールプロトコル（RTCP）パケットです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8286.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8286で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Overview ........................................................4
2.1. Overview of RTP Splicing ...................................4
2.2. Overview of Splicing Interval ..............................5
3. Conveying Splicing Interval in RTP/RTCP Extensions ..............7
3.1. RTP Header Extension .......................................7
3.2. RTCP Splicing Notification Message .........................8
4. Reducing Splicing Latency ......................................10
5. Failure Cases ..................................................11
6. Session Description Protocol (SDP) Signaling ...................12
6.1. Declarative SDP ...........................................12
6.2. Offer/Answer without BUNDLE ...............................13
6.3. Offer/Answer with BUNDLE: All Media Are Spliced ...........14
6.4. Offer/Answer with BUNDLE: A Subset of Media Are Spliced ...16
7. Security Considerations ........................................18
8. IANA Considerations ............................................19
8.1. RTCP Control Packet Types .................................19
8.2. RTP Compact Header Extensions .............................20
8.3. SDP Grouping Semantic Extension ...........................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
Acknowledgements ..................................................22
Authors' Addresses ................................................22
Splicing is a process that replaces some multimedia content with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. In some predictable splicing cases, e.g., advertisement insertion, the splicing duration needs to be inside of the specific pre-designated time slot. Certain timing information about when to start and end the splicing must be first acquired by the splicer in order to start the splicing. This document refers to this information as the "Splicing Interval".
スプライシングは、一部のマルチメディアコンテンツを他のマルチメディアコンテンツで置き換え、代替マルチメディアコンテンツを一定期間レシーバに配信するプロセスです。一部の予測可能なスプライシングの場合（広告の挿入など）では、スプライシング期間は特定の事前に指定されたタイムスロット内にある必要があります。スプライシングを開始および終了するタイミングに関する特定のタイミング情報は、スプライシングを開始するために、最初にスプライサーが取得する必要があります。このドキュメントでは、この情報を「スプライシングインターバル」と呼びます。
[SCTE35] provides a method that encapsulates the Splicing Interval inside the MPEG2-TS (MPEG2 transport stream) layer in cable TV systems. When transported in RTP, a middlebox designed as the splicer to decode the RTP packets and search for the Splicing Interval inside the payloads is required. The need for such processing increases the workload of the middlebox and limits the number of RTP sessions the middlebox can support.
[SCTE35]は、ケーブルテレビシステムのMPEG2-TS（MPEG2トランスポートストリーム）レイヤー内に接続間隔をカプセル化する方法を提供します。 RTPで転送する場合、RTPパケットをデコードしてペイロード内のスプライシング間隔を検索するスプライサーとして設計されたミドルボックスが必要です。このような処理の必要性により、ミドルボックスのワークロードが増加し、ミドルボックスがサポートできるRTPセッションの数が制限されます。
This document defines an RTP header extension [RFC8285] used by the main RTP sender to provide the Splicing Interval by including it in the RTP packets.
このドキュメントでは、RTPパケットにスプライシングインターバルを含めることでスプライシングインターバルを提供するために、メインRTP送信者が使用するRTPヘッダー拡張[RFC8285]を定義しています。
However, the Splicing Interval conveyed in the RTP header extension might not reach the splicer successfully. Any splicing-unaware middlebox on the path between the RTP sender and the splicer might strip this RTP header extension.
ただし、RTPヘッダー拡張で伝達されるスプライシングインターバルは、スプライサーに正常に到達しない場合があります。 RTP送信者とスプライサー間のパス上のスプライシング非対応ミドルボックスは、このRTPヘッダー拡張を削除する可能性があります。
To increase robustness against such a case, this document also defines a new RTP Control Protocol (RTCP) packet type to carry the same Splicing Interval to the splicer. Since RTCP is also unreliable and may not be as "immediate" as the in-band technique, it's only considered to be a complement to the RTP header extension.
このような場合の堅牢性を高めるために、このドキュメントでは、新しいRTP制御プロトコル（RTCP）パケットタイプも定義して、同じスプライシング間隔をスプライサーに伝えます。 RTCPも信頼性が低く、インバンドテクニックほど「即時」ではない可能性があるため、RTPヘッダー拡張を補完するものと見なされるだけです。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
In addition, we define the following terms:
さらに、次の用語を定義します。
Main RTP Sender:
メインRTP送信者：
The sender of RTP packets carrying the main RTP stream.
メインRTPストリームを運ぶRTPパケットの送信者。
Splicer:
スプライサー：
An intermediary node that inserts substitutive content into a main RTP stream. The splicer sends substitutive content to the RTP receiver instead of the main content during splicing. It is also responsible for processing RTCP traffic between the RTP sender and the RTP receiver.
代替コンテンツをメインRTPストリームに挿入する中間ノード。スプライサーは、スプライシング中にメインコンテンツの代わりにRTPレシーバーに代替コンテンツを送信します。また、RTP送信側とRTP受信側の間のRTCPトラフィックを処理します。
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つの独立してデコード可能なフレーム間の境界にあります。
Splicing Interval:
スプライシング間隔：
The NTP timestamps, representing the main RTP sender wallclock time, for the splicing-in point and splicing-out point per [RFC6828], allowing the splicer to know when to start and end the RTP splicing.
[RFC6828]に基づくスプライシングインポイントとスプライシングアウトポイントのメインRTP送信側ウォールクロック時間を表すNTPタイムスタンプ。これにより、スプライサーはRTPスプライシングを開始および終了するタイミングを知ることができます。
Substitutive RTP Sender:
代替RTP送信者：
The sender of RTP packets carrying the RTP stream that will replace the content in the main RTP stream.
メインRTPストリームのコンテンツを置き換えるRTPストリームを運ぶRTPパケットの送信者。
RTP splicing is intended to replace some multimedia content with certain substitutive multimedia content and then forward it to the receivers for a period of time. This process is authorized by the main RTP sender that offers a specific time window for inserting the substitutive multimedia content in the main content. A typical usage scenario is where an IPTV service provider uses its own regional advertising content to replace national advertising content, the time window of which is explicitly indicated by the IPTV service provider.
RTPスプライシングは、一部のマルチメディアコンテンツを特定の代替マルチメディアコンテンツに置き換えてから、しばらくの間レシーバーに転送することを目的としています。このプロセスは、メインのコンテンツに代替マルチメディアコンテンツを挿入するための特定の時間枠を提供するメインのRTP送信者によって承認されます。典型的な使用シナリオは、IPTVサービスプロバイダーが独自の地域広告コンテンツを使用して、国別広告コンテンツを置き換える場合です。その時間枠はIPTVサービスプロバイダーによって明示的に示されます。
The splicer is a middlebox handling RTP splicing. It receives the main content and substitutive content simultaneously but only chooses to send one of them to the receiver at any point in time. When RTP splicing begins, the splicer sends the substitutive content to the receivers instead of the main content. When RTP splicing ends, the splicer switches back to sending the main content to the receivers. This implies that the receiver is explicitly configured to receive the traffic via the splicer and will return any RTCP feedback to it in the presence of the splicer.
スプライサーは、RTPスプライシングを処理するミドルボックスです。メインコンテンツと代替コンテンツを同時に受信しますが、いずれかの時点でそれらの1つを受信者に送信することのみを選択します。 RTPスプライシングが開始すると、スプライサーはメインコンテンツの代わりに代替コンテンツを受信者に送信します。 RTPスプライシングが終了すると、スプライサーはメインコンテンツをレシーバーに送信するように切り替わります。これは、レシーバーがスプライサーを介してトラフィックを受信するように明示的に構成され、スプライサーが存在する場合はRTCPフィードバックをレシーバーに返すことを意味します。
The middlebox working as the splicer can be implemented as either an RTP mixer or an RTP translator. If implemented as an RTP mixer, the splicer will use its own synchronization source (SSRC), sequence number space, and timing model when generating the output stream to receivers, using the contributing source (CSRC) list to indicate whether the original content or substitutive content is being delivered. The splicer, on behalf of the content provider, can omit the CSRC list from the RTP packets it generates. This simplifies the design of the receivers, since they don't need to parse the CSRC list, but makes it harder to determine when the splicing is taking place (it requires inspection of the RTP payload data, rather than just the RTP headers). A splicer working as an RTP mixer splits the flow between the sender and receiver into two, and it requires separate control loops for RTCP and congestion control. [RFC6828] provides an example of an RTP mixer approach.
スプライサーとして機能するミドルボックスは、RTPミキサーまたはRTPトランスレーターとして実装できます。 RTPミキサーとして実装されている場合、スプライサーは、ソースへの出力ストリーム（CSRC）リストを使用してレシーバーへの出力ストリームを生成するときに、独自の同期ソース（SSRC）、シーケンス番号スペース、およびタイミングモデルを使用して、元のコンテンツまたは代替のどちらであるかを示しますコンテンツが配信されています。スプライサーは、コンテンツプロバイダーに代わって、生成するRTPパケットからCSRCリストを省略できます。これにより、CSRCリストを解析する必要がないため、レシーバーの設計が簡素化されますが、スプライシングが行われているときを判断することが難しくなります（RTPヘッダーだけでなく、RTPペイロードデータの検査が必要になります）。 RTPミキサーとして機能するスプライサーは、送信側と受信側の間のフローを2つに分割し、RTCPと輻輳制御のために個別の制御ループが必要です。 [RFC6828]は、RTPミキサーアプローチの例を提供します。
A splicer implemented as an RTP translator [RFC3550] will forward the RTP packets from the original and substitutive senders with their SSRCs intact but will need to rewrite RTCP Sender Report (SR) packets to account for the splicing. In this case, the congestion control loops run between the original sender and receiver and between the substitutive sender and receiver. The splicer needs to ensure that the RTCP feedback messages from the receiver are passed to the right sender to let the congestion control work.
RTPトランスレーター[RFC3550]として実装されたスプライサーは、元の送信者と代替送信者からのRTPパケットをそのままのSSRCで転送しますが、RTCP送信者レポート（SR）パケットを書き換えてスプライシングを考慮する必要があります。この場合、輻輳制御ループは、元の送信側と受信側の間、および代替送信側と受信側の間で実行されます。スプライサーは、輻輳制御を機能させるために、受信側からのRTCPフィードバックメッセージが正しい送信側に渡されるようにする必要があります。
To handle splicing on the RTP layer at the reserved time slots set by the main RTP sender, the splicer must first know the Splicing Interval from the main RTP sender before it can start splicing.
メインRTP送信側によって設定された予約済みタイムスロットでRTP層のスプライシングを処理するには、スプライサーはスプライシングを開始する前に、まずメインRTPセンダーからのスプライシング間隔を知る必要があります。
When a new splicing is forthcoming, the main RTP sender needs to send the Splicing Interval to the splicer. The Splicing Interval SHOULD be sent by the RTP header extension or RTCP extension message more than once to mitigate possible packet loss. To enable the splicer to get the substitutive content before the splicing starts, the main RTP sender MUST send the Splicing Interval well in advance. For example, the main RTP sender can estimate when to send the Splicing Interval based on the round-trip time (RTT), following the mechanisms described in Section 6.4.1 of [RFC3550] when the splicer sends an RTCP Receiver Report (RR) to the main sender.
新しいスプライシングが近づくと、メインのRTP送信者はスプライシング間隔をスプライサーに送信する必要があります。可能なパケット損失を軽減するために、RTPヘッダー拡張またはRTCP拡張メッセージによってスプライシングインターバルを2回以上送信する必要があります（SHOULD）。スプライサーがスプライシングを開始する前に代替コンテンツを取得できるようにするには、メインのRTP送信者がスプライシング間隔を十分に前もって送信する必要があります。たとえば、メインのRTP送信者は、スプライサーがRTCPレシーバーレポート（RR）を送信するときに、[RFC3550]のセクション6.4.1で説明されているメカニズムに従って、往復時間（RTT）に基づいてスプライシングインターバルを送信するタイミングを推定できます。メインの送信者に。
The substitutive sender also needs to learn the Splicing Interval from the main RTP sender in advance and estimate when to transfer the substitutive content to the splicer. The Splicing Interval could be transmitted from the main RTP sender to the substitutive content using some out-of-band mechanisms -- for example, a proprietary mechanism to exchange the Splicing Interval -- or the substitutive sender is implemented together with the main RTP sender inside a single device. To ensure that the Splicing Interval is valid for both the main RTP sender and the substitutive RTP sender, the two senders MUST share a common reference clock so that the splicer can achieve accurate splicing. The requirements for the common reference clock (e.g., resolution, skew) depend on the codec used by the media content.
代用送信者は、メインRTP送信者から事前にスプライシング間隔を学習し、代用コンテンツをスプライサーに転送するタイミングを推定する必要もあります。スプライシングインターバルは、帯域外メカニズム（たとえば、スプライシングインターバルを交換する独自のメカニズム）を使用して、メインRTP送信者から代替コンテンツに送信できます。または、代替RTP送信者がメインRTP送信者と一緒に実装されています。単一のデバイス内。スプライシングインターバルがメインRTPセンダーと代替RTPセンダーの両方に対して有効であることを確認するには、2つのセンダーが共通の基準クロックを共有して、スプライサーが正確なスプライシングを実現できるようにする必要があります。共通の基準クロックの要件（解像度、スキューなど）は、メディアコンテンツで使用されるコーデックによって異なります。
In this document, the main RTP sender uses a pair of NTP timestamps to indicate when to start and end the splicing to the splicer: the timestamp of the first substitutive RTP packet at the splicing-in point and the timestamp of the first main RTP packet at the splicing-out point.
このドキュメントでは、メインRTP送信者は、スプライサーへのスプライシングをいつ開始および終了するかを示すために、NTPタイムスタンプのペアを使用します。スプライシングインポイントでの最初の代替RTPパケットのタイムスタンプと最初のメインRTPパケットのタイムスタンプスプライシングアウトポイントで。
When the substitutive RTP sender gets the Splicing Interval, it must prepare the substitutive stream. The main content provider and the substitutive content provider MUST ensure that the RTP timestamp of the first substitutive RTP packet that would be presented to the receivers corresponds to the same time instant as the former NTP timestamp in the Splicing Interval. To enable the splicer to know the first substitutive RTP packet it needs to send, the substitutive RTP sender MUST send the substitutive RTP packet ahead of the splicing-in point, allowing the splicer to find out the timestamp of this first RTP packet in the substitutive RTP stream, e.g., using a prior RTCP SR message.
代用RTP送信者がスプライシング間隔を取得すると、代用ストリームを準備する必要があります。メインコンテンツプロバイダーと代替コンテンツプロバイダーは、レシーバーに提示される最初の代替RTPパケットのRTPタイムスタンプが、スプライシングインターバルの以前のNTPタイムスタンプと同じ時刻に対応することを確認する必要があります。スプライサーが送信する必要がある最初の代替RTPパケットを知ることができるようにするには、代替RTP送信者がスプライシングインポイントの前に代替RTPパケットを送信して、スプライサーが代替のこの最初のRTPパケットのタイムスタンプを見つけられるようにする必要がありますたとえば、以前のRTCP SRメッセージを使用したRTPストリーム。
When it is time for the splicing to end, the main content provider and the substitutive content provider MUST ensure that the RTP timestamp of the first main RTP packet that would be presented on the receivers corresponds to the same time instant as the latter NTP timestamp in the Splicing Interval.
スプライシングが終了する時間になると、メインコンテンツプロバイダーと代替コンテンツプロバイダーは、レシーバーに提示される最初のメインRTPパケットのRTPタイムスタンプが、スプライシング間隔。
This memo defines two backward-compatible RTP extensions to convey the Splicing Interval to the splicer: an RTP header extension and an RTCP splicing notification message.
このメモは、スプライシング間隔をスプライサーに伝えるための2つの下位互換性のあるRTP拡張を定義します。RTPヘッダー拡張とRTCPスプライシング通知メッセージです。
The RTP header extension mechanism defined in [RFC8285] can be adapted to carry the Splicing Interval, which consists of a pair of NTP timestamps.
[RFC8285]で定義されているRTPヘッダー拡張メカニズムは、NTPタイムスタンプのペアで構成されるスプライシングインターバルを伝送するように適合させることができます。
This RTP header extension carries the 7 octets of the splicing-out NTP timestamp (lower 24-bit part of the "Seconds" of an NTP timestamp and the 32 bits of the "Fraction" of an NTP timestamp as defined in [RFC5905]), followed by the 8 octets of the splicing-in NTP timestamp (64-bit NTP timestamp as defined in [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are inferred from the top 8 bits of the splicing-in NTP timestamp, assuming that (1) the splicing-out time is after the splicing-in time and (2) the Splicing Interval is less than 2^25 seconds. Therefore, if the value of the 7 octets of the splicing-out NTP timestamp is smaller than the value of the 7 lower octets of the splicing-in NTP timestamp, it implies a wrap of the 56-bit splicing-out NTP timestamp, which means that the top 8-bit value of the 64-bit splicing-out NTP timestamp is equal to the top 8-bit value of the splicing-in NTP timestamp plus 0x01. Otherwise, the top 8 bits of the splicing-out NTP timestamp are equal to the top 8 bits of the splicing-in NTP timestamp.
このRTPヘッダー拡張は、スプライシングアウトNTPタイムスタンプの7オクテット（NTPタイムスタンプの「秒」の下位24ビット部分と[RFC5905]で定義されているNTPタイムスタンプの「分数」の32ビット）を伝送します、続いてスプライシングインNTPタイムスタンプの8オクテット（[RFC5905]で定義されている64ビットNTPタイムスタンプ）。スプライシングアウトNTPタイムスタンプの上位8ビットは、スプライシングインNTPタイムスタンプの上位8ビットから推測されます。これは、（1）スプライシングアウト時間がスプライシングイン時間より後であり、（2）スプライシング間隔であると仮定します。 2 ^ 25秒未満です。したがって、スプライシングアウトNTPタイムスタンプの7オクテットの値がスプライシングインNTPタイムスタンプの7オクテットの値よりも小さい場合、56ビットのスプライシングアウトNTPタイムスタンプのラップを意味します。つまり、64ビットのスプライシングアウトNTPタイムスタンプの上位8ビット値は、スプライシングインNTPタイムスタンプの上位8ビット値に0x01を加えたものに等しいということです。それ以外の場合、スプライシングアウトNTPタイムスタンプの上位8ビットは、スプライシングインNTPタイムスタンプの上位8ビットと同じです。
This RTP header extension can be encoded using either the one-byte or two-byte header defined in [RFC8285]. Figures 1 and 2 show the Splicing Interval header extension with each of the two header formats.
このRTPヘッダー拡張は、[RFC8285]で定義されている1バイトまたは2バイトのヘッダーを使用してエンコードできます。図1と図2は、2つのヘッダー形式のそれぞれを持つスプライシングインターバルヘッダー拡張を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=14 | OUT NTP timestamp - Seconds (bit 8-31) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| OUT NTP timestamp - Fraction (bit 0-31) |e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
| IN NTP timestamp - Seconds (bit 0-31) |s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| IN NTP timestamp - Fraction (bit 0-31) |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
Figure 1: Splicing Interval Using the One-Byte Header Format
図1：1バイトのヘッダー形式を使用したスプライシング間隔
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=15 | OUT NTP timestamp - Seconds |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
|OUT Secds(cont)| OUT NTP timestamp - Fraction |e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
|OUT Fract(cont)| IN NTP timestamp - Seconds |s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| IN Secds(cont)| IN NTP timestamp - Fraction |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
| IN Fract(cont)| 0 (pad) | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Splicing Interval Using the Two-Byte Header Format
図2：2バイトのヘッダー形式を使用したスプライシング間隔
Since the inclusion of an RTP header extension will reduce the efficiency of RTP header compression, it is RECOMMENDED that the main sender insert the RTP header extensions into a number of RTP packets, instead of all of the RTP packets, prior to the splicing-in.
RTPヘッダー拡張を含めるとRTPヘッダー圧縮の効率が低下するため、メインの送信者は、スプライスインの前に、すべてのRTPパケットではなく、いくつかのRTPパケットにRTPヘッダー拡張を挿入することをお勧めします。
After the splicer obtains the RTP header extension and derives the Splicing Interval, it generates its own stream and is not allowed to include the RTP header extension in outgoing packets; this reduces header overhead.
スプライサーは、RTPヘッダー拡張を取得してスプライシング間隔を導出した後、独自のストリームを生成し、発信パケットにRTPヘッダー拡張を含めることはできません。これにより、ヘッダーのオーバーヘッドが減少します。
In addition to including the RTP header extension, the main RTP sender includes the Splicing Interval in an RTCP splicing notification message. Whether or not the timestamps are included in the RTP header extension, the main RTP sender MUST send the RTCP splicing notification message. This provides robustness in the case where a middlebox strips RTP header extensions. The main RTP sender MUST make sure that the splicing information contained in the RTCP splicing notification message is consistent with the information included in the RTP header extensions.
RTPヘッダー拡張を含めることに加えて、メインのRTP送信者は、RTCPスプライシング通知メッセージにスプライシング間隔を含めます。タイムスタンプがRTPヘッダー拡張に含まれているかどうかに関係なく、メインのRTP送信者はRTCPスプライシング通知メッセージを送信する必要があります。これにより、ミドルボックスがRTPヘッダー拡張を取り除く場合に堅牢性が提供されます。メインのRTP送信者は、RTCPスプライシング通知メッセージに含まれているスプライシング情報が、RTPヘッダー拡張に含まれている情報と一致していることを確認する必要があります。
The RTCP splicing notification message is a new RTCP packet type. It has a fixed header followed by a pair of NTP timestamps:
RTCPスプライシング通知メッセージは、新しいRTCPパケットタイプです。固定ヘッダーとそれに続くNTPタイムスタンプのペアがあります。
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|reserved | PT=213 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN NTP timestamp (most significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN NTP timestamp (least significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUT NTP timestamp (most significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUT NTP timestamp (least significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RTCP Splicing Notification Message
図3：RTCPスプライシング通知メッセージ
The RTCP splicing notification message includes the following fields:
RTCPスプライシング通知メッセージには、次のフィールドが含まれます。
Length: 16 bits
長さ：16ビット
As defined in [RFC3550], the length of the RTCP packet in 32-bit words minus one, including the header and any padding.
[RFC3550]で定義されているように、32ビットワードから1を引いたRTCPパケットの長さ。ヘッダーとパディングを含みます。
SSRC: 32 bits
SSRC：32ビット
The SSRC of the main RTP sender.
メインRTP送信側のSSRC。
Timestamp: 64 bits
タイムスタンプ：64ビット
Indicates the wallclock time when this splicing starts and ends. The full-resolution NTP timestamp is used, which is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. This format is the same as the NTP timestamp field in the RTCP SR (Section 6.4.1 of [RFC3550]).
このスプライシングが開始および終了する実時間を示します。フル解像度のNTPタイムスタンプが使用されます。これは、最初の32ビットに整数部があり、最後の32ビットに小数部がある64ビットの符号なし固定小数点数です。この形式は、RTCP SRのNTPタイムスタンプフィールドと同じです（[RFC3550]のセクション6.4.1）。
The RTCP splicing notification message can be included in the RTCP compound packet together with the RTCP SR generated at the main RTP sender; hence, it follows the compound RTCP rules defined in Section 6.1 in [RFC3550].
RTCPスプライシング通知メッセージは、メインRTP送信側で生成されたRTCP SRと共にRTCP複合パケットに含めることができます。したがって、[RFC3550]のセクション6.1で定義されている複合RTCPルールに従います。
If the use of non-compound RTCP [RFC5506] was previously negotiated between the sender and the splicer, the RTCP splicing notification messages may be sent as non-compound RTCP packets. In some cases where the mapping from the RTP timestamp to the NTP timestamp changes, e.g., clock drift happens before the splicing event, sending an RTCP SR or even updated Splicing Interval information in a timely manner might be required in order to update the timestamp mapping for accurate splicing.
非複合RTCP [RFC5506]の使用が送信者とスプライサー間で以前にネゴシエートされた場合、RTCPスプライシング通知メッセージは非複合RTCPパケットとして送信される場合があります。 RTPタイムスタンプからNTPタイムスタンプへのマッピングが変更される場合、たとえば、スプライシングイベントの前にクロックドリフトが発生する場合、タイムスタンプマッピングを更新するために、RTCP SRまたは更新されたスプライシングインターバル情報をタイムリーに送信することが必要になる場合があります。正確なスプライシングのため。
Since the RTCP splicing notification message is intentionally sent by the main RTP sender to the splicer, the splicer is not allowed to forward this message to the receivers, so as to avoid useless processing and additional RTCP bandwidth consumption in the downstream receivers.
RTCPスプライシング通知メッセージはメインRTP送信者によってスプライサーに意図的に送信されるため、スプライサーはこのメッセージをレシーバーに転送できません。これにより、ダウンストリームレシーバーでの無用な処理と追加のRTCP帯域幅の消費が回避されます。
When splicing starts or ends, the splicer outputs the multimedia content from another sender to the receivers. Given that the receivers must first acquire certain information ([RFC6285] refers to this information as "Reference Information") to start processing the multimedia data, either the main RTP sender or the substitutive sender SHOULD provide the Reference Information together with its multimedia content to reduce the delay caused by acquiring the Reference Information. The methods by which the Reference Information is distributed to the receivers are out of scope for this memo.
スプライシングが開始または終了すると、スプライサーはマルチメディアコンテンツを別の送信者から受信者に出力します。受信者がマルチメディアデータの処理を開始するために最初に特定の情報（[RFC6285]はこの情報を「参照情報」と呼ぶ）を取得する必要がある場合、メインRTP送信者または代替送信者のいずれかが参照情報とそのマルチメディアコンテンツを提供する必要があります。参照情報の取得による遅延を削減します。参照情報が受信者に配布される方法は、このメモの範囲外です。
Another latency element is delay caused by synchronization. The receivers must receive enough synchronization metadata prior to synchronizing the separate components of the multimedia streams when splicing starts or ends. Either the main RTP sender or the substitutive sender SHOULD send the synchronization metadata early enough so that the receivers can play out the multimedia in a synchronized fashion. The main RTP sender or the substitutive sender can estimate when to send the synchronization metadata based on, for example, the RTT, following the mechanisms described in Section 6.4.1 of [RFC3550] when the splicer sends an RTCP RR to the main sender or the substitutive sender. The main RTP sender and the substitutive sender can also be coordinated by some proprietary out-of-band mechanisms to decide when, and to whom, the metadata is to be sent. If both send the information, the splicer SHOULD pick one based on the current situation, e.g., choosing either (1) the main RTP sender when synchronizing the main media content or (2) the information from the substitutive sender when synchronizing the spliced content. To reduce possible synchronization delay, it is RECOMMENDED that the mechanisms defined in [RFC6051] be adopted.
もう1つの遅延要素は、同期による遅延です。レシーバーは、スプライシングの開始時または終了時にマルチメディアストリームの個別のコンポーネントを同期する前に、十分な同期メタデータを受信する必要があります。メインのRTP送信者または代替の送信者のいずれかが、受信者がマルチメディアを同期した方法で再生できるように、同期メタデータを早く送信する必要があります（SHOULD）。メインのRTP送信者または代理の送信者は、RTFなどに基づいて、同期メタデータをいつ送信するかを見積もることができます。スプライサーがRTCP RRをメインの送信者または代替送信者。メインRTP送信者と代替送信者は、メタデータをいつ誰に送信するかを決定するために、独自の帯域外メカニズムによって調整することもできます。両方が情報を送信する場合、スプライサーは現在の状況に基づいて1つを選択する必要があります。たとえば、（1）メインメディアコンテンツを同期するときにメインRTP送信者を、または（2）スプライスされたコンテンツを同期するときに代替送信者からの情報を選択します。起こり得る同期遅延を減らすために、[RFC6051]で定義されたメカニズムを採用することを推奨します。
This section examines the implications of losing RTCP splicing notification messages, e.g., the RTP header extension is stripped on the path.
このセクションでは、RTPスプライシング通知メッセージが失われた場合の影響について検討します。たとえば、RTPヘッダー拡張がパスから削除されます。
Given that there may be a splicing-unaware middlebox on the path between the main RTP sender and the splicer, the main and substitutive RTP senders can use one heuristic to verify whether or not the Splicing Interval reaches the splicer.
メインRTP送信者とスプライサーの間のパスにスプライシング非対応ミドルボックスが存在する可能性がある場合、メインおよび代替RTP送信者は1つのヒューリスティックを使用して、スプライシング間隔がスプライサーに到達するかどうかを確認できます。
The splicer can be implemented to have its own SSRC and send RTCP reception reports to the senders of the main and substitutive RTP streams. This allows the senders to detect problems on the path to the splicer. Alternatively, it is possible to implement the splicer such that it has no SSRC and does not send RTCP reports; this prevents the senders from being able to monitor the quality of the path to the splicer.
スプライサーは、独自のSSRCを持ち、RTCP受信レポートをメインおよび代替RTPストリームの送信者に送信するように実装できます。これにより、送信者はスプライサーへのパス上の問題を検出できます。または、SSRCがなく、RTCPレポートを送信しないようにスプライサーを実装することもできます。これにより、送信者はスプライサーへのパスの品質を監視できなくなります。
If the splicer has an SSRC and sends its own RTCP reports, it can choose not to pass RTCP reports it receives from the receivers to the senders. This will prevent the senders from being able to monitor the quality of the paths from the splicer to the receivers.
スプライサーにSSRCがあり、独自のRTCPレポートを送信する場合、受信機から受信したRTCPレポートを送信機に渡さないように選択できます。これにより、送信側がスプライサーから受信側へのパスの品質を監視できなくなります。
A splicer that has an SSRC can choose to pass RTCP reception reports from the receivers back to the senders, after modifications to account for the splicing. This will allow the senders to monitor the quality of the paths from the splicer to the receivers. A splicer that does not have its own SSRC has to forward and translate RTCP reports from the receiver; otherwise, the senders will not see any receivers in the RTP session.
SSRCを持つスプライサーは、スプライシングを考慮して変更した後、RTCP受信レポートを受信者から送信者に渡すことを選択できます。これにより、送信側は、スプライサーから受信側へのパスの品質を監視できます。独自のSSRCを持たないスプライサーは、レシーバーからのRTCPレポートを転送および変換する必要があります。そうでない場合、送信者はRTPセッションで受信者を参照できません。
If the splicer is implemented as a mixer, it will have its own SSRC, send its own RTCP reports, and forward translated RTCP reports from the receivers.
スプライサーがミキサーとして実装されている場合は、独自のSSRCを持ち、独自のRTCPレポートを送信し、レシーバーから変換されたRTCPレポートを転送します。
Upon the detection of a failure, the splicer can communicate with the main sender and the substitutive sender via some out-of-band signaling technique and fall back to the payload-specific mechanisms it supports, e.g., the MPEG2-TS splicing solution defined in [SCTE35], or just abandon the splicing.
障害が検出されると、スプライサーは帯域外シグナリング技術を介してメイン送信者および代替送信者と通信し、サポートするペイロード固有のメカニズムにフォールバックできます（例：で定義されているMPEG2-TSスプライシングソリューション）。 [SCTE35]、またはスプライシングを放棄する。
This document defines the URI for declaring this header extension in an "extmap" attribute to be "urn:ietf:params:rtp-hdrext:splicing-interval".
このドキュメントでは、「extmap」属性でこのヘッダー拡張を宣言するためのURIを「urn：ietf：params：rtp-hdrext：splicing-interval」として定義しています。
This document extends the standard semantics defined in "The Session Description Protocol (SDP) Grouping Framework" [RFC5888] with a new semantic, called "SPLICE", to represent the relationship between the main RTP stream and the substitutive RTP stream. Only two "m=" lines are allowed in the SPLICE group. The main RTP stream is the one with the extended "extmap" attribute, and the other one is the substitutive stream. A single "m=" line MUST NOT be included in different SPLICE groups at the same time. The main RTP sender provides the information about both main and substitutive sources.
このドキュメントは、「セッション記述プロトコル（SDP）グループ化フレームワーク」[RFC5888]で定義されている標準のセマンティクスを「SPLICE」と呼ばれる新しいセマンティクスで拡張し、メインRTPストリームと代替RTPストリームの関係を表します。 SPLICEグループでは、 "m ="行は2つだけ許可されます。メインのRTPストリームは拡張「extmap」属性を持つストリームで、もう1つは代替ストリームです。単一の「m =」行を、同時に異なるSPLICEグループに含めることはできません。メインRTP送信側は、メインソースと代替ソースの両方に関する情報を提供します。
The extended SDP attribute specified in this document is applicable for offer/answer content [RFC3264] and does not affect any rules when negotiating offers and answers. When used with multiple "m=" lines, substitutive RTP MUST be applied only to the RTP packets whose SDP "m=" line is in the same group with the substitutive stream using SPLICE and has the extended splicing "extmap" attribute. This semantic is also applicable for BUNDLE cases.
このドキュメントで指定されている拡張SDP属性は、オファー/アンサーコンテンツ[RFC3264]に適用され、オファーとアンサーをネゴシエートするときのルールには影響しません。複数の「m =」行で使用する場合、代替RTPは、SPLICEを使用する代替ストリームと同じグループにあり、拡張スプライシング「extmap」属性を持つRTPパケットにのみ適用する必要があります。このセマンティクスは、BUNDLEケースにも適用されます。
The following examples show how SDP signaling could be used for splicing in different cases.
次の例は、SDPシグナリングをさまざまなケースでスプライシングに使用する方法を示しています。
v=0
o=xia 1122334455 1122334466 IN IP4 splicing.example.com
s=RTP Splicing Example
t=0 0
a=group:SPLICE 1 2
m=video 30000 RTP/AVP 100
i=Main RTP Stream
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=mid:1
m=video 30002 RTP/AVP 100
i=Substitutive RTP Stream
c=IN IP4 233.252.0.2/127
a=sendonly
a=rtpmap:100 MP2T/90000
a=mid:2
Figure 4: Example SDP for a Single-Channel Splicing Scenario
図4：単一チャネル接続シナリオのSDPの例
The splicer receiving the SDP message above receives one MPEG2-TS stream (payload 100) from the main RTP sender (with a multicast destination address of 233.252.0.1) on port 30000 and/or receives another MPEG2-TS stream from the substitutive RTP sender (with a multicast destination address of 233.252.0.2) on port 30002. But at a particular point in time, the splicer only selects one stream and outputs the content from the chosen stream to the downstream receivers.
上記のSDPメッセージを受信するスプライサーは、ポート30000のメインRTP送信者（233.252.0.1のマルチキャスト宛先アドレス）から1つのMPEG2-TSストリーム（ペイロード100）を受信し、および/または代替RTP送信者から別のMPEG2-TSストリームを受信します。 （マルチキャスト宛先アドレス233.252.0.2で）ポート30002。ただし、特定の時点では、スプライサーは1つのストリームのみを選択し、選択したストリームからコンテンツをダウンストリームレシーバーに出力します。
SDP Offer - from the main RTP sender:
SDPオファー-メインRTP送信者から：
v=0
o=xia 1122334455 1122334466 IN IP4 splicing.example.com
s=RTP Splicing Example
t=0 0
a=group:SPLICE 1 2
m=video 30000 RTP/AVP 31 100
i=Main RTP Stream
c=IN IP4 splicing.example.com
a=rtpmap:31 H261/90000
a=rtpmap:100 MP2T/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
a=mid:1
m=video 40000 RTP/AVP 31 100
i=Substitutive RTP Stream
c=IN IP4 substitutive.example.com
a=rtpmap:31 H261/90000
a=rtpmap:100 MP2T/90000
a=sendonly
a=mid:2
SDP Answer - from the splicer:
SDP回答-スプライサーから：
v=0
o=xia 1122334455 1122334466 IN IP4 splicer.example.com
s=RTP Splicing Example
t=0 0
a=group:SPLICE 1 2
m=video 30000 RTP/AVP 100
i=Main RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:100 MP2T/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
a=mid:1
m=video 40000 RTP/AVP 100
i=Substitutive RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:100 MP2T/90000
a=recvonly
a=mid:2
In this example, the bundled audio and video media have their own substitutive media for splicing:
この例では、バンドルされたオーディオおよびビデオメディアには、スプライシング用の独自の代替メディアがあります。
1. An offer, in which the offerer assigns a unique address and a substitutive media to each bundled "m=" line for splicing within the BUNDLE group.
1. オファー。オファーは、バンドルグループ内のスプライシングのために、バンドルされた各「m =」行に一意のアドレスと代替メディアを割り当てます。
2. An answer, in which the answerer selects its own BUNDLE address and leaves the substitutive media untouched.
2. 回答者が独自のBUNDLEアドレスを選択し、代替メディアをそのままにしておく回答。
SDP Offer - from the main RTP sender:
SDPオファー-メインRTP送信者から：
v=0
o=alice 1122334455 1122334466 IN IP4 splicing.example.com
s=RTP Splicing Example
c=IN IP4 splicing.example.com
t=0 0
a=group:SPLICE foo 1
a=group:SPLICE bar 2
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
m=audio 20000 RTP/AVP 0 8 97
i=Substitutive audio RTP Stream
c=IN IP4 substitutive.example.com
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=sendonly
a=mid:1
m=video 20002 RTP/AVP 31 32
i=Substitutive video RTP Stream
c=IN IP4 substitutive.example.com
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=mid:2
a=sendonly
SDP Answer - from the splicer:
SDP回答-スプライサーから：
v=0
o=bob 2808844564 2808844564 IN IP4 splicer.example.com
s=RTP Splicing Example
c=IN IP4 splicer.example.com
t=0 0
a=group:SPLICE foo 1
a=group:SPLICE bar 2
a=group:BUNDLE foo bar
m=audio 30000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
m=video 30000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
m=audio 30002 RTP/AVP 0
i=Substitutive audio RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:0 PCMU/8000
a=recvonly
a=mid:1
m=video 30004 RTP/AVP 32
i=Substitutive video RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:32 MPV/90000
a=mid:2
a=recvonly
In this example, the substitutive media only applies for video when splicing:
この例では、代替メディアはスプライス時のビデオにのみ適用されます。
1. An offer, in which the offerer assigns a unique address to each bundled "m=" line within the BUNDLE group and assigns a substitutive media to the bundled video "m=" line for splicing.
1. オファー。オファーでは、バンドルグループ内のバンドルされた各「m =」行に一意のアドレスを割り当て、スプライシングのために代替ビデオ「m =」行に代替メディアを割り当てます。
2. An answer, in which the answerer selects its own BUNDLE address and leaves the substitutive media untouched.
2. 回答者が独自のBUNDLEアドレスを選択し、代替メディアをそのままにしておく回答。
SDP Offer - from the main RTP sender:
SDPオファー-メインRTP送信者から：
v=0
o=alice 1122334455 1122334466 IN IP4 splicing.example.com
s=RTP Splicing Example
c=IN IP4 splicing.example.com
t=0 0
a=group:SPLICE bar 2
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=sendonly
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
m=video 20000 RTP/AVP 31 32
i=Substitutive video RTP Stream
c=IN IP4 substitutive.example.com
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=mid:2
a=sendonly
SDP Answer - from the splicer:
SDP回答-スプライサーから：
v=0
o=bob 2808844564 2808844564 IN IP4 splicer.example.com
s=RTP Splicing Example
c=IN IP4 splicer.example.com
t=0 0
a=group:SPLICE bar 2
a=group:BUNDLE foo bar
m=audio 30000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=recvonly
m=video 30000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
m=video 30004 RTP/AVP 32
i=Substitutive video RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:32 MPV/90000
a=mid:2
a=recvonly
The security considerations of the RTP specification [RFC3550] and the general mechanism for RTP header extensions [RFC8285] apply. The splicer can be either a mixer or a translator, and all the security considerations of topologies [RFC7667] [RFC7201] for these two types of RTP intermediaries are applicable for the splicer.
RTP仕様のセキュリティに関する考慮事項[RFC3550]およびRTPヘッダー拡張の一般的なメカニズム[RFC8285]が適用されます。スプライサーはミキサーまたはトランスレーターのいずれかであり、トポロジー[RFC7667] [RFC7201]のこれら2つのタイプのRTP仲介者に関するすべてのセキュリティ上の考慮事項がスプライサーに適用されます。
The splicer replaces some content with other content in RTP packets, thus breaking any RTP-level end-to-end security, such as source authentication and integrity protection. End-to-end source authentication is not possible with any known existing splicing solution. A new solution can theoretically be developed that enables identification of the participating entities and what each provides, i.e., the different media sources -- main and substitutive -- and the splicer, which provides the RTP-level integration of the media payloads in a common timeline and synchronization context.
スプライサーは、RTPパケット内の一部のコンテンツを他のコンテンツに置き換えます。これにより、ソース認証や整合性保護など、RTPレベルのエンドツーエンドのセキュリティが破られます。エンドツーエンドのソース認証は、既知の既存のスプライシングソリューションでは不可能です。理論的には、関与するエンティティとそれぞれが提供するもの、つまり、さまざまなメディアソース（メインと代替）、および共通のメディアペイロードのRTPレベルの統合を提供するスプライサーを特定できる新しいソリューションを開発できます。タイムラインと同期コンテキスト。
Since the splicer breaks RTP-level end-to-end security, it needs to be part of the signaling context and the necessary security associations (e.g., Secure Real-time Transport Protocol (SRTP)
スプライサーはRTPレベルのエンドツーエンドのセキュリティを破壊するため、シグナリングコンテキストと必要なセキュリティアソシエーションの一部である必要があります（例：Secure Real-time Transport Protocol（SRTP）
[RFC3711] crypto contexts) established for the RTP session participants. When using SRTP, the splicer would have to be provisioned with the same security association as the main RTP sender.
[RFC3711]暗号コンテキスト）RTPセッション参加者のために確立されました。 SRTPを使用する場合、スプライサーはメインのRTP送信者と同じセキュリティアソシエーションでプロビジョニングする必要があります。
If there are concerns about the confidentiality of the splicing time information, the header extension defined in this document MUST also be protected; for example, header extension encryption [RFC6904] can be used in this case. However, the malicious endpoint may get the splicing time information by other means, e.g., inferring it from the communication between the main and substitutive content sources. To avoid the insertion of invalid substitutive content, the splicer MUST have some mechanisms to authenticate the substitutive stream source.
スプライシング時間情報の機密性について懸念がある場合は、このドキュメントで定義されているヘッダー拡張も保護する必要があります。たとえば、この場合、ヘッダー拡張暗号化[RFC6904]を使用できます。ただし、悪意のあるエンドポイントはスプライシング時間情報を他の方法で取得する場合があります。たとえば、メインと代替のコンテンツソース間の通信からそれを推測します。無効な代替コンテンツの挿入を回避するために、スプライサーは代替ストリームソースを認証するメカニズムを備えている必要があります。
For cases where the splicing time information is changed by a malicious endpoint, the splicing, for example, may fail, since it will not be available at the right time for the substitutive media to arrive. Another case is one where an attacker may prevent the receivers from receiving the content from the main sender by inserting extra splicing time information. To avoid the above scenarios, the authentication of the RTP header extension for splicing time information SHOULD be considered.
悪意のあるエンドポイントによってスプライシング時間情報が変更される場合、たとえば、代替メディアが到着する適切なタイミングでスプライシングが利用できないため、スプライシングが失敗する可能性があります。別のケースは、攻撃者が追加のスプライシング時間情報を挿入することにより、受信者がメインの送信者からコンテンツを受信できないようにする場合です。上記のシナリオを回避するには、スプライシング時間情報のRTPヘッダー拡張の認証を検討する必要があります（SHOULD）。
When a splicer implemented as a mixer sends the stream to the receivers, the CSRC list, which can be used to detect RTP-level forwarding loops as defined in Section 8.2 of [RFC3550], may be removed for simplifying the receivers that cannot handle multiple sources in the RTP stream. Hence, loops may occur, causing packets to loop back to a point upstream of the splicer and possibly forming a serious denial-of-service threat. In such a case, non-RTP means, e.g., signaling among all the participants, MUST be used to detect and resolve loops.
ミキサーとして実装されたスプライサーがストリームをレシーバーに送信するとき、[RFC3550]のセクション8.2で定義されているRTPレベルの転送ループを検出するために使用できるCSRCリストは、複数を処理できないレシーバーを簡略化するために削除される場合がありますRTPストリームのソース。したがって、ループが発生し、パケットがスプライサーの上流のポイントにループバックして、深刻なサービス拒否の脅威を形成する可能性があります。そのような場合、非RTPの意味、たとえば、すべての参加者間のシグナリングは、ループを検出して解決するために使用する必要があります。
Based on the guidelines suggested in [RFC8126], a new RTCP packet format has been registered in the "RTCP Control Packet types (PT)" registry:
[RFC8126]で提案されているガイドラインに基づいて、新しいRTCPパケット形式が「RTCP制御パケットタイプ（PT）」レジストリに登録されました。
Name: SNM
名前：SNM
Long name: Splicing Notification Message
長い名前：接合通知メッセージ
Value: 213
値：213
Reference: This document
参照：このドキュメント
IANA has registered a new RTP Compact Header Extension [RFC8285], according to the following:
IANAは、以下に従って、新しいRTPコンパクトヘッダー拡張[RFC8285]を登録しました。
Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
Description: Splicing Interval
説明：スプライシング間隔
Contact: Jinwei Xia <xiajinwei@huawei.com>
Reference: This document
参照：このドキュメント
IANA has registered the new SDP grouping semantic extension called "SPLICE" in the "Semantics for the 'group' SDP Attribute" subregistry of the "Session Description Protocol (SDP) Parameters" registry:
IANAは、「SPLICE」と呼ばれる新しいSDPグループ化セマンティック拡張を、「セッション記述プロトコル（SDP）パラメータ」レジストリの「「グループ」SDP属性のセマンティクス」サブレジストリに登録しました。
Semantics: Splice
セマンティクス：スプライス
Token: SPLICE
とけん： ＳＰぃせ
Reference: This document
参照：このドキュメント
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org / info / rfc3264>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-editor.org/info/rfc5888>.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「セッション記述プロトコル（SDP）グループ化フレームワーク」、RFC 5888、DOI 10.17487 / RFC5888、2010年6月、<https://www.rfc-editor.org/info/ rfc5888>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <https://www.rfc-editor.org/info/rfc5905>。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <https://www.rfc-editor.org/info/rfc6051>.
[RFC6051] Perkins、C。およびT. Schierl、「RTPフローの迅速な同期」、RFC 6051、DOI 10.17487 / RFC6051、2010年11月、<https://www.rfc-editor.org/info/rfc6051>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<https://www.rfc-editor.org/info/rfc7201>。
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.
[RFC7667] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<https://www.rfc-editor.org/info/rfc7667>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, <https://www.rfc-editor.org/info/rfc8285>.
[RFC8285] Singer、D.、Desieneni、H。、およびR. Even、編、「RTPヘッダー拡張の一般的なメカニズム」、RFC 8285、DOI 10.17487 / RFC8285、2017年10月、<https：//www.rfc -editor.org/info/rfc8285>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<https://www.rfc-editor.org/info/rfc3711>。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC5506] Johansson、I。およびM. Westerlund、「Reduced-Size Real-Time Transport Control Protocol（RTCP）：Opportunities and Consequences」、RFC 5506、DOI 10.17487 / RFC5506、2009年4月、<https：// www .rfc-editor.org / info / rfc5506>。
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011, <https://www.rfc-editor.org/info/rfc6285>.
[RFC6285] Ver Steeg、B.、Begen、A.、Van Caenegem、T。、およびZ. Vax、「マルチキャストRTPセッションのユニキャストベースの迅速な取得」、RFC 6285、DOI 10.17487 / RFC6285、2011年6月、<https ：//www.rfc-editor.org/info/rfc6285>。
[RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, DOI 10.17487/RFC6828, January 2013, <https://www.rfc-editor.org/info/rfc6828>.
[RFC6828] Xia、J。、「RTPセッションのコンテンツスプライシング」、RFC 6828、DOI 10.17487 / RFC6828、2013年1月、<https://www.rfc-editor.org/info/rfc6828>。
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <https://www.rfc-editor.org/info/rfc6904>.
[RFC6904] Lennox、J。、「Secure Real-time Transport Protocol（SRTP）のヘッダー拡張の暗号化」、RFC 6904、DOI 10.17487 / RFC6904、2013年4月、<https://www.rfc-editor.org/ info / rfc6904>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[SCTE35] Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Cueing Message for Cable", 2016, <http://www.scte.org/SCTEDocs/Standards/ SCTE%2035%202016.pdf>.
[SCTE35] Society of Cable Telecommunications Engineers（SCTE）、「Digital Program Insertion Cueing Message for Cable」、2016年、<http://www.scte.org/SCTEDocs/Standards/ SCTE％2035％202016.pdf>。
Acknowledgements
謝辞
The authors would like to thank the following individuals who helped to review this document and provided very valuable comments: Colin Perkins, Bo Burman, Stephen Botzko, and Ben Campbell.
著者は、このドキュメントのレビューを手伝い、非常に貴重なコメントを提供してくれた次の人物に感謝します。ColinPerkins、Bo Burman、Stephen Botzko、およびBen Campbell。
Authors' Addresses
著者のアドレス
Jinwei Xia Huawei
jin is X IA hu A is
Email: xiajinwei@huawei.com
Roni Even Huawei
RO逆偶数hu Aは
Email: roni.even@huawei.com
Rachel Huang Huawei
レイチェル・ファンフー
Email: rachel.huang@huawei.com
Lingli Deng China Mobile
チャイナモバイルのグライド
Email: denglingli@chinamobile.com