[要約] RFC 7728は、RTPストリームの一時停止と再開に関するプロトコル仕様です。その目的は、リアルタイム通信アプリケーションでのストリームの制御と効率的なネットワーク利用を可能にすることです。
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データストリームを一時停止および再開するために使用される新しいリアルタイムフィードバックメッセージのグループを追加することにより、コーデック制御メッセージ（CCM）RTP制御プロトコル（RTCP）フィードバックパッケージを拡張します。このドキュメントはRFC 5104を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外で作成したりすることはできません。 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
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]ストリームを一時的に一時停止し、必要に応じて後で再開するマルチメディア通信のいくつかのシナリオについて説明します。受信者は、たとえば、SIP [RFC3261]とセッション記述プロトコル（SDP）[RFC4566]オファー/アンサー[RFC3264]を使用してセッションパラメータをネゴシエートすることにより、RTPセッションを終了または非アクティブ化して最初からやり直す必要はありません。
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 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ミキサーやマルチポイントコントロールユニット（MCU）などの集中型ノードは、一時的ではないRTPストリームを一時停止することにより、送信者とネットワークの両方で消費されるリソースを削減できますRTPミキサーで必要です。会議参加者の数が、会議ロジックが受信参加者に同時に提示することを選択した数よりも多い場合、RTPミキサーに送信される一部の参加者RTPストリームは、他の参加者に転送する必要がない場合があります。これらのRTPストリームは一時的に一時停止される可能性があります。これは、メディアソースが複数のエンコーディングバージョン（Simulcast）[SDP-SIMULCAST]またはスケーラブルビデオコーディング（SVC）[RFC6190]などのスケーラブルエンコーディングのマルチセッション伝送（MST）で提供される場合に特に役立ちます。使用されていない、または常に使用できない、定義されたエンコーディングまたはスケーラブルレイヤーの組み合わせの一部が存在する可能性があります。一例として、集中ノードは、おそらく一時的に制限されたネットワークまたは処理リソースのために、明示的にそうするように要求されることなく、そのような未使用の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 Audio-Visual Profile with Feedback（AVPF）[RFC5104]のコーデック制御メッセージ（CCM）と一致するように見えます。このドキュメントでは、ソリューションを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)
CSRC：Contributing Source（RTP）
FCI: Feedback Control Information (AVPF)
FCI：フィードバック制御情報（AVPF）
FIR: Full Intra Refresh (CCM)
FIR：フルイントラリフレッシュ（CCM）
FMT: Feedback Message Type (AVPF) MCU: Multipoint Control Unit
FMT：フィードバックメッセージタイプ（AVPF）MCU：マルチポイントコントロールユニット
MTU: Maximum Transfer Unit
MTU：最大転送単位
PT: Payload Type (RTP)
PT：ペイロードタイプ（RTP）
RTP: Real-time Transport Protocol (RFC 3550)
RTP：リアルタイム転送プロトコル（RFC 3550）
RTCP: RTP Control Protocol (RFC 3550)
RTCP：RTP制御プロトコル（RFC 3550）
RTCP RR: RTCP Receiver Report
RTCP RR：RTCP受信者レポート
RTCP SR: RTCP Sender Report
RTCP SR：RTCP送信者レポート
SDP: Session Description Protocol (RFC 4566)
SDP：セッション記述プロトコル（RFC 4566）
SIP: Session Initiation Protocol (RFC 3261)
SIP：セッション開始プロトコル（RFC 3261）
SSRC: Synchronization Source (RTP)
SSRC：同期ソース（RTP）
SVC: Scalable Video Coding
SVC：スケーラブルビデオコーディング
TMMBR: Temporary Maximum Media Bitrate Request (CCM)
TMMBR：一時的な最大メディアビットレートリクエスト（CCM）
TMMBN: Temporary Maximum Media Bitrate Notification (CCM)
TMMBN：一時的な最大メディアビットレート通知（CCM）
UA: User Agent (SIP)
UA：ユーザーエージェント（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フィードバックメッセージを要求、コマンド、表示、通知の4つのタイプに分類しました。このドキュメントでは、PAUSEメッセージとRESUMEメッセージをリクエストカテゴリに配置し、PAUSEDを指示として、REFUSEDを通知として配置します。
PAUSE: Request from an RTP stream receiver to pause a stream
PAUSE：ストリームを一時停止する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
PAUSED：ストリームが一時停止されているというRTPストリーム送信者からの通知
REFUSED: Notification from an RTP stream sender that a PAUSE or RESUME request will not be honored
REFUSED：RTPストリーム送信者からの、PAUSEまたはRESUMEリクエストが受け入れられないという通知
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ストリームを受信し、それらを結合して1つのRTPストリームを作成し、それらを宛先に転送する中間RTPノード。「RTPトポロジ」[RFC7667]でTopo-Mixerについて説明した意味で。
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ストリーム送信者。つまり、この仕様で定義されたPAUSE要求またはローカルの決定のいずれかを受信したことに基づいて、他の参加者がRTP送信を受信しません。
Pausing receiver: An RTP stream receiver that sends a PAUSE request, defined in this specification, to another participant(s).
一時停止レシーバー：この仕様で定義されているPAUSE要求を別の参加者に送信する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エンティティ、通常はMedia Depacketizer。
Stream sender: Short for RTP stream sender; the RTP entity responsible for creating an RTP stream, usually a Media Packetizer.
ストリーム送信者：RTPストリーム送信者の略。 RTPストリームの作成を担当するRTPエンティティ（通常はMedia Packetizer）。
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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、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 WGのユースケースと要件のドキュメント[RFC7478]は、W3C WebRTC WGでも使用される次のAPI要件を付録Aで定義しています。
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 WGは一時停止/再開機能を指定していませんでした。
This is the most basic use case with an RTP session containing two endpoints. Each endpoint sends one or more streams.
これは、2つのエンドポイントを含むRTPセッションの最も基本的な使用例です。各エンドポイントは1つ以上のストリームを送信します。
+---+ +---+
| 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ストリーム一時停止の使用法は、送信側が提供するストリームの配信を一時的に停止することですが、受信側は現在使用していません。これは、たとえば、ビデオストリームが実際にはどのディスプレイにも表示されていない、または記録されているなど他の方法で使用されていない、アプリケーションが最小化されていることが原因である可能性があります。この場合、ストリームのレシーバーは1つしかないため、ストリームを一時停止または再開しても、そのストリームの送信者と単一のレシーバー以外には影響しません。
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].
集中会議で最も一般的に使用されるトポロジの1つは、RTPミキサー[RFC7667]に基づいています。これの主な理由は、各参加者に対するRTPセッションの非常に一貫したビューを提供することです。これは、別個のSSRC値によって識別される独自のストリームを発信するミキサーを介して行われ、参加者に送信されるRTPストリームは、それらのSSRC値を使用して送信されます。ミキサーが概念的なストリームの基になるメディアソースを識別したい場合、CSRCを使用してそれらを識別できます。ミキサーが提供するストリームは、複数のメディアソースの実際のミックスにすることができますが、「RTPトポロジ」[RFC7667]のセクション3.6〜3.8で説明されているように、受信ストリームを切り替えることもできます。
+---+ +-----------+ +---+
| 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:
特定の受信者Aに配信されるクライアントB、C、およびDからのストリームは、いくつかの要素に依存します。
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の3つのドメインに分離する必要があります。上記との違いは、AとCがマルチキャストドメインを共有していることです。下に描かれています。
+-----+
+---+ / \ +-----------+ +---+
| 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つの使用例と比較して逆です。図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のようなエンドポイントは、ストリームを識別するCSRCの一時停止要求を送信することにより、ミキサーが使用する任意のSSRCを介して、Bの1つのような特定のストリームの配信を一時停止するように要求する可能性があります。しかし、著者たちは、これはいくつかの理由で適切な解決策ではないと考えています：
1. The Mixer might not include CSRC in its stream indications.
1. ミキサーのストリーム表示にCSRCが含まれていない場合があります。
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. 配信されたメディアが何らかの種類のミックスである場合、エンドポイントはCSRCに依存して、一時停止するストリームを正しく識別することができません。一般的なケースでこれをサポートするには、より複雑なストリーム識別ソリューションが必要です。
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.
送信者からのストリームを一時停止または再開して、PAUSEおよびRESUMEメッセージを送信するのは、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.
PAUSEおよびRESUMEメッセージは、SSRCによって識別される単一のRTPストリームに適用されます。つまり、受信者は、PAUSEおよびRESUMEリクエストで送信者のSSRCをターゲットにします。一時停止した送信者が新しいSSRCで送信を開始した場合、受信者は一時停止するために新しいPAUSE要求を送信する必要があります。 PAUSED表示は、送信者自身の一時停止したSSRCの1つを指します。
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セッションを備えたメッシュ、トランスポートトランスレータベースのネットワークなどです。この結果、新しく参加するレシーバーは、まず一時停止したストリームの存在を知る必要があり、次に、一時停止したストリームを再開できる必要があります。新しく参加するレシーバーは、たとえば、セッションでまだ発生していない新しいSSRCとCNAMEの両方を含むRTCPレシーバーレポートを通じて検出できます。ストリームを再開したい単一のレシーバーも、ストリームを再開させる必要があります。これに対する重要な例外は、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エンドポイントから送信されたPAUSEおよび/またはRESUMEメッセージがその宛先、つまりターゲットのRTPストリーム送信者に到達しない可能性があります。 PAUSEまたはRESUMEが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).
場合によっては、PAUSEまたはRESUMEメッセージが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.
ストリームがPAUSEまたはRESUMEリクエストによって期待どおりに影響を受けない場合は、リクエストが失われた可能性があり、リクエストの送信者はそれを再送信する必要があります。再送信では、往復時間を考慮に入れる必要があります。また、フィードバックの再送信をスケジュールするときは、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.
PAUSE要求メッセージには、再送信と新しい要求を区別するためのシーケンス番号が必要です。再送信ではシーケンス番号は変更されませんが、以前の要求の再送信ではない新しいPAUSE要求が送信されるたびにインクリメントされます。
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よりも優先され、ストリームの一時停止を回避することもできるため、PAUSEとRESUMEの厳密な順序を維持する必要があります。したがって、RESUMEはシーケンス番号スペースをPAUSEと共有し、それが参照するPAUSEを暗黙的に参照する必要があります。同じ理由で、明示的なPAUSED指示もシーケンス番号スペースをPAUSEおよびRESUMEと共有する必要があります。
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 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.
SIP / SDPおよびRTCPシグナリングテクノロジー間のパフォーマンス比較が行われ、この仕様のドラフトバージョンに含まれていました。 SIPとSDPを使用して一時停止と再開の情報を伝送することは、シグナリングパス全体をトラバースして、シグナリングの宛先（リモートエンドポイントまたはRTPミキサーを制御するエンティティ）に到達する必要があることを意味します。 SDPコンテンツは、彼らがそれに作用することが期待されるかどうかを決定します。 SIP / SDPに基づくシグナリングソリューションに必要な帯域幅の量は、RTCPベースのソリューションの少なくとも10倍程度です。特に、モバイルワイヤレスアクセスを使用しているUAの場合、遅延が長すぎるため（セクション4.1）、ユーザーエクスペリエンスを向上させることができず、RTCPベースのソリューションと比較して、帯域幅のコストも実現不可能と見なされる場合があります。メディアパスを介して送信される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.
提案されたソリューションは、送信者SSRCによって識別される、ストリーム送信者をターゲットとするストリームを一時停止または再開したい任意のRTPセッション参加者からのAVPF RTCPフィードバックメッセージの送信に基づいて、一時停止および再開機能を実装します。
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）ブロックで構成されます。各ブロックは、PAUSE要求、RESUME要求、PAUSED通知、REFUSED通知、またはこの仕様の拡張です。この構造により、単一のフィードバックメッセージで複数のストリームの一時停止機能を処理できます。
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.
PAUSED機能は、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.
TMMBR / TMMBNを一時停止および再開の目的で使用する場合に適用される特別な考慮事項については、セクション5.6で説明します。この仕様は、特に明記されている場合を除き、ここで定義された新しいメッセージとTMMBR / TMMBNの両方に適用されます。明らかな例外は、ここで定義されたメッセージでのみ使用可能なメッセージパラメータへの参照です。たとえば、以下のテキストでのPAUSEへの参照はTMMBR 0にも等しく適用され、PAUSEDへの参照は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 Mixer to Media Sender」のユースケース（セクション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が一時停止および再開の目的で使用される場合、TMMBNのみではなく、TMMBRと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）で定義されているすべてのメッセージには、シーケンス番号付け（セクション4.7）に関する設計上の考慮事項を満たすPauseIDが含まれています。このPauseIDは、対象のRTPストリーム（SSRC）のスコープであり、そのプロパティであり、個々のメッセージのシーケンス番号だけではありません。代わりに、RTPストリームの「一時停止および再開操作」全体に番号を付け、通常、複数の関連メッセージに対してPauseIDを一定に保ちます。このような操作中に使用されるPauseID値は、現在のPauseIDと呼ばれます。新しい「一時停止および再開操作」は、RTPストリーム送信者がRTPストリームを一時停止した後に再開したときに開始するように定義されています。その後、現在のPauseIDは、モジュロ演算で1ずつ増分されます。以下の後続の説明では、過去のPauseIDとして示される、現在のPauseIDとして既に使用されているPauseID値を参照する必要がある場合があります。 PauseIDはモジュロ演算を使用するため、過去のPauseIDの値が現在のPauseIDよりも大きい場合があることに注意してください。 PauseIDはモジュロ演算を使用するため、「過去」と見なされるPauseID値を定義して、「将来の」PauseID値と見なされるものと明確に区別することも役立ちます。 PauseID値の範囲全体の半分は、過去のPauseIDを表すために選択され、PauseID値の範囲の4分の1は、将来の値を表すために選択されます。 PauseID値の範囲の残りの4分の1は、その点で意図的に未定義のままにしています。
An RTP stream receiver can choose to send a PAUSE request at any time, subject to AVPF timing rules.
RTPストリームレシーバーは、AVPFタイミングルールに従って、いつでもPAUSE要求を送信することを選択できます。
The PAUSE request contains the current PauseID (Section 5.2).
PAUSEリクエストには、現在の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ストリームセンダーは、PAUSE要求を受信すると、RTEストリームを送信し続けますが、しばらく待ってから、同じRTPセッション内の他のRTPストリームレシーバーがRESUMEを送信してこのPAUSE要求を拒否するのを許可します（セクション5.5 ）承認されていないPAUSEと同じストリームおよび同じ現在のPauseIDの場合。ストリームが一時停止される前のホールドオフ期間中に、このような不承認のRESUMEが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でさらにPAUSE要求を受信した場合、それらの追加の要求は無視されます。
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ストリーム送信者に到達する前にPAUSE要求が失われた場合、RTPストリームを受信し続けるため、RTPストリーム受信者によって検出されます。また、ストリームのPAUSED表示（5.4節）も表示されません。同じ条件は、RTPストリーム送信者がストリーム受信者Aからストリーム送信者Bが送信したPAUSEリクエストに対して不承認のRESUMEを受信したことが原因である可能性があります。ただし、PAUSE送信者（B）が（Aから）RESUMEを受信せず、代わりに一時停止が失われたと思います。どちらの場合も、同じ現在のPauseIDを使用してPAUSE要求を再送信できます。 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.
保留中のストリームの一時停止がRESUMEの不承認により中止された場合、そのPauseIDの一時停止および再開操作が終了し、現在のPauseIDが更新されるため、新しいPAUSEは新しい現在のPauseIDを使用して有効にする必要があります。
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を使用しないPAUSEを受信するRTPストリームセンダーは、現在のPauseID値を含むREFUSED通知を送信することにより、この状態の無効なPAUSEを送信する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 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).
新しいRTPストリームレシーバーがセッションに参加し、ストリームを一時停止したいが、現在使用するPauseIDがまだわからない場合、無効なPauseIDが選択される状況が発生する可能性があります。 REFUSED通知は、有効な一時停止を作成するのに十分な情報を提供します。必要な追加のシグナリングラウンドトリップは、ストリームの一時停止は時間的に重要ではないと想定されているため（セクション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ストリーム送信者はREFUSEDで応答できます。この場合、使用された現在のPauseIDが別の方法で有効であった場合、REFUSEDにはPAUSEリクエストと同じ現在のPauseIDが含まれます。 TMMBR 0をPAUSEとして使用する場合、TMMBNには現在の境界セットが含まれるという[RFC5104]のセクション4.2.2.2の既存の制限、およびTMMBR 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ストリームセンダーが、少なくとも1回はREFUSEDですでに応答されているRTPストリームに対する同一のPAUSE要求をいくつか受信し、REFUSEDの原因となる状態が残っている場合は、それらの追加のREFUSED通知を通常のRTCPタイミングで送信する必要があります。単一のREFUSEDは、複数の同一のPAUSE要求に応答できます。
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を含むPAUSED通知を送信します。非送信請求PAUSED（PAUSEを受信していない）の現在のPauseIDは、以前に送信されたPAUSEDと比較して増加することに注意してください。また、次の2つの定期的なRTCPレポートでPAUSED通知を送信します。ただし、一時停止状態が引き続き有効であることを前提とします。
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.
PAUSED表示に対する応答はありません。これは、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 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.
PAUSED指示には、一時停止が有効になったときのRTP拡張最大シーケンス番号に関する情報も含まれています。これにより、RTPストリームレシーバーは、ストリームが一時停止する直前、またはストリームが再開したときにパケットを損失したかどうかを知ることができる直接的な情報を受信者に提供します。これにより、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でPAUSE要求を受信した場合、それらの要求は無視されます。
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.
ストリームが一時停止されている限り、PAUSED通知は通常のRTCP送信者レポート（SR）または受信者レポート（RR）と一緒に送信できます（MAY）。この方法でPAUSEDを含めると、ストリームが一時停止しているときにRTPストリームレシーバーが参加し、一時停止されたストリームがあること、最後に送信された拡張RTPシーケンス番号、および現在のPauseIDが何であるかをすばやく知ることができます。後でPAUSEおよびRESUMEリクエスト。
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セッションに参加したことを（たとえば、以前にRTPセッションで見られなかった新しいSSRCとCNAMEによって）認識した場合、すべての一時停止されたストリームのPAUSED通知を最も早い機会に送信する必要があります。さらに、少なくとも2つの通常のRTCPレポートにPAUSED通知が含まれるようにする必要があります。
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タイミングルールに従って、いつでもRESUME要求でストリームを再開するようにRTPストリームセンダーに要求できます。 RTPストリームレシーバーを有効にするには、現在のPauseIDをRESUMEリクエストに含める必要があります。
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.
現在のPauseIDを含むRESUMEを受信する一時停止RTPストリーム送信者は、できるだけ早くストリームを再開します。一時停止されていないストリームのRESUMEリクエストを受信する場合、アクションは不要であり、無視できます。
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ストリームセンダーが現在のREFUSEDを含むREFUSEDで応答できるなど、RTPストリームセンダーでローカルの考慮事項がある場合があります。 PauseID。送信されたRESUMEのPauseIDと同じ現在のPauseIDでそのようなREFUSEDを受信する場合、RTPストリームレシーバーは、条件がクリアされるのを可能にするために、ある程度の妥当な時間、それ以上RESUMEリクエストを送信しないようにする必要があります。 REFUSEDを送信したRTPストリーム送信者は、REFUSEDの原因となった条件が真でなくなったときに、ローカルの考慮事項（下記を参照）を通じてストリームを再開する必要があります（SHOULD）。
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ストリームセンダーが、少なくとも一度はREFUSEDで応答されたRTPストリームに対するいくつかの同一のRESUME要求を受信し、REFUSEDの原因となる状態が残っている場合、それらの追加のREFUSED通知は通常のRTCPタイミングで送信する必要があります。単一のREFUSEDは、複数の同一のRESUME要求に応答できます。
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ストリームをいつでも再開できます。 RMMストリームを一時停止するためにTMMBR 0が使用された場合、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]を使用して明示的に要求できます。 RESUMEの送信と同時に、時間依存性のないサンプル（ビデオの場合、いわゆるイントラピクチャ）の場合。
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ストリームを一時停止する前にRESUMEを待機するホールドオフ期間を必要とせず、PAUSEに対応します。
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で一時停止されていた場合のRESUMEに対応します。RTPストリームレシーバーは1つだけなので、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で一時停止された場合のPAUSEDに対応しますが、PAUSEDと同様に、非送信請求でも使用できます。ローカル送信者の考慮事項に基づく非送信請求RTPストリームの一時停止は、TMMBNメッセージバウンディングセットのTMMBR制限所有者としてRTPストリームの独自のSSRCを使用します。これは、TMMBR> 0でストリームの再開が要求されたときのREFUSED通知にも対応しているため、ストリーム送信者は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で述べた理由により、TMMMBR 0でストリームを一時停止するように要求された場合、REFUSED通知として使用できません。
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送信側のストリームの3つの新しい状態を紹介します。このセクションでのPAUSE、PAUSED、RESUME、およびREFUSEDへの言及は、この機能にTMMBR / TMMBNが使用されている場合（セクション5.6）にも可能な範囲で適用されるものとします（SHALL）。
+------------------------------------------------------+
| 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ずつ増加する必要があります（SHALL）。一時停止後に送信された最初のパケットの最初のRTPタイムスタンプは、ソースでのキャプチャ時間に従って設定する必要があります（SHOULD）。つまり、一時停止前と比較した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ストリーム送信者は、問題のストリームについて少なくとも1つのPAUSEメッセージを受信しています。 RTPストリームの送信側は、ホールドオフ期間中、一時停止中のRTPストリームのRESUMEメッセージの受信を待ってから、実際にRTPストリームの送信を一時停止する必要があります。待機するホールドオフ期間は、別のRTPストリームレシーバーがストリームの一時停止を見たくないと判断した場合に、RESUMEでPAUSEに応答できるように十分に長くなければなりません。このホールドオフ期間は、次の式で決定されます。
2 * RTT + T_dither_max,
2 * RTT + T_dither_max、
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_dither_maxは[RFC4585]のセクション3.4で定義されています。ホールドオフ期間は、一部のシグナリング（セクション9）によって0に設定される場合があります（セクション9）。これは、たとえば、ポイントツーポイントまたはいくつかのユニキャスト状況で、単一のレシーバーしかないと判断できる場合を意味します。
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ストリームセンダーは、次の基準を使用して、明示的で信頼性の高い情報がない限り、レシーバーが1つだけかどうかを判断する必要があります（SHOULD）。
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ストリームは、送信者が少なくとも1つのPAUSEメッセージを受信した後で送信を一時停止し、そのストリームのRESUMEメッセージを受信せずにホールドオフ期間が経過すると、一時停止状態になります。送信の一時停止は、メディアレシーバーが修復または隠蔽アクションをトリガーすることを回避するメディア境界のように、ストリーム内で一時停止する適切な場所に到達したときにのみ行う必要があります。
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ストリーム受信者にPAUSED指示を送信する必要があり（SHALL）、次の2つの通常のRTCPレポートでPAUSEDを繰り返す必要があります。
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive [RFC6263][RFC5245] applicable to that RTP stream.
RTPストリームを一時停止しても、そのRTPストリームに適用可能なRTPキープアライブ[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ミキサーが参加者間で関与している場合（RTPデータを独自のSSRCでマークすることによりストリームを転送します）、送信者へのPAUSEおよびRESUMEリクエストの送信を制御するのはミキサーの責任です。以下の条件は、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メッセージを送信するときは、次の2つの条件も考慮する必要があります。
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メッセージを送信する場合、これを監視する受信者は、それ以上のPAUSEまたはRESUME要求を送信しないものとします（SHALL NOT）。
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 送信者はセッション内の任意の受信者からのPAUSE要求を受信すると送信を一時停止するため、送信者はどの受信者がRTPストリームを一時停止させたかの記録を保持しなければなりません。その受信者が送信者によって監視されたRTCP BYEメッセージを送信する場合、送信者はRTPストリームを再開する必要があります（SHALL）。ストリームが一時停止されたときにRTPセッションにあったレシーバーはストリームの一時停止に反対していませんが、一時停止中にこれまでに検出されていないレシーバーがセッションに追加された場合、それらのいずれかが原因で一時停止されたストリームの存在を認識できなかった可能性があります一時停止されたRTPストリームに対してPAUSEDが送信されなかったか、それらのレシーバーがPAUSEDをサポートしていませんでした。一時停止中のパーティが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参加者は、セッションの送信者と受信者のリストを保持します。参加者が最後の5つのRTCPレポート間隔で他の参加者からRTPまたはRTCPパケットを取得しなかった場合、その参加者は受信者リストから削除されます。削除された参加者によって一時停止されたストリームはすべて再開されます。
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ストリームセンダーは、ストリームがすでに一時停止状態（セクション6.3）である場合を除き、状態に入るときにすべての既知のRTPストリームレシーバーにPAUSED指示を送信する必要があります（SHALL）。そのような一時停止された表示は十分に繰り返されるべきである
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をPAUSED表示として使用し、すでに一時停止状態にある場合、ローカル一時停止状態に入るときのアクションは、一時停止状態を引き起こした受信した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を送信してはなりません（SHALL NOT）。
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自体を送信する必要があります（SHALL）。
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をPAUSED表示として使用し、ローカルの一時停止状態にあり、TMBBR 0でRTPストリーム送信者自身が使用する値よりも大きい境界設定オーバーヘッド値でTMMBR 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）よりも優先順位が高く、RESUMEメッセージだけでは、ローカルの決定が適用される限り、一時停止された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（RESUME）によって状態を引き起こしているTMMBR 0制限が削除されるまで、その状態を離れることはできません。次に、RTPストリーム送信者がローカルの考慮事項のためにローカルの一時停止状態に留まる必要がある場合、ローカルの一時停止状態を入力してRTPストリームを一時停止し続け、その後、それに応じて動作する必要があります。
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive [RFC6263][RFC5245] applicable to that RTP stream.
RTPストリームを一時停止しても、そのRTPストリームに適用可能なRTPキープアライブ[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.
ローカルの一時停止状態を抜けると、ローカルの一時停止状態の間にそのストリームのPAUSEを送信したRTPストリームレシーバーがあったかどうかに関係なく、ストリーム状態はPlayingになり、そのストリームの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は、3種類の低遅延RTCPフィードバックメッセージ、すなわち、トランスポート層、ペイロード固有、およびアプリケーション層のフィードバックメッセージを定義しています。このドキュメントは、新しいトランスポート層フィードバックメッセージを定義します。これは、PAUSE要求、RESUME要求、PAUSED通知、またはREFUSED通知のいずれかにさらにサブタイプ化されます。
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.
トランスポート層フィードバックメッセージは、AVPF [RFC4585]で定義されているように、RTCPペイロードタイプをRTPFB（205）にすることで識別されます。サブタイプ化されたメッセージの1つ以上を含むこのトランスポート層フィードバックメッセージは、以降、PAUSE-RESUMEメッセージと呼ばれます。特定のFCI形式は、AVPF [RFC4585]のセクション6.1で定義されているフィードバックメッセージの共通パケットヘッダー内のフィードバックメッセージタイプ（FMT）値によって識別されます。 PAUSE-RESUMEトランスポート層フィードバックメッセージ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) :
: :
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:
このメモで定義されているPAUSE-RESUMEメッセージについては、パケットフィールドの次の解釈が適用されます。
FMT: The FMT value identifying the PAUSE-RESUME FCI: 9
FMT：PAUSE-RESUME 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：使用されません。 SHALLは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フィールドは、1つ以上のPAUSE、RESUME、PAUSED、またはREFUSEDメッセージまたは将来の拡張で構成されます。これらのメッセージの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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of FCI Entry in the PAUSE and RESUME Message
図6：PAUSEおよびRESUMEメッセージの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です。 PAUSEDの場合は、SSRCが一時停止されている必要があります。一時停止がPAUSE要求の結果である場合、PAUSEDの値は、関連するPAUSE要求のターゲットSSRCと実質的に同じです。 REFUSEDの場合、状態を変更できないのは、PAUSEまたはRESUME要求のターゲットSSRCでなければなりません。そのような要求の解釈が不明確であるため、CSRCをターゲットとして使用してはなりません。
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：RESUME要求メッセージ。
2: PAUSED indication message.
2：PAUSED表示メッセージ。
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：将来の使用のために予約されています。これらのType値を持つFCIフィールドは、受信者による受信時に無視されるものとし（SHALL）、この仕様を実装する送信者が使用してはならない（MUST NOT）。
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ビット）：タイプ固有の予約済み。これは、この仕様を実装する受信者によって無視されなければならず（SHALL）、この仕様を実装する送信者によって0に設定されなければならない（MUST）。
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で説明されているメッセージシーケンスID。メッセージが再送信されない限り、新しいPAUSEメッセージごとに2 ^ 16を法として1ずつ増加する必要があります。初期値は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.
タイプ固有（変数）：一時停止ごとに定義されるフィードバックタイプ。空の場合があります。この仕様を実装する受信機は、この仕様で定義されているType値であっても、不明なType Specificデータをスキップして無視できる必要があります。
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.
このセクションでのPAUSE、PAUSED、RESUME、およびREFUSEDへの言及は、可能な限り、またこの機能にTMMBR / TMMBNが使用される場合（セクション5.6）に適用されるものとします。有効なトポロジがポイントツーポイントの場合、この仕様で定義されているメッセージの代わりにTMMBR / TMMBNを使用できます。この使用法は、主に、この仕様で定義されているメッセージをサポートしていないが、TMMBR / TMMBNを使用して同様の効果を実現する実装との相互作用に使用することが期待されています。送信者または受信者がトポロジがポイントツーポイントではないことを学習した場合、TMMBR / TMMBNを一時停止/再開機能に使用してはなりません（MUST NOT）。 TMMBR / TMMBNに加えて、この仕様で定義されているメッセージがすべての関係者によってサポートされている場合、一時停止/再開シグナリングは、この仕様のメッセージを使用する必要があります。トポロジがポイントツーポイントではなく、この仕様で定義されているメッセージがサポートされていない場合は、TMMBR / TMMBNによる一時停止/再開機能を使用してはなりません（MUST NOT）。
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をスケジュールできます。
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は、PAUSED（セクション8.2）、REFUSED（セクション8.4）によって示される、または以前に受信したPAUSEまたはRESUME（セクション8.3）要求によって暗黙的に決定される現在のPauseIDである必要があります（SHOULD）。現在のPauseID情報を取得できなかった場合は、ランダムに選択されたPauseIDを使用できます。その場合、PAUSEは成功するか、返されたREFUSEDで現在の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での説明の結果として、メディアによって送信された最後のPAUSED表示で使用されたものと比較して、再送信ではない各PAUSE要求に対して、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でPAUSEを送信したRTPストリームレシーバーが同じターゲットSSRCの同じPauseIDでRESUMEまたはREFUSEDを受信する場合、適切な時間のさらなるPAUSE要求のスケジューリングを控えることが推奨されます。これは、RESUMEがまだストリームを受信したい他の受信者がいることを示し、REFUSEDが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ストリームが一時停止しない場合、一時停止で使用されたものと比較して将来の一時停止IDで一時停止の指示が受信されず、現在または将来の一時停止IDでREFUSEDが2 * RTT + T_dither_max内で受信されない場合、一時停止が発生する場合があります。同じ現在のPauseIDを使用して、再送信がスケジュールされます。 RTTはRTPストリーム送信者への観測された往復であり、T_dither_maxは[RFC4585]のセクション3.4で定義されています。双方向RTP通信のRTPストリームレシーバーは、RTP SR / RRからのRTPストリーム送信者へのRTT見積もりを一般に持っています（セクション6.4で説明されています）。
[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ストリームレシーバーは、RTCP XR [RFC3611]の「Receiver Reference Time Report Block」部分などの追加のメカニズムを使用しない限り、RTTの見積もりがありません。送信者へのRTT見積もりがないRTPストリーム受信者は、デフォルト値として500ミリ秒を使用する必要があります（SHOULD）。
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を持つPAUSEを受信した場合、ローカルの考慮事項により現在ストリームの一時停止が不可能でない限り、一時停止状態（6.2節）に移行し、それに応じて行動するものとします（SHALL）。
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を持つPAUSEを受信した場合、受信したPAUSEは無視されます。
The PAUSED indication, if supported, MUST be sent whenever entering paused state (Section 6.3) or local paused state (Section 6.4).
PAUSED表示は、サポートされている場合、一時停止状態（セクション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.
PAUSEDメッセージのPauseIDには、後続のRESUME（セクション8.3）に含めることができる現在のPauseIDが含まれている必要があります。ローカルの一時停止状態の場合、これは、RTPストリーム送信者が自身にPAUSEを送信したかのように、メッセージ内のPauseIDが現在のPauseIDであることを意味します。
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]).
PAUSED SHALLには、Type Specificフィールドの先頭に固定長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.
一時停止状態またはローカル一時停止状態に入り、一度PAUSEDを送信した後、一時停止状態が引き続き有効であることを考えると、PAUSEDも（少なくとも）次の2つの通常の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節）に従い、PAUSED表示を再送信してもよい（MAY）。これは、ローカルの一時停止状態に入るときに特に重要です。使用する繰り返しの数は、たとえば、目的のメッセージターゲットから受信した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レポートにPAUSEDが含まれる場合があります。
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レポートなどによって、以前にストリームを受信しなかったエンドポイントがあることを知ると、常にPAUSEDをできるだけ早く送信し、（少なくとも）次の2つの定期的な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ストリームレシーバーは、一時停止したストリームを再開したり、ストリームの一時停止を拒否したりする場合はいつでも、RESUMEの送信をスケジュールできます（MAY）。
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は、PAUSED（セクション8.2）によって示されるか、以前に受信したPAUSE（セクション8.1）またはRESUME要求によって暗黙的に決定された現在のPauseIDである必要があります（SHOULD）。現在のPauseID情報を取得できなかった場合は、ランダムに選択されたPauseIDを使用できます。その場合、RESUMEは成功するか、返されたREFUSEDで現在の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でRESUMEを送信したRTPストリームレシーバーが同じPauseIDでREFUSEDを受信した場合、REFUSEが現在ストリームを再開することができないことを示しているため、適切な時間のRESUMEリクエストのスケジューリングを控えることが推奨されます。 。適切な時間はアプリケーションによって異なり、ストリームを再開することの重要性にも依存しますが、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.
RESUMEリクエストは、メッセージがタイムリーに受信者に届く確率を高めるために、送信ルール（8.5節）に従って再送信される場合があります（MAY）。使用する繰り返しの数は、たとえば、目的のメッセージターゲットから受信したRTCPレポートに基づいて、観測された損失率と望ましい損失確率に調整できます。そのような再送信は、ターゲットストリームからのRTPパケットが受信されるとすぐに、またはターゲットRTPストリームの現在のPauseIDでREFUSEDが受信されると停止する必要があります。
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 current PauseID while in paused or pausing state, the RTP stream sender SHALL schedule a REFUSED message for transmission as specified below.
一時停止中（セクション6.2）、一時停止中（セクション6.3）、またはローカル一時停止状態（セクション6.4）のRTPストリーム送信者が現在のPauseIDでRESUMEを受信した場合、ローカルの考慮事項により現在ストリームの再開が不可能でない限り、エントリーをSHALLする必要がありますプレイ状態（6.1節）に従って動作します。 RTPストリームセンダーが現在のPauseIDでRESUMEリクエストを受け入れることができない場合、またはRTPストリームセンダーが一時停止または一時停止の状態のときに現在のPauseIDでないPauseIDでRESUMEリクエストを受け取る場合、RTPストリームセンダーはREFUSEDメッセージをスケジュールする必要があります（SHALL）。下記のように送信。
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のいずれかを含むRESUMEを受信した場合、受信したRESUMEは無視されます。
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を含むPAUSE（セクション8.1）またはRESUME（セクション8.3）リクエストを受信した場合、ローカルの考慮事項により、RTPストリームセンダーは要求されたアクションを実行できないため、拒否通知の送信をスケジュールする必要があります。拒否されたリクエストの現在のPauseIDを含みます。
REFUSED has no defined Type Specific parameters.
REFUSEDには、タイプ固有のパラメータが定義されていません。
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を持つPAUSEまたはRESUMEリクエストを受信した場合、RTPストリームセンダーが再生状態にあり、過去のPauseIDでRESUMEを受信する場合を除いて、現在のPauseIDを含むREFUSED通知をスケジュールする必要があります。この場合、RESUME SHALLは無視されます。
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.
スケジュールされたREFUSEDが送信される前に、同一のREFUSED通知をレンダリングする複数のPAUSEまたはRESUME要求が受信される場合、重複するREFUSED通知を送信するようにスケジュールしてはなりません（MUST NOT）。これにより、単一のREFUSEDがいくつかの無効なPAUSEまたはRESUMEリクエストに効果的に応答できるようになります。
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.
PAUSEまたはRESUMEリクエストを送信し、リクエストと同じPauseIDを含むREFUSEDを受信したRTPストリームレシーバーは、REFUSEDをクリアする原因となった状態を許容するために、適切な時間の間同じリクエストを送信しないでください。一時停止については、セクション8.1で適切な時間を提案します。 RESUMEについては、適切な時間をセクション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.
PAUSEまたはRESUMEリクエストを送信し、リクエストとは異なるPauseIDを含むREFUSEDを受信したRTPストリームレシーバーは、REFUSED通知のPauseIDを使用して別のリクエストをスケジュールできます。
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:
この仕様で定義されているすべてのメッセージと、一時停止/再開の目的（セクション5.6）で使用されるTMMBR / TMMBNは、通常、早期、または即時のタイミングを使用できますが、タイムリーな送信（セクション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帯域幅が通常のタイミングの使用を動機付けることができる再送信を除いて、PAUSEは早期または即時のタイミングを使用することをお勧めします。
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に対する最初のPAUSEDの送信は、即時または早期のタイミングで送信して、不必要なPAUSEの繰り返しを停止することをお勧めします。そのPauseIDのPAUSEDの後続の送信では、複数のPAUSE要求によって引き起こされる過度のPAUSED 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 RTPストリームレシーバーを回避するために、その一時停止IDが一時停止されたRTPストリームのすべてのレシーバーに少なくとも1回配信されたと見なされるまで、未承認のPAUSED（ローカルポーズ状態に入るときに送信（6.4））は常にイミディエートまたはアーリータイミングを使用することをお勧めします。これらは、RTPストリームが受信されなくなったときに不要な修正アクションを実行します。その後、PAUSEは通常のタイミングを使用することをお勧めします（上記のPAUSEによってトリガーされるPAUSEDの場合と同様）。
o RESUME is often time critical, and it is recommended that it always uses Immediate or Early timing.
o RESUMEは多くの場合タイムクリティカルであり、常にイミディエートまたはアーリータイミングを使用することをお勧めします。
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に対するREFUSEDの最初の送信は、PAUSEまたはRESUMEの不要な繰り返しを停止するために、即時または早期のタイミングで送信することをお勧めします。そのPauseIDに対する後続のREFUSED通知では、複数の不当な要求によって引き起こされる過度のREFUSED 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」属性を拡張して、一時停止と再開のリクエストを含めています。この仕様は、セッション記述のペイロードタイプに関連する「rtcp-fb」属性について、AVPF [RFC4585]およびCCM [RFC5104]で定義されたすべてのルールに従います。
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.
この仕様は、CCM [RFC5104]で定義された「ccm」フィードバック値に対する新しいパラメーター「pause」を定義し、RTCPフィードバックメッセージと、PAUSE、RESUME、PAUSED、およびREFUSEDの定義されたすべての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」という2つのオプション属性があります。
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に設定できることを示し、PAUSEリクエストの受信後にストリームを一時停止できるまでのレイテンシを短縮します。この状態は、ポイントツーポイントセッションなど、RTPセッションの方向ごとにレシーバーが1つしかない場合に発生します。単方向メディアを使用するシナリオでも使用できます。 「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」の一時停止属性がない場合は、「config」の値を1に設定することと同等に扱う必要があります。
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ストリームに対してPAUSEおよびRESUMEリクエストを送信することを目的としているため、PAUSEDおよびREFUSEDを受信することもできます。 PAUSEリクエストとRESUMEリクエストの受信はサポートされていませんが、ローカルの考慮事項により、送信されたRTPストリームを一時停止し、PAUSEDを送信する予定です。
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ストリームを対象としたPAUSEおよびRESUMEリクエストの受信をサポートします。必要に応じてPAUSEDおよびREFUSEDを送信します。ノードはPAUSEおよびRESUMEリクエストを送信しませんが、受信したRTPストリームが一時停止されている場合、PAUSEDの受信をサポートおよび希望します。
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ストリームに対してPAUSEおよびRESUMEリクエストを送信することを目的としているため、PAUSEDおよびREFUSEDを受信することもできます。送信するRTPストリームを一時停止することはできないため、PAUSEおよびRESUMEリクエストの受信はサポートされていません。また、PAUSED指示の送信もサポートされていません。
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ストリームを対象としたPAUSEおよびRESUMEリクエストの受信をサポートします。必要に応じてPAUSEDおよびREFUSEDを送信します。受信したRTPストリームを一時停止するためのPAUSEおよびRESUME要求の送信はサポートされていません。また、PAUSED指示の受信もサポートしていません。
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ストリームをサポートするため、PAUSED指示の送信および受信をサポートします。
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ストリームのPAUSED表示をサポートすることを希望しますが、送信したRTPストリームのPAUSED表示を一時停止または送信しません。この仕様で定義されている他のメッセージはサポートしていません。
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ストリームの一時停止とそれらのPAUSED指示の送信をサポートしますが、受信したRTPストリームのPAUSED指示の受信はサポートしません。この仕様で定義されている他のメッセージはサポートしていません。
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」値を通知する場合、実装は受信時にサポートされていないメッセージを無視する必要があり、リモートピアによってサポートされていない送信メッセージを省略する必要があります。一部の受信者がサポートしていないメッセージを送信する動機付けとなる1つの例は、異なるメッセージサポート（異なる「config」値）を持つ複数のメッセージ受信者がいる場合です。このアプローチにより、最小能力のレシーバーが他のレシーバーに提供される機能を制限することを回避できます。次の表は、さまざまな「config」pause属性値のメッセージごとの送受信サポートをまとめたものです（「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：さまざまな「config」値でサポートされるメッセージ
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ミキサーに対応し、「config」値3と5は同じ使用例です。そのユースケースでは、 "config"値3または5のみを実装するRTPミキサーは実用的なソリューションを提供しないことは明らかです。同様に、その使用例では、「config」値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ミキサーへのメディアセンダーでもあり、「config」値2と3または「config」値4と5の結合をサポートする必要があるためです。
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からわかるように、「config」の値2と3は「config」の値4と5とは異なります。後者の場合、PAUSE / RESUMEメッセージの送信側（RTPミキサー側など）はローカルをサポートしません独自のストリームの一時停止（6.4節）のため、PAUSEDの送信もサポートしていません。
Partial implementations that only support local pause functionality can declare this capability through "config" values 6-8.
ローカル一時停止機能のみをサポートする部分的な実装は、「config」値6〜8を介してこの機能を宣言できます。
Viable fallback rules between different "config" values are described in Section 9.1 and Figure 9.
異なる「config」値間の実行可能なフォールバックルールについては、セクション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
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」シグナリングで新しい「一時停止」パラメータを示す必要がありますが、TMMBR / TMMBNを使用するときに機能の制限がある場合は、既存の「ccm tmmbr」シグナリング[RFC5104]を代わりに使用できますこの仕様（セクション5.6）は許容できると見なされます。その場合、メッセージを部分的にサポートすることはできません。この仕様（セクション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」行が複数あることはできません。明示的な「一時停止」指定がないリストされたすべてのペイロードタイプに適用可能と解釈されます。 「config」の一時停止属性は、「一時停止」の各CCMパラメータに対して2回以上指定してはなりません。 「nowait」の一時停止属性は、「一時停止」のCCMパラメータごとに複数回出現してはなりません。
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に適切な構成属性（「構成」）を持つ「一時停止」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オファー/アンサーでは、「config」ポーズ属性とそのメッセージ方向は、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
Figure 9: "config" Values in Offer/Answer
図9：オファー/アンサーの「config」値
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」の一時停止属性を省略したオファーまたはアンサーは、「config = 1」と同等であると解釈する必要があります。この仕様の実装は、オファーまたはアンサーで上記で定義されたもの以外の「config」値を使用してはならず、また、理解できない「config」値を持つオファーを受信した場合、アンサーの「pause」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セッションの唯一のエンドポイントである可能性が高いとオファー側が信じている場合、オファーの「pause」行に「nowait」ポーズ属性を含めることができます。応答側がSDPの「一時停止」行で「待機なし」一時停止属性を受け取り、オファー側とそれ自体がRTPセッションの唯一のエンドポイントではないという情報がある場合、「待機なし」一時停止属性を含めることはできませんSDP回答の「一時停止」行にあります。オファーの「一時停止」行に存在しない限り、回答者は回答の「一時停止」行に「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.
オファーに「pause」と「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.
最初に、「config」の一時停止属性とそのメッセージの方向は、SDPを受信するノードに基づいて解釈され、推奨される操作レベルを示します。参加しているクライアントが指定された「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」の一時停止属性が含まれている場合は、それが指定どおりに続きます。使用に基づいて、構成されたノードがポイントツーポイントのセッションに参加するかどうかを決定するのは、宣言型SDP送信者の責任です。たとえば、Session Announcement Protocol（SAP）[RFC2974]を使用して任意のソースマルチキャストセッション用に構成されている会議クライアントは、ポイントツーポイントセッションに含まれないため、「nowait」を含めることはできません。 Real-Time Streaming Protocol（RTSP）[RFC2326]宣言型SDPを受信するクライアントは、ポイントツーポイントセッションにいる可能性が非常に高いですが、RTSPクライアントがこの仕様をサポートする必要があるかどうかは非常に疑わしく、固有のPAUSE 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:
次の例は、オファー/アンサーの使用を含む、PAUSEおよびRESUMEメッセージの使用を示しています。
1. Offer/Answer
1. オファー/アンサー
2. Point-to-Point Session
2. ポイントツーポイントセッション
3. Point to Multipoint using Mixer 4. Point to Multipoint using Relay
3.ミキサーを使用したマルチポイントへのポイント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
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」ポーズ属性は省略します。提供者はまた、それが応答者のストリームの唯一の受信者であり、応答者が提供者のストリームの唯一の受信者であると考えているため、「一時停止」パラメーターの「待機なし」一時停止属性が含まれます。
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
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 = 4」ではなく「config = 2」が選択されています。回答者は、それがポイントツーポイントRTPセッションではないことをどういうわけか知っているため、「一時停止」行から「待機なし」を削除しました。ストリーム。
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を使用して一時停止および再開機能を実現する場合、CCMと比較してSDPに違いはありません[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.
これは最も基本的なシナリオで、2人の参加者が関与し、それぞれが送信者または受信者として機能します。 RTPデータレシーバーは、PAUSEまたはRESUMEメッセージを送信者に送信し、送信者はそれに応じて送信を一時停止または再開します。ストリームを一時停止する前のホールドオフ期間は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) |
| -------------------------------> |
: :
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受信者はPauseID 3（この例では以前からわかっていた）を使用して、送信者にストリームの一時停止を要求します。送信者はデータを一時停止し、同じPauseIDを含むPAUSEDで応答します。しばらくして（時刻t4で）、受信側は送信側に再開を要求し、送信を再開します。時間t6に送信された次のPAUSEには、更新されたPauseID（4）が含まれ、対応するPAUSEDが時間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 |
| -------------------------------> |
: :
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 |
| -------------------------------> |
: :
Figure 14: Unsolicited PAUSED Using TMMBN
図14：TMMBNを使用した一方的なPAUSED
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バウンディングセットに自身を含めて、TMMBN 0を使用してPAUSEDを通知します。時間t3で、RTPストリームがまだ一時停止しているという事実にもかかわらず、BはRTPストリームを受信する必要がないと判断し、TMMBR 0を送信してPAUSEを通知します。その結果、境界セットには両方のAが含まれますBとAは、それを反映した新しいTMMBNを送信します。しばらくすると、時刻t5で、AがRTPストリームを一時停止する原因となったローカルの考慮事項が適用されなくなり、Aが自身を境界セットから削除し、これを示す新しいTMMBNを送信します。時間t6で、BはRTPストリームを再び受信することに関心があると判断し、0より大きいビットレート値を含むTMMBRを送信してRESUMEを通知し、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) |
| <------------------------------------ |
: :
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ストリームレシーバーからのPAUSEメッセージがRTPストリームセンダーに到達しない場合にどうなるかを示しています。一時停止メッセージを送信した後、RTPストリームレシーバーはタイムアウトを待って、RTPストリームセンダーがデータ送信を一時停止したか、セクション6.3で説明したルールに従ってPAUSED指示を送信したかどうかを検出します。途中でPAUSEメッセージが失われると（時刻t2）、RTPデータはRTPストリームレシーバーに到達し続けます。タイマーが期限切れになると、RTPストリームレシーバーは、時刻t4に送信されるPAUSEメッセージの再送信をスケジュールします。 PAUSEメッセージがRTPストリーム送信者に到達すると、RTPストリームを一時停止し、PAUSEDで応答します。
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 may, for example, be one RTCP feedback transmission interval as determined by the AVPF rules.
時間ｔ６で、ＲＴＰストリーム受信機はストリームを再開することを望み、失われた再開を送信する。さらにRESUMEリクエストが送信されるまで待つ必要はなく、別のRESUMEがすでに時刻t7に送信されており、RTPストリームセンダーに到達して、結果的に時刻t8にストリームを再開するため、これは深刻な影響を引き起こしません。 ｔ６とｔ７との間の時間間隔は変化し得るが、例えば、ＡＶＰＦ規則によって決定されるような１つのＲＴＣＰフィードバック送信間隔であり得る。
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ストリームが時間内に再開され、さらに別のスケジュールされたRESUMEが時刻t9に送信されないようにすることを認識しませんでした。ただし、RESUMEには過去のPauseIDが含まれており、RTPストリーム送信者によって無視されるため、これは無害です。また、RESUMEを受信する前に他のレシーバーからのPAUSEに基づいてストリームが再び一時停止された場合でも、現在のPauseIDが、過去を含む浮遊RESUMEのものと比較して更新されているため、RTPストリームは再開されません。 PauseIDであり、RTPストリーム送信者によって無視されます。
+---------------+ +---------------+
| 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では、受信者が送信者の一時停止を要求しています。送信者のローカルな考慮事項により、受信者は一時停止を拒否し、REFUSEDメッセージで応答します。
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ソースからストリームを受信し、アプリケーションのニーズに基づいてそれらを選択または結合し、生成されたストリームを宛先に転送します。ミキサーは通常、元のソースではなく独自のSSRCをRTPデータパケットに入れます。
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 stream will be delivered to R using M's SSRC and with a CSRC indicating the original source.
ミキサーは、ミキサーに配信されたすべてのストリームと、それらが現在どのように使用されているかを追跡します。この例では、ミキサー（M）は、RTPストリーム送信者（S1およびS2）の音声アクティビティに基づいて、RTPストリーム受信者（R）に配信するビデオストリームを選択します。ビデオストリームは、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> | |
: : : :
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 t9, which is acknowledged at t10 with PAUSED, and the RTP stream from S1 stops being delivered.
セッションはt1で始まり、S1が最もアクティブなスピーカーなので、MのSSRCを使用してR（t2）に配信される単一のビデオストリームとして選択されますが、CSRCとしてS1が使用されます（図のコロンの後に示されています）。次に、S2はt3でセッションに参加し、RTPストリームのMへの配信を開始します。S2の音声アクティビティが少ないため、S1は、S2にPAUSE要求を送信することにより、t4でS2を一時停止することを決定します。 t5で、S2はPAUSEDで確認し、同時にMへのRTPの配信を停止します。t6で、S2のユーザーが話し始め、最もアクティブなスピーカーになり、MはビデオストリームをS2に切り替えることを決定し、そのためすぐにRESUMEリクエストを送信しますS2に。 t7で、S2はRESUME要求を受信し、MへのRTPストリーム配信を再開することで動作します。t7からのRTPストリームがMに到着すると、t8でこのRTPストリームをSSRC（M）に切り替え、CSRCをS2に変更します。 。 S1が未使用になると、Mはt9でPA1要求をS1に発行します。これはPAUSEDで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セッションのトランスポートリレーは、1つのピアから他のすべてのピアにメッセージを転送します。ミキサーとは異なり、リレーはストリームを混合したり、メッセージや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) |
| |------------------>|
: : :
Figure 18: Pause and Resume Operation between Two Participants Using a Relay
図18：リレーを使用した2人の参加者間の操作の一時停止と再開
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 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.
図18は、リレーが送信者（S）を一時停止および再開する際に受信者（R）をどのように支援できるかを示しています。 SはRTPデータをリレーを介してRに送信し、リレーはSSRCを変更せずにデータを転送するだけです。 RはSにPAUSE要求を送信します。この例では、ストリームのレシーバがさらに存在する可能性があることを認識し、ゼロ以外のホールドオフ期間を待って、データを受信する必要のある他のレシーバがあるかどうかと、いつ不承認のRESUMEメッセージは受信されず、一時停止してPAUSEDで応答します。同様に、Rはリレーを介してRESUME要求を送信することでSを再開します。これは、単一のRTPストリーム送信側の単一の一時停止および再開操作のみを説明しているため、すべてのメッセージが単一のPauseIDを使用します。この例では3です。
+-----+ +-----+ +-----+ +-----+
| 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：リレーを介した1つの送信者と2つの受信者間の操作の一時停止と再開
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セッションでトランスポートリレー（Rel）が送信者（S）と2つの受信者（R1およびR2）の間に含まれる場合の一時停止および再開操作を説明しています。各メッセージ交換は、発生した時間によって表されます。時間t1で、SはRTPストリームのRelへの送信を開始し、RelはRelをR1およびR2に転送します。 R1とR2は、t2でRelからRTPデータを受信します。この時点で、R1とR2の両方がRTCP受信者レポートをSに送信し、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からPAUSE要求を受信すると、Sは、まだデータを受信したい受信者が少なくとも1人いることを知っており、ゼロ以外のホールドオフ期間を使用して、可能なRESUMEメッセージを待機します。 R2はまた、時刻t4でPAUSE要求を受信しましたが、それでもストリームの受信を希望しているため、時刻t5でそのためにRESUMEを送信します。これはRelによって送信者Sに転送されます。 Sは時刻t6でRESUMEを確認し、Relにデータを送信し続け、RelはR1とR2の両方に転送します。 t7で、R2は、更新されたPauseIDでPAUSE要求を送信することにより、ストリームを一時停止することを選択します。 Sは、ストリームを必要とする可能性のある複数のレシーバー（R1およびR2）がいることを認識し、ゼロ以外のホールドオフ期間を再び待機します。その後、不承認のRESUMEメッセージを受信しなかったため、ストリームは一時停止します。 Sはストリームの送信を停止し、PA1EDでR1およびR2に応答します。レシーバー（R1またはR2）がSからストリームを再開することを選択すると（この例ではR1）、SにRESUME要求を送信します（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.
1つ以上の受信者、一時停止した送信者、およびリレーを含む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. メディアストリームの一時停止/再開の新しい値は、公開時に<http://www.iana.org/assignments/rtp-parameters>にある「RTPFB Payload TypesのFMT値」レジストリに登録されています。
Value: 9
値：9
Name: PAUSE-RESUME
名前：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. 公開時に<http://www.iana.org/assignments/sdp-parameters>にある「Codec Control Messages」レジストリでIANAに登録される新しい値「pause」。
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]を拡張し、PAUSE、RESUME、PAUSED、REFUSEDなどの新しいメッセージを定義します。これらの新しいメッセージの交換には、セキュリティ上の意味があり、ユーザーが対処する必要があります。
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 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].
この仕様で定義されているメッセージは、悪意のある方法で使用された場合、認識されるメディア品質に大きな影響を与える可能性があります。まず、PAUSE-RESUME機能を使用するすべてのRTPセッションでサービス拒否（DoS）のリスクがあります。特にホールドオフ期間がゼロの場合、攻撃者は1つ以上のPAUSE要求をRTPセッションに挿入することにより、メディアのフローを阻止できる可能性があります。 PAUSEメッセージの挿入は非常に簡単で、SSRCとPauseIDの知識が必要です。 RTCPメッセージが暗号化されていない限り、この情報はパス上の攻撃者に表示されます。 16ビットのPauseIDを推測または試行する必要がある一方で、シグナリングメッセージにはSSRC値が含まれていることが多いため、オフパス攻撃も可能です。これらの挿入からRTPセッションを保護する方法は、メッセージの整合性と組み合わせてソース認証を実行して、意図したセッション参加者以外がこれらのメッセージを送信しないようにすることです。セキュリティソリューションは、再生保護を提供する必要があります。そうでない場合、PauseID値がラップするほどセッションが長く存続すると、攻撃者は適切なタイミングで古いメッセージを再生して、メディア送信者の状態に影響を与える可能性があります。このタイプの攻撃を防ぐために、RTPセッションを保護するためのいくつかの異なる選択肢があります。 Secure Real-time Transport Protocol（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を保護するためのほとんどの方法では、マルチパーティのユースケースで個々の参加者のソース認証を提供していません。セッション参加者の1人が悪意のある場合、RTPセッション内で重大な混乱を引き起こし、同様に内部からRTPセッションでDoSを引き起こす可能性があります。攻撃者がセッション内の他のエンドポイントになりすまして、その被害を難読化することもできます。これらの攻撃は、すべての参加者のRTCPパケットの真のソース認証を提供するソリューションを使用することで軽減できます。ただし、これには他の影響もあります。ミドルボックスを含むマルチパーティセッションの場合、そのミドルボックスは、転送されたすべてのRTCPパケットのチェックを実行することをお勧めします。これにより、各参加者はSSRCのセットのみを使用して、攻撃者が別の参加者のSSRCを利用するのを防ぎます。メディア送信者以外の参加者に到達しないPAUSEリクエストを送信できる攻撃者は、反対の機会を提供せずにストリームを一時停止させることができます。これは、要求がすべてまたはほとんどのRTPセッション参加者によって確実に認識されるようにするマルチパーティトポロジで緩和され、これらの参加者がRESUMEを送信できるようにします。 PAUSE要求を消費および処理するミドルボックスを使用するトポロジでは、ミドルボックスは、他の参加者がメディアストリームを使用していることを知っている場合にPAUSEメッセージを生成または転送しないため、このような動作を軽減することもできます。
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セッションに悪意のある影響を与えるためのツールとしてPAUSEメッセージを使用することに焦点を当てています。これは、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.
セッション確立シグナリングは、シグナリングメッセージを変更することによって一時停止および再開機能の有効化を防ぐために使用できるため、潜在的な攻撃の場でもあります。上記のソース認証に基づく攻撃の緩和には、シグナリングシステムがIDを安全に処理し、意図したIDのみが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：A Transport Protocol for Real-Time Applications」、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：Session Description Protocol」、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プロファイル（RTP / AVPF） "、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、2月2008、<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]クロッカー、D。、エド。および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。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、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受信統計とその他のフィードバックのグループ化」、進行中の作業、draft-ietf-avtcore-rtp-multi-stream-optimization-11、2015年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、「Real Time Streaming Protocol（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、「Session Announcement Protocol」、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：Session Initiation Protocol」 、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]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年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 Payload Format for Scalable Video Coding」、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.、Hakansson、S。、およびG. Eriksson、「Web Real-Time Communication Use Cases and Requirements」、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、編、「リアルタイムの転送プロトコル（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. 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]バーマン、B。、ウェスタールンド、M。、ナンダクマール、S。、およびM.ザナティー、「SDPおよびRTPセッションでのSimulcastの使用」、作業中、draft-ietf-mmusic-sdp-simulcast-04 、2016年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は、このドキュメントの最初のバージョンで貴重な貢献をしました。著者はまた、貴重なレビューコメントを提供してくれたEmil Ivov、Christian Groves、David Mandelberg、Meral Shirazipour、Spencer Dawkins、Bernard Aboba、およびBen Campbellにも感謝します。
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"ポーズ属性と、オファー/アンサーでのその使用に大きく貢献しました。
Authors' Addresses
著者のアドレス
Bo Burman Ericsson Kistavagen 25 SE - 164 80 Kista Sweden
Bo Burman Ericsson Kistavagen 25 SE-164 80 Kistaスウェーデン
Email: bo.burman@ericsson.com
Azam Akram Ericsson Farogatan 6 SE - 164 80 Kista Sweden
Azam Akram Ericsson Farogatan 6 SE-164 80 Kistaスウェーデン
Phone: +46107142658
Email: akram.muhammadazam@gmail.com
URI: www.ericsson.com
Roni Even Huawei Technologies Tel Aviv Israel
Roni Even Huawei Technologiesテルアビブイスラエル
Email: roni.even@mail01.huawei.com
Magnus Westerlund Ericsson Farogatan 6 SE - 164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kistaスウェーデン
Phone: +46107148287
Email: magnus.westerlund@ericsson.com