[要約] RFC 7272は、RTP制御プロトコル（RTCP）を使用したインターデスティネーションメディア同期（IDMS）に関する規格です。このRFCの目的は、複数のメディアストリームを同期させるためのプロトコルを提供することです。
Internet Engineering Task Force (IETF) R. van Brandenburg
Request for Comments: 7272 H. Stokking
Category: Standards Track O. van Deventer
ISSN: 2070-1721 TNO
F. Boronat
M. Montagud
UPV
K. Gross
AVA Networks
June 2014
Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)
RTP制御プロトコル（RTCP）を使用した宛先間メディア同期（IDMS）
Abstract
概要
This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.
このドキュメントでは、新しいRTPコントロールプロトコル（RTCP）パケットタイプとRTCP拡張レポート（XR）ブロックタイプを定義して、宛先間メディア同期（IDMS）を実現します。 IDMSは、複数のメディアレシーバー間で再生を同期するプロセスです。このドキュメントで定義されているRTCP XR IDMSレポートブロックを使用して、同期グループの参加者からのメディアプレイアウト情報を収集できます。収集された情報に基づいて、RTCP IDMS設定パケットを送信して、メディアエクスペリエンスを共有するすべての分散型レシーバーが同期できる共通のターゲットプレイアウトポイントを分散できます。
Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.
IDMSが役立つ典型的な使用例は、ソーシャルTV、共有サービスコントロール（つまり、地理的に離れた2人以上のユーザーが一緒にメディアストリームを視聴しているアプリケーション）、遠隔学習、ネットワークビデオウォール、ネットワークスピーカーなどです。
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/rfc7272.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7272で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 3
2.2. IDMS and ETSI . . . . . . . . . . . . . . . . . . . . . . 4
3. Inter-Destination Media Synchronization (IDMS) Use Cases . . 4
4. Overview of IDMS Operation . . . . . . . . . . . . . . . . . 5
5. Architecture for Inter-Destination Media Synchronization . . 7
5.1. Media Synchronization Application Server (MSAS) . . . . . 7
5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 8
5.3. Communication between MSAS and SCs . . . . . . . . . . . 8
6. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . . . . 8
7. RTCP Packet Type for IDMS (IDMS Settings Packet) . . . . . . 11
8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13
9. On the Use of Presentation Timestamps . . . . . . . . . . . . 14
10. SDP Signaling for RTCP IDMS Settings Packet . . . . . . . . . 15
11. SDP Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Offer/Answer Rules . . . . . . . . . . . . . . . . . . . 16
11.2. Declarative Cases . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13.1. RTCP IDMS Packet Type . . . . . . . . . . . . . . . . . 18
13.2. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . 19
13.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 19
13.4. IDMS XR Block SPST Registry . . . . . . . . . . . . . . 19
13.5. Contact Information for Registrations . . . . . . . . . 20
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . 21
IDMS refers to the playout of media streams at two or more geographically distributed locations in a time-synchronized manner. It can be applied to both unicast and multicast media streams and can be applied to any type and/or combination of streaming media, such as audio, video, and text (subtitles). [Ishibashi2006] and [Boronat2009] provide an overview of technologies and algorithms for IDMS.
IDMSは、地理的に分散した2つ以上の場所で時間同期された方法でメディアストリームを再生することを指します。ユニキャストとマルチキャストの両方のメディアストリームに適用でき、オーディオ、ビデオ、テキスト（字幕）など、ストリーミングメディアの任意のタイプや組み合わせに適用できます。 [Ishibashi2006]と[Boronat2009]は、IDMSのテクノロジーとアルゴリズムの概要を示しています。
Inter-Destination Media Synchronization (IDMS) requires the exchange of information on media arrival and presentation times among participants in an IDMS session. It may also require signaling for the initiation and maintenance of IDMS sessions and groups of receivers.
Inter-Destination Media Synchronization（IDMS）では、IDMSセッションの参加者間でメディアの到着とプレゼンテーション時間に関する情報を交換する必要があります。 IDMSセッションと受信機のグループの開始と保守のためのシグナリングも必要になる場合があります。
The presented RTCP specification for IDMS is independent of the synchronization algorithm employed, which is out of scope of this document.
提示されたIDMSのRTCP仕様は、採用されている同期アルゴリズムとは無関係であり、このドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Currently, a large share of real-time applications make use of RTP and RTCP [RFC3550]. RTP provides end-to-end network transport functions suitable for applications requiring real-time data transport, such as audio, video, or data, over multicast or unicast network services. The timestamps, sequence numbers, and payload (content) type identification mechanisms provided by RTP packets are very useful for reconstructing the original media timing and the original order of packets and for detecting packet loss at the receiver.
現在、リアルタイムアプリケーションの大部分はRTPとRTCP [RFC3550]を利用しています。 RTPは、マルチキャストまたはユニキャストネットワークサービスを介して、オーディオ、ビデオ、データなどのリアルタイムのデータ転送を必要とするアプリケーションに適したエンドツーエンドのネットワーク転送機能を提供します。 RTPパケットによって提供されるタイムスタンプ、シーケンス番号、およびペイロード（コンテンツ）タイプ識別メカニズムは、元のメディアタイミングと元のパケットの順序を再構築し、受信側でパケット損失を検出するのに非常に役立ちます。
The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner that is scalable to large groups and to provide minimal control and identification functionality. RTP receivers and senders provide reception quality feedback by sending out RTCP receiver report (RR) and sender report (SR) packets [RFC3550], respectively, which may be augmented by extended report (XR) blocks [RFC3611].
データトランスポートは、制御プロトコル（RTCP）によって拡張され、大規模なグループに拡張可能な方法でデータ配信の監視を可能にし、最小限の制御および識別機能を提供します。 RTPレシーバーとセンダーは、それぞれRTCPレシーバーレポート（RR）パケットとセンダーレポート（SR）パケット[RFC3550]を送信することにより、受信品質のフィードバックを提供します。これらは、拡張レポート（XR）ブロック[RFC3611]によって補強されます。
IDMS involves the collection, summarization, and distribution of RTP packet arrival and presentation times. As information on RTP packet arrival times and presentation times can be considered reception quality feedback information, RTCP is well suited for carrying out IDMS.
IDMSには、RTPパケットの到着時間と表示時間の収集、要約、および配布が含まれます。 RTPパケットの到着時間とプレゼンテーション時間に関する情報は、受信品質のフィードバック情報と見なすことができるため、RTCPはIDMSの実行に適しています。
A first version of IDMS for use with RTP/RTCP was standardized by ETSI Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) in [TS183063], resulting in an IANA registration for an RTCP XR Block Type. This work was then brought as input to the IETF AVTCORE WG for further standardization, leveraging the RTP/RTCP expertise present in the AVTCORE WG. This document is the result of that effort.
RTP / RTCPで使用するIDMSの最初のバージョンは、[TS183063]のETSIテレコミュニケーションおよびインターネットコンバージドサービスおよびプロトコル（TISPAN）によって標準化され、RTCP XRブロックタイプのIANA登録になりました。この作業は、さらなる標準化のためにIETF AVTCORE WGへの入力として持ち込まれ、AVTCORE WGに存在するRTP / RTCPの専門知識を活用しました。このドキュメントはその努力の結果です。
Although the IDMS protocol described in this document has evolved significantly from the version that was originally specified by ETSI TISPAN, it is still backwards compatible with the ETSI version. As such, it had been decided in ETSI to update the TS 183 063 document to reference this document as the normative specification of IDMS. This update can be found in newer versions of TS 183 063 (i.e., versions higher than 3.5.2). In accordance, this document proposes to update the IANA registration for the RTCP XR IDMS Report Block to point to this document. Finally, this document proposes an IANA registry for Synchronization Packet Sender Type (SPST) values, allowing the registration of extensions to this document.
このドキュメントで説明されているIDMSプロトコルは、もともとETSI TISPANで指定されていたバージョンから大幅に進化しましたが、まだETSIバージョンとの下位互換性があります。そのため、ETSIでは、TS 183 063ドキュメントを更新して、このドキュメントをIDMSの標準仕様として参照することが決定されています。この更新は、TS 183 063の新しいバージョン（つまり、3.5.2以降のバージョン）に含まれています。したがって、このドキュメントでは、RTCP XR IDMSレポートブロックのIANA登録を更新して、このドキュメントをポイントすることを提案しています。最後に、このドキュメントでは、同期パケット送信者タイプ（SPST）値のIANAレジストリを提案し、このドキュメントへの拡張の登録を可能にします。
There is a large number of use cases in which IDMS might be useful. This section will highlight some of them. It should be noted that this section is in no way meant to be exhaustive.
IDMSが役立つユースケースは多数あります。このセクションでは、それらのいくつかを取り上げます。このセクションは決して網羅的なものではないことに注意してください。
A first usage scenario for IDMS is social TV. Social TV is the combination of media content consumption by two or more users at different devices and locations combined with real-time communication between those users. An example of social TV is when two or more users are watching the same television broadcast at different devices and locations, while communicating with each other using text, audio, and/or video. A skew in their media playout processes can have adverse effects on their experience. A well-known use case here is one friend experiencing a goal in a football match well before or after another friend(s).
IDMSの最初の使用シナリオはソーシャルTVです。ソーシャルTVは、異なるデバイスや場所にいる2人以上のユーザーによるメディアコンテンツの消費と、それらのユーザー間のリアルタイムのコミュニケーションを組み合わせたものです。ソーシャルTVの例は、2人以上のユーザーが異なるデバイスや場所で同じテレビ放送を視聴し、テキスト、オーディオ、ビデオを使用して互いに通信している場合です。メディア再生プロセスのスキューは、エクスペリエンスに悪影響を与える可能性があります。ここでよく知られているユースケースは、ある友人が別の友人の前または後にサッカーの試合でゴールを経験している場合です。
Another potential use case for IDMS is a networked video wall. A video wall consists of multiple computer monitors, video projectors, or television sets tiled together contiguously or overlapped in order to form one large screen. Each of the screens reproduces a portion of the larger picture. In some implementations, each screen may be individually connected to the network and receive its portion of the overall image from a network-connected video server or video scaler. Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh is not synchronized, the effect of multiple screens acting as one is broken, with users noticing tearing effects and no longer perceiving a single image.
IDMSのもう1つの潜在的な使用例は、ネットワーク化されたビデオウォールです。ビデオウォールは、1つの大きな画面を形成するために、連続して並べて、または重なり合った複数のコンピューターモニター、ビデオプロジェクター、またはテレビで構成されます。各画面は、大きな画像の一部を再現します。いくつかの実装形態では、各画面は個別にネットワークに接続され、ネットワークに接続されたビデオサーバーまたはビデオスケーラーから画像全体のその一部を受信します。画面は60ヘルツ（16-2 / 3ミリ秒ごと）またはより高速で更新される可能性があります。更新が同期されていない場合、1つの画面として機能している複数の画面の効果が失われ、ユーザーはティアリング効果に気づき、1つの画像を認識しなくなります。
A third usage scenario is that of networked loudspeakers in which two or more speakers are connected to the network individually. Such situations can, for example, be found in large conference rooms, legislative chambers, classrooms (especially those supporting distance learning), and other large-scale environments such as stadiums. Since humans are more sensitive to differences in audio delay compared to video delay, this use case needs even more accuracy than the video wall use case. Depending on the exact application, the need for accuracy can then be in the range of microseconds.
3番目の使用シナリオは、2つ以上のスピーカーが個別にネットワークに接続されているネットワーク化されたスピーカーのシナリオです。このような状況は、たとえば、大規模な会議室、立法会議室、教室（特に遠隔学習をサポートするもの）、およびスタジアムなどの他の大規模な環境で見られます。人間はビデオ遅延よりもオーディオ遅延の違いに敏感であるため、この使用例はビデオウォールの使用例よりもさらに正確である必要があります。正確なアプリケーションによっては、精度の必要性がマイクロ秒の範囲になる場合があります。
This section provides a brief example of how the RTCP functionality is used for achieving IDMS. The section is tutorial in nature and does not contain any normative statements.
このセクションでは、RTCP機能を使用してIDMSを実現する方法の簡単な例を示します。このセクションは本来チュートリアルであり、規範的な記述は含まれていません。
Alice's . . . . . . .tv:abc.com . . . . . . . Bob's
TV (Sync Client) (Sync Server) Laptop (Sync Client)
| | |
| Media Session | |
|<=====================>| |
| Invite(URL, SyncGroupId) |
|------------------------------------------------->|
| | Media Session Setup |
| |<========================>|
| | |
| Call Setup |
|<================================================>|
| | |
| RTP Packets | RTP Packets |
|<----------------------|------------------------->|
| RR + XR IDMS Report | |
|---------------------->| RR + XR IDMS Report |
| |<-------------------------|
| RTCP IDMS Settings | RTCP IDMS Settings |
|<----------------------|------------------------->|
| | |
Figure 1: Example of a Typical IDMS Session
図1：典型的なIDMSセッションの例
Alice is watching TV in her living room. At some point, she sees that Bob's favorite team is playing football. She sends him an invite to watch the program together. Embedded in the invitation is the link to the media server and a unique sync-group identifier.
アリスはリビングルームでテレビを見ています。ある時点で、彼女はボブのお気に入りのチームがサッカーをしているのを見ます。彼女は彼に番組を一緒に見たいという誘いを送ります。招待状には、メディアサーバーへのリンクと一意の同期グループ識別子が埋め込まれています。
Bob, who is also at home, receives the invite on his laptop. He accepts Alice's invitation, and the RTP client on his laptop sets up a session with the media server. A Voice over IP (VoIP) connection to Alice's TV is also set up, so that Alice and Bob can talk while watching the game together.
自宅にもいるボブは、自分のラップトップで招待状を受け取ります。彼はアリスの招待を受け入れ、ラップトップのRTPクライアントがメディアサーバーとのセッションをセットアップします。アリスのテレビへのボイスオーバーIP（VoIP）接続もセットアップされているので、アリスとボブは一緒にゲームを見ながら話をすることができます。
As is common with RTP, both the RTP client in Alice's TV as well as the one in Bob's laptop send periodic RTCP RRs to the media server. However, in order to make sure Alice and Bob see the events in the football game at the same time, their clients also periodically send an RTCP XR IDMS Report Block to the Sync Server function of the media server. Included in the RTCP XR IDMS Report Blocks are timestamps on when both Alice and Bob received (and, optionally, when they played out) a particular RTP packet.
RTPと同様に、アリスのTVのRTPクライアントとボブのラップトップのRTPクライアントの両方が、定期的にRTCP RRをメディアサーバーに送信します。ただし、アリスとボブがサッカーの試合のイベントを同時に確認できるようにするために、クライアントは定期的にRTCP XR IDMSレポートブロックをメディアサーバーの同期サーバー機能に送信します。 RTCP XR IDMSレポートブロックには、アリスとボブの両方が特定のRTPパケットを受信したとき（およびオプションで、それらが再生されたとき）のタイムスタンプが含まれます。
The Sync Server function in the media server calculates a reference client from the received RTCP XR IDMS Report Blocks (e.g., by selecting the most lagged client as the reference for IDMS). It then sends an RTCP IDMS Settings Packet containing the playout information of this reference client to the sync clients of both Alice and Bob.
メディアサーバーの同期サーバー機能は、受信したRTCP XR IDMSレポートブロックから参照クライアントを計算します（IDMSの参照として最も遅れたクライアントを選択するなど）。次に、この参照クライアントのプレイアウト情報を含むRTCP IDMS設定パケットを、アリスとボブの両方の同期クライアントに送信します。
In this case, Bob's connection has the longest delay and the reference client, therefore, includes a delay similar to the one experienced by Bob. Upon reception of this information, Alice's RTP client can choose what to do with this information. In this case, it decreases its playout rate temporarily until the playout time matches with the reference client playout (and, thus, matches Bob's playout). Another option for Alice's TV would be to simply pause playback until it catches up. The exact implementation of the synchronization algorithm is up to the client.
この場合、Bobの接続には最も長い遅延があり、参照クライアントには、Bobが経験したものと同様の遅延が含まれます。この情報を受信すると、アリスのRTPクライアントはこの情報をどう処理するかを選択できます。この場合、プレイアウト時間が参照クライアントのプレイアウトと一致する（したがって、ボブのプレイアウトと一致する）まで、プレイアウトレートを一時的に下げます。アリスのTVのもう1つのオプションは、追いつくまで再生を一時停止することです。同期アルゴリズムの正確な実装はクライアント次第です。
Upon reception of the RTCP IDMS Settings Packet, Bob's client does not have to do anything since it is already synchronized to the reference client (since it is based on Bob's delay). Note that other synchronization algorithms may introduce even more delay than the one experienced by the most delayed client, e.g., to account for delay variations, for new clients joining an existing synchronization group, etc.
RTCP IDMS設定パケットを受信すると、ボブのクライアントはすでに参照クライアントに同期されているため（ボブの遅延に基づいているため）、何もする必要はありません。他の同期アルゴリズムでは、遅延の変動を考慮したり、既存の同期グループに参加する新しいクライアントの場合など、最も遅延しているクライアントが経験するよりもさらに遅延が発生する可能性があることに注意してください。
For this functionality to work correctly, it is necessary that the wallclocks of the receivers are synchronized with each other. While Alice and Bob both report when they receive, and optionally when they playout, certain RTP packets, in order to correlate their reports to each other, it is necessary that their wallclocks are synchronized.
この機能を正しく動作させるには、レシーバーのウォールクロックが互いに同期している必要があります。アリスとボブは両方とも、受信したとき、およびオプションで再生時に特定のRTPパケットを報告しますが、それらの報告を相互に関連付けるには、壁時計が同期している必要があります。
The architecture for IDMS, which is based on a sync-maestro architecture [Boronat2009], is diagrammed below. In this particular case, the Synchronization Client (SC) and Media Synchronization Application Server (MSAS) entities are shown as additional functionality for the RTP receiver and sender, respectively.
sync-maestroアーキテクチャ[Boronat2009]に基づくIDMSのアーキテクチャを以下に示します。この特定のケースでは、同期クライアント（SC）とメディア同期アプリケーションサーバー（MSAS）のエンティティが、それぞれRTP受信者と送信者の追加機能として示されています。
+-----------------------+ +-----------------------+
| | SR + | |
| RTP Receiver | RTCP | RTP Sender |
| | IDMS | |
| +-----------------+ | <----- | +-----------------+ |
| | | | | | | |
| | Synchronization | | | | Media | |
| | Client | | | | Synchronization | |
| | (SC) | | | | Application | |
| | | | | | Server | |
| | | | RR+XR | | (MSAS) | |
| | | | -----> | | | |
| +-----------------+ | | +-----------------+ |
| | | |
+-----------------------+ +-----------------------+
Figure 2: IDMS Architecture Diagram
図2：IDMSアーキテクチャ図
An MSAS collects RTP packet arrival times and presentation times from one or more SCs in a synchronization group by receiving RTCP XR IDMS reports. The MSAS summarizes and distributes this information to the SCs in the synchronization group as synchronization settings via the RTCP IDMS Settings Packet messages, e.g., by determining the SC with the most lagged playout and using its reported RTP packet arrival time and presentation time as a summary.
MSASは、RTCP XR IDMSレポートを受信することにより、同期グループ内の1つ以上のSCからRTPパケットの到着時間とプレゼンテーション時間を収集します。 MSASは、RTCP IDMS設定パケットメッセージを介して同期設定として同期グループ内のSCにこの情報を要約して配信します。たとえば、最も遅れたプレイアウトを持つSCを特定し、その報告されたRTPパケット到着時間とプレゼンテーション時間を要約として使用します。 。
It should be noted that while the diagram above shows the MSAS as part of the RTP sender, this is not necessary. For example, an MSAS might also be implemented as an independent function in the network or in a master/slave type of architecture where one of the SC devices also acts as an MSAS. Wherever the MSAS is implemented, it is important that the MSAS has access to the RTP stream to which the XR reports apply, so that it is able to correlate the RTCP XR IDMS reports coming from different SCs.
上記の図では、MSASをRTP送信側の一部として示していますが、これは必須ではないことに注意してください。たとえば、MSASは、ネットワーク内の独立した機能として、またはSCデバイスの1つがMSASとしても機能するマスター/スレーブタイプのアーキテクチャで実装される場合もあります。 MSASが実装されている場合は常に、MSRがXRレポートが適用されるRTPストリームにアクセスできるようにすることが重要です。これにより、異なるSCからのRTCP XR IDMSレポートを相互に関連付けることができます。
An SC reports on RTP packet arrival times and presentation times of a media stream. It can receive IDMS Settings Packets containing summaries of such information and use that to adjust its playout buffer. The SC sends RTCP XR IDMS reports to the MSAS.
SCは、メディアストリームのRTPパケット到着時間とプレゼンテーション時間について報告します。このような情報の要約を含むIDMS設定パケットを受信し、それを使用して再生バッファーを調整できます。 SCはRTCP XR IDMSレポートをMSASに送信します。
Two different message types are used for the communication between MSAS and SCs. For the SC->MSAS message containing the arrival and playout information of a particular client, an RTCP XR IDMS Report Block is used (see Section 6). For the MSAS->SC message containing the synchronization settings instructions, a new RTCP IDMS Settings Packet is defined (see Section 7).
MSASとSC間の通信には、2つの異なるメッセージタイプが使用されます。特定のクライアントの到着およびプレイアウト情報を含むSC-> MSASメッセージの場合、RTCP XR IDMSレポートブロックが使用されます（セクション6を参照）。同期設定の手順を含むMSAS-> SCメッセージの場合、新しいRTCP IDMS設定パケットが定義されます（セクション7を参照）。
This section specifies a new RTCP XR Block Type, the RTCP XR IDMS Report Block, for reporting IDMS information to an MSAS. In particular, it is used to provide feedback information on arrival times and presentation times of RTP packets. Its definition is based on [RFC3550] and [RFC3611].
このセクションでは、IDAS情報をMSASに報告するための新しいRTCP XRブロックタイプであるRTCP XR IDMSレポートブロックを指定します。特に、RTPパケットの到着時間とプレゼンテーション時間に関するフィードバック情報を提供するために使用されます。その定義は[RFC3550]と[RFC3611]に基づいています。
In most cases, a single RTP receiver will only be part of a single IDMS session, i.e., it will report on arrival and presentation times of RTP packets from a single RTP stream in a certain synchronization group. In some cases, however, an RTP receiver may be a member of multiple synchronization groups for the same RTP stream, e.g., watching a single television program simultaneously with different groups. In even further cases, a receiver may wish to synchronize different RTP streams at the same time, either as part of the same synchronization group or as part of multiple synchronization groups. These are all valid scenarios for IDMS and will require multiple reports by an SC.
ほとんどの場合、単一のRTPレシーバーは単一のIDMSセッションの一部のみになります。つまり、特定の同期グループ内の単一のRTPストリームからのRTPパケットの到着時間と表示時間についてレポートします。ただし、場合によっては、RTP受信機は、同じRTPストリームの複数の同期グループのメンバーである場合があります。たとえば、異なるグループと同時に単一のテレビ番組を視聴している場合があります。さらに別の場合では、受信機は、同じ同期グループの一部として、または複数の同期グループの一部として、異なるRTPストリームを同時に同期することを望む場合がある。これらはすべてIDMSの有効なシナリオであり、SCによる複数のレポートが必要になります。
This document does not define new rules for when to send RTCP reports, but uses the existing rules specified in [RFC3550] for sending RTCP reports. When the RTCP reporting timer allows an SC to send an IDMS report, the SC SHOULD report on an RTP packet received during the period since the last RTCP XR IDMS Report Block was sent. Because of RTP timestamp rollover, there is ambiguity in mapping RTP timestamps to NTP timestamps. The recommendation to report on recent RTP packets serves to manage this ambiguity. For more details on which packet to report on, see below under "Packet Received RTP timestamp".
このドキュメントでは、RTCPレポートを送信するタイミングに関する新しいルールを定義していませんが、[RFC3550]で指定されている既存のルールを使用してRTCPレポートを送信しています。 RTCPレポートタイマーによりSCがIDMSレポートを送信できる場合、最後のRTCP XR IDMSレポートブロックが送信されてからの期間中に受信されたRTPパケットに関するSC SHOULDレポートが必要です。 RTPタイムスタンプのロールオーバーのため、RTPタイムスタンプをNTPタイムスタンプにマッピングすることは曖昧です。最近のRTPパケットについて報告するという推奨は、このあいまいさを管理するのに役立ちます。レポートするパケットの詳細については、以下の「パケット受信RTPタイムスタンプ」を参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=12 | SPST |Resrv|P| block length=7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Resrv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTCP XR IDMS Report Block consists of 8 32-bit words, with the following fields:
RTCP XR IDMSレポートブロックは8つの32ビットワードで構成され、次のフィールドがあります。
Block Type (BT): 8 bits. It identifies the block format. Its value is set to 12.
ブロックタイプ（BT）：8ビット。ブロック形式を識別します。その値は12に設定されます。
Synchronization Packet Sender Type (SPST): 4 bits. This field identifies the role of the packet sender for this specific Extended Report. It can have the following values, as enumerated in a registry maintained by IANA (see Section 13.4):
同期パケット送信者タイプ（SPST）：4ビット。このフィールドは、この特定の拡張レポートに対するパケット送信者の役割を識別します。 IANA（セクション13.4を参照）が管理するレジストリで列挙されているように、次の値を持つことができます。
SPST=0 Reserved for future use.
SPST = 0将来の使用のために予約されています。
SPST=1 The packet sender is an SC. It uses this XR to report synchronization status information. Timestamps relate to the SC input.
SPST = 1パケット送信者はSCです。このXRを使用して、同期ステータス情報を報告します。タイムスタンプはSC入力に関連しています。
SPST=2-4 Values defined by ETSI TISPAN (see [TS183063]).
SPST = 2-4 ETSI TISPANによって定義された値（[TS183063]を参照）。
SPST=5-15 Unassigned.
SPST = 5-15未割り当て。
Reserved bits (Resrv): 3 bits. These bits are reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero at transmission and MUST be ignored by the receiver.
予約ビット（Resrv）：3ビット。これらのビットは将来の定義のために予約されています。そのような定義がない場合、このフィールドのビットは送信時にゼロに設定されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。
Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the Packet Presented NTP timestamp field contains a value, 0 if it is empty. If this flag is set to 0, then the Packet Presented NTP timestamp SHALL be ignored by the receiver.
パケット提示NTPタイムスタンプフラグ（P）：1ビット。 Packet Presented NTPタイムスタンプフィールドに値が含まれている場合はビットが1に設定され、空の場合は0に設定されます。このフラグが0に設定されている場合、パケット提示NTPタイムスタンプは受信者によって無視される必要があります。
Block Length: 16 bits. This field indicates the length of the block in 32-bit words minus one and is set to 7, as this RTCP XR IDMS Block Report has a fixed length.
ブロック長：16ビット。このRTCP XR IDMSブロックレポートは固定長であるため、このフィールドは32ビットワードから1を引いたブロックの長さを示し、7に設定されます。
Payload Type (PT): 7 bits. This field identifies the format of the media payload, according to [RFC3551]. This is the payload type of the RTP packet reported upon. The PT field is needed in the case where the MSAS is neither the media server nor a receiver of the media stream, i.e., it is implemented as a third-party entity. In such cases, the MSAS needs the PT to determine the rate of advancement of the timestamps of the RTP media stream to be able to relate reports from different SCs on different RTP timestamp values.
ペイロードタイプ（PT）：7ビット。このフィールドは、[RFC3551]に従って、メディアペイロードのフォーマットを識別します。これは、報告されたRTPパケットのペイロードタイプです。 PTフィールドは、MSASがメディアサーバーでもメディアストリームの受信者でもない場合、つまり、サードパーティエンティティとして実装されている場合に必要です。このような場合、MSASは、RTPメディアストリームのタイムスタンプの進行速度を決定して、異なるSCからのレポートを異なるRTPタイムスタンプ値に関連付けることができるように、PTを必要とします。
Reserved bits (Resrv): 25 bits. These bits are reserved for future use and SHALL be set to 0 at transmission and MUST be ignored by the receiver.
予約ビット（Resrv）：25ビット。これらのビットは将来の使用のために予約されており、送信時に0に設定する必要があり、受信者はこれを無視する必要があります。
Media Stream Correlation Identifier: 32 bits. This identifier is used to correlate synchronized media streams. The value 0 (all bits are set "0") indicates that this field is empty. The value 2^32-1 (all bits are set "1") is reserved for future use. If the RTCP Packet Sender is an SC (SPST=1), then the Media Stream Correlation Identifier field contains the Synchronization Group Identifier (SyncGroupId) to which the report applies.
メディアストリーム相関識別子：32ビット。この識別子は、同期されたメディアストリームを関連付けるために使用されます。値0（すべてのビットは "0"に設定）は、このフィールドが空であることを示します。値2 ^ 32-1（すべてのビットは "1"に設定されています）は、将来の使用のために予約されています。 RTCPパケット送信者がSC（SPST = 1）の場合、[メディアストリーム相関識別子]フィールドには、レポートが適用される同期グループ識別子（SyncGroupId）が含まれます。
Synchronization Source (SSRC): 32 bits. The SSRC of the media source is set to the value of the SSRC identifier carried in the RTP header [RFC3550] of the RTP packet to which the XR IDMS relates.
同期ソース（SSRC）：32ビット。メディアソースのSSRCは、XR IDMSが関連するRTPパケットのRTPヘッダー[RFC3550]で伝送されるSSRC識別子の値に設定されます。
Packet Received NTP timestamp: 64 bits. This timestamp reflects the wallclock time at the moment of arrival of the first octet of the RTP packet to which the XR IDMS relates. It is formatted based on the NTP timestamp format as specified in [RFC5905]. See Section 8 for more information on how this field is used.
パケット受信NTPタイムスタンプ：64ビット。このタイムスタンプは、XR IDMSが関連するRTPパケットの最初のオクテットが到着した瞬間のウォールクロック時間を反映しています。 [RFC5905]で指定されているNTPタイムスタンプ形式に基づいてフォーマットされます。このフィールドの使用方法の詳細については、セクション8を参照してください。
Packet Received RTP timestamp: 32 bits. This timestamp has the value of the RTP timestamp carried in the RTP header [RFC3550] of the RTP packet to which the XR IDMS relates. Several consecutive RTP packets will have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. It may well be the case that one receiver reports on the first RTP packet that has a certain RTP timestamp, and a second receiver reports on the last RTP packet that has that same RTP timestamp. This would lead to an error in the synchronization algorithm due to the faulty interpretation of considering both reports to be on the same RTP packet. When reporting on an RTP packet, which is one of several consecutive RTP packets having equal timestamps, an SC SHOULD report on the RTP packet it received with the lowest sequence number. Note that 'lowest sequence number' here is meant to be the first in the sequence of RTP packets just received, not from an earlier time before the last wrap around of RTP timestamps (unless this wrap around occurs during the sequence with equal RTP timestamps).
パケット受信RTPタイムスタンプ：32ビット。このタイムスタンプは、XR IDMSが関連するRTPパケットのRTPヘッダー[RFC3550]で伝送されるRTPタイムスタンプの値を持っています。いくつかの連続したRTPパケットは、それらが（論理的に）一度に生成される場合、たとえば同じビデオフレームに属する場合、タイムスタンプが等しくなります。 1つの受信者が特定のRTPタイムスタンプを持つ最初のRTPパケットについて報告し、2番目の受信者が同じRTPタイムスタンプを持つ最後のRTPパケットについて報告する場合がよくあります。これにより、両方のレポートが同じRTPパケット上にあると見なすという誤った解釈が原因で、同期アルゴリズムでエラーが発生します。同じタイムスタンプを持ついくつかの連続したRTPパケットの1つであるRTPパケットについて報告するとき、SCは、最小のシーケンス番号で受信したRTPパケットについて報告する必要があります（SHOULD）。ここでの「最小シーケンス番号」は、RTPタイムスタンプの最後のラップアラウンドの前の早い時点からではなく、RTPパケットのシーケンスの最初のものであることを意味することに注意してください（このラップアラウンドが同じRTPタイムスタンプのシーケンス中に発生しない限り） 。
Packet Presented NTP timestamp: 32 bits. This timestamp reflects the wallclock time at the moment the rendered media unit (e.g., video frame or audio sample) contained in the first byte of the associated RTP packet is presented to the user. It is based on the time format used by NTP and consists of the least significant 16 bits of the NTP seconds part and the most significant 16 bits of the NTP fractional second part. If no Packet Presented NTP timestamp is available, this field SHALL be set to 0 and be considered empty, and the Packet Presented NTP timestamp flag (P) SHALL be set to 0. With regards to NTP epoch and rollover, the value of the Packet Presented NTP timestamp is considered to always be greater than the Packet Received NTP timestamp and to be within 2^16 seconds of it. Presented in this context means the moment the data is played out to the user of the system, i.e., sound played out through speakers, video images being displayed on some display, etc. The accuracy resulting from the synchronization algorithm will only be as good as the accuracy with which the SCs can determine the delay between receiving packets and presenting them to the end user. If no presentation timestamps are reported by SCs, the ability to accurately synchronize playout may be limited.
パケット提示NTPタイムスタンプ：32ビット。このタイムスタンプは、関連付けられたRTPパケットの最初のバイトに含まれるレンダリングされたメディアユニット（ビデオフレームやオーディオサンプルなど）がユーザーに提示された瞬間の壁時計時間を反映しています。これは、NTPで使用される時間形式に基づいており、NTP秒部分の最下位16ビットと、NTP小数秒部分の最上位16ビットで構成されています。 Packet Presented NTPタイムスタンプが利用できない場合、このフィールドは0に設定されて空と見なされ（SHALL）、Packet Presented NTPタイムスタンプフラグ（P）は0に設定される必要があります。NTPエポックとロールオーバーに関して、パケットの値提示されたNTPタイムスタンプは、常にパケット受信NTPタイムスタンプより大きく、その2 ^ 16秒以内であると見なされます。このコンテキストで表示されるとは、システムのユーザーにデータが再生される瞬間、つまり、スピーカーから再生される音、一部のディスプレイに表示されるビデオ画像などを意味します。同期アルゴリズムによる精度は、 SCがパケットを受信してエンドユーザーに提示するまでの遅延を決定できる精度。 SCによってプレゼンテーションのタイムスタンプが報告されない場合、再生を正確に同期する機能が制限される可能性があります。
This section specifies the RTCP packet type for indicating synchronization settings instructions to the receivers of the RTP media stream. Its definition is based on [RFC3550]. Synchronization settings take the form of a report referencing a real or hypothetical RTP packet selected or contrived by the MSAS.
このセクションでは、RTPメディアストリームの受信者に同期設定の指示を示すためのRTCPパケットタイプを指定します。その定義は[RFC3550]に基づいています。同期設定は、MSASによって選択または作成された実際または仮想のRTPパケットを参照するレポートの形式を取ります。
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| Resrv | PT=211 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 64 bits form the header of the RTCP packet type, as defined in [RFC3550]. The SSRC of the packet sender identifies the sender of the specific RTCP packet.
[RFC3550]で定義されているように、最初の64ビットはRTCPパケットタイプのヘッダーを形成します。パケット送信者のSSRCは、特定のRTCPパケットの送信者を識別します。
The RTCP IDMS Settings Packet consists of 7 32-bit words, with the following fields:
RTCP IDMS設定パケットは7つの32ビットワードで構成され、次のフィールドがあります。
PT: 211, as registered by IANA.
PT：211、IANAによる登録。
SSRC: 32 bits. The SSRC of the media source is set to the value of the SSRC identifier of the media source carried in the RTP header [RFC3550] of the RTP packet to which the RTCP IDMS Settings Packet relates.
SSRC：32ビット。メディアソースのSSRCは、RTCP IDMS設定パケットが関連するRTPパケットのRTPヘッダー[RFC3550]で伝送されるメディアソースのSSRC識別子の値に設定されます。
Media Stream Correlation Identifier: 32 bits. This identifier is used to correlate synchronized media streams. The value 0 (all bits are set "0") indicates that this field is empty. The value 2^32-1 (all bits are set "1") is reserved for future use. The Media Stream Correlation Identifier contains the SyncGroupId of the group to which this packet is sent.
メディアストリーム相関識別子：32ビット。この識別子は、同期されたメディアストリームを関連付けるために使用されます。値0（すべてのビットは "0"に設定）は、このフィールドが空であることを示します。値2 ^ 32-1（すべてのビットは "1"に設定されています）は、将来の使用のために予約されています。 Media Stream Correlation Identifierには、このパケットの送信先のグループのSyncGroupIdが含まれています。
Packet Received NTP timestamp: 64 bits. This timestamp reflects the wallclock time at the reference client at the moment it received the first octet of the RTP packet to which this packet relates. It can be used by the synchronization algorithm on the receiving SC to adjust its playout timing in order to achieve synchronization, e.g., to set the required playout delay. The timestamp is formatted based on the NTP timestamp format as specified in [RFC5905]. See Section 8 for more information on how this field is used. Because RTP timestamps do wrap around, the sender of this packet MUST use recent values, i.e., choose NTP timestamps that reflect current time and not too far in the future or in the past so as to create ambiguity with regards to RTP timestamp wrap around.
パケット受信NTPタイムスタンプ：64ビット。このタイムスタンプは、参照クライアントがこのパケットに関連するRTPパケットの最初のオクテットを受信した瞬間の基準時刻を反映しています。これは、同期を達成するために、たとえば必要なプレイアウト遅延を設定するために、プレイアウトタイミングを調整するために受信側SCの同期アルゴリズムで使用できます。タイムスタンプは、[RFC5905]で指定されているNTPタイムスタンプ形式に基づいてフォーマットされます。このフィールドの使用方法の詳細については、セクション8を参照してください。 RTPタイムスタンプはラップアラウンドするため、このパケットの送信者は最新の値を使用する必要があります。つまり、RTPタイムスタンプのラップアラウンドに関して曖昧さを生み出すために、現在の時刻を反映し、未来または過去の遠すぎないNTPタイムスタンプを選択する必要があります。
Packet Received RTP timestamp: 32 bits. This timestamp has the value of the RTP timestamp carried in the RTP header [RFC3550] of the RTP packet to which the XR IDMS relates. This SHOULD relate to the first arriving RTP packet containing this particular RTP timestamp, in case multiple consecutive RTP packets contain the same RTP timestamp.
パケット受信RTPタイムスタンプ：32ビット。このタイムスタンプは、XR IDMSが関連するRTPパケットのRTPヘッダー[RFC3550]で伝送されるRTPタイムスタンプの値を持っています。複数の連続するRTPパケットに同じRTPタイムスタンプが含まれている場合、このSHOULDは、この特定のRTPタイムスタンプを含む最初に到着するRTPパケットに関連しています。
Packet Presented NTP timestamp: 64 bits. This timestamp reflects the wallclock time at the reference client at the moment it presented the rendered media unit (e.g., video frame or audio sample) contained in the first octet of the associated RTP packet to the user. The timestamp is formatted based on the NTP timestamp format as specified in [RFC5905]. If no Packet Presented NTP timestamp is available, this field SHALL be set to 0 and be considered empty. This field MAY be left empty if none or only one of the receivers reported on presentation timestamps. Presented here means the moment the data is played out to the user of the system.
パケット提示NTPタイムスタンプ：64ビット。このタイムスタンプは、関連するRTPパケットの最初のオクテットに含まれるレンダリングされたメディアユニット（ビデオフレームやオーディオサンプルなど）をユーザーに提示した時点の参照クライアントの実時間を反映しています。タイムスタンプは、[RFC5905]で指定されているNTPタイムスタンプ形式に基づいてフォーマットされます。 Packet Presented NTPタイムスタンプが利用できない場合、このフィールドは0に設定され、空であると見なされます。プレゼンテーションのタイムスタンプについて報告されたレシーバーがないか、または1つだけの場合、このフィールドは空のままにすることができます。ここに表示されるのは、システムのユーザーにデータが再生される瞬間です。
In some use cases (e.g., phased array transducers), the level of control an MSAS might need to have over the exact moment of playout is so precise that a 32-bit Presented timestamp will not suffice. For this reason, this RTCP packet type for IDMS includes a 64-bit Presented Timestamp field. Since an MSAS will in practice always add some extra delay to the delay reported by the most lagged receiver (to account for packet jitter), it suffices for the RTCP XR IDMS Report Block with which the SCs report on their playout to have a 32-bit Presented Timestamp field.
一部の使用例（フェーズドアレイトランスデューサーなど）では、MSASが再生の正確な瞬間に必要とする制御のレベルが非常に正確であるため、32ビットの提示タイムスタンプでは不十分です。このため、IDMSのこのRTCPパケットタイプには、64ビットの提示タイムスタンプフィールドが含まれています。 MSASは実際には常に最も遅れたレシーバーによって報告された遅延に追加の遅延を追加するため（パケットジッタを考慮するため）、SCがプレイアウトについて報告するRTCP XR IDMSレポートブロックが32であると十分です。ビット提示されたタイムスタンプフィールド。
To achieve IDMS, the different receivers involved need synchronized wallclocks as a common timeline for synchronization. This synchronized clock is used for reporting the Packet Received NTP timestamp and the Packet Presented NTP timestamp, and for interpretation of these fields in received IDMS Settings Packets. Depending on the synchronization accuracy required, different clock synchronization methods can be used. For social TV, synchronization accuracy should be achieved on the order of hundreds of milliseconds. In that case, correct use of NTP on receivers will in most situations achieve the required accuracy. As a guideline, to deal with clock drift of receivers, receivers should synchronize their clocks at the beginning of a synchronized session. In case of high required accuracy, the synchronized clocks of different receivers should not drift beyond the accuracy required for the synchronization mechanism. In practice, this can mean that receivers need to synchronize their clocks repeatedly during a synchronization session.
IDMSを実現するには、関係するさまざまなレシーバーが同期の共通タイムラインとして同期されたウォールクロックを必要とします。この同期されたクロックは、パケット受信NTPタイムスタンプとパケット提示NTPタイムスタンプのレポート、および受信したIDMS設定パケットのこれらのフィールドの解釈に使用されます。必要な同期精度に応じて、さまざまなクロック同期方法を使用できます。ソーシャルTVの場合、同期の精度は数百ミリ秒のオーダーで達成する必要があります。その場合、レシーバーでNTPを正しく使用すると、ほとんどの状況で必要な精度が得られます。ガイドラインとして、レシーバーのクロックドリフトに対処するには、レシーバーは同期されたセッションの開始時にクロックを同期する必要があります。必要な精度が高い場合、異なるレシーバーの同期クロックは、同期メカニズムに必要な精度を超えてドリフトしてはなりません。実際には、これは、受信機が同期セッション中に繰り返しクロックを同期する必要があることを意味します。
Because of the stringent synchronization requirements for achieving good audio quality in some use cases, a high accuracy will be needed. In this case, use of the global NTP system may not be sufficient. For improved accuracy, a local NTP server could be set up, or some other more accurate clock synchronization mechanism can be used, such as GPS time or the Precision Time Protocol [IEEE1588-2008].
一部のユースケースでは良好なオーディオ品質を実現するための厳しい同期要件があるため、高い精度が必要になります。この場合、グローバルNTPシステムの使用では不十分な場合があります。精度を向上させるには、ローカルNTPサーバーをセットアップするか、GPS時間や高精度時間プロトコル[IEEE1588-2008]など、より正確なクロック同期メカニズムを使用できます。
[RFC7273] defines a set of Session Description Protocol (SDP) parameters for signaling the clock synchronization source or sources available to and used by the individual receivers. SCs MAY use [RFC7273] to indicate their clock synchronization source or sources in use and available. Using these parameters, an SC can indicate which synchronization source is being used at the moment. An SC can also indicate any other synchronization sources available to it. This allows multiple SCs in an IDMS session to use the same or a similar clock source for their session.
[RFC7273]は、個々のレシーバーが利用でき、使用するクロック同期ソースに信号を送るための一連のセッション記述プロトコル（SDP）パラメーターを定義します。 SCは、[RFC7273]を使用して、クロック同期ソースまたは使用中のソースを示すことができます。これらのパラメーターを使用して、SCは現在使用されている同期ソースを示すことができます。 SCは、SCで使用可能な他の同期ソースを示すこともできます。これにより、IDMSセッション内の複数のSCがセッションに同じまたは類似のクロックソースを使用できるようになります。
Applications performing IDMS may or may not be able to choose a synchronization method for the system clock because this may be a system-wide setting that the application cannot change. How applications deal with this is up to the implementation. The application might control the system clock, or it might use a separate application clock or even a separate IDMS session clock. It might also report on the system clock and the synchronization method used, without being able to change it.
IDMSを実行するアプリケーションは、システムクロックの同期方法を選択できる場合とできない場合があります。これは、アプリケーション全体が変更できないシステム全体の設定であるためです。アプリケーションがこれをどのように処理するかは、実装次第です。アプリケーションはシステムクロックを制御する場合もあれば、個別のアプリケーションクロックまたは個別のIDMSセッションクロックを使用する場合もあります。また、変更することなく、システムクロックと使用された同期方法について報告する場合もあります。
[RFC7164] presents some guidelines on how RTP senders and receivers should deal with leap seconds. When relying on NTP for clock synchronization, IDMS is particularly sensitive to leap-second-induced timing discrepancies. It is RECOMMENDED to take the guidelines specified in [RFC7164] into account when implementing IDMS.
[RFC7164]は、RTP送信者と受信者がうるう秒を処理する方法に関するいくつかのガイドラインを示しています。 NTPを使用してクロックを同期する場合、IDMSはうるう秒に起因するタイミングの不一致に特に敏感です。 IDMSを実装するときは、[RFC7164]で指定されたガイドラインを考慮することをお勧めします。
A receiver can report on different timing events, i.e., on packet arrival times and on playout or presentation times. A receiver SHALL report on arrival times and a receiver MAY report on playout times. RTP packet arrival times are relatively easy to report on. Normally, the processing and playout of the same media stream by different receivers will take roughly the same amount of time. Synchronizing on packet arrival times may lead to some accuracy loss, but it will be adequate for many applications, such as social TV.
受信機は、さまざまなタイミングイベント、つまりパケットの到着時間と、プレイアウトまたはプレゼンテーション時間についてレポートできます。受信者は到着時間について報告する必要があり（SHALL）、受信者はプレイアウト時間について報告する場合があります（MAY）。 RTPパケットの到着時間は比較的簡単に報告できます。通常、異なるメディアによる同じメディアストリームの処理と再生には、ほぼ同じ時間がかかります。パケットの到着時刻で同期すると、精度がいくらか失われる可能性がありますが、ソーシャルTVなどの多くのアプリケーションに適しています。
Also, if the receivers are in some way controlled, e.g., having the same buffer settings and decoding and rendering times, high accuracy can be achieved. However, if all receivers in a synchronization session have the ability to report on and, thus, synchronize on actual presentation times, this will be more accurate. It is up to the applications and implementations of this RTCP extension whether to implement and use presentation timestamps.
また、レシーバが何らかの方法で制御されている場合、たとえば、同じバッファ設定とデコード時間とレンダリング時間を持っている場合は、高い精度を実現できます。ただし、同期セッションのすべてのレシーバーがレポートを作成できるため、実際のプレゼンテーション時間で同期できる場合、これはより正確になります。プレゼンテーションのタイムスタンプを実装して使用するかどうかは、このRTCP拡張のアプリケーションと実装次第です。
The SDP attribute rtcp-idms is used to signal the use of the RTCP IDMS Settings Packet and the associated RTCP XR IDMS Report Block. It is also used to carry an identifier of the synchronization group to which clients belong or will belong. The SDP attribute is used as a media-level attribute during session setup. This means that in case of multiple related streams, IDMS is performed on one of them. The other streams will be synchronized to this reference or master stream using existing inter-stream synchronization (such as lip-sync) solutions, i.e., using sender reports based on a common clock source. Basic guidelines for choosing the media stream for IDMS is to choose audio above video, as humans are most sensitive to degradation in audio synchronization. When using multi-description or multi-view codecs, the IDMS control should be performed on the base layer.
SDP属性rtcp-idmsは、RTCP IDMS設定パケットおよび関連するRTCP XR IDMSレポートブロックの使用を通知するために使用されます。また、クライアントが属している、または属する予定の同期グループの識別子を運ぶためにも使用されます。 SDP属性は、セッションのセットアップ中にメディアレベルの属性として使用されます。つまり、関連するストリームが複数ある場合は、そのうちの1つでIDMSが実行されます。他のストリームは、既存のストリーム間同期（リップシンクなど）ソリューションを使用して、つまり、共通のクロックソースに基づく送信者レポートを使用して、この参照またはマスターストリームに同期されます。人間はオーディオ同期の劣化に最も敏感であるため、IDMSのメディアストリームを選択するための基本的なガイドラインは、ビデオよりもオーディオを選択することです。マルチディスクリプションまたはマルチビューコーデックを使用する場合、IDMSコントロールはベースレイヤーで実行する必要があります。
This SDP attribute is defined as follows, using Augmented Backus-Naur Form [RFC5234].
このSDP属性は、拡張バッカスナウアフォーム[RFC5234]を使用して、次のように定義されます。
rtcp-idms = "a=" "rtcp-idms" ":" sync-grp CRLF
sync-grp = "sync-group=" SyncGroupId
sync-grp = "sync-group =" SyncGroupId
SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294
DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer and represented in decimal. SyncGroupId identifies a group of SCs for IDMS. The value SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295 (2^32-1) is reserved for future use. For a description on the value of SyncGroupId to include, see Section 11.
SyncGroupIdは32ビットの符号なし整数で、10進数で表されます。 SyncGroupIdは、IDMSのSCのグループを識別します。値SyncGroupId = 0は空のSyncGroupIdを表します。値4294967295（2 ^ 32-1）は、将来の使用のために予約されています。含めるSyncGroupIdの値については、セクション11を参照してください。
The following is an example of the SDP attribute for IDMS.
IDMSのSDP属性の例を次に示します。
a=rtcp-idms:sync-group=42
The SDP usage for IDMS follows the rules defined in [RFC4566] and Section 5 of [RFC3611] on SDP signaling with the exception of what is stated here. The IDMS usage of RTCP is a loosely coupled collaborative attribute, in the sense that receivers send their status information and, in response, the MSAS asynchronously sends synchronization setting instructions. The rtcp-idms attribute, thus, indicates the ability to send and receive indicated RTCP messages. This section defines how this SDP attribute should be used with regard to an offer/answer context.
IDMSのSDPの使用法は、ここに記載されているものを除き、SDPシグナリングに関する[RFC4566]および[RFC3611]のセクション5で定義されたルールに従います。 RTCPのIDMSの使用法は、受信機がステータス情報を送信し、それに応答してMSASが非同期で同期設定命令を送信するという意味で、疎結合の協調属性です。したがって、rtcp-idms属性は、示されたRTCPメッセージを送受信する機能を示します。このセクションでは、オファー/アンサーコンテキストに関してこのSDP属性を使用する方法を定義します。
It is expected that, in most cases, the rtcp-idms attribute will be used in an offer/answer context where receivers will have predetermined, through some means outside the scope of this document, a SyncGroupId before the media session is set up. However, A sender that assigns a SyncGroupId is also supported for cases, for example, where the MSAS contains group management functionality and is co-located with or otherwise communicates with the sender. Thus, both senders and receivers can insert the attribute and the SyncGroupId. Furthermore, the attribute is allowed to be inserted for more than one media stream, allowing an SC to become part of multiple synchronization groups simultaneously. This effectively couples two (or more) synchronization groups to each other. If the rtcp-idms attribute is inserted more than once for a particular media session, each SyncGroupId SHALL only be inserted once.
ほとんどの場合、rtcp-idms属性は、メディアセッションが設定される前に、このドキュメントの範囲外の何らかの手段でSyncGroupIdを受信者が事前に決定するオファー/アンサーコンテキストで使用されることが予想されます。ただし、SyncGroupIdを割り当てる送信者は、MSASにグループ管理機能が含まれ、送信者と同じ場所に配置されているか、送信者と通信する場合などにもサポートされます。したがって、送信者と受信者の両方が属性とSyncGroupIdを挿入できます。さらに、この属性は複数のメディアストリームに挿入できるため、SCを同時に複数の同期グループの一部にすることができます。これにより、2つ（またはそれ以上）の同期グループが互いに効果的に結合されます。特定のメディアセッションでrtcp-idms属性が複数回挿入される場合、各SyncGroupIdは1回だけ挿入される必要があります。
In order to join an IDMS session, the receiver (the SC) inserts the rtcp-idms attribute as a media-level attribute in the SDP offer. This SDP offer can be an initial offer if the media session is starting as a synchronized session. The SDP offer can also be an update to an existing media session, converting the session to an IDMS session. If the receiver has a predetermined SyncGroupId value, it SHOULD use this value for setting the SyncGroupId parameter in the rtcp-idms attribute. If the receiver does not know the SyncGroupId to be used, it MAY leave the SyncGroupId parameter empty by setting its value to 0.
IDMSセッションに参加するために、レシーバー（SC）は、rtcp-idms属性をメディアレベル属性としてSDPオファーに挿入します。メディアセッションが同期セッションとして開始されている場合、このSDPオファーは最初のオファーになる可能性があります。 SDPオファーは、既存のメディアセッションを更新して、セッションをIDMSセッションに変換することもできます。レシーバーに事前に定義されたSyncGroupId値がある場合は、rtcp-idms属性のSyncGroupIdパラメーターを設定するためにこの値を使用する必要があります（SHOULD）。使用するSyncGroupIdがレシーバーでわからない場合は、値を0に設定してSyncGroupIdパラメーターを空のままにすることができます。
The sender SHALL include the rtcp-idms attribute in its answer. If the value of the SyncGroupId parameter in the offer is not empty (not equal to 0), the sender SHOULD NOT change the SyncGroupId in its answer. If the SyncGroupId is empty, the sender SHALL include the proper SyncGroupId in its answer. If the sender receives an offer with the value of the SyncGroupId parameter set to 0, and cannot determine the proper SyncGroupId, it SHALL remove the attribute from its answer.
送信者は、応答にrtcp-idms属性を含める必要があります（SHALL）。オファーのSyncGroupIdパラメータの値が空ではない（0と等しくない）場合、送信者はその回答のSyncGroupIdを変更してはなりません（SHOULD NOT）。 SyncGroupIdが空の場合、送信者は応答に適切なSyncGroupIdを含める必要があります。送信者がSyncGroupIdパラメータの値が0に設定されたオファーを受信し、適切なSyncGroupIdを決定できない場合、その回答から属性を削除する必要があります（SHALL）。
A sender receiving an SDP offer without the rtcp-idms attribute can also decide that IDMS is applicable to that media session. In such a case, the sender MAY insert the rtcp-idms attribute, including a non-empty SyncGroupId, as part of its answer.
rtcp-idms属性なしでSDPオファーを受信する送信者も、IDMSがそのメディアセッションに適用可能であると判断できます。そのような場合、送信者は、空ではないSyncGroupIdを含むrtcp-idms属性を、その回答の一部として挿入してもよい（MAY）。
A receiver receiving an rtcp-idms attribute as part of the SDP answer from a sender SHALL start sending RTCP XR IDMS reports (following all the normal RTCP rules for sending RTCP XR IDMS Report Blocks) and SHALL be ready to start receiving IDMS Settings. As usual, if a receiver does not support the attribute (e.g., in case of an MSAS-inserted IDMS attribute), it SHALL ignore the attribute.
送信者からのSDP応答の一部としてrtcp-idms属性を受信する受信者は、RTCP XR IDMSレポートの送信を開始し（RTCP XR IDMSレポートブロックを送信するためのすべての通常のRTCPルールに従って）、IDMS設定の受信を開始する準備ができている必要があります。いつものように、レシーバーが属性をサポートしない場合（たとえば、MSASが挿入したIDMS属性の場合）、属性を無視する必要があります（SHALL）。
Different updates are applicable to such an IDMS session. Updates can be sent omitting the rtcp-idms attribute, thereby ending involvement in the synchronization session. Updates can also be sent including the rtcp-idms attribute, but with a different SyncGroupId. This indicates a switch in the synchronization group.
このようなIDMSセッションには、さまざまな更新が適用されます。 rtcp-idms属性を省略して更新を送信できるため、同期セッションへの関与を終了できます。 rtcp-idms属性を含む更新を送信することもできますが、SyncGroupIdは異なります。これは、同期グループ内のスイッチを示します。
In certain situations, there is no offer/answer context, but only a declarative modus. In this case, the MSAS just inserts the rtcp-idms attribute and a valid SyncGroupId. Any receiver receiving the rtcp-idms attribute in such a declarative case SHALL start sending RTCP XR IDMS Report Blocks and SHALL be ready to start receiving RTCP IDMS Settings Packets.
特定の状況では、オファー/アンサーコンテキストはなく、宣言的な方法のみがあります。この場合、MSASはrtcp-idms属性と有効なSyncGroupIdを挿入するだけです。このような宣言的なケースでrtcp-idms属性を受信する受信者はすべて、RTCP XR IDMSレポートブロックの送信を開始し、RTCP IDMS設定パケットの受信を開始する準備ができている必要があります。
The security considerations described in [RFC3611] apply to this document as well.
[RFC3611]で説明されているセキュリティの考慮事項は、このドキュメントにも適用されます。
The RTCP XR IDMS Report Block defined in this document is used to collect, summarize, and distribute information on packet reception and playout times of streaming media. The information may be used to orchestrate the media playout at multiple devices.
このドキュメントで定義されているRTCP XR IDMSレポートブロックは、ストリーミングメディアのパケット受信および再生時間に関する情報を収集、要約、および配信するために使用されます。この情報を使用して、複数のデバイスでメディアプレイアウトを調整できます。
Errors in the information, either accidental or malicious, may lead to undesired behavior. For example, if one device erroneously or maliciously reports a two-hour delayed playout, then another device in the same synchronization group could decide to delay its playout by two hours as well, in order to keep its playout synchronized. A user would likely interpret this two-hour delay as a malfunctioning service.
偶発的または悪意のある情報のエラーは、望ましくない動作につながる可能性があります。たとえば、あるデバイスが誤ってまたは悪意を持って2時間の遅延再生を報告した場合、同じ同期グループ内の別のデバイスも、再生を同期させるために、再生を2時間遅らせることを決定できます。ユーザーは、この2時間の遅延をサービスの誤動作と解釈する可能性があります。
Therefore, the application logic of both SCs and MSASs should check for out-of-bound information. Differences in playout time exceeding configured limits (e.g., more than ten seconds) could be an indication of such out-of-bound information.
したがって、SCとMSASの両方のアプリケーションロジックは、範囲外の情報をチェックする必要があります。構成された制限（たとえば、10秒を超える）を超えるプレイアウト時間の差は、そのような範囲外の情報を示している可能性があります。
Apart from checking for out-of-bound information in the endpoints, an IDMS implementation can reduce its vulnerability to attacks by including source authentication and message integrity measures, reducing the potential for man-in-the-middle attacks. [RFC7201] provides an overview of the security options in RTP environments and includes a set of recommendations for message integrity and source authentication that are applicable to IDMS. In addition to preventing man-in-the-middle attacks from inserting erroneous IDMS reports, the message confidentiality mechanisms outlined in [RFC7201] also prevent third parties from determining that two or more end hosts are receiving the same stream by looking at the Media Stream Correlation Identifier.
エンドポイントでの範囲外の情報のチェックとは別に、IDMSの実装では、ソース認証とメッセージの整合性対策を含めることで、攻撃に対する脆弱性を減らし、中間者攻撃の可能性を減らすことができます。 [RFC7201]は、RTP環境のセキュリティオプションの概要を提供し、IDMSに適用可能なメッセージの整合性とソース認証に関する一連の推奨事項を含みます。中間者攻撃による誤ったIDMSレポートの挿入を防止することに加えて、[RFC7201]で概説されているメッセージの機密性メカニズムは、メディアストリームを見て、2つ以上のエンドホストが同じストリームを受信していることを第三者が判断できないようにします。相関識別子。
Apart from attacking an IDMS session directly by sending incorrect IDMS reports, and with it introducing delays for all devices in a synchronization group, another potential vulnerability comes from the clock synchronization method used. Should an attacker succeed in adjusting an SC's wallclock, that SC will report incorrect IDMS reports. In order to prevent such clock synchronization attacks, it is recommended to use a secure time synchronization service.
不正なIDMSレポートを送信してIDMSセッションを直接攻撃することとは別に、同期グループ内のすべてのデバイスに遅延を導入することとは別に、使用されるクロック同期方法に起因する別の潜在的な脆弱性があります。攻撃者がSCの壁時計の調整に成功した場合、SCは不正なIDMSレポートを報告します。このようなクロック同期攻撃を防ぐために、安全な時刻同期サービスを使用することをお勧めします。
This document defines a new RTCP packet type, the RTCP IDMS Packet (IDMS Settings), within the existing Internet Assigned Numbers Authority (IANA) registry of RTCP Control Packet Types. This document also defines a new RTCP XR Block Type, the RTCP XR IDMS Report Block, within the existing IANA registry of RTCP Extended Reports (RTCP XR) Block Types.
このドキュメントでは、RTCP制御パケットタイプの既存のインターネット割り当て番号認証局（IANA）レジストリ内で、新しいRTCPパケットタイプであるRTCP IDMSパケット（IDMS設定）を定義します。このドキュメントでは、RTCP拡張レポート（RTCP XR）ブロックタイプの既存のIANAレジストリ内に、新しいRTCP XRブロックタイプであるRTCP XR IDMSレポートブロックも定義しています。
Further, this document defines a new SDP attribute "rtcp-idms" within the existing IANA registry of SDP Parameters, which is part of the "att-field (media level only)". Finally, this document defines a new IANA registry subordinate to the IANA RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR Block SPST Registry.
さらに、このドキュメントでは、SDPパラメータの既存のIANAレジストリ内に「att-field（メディアレベルのみ）」の一部である新しいSDP属性「rtcp-idms」を定義しています。最後に、このドキュメントでは、IANA RTCP拡張レポート（RTCP XR）ブロックタイプレジストリの下位にある新しいIANAレジストリであるIDMS XRブロックSPSTレジストリを定義しています。
This document assigns the packet type value 211 in the IANA 'RTCP Control Packet types (PT)' registry to the RTCP IDMS Packet (IDMS Settings).
このドキュメントでは、IANAの「RTCP制御パケットタイプ（PT）」レジストリのパケットタイプ値211をRTCP IDMSパケット（IDMS設定）に割り当てます。
This document updates the assignment of value 12 from the RTCP XR Block Type for reporting IDMS information as per [TS183063] to the RTCP XR IDMS Report Block defined in this document.
このドキュメントは、[TS183063]に従ってIDMS情報を報告するためのRTCP XRブロックタイプから値12の割り当てを、このドキュメントで定義されているRTCP XR IDMSレポートブロックに更新します。
The RTCP XR IDMS Report Block contains an extensible SPST value field; therefore, a new registry for this field is required. This new registry is defined in Section 13.4.
RTCP XR IDMSレポートブロックには、拡張可能なSPST値フィールドが含まれています。したがって、このフィールドの新しいレジストリが必要です。この新しいレジストリは、セクション13.4で定義されています。
The SDP attribute "rtcp-idms" defined by this document is registered with the IANA registry of SDP Parameters as follows:
このドキュメントで定義されているSDP属性「rtcp-idms」は、次のようにSDPパラメータのIANAレジストリに登録されています。
SDP Attribute ("att-field"):
SDP属性（ "att-field"）：
Attribute name: rtcp-idms
属性名：rtcp-idms
Long form: RTCP IDMS Parameters
長い形式：RTCP IDMSパラメータ
Type of name: att-field
名前のタイプ：att-field
Type of attribute: media level
属性のタイプ：メディアレベル
Subject to charset: no
文字セットの対象：いいえ
Purpose: see Section 10 of this document
目的：このドキュメントのセクション10を参照
Reference: this document
参照：このドキュメント
Values: see this document
値：このドキュメントを参照
This document defines a new IANA registry subordinate to the IANA RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR Block SPST Registry.
このドキュメントでは、IANA RTCP拡張レポート（RTCP XR）ブロックタイプレジストリの下位にある新しいIANAレジストリであるIDMS XRブロックSPSTレジストリを定義しています。
Initial values for the IDMS XR Block SPST Registry are given below; future assignments are to be made through the Specification Required policy [RFC5226]. The registry is limited to 16 entries (numbered 0-15), with 0 being Reserved. Values 5-15 are available for assignment.
IDMS XRブロックSPSTレジストリの初期値を以下に示します。将来の割り当ては、Specification Requiredポリシー[RFC5226]を通じて行われます。レジストリは16エントリ（0〜15の番号）に制限されており、0が予約されています。割り当てには5〜15の値を使用できます。
In accordance with [RFC5226], a Designated Expert will review any applications made to IANA for the registry. Primary criteria for the Designated Expert to use when reviewing new applications are clarity of the specification and, due to the relatively small value range of SPST values available, potential overlap in functionality with existing SPST registrations.
[RFC5226]に従い、指定専門家は、IANAに対して行われたレジストリの申請をレビューします。指定された専門家が新しいアプリケーションをレビューするときに使用する主要な基準は、仕様の明確さと、利用可能なSPST値の値の範囲が比較的小さいため、既存のSPST登録と機能が重複する可能性があることです。
Value Name Reference
----- ---- ---------
1 Synchronization Client This document, Section 7
2 MSAS [TS183063]
3 SC Prime Input [TS183063]
4 SC Prime Output [TS183063]
The contact information for the registrations is:
登録の連絡先情報は次のとおりです。
Ray van Brandenburg (ray.vanbrandenburg@tno.nl) Brassersplein 2 2612CT, Delft, The Netherlands
Ray van Brandenburg（ray.vanbrandenburg@tno.nl）Brassersplein 2 2612CT、デルフト、オランダ
The following people have provided substantial contributions to this document: Omar Niamut, Fabian Walraven, Ishan Vaishnavi, and Rufael Mekuria. In addition, the authors would like to thank Aidan Williams, Colin Perkins, Magnus Westerlund, Roni Even, Peter Musgrave, Ali Begen, Qin Wu, and Rob Koenen for their review comments and contributions to the text.
次の人々は、このドキュメントに多大な貢献をしてくれました：Omar Niamut、Fabian Walraven、Ishan Vaishnavi、およびRufael Mekuria。さらに、著者は、レビューへのコメントと本文への貢献に対して、Aidan Williams、Colin Perkins、Magnus Westerlund、Roni Even、Peter Musgrave、Ali Begen、Qin Wu、およびRob Koenenに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T。、カセレス、R。、およびA.クラーク、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, June 2014.
[RFC7273]ウィリアムズ、A。、グロス、K。、ファンブランデンブルク、R。、およびH.ストキング、「RTPクロックソースシグナリング」、RFC 7273、2014年6月。
[Boronat2009] Boronat, F., Lloret, J., and M. Garcia, "Multimedia group and inter-stream synchronization techniques: a comparative study", Elsevier Information Systems 34, Pages 108-131, March 2009, <http://www.sciencedirect.com/science/article/pii/ S0306437908000525>.
[Boronat2009] Boronat、F.、Lloret、J。、およびM. Garcia、「マルチメディアグループとストリーム間同期技術：比較研究」、Elsevier Information Systems 34、ページ108-131、2009年3月、<http：/ /www.sciencedirect.com/science/article/pii/ S0306437908000525>。
[IEEE1588-2008] IEEE, "1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", July 2008, <http://standards.ieee.org/findstds/ standard/1588-2008.html>.
[IEEE1588-2008] IEEE、「1588-2008-ネットワーク化された測定および制御システム用の高精度クロック同期プロトコルのIEEE標準」、2008年7月、<http://standards.ieee.org/findstds/ standard / 1588-2008。 html>。
[Ishibashi2006] Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective assessment of fairness among users in multipoint communications", Proceedings of the 2006 ACM SIGCHI international conference on Advances in computer entertainment technology, Article No. 69, June 2006, <http://dl.acm.org/citation.cfm?id=1178905>.
[Ishibashi2006]石橋由紀子、長坂雅人、藤吉直人、「マルチポイント通信におけるユーザー間の公平性の主観的評価」、2006年ACM SIGCHI国際コンピュータエンターテインメント技術の進歩に関する会議、第69条2006年6月、<http://dl.acm.org/citation.cfm?id=1178905>。
[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, March 2014.
[RFC7164] Gross、K。およびR. Brandenburg、「RTP and Leap Seconds」、RFC 7164、2014年3月。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, April 2014.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、2014年4月。
[TS183063] ETSI, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification", TS 183 063 v3.5.2, March 2011.
[TS183063] ETSI、「高度なネットワーキング（TISPAN）向けの通信およびインターネット統合サービスおよびプロトコル。IMSベースのIPTVステージ3仕様」、TS 183 063 v3.5.2、2011年3月。
Authors' Addresses
著者のアドレス
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 EMail: ray.vanbrandenburg@tno.nl
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CTオランダ電話：+ 31-88-866-7000メール：ray.vanbrandenburg@tno.nl
Hans Stokking TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 EMail: hans.stokking@tno.nl
Hans Stokking TNO Brassersplein 2 Delft 2612CTオランダ電話：+ 31-88-866-7000メール：hans.stokking@tno.nl
M. Oskar van Deventer TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 EMail: oskar.vandeventer@tno.nl
M.オスカーファンデーフェンターTNOブラッサースプレイン2デルフト2612CTオランダ電話：+ 31-88-866-7000電子メール：oskar.vandeventer@tno.nl
Fernando Boronat Universitat Politecnica de Valencia (UPV) Valencia 46730 Spain Phone: +34 962 849 341 EMail: fboronat@dcom.upv.es
フェルナンドボロナト大学バレンシア工科大学（UPV）バレンシア46730スペイン電話：+34 962 849 341メール：fboronat@dcom.upv.es
Mario Montagud Universitat Politecnica de Valencia (UPV) Valencia 46730 Spain Phone: +34 962 849 341 EMail: mamontor@posgrado.upv.es
マリオモンタグユニバーシタットポリテクニカデバレンシア（UPV）バレンシア46730スペイン電話：+34 962 849 341メール：mamontor@posgrado.upv.es
Kevin Gross AVA Networks Phone: +1-303-447-0517 EMail: Kevin.Gross@AVAnw.com
Kevin Gross AVA Networks電話：+ 1-303-447-0517メール：Kevin.Gross@AVAnw.com