Internet Engineering Task Force (IETF) B. Burman
Request for Comments: 7728 A. Akram
Updates: 5104 Ericsson
Category: Standards Track R. Even
ISSN: 2070-1721 Huawei Technologies
M. Westerlund
Ericsson
February 2016
Internet Engineering Task Force (IETF) B. Burman
Request for Comments: 7728 A. Akram
Updates: 5104 Ericsson
Category: Standards Track R. Even
ISSN: 2070-1721 Huawei Technologies
M. Westerlund
Ericsson
February 2016
RTP Stream Pause and Resume
RTP流暂停和恢复
Abstract
摘要
With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real-time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104.
随着实时多媒体应用的日益普及，人们希望提供对资源使用的良好控制，用户也要求对通信会话进行更多的控制。本文档描述了在使用实时传输协议（RTP）进行实时数据传输时，多媒体会话中的接收者如何通过发送实时反馈消息来暂停和恢复来自发送者的传入数据。本文档扩展了编解码器控制消息（CCM）RTP控制协议（RTCP）反馈包，明确允许和描述现有CCM的具体使用，并添加一组用于暂停和恢复RTP数据流的新实时反馈消息。本文件更新了RFC 5104。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7728.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7728.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 8
3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 9
3.3. RTP Mixer to Media Sender in Point to Multipoint . . . . 10
3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 11
3.5. Media Receiver to Media Sender across RTP Mixer . . . . . 11
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
4.1. Real-Time Nature . . . . . . . . . . . . . . . . . . . . 12
4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 12
4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12
4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 13
4.6. Request Retransmission . . . . . . . . . . . . . . . . . 14
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 14
4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 14
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 16
5.2. PauseID . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Requesting to Pause . . . . . . . . . . . . . . . . . . . 17
5.4. Media Sender Pausing . . . . . . . . . . . . . . . . . . 18
5.5. Requesting to Resume . . . . . . . . . . . . . . . . . . 19
5.6. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 20
6. Participant States . . . . . . . . . . . . . . . . . . . . . 22
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 22
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 23
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 24
6.3.2. SSRC Time-Out . . . . . . . . . . . . . . . . . . . . 24
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 24
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 26
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 32
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 37
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 8
3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 9
3.3. RTP Mixer to Media Sender in Point to Multipoint . . . . 10
3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 11
3.5. Media Receiver to Media Sender across RTP Mixer . . . . . 11
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
4.1. Real-Time Nature . . . . . . . . . . . . . . . . . . . . 12
4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 12
4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12
4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 13
4.6. Request Retransmission . . . . . . . . . . . . . . . . . 14
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 14
4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 14
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 16
5.2. PauseID . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Requesting to Pause . . . . . . . . . . . . . . . . . . . 17
5.4. Media Sender Pausing . . . . . . . . . . . . . . . . . . 18
5.5. Requesting to Resume . . . . . . . . . . . . . . . . . . 19
5.6. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 20
6. Participant States . . . . . . . . . . . . . . . . . . . . . 22
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 22
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 23
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 24
6.3.2. SSRC Time-Out . . . . . . . . . . . . . . . . . . . . 24
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 24
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 26
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 32
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 37
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 39
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 40
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 41
10.3. Point to Multipoint Using Mixer . . . . . . . . . . . . 45
10.4. Point to Multipoint Using Translator . . . . . . . . . . 47
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.1. Normative References . . . . . . . . . . . . . . . . . . 52
13.2. Informative References . . . . . . . . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 40
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 41
10.3. Point to Multipoint Using Mixer . . . . . . . . . . . . 45
10.4. Point to Multipoint Using Translator . . . . . . . . . . 47
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.1. Normative References . . . . . . . . . . . . . . . . . . 52
13.2. Informative References . . . . . . . . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
As real-time communication attracts more people, more applications are created; multimedia conversation applications is one example. Multimedia conversation further exists in many forms, for example, peer-to-peer chat application and multiparty video conferencing controlled by central media nodes, such as RTP Mixers.
随着实时通信吸引了更多的人，创造了更多的应用程序；多媒体对话应用就是一个例子。多媒体会话还以多种形式存在，例如，点对点聊天应用程序和由中央媒体节点（如RTP混音器）控制的多方视频会议。
Multimedia conferencing may involve many participants; each has its own preferences for the communication session, not only at the start but also during the session. This document describes several scenarios in multimedia communication where a conferencing node or participant chooses to temporarily pause an incoming RTP [RFC3550] stream and later resume it when needed. The receiver does not need to terminate or inactivate the RTP session and start all over again by negotiating the session parameters, for example, using SIP [RFC3261] with the Session Description Protocol (SDP) [RFC4566] offer/answer [RFC3264].
多媒体会议可能涉及许多参与者；对于通信会话，每个会话都有自己的首选项，不仅在开始时，而且在会话期间。本文档描述了多媒体通信中的几种场景，其中会议节点或参与者选择暂时暂停传入的RTP[RFC3550]流，然后在需要时恢复该流。接收机不需要通过协商会话参数来终止或停用RTP会话并重新开始，例如，使用会话描述协议（SDP）[RFC4566]提供/应答[RFC3264]的SIP[RFC3261]。
Centralized nodes, like RTP Mixers or Multipoint Control Units (MCUs) that use either logic based on voice activity, other measurements, or user input could reduce the resources consumed in both the sender and the network by temporarily pausing the RTP streams that aren't required by the RTP Mixer. If the number of conference participants are greater than what the conference logic has chosen to present simultaneously to receiving participants, some participant RTP streams sent to the RTP Mixer may not need to be forwarded to any other participant. Those RTP streams could then be temporarily paused. This becomes especially useful when the media sources are provided in multiple encoding versions (Simulcast) [SDP-SIMULCAST] or with Multi-Session Transmission (MST) of scalable encoding such as Scalable Video Coding (SVC) [RFC6190]. There may be some of the
集中式节点，如使用基于语音活动、其他测量或用户输入的逻辑的RTP混频器或多点控制单元（MCU），可以通过临时暂停RTP混频器不需要的RTP流来减少发送器和网络中消耗的资源。如果会议参与者的数量大于会议逻辑选择同时呈现给接收参与者的数量，则发送到RTP混合器的一些参与者RTP流可能不需要转发给任何其他参与者。然后可以暂时暂停这些RTP流。当媒体源以多个编码版本（Simulcast）[SDP-Simulcast]或可伸缩编码的多会话传输（MST）（例如可伸缩视频编码（SVC）[RFC6190]提供时，这变得特别有用。可能有一些
defined encodings or a combination of scalable layers that are not used or cannot be used all of the time. As an example, a centralized node may choose to pause such unused RTP streams without being explicitly requested to do so, maybe due to temporarily limited network or processing resources. It may then also send an explicit indication that the streams are paused.
未使用或不能一直使用的已定义编码或可伸缩层的组合。例如，可能由于暂时有限的网络或处理资源，集中式节点可以选择暂停此类未使用的RTP流而不被明确请求这样做。然后，它还可以发送流暂停的明确指示。
As the set of RTP streams required at any given point in time is highly dynamic in such scenarios, using the out-of-band signaling channel for pausing, and even more importantly resuming, an RTP stream is difficult due to the performance requirements. Instead, the pause and resume signaling should be in the media plane and go directly between the affected nodes. When using RTP [RFC3550] for media transport, using "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] appears appropriate. No currently existing RTCP feedback message explicitly supports pausing and resuming an incoming RTP stream. As this affects the generation of packets and may even allow the encoding process to be paused, the functionality appears to match Codec Control Messages (CCMs) in the RTP Audio-Visual Profile with Feedback (AVPF) [RFC5104]. This document defines the solution as a CCM extension.
由于在任何给定时间点所需的RTP流集在此类场景中是高度动态的，因此使用带外信令信道进行暂停，甚至更重要的是恢复，由于性能要求，RTP流是困难的。相反，暂停和恢复信令应该在媒体平面中，并直接在受影响的节点之间传递。当使用RTP[RFC3550]进行媒体传输时，使用“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”[RFC4585]似乎是合适的。当前没有任何现有RTCP反馈消息明确支持暂停和恢复传入RTP流。由于这会影响数据包的生成，甚至可能允许暂停编码过程，因此该功能似乎与RTP视听配置文件中的编解码器控制消息（CCM）与反馈（AVPF）[RFC5104]相匹配。本文档将解决方案定义为CCM扩展。
The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is used by video conferencing systems for flow control. It is desirable to be able to use that method with a bitrate value of zero for pause, whenever possible. This specification updates RFC 5104 by adding the new pause and resume semantics to the TMMBR and Temporary Maximum Media Bitrate Notification (TMMBN) messages.
CCM的临时最大媒体比特率请求（TMMBR）消息由视频会议系统用于流控制。在可能的情况下，最好能够使用比特率值为零的暂停方法。本规范通过向TMMBR和临时最大媒体比特率通知（TMMBN）消息添加新的暂停和恢复语义来更新RFC 5104。
AVPF: Audio-Visual Profile with Feedback (RFC 4585)
AVPF：带反馈的视听配置文件（RFC 4585）
CCM: Codec Control Message (RFC 5104)
CCM：编解码器控制消息（RFC 5104）
CNAME: Canonical Name (RTCP Source Description)
CNAME:规范名称（RTCP源描述）
CSRC: Contributing Source (RTP)
中国证监会：出资来源（RTP）
FCI: Feedback Control Information (AVPF)
FCI：反馈控制信息（AVPF）
FIR: Full Intra Refresh (CCM)
FIR：完全帧内刷新（CCM）
FMT: Feedback Message Type (AVPF)
FMT：反馈消息类型（AVPF）
MCU: Multipoint Control Unit
多点控制单元
MTU: Maximum Transfer Unit
最大传输单位
PT: Payload Type (RTP)
PT：有效负载类型（RTP）
RTP: Real-time Transport Protocol (RFC 3550)
RTP：实时传输协议（RFC3550）
RTCP: RTP Control Protocol (RFC 3550)
RTCP:RTP控制协议（RFC3550）
RTCP RR: RTCP Receiver Report
RTCP RR:RTCP接收器报告
RTCP SR: RTCP Sender Report
RTCP SR:RTCP发送方报告
SDP: Session Description Protocol (RFC 4566)
会话描述协议（RFC4566）
SIP: Session Initiation Protocol (RFC 3261)
会话启动协议（RFC3261）
SSRC: Synchronization Source (RTP)
SSRC：同步源（RTP）
SVC: Scalable Video Coding
可伸缩视频编码
TMMBR: Temporary Maximum Media Bitrate Request (CCM)
TMMBR：临时最大媒体比特率请求（CCM）
TMMBN: Temporary Maximum Media Bitrate Notification (CCM)
TMMBN：临时最大媒体比特率通知（CCM）
UA: User Agent (SIP)
用户代理（SIP）
UDP: User Datagram Protocol (RFC 768)
UDP：用户数据报协议（RFC 768）
In addition to the following, the definitions from RTP [RFC3550], AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy [RFC7656] also apply in this document.
除以下内容外，RTP[RFC3550]、AVPF[RFC4585]、CCM[RFC5104]和RTP分类法[RFC7656]中的定义也适用于本文件。
Feedback Messages: CCM [RFC5104] categorized different RTCP feedback messages into four types: Request, Command, Indication, and Notification. This document places the PAUSE and RESUME messages into the Request category, PAUSED as an Indication, and REFUSED as a Notification.
反馈消息：CCM[RFC5104]将不同的RTCP反馈消息分为四种类型：请求、命令、指示和通知。本文档将暂停和恢复消息放入请求类别，暂停作为指示，拒绝作为通知。
PAUSE: Request from an RTP stream receiver to pause a stream
暂停：来自RTP流接收器的暂停流的请求
RESUME: Request from an RTP stream receiver to resume a paused stream
RESUME：RTP流接收器请求恢复暂停的流
PAUSED: Indication from an RTP stream sender that a stream is paused
暂停：RTP流发送器指示流已暂停
REFUSED: Notification from an RTP stream sender that a PAUSE or RESUME request will not be honored
拒绝：来自RTP流发送方的暂停或恢复请求将不被接受的通知
Mixer: The intermediate RTP node that receives an RTP stream from different endpoints, combines them to make one RTP stream, and forwards them to destinations, in the sense described for Topo-Mixer in "RTP Topologies" [RFC7667].
混合器：从不同端点接收RTP流的中间RTP节点，将它们组合成一个RTP流，并将它们转发到目的地，正如“RTP拓扑”中描述的拓扑混合器[RFC7667]。
Participant: A member that is part of an RTP session, acting as the receiver, sender, or both.
参与者：作为RTP会话一部分的成员，充当接收方、发送方或两者。
Paused sender: An RTP stream sender that has stopped its transmission, i.e., no other participant receives its RTP transmission, based on having received either a PAUSE request, defined in this specification, or a local decision.
暂停发送方：已停止其传输的RTP流发送方，即，没有其他参与者接收其RTP传输，基于已接收本规范中定义的暂停请求或本地决定。
Pausing receiver: An RTP stream receiver that sends a PAUSE request, defined in this specification, to another participant(s).
Pausing receiver：一个RTP流接收器，它向另一个参与者发送本规范中定义的暂停请求。
Stream: Used as a short term for RTP stream, unless otherwise noted.
流：用作RTP流的短期术语，除非另有说明。
Stream receiver: Short for RTP stream receiver; the RTP entity responsible for receiving an RTP stream, usually a Media Depacketizer.
流接收器：RTP流接收器的简称；负责接收RTP流的RTP实体，通常是媒体解包器。
Stream sender: Short for RTP stream sender; the RTP entity responsible for creating an RTP stream, usually a Media Packetizer.
流发送器：RTP流发送器的简称；负责创建RTP流的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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
This section discusses the main use cases for RTP stream pause and resume.
本节讨论RTP流暂停和恢复的主要用例。
The RTCWEB WG's use case and requirements document [RFC7478] defines the following API requirements in Appendix A, which is also used by the W3C WebRTC WG:
RTCWEB工作组的用例和要求文件[RFC7478]在附录A中定义了以下API要求，W3C WebRTC工作组也使用了这些要求：
A8 The web API must provide means for the web application to mute/ unmute a stream or stream component(s). When a stream is sent to a peer, mute status must be preserved in the stream received by the peer.
A8 web API必须为web应用程序提供静音/取消静音流或流组件的方法。当流被发送到对等方时，对等方接收的流中必须保持静音状态。
A9 The web API must provide means for the web application to cease the sending of a stream to a peer.
A9 web API必须为web应用程序提供停止向对等方发送流的方法。
This document provides means to optimize transport usage by stopping the sending of muted streams and starting the sending of streams again when unmuted. Here, it is assumed that "mute" above can be taken to apply also to media other than audio. At the time of publication for this specification, the RTCWEB WG did not specify any pause/resume functionality.
本文档提供了通过停止发送静音流并在取消静音时再次开始发送流来优化传输使用的方法。这里，假设上述“静音”也适用于音频以外的媒体。在本规范发布时，RTCWEB工作组未指定任何暂停/恢复功能。
This is the most basic use case with an RTP session containing two endpoints. Each endpoint sends one or more streams.
这是包含两个端点的RTP会话的最基本用例。每个端点发送一个或多个流。
+---+ +---+
| A |<------->| B |
+---+ +---+
+---+ +---+
| A |<------->| B |
+---+ +---+
Figure 1: Point to Point
图1：点对点
The usage of RTP stream pause in this use case is to temporarily halt delivery of streams that the sender provides but the receiver does not currently use. This can, for example, be due to minimized applications where the video stream is not actually shown on any display, or it is not used in any other way, such as being recorded. In this case, since there is only a single receiver of the stream, pausing or resuming a stream does not impact anyone else other than the sender and the single receiver of that stream.
在这个用例中，RTP流暂停的用法是暂时停止发送方提供但接收方当前不使用的流的传递。例如，这可归因于最小化的应用，其中视频流未实际显示在任何显示器上，或未以任何其他方式使用，例如被记录。在这种情况下，由于流只有一个接收者，因此暂停或恢复流不会影响该流的发送者和单个接收者以外的任何人。
One of the most commonly used topologies in centralized conferencing is based on the RTP Mixer [RFC7667]. The main reason for this is that it provides a very consistent view of the RTP session towards each participant. That is accomplished through the Mixer originating its own streams, identified by distinct SSRC values, and any RTP streams sent to the participants will be sent using those SSRC values. If the Mixer wants to identify the underlying media sources for its conceptual streams, it can identify them using CSRC. The stream the Mixer provides can be an actual mix of multiple media sources, but it might also be switching received streams as described in Sections 3.6 - 3.8 of "RTP Topologies" [RFC7667].
集中式会议中最常用的拓扑之一是基于RTP混频器[RFC7667]。这样做的主要原因是，它为每个参与者提供了一个非常一致的RTP会话视图。这是通过混频器来完成的，混频器产生自己的流，由不同的SSRC值标识，发送给参与者的任何RTP流都将使用这些SSRC值来发送。如果混音器想要识别其概念流的底层媒体源，它可以使用CSC来识别它们。混频器提供的流可以是多个媒体源的实际混合，但也可能是如“RTP拓扑”[RFC7667]第3.6-3.8节所述切换接收流。
+---+ +-----------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +-----------+ +---+
+---+ +-----------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +-----------+ +---+
Figure 2: RTP Mixer in Unicast Only
图2：仅单播中的RTP混频器
Which streams from clients B, C, and D that are delivered to a given receiver, A, can depend on several things:
从客户端B、C和D发送到给定接收器a的哪些流取决于以下几点：
o The RTP Mixer's own logic and measurements, such as voice activity on the incoming audio streams.
o RTP混音器自身的逻辑和测量，如传入音频流上的语音活动。
o The number of sent media sources exceed what is reasonable to present simultaneously at any given receiver.
o 发送的媒体源的数量超过了在任何给定接收器上同时显示的合理数量。
o A human controlling the conference that determines how the media should be mixed. This would be more common in lecture or similar applications where regular listeners may be prevented from breaking into the session unless approved by the moderator.
o 控制会议的人，决定媒体如何混合。这在讲座或类似的应用中更为常见，除非主持人批准，否则常规听众可能会被阻止进入会议。
o The streams may also be part of a Simulcast [SDP-SIMULCAST] or scalable encoded (for Multi-Session Transmission) [RFC6190], thus providing multiple versions that can be delivered by the RTP stream sender.
o 流还可以是同步广播[SDP-Simulcast]或可伸缩编码（用于多会话传输）[RFC6190]的一部分，从而提供可由RTP流发送方交付的多个版本。
These examples indicate that there are numerous reasons why a particular stream would not currently be in use but must be available for use at very short notice if any dynamic event occurs that causes a different stream selection to be done in the Mixer.
这些示例表明，有许多原因导致当前不会使用特定流，但如果发生导致在混合器中进行不同流选择的任何动态事件，则必须在非常短的时间内提供使用。
Because of this, it would be highly beneficial if the Mixer could request the RTP stream sender to pause a particular stream. The Mixer also needs to be able to request the RTP stream sender to resume delivery with minimal delay.
因此，如果混合器可以请求RTP流发送器暂停特定流，这将是非常有益的。混合器还需要能够请求RTP流发送器以最小的延迟恢复传送。
In some cases, especially when the Mixer sends multiple RTP streams per receiving client, there may be situations that make it desirable for the Mixer to pause some of its sent RTP streams, even without being explicitly asked to do so by the receiving client. Such situations can, for example, be caused by a temporary lack of available Mixer network or processing resources. An RTP stream receiver that no longer receives an RTP stream could interpret this as an error condition and try to take action to re-establish the RTP stream. Such action would likely be undesirable if the RTP stream was in fact deliberately paused by the Mixer. Undesirable RTP stream receiver actions could be avoided if the Mixer is able to explicitly indicate that an RTP stream is deliberately paused.
在某些情况下，尤其是当混合器在每个接收客户端发送多个RTP流时，可能存在使混合器暂停其发送的一些RTP流的情况，即使接收客户端没有明确要求这样做。例如，这种情况可能是由于暂时缺乏可用的混音器网络或处理资源造成的。不再接收RTP流的RTP流接收器可以将其解释为错误情况，并尝试采取措施重新建立RTP流。如果RTP流实际上是由混合器故意暂停的，那么这种操作可能是不可取的。如果混频器能够显式指示RTP流被故意暂停，则可以避免不希望的RTP流接收器动作。
Just as for point to point (Section 3.1), there is only a single receiver of the stream, the RTP Mixer, and pausing or resuming a stream does not affect anyone else other than the sender and single receiver of that stream.
正如点对点（第3.1节）一样，流只有一个接收器，即RTP混合器，暂停或恢复流不会影响该流的发送者和单个接收器以外的任何其他人。
This use case is similar to the previous section; however, the RTP Mixer is involved in three domains that need to be separated: the Multicast Network (including participants A and C), participant B, and participant D. The difference from above is that A and C share a multicast domain, which is depicted below.
此用例与上一节类似；然而，RTP混合器涉及三个需要分离的域：多播网络（包括参与者A和C）、参与者B和参与者D。与上述不同的是，A和C共享一个多播域，如下所示。
+-----+
+---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ cast +->| Mixer |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+
+-----+
+-----+
+---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ cast +->| Mixer |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+
+-----+
Figure 3: RTP Mixer in Point to Multipoint
图3：点对多点RTP混频器
If the RTP Mixer pauses a stream from A, it will not only pause the stream towards itself but will also stop the stream from arriving to C, which C is heavily impacted by, might not approve of, and should thus have a say on.
如果RTP混合器暂停来自a的流，它不仅会暂停流向自身的流，还会阻止流到达C，C受到严重影响，可能不赞成，因此应该有发言权。
If the Mixer resumes a paused stream from A, it will be resumed also towards C. In this case, if C is not interested, it can simply ignore the stream and is not impacted as much as above.
如果混频器从a恢复暂停的流，它也将向C恢复。在这种情况下，如果C不感兴趣，它可以简单地忽略该流，并且不会像上面那样受到影响。
In this use case, there are several receivers of a stream, and the Mixer must take special care so as not to pause a stream that is still wanted by some receivers.
在这个用例中，一个流有几个接收器，混合器必须特别小心，以免暂停一些接收器仍然需要的流。
In this use case, the direction of the request to pause is the opposite compared to the two previous use cases. An endpoint in Figure 2 could potentially request to pause the delivery of a given stream. Possible reasons include those in the point-to-point case (Section 3.1) above.
在这个用例中，暂停请求的方向与前面两个用例相反。图2中的端点可能会请求暂停给定流的交付。可能的原因包括上述点对点案例（第3.1节）中的原因。
When the RTP Mixer is only connected to individual unicast paths, the use case and any considerations are identical to the point-to-point use case.
当RTP混频器仅连接到单个单播路径时，用例和任何注意事项都与点对点用例相同。
However, when the endpoint requesting stream pause is connected to the RTP Mixer through a multicast network, such as A or C in Figure 3, the use case instead becomes identical to the one in Section 3.3, only with reverse direction of the streams and pause/ resume requests.
然而，当请求流暂停的端点通过多播网络（如图3中的a或C）连接到RTP混合器时，用例与第3.3节中的相同，只是流和暂停/恢复请求的方向相反。
An endpoint, like A in Figure 2, could potentially request to pause the delivery of a given stream, like one of B's, over any of the SSRCs used by the Mixer by sending a pause request for the CSRC identifying the stream. However, the authors are of the opinion that this is not a suitable solution for several reasons:
端点（如图2中的A）可以通过发送用于识别流的CSC的暂停请求，潜在地请求暂停给定流（如B中的一个）在混合器使用的任何SSRC上的交付。然而，作者认为这不是一个合适的解决方案，原因如下：
1. The Mixer might not include CSRC in its stream indications.
1. 混合器的流指示中可能不包含CSC。
2. An endpoint cannot rely on the CSRC to correctly identify the stream to be paused when the delivered media is some type of mix. A more elaborate stream identification solution is needed to support this in the general case.
2. 当交付的媒体是某种类型的混合媒体时，端点不能依靠CSC正确识别要暂停的流。在一般情况下，需要更详细的流标识解决方案来支持这一点。
3. The endpoint cannot determine if a given stream is still needed by the RTP Mixer to deliver to another session participant.
3. 端点无法确定RTP混合器是否仍需要给定流来传递给另一个会话参与者。
Due to the above reasons, we exclude this use case from further consideration.
由于上述原因，我们将此用例排除在进一步考虑之外。
This section describes the requirements that this specification needs to meet.
本节描述了本规范需要满足的要求。
The first section (Section 1) of this specification describes some possible reasons why a receiver may pause an RTP sender. Pausing and resuming is time dependent, i.e., a receiver may choose to pause an RTP stream for a certain duration, after which the receiver may want the sender to resume. This time dependency means that the messages related to pause and resume must be transmitted to the sender in a timely fashion in order for them to be purposeful. The pause operation is arguably not as time critical as the resume operation, since it mainly provides a reduction of resource usage. Timely handling of the resume operation is, however, likely to directly impact the end-user's perceived quality experience, since it affects the availability of media that the user expects to receive more or less instantly. It may also be highly desirable for a receiver to quickly learn that an RTP stream is intentionally paused on the RTP sender's own behalf.
本规范的第一节（第1节）描述了接收机暂停RTP发送机的一些可能原因。暂停和恢复取决于时间，即，接收器可以选择将RTP流暂停一定的持续时间，之后接收器可能希望发送方继续。这种时间依赖性意味着与暂停和恢复相关的消息必须及时发送给发送者，以便它们是有目的的。暂停操作可以说不如恢复操作对时间要求严格，因为它主要是减少资源使用。然而，及时处理恢复操作可能会直接影响最终用户的感知质量体验，因为它会影响用户希望或多或少立即收到的媒体的可用性。接收机也可能非常希望快速了解到RTP流是代表RTP发送方自己故意暂停的。
It is the responsibility of an RTP stream receiver that wants to pause or resume a stream from the sender(s) to transmit PAUSE and RESUME messages. An RTP stream sender that wants to pause itself can often simply do it, but sometimes this will adversely affect the receiver and an explicit indication that the RTP stream is paused may then help. Any indication that an RTP stream is paused is the responsibility of the RTP stream sender and may in some cases not even be needed by the stream receiver.
RTP流接收器负责暂停或恢复来自发送方的流，以传输暂停和恢复消息。想要暂停自身的RTP流发送方通常可以简单地这样做，但有时这会对接收方产生不利影响，并且RTP流暂停的明确指示可能会有所帮助。RTP流暂停的任何指示是RTP流发送方的责任，在某些情况下，流接收方甚至可能不需要该指示。
The PAUSE and RESUME messages apply to single RTP streams identified by their SSRC, which means the receiver targets the sender's SSRC in the PAUSE and RESUME requests. If a paused sender starts sending with a new SSRC, the receivers will need to send a new PAUSE request in order to pause it. PAUSED indications refer to a single one of the sender's own paused SSRC.
暂停和恢复消息应用于由其SSRC标识的单个RTP流，这意味着接收方在暂停和恢复请求中以发送方的SSRC为目标。如果暂停的发送方开始发送新的SSRC，接收方需要发送新的暂停请求才能暂停。暂停指示是指发送方自己的一个暂停SSRC。
An RTP stream sender should not pause an SSRC that some receiver still wishes to receive.
RTP流发送方不应暂停某些接收方仍希望接收的SSRC。
The reason is that in RTP topologies where the stream is shared between multiple receivers, a single receiver on that shared network must not single-handedly cause the stream to be paused without letting all other receivers voice their opinions on whether or not the stream should be paused. Such shared networks can, for example, be multicast, a mesh with a joint RTP session, or a transport Translator-based network. A consequence of this is that a newly joining receiver first needs to learn the existence of paused streams and secondly should be able to resume any paused stream. A newly joining receiver can, for example, be detected through an RTCP Receiver Report containing both a new SSRC and a CNAME that does not already occur in the session. Any single receiver wanting to resume a stream should also cause it to be resumed. An important exception to this is when the RTP stream sender is aware of conditions that make it desirable or even necessary to pause the RTP stream on its own behalf, without being explicitly asked to do so. Such local consideration in the RTP sender takes precedence over RTP receiver wishes to receive the stream.
原因是，在多个接收器之间共享流的RTP拓扑中，共享网络上的单个接收器不得单独导致流暂停，而不允许所有其他接收器就流是否应暂停发表意见。例如，这种共享网络可以是多播、具有联合RTP会话的网状网或基于传输转换器的网络。其结果是，新加入的接收器首先需要了解暂停流的存在，其次应该能够恢复任何暂停流。例如，可以通过RTCP接收器报告检测新加入的接收器，该报告包含会话中尚未出现的新SSRC和CNAME。任何想要恢复流的单个接收器也应该使其恢复。一个重要的例外情况是，RTP流发送方知道需要或甚至有必要代表自己暂停RTP流的条件，而没有明确要求这样做。RTP发送方中的这种本地考虑优先于RTP接收方希望接收流的情况。
RTP and RTCP does not guarantee reliable data transmission. It uses whatever assurance the lower-layer transport protocol can provide. However, this is commonly UDP that provides no reliability guarantees. Thus, it is possible that a PAUSE and/or RESUME message transmitted from an RTP endpoint does not reach its destination, i.e., the targeted RTP stream sender. When PAUSE or RESUME reaches the RTP stream sender and is effective, i.e., an active RTP stream sender pauses or a resuming RTP stream sender has media data to transmit, it is immediately seen from the arrival or non-arrival of RTP packets for that RTP stream. Thus, no explicit acknowledgments are required in this case.
RTP和RTCP不能保证可靠的数据传输。它使用底层传输协议可以提供的任何保证。但是，这通常是UDP，不提供可靠性保证。因此，从RTP端点发送的暂停和/或恢复消息可能没有到达其目的地，即，目标RTP流发送方。当暂停或恢复到达RTP流发送器且有效时，即，活动RTP流发送器暂停或正在恢复的RTP流发送器具有要传输的媒体数据时，可立即从该RTP流的RTP分组的到达或未到达中看到。因此，在这种情况下不需要明确的确认。
In some cases, when a PAUSE or RESUME message reaches the RTP stream sender, it will not be able to pause or resume the stream due to some local consideration, for example, lack of data to transmit. In this error condition, a negative acknowledgment may be needed to avoid unnecessary retransmission of requests (Section 4.6).
在某些情况下，当暂停或恢复消息到达RTP流发送方时，由于某些本地因素（例如，缺少要传输的数据），它将无法暂停或恢复流。在这种错误情况下，可能需要否定确认，以避免不必要的请求重传（第4.6节）。
When the stream is not affected as expected by a PAUSE or RESUME request, the request may have been lost and the sender of the request will need to retransmit it. The retransmission should take the round-trip time into account, and will also need to take the normal RTCP bandwidth and timing rules applicable to the RTP session into account, when scheduling retransmission of feedback.
当流没有受到暂停或恢复请求的预期影响时，请求可能已丢失，请求的发送方将需要重新传输它。重新传输应考虑往返时间，并且在安排反馈的重新传输时，还需要考虑适用于RTP会话的正常RTCP带宽和定时规则。
When it comes to resume requests or unsolicited paused indications that are more time critical, the best performance may be achieved by repeating the message as often as possible until a sufficient number have been sent to reach a high probability of message delivery or at an explicit indication that the message was delivered. For resume requests, such explicit indication can be delivery of the RTP stream being requested to be resumed.
对于时间更为关键的恢复请求或未经请求的暂停指示，可通过尽可能频繁地重复消息，直到发送足够数量的消息以达到消息传递的高概率，或通过明确指示消息已传递，来实现最佳性能。对于恢复请求，这种明确指示可以是被请求恢复的RTP流的交付。
A PAUSE request message will need to have a sequence number to separate retransmissions from new requests. A retransmission keeps the sequence number unchanged, while it is incremented every time a new PAUSE request is transmitted that is not a retransmission of a previous request.
暂停请求消息需要有一个序列号，以便将重新传输与新请求分开。重新传输时，序列号保持不变，而每次传输的新暂停请求不是前一个请求的重新传输时，序列号都会增加。
Since RESUME always takes precedence over PAUSE and is even allowed to avoid pausing a stream, there is a need to keep strict ordering of PAUSE and RESUME. Thus, RESUME needs to share sequence number space with PAUSE and implicitly reference which PAUSE it refers to. For the same reasons, the explicit PAUSED indication also needs to share sequence number space with PAUSE and RESUME.
由于RESUME始终优先于PAUSE，甚至可以避免暂停流，因此需要保持暂停和RESUME的严格顺序。因此，RESUME需要与PAUSE共享序列号空间，并隐式引用它所指的PAUSE。出于同样的原因，显式暂停指示还需要与暂停和恢复共享序列号空间。
A performance comparison between SIP/SDP and RTCP signaling technologies was made and included in draft versions of this specification. Using SIP and SDP to carry pause and resume information means that they will need to traverse the entire signaling path to reach the signaling destination (either the remote endpoint or the entity controlling the RTP Mixer) across any signaling proxies that potentially also have to process the SDP content to determine if they are expected to act on it. The amount of bandwidth required for a signaling solution based on SIP/SDP is in the order of at least 10 times more than an RTCP-based solution. Especially for a UA sitting on mobile wireless access, this will risk introducing delays that are too long (Section 4.1) to provide a good user experience, and the bandwidth cost may also be considered infeasible compared to an RTCP-based solution. RTCP data sent
对SIP/SDP和RTCP信令技术进行了性能比较，并将其包含在本规范的草案版本中。使用SIP和SDP携带暂停和恢复信息意味着它们需要遍历整个信令路径以到达信令目的地（远程端点或控制RTP混频器的实体）在任何可能还必须处理SDP内容的信令代理之间，以确定它们是否需要对其进行操作。基于SIP/SDP的信令解决方案所需的带宽量至少是基于RTCP的解决方案的10倍。特别是对于使用移动无线接入的UA，这将有可能引入过长的延迟（第4.1节），无法提供良好的用户体验，并且与基于RTCP的解决方案相比，带宽成本也可能被认为是不可行的。发送的RTCP数据
through the media path, which is likely shorter (contains fewer intermediate nodes) than the signaling path, may have to traverse a few intermediate nodes anyway. The amount of processing and buffering required in intermediate nodes to forward those RTCP messages is, however, believed to be significantly less than for intermediate nodes in the signaling path. Based on those considerations, RTCP is chosen as the signaling protocol for the pause and resume functionality.
通过媒体路径可能比信令路径短（包含较少的中间节点），但无论如何可能必须穿过几个中间节点。然而，中间节点转发这些RTCP消息所需的处理和缓冲量被认为明显小于信令路径中的中间节点。基于这些考虑，选择RTCP作为暂停和恢复功能的信令协议。
The proposed solution implements pause and resume functionality based on sending AVPF RTCP feedback messages from any RTP session participant that wants to pause or resume a stream targeted at the stream sender, as identified by the sender SSRC.
建议的解决方案基于从任何RTP会话参与者发送AVPF RTCP反馈消息来实现暂停和恢复功能，该RTP会话参与者希望暂停或恢复针对流发送方的流，如发送方SSRC所识别。
This solution reuses CCM TMMBR and TMMBN [RFC5104] to the extent possible and defines a small set of new RTCP feedback messages where new semantics is needed.
该解决方案尽可能重用CCM TMMBR和TMMBN[RFC5104]，并在需要新语义的地方定义一组新的RTCP反馈消息。
A single feedback message specification is used to implement the new messages. The message consists of a number of Feedback Control Information (FCI) blocks, where each block can be a PAUSE request, a RESUME request, a PAUSED indication, a REFUSED notification, or an extension to this specification. This structure allows a single feedback message to handle pause functionality on a number of streams.
使用单个反馈消息规范来实现新消息。该消息由多个反馈控制信息（FCI）块组成，其中每个块可以是暂停请求、恢复请求、暂停指示、拒绝通知或本规范的扩展。此结构允许单个反馈消息处理多个流上的暂停功能。
The PAUSED functionality is also defined in such a way that it can be used as a standalone by the RTP stream sender to indicate a local decision to pause, and it can inform any receiver of the fact that halting media delivery is deliberate and which RTP packet was the last transmitted.
暂停功能还以这样的方式定义，即RTP流发送器可以将其用作独立的功能，以指示暂停的本地决定，并且它可以通知任何接收器停止媒体交付是故意的，并且哪个RTP分组是最后发送的。
Special considerations that apply when using TMMBR/TMMBN for pause and resume purposes are described in Section 5.6. This specification applies to both the new messages defined herein as well as their TMMBR/TMMBN counterparts, except when explicitly stated otherwise. An obvious exception is any reference to the message parameters that are only available in the messages defined here. For example, any reference to PAUSE in the text below is equally applicable to TMMBR 0, and any reference to PAUSED is equally applicable to TMMBN 0. Therefore, and for brevity, TMMBR/TMMBN will not be mentioned in the text, unless there is specific reason to do so.
第5.6节描述了使用TMMBR/TMMBN进行暂停和恢复时的特殊注意事项。本规范适用于本文定义的新消息及其TMMBR/TMMBN对应消息，除非另有明确说明。一个明显的例外是对仅在此处定义的消息中可用的消息参数的任何引用。例如，下文中对暂停的任何引用都同样适用于TMMBR 0，对暂停的任何引用也同样适用于TMMBN 0。因此，为了简洁起见，除非有具体的理由，否则文本中不会提及TMMBR/TMMBN。
This section is intended to be explanatory and therefore intentionally contains no mandatory statements. Such statements can instead be found in other parts of this specification.
本节旨在解释，因此故意不包含强制性声明。此类声明可以在本规范的其他部分中找到。
An endpoint can use an extension to CCM SDP signaling to declare capability to understand the messages defined in this specification. Capability to understand only a subset of messages is possible, to support partial implementation, which is specifically believed to be feasible for the 'RTP Mixer to Media Sender' use case (Section 3.2). In that use case, only the RTP Mixer has capability to request the media sender to pause or resume. Consequently, in that same use case, only the media sender has capability to pause and resume its sent streams based on requests from the RTP Mixer. Allowing for partial implementation of this specification is not believed to hamper interoperability, as long as the subsets are well defined and describe a consistent functionality, including a description of how a more capable implementation must perform fallback.
端点可以使用CCM SDP信令的扩展来声明理解本规范中定义的消息的能力。仅理解消息子集的能力是可能的，以支持部分实现，这对于“RTP混音器到媒体发送器”用例是可行的（第3.2节）。在这种情况下，只有RTP混音器能够请求媒体发送器暂停或恢复。因此，在相同的用例中，只有媒体发送方能够基于来自RTP混合器的请求暂停和恢复其发送的流。允许部分实施本规范并不妨碍互操作性，只要子集定义良好并描述了一致的功能，包括描述能力更强的实现必须如何执行回退。
For the case when TMMBR/TMMBN are used for pause and resume purposes, it is possible to explicitly express joint support for TMMBR and TMMBN, but not for TMMBN only.
对于TMMBR/TMMBN用于暂停和恢复目的的情况，可以明确表示对TMMBR和TMMBN的联合支持，但不能仅表示对TMMBN的联合支持。
All messages defined in this specification (Section 8) contain a PauseID, satisfying the design consideration on sequence numbering (Section 4.7). This PauseID is scoped by and thus a property of the targeted RTP stream (SSRC) and is not only a sequence number for individual messages. Instead, it numbers an entire "pause and resume operation" for the RTP stream, typically keeping PauseID constant for multiple, related messages. The PauseID value used during such operation is called the current PauseID. A new "pause and resume operation" is defined to start when the RTP stream sender resumes the RTP stream after it was being paused. The current PauseID is then incremented by one in modulo arithmetic. In the subsequent descriptions below, it is sometimes necessary to refer to PauseID values that were already used as the current PauseID, which is denoted as the past PauseID. It should be noted that since PauseID uses modulo arithmetic, a past PauseID may have a larger value than the current PauseID. Since PauseID uses modulo arithmetic, it is also useful to define what PauseID values are considered "past" to clearly separate it from what could be considered "future" PauseID values. Half of the entire PauseID value range is chosen to represent a past PauseID, while a quarter of the PauseID value range is chosen to represent future values. The remaining quarter of the PauseID value range is intentionally left undefined in that respect.
本规范（第8节）中定义的所有信息均包含PauseID，满足顺序编号（第4.7节）的设计考虑。此PauseID的范围由目标RTP流（SSRC）的属性确定，因此它不仅仅是单个消息的序列号。相反，它为RTP流的整个“暂停和恢复操作”编号，通常为多个相关消息保持PauseID恒定。此操作期间使用的PauseID值称为当前PauseID。定义了一个新的“暂停和恢复操作”，当RTP流发送器在RTP流暂停后恢复RTP流时启动。然后，在模运算中，当前PauseID增加1。在下面的后续描述中，有时需要引用已用作当前PauseID的PauseID值，该值表示为过去的PauseID。应注意，由于PauseID使用模运算，因此过去的PauseID可能比当前的PauseID具有更大的值。由于PauseID使用模运算，因此定义哪些PauseID值被视为“过去”也很有用，以便将其与可能被视为“未来”的PauseID值明确区分开来。选择整个PauseID值范围的一半表示过去的PauseID，而选择PauseID值范围的四分之一表示未来的值。PauseID值范围的剩余四分之一在这方面故意未定义。
An RTP stream receiver can choose to send a PAUSE request at any time, subject to AVPF timing rules.
RTP流接收器可以根据AVPF定时规则选择随时发送暂停请求。
The PAUSE request contains the current PauseID (Section 5.2).
暂停请求包含当前的PauseID（第5.2节）。
When a non-paused RTP stream sender receives the PAUSE request, it continues to send the RTP stream while waiting for some time to allow other RTP stream receivers in the same RTP session that saw this PAUSE request to disapprove by sending a RESUME (Section 5.5) for the same stream and with the same current PauseID as in the PAUSE being disapproved. If such a disapproving RESUME arrives at the RTP stream sender during the hold-off period before the stream is paused, the pause is not performed. In point-to-point configurations, the hold-off period may be set to zero. Using a hold-off period of zero is also appropriate when using TMMBR 0 and is in line with the semantics for that message.
当未暂停的RTP流发送方收到暂停请求时，它将继续发送RTP流，同时等待一段时间，以允许在同一RTP会话中看到此暂停请求的其他RTP流接收方通过发送恢复来拒绝（第5.5节）对于相同的流，并且具有与不批准暂停中相同的当前PauseID。如果在暂停流之前的等待期间，这种不批准的恢复到达RTP流发送方，则不执行暂停。在点对点配置中，延迟周期可设置为零。在使用TMMBR 0时，使用延迟期零也是合适的，并且符合该消息的语义。
If the RTP stream sender receives further PAUSE requests with the current PauseID while waiting as described above, those additional requests are ignored.
如果RTP流发送器在如上所述的等待期间接收到具有当前PauseID的进一步暂停请求，则忽略这些附加请求。
If the PAUSE request is lost before it reaches the RTP stream sender, it will be discovered by the RTP stream receiver because it continues to receive the RTP stream. It will also not see any PAUSED indication (Section 5.4) for the stream. The same condition can be caused by the RTP stream sender having received a disapproving RESUME from stream receiver A for a PAUSE request sent by stream sender B, except that the PAUSE sender (B) did not receive the RESUME (from A) and may instead think that the PAUSE was lost. In both cases, a PAUSE request can be retransmitted using the same current PauseID. If using TMMBR 0, the request MAY be retransmitted when the requester fails to receive a TMMBN 0 confirmation.
如果暂停请求在到达RTP流发送方之前丢失，RTP流接收器将发现它，因为它继续接收RTP流。它也不会看到流的任何暂停指示（第5.4节）。对于流发送方B发送的暂停请求，RTP流发送方已经从流接收方a接收到不批准的恢复，除了暂停发送方（B）没有接收到（来自a）的恢复，并且可能认为暂停已丢失之外，可能会导致相同的情况。在这两种情况下，可以使用相同的当前PauseID重新传输暂停请求。如果使用TMMBR 0，当请求者未能收到TMMBN 0确认时，可能会重新传输请求。
If the pending stream pause is aborted due to a disapproving RESUME, the pause and resume operation for that PauseID is concluded, the current PauseID is updated, and any new PAUSE must therefore use the new current PauseID to be effective.
如果由于不批准恢复而中止挂起的流暂停，则该暂停ID的暂停和恢复操作将结束，当前的暂停ID将更新，因此任何新的暂停必须使用新的当前暂停ID才能生效。
An RTP stream sender receiving a PAUSE not using the current PauseID informs the RTP stream receiver sending the ineffective PAUSE of this condition by sending a REFUSED notification that contains the current PauseID value.
接收到未使用当前PauseID的暂停的RTP流发送方通过发送包含当前PauseID值的拒绝通知来通知发送无效暂停的RTP流接收方此情况。
A situation where an ineffective PauseID is chosen can appear when a new RTP stream receiver joins a session and wants to PAUSE a stream but does not yet know the current PauseID to use. The REFUSED
当一个新的RTP流接收器加入一个会话并想要暂停一个流，但还不知道要使用的当前PauseID时，可能会出现选择无效PauseID的情况。拒绝
notification will then provide sufficient information to create a valid PAUSE. The required extra signaling round trip is not considered harmful, since it is assumed that pausing a stream is not time critical (Section 4.1).
通知将提供足够的信息来创建有效的暂停。所需的额外信号往返不被认为是有害的，因为假定暂停流不是时间关键的（第4.1节）。
There may be local considerations making it impossible or infeasible to pause the stream, and the RTP stream sender can then respond with a REFUSED. In this case, if the used current PauseID would otherwise have been effective, REFUSED contains the same current PauseID as in the PAUSE request. Note that when using TMMBR 0 as PAUSE, that request cannot be refused (TMMBN > 0) due to the existing restriction in Section 4.2.2.2 of [RFC5104] that TMMBN shall contain the current bounding set, and the fact that a TMMBR 0 will always be the most restrictive point in any bounding set, regardless of the bounding set overhead value.
可能存在本地因素使得暂停流不可能或不可行，RTP流发送方随后可以使用拒绝响应。在这种情况下，如果使用的当前PauseID本来是有效的，则拒绝包含与暂停请求中相同的当前PauseID。请注意，当使用TMMBR 0作为暂停时，由于[RFC5104]第4.2.2.2节中存在TMMBN应包含当前边界集的限制，并且无论边界集开销值如何，TMMBR 0始终是任何边界集中限制最严格的点，因此无法拒绝该请求（TMMBN>0）。
If the RTP stream sender receives several identical PAUSE requests for an RTP stream that was already responded to at least once with REFUSED and the condition causing REFUSED remains, those additional REFUSED notifications should be sent with regular RTCP timing. A single REFUSED can respond to several identical PAUSE requests.
如果RTP流发送方接收到RTP流的多个相同暂停请求，且该请求已被拒绝至少响应一次，并且导致拒绝的条件仍然存在，则应使用常规RTCP定时发送这些额外的被拒绝通知。一个被拒绝的用户可以响应多个相同的暂停请求。
An RTP stream sender can choose to pause the stream at any time. This can be either a result of receiving a PAUSE or based on some local sender consideration. When it does, it sends a PAUSED indication, containing the current PauseID. Note that the current PauseID in an unsolicited PAUSED (without having received a PAUSE) is incremented compared to a previously sent PAUSED. It also sends the PAUSED indication in the next two regular RTCP reports, given that the pause condition is then still effective.
RTP流发送方可以选择随时暂停流。这可能是由于接收到暂停或基于某些本地发送方的考虑。当它这样做时，它会发送一个暂停指示，其中包含当前的PauseID。请注意，与先前发送的暂停相比，非请求暂停（未收到暂停）中的当前暂停ID增加。如果暂停条件仍然有效，它还会在接下来的两个常规RTCP报告中发送暂停指示。
There is no reply to a PAUSED indication; it is simply an explicit indication of the fact that an RTP stream is paused. This can be helpful for the RTP stream receiver, for example, to quickly understand that transmission is deliberately and temporarily suspended and no specific corrective action is needed.
没有对暂停指示的回复；它只是RTP流暂停这一事实的明确指示。例如，这有助于RTP流接收器快速理解传输被故意和临时暂停，并且不需要特定的纠正措施。
The RTP stream sender may want to apply some local consideration to exactly when the RTP stream is paused, for example, completing some media unit or a forward error correction block, before pausing the stream.
RTP流发送器可能希望在暂停流之前，将一些本地考虑应用于RTP流暂停的确切时间，例如，完成某个媒体单元或前向纠错块。
The PAUSED indication also contains information about the RTP extended highest sequence number when the pause became effective. This provides RTP stream receivers with firsthand information that allows them to know whether they lost any packets just before the
暂停指示还包含有关暂停生效时RTP扩展的最高序列号的信息。这为RTP流接收器提供了第一手信息，使他们能够知道在传输之前是否丢失了任何数据包
stream paused or when the stream is resumed again. This allows RTP stream receivers to quickly and safely take into account that the stream is paused in, for example, retransmission or congestion control algorithms.
流暂停或流再次恢复时。这允许RTP流接收器快速且安全地考虑流在例如重传或拥塞控制算法中暂停。
If the RTP stream sender receives PAUSE requests with the current PauseID while the stream is already paused, those requests are ignored.
如果RTP流发送器在流已暂停时接收到带有当前PauseID的暂停请求，则忽略这些请求。
As long as the stream is being paused, the PAUSED indication MAY be sent together with any regular RTCP Sender Report (SR) or Receiver Report (RR). Including PAUSED in this way allows RTP stream receivers to join while the stream is paused and to quickly know that there is a paused stream, what the last sent extended RTP sequence number is, and what the current PauseID is, which enables them to construct valid PAUSE and RESUME requests at a later stage.
只要流处于暂停状态，暂停指示可以与任何常规RTCP发送方报告（SR）或接收方报告（RR）一起发送。以这种方式包括暂停允许RTP流接收器在流暂停时加入，并快速知道存在暂停流、上次发送的扩展RTP序列号是什么以及当前暂停ID是什么，这使他们能够在稍后阶段构造有效的暂停和恢复请求。
When the RTP stream sender learns that a new endpoint has joined the RTP session, for example, by a new SSRC and a CNAME that was not previously seen in the RTP session, it should send PAUSED indications for all its paused streams at its earliest opportunity. In addition, it should continue to include PAUSED indications in at least two regular RTCP reports.
当RTP流发送方得知新端点已加入RTP会话（例如，通过新SSRC和以前在RTP会话中未看到的CNAME）时，它应尽早发送其所有暂停流的暂停指示。此外，应继续在至少两份定期RTCP报告中包含暂停指示。
An RTP stream receiver can request the RTP stream sender to resume a stream with a RESUME request at any time, subject to AVPF timing rules. The RTP stream receiver must include the current PauseID in the RESUME request for it to be effective.
RTP流接收器可以根据AVPF定时规则，随时请求RTP流发送器使用恢复请求恢复流。RTP流接收器必须在恢复请求中包含当前PauseID，才能使其生效。
A pausing RTP stream sender that receives a RESUME including the current PauseID resumes the stream at the earliest opportunity. Receiving RESUME requests for a stream that is not paused does not require any action and can be ignored.
一个暂停的RTP流发送器，它接收一个包括当前暂停ID的恢复，并尽早恢复流。接收未暂停流的恢复请求不需要任何操作，可以忽略。
There may be local considerations at the RTP stream sender, for example, that the media device is not ready, making it temporarily impossible to resume the stream at that point in time, and the RTP stream sender can then respond with a REFUSED containing the current PauseID. When receiving such REFUSED with a current PauseID identical to the one in the sent RESUME, RTP stream receivers should avoid sending further RESUME requests for some reasonable amount of time to allow the condition to clear. An RTP stream sender having sent a REFUSED SHOULD resume the stream through local considerations (see below) when the condition that caused the REFUSED is no longer true.
在RTP流发送器处可能存在本地考虑，例如，媒体设备未准备好，使得暂时不可能在该时间点恢复流，并且RTP流发送器随后可以使用包含当前PauseID的拒绝响应。当以与发送的恢复中相同的当前PauseID接收此类拒绝时，RTP流接收器应避免在一段合理的时间内发送进一步的恢复请求，以允许条件清除。当导致拒绝的条件不再成立时，已发送拒绝的RTP流发送方应通过本地考虑（见下文）恢复流。
If the RTP stream sender receives several identical RESUME requests for an RTP stream that was already at least once responded to with REFUSED and the condition causing REFUSED remains, those additional REFUSED notifications should be sent with regular RTCP timing. A single REFUSED can respond to several identical RESUME requests.
如果RTP流发送方收到多个相同的RTP流恢复请求，且该请求至少已被拒绝响应一次，并且导致拒绝的条件仍然存在，则应定期发送这些额外的被拒绝通知，并进行RTCP定时。一个被拒绝的人可以响应多个相同的简历请求。
A pausing RTP stream sender can apply local considerations and can resume a paused RTP stream at any time. If TMMBR 0 was used to pause the RTP stream, resumption is prevented by protocol, even if the RTP sender would like to resume due to local considerations. If TMMBR/ TMMBN signaling is used, the RTP stream is paused due to local considerations (Section 5.4), and the RTP stream sender thus owns the TMMBN bounding set, the RTP stream can be resumed due to local considerations.
暂停的RTP流发送器可以应用本地注意事项，并且可以随时恢复暂停的RTP流。如果使用TMMBR 0暂停RTP流，则协议会阻止恢复，即使RTP发送方出于本地考虑而希望恢复。如果使用TMMBR/TMMBN信令，RTP流由于本地考虑而暂停（第5.4节），RTP流发送方因此拥有TMMBN边界集，RTP流可以由于本地考虑而恢复。
When resuming a paused stream, especially for media that makes use of temporal redundancy between samples such as video, it may not be appropriate to use such temporal dependency in the encoding between samples taken before the pause and at the time instant the stream is resumed. Should such temporal dependency between media samples before and after the media was paused be used by the RTP stream sender, it requires the RTP stream receiver to have saved the samples from before the pause for successful continued decoding when resuming. The use of this temporal dependency of media samples from before the pause is left up to the RTP stream sender. If temporal dependency on samples from before the pause is not used when the RTP stream is resumed, the first encoded sample after the pause will not contain any temporal dependency on samples before the pause (for video it may be a so-called intra picture). If temporal dependency on samples from before the pause is used by the RTP stream sender when resuming, and if the RTP stream receiver did not save any sample from before the pause, the RTP stream receiver can use a FIR request [RFC5104] to explicitly ask for a sample without temporal dependency (for video a so-called intra picture), even at the same time as sending the RESUME.
当恢复暂停的流时，特别是对于利用诸如视频之类的样本之间的时间冗余的媒体，在暂停之前和流恢复的时刻所采取的样本之间的编码中使用这种时间依赖性可能是不合适的。如果RTP流发送器使用暂停媒体之前和之后的媒体样本之间的这种时间依赖性，则RTP流接收器需要保存暂停之前的样本，以便在恢复时成功地继续解码。暂停前媒体样本的这种时间依赖性的使用留给RTP流发送方。如果在恢复RTP流时未使用对来自暂停之前的样本的时间依赖性，则暂停之后的第一个编码样本将不包含对暂停之前的样本的任何时间依赖性（对于视频，它可能是所谓的帧内图片）。如果RTP流发送方在恢复时使用了对暂停前的样本的时间依赖性，并且如果RTP流接收器没有保存暂停前的任何样本，RTP流接收器可以使用FIR请求[RFC5104]来明确请求没有时间依赖性的样本（对于视频，所谓的帧内图片），甚至在发送简历的同时。
As stated above, TMMBR/TMMBN may be used to provide pause and resume functionality for the point-to-point case. If the topology is not point to point, TMMBR/TMMBN cannot safely be used for pause or resume. This use is expected to be mainly for interworking with implementations that don't support the messages defined in this specification (Section 8) but make use of TMMBR/TMMBN to achieve a similar effect.
如上所述，TMMBR/TMMBN可用于为点到点情况提供暂停和恢复功能。如果拓扑不是点对点的，则TMMBR/TMMBN不能安全地用于暂停或恢复。此用途主要用于与不支持本规范（第8节）中定义的消息，但使用TMMBR/TMMBN实现类似效果的实现进行交互。
This is a brief summary of what functionality is provided when using TMMBR/TMMBN:
这是使用TMMBR/TMMBN时提供的功能的简要总结：
TMMBR 0: Corresponds to PAUSE, without the requirement for any hold-off period to wait for RESUME before pausing the RTP stream.
TMMBR 0：对应于暂停，在暂停RTP流之前不需要任何等待时间来等待恢复。
TMMBR > 0: Corresponds to RESUME when the RTP stream was previously paused with TMMBR 0. Since there is only a single RTP stream receiver, there is no need for the RTP stream sender to delay resuming the stream until after sending TMMBN > 0 or to apply the hold-off period specified in [RFC5104] before increasing the bitrate from zero. The bitrate value used when resuming after pausing with TMMBR 0 is either according to known limitations or based on starting a stream with the configured maximum for the stream or session, for example, given by "b=" line in SDP.
TMMBR>0：对应于RTP流先前使用TMMBR 0暂停时的恢复。因为只有一个RTP流接收器，所以RTP流发送器不需要延迟恢复流，直到发送TMMBN>0之后，或者在比特率从零增加之前应用[RFC5104]中指定的延迟周期。使用TMMBR 0暂停后恢复时使用的比特率值根据已知限制或基于以流或会话配置的最大值启动流，例如，SDP中的“b=”行给出。
TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with TMMBR 0 but may, just as PAUSED, also be used unsolicited. An unsolicited RTP stream pause based on local sender considerations uses the RTP stream's own SSRC as the TMMBR restriction owner in the TMMBN message bounding set. It also corresponds to a REFUSED notification when a stream is requested to be resumed with TMMBR > 0, thus resulting in the stream sender becoming the owner of the bounding set in the TMMBN message.
TMMBN 0：对应于RTP流使用TMMBR 0暂停时的暂停，但也可以像暂停一样未经请求使用。基于本地发送方考虑的未经请求的RTP流暂停使用RTP流自己的SSRC作为TMMBN消息边界集中的TMMBR限制所有者。当TMMBR>0请求恢复流时，它还对应于拒绝通知，从而导致流发送方成为TMMBN消息中边界集的所有者。
TMMBN > 0: Cannot be used as a REFUSED notification when a stream is requested to be paused with TMMBR 0, for reasons stated in Section 5.3.
TMMBN>0：由于第5.3节所述原因，当请求使用TMMBR 0暂停流时，不能将其用作拒绝通知。
This document introduces three new states for a stream in an RTP sender, according to the figure and subsections below. Any references to PAUSE, PAUSED, RESUME, and REFUSED in this section SHALL be taken to apply to the extent possible also when TMMBR/TMMBN are used (Section 5.6) for this functionality.
根据下面的图和小节，本文介绍了RTP发送器中流的三种新状态。当TMMBR/TMMBN用于此功能时（第5.6节），本节中提及的暂停、暂停、恢复和拒绝也应尽可能适用。
+------------------------------------------------------+
| Received RESUME |
v |
+---------+ Received PAUSE +---------+ Hold-off period +--------+
| Playing |---------------->| Pausing |---------------->| Paused |
| |<----------------| | | |
+---------+ Received RESUME +---------+ +--------+
^ | | PAUSE decision |
| | v |
| | PAUSE decision +---------+ PAUSE decision |
| +------------------>| Local |<--------------------+
+-------------------------| Paused |
RESUME decision +---------+
+------------------------------------------------------+
| Received RESUME |
v |
+---------+ Received PAUSE +---------+ Hold-off period +--------+
| Playing |---------------->| Pausing |---------------->| Paused |
| |<----------------| | | |
+---------+ Received RESUME +---------+ +--------+
^ | | PAUSE decision |
| | v |
| | PAUSE decision +---------+ PAUSE decision |
| +------------------>| Local |<--------------------+
+-------------------------| Paused |
RESUME decision +---------+
Figure 4: RTP Pause States in Sender
图4：发送器中的RTP暂停状态
This state is not new but is the normal media sending state from [RFC3550]. When entering the state, the current PauseID MUST be incremented by one in modulo arithmetic. The RTP sequence number for the first packet sent after a pause SHALL be incremented by one compared to the highest RTP sequence number sent before the pause. The first RTP timestamp for the first packet sent after a pause SHOULD be set according to capture times at the source, meaning the RTP timestamp difference compared to before the pause reflects the time the RTP stream was paused.
此状态不是新状态，而是[RFC3550]的正常媒体发送状态。进入状态时，当前PauseID必须以模运算方式递增1。与暂停前发送的最高RTP序列号相比，暂停后发送的第一个数据包的RTP序列号应增加1。暂停后发送的第一个数据包的第一个RTP时间戳应根据源的捕获时间设置，这意味着与暂停前相比的RTP时间戳差异反映了RTP流暂停的时间。
In this state, the RTP stream sender has received at least one PAUSE message for the stream in question. The RTP stream sender SHALL wait during a hold-off period for the possible reception of RESUME messages for the RTP stream being paused before actually pausing RTP stream transmission. The hold-off period to wait SHALL be long enough to allow another RTP stream receiver to respond to the PAUSE with a RESUME, if it determines that it would not like to see the stream paused. This hold-off period is determined by the formula:
在这种状态下，RTP流发送方已收到有关流的至少一条暂停消息。在实际暂停RTP流传输之前，RTP流发送方应在等待期间等待可能接收到的暂停RTP流的恢复消息。等待的延迟时间应足够长，以允许另一个RTP流接收器在其确定不希望看到流暂停的情况下，用恢复响应暂停。延迟期由以下公式确定：
2 * RTT + T_dither_max,
2*RTT+T_抖动最大值，
where RTT is the longest round trip known to the RTP stream sender and T_dither_max is defined in Section 3.4 of [RFC4585]. The hold-off period MAY be set to 0 by some signaling (Section 9) means when it can be determined that there is only a single receiver, for example, in point to point or some unicast situations.
其中RTT是RTP流发送器已知的最长往返行程，T_抖动_max在[RFC4585]的第3.4节中定义。例如，在点对点或一些单播情况下，当可以确定只有一个接收机时，可以通过一些信令（第9部分）手段将保持周期设置为0。
If the RTP stream sender has set the hold-off period to 0 and receives information that it was an incorrect decision and that there are in fact several receivers of the stream, it MUST change the hold-off period to be based on the above formula instead.
如果RTP流发送方已将延迟时间设置为0，并收到信息表明这是一个错误的决定，并且实际上有多个流接收方，则必须将延迟时间更改为基于上述公式。
An RTP stream sender SHOULD use the following criteria to determine if there is only a single receiver, unless it has explicit and more reliable information:
RTP流发送方应使用以下标准来确定是否只有一个接收方，除非其具有明确且更可靠的信息：
o Observing only a single CNAME across all received SSRCs (CNAMEs for received CSRCs are insignificant), or
o 在所有接收到的SSRC中仅观察一个CNAME（接收到的CSRC的CNAME不重要），或
o If RTCP reporting groups [MULTI-STREAM-OPT] is used, observing only a single, endpoint external RTCP reporting group.
o 如果使用RTCP报告组[MULTI-STREAM-OPT]，则只观察单个端点外部RTCP报告组。
An RTP stream is in paused state when the sender pauses its transmission after receiving at least one PAUSE message and the hold-off period has passed without receiving any RESUME message for that stream. Pausing transmission SHOULD only be done when reaching an appropriate place to pause in the stream, like a media boundary that avoids a media receiver to trigger repair or concealment actions.
当发送方在接收到至少一条暂停消息后暂停其传输，并且在没有接收到该流的任何恢复消息的情况下，等待时间已经过去时，RTP流处于暂停状态。暂停传输只能在到达流中暂停的适当位置时进行，如避免媒体接收器触发修复或隐藏操作的媒体边界。
When entering the state, the RTP stream sender SHALL send a PAUSED indication to all known RTP stream receivers, and SHALL also repeat PAUSED in the next two regular RTCP reports, as long as it is then still in paused state.
进入状态时，RTP流发送方应向所有已知RTP流接收器发送暂停指示，并在接下来的两个常规RTCP报告中重复暂停，只要其仍处于暂停状态。
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive [RFC6263][RFC5245] applicable to that RTP stream.
暂停RTP流不得影响适用于该RTP流的RTP keepalive[RFC6263][RFC5245]的发送。
The following subsections discuss some potential issues when an RTP sender goes into paused state. These conditions are also valid if an RTP Translator is used in the communication. When an RTP Mixer implementing this specification is involved between the participants (which forwards the stream by marking the RTP data with its own SSRC), it SHALL be a responsibility of the Mixer to control sending PAUSE and RESUME requests to the sender. The below conditions also apply to the sender and receiver parts of the RTP Mixer, respectively.
以下小节将讨论RTP发送方进入暂停状态时的一些潜在问题。如果在通信中使用RTP转换器，这些条件也有效。当参与者之间涉及实施本规范的RTP混合器时（通过使用自己的SSRC标记RTP数据转发流），混合器应负责控制向发送者发送暂停和恢复请求。以下条件也分别适用于RTP混频器的发送器和接收器部分。
When a participant leaves the RTP session, it sends an RTCP BYE message. In addition to the semantics described in Sections 6.3.4 and 6.3.7 of RTP [RFC3550], the following two conditions MUST also be considered when an RTP participant sends an RTCP BYE message:
当参与者离开RTP会话时，会发送RTCP BYE消息。除了RTP[RFC3550]第6.3.4节和第6.3.7节中描述的语义外，当RTP参与者发送RTCP BYE消息时，还必须考虑以下两个条件：
o If a paused sender sends an RTCP BYE message, receivers observing this SHALL NOT send further PAUSE or RESUME requests to it.
o 如果暂停的发送方发送RTCP BYE消息，则遵守该消息的接收方不得向其发送进一步的暂停或恢复请求。
o Since a sender pauses its transmission on receiving the PAUSE requests from any receiver in a session, the sender MUST keep record of which receiver caused the RTP stream to pause. If that receiver sends an RTCP BYE message observed by the sender, the sender SHALL resume the RTP stream. No receivers that were in the RTP session when the stream was paused objected that the stream was paused, but if there were so far undetected receivers added to the session during pause, those may not have learned about the existence of the paused stream because either there was no PAUSED sent for the paused RTP stream or those receivers did not support PAUSED. Resuming the stream when the pausing party leaves the RTP session allows those potentially undetected receivers to learn that the stream exists.
o 由于发送方在从会话中的任何接收方接收暂停请求时暂停其传输，因此发送方必须保留导致RTP流暂停的接收方的记录。如果接收方发送发送方观察到的RTCP BYE消息，发送方应恢复RTP流。暂停流时，RTP会话中没有任何接收者反对暂停流，但如果暂停期间有未检测到的接收者添加到会话中，因为暂停的RTP流没有暂停发送，或者那些接收器不支持暂停，所以他们可能没有了解暂停流的存在。当暂停方离开RTP会话时恢复流允许那些潜在未被检测到的接收者知道流存在。
Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP participant. Every RTP participant maintains a sender and receiver list in a session. If a participant does not get any RTP or RTCP packets from some other participant for the last five RTCP reporting intervals, it removes that participant from the receiver list. Any streams that were paused by that removed participant SSRC SHALL be resumed.
RTP[RFC3550]中的第6.3.5节描述了RTP参与者的SSRC超时。每个RTP参与者在会话中维护一个发送方和接收方列表。如果某个参与者在过去五个RTCP报告间隔内没有从其他参与者处获得任何RTP或RTCP数据包，则会将该参与者从接收方列表中删除。被移除的参与者SSRC暂停的任何流都应恢复。
This state can be entered at any time, based on local decision from the RTP stream sender. Pausing transmission SHOULD only be done when reaching an appropriate place to pause in the stream, like a media boundary that avoids a media receiver to trigger repair or concealment actions.
根据RTP流发送方的本地决定，可以随时输入此状态。暂停传输只能在到达流中暂停的适当位置时进行，如避免媒体接收器触发修复或隐藏操作的媒体边界。
As with paused state (Section 6.3), the RTP stream sender SHALL send a PAUSED indication to all known RTP stream receivers, when entering the state, unless the stream was already in paused state (Section 6.3). Such PAUSED indication SHALL be repeated a sufficient
与暂停状态（第6.3节）一样，RTP流发送器应在进入该状态时向所有已知RTP流接收器发送暂停指示，除非流已经处于暂停状态（第6.3节）。此类暂停指示应重复足够长的时间
number of times to reach a high probability that the message is correctly delivered, stopping such repetition whenever leaving the state.
达到消息正确传递的高概率的次数，在离开状态时停止此类重复。
When using TMMBN 0 as a PAUSED indication and when already in paused state, the actions when entering local paused state depends on the bounding set overhead value in the received TMMBR 0 that caused the paused state and the bounding set overhead value used in (the RTP stream sender's own) TMMBN 0:
当使用TMMBN 0作为暂停指示并且已经处于暂停状态时，进入本地暂停状态时的操作取决于导致暂停状态的接收TMMBR 0中的边界集开销值和（RTP流发送方自己的）TMMBN 0中使用的边界集开销值：
TMMBN 0 overhead <= TMMBR 0 overhead: The RTP stream sender SHALL NOT send any new TMMBN 0 replacing that active (more restrictive) bounding set, even if entering local paused state.
TMMBN 0开销<=TMMBR 0开销：RTP流发送器不应发送任何新的TMMBN 0来替换该活动（更严格的）边界集，即使进入本地暂停状态。
TMMBN 0 overhead > TMMBR 0 overhead: The RTP stream sender SHALL send TMMBN 0 with itself in the TMMBN bounding set when entering local paused state.
TMMBN 0开销>TMMBR 0开销：当进入本地暂停状态时，RTP流发送方应在TMMBN边界集中发送TMMBN 0。
The case above, when using TMMBN 0 as a PAUSED indication, being in local paused state, and having received a TMMBR 0 with a bounding set overhead value greater than the value the RTP stream sender would itself use in a TMMBN 0, requires further consideration and is for clarity henceforth referred to as "restricted local paused state".
上述情况，当使用TMMBN 0作为暂停指示时，处于本地暂停状态，并且接收到的TMMBR 0的边界设置开销值大于RTP流发送器本身在TMMBN 0中使用的值，需要进一步考虑，并且为了清楚起见，以下称为“受限本地暂停状态”。
As indicated in Figure 4, local paused state has higher precedence than paused state (Section 6.3), and RESUME messages alone cannot resume a paused RTP stream as long as the local decision still applies. An RTP stream sender in local paused state is responsible for leaving the state whenever the conditions that caused the decision to enter the state no longer apply.
如图4所示，本地暂停状态的优先级高于暂停状态（第6.3节），只要本地决定仍然适用，恢复消息本身就不能恢复暂停的RTP流。处于本地暂停状态的RTP流发送器负责在导致进入状态的条件不再适用时离开该状态。
If the RTP stream sender is in restricted local paused state, it cannot leave that state until the TMMBR 0 limit causing the state is removed by a TMMBR > 0 (RESUME). If the RTP stream sender then needs to stay in local paused state due to local considerations, it MAY continue pausing the RTP stream by entering local paused state and MUST then act accordingly, including sending a TMMBN 0 with itself in the bounding set.
如果RTP流发送器处于受限本地暂停状态，则在导致该状态的TMMBR 0限制被TMMBR>0（恢复）删除之前，它无法离开该状态。如果RTP流发送器由于本地考虑而需要保持在本地暂停状态，则它可以通过进入本地暂停状态来继续暂停RTP流，并且随后必须相应地采取行动，包括发送一个TMMBN 0，其自身在边界集中。
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive [RFC6263][RFC5245] applicable to that RTP stream.
暂停RTP流不得影响适用于该RTP流的RTP keepalive[RFC6263][RFC5245]的发送。
When leaving the local paused state, the stream state SHALL become Playing, regardless of whether or not there were any RTP stream receivers that sent PAUSE for that stream during the local paused state, effectively clearing the RTP stream sender's memory for that stream.
当离开本地暂停状态时，流状态应变为播放，无论是否有任何RTP流接收器在本地暂停状态期间发送该流的暂停，有效地清除该流的RTP流发送者的内存。
Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP feedback messages, i.e., transport-layer, payload-specific, and application-layer feedback messages. This document defines a new transport-layer feedback message, which is further subtyped into either a PAUSE request, a RESUME request, a PAUSED indication, or a REFUSED notification.
AVPF[RFC4585]第6节定义了三种类型的低延迟RTCP反馈消息，即传输层、特定于有效负载和应用层反馈消息。本文档定义了一个新的传输层反馈消息，该消息进一步细分为暂停请求、恢复请求、暂停指示或拒绝通知。
The transport-layer feedback messages are identified by having the RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. This transport-layer feedback message, containing one or more of the subtyped messages, is henceforth referred to as the PAUSE-RESUME message. The specific FCI format is identified by a Feedback Message Type (FMT) value in a common packet header for the feedback message defined in Section 6.1 of AVPF [RFC4585]. The PAUSE-RESUME transport-layer feedback message FCI is identified by FMT value = 9.
传输层反馈消息通过使RTCP有效负载类型为AVPF[RFC4585]定义的RTPFB（205）来识别。此传输层反馈消息包含一个或多个子类型消息，因此称为暂停-恢复消息。特定FCI格式由AVPF[RFC4585]第6.1节中定义的反馈消息的公共数据包报头中的反馈消息类型（FMT）值标识。暂停-恢复传输层反馈消息FCI由FMT值=9标识。
The Common Packet Format for feedback messages defined by AVPF [RFC4585] is:
AVPF[RFC4585]定义的反馈消息的通用数据包格式为：
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| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
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| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 5: AVPF Common Feedback Message Packet Format
图5:AVPF公共反馈消息包格式
For the PAUSE-RESUME message defined in this memo, the following interpretations of the packet fields apply:
对于本备忘录中定义的暂停-恢复消息，以下数据包字段解释适用：
FMT: The FMT value identifying the PAUSE-RESUME FCI: 9
FMT：标识暂停-恢复FCI的FMT值：9
PT: Payload Type = 205 (RTPFB)
PT：有效载荷类型=205（RTPFB）
Length: As defined by AVPF, i.e., the length of this packet in 32-bit words minus one, including the header and any padding.
长度：由AVPF定义，即该数据包在32位字中的长度减去1，包括报头和任何填充。
SSRC of packet sender: The SSRC of the RTP session participant sending the messages in the FCI. Note, for endpoints that have multiple SSRCs in an RTP session, any of its SSRCs MAY be used to send any of the pause message types.
数据包发送方的SSRC：在FCI中发送消息的RTP会话参与者的SSRC。注意，对于在RTP会话中具有多个SSRC的端点，其任何SSRC均可用于发送任何暂停消息类型。
SSRC of media source: Not used; SHALL be set to 0. The FCI identifies the SSRC the message is targeted for.
媒体源SSRC：未使用；应设置为0。FCI识别消息的目标SSRC。
The FCI field consists of one or more PAUSE, RESUME, PAUSED, or REFUSED messages or any future extension. These messages have the following FCI format:
FCI字段由一个或多个暂停、恢复、暂停或拒绝的消息或任何未来扩展组成。这些消息具有以下FCI格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res | Parameter Len | PauseID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Type Specific :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res | Parameter Len | PauseID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Type Specific :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of FCI Entry in the PAUSE and RESUME Message
图6：暂停和恢复消息中FCI条目的语法
The FCI fields have the following definitions:
FCI字段具有以下定义：
Target SSRC (32 bits): For a PAUSE-RESUME message, this value is the SSRC that the request is intended for. For PAUSED, it MUST be the SSRC being paused. If pausing is the result of a PAUSE request, the value in PAUSED is effectively the same as Target SSRC in a related PAUSE request. For REFUSED, it MUST be the Target SSRC of the PAUSE or RESUME request that cannot change state. A CSRC MUST NOT be used as a target as the interpretation of such a request is unclear.
目标SSRC（32位）：对于PAUSE-RESUME消息，此值是请求的目标SSRC。对于暂停，必须是正在暂停的SSRC。如果暂停是暂停请求的结果，则暂停中的值实际上与相关暂停请求中的目标SSRC相同。对于拒绝，它必须是无法更改状态的暂停或恢复请求的目标SSRC。不得将中国证监会用作目标，因为对此类请求的解释不明确。
Type (4 bits): The pause feedback type. The values defined in this specification are as follows:
类型（4位）：暂停反馈类型。本规范中定义的值如下：
0: PAUSE request message.
0:暂停请求消息。
1: RESUME request message.
1：恢复请求消息。
2: PAUSED indication message.
2：暂停指示消息。
3: REFUSED notification message.
3：拒绝通知消息。
4-15: Reserved for future use. FCI fields with these Type values SHALL be ignored on reception by receivers and MUST NOT be used by senders implementing this specification.
4-15：保留供将来使用。接收器接收时，应忽略具有这些类型值的FCI字段，且实施本规范的发送者不得使用这些字段。
Res: (4 bits): Type Specific reserved. It SHALL be ignored by receivers implementing this specification and MUST be set to 0 by senders implementing this specification.
Res：（4位）：类型特定保留。实施本规范的接收方应忽略该值，且实施本规范的发送方必须将其设置为0。
Parameter Len (8 bits): Length of the Type Specific field in 32-bit words. MAY be 0.
参数Len（8位）：类型特定字段的长度（32位字）。可能是0。
PauseID (16 bits): Message sequence identification, as described in Section 5.2. SHALL be incremented by one modulo 2^16 for each new PAUSE message, unless the message is retransmitted. The initial value SHOULD be 0. The PauseID is scoped by the Target SSRC, meaning that PAUSE, RESUME, and PAUSED messages therefore share the same PauseID space for a specific Target SSRC.
PauseID（16位）：消息序列标识，如第5.2节所述。除非消息被重新传输，否则对于每个新的暂停消息，应增加一个模2^16。初始值应为0。PauseID的范围由目标SSRC确定，这意味着PAUSE、RESUME和PAUSED消息因此共享特定目标SSRC的相同PauseID空间。
Type Specific (variable): Defined per pause feedback type. MAY be empty. A receiver implementing this specification MUST be able to skip and ignore any unknown Type Specific data, even for Type values defined in this specification.
特定类型（变量）：根据暂停反馈类型定义。可能是空的。实现此规范的接收器必须能够跳过和忽略任何未知的特定于类型的数据，即使对于本规范中定义的类型值也是如此。
This section contains detailed explanations of each message defined in this specification. All transmissions of requests and indications are governed by the transmission rules as defined by Section 8.5.
本节包含本规范中定义的每条消息的详细说明。所有请求和指示的传输均受第8.5节规定的传输规则管辖。
Any references to PAUSE, PAUSED, RESUME, and REFUSED in this section SHALL be taken to apply to the extent possible and also when TMMBR/ TMMBN are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY be used instead of the messages defined in this specification when the effective topology is point to point. This use is expected to be mainly for interworking with implementations that don't support the messages defined in this specification but make use of TMMBR/TMMBN to achieve a similar effect. If either sender or receiver learns that the topology is not point to point, TMMBR/TMMBN MUST NOT be used for pause/resume functionality. If the messages defined in this specification are supported in addition to TMMBR/TMMBN by all involved parties, pause/resume signaling MUST use messages from this specification. If the topology is not point to point and the messages defined in this specification are not supported, pause/ resume functionality with TMMBR/TMMBN MUST NOT be used.
本节中对暂停、暂停、恢复和拒绝的任何引用应尽可能适用，并且在本功能使用TMMBR/TMMBN时（第5.6节）。当有效拓扑为点对点时，可以使用TMMBR/TMMBN代替本规范中定义的消息。此用途主要用于与不支持本规范中定义的消息但使用TMMBR/TMMBN实现类似效果的实现进行交互。如果发送方或接收方发现拓扑不是点对点的，则TMMBR/TMMBN不得用于暂停/恢复功能。如果除TMMBR/TMMBN外，所有相关方还支持本规范中定义的消息，则暂停/恢复信令必须使用本规范中的消息。如果拓扑不是点对点的，并且不支持本规范中定义的消息，则不得使用TMMBR/TMMBN的暂停/恢复功能。
For the scope of this specification, a past PauseID (Section 5.2) is defined as having a value between and including (PauseID - 2^15) MOD 2^16 and (PauseID - 1) MOD 2^16, where "MOD" is the modulo operator.
在本规范范围内，过去的PauseID（第5.2节）定义为具有介于（PauseID-2^15）MOD 2^16和（PauseID-1）MOD 2^16之间的值，其中“MOD”是模运算符。
Similarly, a future PauseID is defined as having a value between and including (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16. It is intentional that future PauseID is not defined as the entire range outside that of past PauseID. The remaining range of PauseID is simply "not current".
类似地，未来的PauseID定义为具有介于（PauseID+1）MOD 2^16和（PauseID+2^14）MOD 2^16之间的值。有意不将未来的PauseID定义为过去PauseID之外的整个范围。PauseID的剩余范围只是“非当前”。
An RTP stream receiver MAY schedule PAUSE for transmission at any time.
RTP流接收器可在任何时间调度用于传输的暂停。
PAUSE has no defined Type Specific parameters.
PAUSE没有定义特定于类型的参数。
PauseID SHOULD be the current PauseID, as indicated by PAUSED (Section 8.2), REFUSED (Section 8.4), or implicitly determined by previously received PAUSE or RESUME (Section 8.3) requests. A randomly chosen PauseID MAY be used if it was not possible to retrieve current PauseID information, in which case the PAUSE will either succeed or the current PauseID can be found in the returned REFUSED (Section 8.4).
PauseID应为当前PauseID，如暂停（第8.2节）、拒绝（第8.4节）或先前收到的暂停或恢复（第8.3节）请求所示。如果无法检索当前PauseID信息，则可以使用随机选择的PauseID，在这种情况下，暂停将成功，或者可以在返回的拒绝中找到当前PauseID（第8.4节）。
It can be noted that as a result of what is described in Section 6.1, PauseID is incremented by one, in modulo arithmetic, for each PAUSE request that is not a retransmission, compared to what was used in the last PAUSED indication sent by the media sender. PauseID in the message is supposed to match current PauseID at the RTP stream sender.
可以注意到，由于第6.1节所述，与媒体发送方发送的上一次暂停指示中使用的内容相比，对于不是重传的每个暂停请求，PauseID以模运算方式递增1。消息中的PauseID应该与RTP流发送方的当前PauseID匹配。
If an RTP stream receiver that sent a PAUSE with a certain PauseID for a Target SSRC receives a RESUME or a REFUSED with the same PauseID for the same Target SSRC, it is RECOMMENDED that it refrains from scheduling further PAUSE requests for some appropriate time. This is because the RESUME indicates that there are other receivers that still wish to receive the stream, and the REFUSED indicates that the RTP stream sender is currently not able to pause the stream. What is an appropriate time can vary from application to application and will also depend on the importance of achieving the bandwidth saving, but 2-5 regular RTCP intervals is expected to be appropriate.
如果为目标SSRC发送具有特定PauseID的暂停的RTP流接收器接收到相同目标SSRC具有相同PauseID的恢复或拒绝，建议其在适当的时间内避免安排进一步的暂停请求。这是因为RESUME表示还有其他接收者仍然希望接收流，而拒绝表示RTP流发送者当前无法暂停流。什么是合适的时间可能因应用程序而异，也取决于实现带宽节约的重要性，但预计2-5个定期RTCP间隔是合适的。
If the targeted RTP stream does not pause, if no PAUSED indication with a future PauseID compared to the one used in PAUSE is received, and if no REFUSED with the current or a future PauseID is received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled for retransmission, using the same current PauseID. RTT is the observed round trip to the RTP stream sender, and T_dither_max is defined in Section 3.4 of [RFC4585]. An RTP stream receiver in a bi-directional RTP communication will generally have an RTT estimate to the RTP stream sender, e.g., from RTCP SR/RR as described in Section 6.4 of
如果目标RTP流没有暂停，如果没有接收到与暂停中使用的暂停指示相比具有未来暂停标识的暂停指示，并且如果在2*RTT+T_抖动_max内没有接收到当前或未来暂停标识的拒绝，则可以使用相同的当前暂停标识来调度暂停以重新传输。RTT是观察到的到RTP流发送器的往返行程，T_抖动_max在[RFC4585]的第3.4节中定义。双向RTP通信中的RTP流接收器通常具有对RTP流发送器的RTT估计，例如，如本协议第6.4节所述，来自RTCP SR/RR
[RFC3550]. However, RTP stream receivers that don't send any RTP streams will lack an RTT estimate unless they use additional mechanisms, such as the "Receiver Reference Time Report Block" part of RTCP XR [RFC3611]. RTP stream receivers that lack an RTT estimate to the sender SHOULD use 500 ms as the default value.
[RFC3550]。但是，不发送任何RTP流的RTP流接收器将缺少RTT估计值，除非它们使用其他机制，如RTCP XR[RFC3611]的“接收器参考时间报告块”部分。缺少对发送方的RTT估计的RTP流接收器应使用500 ms作为默认值。
When an RTP stream sender in playing state (Section 6.1) receives a PAUSE with the current PauseID, and unless local considerations currently make it impossible to pause the stream, it SHALL enter pausing state (Section 6.2) and act accordingly.
当处于播放状态（第6.1节）的RTP流发送器接收到带有当前PauseID的暂停时，除非当前本地因素导致无法暂停流，否则其应进入暂停状态（第6.2节）并相应采取行动。
If an RTP stream sender receives a PAUSE with the current PauseID while in pausing, paused (Section 6.3), or local paused (Section 6.4) states, the received PAUSE SHALL be ignored.
如果RTP流发送器在暂停、暂停（第6.3节）或本地暂停（第6.4节）状态下接收到带有当前PauseID的暂停，则应忽略接收到的暂停。
The PAUSED indication, if supported, MUST be sent whenever entering paused state (Section 6.3) or local paused state (Section 6.4).
如果支持暂停指示，则必须在进入暂停状态（第6.3节）或本地暂停状态（第6.4节）时发送暂停指示。
PauseID in the PAUSED message MUST contain the current PauseID that can be included in a subsequent RESUME (Section 8.3). For local paused state, this means that PauseID in the message is the current PauseID, just as if the RTP stream sender had sent a PAUSE to itself.
暂停消息中的PauseID必须包含可包含在后续简历中的当前PauseID（第8.3节）。对于本地暂停状态，这意味着消息中的PauseID是当前的PauseID，就像RTP流发送器向自身发送了暂停一样。
PAUSED SHALL contain a fixed-length 32-bit parameter at the start of the Type Specific field with the extended RTP sequence number of the last RTP packet sent before the RTP stream was paused, in the same format as the extended highest sequence number received (Section 6.4.1 of [RFC3550]).
暂停应在类型特定字段的开头包含一个固定长度的32位参数，该参数具有RTP流暂停前发送的最后一个RTP数据包的扩展RTP序列号，格式与接收到的扩展最高序列号相同（RFC3550第6.4.1节）。
After having entered paused or local paused state and thus having sent PAUSED once, PAUSED MUST also be included in (at least) the next two regular RTCP reports, given that the pause condition is then still effective.
在进入暂停或本地暂停状态并因此发送暂停一次后，如果暂停条件仍然有效，则暂停也必须包括在（至少）下两个常规RTCP报告中。
PAUSED indications MAY be retransmitted, subject to transmission rules (Section 8.5), to increase the probability that the message reaches the receiver in a timely fashion. This can be especially important when entering local paused state. The number of repetitions to use could be tuned to observed loss rate and desired loss probability, for example, based on RTCP reports received from the intended message target.
暂停的指示可根据传输规则（第8.5节）重新传输，以增加消息及时到达接收器的概率。这在进入本地暂停状态时尤为重要。可根据观察到的丢失率和期望的丢失概率（例如，基于从预期消息目标接收到的RTCP报告）调整要使用的重复次数。
While remaining in paused or local paused states, PAUSED MAY be included in all compound RTCP reports, as long as the negotiated RTCP bandwidth is not exceeded.
在保持暂停或本地暂停状态时，暂停可包括在所有复合RTCP报告中，只要不超过协商的RTCP带宽。
When in paused or local paused states, whenever the RTP stream sender learns that there are endpoints that did not previously receive the stream, for example, by RTCP reports with an SSRC and a CNAME that were not previously seen in the RTP session, it is RECOMMENDED to send PAUSED at the earliest opportunity and also to include it in (at least) the next two regular RTCP reports, given that the pause condition is then still effective.
当处于暂停或本地暂停状态时，无论何时RTP流发送方得知存在以前未接收流的端点（例如，通过RTP会话中以前未看到的带有SSRC和CNAME的RTCP报告），建议尽早发送暂停，并将其包括在（至少）接下来的两个常规RTCP报告，假设暂停条件仍然有效。
An RTP stream receiver MAY schedule RESUME for transmission whenever it wishes to resume a paused stream or disapprove a stream from being paused.
RTP流接收器可在其希望恢复暂停的流或不批准暂停的流时，安排恢复传输。
PauseID SHOULD be the current PauseID, as indicated by PAUSED (Section 8.2) or implicitly determined by previously received PAUSE (Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be used if it was not possible to retrieve current PauseID information, in which case the RESUME will either succeed or the current PauseID can be found in a returned REFUSED (Section 8.4).
PauseID应为当前PauseID，如暂停（第8.2节）所示，或由先前收到的暂停（第8.1节）或恢复请求隐式确定。如果无法检索当前PauseID信息，则可以使用随机选择的PauseID，在这种情况下，恢复将成功，或者可以在返回的拒绝中找到当前PauseID（第8.4节）。
If an RTP stream receiver that sent a RESUME with a certain PauseID receives a REFUSED with the same PauseID, it is RECOMMENDED that it refrains from scheduling further RESUME requests for some appropriate time since the REFUSE indicates that it is currently not possible to resume the stream. What is an appropriate time can vary from application to application and will also depend on the importance of resuming the stream, but 1-2 regular RTCP intervals is expected to be appropriate.
如果发送具有特定PauseID的恢复的RTP流接收器接收到具有相同PauseID的拒绝，建议其在适当的时间内避免安排进一步的恢复请求，因为拒绝指示当前无法恢复流。什么是合适的时间可能因应用程序而异，也取决于恢复流的重要性，但预计1-2个定期RTCP间隔是合适的。
RESUME requests MAY be retransmitted, subject to transmission rules (Section 8.5), to increase the probability that the message reaches the receiver in a timely fashion. The number of repetitions to use could be tuned to observed loss rate and desired loss probability, for example, based on RTCP reports received from the intended message target. Such retransmission SHOULD stop as soon as RTP packets from the targeted stream are received or when a REFUSED with the current PauseID for the targeted RTP stream is received.
根据传输规则（第8.5节），可以重新传输恢复请求，以增加消息及时到达接收器的概率。可根据观察到的丢失率和期望的丢失概率（例如，基于从预期消息目标接收到的RTCP报告）调整要使用的重复次数。一旦接收到来自目标流的RTP分组，或者当接收到针对目标RTP流的当前PauseID的拒绝时，这种重传就应该停止。
RESUME has no defined Type Specific parameters.
RESUME没有定义类型特定的参数。
When an RTP stream sender in pausing (Section 6.2), paused (Section 6.3), or local paused state (Section 6.4) receives a RESUME with the current PauseID, and unless local considerations currently make it impossible to resume the stream, it SHALL enter playing state (Section 6.1) and act accordingly. If the RTP stream sender is incapable of honoring a RESUME request with the current PauseID, or if it receives a RESUME request with a PauseID that is not the
当处于暂停状态（第6.2节）、暂停状态（第6.3节）或本地暂停状态（第6.4节）的RTP流发送器接收到带有当前暂停ID的恢复时，除非本地因素当前导致无法恢复流，否则其应进入播放状态（第6.1节）并相应采取行动。如果RTP流发送方无法使用当前的PauseID接受恢复请求，或者如果它接收到的恢复请求的PauseID不是当前的PauseID
current PauseID while in paused or pausing state, the RTP stream sender SHALL schedule a REFUSED message for transmission as specified below.
当前PauseID当处于暂停或暂停状态时，RTP流发送方应按照以下规定安排一条被拒绝的消息进行传输。
If an RTP stream sender in playing state receives a RESUME containing either the current PauseID or a past PauseID, the received RESUME SHALL be ignored.
如果处于播放状态的RTP流发送器接收到包含当前PauseID或过去PauseID的恢复，则应忽略接收到的恢复。
If an RTP stream sender receives a PAUSE (Section 8.1) or RESUME (Section 8.3) request containing the current PauseID, where the requested action cannot be fulfilled by the RTP stream sender due to some local consideration, it SHALL schedule transmission of a REFUSED notification containing the current PauseID from the rejected request.
如果RTP流发送方收到包含当前PauseID的暂停（第8.1节）或恢复（第8.3节）请求，且RTP流发送方由于某些本地考虑而无法完成请求的操作，则其应安排传输包含来自拒绝请求的当前PauseID的拒绝通知。
REFUSED has no defined Type Specific parameters.
拒绝没有定义类型特定的参数。
If an RTP stream sender receives a PAUSE or RESUME request with a PauseID that is not the current PauseID, it SHALL schedule a REFUSED notification containing the current PauseID, except if the RTP stream sender is in playing state and receives a RESUME with a past PauseID, in which case the RESUME SHALL be ignored.
如果RTP流发送方接收到的暂停或恢复请求的PauseID不是当前的PauseID，则其应安排包含当前PauseID的拒绝通知，除非RTP流发送方处于播放状态并接收到具有过去PauseID的恢复，在这种情况下，应忽略恢复。
If several PAUSE or RESUME requests that would render identical REFUSED notifications are received before the scheduled REFUSED is sent, duplicate REFUSED notifications MUST NOT be scheduled for transmission. This effectively lets a single REFUSED respond to several ineffective PAUSE or RESUME requests.
如果在发送计划的拒绝通知之前收到多个暂停或恢复请求，这些请求将呈现相同的拒绝通知，则不得计划传输重复的拒绝通知。这可以有效地让一个被拒绝的用户响应多个无效的暂停或恢复请求。
An RTP stream receiver that sent a PAUSE or RESUME request and receives a REFUSED containing the same PauseID as in the request SHOULD refrain from sending an identical request for some appropriate time to allow the condition that caused REFUSED to clear. For PAUSE, an appropriate time is suggested in Section 8.1. For RESUME, an appropriate time is suggested in Section 8.3.
发送暂停或恢复请求并接收包含与请求中相同PauseID的拒绝的RTP流接收器应在适当的时间内避免发送相同的请求，以允许导致拒绝清除的条件。对于暂停，第8.1节建议了适当的时间。对于简历，第8.3节建议了一个合适的时间。
An RTP stream receiver that sent a PAUSE or RESUME request and receives a REFUSED containing a PauseID different from the request MAY schedule another request using the PauseID from the REFUSED notification.
发送暂停或恢复请求并接收包含与请求不同的暂停ID的拒绝的RTP流接收器可以使用来自拒绝通知的暂停ID调度另一个请求。
The transmission of any RTCP feedback messages defined in this specification MUST follow the normal AVPF-defined timing rules and depend on the session's mode of operation.
本规范中定义的任何RTCP反馈消息的传输必须遵循AVPF定义的正常定时规则，并取决于会话的操作模式。
All messages defined in this specification, as well as TMMBR/TMMBN used for pause/resume purposes (Section 5.6), can use either Regular, Early, or Immediate timings but should make a trade-off between timely transmission (Section 4.1) and RTCP bandwidth consumption. This can be achieved by taking the following into consideration:
本规范中定义的所有消息，以及用于暂停/恢复目的的TMMBR/TMMBN（第5.6节），可以使用常规、早期或即时计时，但应在及时传输（第4.1节）和RTCP带宽消耗之间进行权衡。这可以通过考虑以下因素来实现：
o It is recommended that PAUSE use Early or Immediate timing, except for retransmissions where RTCP bandwidth can motivate the use of Regular timing.
o 建议暂停使用早期或即时计时，但RTCP带宽可促使使用常规计时的重传除外。
o The first transmission of PAUSED for each (non-wrapped) PauseID is recommended to be sent with Immediate or Early timing to stop unnecessary repetitions of PAUSE. It is recommended that subsequent transmissions of PAUSED for that PauseID use Regular timing to avoid excessive PAUSED RTCP bandwidth caused by multiple PAUSE requests.
o 建议立即或提前发送针对每个（非包装）PauseID的暂停的第一次传输，以停止不必要的暂停重复。建议为该PauseID暂停的后续传输使用常规定时，以避免多个暂停请求导致的过多暂停RTCP带宽。
o It is recommended that unsolicited PAUSED (sent when entering local paused state (Section 6.4)) always use Immediate or Early timing, until PAUSED for that PauseID is considered delivered at least once to all receivers of the paused RTP stream, to avoid RTP stream receivers that take unnecessary corrective action when the RTP stream is no longer received, after which it is recommended that PAUSE uses Regular timing (as for PAUSED triggered by PAUSE above).
o 建议未经请求的暂停（在进入本地暂停状态时发送（第6.4节））始终使用立即或提前计时，直到暂停ID被视为至少一次发送到暂停RTP流的所有接收器，为了避免RTP流接收器在不再接收RTP流时采取不必要的纠正措施，在此之后，建议暂停使用常规定时（对于由上面的暂停触发的暂停）。
o RESUME is often time critical, and it is recommended that it always uses Immediate or Early timing.
o 简历通常是时间关键型的，建议总是使用即时或提前的时间安排。
o The first transmission of REFUSED for each (non-wrapped) PauseID is recommended to be sent with Immediate or Early timing to stop unnecessary repetitions of PAUSE or RESUME. It is recommended that subsequent REFUSED notifications for that PauseID use Regular timing to avoid excessive REFUSED RTCP bandwidth caused by multiple unreasonable requests.
o 建议立即或提前发送每个（非包装）PauseID的第一次拒绝传输，以停止不必要的暂停或恢复重复。建议该PauseID的后续被拒绝通知使用常规定时，以避免多个不合理请求导致被拒绝的RTCP带宽过大。
The capability of handling messages defined in this specification MAY be exchanged at a higher layer such as SDP. This document extends the "rtcp-fb" attribute defined in Section 4 of AVPF [RFC4585] to include the request for pause and resume. This specification follows all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an "rtcp-fb" attribute relating to the payload type in a session description.
处理本规范中定义的消息的能力可以在更高的层（如SDP）上交换。本文档扩展了AVPF[RFC4585]第4节中定义的“rtcp fb”属性，以包括暂停和恢复请求。本规范遵循AVPF[RFC4585]和CCM[RFC5104]中为会话描述中与有效负载类型相关的“rtcp fb”属性定义的所有规则。
This specification defines a new parameter "pause" to the "ccm" feedback value defined in CCM [RFC5104], representing the capability to understand the RTCP feedback message and all of the defined FCIs of PAUSE, RESUME, PAUSED, and REFUSED.
本规范将新参数“pause”定义为ccm[RFC5104]中定义的“ccm”反馈值，表示理解RTCP反馈消息和所有定义的暂停、恢复、暂停和拒绝FCI的能力。
Note: When TMMBR 0 / TMMBN 0 are used to implement pause and resume functionality (with the restrictions described in this specification), signaling the "rtcp-fb" attribute with the "ccm" and "tmmbr" parameters is sufficient and no further signaling is necessary. There is, however, no guarantee that TMMBR/TMMBN implementations predating this specification work exactly as described here when used with a bitrate value of 0.
注：当TMMBR 0/TMMBN 0用于实现暂停和恢复功能（具有本规范中所述的限制）时，用“ccm”和“TMMBR”参数向“rtcp fb”属性发送信号就足够了，无需进一步发送信号。然而，当使用比特率值0时，不能保证本规范之前的TMMBR/TMMBN实现完全按照此处所述工作。
The "pause" parameter has two optional attributes, which are "nowait" and "config":
“pause”参数有两个可选属性，即“nowait”和“config”：
o "nowait" indicates that the hold-off period defined in Section 6.2 can be set to 0, reducing the latency before the stream can be paused after receiving a PAUSE request. This condition occurs when there will only be a single receiver per direction in the RTP session, for example, in point-to-point sessions. It is also possible to use in scenarios using unidirectional media. The conditions that allow "nowait" to be set (Section 6.2) also indicate that it would be possible to use CCM TMMBR/TMMBN as pause/resume signaling.
o “nowait”表示第6.2节中定义的延迟时间可以设置为0，从而减少在收到暂停请求后暂停流之前的延迟。当RTP会话（例如，在点到点会话中）中每个方向只有一个接收器时，就会出现这种情况。也可以在使用单向介质的场景中使用。允许设置“nowait”的条件（第6.2节）也表明可以使用CCM TMMBR/TMMBN作为暂停/恢复信令。
o "config" allows for partial implementation of this specification according to the different roles in the use-cases section (Section 3) and takes a value that describes what subset is implemented:
o “config”允许根据用例部分（第3部分）中的不同角色部分实现本规范，并采用一个描述实现的子集的值：
1 Full implementation of this specification. This is the default configuration. A missing "config" pause attribute MUST be treated equivalent to providing a "config" value of 1.
1本规范的全面实施。这是默认配置。缺少的“config”pause属性必须被视为等同于提供1的“config”值。
2 The implementation intends to send PAUSE and RESUME requests for received RTP streams and is thus also capable of receiving PAUSED and REFUSED. It does not support receiving PAUSE and RESUME requests, but it may pause sent RTP streams due to local considerations and then intend to send PAUSED for them.
2该实现旨在发送对接收到的RTP流的暂停和恢复请求，因此也能够接收暂停和拒绝的请求。它不支持接收暂停和恢复请求，但出于本地考虑，它可能会暂停发送的RTP流，然后打算为它们发送暂停的请求。
3 The implementation supports receiving PAUSE and RESUME requests targeted for RTP streams it sends. It will send PAUSED and REFUSED as needed. The node will not send any PAUSE and RESUME requests but supports and desires receiving PAUSED if received RTP streams are paused.
3该实现支持接收针对其发送的RTP流的暂停和恢复请求。它将根据需要发送暂停和拒绝。节点不会发送任何暂停和恢复请求，但支持并希望在接收到的RTP流暂停时接收暂停。
4 The implementation intends to send PAUSE and RESUME requests for received RTP streams and is thus also capable of receiving PAUSED and REFUSED. It cannot pause any RTP streams it sends, and thus does not support receiving PAUSE and RESUME requests, and it also does not support sending PAUSED indications.
4该实现旨在发送对接收到的RTP流的暂停和恢复请求，因此也能够接收暂停和拒绝的请求。它不能暂停发送的任何RTP流，因此不支持接收暂停和恢复请求，也不支持发送暂停指示。
5 The implementation supports receiving PAUSE and RESUME requests targeted for RTP streams it sends. It will send PAUSED and REFUSED as needed. It does not support sending PAUSE and RESUME requests to pause received RTP streams, and it also does not support receiving PAUSED indications.
5该实现支持接收针对其发送的RTP流的暂停和恢复请求。它将根据需要发送暂停和拒绝。它不支持发送暂停和恢复请求以暂停接收到的RTP流，也不支持接收暂停指示。
6 The implementation supports sent and received RTP streams being paused due to local considerations and thus supports sending and receiving PAUSED indications.
6该实现支持由于本地考虑而暂停发送和接收的RTP流，因此支持发送和接收暂停指示。
7 The implementation supports and desires to receive PAUSED indications for received RTP streams but does not pause or send PAUSED indications for sent RTP streams. It does not support any other messages defined in this specification.
7实现支持并希望接收已接收RTP流的暂停指示，但不暂停或发送已发送RTP流的暂停指示。它不支持本规范中定义的任何其他消息。
8 The implementation supports pausing sent RTP streams and sending PAUSED indications for them but does not support receiving PAUSED indications for received RTP streams. It does not support any other messages defined in this specification.
8该实现支持暂停发送的RTP流并为其发送暂停指示，但不支持接收接收的RTP流的暂停指示。它不支持本规范中定义的任何其他消息。
All implementers of this specification are encouraged to include full support for all messages ("config=1"), but it is recognized that this is sometimes not meaningful for implementations operating in an environment where only parts of the functionality provided by this specification are needed. The above defined "config" functionality subsets provide a trade-off between completeness and the need for implementation interoperability, achieving at least a level of functionality corresponding to what is desired by the least-capable party when used as specified here. Implementing any functionality subsets other than those defined above is NOT RECOMMENDED.
鼓励本规范的所有实现者包括对所有消息的完全支持（“config=1”），但要认识到，对于在只需要本规范提供的部分功能的环境中运行的实现，这有时是没有意义的。上述定义的“配置”功能子集提供了完整性和实现互操作性需求之间的折衷，实现了至少一个与最低能力方在此处指定使用时所需的功能级别相对应的功能。不建议实现除上述定义之外的任何功能子集。
When signaling a "config" value other than 1, an implementation MUST ignore non-supported messages on reception and SHOULD omit sending messages not supported by the remote peer. One example where it can be motivated to send messages that some receivers do not support is when there are multiple message receivers with different message support (different "config" values). That approach avoids letting the least-capable receiver limit the functionality provided to others. The below table summarizes per-message send and receive support for the different "config" pause attribute values ("X" indicating support and "-" indicating non-support):
当发送非1的“config”值时，实现必须在接收时忽略不支持的消息，并且应该忽略发送远程对等方不支持的消息。当有多个具有不同消息支持（不同的“配置”值）的消息接收器时，可以激发发送某些接收器不支持的消息的一个示例。这种方法避免了让能力最低的接收器限制提供给其他人的功能。下表总结了每条消息发送和接收对不同“配置”暂停属性值的支持（“X”表示支持，“-”表示不支持）：
+---+-----------------------------+-----------------------------+
| # | Send | Receive |
| | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED |
+---+-----------------------------+-----------------------------+
| 1 | X X X X | X X X X |
| 2 | X X X - | - - X X |
| 3 | - - X X | X X X - |
| 4 | X X - - | - - X X |
| 5 | - - X X | X X - - |
| 6 | - - X - | - - X - |
| 7 | - - - - | - - X - |
| 8 | - - X - | - - - - |
+---+-----------------------------+-----------------------------+
+---+-----------------------------+-----------------------------+
| # | Send | Receive |
| | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED |
+---+-----------------------------+-----------------------------+
| 1 | X X X X | X X X X |
| 2 | X X X - | - - X X |
| 3 | - - X X | X X X - |
| 4 | X X - - | - - X X |
| 5 | - - X X | X X - - |
| 6 | - - X - | - - X - |
| 7 | - - - - | - - X - |
| 8 | - - X - | - - - - |
+---+-----------------------------+-----------------------------+
Figure 7: Supported Messages for Different "config" Values
图7：不同“配置”值支持的消息
In the above description of partial implementations, "config" values 2 and 4 correspond to the RTP Mixer in the 'RTP Mixer to Media Sender' use case (Section 3.2), and "config" values 3 and 5 correspond to the media sender in that same use case. For that use case, it should be clear that an RTP Mixer implementing only "config" values 3 or 5 will not provide a working solution. Similarly, for that use case, a media sender implementing only "config" values 2 or 4 will not provide a working solution. Both the RTP Mixer and the media sender will of course work when implementing the full set of messages, corresponding to "config=1".
在上述部分实现的描述中，“config”值2和4对应于“RTP Mixer to Media Sender”用例（第3.2节）中的RTP Mixer，“config”值3和5对应于同一用例中的媒体发送器。对于该用例，应该清楚的是，仅实现“配置”值3或5的RTP混频器不会提供有效的解决方案。类似地，对于该用例，仅实现“配置”值2或4的媒体发送器不会提供有效的解决方案。当实现与“config=1”对应的完整消息集时，RTP混合器和媒体发送器当然都可以工作。
A partial implementation is not suitable for pause/resume support between cascaded RTP Mixers, but it would require support corresponding to "config=1" between such RTP Mixers. This is because an RTP Mixer is then also a media sender towards the other RTP Mixer, requiring support for the union of "config" values 2 and 3 or "config" values 4 and 5, which effectively becomes "config=1".
部分实现不适用于级联RTP混频器之间的暂停/恢复支持，但它需要与此类RTP混频器之间的“config=1”对应的支持。这是因为RTP混频器同时也是另一个RTP混频器的媒体发送器，需要支持“配置”值2和3或“配置”值4和5的并集，这实际上变成了“配置=1”。
As can be seen from Figure 7 above, "config" values 2 and 3 differ from "config" values 4 and 5 only in that in the latter, the PAUSE/ RESUME message sender (e.g., the RTP Mixer side) does not support local pause (Section 6.4) for any of its own streams and therefore also does not support sending PAUSED.
从上面的图7可以看出，“配置”值2和3与“配置”值4和5的不同之处在于，在后者中，暂停/恢复消息发送方（例如RTP混音器端）不支持其自身任何流的本地暂停（第6.4节），因此也不支持发送暂停。
Partial implementations that only support local pause functionality can declare this capability through "config" values 6-8.
仅支持本地暂停功能的部分实现可以通过“配置”值6-8声明此功能。
Viable fallback rules between different "config" values are described in Section 9.1 and Figure 9.
第9.1节和图9描述了不同“配置”值之间可行的回退规则。
This is the resulting ABNF [RFC5234], extending the existing ABNF in Section 7.1 of CCM [RFC5104]:
这是产生的ABNF[RFC5234]，扩展了CCM[RFC5104]第7.1节中的现有ABNF：
rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr)
pause-attr = pause-config ; partial message support
/ "nowait" ; no hold-off period
/ byte-string ; for future extensions
pause-config = "config=" pause-config-value
pause-config-value = 1*2DIGIT
; byte-string as defined in RFC 4566
rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr)
pause-attr = pause-config ; partial message support
/ "nowait" ; no hold-off period
/ byte-string ; for future extensions
pause-config = "config=" pause-config-value
pause-config-value = 1*2DIGIT
; byte-string as defined in RFC 4566
Figure 8: ABNF
图8:ABNF
An endpoint implementing this specification and using SDP to signal capability SHOULD indicate the new "pause" parameter with "ccm" signaling but MAY instead use existing "ccm tmmbr" signaling [RFC5104] if the limitations in functionality when using TMMBR/TMMBN as described in this specification (Section 5.6) are considered acceptable. In that case, no partial message support is possible. The messages from this specification (Section 8) SHOULD NOT be used towards receivers that did not declare capability to receive those messages.
实施本规范并使用SDP发送信号的端点应使用“ccm”信令指示新的“暂停”参数，但如果使用本规范（第5.6节）所述tmmbr/TMMBN时的功能限制被认为是可接受的，则可以使用现有的“ccm tmmbr”信令[RFC5104]。在这种情况下，不可能提供部分消息支持。本规范（第8节）中的消息不应用于未声明有能力接收这些消息的接收器。
The pause functionality can normally be expected to work independently of the payload type. However, there might exist situations where an endpoint needs to restrict or at least configure the capabilities differently depending on the payload type carrying the media stream. Reasons for this might relate to capabilities to correctly handle media boundaries and avoid any pause or resume operation to occur where it would leave a receiver or decoder with no choice than to attempt to repair or discard the media received just prior to or at the point of resuming.
暂停功能通常可以独立于有效负载类型工作。然而，可能存在端点需要根据承载媒体流的有效负载类型以不同方式限制或至少配置功能的情况。其原因可能与正确处理媒体边界和避免任何暂停或恢复操作的能力有关，如果暂停或恢复操作会使接收器或解码器除了在恢复之前或恢复时尝试修复或丢弃接收到的媒体之外别无选择。
There MUST NOT be more than one "a=rtcp-fb" line with "pause" applicable to a single payload type in the SDP, unless the additional line uses "*" as the payload type, in which case "*" SHALL be interpreted as applicable to all listed payload types that do not have an explicit "pause" specification. The "config" pause attribute MUST NOT appear more than once for each "pause" CCM parameter. The "nowait" pause attribute MUST NOT appear more than once for each "pause" CCM parameter.
对于SDP中的单个有效负载类型，不得有多条带有“暂停”的“a=rtcp fb”行，除非附加行使用“*”作为有效负载类型，在这种情况下，“*”应解释为适用于所有列出的没有明确“暂停”规范的有效负载类型。对于每个“暂停”CCM参数，“配置”暂停属性不得出现一次以上。对于每个“暂停”CCM参数，“nowait”暂停属性不得出现一次以上。
An offerer implementing this specification needs to include the "pause" CCM parameter with a suitable configuration attribute ("config") in the SDP, according to what messages it intends to send and desires to receive in the session.
实施本规范的报价人需要根据其在会话中打算发送和希望接收的消息，在SDP中包括具有适当配置属性（“config”）的“pause”CCM参数。
In SDP offer/answer, the "config" pause attribute and its message directions are interpreted based on the agent providing the SDP. The offerer is described in an offer, and the answerer is described in an answer.
在SDP offer/answer中，“config”pause属性及其消息方向根据提供SDP的代理进行解释。要约人在要约中被描述，回答人在回答中被描述。
An answerer receiving an offer with a "pause" CCM line and a "config" pause attribute with a certain value, describing a certain capability to send and receive messages, MAY change the "config" pause attribute value in the answer to another configuration. The permitted answers are listed in the below table.
应答者收到带有“暂停”CCM行和具有特定值的“配置”暂停属性（描述发送和接收消息的特定能力）的要约时，可将应答中的“配置”暂停属性值更改为另一配置。下表列出了允许的答案。
SDP Offer "config" value | Permitted SDP Answer "config" values
-------------------------+-------------------------------------
1 | 1, 2, 3, 4, 5, 6, 7, 8
2 | 3, 4, 5, 6, 7, 8
3 | 2, 4, 5, 6, 7, 8
4 | 5, 6, 7, 8
5 | 4, 6, 7, 8
6 | 6, 7, 8
7 | 8
8 | 7
SDP Offer "config" value | Permitted SDP Answer "config" values
-------------------------+-------------------------------------
1 | 1, 2, 3, 4, 5, 6, 7, 8
2 | 3, 4, 5, 6, 7, 8
3 | 2, 4, 5, 6, 7, 8
4 | 5, 6, 7, 8
5 | 4, 6, 7, 8
6 | 6, 7, 8
7 | 8
8 | 7
Figure 9: "config" Values in Offer/Answer
图9：报价/应答中的“配置”值
An offer or answer omitting the "config" pause attribute MUST be interpreted as equivalent to "config=1". Implementations of this specification MUST NOT use any "config" values other than those defined above in an offer or answer and MUST remove the "pause" CCM line in the answer when receiving an offer with a "config" value it does not understand. In all cases, the answerer MAY also completely remove any "pause" CCM line to indicate that it does not understand or desire to use any pause functionality for the affected payload types.
省略“config”pause属性的报价或应答必须解释为等同于“config=1”。本规范的实施不得使用除上述报价或应答中定义的值以外的任何“配置”值，并且在接收到不理解“配置”值的报价时，必须删除应答中的“暂停”CCM行。在所有情况下，应答者也可完全移除任何“暂停”CCM行，以表明其不理解或不希望对受影响的有效负载类型使用任何暂停功能。
If the offerer believes that itself and the intended answerer are likely the only endpoints in the RTP session, it MAY include the "nowait" pause attribute on the "pause" line in the offer. If an answerer receives the "nowait" pause attribute on the "pause" line in the SDP, and if it has information that the offerer and itself are not the only endpoints in the RTP session, it MUST NOT include any "nowait" pause attribute on its "pause" line in the SDP answer. The answerer MUST NOT add "nowait" on the "pause" line in the answer unless it is present on the "pause" line in the offer. If both offer and answer contain a "nowait" pause attribute, then the hold-off period is configured to 0 at both the offerer and answerer.
如果报价人认为自己和预期应答人可能是RTP会话中的唯一端点，则报价中的“暂停”行中可能包含“nowait”暂停属性。如果应答者在SDP中的“暂停”行上接收到“nowait”暂停属性，并且如果其有信息表明报价人及其自身不是RTP会话中的唯一端点，则其在SDP应答中的“暂停”行上不得包含任何“nowait”暂停属性。回答者不得在回答的“暂停”行中添加“nowait”，除非其出现在报价的“暂停”行中。如果报价和应答都包含“nowait”暂停属性，则报价人和应答人的延迟时间都配置为0。
Unknown pause attributes MUST be ignored in the offer and MUST then be omitted from the answer.
在报价中必须忽略未知的暂停属性，然后必须从答案中忽略。
If both "pause" and "tmmbr" are present in the offer, both MAY be included also in the answer, in which case TMMBR/TMMBN MUST NOT be used for pause/resume purposes (with a bitrate value of 0), to avoid signaling ambiguity.
如果报价中同时存在“暂停”和“tmmbr”，则答案中也可能包含这两个选项，在这种情况下，tmmbr/TMMBN不得用于暂停/恢复目的（比特率值为0），以避免信号歧义。
In declarative use, the SDP is used to configure the node receiving the SDP. This has implications on the interpretation of the SDP signaling extensions defined in this specification.
在声明性使用中，SDP用于配置接收SDP的节点。这对本规范中定义的SDP信令扩展的解释有影响。
First, the "config" pause attribute and its message directions are interpreted based on the node receiving the SDP, and it describes the RECOMMENDED level of operation. If the joining client does not support the indicated "config" value, some RTP session stream optimizations may not be possible in that some RTP streams will not be paused by the joining client, and/or the joining client may not be able to resume and receive wanted streams because they are paused.
首先，根据接收SDP的节点解释“config”pause属性及其消息方向，并描述建议的操作级别。如果加入客户端不支持指示的“config”值，则某些RTP会话流优化可能不可能，因为加入客户端不会暂停某些RTP流，和/或加入客户端可能无法恢复和接收所需流，因为它们已暂停。
Second, the "nowait" pause attribute, if included, is followed as specified. It is the responsibility of the declarative SDP sender to determine if a configured node will participate in a session that will be point to point, based on the usage. For example, a conference client being configured for an any source multicast session using the Session Announcement Protocol (SAP) [RFC2974] will not be in a point-to-point session, thus "nowait" cannot be included. A Real-Time Streaming Protocol (RTSP) [RFC2326] client receiving a declarative SDP may very well be in a point-to-point session, although it is highly doubtful that an RTSP client would need to support this specification, considering the inherent PAUSE support in RTSP.
其次，如果包含“nowait”pause属性，则按照指定的顺序执行。声明性SDP发送方负责根据使用情况确定已配置的节点是否将参与点对点会话。例如，使用会话公告协议（SAP）[RFC2974]为任何源多播会话配置的会议客户端将不在点对点会话中，因此不能包括“nowait”。接收声明性SDP的实时流协议（RTSP）[RFC2326]客户机很可能处于点对点会话中，尽管考虑到RTSP中固有的暂停支持，RTSP客户机是否需要支持此规范是非常值得怀疑的。
Unknown pause attributes MUST be ignored.
必须忽略未知的暂停属性。
If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST NOT be used for pause/resume purposes (with a bitrate value of 0) to avoid signaling ambiguity.
如果SDP中同时存在“pause”和“tmmbr”，则tmmbr/TMMBN不得用于暂停/恢复目的（比特率值为0），以避免信号歧义。
The following examples show use of PAUSE and RESUME messages, including use of offer/answer:
以下示例显示了暂停和恢复消息的使用，包括提供/应答的使用：
1. Offer/Answer
1. 提议/答复
2. Point-to-Point Session
2. 点对点会话
3. Point to Multipoint using Mixer
3. 使用混频器的点对多点
4. Point to Multipoint using Relay
4. 使用继电器的点对多点
The below figures contain an example of how to show support for pausing and resuming the streams, as well as indicating whether or not the hold-off period can be set to 0.
下图包含一个示例，说明如何显示对暂停和恢复流的支持，以及指示是否可以将延迟时间设置为0。
v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media
t=0 0
c=IN IP4 alice.example.com
m=audio 49170 RTP/AVPF 98 99
a=rtpmap:98 G719/48000
a=rtpmap:99 PCMA/8000
a=rtcp-fb:* ccm pause nowait
v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media
t=0 0
c=IN IP4 alice.example.com
m=audio 49170 RTP/AVPF 98 99
a=rtpmap:98 G719/48000
a=rtpmap:99 PCMA/8000
a=rtcp-fb:* ccm pause nowait
Figure 10: SDP Offer with Pause and Resume Capability
图10：具有暂停和恢复功能的SDP产品
The offerer supports all of the messages defined in this specification, leaving out the optional "config" pause attribute. The offerer also believes that it will be the sole receiver of the answerer's stream as well as that the answerer will be the sole receiver of the offerer's stream and thus includes the "nowait" pause attribute for the "pause" parameter.
报价人支持本规范中定义的所有消息，省略可选的“config”pause属性。报价人还认为其将是应答人流的唯一接收者，以及应答人将是报价人流的唯一接收者，因此包括“暂停”参数的“nowait”暂停属性。
This is the SDP answer:
这是SDP的答案：
v=0
o=bob 293847192 293847192 IN IP4 bob.example.com
s=-
t=0 0
c=IN IP4 bob.example.com
m=audio 49202 RTP/AVPF 98
a=rtpmap:98 G719/48000
a=rtcp-fb:98 ccm pause config=2
v=0
o=bob 293847192 293847192 IN IP4 bob.example.com
s=-
t=0 0
c=IN IP4 bob.example.com
m=audio 49202 RTP/AVPF 98
a=rtpmap:98 G719/48000
a=rtcp-fb:98 ccm pause config=2
Figure 11: SDP Answer with Pause and Resume Capability
图11：具有暂停和恢复功能的SDP应答
The answerer will not allow its sent streams to be paused or resumed and thus restricts the answer to indicate "config=2". It also supports pausing its own RTP streams due to local considerations, which is why "config=2" is chosen rather than "config=4". The answerer somehow knows that it will not be a point-to-point RTP session and has therefore removed "nowait" from the "pause" line, meaning that the offerer must use a non-zero hold-off period when being requested to pause the stream.
应答器将不允许暂停或恢复其发送的流，因此将应答限制为指示“config=2”。由于本地因素，它还支持暂停自己的RTP流，这就是为什么选择“config=2”而不是“config=4”。应答者不知何故知道这不是点对点RTP会话，因此从“暂停”行中删除了“nowait”，这意味着在请求暂停流时，报价人必须使用非零延迟时间。
When using TMMBR 0 / TMMBN 0 to achieve pause and resume functionality, there are no differences in SDP compared to CCM [RFC5104]; therefore, no such examples are included here.
当使用TMMBR 0/TMMBN 0实现暂停和恢复功能时，SDP与CCM[RFC5104]相比没有差异；因此，此处不包括此类示例。
This is the most basic scenario, which involves two participants, each acting as a sender and/or receiver. Any RTP data receiver sends PAUSE or RESUME messages to the sender, which pauses or resumes transmission accordingly. The hold-off period before pausing a stream is 0.
这是最基本的场景，涉及两个参与者，每个参与者充当发送者和/或接收者。任何RTP数据接收器向发送方发送暂停或恢复消息，发送方相应地暂停或恢复传输。暂停流之前的延迟时间为0。
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| -------------------------------> |
| t2: PAUSE(3) |
| <------------------------------- |
| < RTP data paused > |
| t3: PAUSED(3) |
| -------------------------------> |
: < Some time passes > :
| t4: RESUME(3) |
| <------------------------------- |
| t5: RTP data |
| -------------------------------> |
: < Some time passes > :
| t6: PAUSE(4) |
| <------------------------------- |
| < RTP data paused > |
| t7: PAUSED(4) |
| -------------------------------> |
: :
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| -------------------------------> |
| t2: PAUSE(3) |
| <------------------------------- |
| < RTP data paused > |
| t3: PAUSED(3) |
| -------------------------------> |
: < Some time passes > :
| t4: RESUME(3) |
| <------------------------------- |
| t5: RTP data |
| -------------------------------> |
: < Some time passes > :
| t6: PAUSE(4) |
| <------------------------------- |
| < RTP data paused > |
| t7: PAUSED(4) |
| -------------------------------> |
: :
Figure 12: Pause and Resume Operation in Point to Point
图12：点对点暂停和恢复操作
Figure 12 shows the basic pause and resume operation in a point-to-point scenario. At time t1, an RTP sender sends data to a receiver. At time t2, the RTP receiver requests the sender to pause the stream, using PauseID 3 (which it knew since before in this example). The sender pauses the data and replies with a PAUSED containing the same PauseID. Some time later (at time t4), the receiver requests the sender to resume, which resumes its transmission. The next PAUSE, sent at time t6, contains an updated PauseID (4), with a corresponding PAUSED being sent at time t7.
图12显示了点到点场景中的基本暂停和恢复操作。在时间t1，RTP发送方向接收方发送数据。在时间t2，RTP接收器使用pauseid3（在本例中，它从之前就知道）请求发送方暂停流。发送方暂停数据，并使用包含相同PauseID的暂停回复。一段时间后（在时间t4），接收机请求发送方恢复，发送方恢复其传输。在时间t6发送的下一个暂停包含更新的PauseID（4），相应的暂停在时间t7发送。
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| -------------------------------> |
| t2: TMMBR 0 |
| <------------------------------- |
| < RTP data paused > |
| t3: TMMBN 0 |
| -------------------------------> |
: < Some time passes > :
| t4: TMMBR 150000 |
| <------------------------------- |
| t5: RTP data |
| -------------------------------> |
: < Some time passes > :
| t6: TMMBR 0 |
| <------------------------------- |
| < RTP data paused > |
| t7: TMMBN 0 |
| -------------------------------> |
: :
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| -------------------------------> |
| t2: TMMBR 0 |
| <------------------------------- |
| < RTP data paused > |
| t3: TMMBN 0 |
| -------------------------------> |
: < Some time passes > :
| t4: TMMBR 150000 |
| <------------------------------- |
| t5: RTP data |
| -------------------------------> |
: < Some time passes > :
| t6: TMMBR 0 |
| <------------------------------- |
| < RTP data paused > |
| t7: TMMBN 0 |
| -------------------------------> |
: :
Figure 13: TMMBR Pause and Resume in Point to Point
图13:TMMBR点对点暂停和恢复
Figure 13 describes the same point-to-point scenario as above, but using TMMBR/TMMBN signaling.
图13描述了与上述相同的点对点场景，但使用了TMMBR/TMMBN信令。
+---------------+ +----------------+
| RTP Sender A | | RTP Receiver B |
+---------------+ +----------------+
: t1: RTP data :
| -------------------------------> |
| < RTP data paused > |
| t2: TMMBN {A:0} |
| -------------------------------> |
: < Some time passes > :
| t3: TMMBR 0 |
| <------------------------------- |
| t4: TMMBN {A:0,B:0} |
| -------------------------------> |
: < Some time passes > :
| t5: TMMBN {B:0} |
| -------------------------------> |
: < Some time passes > :
| t6: TMMBR 80000 |
| <------------------------------- |
| t7: RTP data |
| -------------------------------> |
: :
+---------------+ +----------------+
| RTP Sender A | | RTP Receiver B |
+---------------+ +----------------+
: t1: RTP data :
| -------------------------------> |
| < RTP data paused > |
| t2: TMMBN {A:0} |
| -------------------------------> |
: < Some time passes > :
| t3: TMMBR 0 |
| <------------------------------- |
| t4: TMMBN {A:0,B:0} |
| -------------------------------> |
: < Some time passes > :
| t5: TMMBN {B:0} |
| -------------------------------> |
: < Some time passes > :
| t6: TMMBR 80000 |
| <------------------------------- |
| t7: RTP data |
| -------------------------------> |
: :
Figure 14: Unsolicited PAUSED Using TMMBN
图14：使用TMMBN的非请求暂停
Figure 14 describes the case when an RTP stream sender (A) chooses to pause an RTP stream due to local considerations. Both A and the RTP stream receiver (B) use TMMBR/TMMBN signaling for pause/resume purposes. A decides to pause the RTP stream at time t2 and uses TMMBN 0 to signal PAUSED, including itself in the TMMBN bounding set. At time t3, despite the fact that the RTP stream is still paused, B decides that it is no longer interested in receiving the RTP stream and signals PAUSE by sending a TMMBR 0. As a result of that, the bounding set now contains both A and B, and A sends out a new TMMBN reflecting that. After a while, at time t5, the local considerations that caused A to pause the RTP stream no longer apply, causing it to remove itself from the bounding set and to send a new TMMBN indicating this. At time t6, B decides that it is now interested in receiving the RTP stream again and signals RESUME by sending a TMMBR containing a bitrate value greater than 0, causing A to resume sending RTP data.
图14描述了RTP流发送器（A）出于本地考虑而选择暂停RTP流的情况。A和RTP流接收器（B）都使用TMMBR/TMMBN信令进行暂停/恢复。A决定在时刻t2暂停RTP流，并使用TMMBN 0来发出暂停信号，包括其自身在TMMBN边界集中。在时刻t3，尽管RTP流仍然被暂停，但是B确定其不再对接收RTP流感兴趣，并且通过发送TMMBR 0来暂停信号。因此，边界集现在同时包含a和B，a发送一个新的TMMBN来反映这一点。一段时间后，在时间t5，导致暂停RTP流的本地注意事项不再适用，导致其从边界集移除自身并发送指示这一点的新TMMBN。在时间t6，B决定它现在有兴趣再次接收RTP流，并且通过发送包含比特率值大于0的TMMBR来恢复信号，使得a恢复发送RTP数据。
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------------> |
| t2: PAUSE(7), lost |
| <---X-------------- |
| |
| t3: RTP data |
| ------------------------------------> |
: :
| < Time-out, still receiving data > |
| t4: PAUSE(7) |
| <------------------------------------ |
| < RTP data paused > |
| t5: PAUSED(7) |
| ------------------------------------> |
: < Some time passes > :
| t6: RESUME(7), lost |
| <---X-------------- |
| t7: RESUME(7) |
| <------------------------------------ |
| t8: RTP data |
| ------------------------------------> |
| t9: RESUME(7) |
| <------------------------------------ |
: :
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------------> |
| t2: PAUSE(7), lost |
| <---X-------------- |
| |
| t3: RTP data |
| ------------------------------------> |
: :
| < Time-out, still receiving data > |
| t4: PAUSE(7) |
| <------------------------------------ |
| < RTP data paused > |
| t5: PAUSED(7) |
| ------------------------------------> |
: < Some time passes > :
| t6: RESUME(7), lost |
| <---X-------------- |
| t7: RESUME(7) |
| <------------------------------------ |
| t8: RTP data |
| ------------------------------------> |
| t9: RESUME(7) |
| <------------------------------------ |
: :
Figure 15: Pause and Resume Operation with Messages Lost
图15：消息丢失时暂停和恢复操作
Figure 15 describes what happens if a PAUSE message from an RTP stream receiver does not reach the RTP stream sender. After sending a PAUSE message, the RTP stream receiver waits for a time-out to detect if the RTP stream sender has paused the data transmission or has sent a PAUSED indication according to the rules discussed in Section 6.3. As the PAUSE message is lost on the way (at time t2), RTP data continues to reach to the RTP stream receiver. When the timer expires, the RTP stream receiver schedules a retransmission of the PAUSE message, which is sent at time t4. If the PAUSE message now reaches the RTP stream sender, it pauses the RTP stream and replies with PAUSED.
图15描述了如果来自RTP流接收器的暂停消息没有到达RTP流发送者时会发生什么。发送暂停消息后，RTP流接收器等待超时，以检测RTP流发送器是否已根据第6.3节中讨论的规则暂停数据传输或发送暂停指示。当暂停消息在途中丢失时（在时间t2），RTP数据继续到达RTP流接收器。当定时器到期时，RTP流接收器调度在时刻t4发送的暂停消息的重传。如果暂停消息现在到达RTP流发送方，它将暂停RTP流并以暂停回复。
At time t6, the RTP stream receiver wishes to resume the stream again and sends a RESUME, which is lost. This does not cause any severe effect, since there is no requirement to wait until further RESUME requests are sent, and another RESUME is sent already at time t7, which now reaches the RTP stream sender that consequently resumes the stream at time t8. The time interval between t6 and t7 can vary but
在时间t6，RTP流接收器希望再次恢复流并发送丢失的恢复。这不会造成任何严重影响，因为不需要等待进一步的恢复请求被发送，并且在时间t7已经发送了另一个恢复，它现在到达RTP流发送器，从而在时间t8恢复流。t6和t7之间的时间间隔可以变化，但
may, for example, be one RTCP feedback transmission interval as determined by the AVPF rules.
例如，可以是由AVPF规则确定的一个RTCP反馈传输间隔。
The RTP stream receiver did not realize that the RTP stream was resumed in time to stop yet another scheduled RESUME from being sent at time t9. This is, however, harmless since RESUME contains a past PauseID and will be ignored by the RTP stream sender. It will also not cause the RTP stream to be resumed even if the stream was paused again based on a PAUSE from some other receiver before receiving the RESUME, since the current PauseID was updated compared to the one in the stray RESUME, which contains a past PauseID and will be ignored by the RTP stream sender.
RTP流接收器没有意识到RTP流已及时恢复，以阻止在时间t9发送另一个预定恢复。但是，这是无害的，因为RESUME包含过去的PauseID，RTP流发送器将忽略它。它也不会导致RTP流恢复，即使该流在接收到恢复之前基于来自某个其他接收器的暂停再次暂停，因为当前的PauseID与杂散恢复中的PauseID相比已更新，其中包含过去的PauseID，RTP流发送方将忽略该PauseID。
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------> |
| t2: PAUSE(11) |
| <------------------------------ |
| |
| < Cannot pause RTP data > |
| t3: REFUSED(11) |
| ------------------------------> |
| |
| t4: RTP data |
| ------------------------------> |
: :
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------> |
| t2: PAUSE(11) |
| <------------------------------ |
| |
| < Cannot pause RTP data > |
| t3: REFUSED(11) |
| ------------------------------> |
| |
| t4: RTP data |
| ------------------------------> |
: :
Figure 16: Pause Request is Refused in Point to Point
图16：点对点的暂停请求被拒绝
In Figure 16, the receiver requests to pause the sender, which refuses to pause due to some consideration local to the sender and responds with a REFUSED message.
在图16中，接收方请求暂停发送方，发送方出于发送方本地的某些考虑拒绝暂停，并以拒绝消息进行响应。
An RTP Mixer is an intermediate node connecting different transport-level clouds. The Mixer receives streams from different RTP sources, selects or combines them based on the application's needs, and forwards the generated stream(s) to the destination. The Mixer typically puts its own SSRC(s) in RTP data packets instead of the original source(s).
RTP混合器是连接不同传输级别云的中间节点。混合器接收来自不同RTP源的流，根据应用程序的需要选择或组合它们，并将生成的流转发到目的地。混频器通常在RTP数据包中放入自己的SSRC，而不是原始源。
The Mixer keeps track of all the streams delivered to the Mixer and how they are currently used. In this example, Mixer (M) selects the video stream to deliver to the RTP stream receiver (R) based on the voice activity of the RTP stream senders (S1 and S2). The video
混合器跟踪传送到混合器的所有流以及它们当前的使用方式。在该示例中，混合器（M）基于RTP流发送器（S1和S2）的语音活动选择要传送到RTP流接收器（R）的视频流。录像带
stream will be delivered to R using M's SSRC and with a CSRC indicating the original source.
流将使用M的SSRC和指示原始来源的CSRC交付给R。
Note that PauseID is not of any significance for the example and is therefore omitted in the description.
请注意，PauseID对于该示例没有任何意义，因此在描述中省略。
+-----+ +-----+ +-----+ +-----+
| R | | M | | S1 | | S2 |
+-----+ +-----+ +-----+ +-----+
: : t1:RTP(S1) : :
| t2:RTP(M:S1) |<-----------------| |
|<-----------------| | |
| | t3:RTP(S2) | |
| |<------------------------------------|
| | t4: PAUSE(S2) | |
| |------------------------------------>|
| | | t5: PAUSED(S2) |
| |<------------------------------------|
| | | <S2:No RTP to M> |
| | t6: RESUME(S2) | |
| |------------------------------------>|
| | | t7: RTP to M |
| |<------------------------------------|
| t8:RTP(M:S2) | | |
|<-----------------| | |
| | t9:PAUSE(S1) | |
| |----------------->| |
| | t10:PAUSED(S1) | |
| |<-----------------| |
| | <S1:No RTP to M> | |
: : : :
+-----+ +-----+ +-----+ +-----+
| R | | M | | S1 | | S2 |
+-----+ +-----+ +-----+ +-----+
: : t1:RTP(S1) : :
| t2:RTP(M:S1) |<-----------------| |
|<-----------------| | |
| | t3:RTP(S2) | |
| |<------------------------------------|
| | t4: PAUSE(S2) | |
| |------------------------------------>|
| | | t5: PAUSED(S2) |
| |<------------------------------------|
| | | <S2:No RTP to M> |
| | t6: RESUME(S2) | |
| |------------------------------------>|
| | | t7: RTP to M |
| |<------------------------------------|
| t8:RTP(M:S2) | | |
|<-----------------| | |
| | t9:PAUSE(S1) | |
| |----------------->| |
| | t10:PAUSED(S1) | |
| |<-----------------| |
| | <S1:No RTP to M> | |
: : : :
Figure 17: Pause and Resume Operation for a Voice-Activated Mixer
图17：声控混音器的暂停和恢复操作
The session starts at t1 with S1 being the most active speaker and thus being selected as the single video stream to be delivered to R (t2) using M's SSRC but with S1 as the CSRC (indicated after the colon in the figure). Then S2 joins the session at t3 and starts delivering an RTP stream to M. As S2 has less voice activity then S1, M decides to pause S2 at t4 by sending S2 a PAUSE request. At t5, S2 acknowledges with PAUSED and at the same instant stops delivering RTP to M. At t6, the user at S2 starts speaking and becomes the most active speaker and M decides to switch the video stream to S2 and therefore quickly sends a RESUME request to S2. At t7, S2 has received the RESUME request and acts on it by resuming RTP stream delivery to M. When the RTP stream from t7 arrives at M, it switches this RTP stream into its SSRC (M) at t8 and changes the CSRC to S2. As S1 now becomes unused, M issues a PAUSE request to S1 at
会话从t1开始，S1是最活跃的演讲者，因此被选为使用M的SSRC传送到R（t2）的单个视频流，但S1是CSC（在图中冒号后指示）。然后S2在t3加入会话并开始向M发送RTP流。由于S2的语音活动比S1少，M决定通过向S2发送暂停请求在t4暂停S2。在t5，S2确认暂停，同时停止向M发送RTP。在t6，S2处的用户开始讲话并成为最活跃的演讲者，M决定将视频流切换到S2，因此快速向S2发送恢复请求。在t7，S2已接收到恢复请求，并通过恢复向M的RTP流交付来对其进行操作。当来自t7的RTP流到达M时，S2在t8将该RTP流切换为其SSRC（M），并将CSC更改为S2。当S1现在变得不可用时，M向S1发出暂停请求
t9, which is acknowledged at t10 with PAUSED, and the RTP stream from S1 stops being delivered.
t9，它在t10被暂停确认，并且来自S1的RTP流停止被传送。
A transport Relay in an RTP session forwards the message from one peer to all the others. Unlike Mixer, the Relay does not mix the streams or change the SSRC of the messages or RTP media. These examples are to show that the messages defined in this specification can be safely used also in a transport Relay case. The parentheses in the figures contains (Target SSRC, PauseID) information for the messages defined in this specification.
RTP会话中的传输中继将消息从一个对等方转发到所有其他对等方。与混合器不同，中继不会混合流或更改消息或RTP媒体的SSRC。这些示例旨在说明本规范中定义的消息也可以安全地用于传输中继情况。图中的括号包含本规范中定义的消息的（目标SSRC、PauseID）信息。
+-------------+ +-------------+ +-------------+
| Sender(S) | | Relay | | Receiver(R) |
+-------------+ +-------------+ +-------------+
: t1: RTP(S) : :
|------------------>| |
| | t2: RTP (S) |
| |------------------>|
| | t3: PAUSE(S,3) |
| |<------------------|
| t4:PAUSE(S,3) | |
|<------------------| |
: <Sender waiting for possible RESUME> :
| < RTP data paused > |
| t5: PAUSED(S,3) | |
|------------------>| |
| | t6: PAUSED(S,3) |
| |------------------>|
: : :
| | t7: RESUME(S,3) |
| |<------------------|
| t8: RESUME(S,3) | |
|<------------------| |
| t9: RTP (S) | |
|------------------>| |
| | t10: RTP (S) |
| |------------------>|
: : :
+-------------+ +-------------+ +-------------+
| Sender(S) | | Relay | | Receiver(R) |
+-------------+ +-------------+ +-------------+
: t1: RTP(S) : :
|------------------>| |
| | t2: RTP (S) |
| |------------------>|
| | t3: PAUSE(S,3) |
| |<------------------|
| t4:PAUSE(S,3) | |
|<------------------| |
: <Sender waiting for possible RESUME> :
| < RTP data paused > |
| t5: PAUSED(S,3) | |
|------------------>| |
| | t6: PAUSED(S,3) |
| |------------------>|
: : :
| | t7: RESUME(S,3) |
| |<------------------|
| t8: RESUME(S,3) | |
|<------------------| |
| t9: RTP (S) | |
|------------------>| |
| | t10: RTP (S) |
| |------------------>|
: : :
Figure 18: Pause and Resume Operation between Two Participants Using a Relay
图18：使用中继的两个参与者之间的暂停和恢复操作
Figure 18 describes how a Relay can help the receiver (R) in pausing and resuming the sender (S). S sends RTP data to R through the Relay, which just forwards the data without modifying the SSRCs. R sends a PAUSE request to S which, in this example, knows that there
图18描述了中继如何帮助接收器（R）暂停和恢复发送器。S通过中继向R发送RTP数据，中继只转发数据而不修改SSRC。R向S发送暂停请求，在本例中，S知道
may be more receivers of the stream and waits a non-zero hold-off period to see if there is any other receiver that wants to receive the data, and when no disapproving RESUME messages are received, it pauses itself and replies with PAUSED. Similarly R resumes S by sending a RESUME request through the Relay. Since this describes only a single pause and resume operation for a single RTP stream sender, all messages use a single PauseID; in this example, it's three.
可能有更多的流接收者，并等待非零延迟时间，以查看是否有任何其他接收者想要接收数据，并且当没有接收到不批准的恢复消息时，它暂停自身并以暂停的方式回复。类似地，R通过中继发送恢复请求来恢复。因为这只描述了单个RTP流发送器的单个暂停和恢复操作，所以所有消息都使用单个PauseID；在这个例子中，它是三。
+-----+ +-----+ +-----+ +-----+
| S | | Rel | | R1 | | R2 |
+-----+ +-----+ +-----+ +-----+
: t1:RTP(S) : : :
|----------------->| | |
| | t2:RTP(S) | |
| |----------------->------------------>|
| | t3:PAUSE(S,7) | |
| |<-----------------| |
| t4:PAUSE(S,7) | | |
|<-----------------|------------------------------------>|
| | | t5:RESUME(S,7) |
| |<------------------------------------|
| t6:RESUME(S,7) | | |
|<-----------------|----------------->| |
| | <RTP stream continues to R1 and R2> |
| | | t7: PAUSE(S,8) |
| |<------------------------------------|
| t8:PAUSE(S,8) | | |
|<-----------------|----------------->| |
: : : :
| < Pauses RTP stream > | |
| t9:PAUSED(S,8) | | |
|----------------->| | |
| | t10:PAUSED(S,8) | |
| |----------------->------------------>|
: : : :
| | t11:RESUME(S,8) | |
| |<-----------------| |
| t12:RESUME(S,8) | | |
|<-----------------|------------------------------------>|
| t13:RTP(S) | | |
|----------------->| | |
| | t14:RTP(S) | |
| |----------------->------------------>|
: : : :
+-----+ +-----+ +-----+ +-----+
| S | | Rel | | R1 | | R2 |
+-----+ +-----+ +-----+ +-----+
: t1:RTP(S) : : :
|----------------->| | |
| | t2:RTP(S) | |
| |----------------->------------------>|
| | t3:PAUSE(S,7) | |
| |<-----------------| |
| t4:PAUSE(S,7) | | |
|<-----------------|------------------------------------>|
| | | t5:RESUME(S,7) |
| |<------------------------------------|
| t6:RESUME(S,7) | | |
|<-----------------|----------------->| |
| | <RTP stream continues to R1 and R2> |
| | | t7: PAUSE(S,8) |
| |<------------------------------------|
| t8:PAUSE(S,8) | | |
|<-----------------|----------------->| |
: : : :
| < Pauses RTP stream > | |
| t9:PAUSED(S,8) | | |
|----------------->| | |
| | t10:PAUSED(S,8) | |
| |----------------->------------------>|
: : : :
| | t11:RESUME(S,8) | |
| |<-----------------| |
| t12:RESUME(S,8) | | |
|<-----------------|------------------------------------>|
| t13:RTP(S) | | |
|----------------->| | |
| | t14:RTP(S) | |
| |----------------->------------------>|
: : : :
Figure 19: Pause and Resume Operation between One Sender and Two Receivers through Relay
图19：通过继电器在一个发送器和两个接收器之间暂停和恢复操作
Figure 19 explains the pause and resume operations when a transport Relay (Rel) is involved between a sender (S) and two receivers (R1 and R2) in an RTP session. Each message exchange is represented by the time it happens. At time t1, S starts sending an RTP stream to Rel, which forwards it to R1 and R2. R1 and R2 receives RTP data from Rel at t2. At this point, both R1 and R2 will send RTCP Receiver Reports to S informing that they received S's stream.
图19解释了RTP会话中发送方和两个接收方（R1和R2）之间涉及传输中继（Rel）时的暂停和恢复操作。每个消息交换都由它发生的时间表示。在时间t1，S开始向Rel发送RTP流，Rel将其转发给R1和R2。R1和R2在t2从Rel接收RTP数据。此时，R1和R2都将向S发送RTCP接收器报告，通知他们已收到S的流。
After some time (at t3), R1 chooses to pause the stream. On receiving the PAUSE request from R1 at t4, S knows that there is at least one receiver that may still want to receive the data and uses a non-zero hold-off period to wait for possible RESUME messages. R2 did also receive the PAUSE request at time t4 and since it still wants to receive the stream, it sends a RESUME for it at time t5, which is forwarded to sender S by Rel. S sees the RESUME at time t6 and continues to send data to Rel, which forwards it to both R1 and R2. At t7, R2 chooses to pause the stream by sending a PAUSE request with an updated PauseID. S still knows that there is more than one receiver (R1 and R2) that may want the stream and again waits a non-zero hold-off period, after which, and not having received any disapproving RESUME messages, it concludes that the stream must be paused. S now stops sending the stream and replies with PAUSED to R1 and R2. When any of the receivers (R1 or R2) choose to resume the stream from S, in this example R1, it sends a RESUME request to S (also seen by R2). S immediately resumes the stream.
一段时间后（t3），R1选择暂停流。在t4接收到来自R1的暂停请求时，S知道至少有一个接收机可能仍然想要接收数据，并且使用非零等待时间来等待可能的恢复消息。R2在时间t4也收到了暂停请求，因为它仍然希望接收流，所以它在时间t5为它发送了一个恢复，该恢复通过Rel转发给发送者S。S在时间t6看到简历并继续向Rel发送数据，Rel将其转发给R1和R2。在t7，R2通过发送带有更新的PauseID的暂停请求来选择暂停流。S仍然知道有多个接收器（R1和R2）可能需要流，并再次等待非零延迟时间，在此之后，由于没有收到任何不批准的恢复消息，它得出结论，流必须暂停。S现在停止发送流，并以暂停方式回复R1和R2。当任何接收器（R1或R2）选择从S恢复流时，在本例中，R1向S发送恢复请求（R2也可以看到）。S立即恢复流。
Consider also an RTP session that includes one or more receivers, paused sender(s), and a Relay. Further assume that a new participant joins the session, which is not aware of the paused sender(s). On receiving knowledge about the newly joined participant, e.g., any RTP traffic or RTCP report (i.e., either SR or RR) from the newly joined participant, the paused sender(s) immediately sends PAUSED indications for the paused streams since there is now a receiver in the session that did not pause the sender(s) and may want to receive the streams. Having this information, the newly joined participant has the same possibility as any other participant to resume the paused streams.
还考虑包括一个或多个接收器、暂停发送器和中继的RTP会话。进一步假设一个新参与者加入会话，而该参与者不知道暂停的发送者。当从新加入的参与者接收到关于新加入的参与者的信息，例如任何RTP流量或RTCP报告（即SR或RR）时，暂停的发送方立即发送暂停流的暂停指示，因为会话中现在有一个接收方没有暂停发送方并且可能想要接收流。有了这些信息，新加入的参与者与任何其他参与者一样有可能恢复暂停的流。
Per this specification, IANA has made the following registrations:
根据本规范，IANA进行了以下注册：
1. A new value for media stream pause/resume has been registered in the "FMT Values for RTPFB Payload Types" registry located at the time of publication at: <http://www.iana.org/assignments/rtp-parameters>
1. 媒体流暂停/恢复的新值已在“RTPFB有效负载类型的FMT值”注册表中注册，该注册表在发布时位于：<http://www.iana.org/assignments/rtp-parameters>
Value: 9
数值：9
Name: PAUSE-RESUME
名称：暂停-恢复
Long Name: Media Pause/Resume
长名称：媒体暂停/恢复
Reference: RFC 7728
参考：RFC 7728
2. A new value "pause" to be registered with IANA in the "Codec Control Messages" registry located at the time of publication at: <http://www.iana.org/assignments/sdp-parameters>
2. 在“编解码器控制消息”注册表中向IANA注册的新值“暂停”，发布时位于：<http://www.iana.org/assignments/sdp-parameters>
Value Name: pause
值名称：暂停
Long Name: Media Pause/Resume
长名称：媒体暂停/恢复
Usable with: ccm
可用于：ccm
Reference: RFC 7728
参考：RFC 7728
This document extends CCM [RFC5104] and defines new messages, i.e., PAUSE, RESUME, PAUSED, and REFUSED. The exchange of these new messages has some security implications, which need to be addressed by the user.
本文档扩展了CCM[RFC5104]并定义了新消息，即暂停、恢复、暂停和拒绝。这些新消息的交换有一些安全隐患，需要用户解决。
The messages defined in this specification can have a substantial impact on the perceived media quality if used in a malicious way. First of all, there is the risk for Denial of Service (DoS) on any RTP session that uses the PAUSE-RESUME functionality. By injecting one or more PAUSE requests into the RTP session, an attacker can potentially prevent any media from flowing, especially when the hold-off period is zero. The injection of PAUSE messages is quite simple, requiring knowledge of the SSRC and the PauseID. This information is visible to an on-path attacker unless RTCP messages are encrypted. Even off-path attacks are possible as signaling messages often carry the SSRC value, while the 16-bit PauseID has to be guessed or tried. The way of protecting the RTP session from these injections is to
如果以恶意方式使用，本规范中定义的消息可能会对感知的媒体质量产生重大影响。首先，在任何使用暂停-恢复功能的RTP会话上都存在拒绝服务（DoS）的风险。通过向RTP会话中注入一个或多个暂停请求，攻击者可以潜在地阻止任何媒体流动，尤其是在延迟时间为零的情况下。暂停消息的注入非常简单，需要了解SSRC和PauseID。除非对RTCP消息进行加密，否则路径上的攻击者可以看到此信息。即使是非路径攻击也是可能的，因为信令消息通常携带SSRC值，而必须猜测或尝试16位PauseID。保护RTP会话不受这些注入影响的方法是
perform source authentication combined with message integrity to prevent other than intended session participants from sending these messages. The security solution should provide replay protection. Otherwise, if a session is long lived enough for the PauseID value to wrap, an attacker could replay old messages at the appropriate time to influence the media sender state. There exist several different choices for securing RTP sessions to prevent this type of attack. The Secure Real-time Transport Protocol (SRTP) is the most common, but also other methods exist as discussed in "Options for Securing RTP Sessions" [RFC7201].
执行源身份验证并结合消息完整性，以防止非预期会话参与者发送这些消息。安全解决方案应提供重播保护。否则，如果会话足够长，PauseID值可以包装，则攻击者可以在适当的时间重播旧消息，以影响媒体发送者的状态。为了保护RTP会话以防止这种类型的攻击，存在几种不同的选择。安全实时传输协议（SRTP）是最常见的，但也存在其他方法，如“保护RTP会话的选项”[RFC7201]中所述。
Most of the methods for securing RTP, however, do not provide source authentication of each individual participant in a multiparty use case. In case one of the session participants is malicious, it can wreck significant havoc within the RTP session and similarly cause a DoS on the RTP session from within. That damage can also be attempted to be obfuscated by having the attacker impersonate other endpoints within the session. These attacks can be mitigated by using a solution that provides true source authentication of all participants' RTCP packets. However, that has other implications. For multiparty sessions including a middlebox, that middlebox is RECOMMENDED to perform checks on all forwarded RTCP packets so that each participant only uses its set of SSRCs to prevent the attacker from utilizing another participant's SSRCs. An attacker that can send a PAUSE request that does not reach any participants other than the media sender can cause a stream to be paused without providing opportunity for opposition. This is mitigated in multiparty topologies that ensure that requests are seen by all or most of the RTP session participants, enabling these participants to send a RESUME. In topologies with middleboxes that consume and process PAUSE requests, the middlebox can also mitigate such behavior as it will commonly not generate or forward a PAUSE message if it knows of another participant having use for the media stream.
然而，大多数保护RTP的方法都不提供多方用例中每个参与者的源身份验证。如果其中一个会话参与者是恶意的，它会在RTP会话中造成严重破坏，并从内部对RTP会话造成拒绝服务。通过让攻击者模拟会话中的其他端点，也可以试图混淆这种损害。这些攻击可以通过使用提供所有参与者RTCP数据包的真实源身份验证的解决方案来缓解。然而，这还有其他影响。对于包括中间箱的多方会话，建议该中间箱对所有转发的RTCP数据包执行检查，以便每个参与者仅使用其SSRC集来防止攻击者利用另一参与者的SSRC。攻击者如果发送的暂停请求未到达除媒体发送者以外的任何参与者，则可能导致流暂停，而不提供反对的机会。这在多方拓扑中得到缓解，确保所有或大多数RTP会话参与者都能看到请求，从而使这些参与者能够发送简历。在具有使用和处理暂停请求的中间盒的拓扑中，中间盒还可以缓解此类行为，因为如果它知道另一参与者正在使用媒体流，它通常不会生成或转发暂停消息。
The above text has been focused on using the PAUSE message as the tool for malicious impact on the RTP session. That is because of the greater impact from denying users access to RTP media streams. In contrast, if an attacker attempts to use RESUME in a malicious purpose, it will result in the media streams being delivered. However, such an attack basically prevents the use of the pause and resume functionality. Thus, it potentially forces a reduction of the media quality due to limitation in available resources, like bandwidth that must be shared.
上面的文本重点介绍了如何使用暂停消息作为对RTP会话造成恶意影响的工具。这是因为拒绝用户访问RTP媒体流的影响更大。相反，如果攻击者试图出于恶意目的使用RESUME，则会导致媒体流被传送。但是，这种攻击基本上阻止了暂停和恢复功能的使用。所以，由于可用资源（如必须共享的带宽）的限制，它可能会强制降低媒体质量。
The session establishment signaling is also a potential venue of attack, as that can be used to prevent the enabling of pause and resume functionality by modifying the signaling messages. The above mitigation of attacks based on source authentication also requires
会话建立信令也是一个潜在的攻击场所，因为它可以通过修改信令消息来防止启用暂停和恢复功能。上述基于源身份验证的攻击缓解措施还需要
the signaling system to securely handle identities and assert that only the intended identities are allowed into the RTP session and provided with the relevant security contexts.
信令系统安全地处理身份，并断言只有预期的身份才允许进入RTP会话，并提供相关的安全上下文。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://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, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://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, <http://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月<http://www.rfc-editor.org/info/rfc3550>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[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, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，DOI 10.17487/RFC5104，2008年2月<http://www.rfc-editor.org/info/rfc5104>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <http://www.rfc-editor.org/info/rfc6263>.
[RFC6263]Marjou，X.和A.Sollaud，“保持与RTP/RTP控制协议（RTCP）流相关的NAT映射活动的应用机制”，RFC 6263，DOI 10.17487/RFC6263，2011年6月<http://www.rfc-editor.org/info/rfc6263>.
[MULTI-STREAM-OPT] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Work in Progress, draft-ietf-avtcore-rtp-multi-stream-optimisation-11, December 2015.
[MULTI-STREAM-OPT]Lennox，J.，Westerlund，M.，Wu，W.，和C.Perkins，“在单个RTP会话中发送多个媒体流：分组RTCP接收统计数据和其他反馈”，正在进行的工作，草稿-ietf-avtcore-RTP-MULTI-STREAM-OPTIMIZATION-112015年12月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC 2326，DOI 10.17487/RFC2326，1998年4月<http://www.rfc-editor.org/info/rfc2326>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，DOI 10.17487/RFC2974，2000年10月<http://www.rfc-editor.org/info/rfc2974>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，DOI 10.17487/RFC36112003年11月<http://www.rfc-editor.org/info/rfc3611>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>.
[RFC6190]Wenger，S.，Wang，Y.，Schierl，T.，和A.Eleftheriadis，“可伸缩视频编码的RTP有效载荷格式”，RFC 6190，DOI 10.17487/RFC6190，2011年5月<http://www.rfc-editor.org/info/rfc6190>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，DOI 10.17487/RFC7201，2014年4月<http://www.rfc-editor.org/info/rfc7201>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <http://www.rfc-editor.org/info/rfc7478>.
[RFC7478]Holmberg，C.，Hakanson，S.，和G.Eriksson，“网络实时通信用例和需求”，RFC 7478，DOI 10.17487/RFC7478，2015年3月<http://www.rfc-editor.org/info/rfc7478>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<http://www.rfc-editor.org/info/rfc7656>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.
[RFC7667]Westerlund，M.和S.Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 7667，DOI 10.17487/RFC7667，2015年11月<http://www.rfc-editor.org/info/rfc7667>.
[SDP-SIMULCAST] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", Work in Progress, draft-ietf-mmusic-sdp-simulcast-04, February 2016.
[SDP-SIMULCAST]Burman，B.，Westerlund，M.，Nandakumar，S.，和M.Zanaty，“在SDP和RTP会议中使用同步广播”，正在进行的工作，草案-ietf-mmusic-SDP-SIMULCAST-042016年2月。
Acknowledgments
致谢
Daniel Grondal made valuable contributions during the initial versions of this document. The authors would also like to thank Emil Ivov, Christian Groves, David Mandelberg, Meral Shirazipour, Spencer Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable review comments.
Daniel Grondal在本文件的初始版本中做出了宝贵的贡献。作者还要感谢埃米尔·伊沃夫、克里斯蒂安·格罗夫斯、大卫·曼德伯格、梅拉尔·谢拉齐普尔、斯宾塞·道金斯、伯纳德·阿博巴和本·坎贝尔，他们提供了宝贵的评论意见。
Contributors
贡献者
Daniel Grondal contributed in the creation and writing of early versions of this specification. Christian Groves contributed significantly to the SDP "config" pause attribute and its use in offer/answer.
Daniel Grondal对本规范早期版本的创建和编写做出了贡献。Christian Groves对SDP“config”pause属性及其在offer/answer中的使用做出了重大贡献。
Authors' Addresses
作者地址
Bo Burman Ericsson Kistavagen 25 SE - 164 80 Kista Sweden
博伯曼爱立信基斯塔瓦根25东南-164 80瑞典基斯塔
Email: bo.burman@ericsson.com
Email: bo.burman@ericsson.com
Azam Akram Ericsson Farogatan 6 SE - 164 80 Kista Sweden
Azam Akram Ericsson Farogatan 6 SE-164 80基斯塔瑞典
Phone: +46107142658
Email: akram.muhammadazam@gmail.com
URI: www.ericsson.com
Phone: +46107142658
Email: akram.muhammadazam@gmail.com
URI: www.ericsson.com
Roni Even Huawei Technologies Tel Aviv Israel
Roni甚至华为技术公司以色列特拉维夫
Email: roni.even@mail01.huawei.com
Email: roni.even@mail01.huawei.com
Magnus Westerlund Ericsson Farogatan 6 SE - 164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 6 SE-164 80基斯塔瑞典
Phone: +46107148287
Email: magnus.westerlund@ericsson.com
Phone: +46107148287
Email: magnus.westerlund@ericsson.com