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
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.
本备忘录定义了两个RTP/RTCP扩展，用于向拼接器指示拼接相关信息：一个RTP报头扩展，用于传输“带内”信息，另一个RTP控制协议（RTCP）数据包用于传输带外信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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数据包并在有效负载内搜索拼接间隔。这种处理的需要增加了middlebox的工作负载，并限制了middlebox可以支持的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头扩展[RFC8285]，通过将其包含在RTP数据包中来提供拼接间隔。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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流中的一个虚拟点，适用于替代内容输入，通常位于两个独立可解码帧之间的边界。
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流中的一个虚拟点，适用于替代内容退出，通常位于两个独立可解码帧之间的边界。
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流中的内容。
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
RTP拼接旨在用某些替代多媒体内容替换某些多媒体内容，然后将其转发给接收器一段时间。此过程由主RTP发送方授权，该发送方提供在主内容中插入替代多媒体内容的特定时间窗口。典型用法
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.
场景是指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拼接的中间盒。它同时接收主内容和替代内容，但在任何时间点只选择将其中一个发送给接收方。当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混频器，拼接器将在向接收器生成输出流时使用其自己的同步源（SSRC）、序列号空间和时序模型，使用贡献源（CSC）列表来指示是否正在交付原始内容或替代内容。拼接器代表内容提供商，可以从其生成的RTP数据包中省略CSC列表。这简化了接收器的设计，因为它们不需要解析CSC列表，但更难确定拼接何时发生（它需要检查RTP有效负载数据，而不仅仅是RTP报头）。作为RTP混频器工作的拼接器将发送方和接收方之间的流分成两部分，它需要单独的控制回路来进行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
当即将进行新的拼接时，主RTP发送器需要将拼接间隔发送给拼接器。拼接间隔应通过RTP标头扩展或RTCP扩展消息发送
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发送器必须提前发送拼接间隔。例如，当拼接器向主发送器发送RTCP接收器报告（RR）时，主RTP发送器可以按照[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发送器都有效，两个发送器必须共享一个公共参考时钟，以便拼接器能够实现精确拼接。公共参考时钟的要求（例如，分辨率、偏移）取决于媒体内容使用的编解码器。
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 SR消息在替代RTP流中找出该第一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时间戳与拼接间隔中的后一个NTP时间戳对应相同的时间瞬间。
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.
本备忘录定义了两个向后兼容的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报头扩展携带7个八位字节的拼接输出NTP时间戳（NTP时间戳“秒”的24位以下部分和[RFC5905]中定义的NTP时间戳“分数”的32位），然后是8个八位字节的拼接输出NTP时间戳（64位NTP时间戳，如[RFC5905]中定义）。拼接输出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显示了两种报头格式的拼接间隔报头扩展。
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
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：使用单字节头格式的拼接间隔
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) | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：使用双字节头格式的拼接间隔
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
除了包含RTP头扩展之外，主RTP发送方还在RTCP拼接通知消息中包含拼接间隔。无论时间戳是否包含在RTP标头扩展中，主RTP发送方都必须发送RTCP拼接通知消息。这在中间盒剥离RTP标头扩展的情况下提供了健壮性。主RTP发送器
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.
必须确保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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]中所定义，RTCP数据包的长度（32位字减去1），包括报头和任何填充。
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时间戳，它是一个64位无符号定点数字，整数部分在前32位，小数部分在后32位。该格式与RTCP SR（RFC3550第6.4.1节）中的NTP时间戳字段相同。
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
另一个延迟元素是同步引起的延迟。在拼接开始或结束时，在同步多媒体流的单独组件之前，接收器必须接收足够的同步元数据。主RTP发送方或替代发送方应尽早发送同步元数据，以便接收方能够以同步方式播放多媒体。当拼接器向主发送器或替代发送器发送RTCP RR时，主RTP发送器或替代发送器可以根据[RFC3550]第6.4.1节中描述的机制，基于例如RTT，估计何时发送同步元数据。主RTP发送方和替代发送方也可以通过一些专有的带外机制进行协调，以决定元数据何时发送以及发送给谁。如果两者都发送信息，拼接器应根据当前情况选择一个，例如，选择（1）主RTP发送器
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.
同步主媒体内容时，或（2）同步拼接内容时，从替代发送方获得的信息。为了减少可能的同步延迟，建议采用[RFC6051]中定义的机制。
This section examines the implications of losing RTCP splicing notification messages, e.g., the RTP header extension is stripped on the path.
本节探讨丢失RTCP拼接通知消息的含义，例如，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发送器和替代RTP发送器可以使用一种启发式方法来验证拼接间隔是否到达拼接器。
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，并向主RTP流和替代RTP流的发送者发送RTCP接收报告。这允许发送方检测到拼接器路径上的问题。或者，也可以实现拼接器，使其没有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.
在检测到故障后，拼接器可以通过一些带外信令技术与主发送器和替代发送器通信，并退回到其支持的有效负载特定机制，例如，[SCTE35]中定义的MPEG2-TS拼接解决方案，或者干脆放弃拼接。
This document defines the URI for declaring this header extension in an "extmap" attribute to be "urn:ietf:params:rtp-hdrext:splicing-interval".
本文档定义了用于在“extmap”属性中将此头扩展声明为“urn:ietf:params:rtp hdrext:spicing interval”的URI。
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]中定义的标准语义，使用了一种称为“拼接”的新语义来表示主RTP流和替代RTP流之间的关系。接头组中只允许有两条“m=”线。主RTP流是具有扩展的“extmap”属性的流，另一个是替代流。单个“m=”线不得同时包含在不同的拼接组中。主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必须仅应用于SDP“m=”行与使用拼接的替代流在同一组中且具有扩展拼接“extmap”属性的RTP数据包。此语义也适用于捆绑案例。
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
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）接收一个MPEG2-TS流（有效负载100），和/或在端口30002上从替代RTP发送方（多播目的地地址为233.252.0.2）接收另一个MPEG2-TS流。但在特定时间点，拼接器仅选择一个流并将所选流中的内容输出到下游接收器。
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
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
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. 一种应答，应答者在应答中选择自己的包地址，并保持替代介质不变。
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
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
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. 一种应答，应答者在应答中选择自己的包地址，并保持替代介质不变。
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
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
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]的安全注意事项适用。拼接器可以是混频器或转换器，这两种类型的RTP中介的拓扑[RFC7667][RFC7201]的所有安全注意事项都适用于拼接器。
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级别的端到端安全性，因此它需要成为信令上下文和必要的安全关联（例如，安全实时传输协议（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报头扩展的拼接时间信息进行身份验证。
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级转发环路的CSC列表，以简化无法处理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 Compact标头扩展[RFC8285]，如下所示：
Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
Description: Splicing Interval
说明：拼接间隔
Contact: Jinwei Xia <xiajinwei@huawei.com>
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已在“会话描述协议（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：实时应用的传输协议”，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，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年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.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.，Desineni，H.，和R.Even，Ed.，“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]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<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，“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”，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]夏，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.，“安全实时传输协议（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]Cotton，M.，Leiba，B.，和T.Narten，“在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]电缆通信工程师学会（SCTE），“电缆数字节目插入提示信息”，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.
作者要感谢以下帮助审阅本文件并提供非常有价值评论的个人：科林·珀金斯、波·伯曼、斯蒂芬·博茨科和本·坎贝尔。
Authors' Addresses
作者地址
Jinwei Xia Huawei
夏金伟华为
Email: xiajinwei@huawei.com
Email: xiajinwei@huawei.com
Roni Even Huawei
甚至华为
Email: roni.even@huawei.com
Email: roni.even@huawei.com
Rachel Huang Huawei
黄华伟
Email: rachel.huang@huawei.com
Email: rachel.huang@huawei.com
Lingli Deng China Mobile
凌厉邓中国移动
Email: denglingli@chinamobile.com
Email: denglingli@chinamobile.com