Internet Engineering Task Force (IETF) J. Xia
Request for Comments: 6828 Huawei
Category: Informational January 2013
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Xia
Request for Comments: 6828 Huawei
Category: Informational January 2013
ISSN: 2070-1721
Content Splicing for RTP Sessions
RTP会话的内容拼接
Abstract
摘要
Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.
内容拼接是将主多媒体流的内容替换为其他多媒体内容并在一段时间内将替代多媒体内容发送给接收者的过程。有线电视运营商通常使用拼接插入本地广告，从而用本地广告替换全国广告内容。
This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing.
本备忘录描述了内容拼接的一些用例以及RTP交付的拼接内容的一组要求。它为如何使用RTP混合器处理内容拼接提供了具体的指南。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6828.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6828.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. System Model and Terminology ....................................3
3. Requirements for RTP Splicing ...................................6
4. Content Splicing for RTP Sessions ...............................7
4.1. RTP Processing in RTP Mixer ................................7
4.2. RTCP Processing in RTP Mixer ...............................8
4.3. Considerations for Handling Media Clipping at the
RTP Layer .................................................10
4.4. Congestion Control Considerations .........................11
4.5. Considerations for Implementing Undetectable Splicing .....13
5. Implementation Considerations ..................................13
6. Security Considerations ........................................14
7. Acknowledgments ................................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
Appendix A. Why Mixer Is Chosen ...................................17
1. Introduction ....................................................2
2. System Model and Terminology ....................................3
3. Requirements for RTP Splicing ...................................6
4. Content Splicing for RTP Sessions ...............................7
4.1. RTP Processing in RTP Mixer ................................7
4.2. RTCP Processing in RTP Mixer ...............................8
4.3. Considerations for Handling Media Clipping at the
RTP Layer .................................................10
4.4. Congestion Control Considerations .........................11
4.5. Considerations for Implementing Undetectable Splicing .....13
5. Implementation Considerations ..................................13
6. Security Considerations ........................................14
7. Acknowledgments ................................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
Appendix A. Why Mixer Is Chosen ...................................17
This document outlines how content splicing can be used in RTP sessions. Splicing, in general, is a process where part of a multimedia content is replaced with other multimedia content and delivered to the receivers for a period of time. The substitutive content can be provided, for example, via another stream or via local media file storage. One representative use case for splicing is local advertisement insertion. This allows content providers to replace national advertising content with their own regional advertising content prior to delivering the regional advertising content to the receivers. Besides the advertisement insertion use case, there are other use cases in which the splicing technology can
本文档概述了如何在RTP会话中使用内容拼接。通常，拼接是一个过程，其中一部分多媒体内容被其他多媒体内容替换，并在一段时间内交付给接收器。替代内容可以例如经由另一流或经由本地媒体文件存储来提供。拼接的一个典型用例是本地广告插入。这允许内容提供商在将区域广告内容交付给接收者之前，用自己的区域广告内容替换国家广告内容。除了广告插入用例外，还有其他可以使用拼接技术的用例
be applied, for example, splicing a recorded video into a video conferencing session or implementing a playlist server that stitches pieces of video together.
例如，可以将录制的视频拼接到视频会议会话中，或者实现将视频片段缝合在一起的播放列表服务器。
Content splicing is a well-defined operation in MPEG-based cable TV systems. Indeed, the Society for Cable Telecommunications Engineers (SCTE) has created two standards, [SCTE30] and [SCTE35], to standardize MPEG2-TS splicing procedures. SCTE 30 creates a standardized method for communication between advertisement server and splicer, and SCTE 35 supports splicing of MPEG2 transport streams.
内容拼接是基于MPEG的有线电视系统中定义良好的操作。事实上，电缆通信工程师协会（SCTE）已经制定了两个标准[SCTE30]和[SCTE35]，以标准化MPEG2-TS拼接程序。SCTE 30创建广告服务器和拼接器之间通信的标准化方法，SCTE 35支持MPEG2传输流的拼接。
When using multimedia splicing into the Internet, the media may be transported by RTP. In this case, the original media content and substitutive media content will use the same time period but may contain different numbers of RTP packets due to different media codecs and entropy coding. This mismatch may require some adjustments of the RTP header sequence number to maintain consistency. [RFC3550] provides the tools to enable seamless content splicing in RTP sessions, but to date there have been no clear guidelines on how to use these tools.
当使用多媒体拼接到Internet时，媒体可以通过RTP传输。在这种情况下，原始媒体内容和替代媒体内容将使用相同的时间段，但是由于不同的媒体编解码器和熵编码，可能包含不同数量的RTP分组。这种不匹配可能需要对RTP报头序列号进行一些调整，以保持一致性。[RFC3550]提供了在RTP会话中实现无缝内容拼接的工具，但到目前为止，还没有关于如何使用这些工具的明确指南。
This memo outlines the requirements for content splicing in RTP sessions and describes how an RTP mixer can be used to meet these requirements.
本备忘录概述了RTP会话中内容拼接的要求，并描述了如何使用RTP混合器来满足这些要求。
In this document, the splicer, an intermediary network element, handles RTP splicing. The splicer can receive main content and substitutive content simultaneously but will send one of them at one point of time.
在本文档中，拼接器（一种中间网元）处理RTP拼接。拼接器可以同时接收主内容和替代内容，但会在一个时间点发送其中一个。
When RTP splicing begins, the splicer sends the substitutive content to the RTP receiver instead of the main content for a period of time. When RTP splicing ends, the splicer switches back to sending the main content to the RTP receiver.
当RTP拼接开始时，拼接器向RTP接收器发送替代内容，而不是主内容一段时间。当RTP拼接结束时，拼接器切换回向RTP接收器发送主要内容。
A simplified RTP splicing diagram is depicted in Figure 1, in which only one main content flow and one substitutive content flow are given. Actually, the splicer can handle multiple splicing for multiple RTP sessions simultaneously. RTP splicing may happen more than once in multiple time slots during the lifetime of the main RTP stream. The methods by which the splicer learns when to start and end the splicing are out of scope for this document.
图1描述了一个简化的RTP拼接图，其中只给出了一个主内容流和一个替代内容流。实际上，拼接器可以同时处理多个RTP会话的多个拼接。在主RTP流的生存期内，RTP拼接可能在多个时隙中发生多次。拼接人员了解何时开始和结束拼接的方法不在本文件范围内。
+---------------+
| | Main Content +-----------+
| Main RTP |------------->| | Output Content
| Content | | Splicer |--------------->
+---------------+ ---------->| |
| +-----------+
|
| Substitutive Content
|
|
+-----------------------+
| Substitutive RTP |
| Content |
| or |
| Local File Storage |
+-----------------------+
+---------------+
| | Main Content +-----------+
| Main RTP |------------->| | Output Content
| Content | | Splicer |--------------->
+---------------+ ---------->| |
| +-----------+
|
| Substitutive Content
|
|
+-----------------------+
| Substitutive RTP |
| Content |
| or |
| Local File Storage |
+-----------------------+
Figure 1: RTP Splicing Architecture
图1:RTP拼接体系结构
This document uses the following terminologies.
本文件使用以下术语。
Output RTP Stream
输出RTP流
The RTP stream that the RTP receiver is currently receiving. The content of the output of the RTP stream can be either main content or substitutive content.
RTP接收器当前正在接收的RTP流。RTP流的输出内容可以是主内容或替代内容。
Main Content
主要内容
The multimedia content that is conveyed in the main RTP stream. Main content will be replaced by the substitutive content during splicing.
在主RTP流中传送的多媒体内容。在拼接过程中，主内容将替换为替代内容。
Main RTP Stream
主RTP流
The RTP stream that the splicer is receiving. The content of the main RTP stream can be replaced by substitutive content for a period of time.
拼接器正在接收的RTP流。主RTP流的内容可以在一段时间内被替换内容替换。
Main RTP Sender
主RTP发送器
The sender of RTP packets carrying the main RTP stream.
承载主RTP流的RTP数据包的发送方。
Substitutive Content
替代内容
The multimedia content that replaces the main content during splicing. The substitutive content can, for example, be contained in an RTP stream from a media sender or fetched from local media file storage.
在拼接过程中替换主要内容的多媒体内容。例如，替代内容可以包含在来自媒体发送方的RTP流中，或者从本地媒体文件存储器中获取。
Substitutive RTP Stream
替代RTP流
An RTP stream with new content that will replace the content in the main RTP stream. The substitutive RTP stream and main RTP stream are two separate streams. If the substitutive content is provided via a substitutive RTP stream, the substitutive RTP stream must pass through the splicer before the substitutive content is delivered to the receiver.
具有新内容的RTP流，将替换主RTP流中的内容。替代RTP流和主RTP流是两个独立的流。如果替代内容通过替代RTP流提供，则替代RTP流必须在替代内容交付给接收器之前通过拼接器。
Substitutive RTP Sender
替代RTP发送器
The sender of RTP packets carrying the substitutive RTP stream.
承载替代RTP流的RTP数据包的发送方。
Splicing-In Point
定点拼接
A virtual point in the RTP stream, suitable for substitutive content entry, typically in the boundary between two independently decodable frames.
RTP流中的一个虚拟点，适用于替代内容输入，通常位于两个独立可解码帧之间的边界。
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流中的一个虚拟点，适用于替代内容退出，通常位于两个独立可解码帧之间的边界。
Splicer
拼接器
An intermediary node that inserts substitutive content into a main RTP stream. The splicer sends substitutive content to the RTP receiver instead of main content during splicing. It is also responsible for processing RTP Control Protocol (RTCP) traffic between the RTP sender and the RTP receiver.
将替代内容插入主RTP流的中间节点。拼接器在拼接期间向RTP接收器发送替代内容，而不是主内容。它还负责处理RTP发送方和RTP接收方之间的RTP控制协议（RTCP）通信量。
In order to allow seamless content splicing at the RTP layer, the following requirements must be met. Meeting these will also allow, but not require, seamless content splicing at layers above RTP.
为了在RTP层实现无缝内容拼接，必须满足以下要求。满足这些要求还将允许（但不要求）在RTP之上的层进行无缝内容拼接。
REQ-1:
要求1：
The splicer should be agnostic about the network and transport-layer protocols used to deliver the RTP streams.
拼接器应该不知道用于传输RTP流的网络和传输层协议。
REQ-2:
要求2：
The splicing operation at the RTP layer must allow splicing at any point required by the media content and must not constrain when splicing-in or splicing-out operations can take place.
RTP层的拼接操作必须允许在媒体内容所需的任何点进行拼接，并且不得限制何时可以进行拼接输入或拼接输出操作。
REQ-3:
要求3：
Splicing of RTP content must be backward compatible with the RTP/RTCP protocol, associated profiles, payload formats, and extensions.
RTP内容的拼接必须与RTP/RTCP协议、相关配置文件、有效负载格式和扩展向后兼容。
REQ-4:
要求4：
The splicer will modify the content of RTP packets and thus break the end-to-end security, at a minimum, breaking the data integrity and source authentication. If the splicer is designated to insert substitutive content, it must be trusted, i.e., be in the security context(s) with the main RTP sender, the substitutive RTP sender, and the receivers. If encryption is employed, the splicer commonly must decrypt the inbound RTP packets and re-encrypt the outbound RTP packets after splicing.
拼接器将修改RTP数据包的内容，从而至少破坏端到端安全性，破坏数据完整性和源身份验证。如果指定拼接器插入替代内容，则拼接器必须受信任，即与主RTP发送方、替代RTP发送方和接收方处于安全上下文中。如果采用加密，拼接器通常必须解密入站RTP数据包，并在拼接后重新加密出站RTP数据包。
REQ-5:
要求5：
The splicer should rewrite as necessary and forward RTCP messages (e.g., including packet loss, jitter, etc.) sent from a downstream receiver to the main RTP sender or the substitutive RTP sender, and thus allow the main RTP sender or substitutive RTP sender to learn the performance of the downstream receiver when its content is being passed to an RTP receiver. In addition, the splicer should rewrite RTCP messages from the main RTP sender or substitutive RTP sender to the receiver.
拼接器应根据需要进行重写，并将从下游接收器发送的RTCP消息（例如，包括丢包、抖动等）转发给主RTP发送器或替代RTP发送器，从而允许主RTP发送方或替代RTP发送方在下游接收方的内容被传递到RTP接收方时了解其性能。此外，拼接器应将RTP消息从主RTP发送方或替代RTP发送方重写到接收方。
REQ-6:
要求6：
The splicer must not affect other RTP sessions running between the RTP sender and the RTP receiver and must be transparent for the RTP sessions it does not splice.
拼接器不得影响RTP发送方和RTP接收方之间运行的其他RTP会话，并且对于未拼接的RTP会话必须是透明的。
REQ-7:
要求7：
The RTP receiver should not be able to detect any splicing points in the RTP stream produced by the splicer on the RTP protocol level. For the advertisement insertion use case, it is important to make it difficult for the RTP receiver to detect where an advertisement insertion is starting or ending from the RTP packets, and thus avoiding the RTP receiver from filtering out the advertisement content. This memo only focuses on making the splicing undetectable at the RTP layer. The corresponding processing is depicted in Section 4.5.
RTP接收器不应能够在RTP协议级别上检测拼接器生成的RTP流中的任何拼接点。对于广告插入用例，重要的是使RTP接收器难以从RTP分组检测广告插入开始或结束的位置，从而避免RTP接收器过滤掉广告内容。本备忘录仅侧重于使拼接在RTP层不可检测。第4.5节描述了相应的处理。
The RTP specification [RFC3550] defines two types of middleboxes: RTP translators and RTP mixers. Splicing is best viewed as a mixing operation. The splicer generates a new RTP stream that is a mix of the main RTP stream and the substitutive RTP stream. An RTP mixer is therefore an appropriate model for a content splicer. In the next four subsections (from Section 4.1 to Section 4.4), the document analyzes how the mixer handles RTP splicing and how it satisfies the general requirements listed in Section 3. In Section 4.5, the document looks at REQ-7 in order to hide the fact that splicing takes place.
RTP规范[RFC3550]定义了两种类型的中间盒：RTP转换器和RTP混频器。最好将拼接视为一种混合操作。拼接器生成新的RTP流，该RTP流是主RTP流和替代RTP流的混合。因此，RTP混合器是内容拼接器的合适模型。在接下来的四小节（从第4.1节到第4.4节）中，本文件分析了混合器如何处理RTP拼接，以及它如何满足第3节中列出的一般要求。在第4.5节中，本文件查看了REQ-7，以隐藏拼接发生的事实。
A splicer could be implemented as a mixer that receives the main RTP stream and the substitutive content (possibly via a substitutive RTP stream), and sends a single output RTP stream to the receiver(s). That output RTP stream will contain either the main content or the substitutive content. The output RTP stream will come from the mixer and will have the synchronization source (SSRC) of the mixer rather than the main RTP sender or the substitutive RTP sender.
拼接器可以被实现为混合器，其接收主RTP流和替代内容（可能经由替代RTP流），并向接收器发送单个输出RTP流。该输出RTP流将包含主内容或替代内容。输出RTP流将来自混频器，并且将具有混频器的同步源（SSRC），而不是主RTP发送器或替代RTP发送器。
The mixer uses its own SSRC, sequence number space, and timing model when generating the output stream. Moreover, the mixer may insert the SSRC of the main RTP stream into the contributing source (CSRC) list in the output media stream.
混频器在生成输出流时使用自己的SSRC、序列号空间和时序模型。此外，混合器可以将主RTP流的SSRC插入到输出媒体流中的贡献源（csc）列表中。
At the splicing-in point, when the substitutive content becomes active, the mixer chooses the substitutive RTP stream as the input stream and extracts the payload data (i.e., substitutive content). If the substitutive content comes from local media file storage, the mixer directly fetches the substitutive content. After that, the mixer encapsulates substitutive content instead of main content as the payload of the output media stream and then sends the output RTP media stream to the receiver. The mixer may insert the SSRC of the substitutive RTP stream into the CSRC list in the output media stream. If the substitutive content comes from local media file storage, the mixer should leave the CSRC list blank.
在拼接点，当替代内容变为活动时，混合器选择替代RTP流作为输入流，并提取有效载荷数据（即，替代内容）。如果替代内容来自本地媒体文件存储，则混合器直接获取替代内容。之后，混频器封装替代内容而不是主内容作为输出媒体流的有效载荷，然后将输出RTP媒体流发送给接收器。混合器可以将替代RTP流的SSRC插入到输出媒体流中的csc列表中。如果替代内容来自本地媒体文件存储，混音器应将CSC列表留空。
At the splicing-out point, when the substitutive content ends, the mixer retrieves the main RTP stream as the input stream and extracts the payload data (i.e., main content). After that, the mixer encapsulates main content instead of substitutive content as the payload of the output media stream and then sends the output media stream to the receivers. Moreover, the mixer may insert the SSRC of the main RTP stream into the CSRC list in the output media stream as before.
在拼接输出点，当替代内容结束时，混合器检索主RTP流作为输入流，并提取有效负载数据（即，主内容）。之后，混合器封装主内容而不是替代内容作为输出媒体流的有效载荷，然后将输出媒体流发送给接收机。此外，混合器可以像前面一样将主RTP流的SSRC插入到输出媒体流中的csc列表中。
Note that if the content is too large to fit into RTP packets sent to the RTP receiver, the mixer needs to transcode or perform application-layer fragmentation. Usually the mixer is deployed as part of a managed system and MTU will be carefully managed by this system. This document does not raise any new MTU related issues compared to a standard mixer described in [RFC3550].
请注意，如果内容太大，无法装入发送到RTP接收器的RTP数据包，则混合器需要转码或执行应用层分段。通常，混音器作为管理系统的一部分进行部署，MTU将由该系统仔细管理。与[RFC3550]中所述的标准混合器相比，本文件未提出任何与MTU相关的新问题。
Splicing may occur more than once during the lifetime of the main RTP stream. This means the mixer needs to send main content and substitutive content in turn with its own SSRC identifier. From receiver point of view, the only source of the output stream is the mixer regardless of where the content is coming from.
在主RTP流的生命周期内，拼接可能会发生多次。这意味着混合器需要使用自己的SSRC标识符依次发送主要内容和替代内容。从接收者的角度来看，输出流的唯一来源是混合器，而不管内容来自何处。
By monitoring available bandwidth and buffer levels and by computing network metrics such as packet loss, network jitter, and delay, an RTP receiver can learn the network performance and communicate this to the RTP sender via RTCP reception reports.
通过监控可用带宽和缓冲区级别，并通过计算网络度量（如数据包丢失、网络抖动和延迟），RTP接收器可以了解网络性能，并通过RTCP接收报告将其传达给RTP发送方。
According to the description in Section 7.3 of [RFC3550], the mixer splits the RTCP flow between the sender and receiver into two separate RTCP loops; the RTP sender has no idea about the situation on the receiver. But splicing is a process where the mixer selects one media stream from multiple streams rather than mixing them, so the mixer can leave the SSRC identifier in the RTCP report intact
根据[RFC3550]第7.3节的描述，混频器将发送方和接收方之间的RTCP流分成两个独立的RTCP环路；RTP发送方不知道接收方的情况。但是拼接是一个过程，混合器从多个流中选择一个媒体流，而不是混合它们，因此混合器可以在RTCP报告中保留SSRC标识符不变
(i.e., the SSRC of the downstream receiver). This enables the main RTP sender or the substitutive RTP sender to learn the situation on the receiver.
（即，下游接收器的SSRC）。这使得主RTP发送方或替代RTP发送方能够了解接收方的情况。
If the RTCP report corresponds to a time interval that is entirely main content or entirely substitutive content, the number of output RTP packets containing substitutive content is equal to the number of input substitutive RTP packets (from the substitutive RTP stream) during splicing. In the same manner, the number of output RTP packets containing main content is equal to the number of input main RTP packets (from the main RTP stream) during non-splicing unless the mixer fragments the input RTP packets. This means that the mixer does not need to modify the loss packet fields in reception report blocks in RTCP reports. But, if the mixer fragments the input RTP packets, it may need to modify the loss packet fields to compensate for the fragmentation. Whether the input RTP packets are fragmented or not, the mixer still needs to change the SSRC field in the report block to the SSRC identifier of the main RTP sender or the substitutive RTP sender and rewrite the extended highest sequence number field to the corresponding original extended highest sequence number before forwarding the RTCP report to the main RTP sender or the substitutive RTP sender.
如果RTCP报告对应于完全为主内容或完全替代内容的时间间隔，则在拼接期间包含替代内容的输出RTP分组的数量等于输入替代RTP分组（来自替代RTP流）的数量。以相同的方式，在非拼接期间，包含主内容的输出RTP分组的数量等于输入主RTP分组的数量（来自主RTP流），除非混合器将输入RTP分组分段。这意味着混音器不需要修改RTCP报告中接收报告块中的丢失数据包字段。但是，如果混频器将输入RTP数据包分段，则可能需要修改丢失数据包字段以补偿分段。无论输入的RTP数据包是否分段，混音器仍然需要将报告块中的SSRC字段更改为主RTP发送方或替代RTP发送方的SSRC标识符，并在将RTP报告转发给主RTP发送方或替代RTP发送方之前，将扩展的最高序列号字段重写为相应的原始扩展的最高序列号发件人。
If the RTCP report spans the splicing-in point or the splicing-out point, it reflects the characteristics of the combination of main RTP packets and substitutive RTP packets. In this case, the mixer needs to divide the RTCP report into two separate RTCP reports and send them to their original RTP senders, respectively. For each RTCP report, the mixer also needs to make the corresponding changes to the packet loss fields in the report block besides the SSRC field and the extended highest sequence number field.
如果RTCP报告跨越拼接输入点或拼接输出点，则它反映主RTP数据包和替代RTP数据包组合的特征。在这种情况下，混合器需要将RTCP报告分成两个单独的RTCP报告，并分别将其发送给原始RTP发送者。对于每个RTCP报告，除了SSRC字段和扩展的最高序列号字段外，混合器还需要对报告块中的丢包字段进行相应的更改。
If the mixer receives an RTCP extended report (XR) block, it should rewrite the XR report block in a similar way to the reception report block in the RTCP report.
如果混音器接收到RTCP扩展报告（XR）块，则应以与RTCP报告中接收报告块类似的方式重写XR报告块。
Besides forwarding the RTCP reports sent from the RTP receiver, the mixer can also generate its own RTCP reports to inform the main RTP sender, or the substitutive RTP sender, of the reception quality of content not sent to the RTP receiver when it reaches the mixer. These RTCP reports use the SSRC of the mixer. If the substitutive content comes from local media file storage, the mixer does not need to generate RTCP reports for the substitutive stream.
除了转发从RTP接收器发送的RTCP报告外，混音器还可以生成自己的RTCP报告，以告知主RTP发送者或替代RTP发送者，当到达混音器时未发送到RTP接收器的内容的接收质量。这些RTCP报告使用混音器的SSRC。如果替换内容来自本地媒体文件存储，则混合器不需要为替换流生成RTCP报告。
Based on the above RTCP operating mechanism, the RTP sender whose content is being passed to a receiver will see the reception quality of its stream as received by the mixer and the reception quality of the spliced stream as received by the receiver. The RTP sender whose content is not being passed to a receiver will only see the reception quality of its stream as received by the mixer.
基于上述RTCP操作机制，其内容被传递给接收器的RTP发送方将看到混频器接收到的其流的接收质量和接收器接收到的拼接流的接收质量。内容未传递给接收器的RTP发送方将只看到混频器接收到的其流的接收质量。
The mixer must forward RTCP source description (SDES) and BYE packets from the receiver to the sender and may forward them in inverse direction as defined in Section 7.3 of [RFC3550].
混音器必须将RTCP源描述（SDES）和BYE数据包从接收器转发到发送器，并可按照[RFC3550]第7.3节中的定义反向转发。
Once the mixer receives an RTP/Audio-Visual Profile with Feedback (AVPF) [RFC4585] transport-layer feedback packet, it must handle it carefully, as the feedback packet may contain the information of the content that comes from different RTP senders. In this case, the mixer needs to divide the feedback packet into two separate feedback packets and process the information in the feedback control information (FCI) in the two feedback packets, just as in the RTCP report process described above.
一旦混音器接收到带有反馈（AVPF）[RFC4585]传输层反馈数据包的RTP/视听配置文件，它必须小心处理，因为反馈数据包可能包含来自不同RTP发送者的内容信息。在这种情况下，混频器需要将反馈分组划分为两个单独的反馈分组，并处理两个反馈分组中的反馈控制信息（FCI）中的信息，就像在上述RTCP报告处理中一样。
If the substitutive content comes from local media file storage (i.e., the mixer can be regarded as the substitutive RTP sender), any RTCP packets received from downstream related to the substitutive content must be terminated on the mixer without any further processing.
如果替代内容来自本地媒体文件存储（即，混合器可被视为替代RTP发送器），则从下游接收的与替代内容相关的任何RTCP包必须在混合器上终止，而无需任何进一步处理。
This section provides informative guidelines on how to handle media substitution at the RTP layer to minimize media impact. Dealing well with the media substitution at the RTP layer is necessary for quality implementations. To perfectly erase any media impact needs more considerations at the higher layers. How the media substitution is erased at the higher layers is outside of the scope of this memo.
本节提供了有关如何在RTP层处理介质替换以最小化介质影响的信息性指南。在RTP层处理好媒体替换对于高质量的实现是必要的。要完全擦除任何介质影响，需要在更高的层上进行更多的考虑。如何在更高层擦除介质替换不在本备忘录范围内。
If the time duration for any substitutive content mismatches, i.e., shorter or longer than the duration of the main content to be replaced, then media degradations may occur at the splicing point and thus impact the user's experience.
如果任何替代内容的持续时间不匹配，即短于或长于要替换的主内容的持续时间，则媒体降级可能发生在拼接点，从而影响用户体验。
If the substitutive content has shorter duration from the main content, then there could be a gap in the output RTP stream. The RTP sequence number will be contiguous across this gap, but there will be an unexpected jump in the RTP timestamp. Such a gap would cause the receiver to have nothing to play. This may be unavoidable, unless the mixer can adjusts the splice in or splice out point to compensate. This assumes the splicing mixer can send more of the main RTP stream in place of the shorter substitutive stream or vary
如果替代内容与主内容的持续时间较短，则输出RTP流中可能存在间隙。RTP序列号将在该间隙中连续，但RTP时间戳中会出现意外跳转。这样的间隙将导致接收器无法播放。这可能是不可避免的，除非混音器可以调整拼接输入或拼接输出点以进行补偿。这假设拼接混合器可以发送更多的主RTP流来代替较短的替代流或改变
the length of the substitutive content. It is the responsibility of the higher-layer protocols and the media providers to ensure that the substitutive content is of very similar duration as the main content to be replaced.
替代内容的长度。高层协议和媒体提供商有责任确保替换内容的持续时间与要替换的主要内容非常相似。
If the substitute content has longer duration than the reserved gap duration, there will be an overlap between the substitutive RTP stream and the main RTP stream at the splicing-out point. A straightforward approach is that the mixer performs an ungraceful action and terminates the splicing and switches back to the main RTP stream even if this may cause media stuttering on the receiver. Alternatively, the mixer may transcode the substitutive content to play at a faster rate than normal, to adjust it to the length of the gap in the main content and generate a new RTP stream for the transcoded content. This is a complex operation and very specific to the content and media codec used. Additional approaches exist; these types of issues should be taken into account in both mixer implementors and media generators to enable smooth substitutions.
如果替代内容的持续时间比保留间隙持续时间长，则替代RTP流和主RTP流在拼接输出点之间将存在重叠。一种简单的方法是，混频器执行非竞争性操作，终止拼接并切换回主RTP流，即使这可能会导致接收器上的媒体口吃。或者，混频器可以对替代内容进行转码，以比正常情况更快的速率播放，以将其调整到主内容中的间隙长度，并为转码后的内容生成新的RTP流。这是一个复杂的操作，并且非常特定于所使用的内容和媒体编解码器。还有其他办法；混音器实现者和媒体生成器都应该考虑这些类型的问题，以实现平滑替换。
If the substitutive content has somewhat different characteristics from the main content it replaces, or if the substitutive content is encoded with a different codec or has different encoding bitrate, it might overload the network and might cause network congestion on the path between the mixer and the RTP receiver(s) that would not have been caused by the main content.
如果替代内容与它所替换的主内容具有一些不同的特征，或者如果替代内容使用不同的编解码器进行编码或具有不同的编码比特率，则它可能会使网络过载，并可能导致混音器和RTP接收器之间的路径上的网络拥塞这不是主要内容造成的。
To be robust to network congestion and packet loss, a mixer that is performing splicing must continuously monitor the status of a downstream network by monitoring any of the following RTCP reports that are used:
为了对网络拥塞和数据包丢失具有鲁棒性，正在执行拼接的混频器必须通过监视使用的以下任一RTCP报告来持续监视下游网络的状态：
1. RTCP receiver reports indicate packet loss [RFC3550].
1. RTCP接收器报告表明数据包丢失[RFC3550]。
2. RTCP NACKs for lost packet recovery [RFC4585].
2. 用于丢失数据包恢复的RTCP NACK[RFC4585]。
3. RTCP Explicit Congestion Notification (ECN) Feedback information [RFC6679].
3. RTCP显式拥塞通知（ECN）反馈信息[RFC6679]。
Once the mixer detects congestion on its downstream link, it will treat these reports as follows:
一旦混频器检测到其下游链路上的拥塞，它将按如下方式处理这些报告：
1. If the mixer receives the RTCP receiver reports with packet loss indication, it will forward the reports to the substitutive RTP sender or the main RTP sender as described in Section 4.2.
1. 如果混音器接收到带有丢包指示的RTCP接收器报告，它将按照第4.2节所述将报告转发给替代RTP发送器或主RTP发送器。
2. If mixer receives the RTCP NACK packets defined in [RFC4585] from the RTP receiver for packet loss recovery, it first identifies the content category of lost packets to which the NACK corresponds. Then, the mixer will generate new RTCP NACKs for the lost packets with its own SSRC and make corresponding changes to their sequence numbers to match original, pre-spliced, packets. If the lost substitutive content comes from local media file storage, the mixer acting as the substitutive RTP sender will directly fetch the lost substitutive content and retransmit it to the RTP receiver. The mixer may buffer the sent RTP packets and do the retransmission.
2. 如果混频器从RTP接收器接收[RFC4585]中定义的RTCP NACK数据包以进行数据包丢失恢复，则它首先识别NACK对应的丢失数据包的内容类别。然后，混频器将使用自己的SSRC为丢失的数据包生成新的RTCP NACK，并对其序列号进行相应更改，以匹配原始的预拼接数据包。如果丢失的替代内容来自本地媒体文件存储，则作为替代RTP发送方的混合器将直接获取丢失的替代内容并将其重新传输到RTP接收器。混频器可以缓冲发送的RTP分组并进行重传。
It is somewhat complex that the lost packets requested in a single RTCP NACK message not only contain the main content but also the substitutive content. To address this, the mixer must divide the RTCP NACK packet into two separate RTCP NACK packets: one requests for the lost main content, and another requests for the lost substitutive content.
在单个RTCP NACK消息中请求的丢失数据包不仅包含主要内容，而且还包含替代内容，这有点复杂。为了解决这个问题，混音器必须将RTCP NACK数据包分成两个单独的RTCP NACK数据包：一个请求丢失的主内容，另一个请求丢失的替代内容。
3. If an ECN-aware mixer receives RTCP ECN feedback (RTCP ECN feedback packets or RTCP XR summary reports) defined in [RFC6679] from the RTP receiver, it must process them in a similar way to the RTP/AVPF feedback packet or RTCP XR process described in Section 4.2 of this memo.
3. 如果ECN感知混音器从RTP接收器接收到[RFC6679]中定义的RTCP ECN反馈（RTCP ECN反馈数据包或RTCP XR摘要报告），则其处理方式必须与本备忘录第4.2节所述的RTP/AVPF反馈数据包或RTCP XR处理方式类似。
These three methods require the mixer to run a congestion control loop and bitrate adaptation between itself and the RTP receiver. The mixer can thin or transcode the main RTP stream or the substitutive RTP stream, but such operations are very inefficient and difficult, and they also bring undesirable delay. Fortunately, as noted in this memo, the mixer acting as a splicer can rewrite the RTCP packets sent from the RTP receiver and forward them to the RTP sender, thus letting the RTP sender knows that congestion is being experienced on the path between the mixer and the RTP receiver. Then, the RTP sender applies its congestion control algorithm and reduces the media bitrate to a value that is in compliance with congestion control principles for the slowest link. The congestion control algorithm may be a TCP-friendly bitrate adaptation algorithm specified in [RFC5348] or a Datagram Congestion Control Protocol (DCCP) congestion control algorithm defined in [RFC5762].
这三种方法要求混频器在自身和RTP接收机之间运行拥塞控制环路和比特率自适应。混频器可以对主RTP流或替代RTP流进行细化或转码，但此类操作效率低且困难，并且还带来不希望的延迟。幸运的是，如本备忘录所述，作为拼接器的混音器可以重写从RTP接收器发送的RTCP数据包，并将其转发给RTP发送器，从而让RTP发送器知道混音器和RTP接收器之间的路径正在经历拥塞。然后，RTP发送方应用其拥塞控制算法，并将媒体比特率降低到符合最慢链路的拥塞控制原则的值。拥塞控制算法可以是[RFC5348]中指定的TCP友好比特率自适应算法或[RFC5762]中定义的数据报拥塞控制协议（DCCP）拥塞控制算法。
If the substitutive content comes from local media file storage, the mixer must directly reduce the bitrate as if it were the substitutive RTP sender.
如果替代内容来自本地媒体文件存储，混音器必须直接降低比特率，就像它是替代RTP发送器一样。
From the above analysis, to reduce the risk of congestion and maintain the bandwidth consumption stable over time, the substitutive RTP stream is recommended to be encoded at an appropriate bitrate to match that of the main RTP stream. If the substitutive RTP stream comes from the substitutive RTP sender, this sender should have some knowledge about the media encoding bitrate of the main content in advance. Acquiring such knowledge is out of scope in this document.
根据以上分析，为了降低拥塞风险并保持带宽消耗随时间的稳定，建议以适当的比特率对替代RTP流进行编码，以匹配主RTP流的比特率。如果替代RTP流来自替代RTP发送方，则该发送方应提前了解主要内容的媒体编码比特率。获取此类知识超出了本文件的范围。
If it is desirable to prevent receivers from detecting that splicing is occurring at the RTP layer, the mixer must not include a CSRC list in outgoing RTP packets and must not forward RTCP messages from the main RTP sender or from the substitutive RTP sender. Due to the absence of a CSRC list in the output RTP stream, the RTP receiver only initiates SDES, BYE, and Application-specific functions (APP) packets to the mixer without any knowledge of the main RTP sender and the substitutive RTP sender.
如果希望防止接收机检测到在RTP层发生拼接，则混音器不得在传出RTP分组中包括CSC列表，并且不得转发来自主RTP发送方或替代RTP发送方的RTCP消息。由于在输出RTP流中没有csc列表，RTP接收器仅向混合器发起sde、BYE和应用特定功能（APP）分组，而不知道主RTP发送器和替代RTP发送器。
The CSRC list identifies the contributing sources; these SSRC identifiers of contributing sources are kept globally unique for each RTP session. The uniqueness of the SSRC identifier is used to resolve collisions and to detect RTP-level forwarding loops as defined in Section 8.2 of [RFC3550]. A danger that loops involving those contributing sources will not be detected will be created by the absence of a CSRC list in this case. The loops could occur if either the mixer is misconfigured to form a loop or a second mixer/translator is added, causing packets to loop back to upstream of the original mixer. An undetected RTP packet loop is a serious denial-of-service threat, which can consume all available bandwidth or mixer processing resources until the looped packets are dropped as a result of congestion. So, non-RTP means must be used to detect and resolve loops if the mixer does not add a CSRC list.
中国证监会名单确定了出资来源；对于每个RTP会话，贡献源的这些SSRC标识符保持全局唯一。SSRC标识符的唯一性用于解决冲突和检测[RFC3550]第8.2节中定义的RTP级转发循环。在这种情况下，如果没有中国证监会的名单，将产生涉及这些贡献来源的循环无法被发现的危险。如果混频器被错误配置为形成循环，或者添加了第二个混频器/转换器，导致数据包循环回原始混频器的上游，则可能发生循环。未检测到的RTP数据包循环是一种严重的拒绝服务威胁，它会消耗所有可用带宽或混频器处理资源，直到由于拥塞而丢弃循环数据包。因此，如果混音器没有添加CSC列表，则必须使用非RTP方法来检测和解析循环。
When the mixer is used to handle RTP splicing, the RTP receiver does not need any RTP/RTCP extension for splicing. As a trade-off, additional overhead could be induced on the mixer, which uses its own sequence number space and timing model. So the mixer will rewrite the RTP sequence number and timestamp, whatever splicing is active or not, and generate RTCP flows for both sides. In case the mixer serves multiple main RTP streams simultaneously, this may lead to more overhead on the mixer.
当混频器用于处理RTP拼接时，RTP接收器不需要任何RTP/RTCP扩展进行拼接。作为权衡，混频器可能会产生额外的开销，它使用自己的序列号空间和时序模型。因此，混频器将重写RTP序列号和时间戳，无论拼接是否活动，并为两侧生成RTCP流。如果混频器同时服务于多个主RTP流，这可能导致混频器上的更多开销。
If an undetectable splicing requirement is required, the CSRC list is not included in the outgoing RTP packet; this brings a potential issue with loop detection as briefly described in Section 4.5.
如果需要不可检测的拼接要求，则CSC列表不包括在传出RTP数据包中；如第4.5节所述，这给环路检测带来了一个潜在问题。
The splicing application is subject to the general security considerations of the RTP specification [RFC3550].
拼接应用程序应符合RTP规范[RFC3550]的一般安全考虑。
The mixer acting as splicer replaces some content with other content in RTP packets, thus breaking any RTP-level end-to-end security, such as integrity protection and source authentication. Thus, any RTP-level or outside security mechanism, such as IPsec [RFC4301] or Datagram Transport Layer Security [RFC6347], will use a security association between the splicer and the receiver. When using the Secure Real-Time Transport Protocol (SRTP) [RFC3711], the splicer could be provisioned with the same security association as the main RTP sender. Using a limitation in the SRTP security services regarding source authentication, the splicer can modify and re-protect the RTP packets without enabling the receiver to detect if the data comes from the original source or from the splicer.
充当拼接器的混合器用RTP数据包中的其他内容替换某些内容，从而破坏任何RTP级别的端到端安全性，如完整性保护和源身份验证。因此，任何RTP级别或外部安全机制，如IPsec[RFC4301]或数据报传输层安全[RFC6347]，都将在拼接器和接收器之间使用安全关联。当使用安全实时传输协议（SRTP）[RFC3711]时，可以为拼接器提供与主RTP发送器相同的安全关联。使用SRTP安全服务中关于源认证的限制，拼接器可以修改和重新保护RTP分组，而不使接收器能够检测数据是来自原始源还是来自拼接器。
Security goals to have source authentication all the way from the RTP main sender to the receiver through the splicer is not possible with splicing and any existing solutions. A new solution can theoretically be developed that enables identifying the participating entities and what each provides, i.e., the different media sources, main and substituting, and the splicer providing the RTP-level integration of the media payloads in a common timeline and synchronization context. Such a solution would obviously not meet REQ-7 and will be detectable on the RTP level.
从RTP主发送方到接收方，通过拼接器进行源身份验证的安全目标在拼接和任何现有解决方案中都是不可能实现的。理论上可以开发一种新的解决方案，该解决方案能够识别参与实体和每个实体提供的内容，即不同的媒体源、主媒体源和替代媒体源，以及在公共时间线和同步上下文中提供媒体有效负载RTP级集成的拼接器。这种解决方案显然不符合REQ-7的要求，并且在RTP级别上可以检测到。
The nature of this RTP service offered by a network operator employing a content splicer is that the RTP-layer security relationship is between the receiver and the splicer, and between the sender and the splicer, but is not end-to-end between the receiver and the sender. This appears to invalidate the undetectability goal, but in the common case, the receiver will consider the splicer as the main media source.
由使用内容拼接器的网络运营商提供的这种RTP服务的性质是，RTP层安全关系在接收方和拼接器之间，以及发送方和拼接器之间，但在接收方和发送方之间不是端到端的。这似乎无效的目标，但在一般情况下，接收器将考虑捻接器作为主要媒体来源。
Some RTP deployments use RTP payload security mechanisms (e.g., ISMACryp [ISMACryp]). If any payload internal security mechanisms are used, only the RTP sender and the RTP receiver establish that security context, in which case any middlebox (e.g., splicer) between the RTP sender and the RTP receiver will not get such keying material. This may impact the splicer's ability to perform splicing if it is dependent on RTP payload-level hints for finding the splice in and out points. However, other potential solutions exist to
一些RTP部署使用RTP有效负载安全机制（例如ISMACryp[ISMACryp]）。如果使用任何有效负载内部安全机制，则只有RTP发送方和RTP接收方建立该安全上下文，在这种情况下，RTP发送方和RTP接收方之间的任何中间盒（例如，拼接器）将不会获得此类密钥材料。这可能会影响拼接器执行拼接的能力，如果它依赖于RTP有效负载级别提示来查找拼接输入和输出点。然而，还存在其他可能的解决办法
specify or mark where the splicing points exist in the media streams. When using RTP payload security mechanisms, SRTP or other security mechanisms at RTP or lower layers can be used to provide integrity and source authentication between the splicer and the RTP receiver.
指定或标记媒体流中存在拼接点的位置。当使用RTP有效负载安全机制时，SRTP或RTP或更低层的其他安全机制可用于在拼接器和RTP接收器之间提供完整性和源认证。
The following individuals have reviewed the earlier versions of this specification and provided very valuable comments: Colin Perkins, Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R. Oran, Cullen Jennings, Ali C. Begen, Charles Eckel, and Ning Zong.
以下人员审查了本规范的早期版本，并提供了非常有价值的意见：科林·珀金斯、马格努斯·韦斯特隆德、甚至罗尼、汤姆·范·凯恩杰、约尔格·奥特、大卫·R·奥兰、卡伦·詹宁斯、阿里·C·贝根、查尔斯·埃克尔和宁宗。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, August 2012.
[RFC6679]Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，RFC 6679，2012年8月。
[ISMACryp] Internet Streaming Media Alliance (ISMA), "ISMA Encryption and Authentication Specification 2.0", November 2007.
[ISMACryp]互联网流媒体联盟（ISMA），“ISMA加密和认证规范2.0”，2007年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, April 2010.
[RFC5762]Perkins，C.，“RTP和数据报拥塞控制协议（DCCP）”，RFC 5762，2010年4月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[SCTE30] Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Splicing API", 2009.
[SCTE30]电缆通信工程师协会（SCTE），“数字程序插入拼接API”，2009年。
[SCTE35] Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Cueing Message for Cable", 2011.
[SCTE35]电缆通信工程师协会（SCTE），“电缆数字节目插入提示信息”，2011年。
Both a translator and mixer can realize splicing by changing a set of RTP parameters.
转换器和混频器都可以通过改变一组RTP参数来实现拼接。
A translator has no SSRC; hence it is transparent to the RTP sender and receiver. Therefore, the RTP sender sees the full path to the receiver when the translator is passing its content. When a translator inserts the substitutive content, the RTP sender could get a report on the path up to the translator itself. Additionally, if splicing does not occur yet, the translator does not need to rewrite the RTP header, and the overhead on the translator can be avoided.
译者没有SSRC；因此，它对RTP发送方和接收方是透明的。因此，当翻译器传递其内容时，RTP发送方会看到到接收方的完整路径。当翻译人员插入替代内容时，RTP发送者可以在通往翻译人员自身的路径上获得报告。此外，如果尚未发生拼接，则转换器不需要重写RTP头，并且可以避免转换器上的开销。
If a mixer is used to do splicing, it can also allow the RTP sender to learn the situation of its content on the receiver or on the mixer just like the translator does, which is specified in Section 4.2. Compared to the translator, the mixer's outstanding benefit is that it is pretty straightforward to do with RTCP messages, for example, bit-rate adaptation to handle varying network conditions. But the translator needs more considerations, and its implementation is more complex.
如果使用混音器进行拼接，它还可以让RTP发送者像翻译人员一样了解其内容在接收器或混音器上的情况，这在第4.2节中有规定。与转换器相比，混频器的突出优点是，处理RTCP消息非常简单，例如，比特率自适应以处理不同的网络条件。但是翻译器需要更多的考虑，并且它的实现更加复杂。
From the above analysis, both the translator and mixer have their own advantages: less overhead or less complexity on handling RTCP. After long and sophisticated discussions, the avtext WG members decided that they prefer less complexity rather than less overhead and are inclined to choose a mixer to do splicing.
从上面的分析来看，转换器和混频器都有各自的优势：处理RTCP的开销更小或复杂性更低。经过长时间复杂的讨论后，avtext工作组成员决定，他们更喜欢低复杂性而不是低开销，并且倾向于选择混音器进行拼接。
If one chooses a mixer as splicer, the overhead on the mixer must be taken into account even if the splicing has not occurred yet.
如果选择混频器作为拼接器，即使尚未进行拼接，也必须考虑混频器的开销。
Author's Address
作者地址
Jinwei Xia Huawei Software No.101 Nanjing, Yuhuatai District 210012 China
中国南京雨花台区金威夏华为软件101号210012
Phone: +86-025-86622310
EMail: xiajinwei@huawei.com
Phone: +86-025-86622310
EMail: xiajinwei@huawei.com