[要約] RFC 7273は、RTPクロックソースのシグナリングに関する標準化されたプロトコル仕様です。その目的は、RTPセッション内でのクロックソースの同期を向上させることです。
Internet Engineering Task Force (IETF) A. Williams
Request for Comments: 7273 Audinate
Category: Standards Track K. Gross
ISSN: 2070-1721 AVA Networks
R. van Brandenburg
H. Stokking
TNO
June 2014
RTP Clock Source Signalling
RTPクロックソースシグナリング
Abstract
概要
NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies Session Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.
NTP形式のタイムスタンプは、いくつかのRTPプロトコルで同期と統計測定のために使用されます。このメモは、タイムスタンプ基準クロックソースを識別するセッション記述プロトコル（SDP）シグナリングと、マルチメディアセッションのメディアクロックソースを識別するSDPシグナリングを指定します。
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/rfc7273.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7273で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5
4.1. Clock Synchronisation . . . . . . . . . . . . . . . . . . 5
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . 6
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . 6
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 8
4.5. Private Reference Clocks . . . . . . . . . . . . . . . . 8
4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . 8
4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . 8
4.8. SDP Signalling of Timestamp Reference Clock Source . . . 9
4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12
5.1. Asynchronously Generated Media Clock . . . . . . . . . . 12
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . 15
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19
6.1.1. Indicating Support for Clock Source Signalling . . . 20
6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20
6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22
8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 23
8.3. Timestamp Reference Clock Source Parameters Registry . . 23
8.4. Media Clock Source Parameters Registry . . . . . . . . . 24
8.5. Source-Level Attributes . . . . . . . . . . . . . . . . . 25
8.5.1. Source-Level Timestamp Reference Clock Attribute . . 25
8.5.2. Source-Level Media Clock Attribute . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 27
RTP protocols use NTP format timestamps to facilitate multimedia session synchronisation and to provide estimates of round-trip time (RTT) and other statistical parameters.
RTPプロトコルはNTP形式のタイムスタンプを使用して、マルチメディアセッションの同期を容易にし、ラウンドトリップ時間（RTT）およびその他の統計パラメータの推定を提供します。
Information about media clock timing exchanged in NTP format timestamps may come from a clock that is synchronised to a global time reference, but this cannot be assumed, nor is there a standardised mechanism available to indicate that timestamps are derived from a common reference clock. Therefore, RTP implementations typically assume that NTP timestamps are taken using unsynchronised clocks and must compensate for absolute time differences and rate differences. Without a shared reference clock, RTP can time align flows from the same source at a given receiver using relative timing; however, tight synchronisation between two or more different receivers (possibly with different network paths) or between two or more senders is not possible.
NTP形式のタイムスタンプで交換されるメディアクロックタイミングに関する情報は、グローバルタイムリファレンスと同期するクロックから取得される場合がありますが、これは想定できません。また、タイムスタンプが共通のリファレンスクロックから派生していることを示す標準化されたメカニズムもありません。したがって、RTP実装は通常、NTPタイムスタンプが非同期クロックを使用して取得されることを想定しており、絶対時間差とレート差を補償する必要があります。共有基準クロックがない場合、RTPは、相対タイミングを使用して、特定のレシーバーで同じソースからのフローを時間調整できます。ただし、2つ以上の異なるレシーバー間（場合によっては異なるネットワークパスを使用）または2つ以上のセンダー間での緊密な同期は不可能です。
High performance AV systems often use a reference media clock distributed to all devices in the system. The reference media clock may be distinct from the reference clock used to provide timestamps. A reference media clock may be provided along with an audio or video signal interface, or via a dedicated clock signal (e.g., genlock [SMPTE-318M-1999] or audio word clock [AES11-2009]). If sending and receiving media clocks are known to be synchronised to a common reference clock, performance can be improved by minimising buffering and avoiding rate conversion.
高性能AVシステムは、多くの場合、システム内のすべてのデバイスに配信されるリファレンスメディアクロックを使用します。参照メディアクロックは、タイムスタンプを提供するために使用される参照クロックとは異なる場合があります。基準メディアクロックは、オーディオまたはビデオ信号インターフェースとともに、または専用クロック信号（たとえば、ゲンロック[SMPTE-318M-1999]またはオーディオワードクロック[AES11-2009]）を介して提供できます。メディアクロックの送受信が共通の基準クロックに同期していることがわかっている場合は、バッファリングを最小限に抑え、レート変換を回避することにより、パフォーマンスを向上させることができます。
This specification defines SDP signalling of timestamp reference clock sources and media reference clock sources.
この仕様は、タイムスタンプ基準クロックソースとメディア基準クロックソースのSDPシグナリングを定義しています。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Timestamp reference clock source and media clock signalling benefit applications requiring synchronised media capture or playout and low latency operation.
タイムスタンプ基準クロックソースとメディアクロックシグナリングは、同期されたメディアキャプチャまたは再生と低レイテンシ動作を必要とするアプリケーションに役立ちます。
Examples include, but are not limited to:
例には以下が含まれますが、これらに限定されません。
Social TV: "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)" [RFC7272] defines social TV as the combination of media content consumption by two or more users at different devices and locations and real-time communication between those users. An example of social TV is where two or more users are watching the same television broadcast at different devices and/or locations while communicating with each other using text, audio, and/or video. A skew in the media playout of the two or more users 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 other friends.
ソーシャルTV：「RTP制御プロトコル（RTCP）を使用した宛先間メディア同期（IDMS）」[RFC7272]は、ソーシャルTVを、異なるデバイスと場所にいる2人以上のユーザーによるメディアコンテンツの消費とリアルタイムの通信の組み合わせとして定義していますそれらのユーザー。ソーシャルTVの例は、2人以上のユーザーがテキスト、オーディオ、ビデオを使用して互いに通信しながら、異なるデバイスや場所で同じテレビ放送を視聴している場合です。 2人以上のユーザーのメディアプレイアウトのスキューは、エクスペリエンスに悪影響を与える可能性があります。ここでよく知られている使用例は、他の友人の前または後にサッカーの試合でゴールを経験している1人の友人です。
Video Walls: 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 or projector 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 50 or 60 hertz or potentially faster. If the refresh is not synchronised, the effect of multiple screens acting as one is broken.
ビデオウォール：ビデオウォールは、複数のコンピューターモニター、ビデオプロジェクター、またはテレビセットで構成されており、1つの大きな画面を形成するために、連続してタイル状に並べられているか、重なり合っています。各画面は、大きな画像の一部を再現します。いくつかの実装形態では、各スクリーンまたはプロジェクタは、ネットワークに個別に接続され、ネットワークに接続されたビデオサーバーまたはビデオスケーラーから全体的な画像のその部分を受信することができる。画面は50または60ヘルツでリフレッシュされるか、場合によってはより高速になります。更新が同期されていない場合、1つの画面として機能している複数の画面の効果が失われます。
Networked Audio: Networked loudspeakers, amplifiers, and analogue input/output (I/O) devices transmitting or receiving audio signals via RTP can be connected to various parts of a building or campus network. 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, 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 [Olsen].
ネットワークオーディオ：RTPを介してオーディオ信号を送受信するネットワークスピーカー、アンプ、アナログ入力/出力（I / O）デバイスは、建物またはキャンパスネットワークのさまざまな部分に接続できます。このような状況は、たとえば、大規模な会議室、立法会議室、教室（特に遠隔学習をサポートするもの）、およびスタジアムなどの他の大規模な環境で見られます。人間は音声遅延の違いに敏感なので、この使用例はビデオウォールの使用例よりもさらに正確である必要があります。正確なアプリケーションによっては、精度の必要性がマイクロ秒の範囲になる場合があります[Olsen]。
Sensor Arrays: Sensor arrays contain many synchronised measurement elements producing signals that are then combined to form an overall measurement. Accurate capture of the phase relationships between the various signals arriving at each element of the array is critically important for proper operation. Examples include towed or fixed sonar arrays, seismic arrays, and phased arrays used in radar applications, for instance.
センサーアレイ：センサーアレイには、信号を生成する同期された多くの測定要素が含まれており、これらを組み合わせて全体的な測定値を形成します。アレイの各要素に到達するさまざまな信号間の位相関係を正確にキャプチャすることは、適切な動作のために非常に重要です。例としては、牽引または固定ソナーアレイ、地震アレイ、レーダーアプリケーションで使用されるフェーズドアレイなどがあります。
The following definitions are used in this document:
このドキュメントでは、次の定義が使用されています。
media level: Media-level information applies to a single SDP media stream. In an SDP description, media-level information appears after each "m"-line.
メディアレベル：メディアレベルの情報は、単一のSDPメディアストリームに適用されます。 SDPの説明では、メディアレベルの情報は各「m」行の後に表示されます。
multimedia session: A set of multimedia senders and receivers as well as the data streams flowing from senders to receivers. SDP [RFC4566] describes multimedia sessions.
マルチメディアセッション：マルチメディアの送信者と受信者のセット、および送信者から受信者に流れるデータストリーム。 SDP [RFC4566]はマルチメディアセッションについて説明しています。
RTP media stream: A single stream of RTP packets identified by an RTP Synchronisation Source (SSRC).
RTPメディアストリーム：RTP同期ソース（SSRC）によって識別されるRTPパケットの単一ストリーム。
RTP sender: The device generating an associated RTP media stream.
RTP送信者：関連するRTPメディアストリームを生成するデバイス。
session level: Session-level information applies to an entire multimedia session. In an SDP description, session-level information appears before the first "m"-line.
セッションレベル：セッションレベルの情報は、マルチメディアセッション全体に適用されます。 SDP記述では、セッションレベルの情報は最初の「m」行の前に表示されます。
source level: Source-level information applies to a specific RTP media stream. "Source-Specific Media Attributes in the Session Description Protocol (SDP)" [RFC5576] defines how source-level information is included into an SDP session description.
ソースレベル：ソースレベルの情報は、特定のRTPメディアストリームに適用されます。 「セッション記述プロトコル（SDP）のソース固有のメディア属性」[RFC5576]は、ソースレベルの情報をSDPセッション記述に含める方法を定義しています。
traceable time: A clock is considered to provide traceable time if it can be proven to be synchronised to International Atomic Time (TAI). Coordinated Universal Time (UTC) is a time standard synchronised to TAI. UTC is, therefore, also considered traceable time once leap seconds have been taken into account. GPS [IS-GPS-200F] is commonly used to provide a TAI traceable time reference. Some network time synchronisation protocols (e.g., Precision Time Protocol (PTP) [IEEE1588-2008] and NTP) can explicitly indicate that the master clock is providing a traceable time reference over the network.
追跡可能時間：国際原子時（TAI）と同期していることが証明できる場合、時計は追跡可能時間を提供すると見なされます。協定世界時（UTC）は、TAIに同期された時間標準です。したがって、うるう秒が考慮されると、UTCも追跡可能な時間と見なされます。 GPS [IS-GPS-200F]は、TAI追跡可能な時間基準を提供するために一般的に使用されます。一部のネットワーク時刻同期プロトコル（Precision Time Protocol（PTP）[IEEE1588-2008]およびNTPなど）は、マスタークロックがネットワーク上で追跡可能な時刻基準を提供していることを明示的に示すことができます。
The NTP format timestamps used by RTP are taken by reading a local real-time clock at the sender or receiver. This local clock may be synchronised to another clock (time source) by some means, or it may be unsynchronised. A variety of methods are available to synchronise local clocks to a reference time source, including network time protocols (e.g., NTP [RFC5905] and PTP [IEEE1588-2008]) and radio clocks (e.g., GPS [IS-GPS-200F]).
RTPで使用されるNTP形式のタイムスタンプは、送信者または受信者でローカルのリアルタイムクロックを読み取ることによって取得されます。このローカルクロックは、なんらかの方法で別のクロック（タイムソース）と同期している場合と、同期していない場合があります。ローカルクロックを基準時間ソースに同期させるために、ネットワークタイムプロトコル（例：NTP [RFC5905]およびPTP [IEEE1588-2008]）やラジオクロック（例：GPS [IS-GPS-200F]）などのさまざまな方法が利用可能です。 。
The following sections describe and define SDP signalling, indicating whether and how the local timestamping clock in an RTP sender or receiver is synchronised to a reference clock.
次のセクションでは、RTP送信側または受信側のローカルタイムスタンプクロックが基準クロックと同期するかどうか、およびどのように同期するかを示す、SDPシグナリングについて説明および定義します。
Two or more local clocks that are sufficiently synchronised will produce timestamps for a given RTP event that can be used as if they came from the same clock. Timestamps produced in one RTP sender or receiver can be directly compared to a local clock in another RTP sender or receiver.
十分に同期された2つ以上のローカルクロックは、それらが同じクロックからのものであるかのように使用できる特定のRTPイベントのタイムスタンプを生成します。 1つのRTP送信側または受信側で生成されたタイムスタンプは、別のRTP送信側または受信側のローカルクロックと直接比較できます。
The accuracy of synchronisation required is application dependent. See "Applications" (Section 2) for a discussion of applications and their corresponding requirements. To serve as a reference clock, clocks must minimally be "syntonised" (exactly frequency matched) to one another.
必要な同期の精度はアプリケーションに依存します。アプリケーションとそれに対応する要件については、「アプリケーション」（セクション2）を参照してください。基準クロックとして機能するために、クロックは互いに最小限に「同期化」されている（正確に周波数が一致している）必要があります。
Sufficient synchronisation can typically be achieved by using a network time protocol (e.g., NTP, 802.1AS, and IEEE 1588-2008) to synchronise all devices to a single master clock.
通常、十分な同期は、ネットワークタイムプロトコル（NTP、802.1AS、IEEE 1588-2008など）を使用してすべてのデバイスを単一のマスタークロックに同期させることで実現できます。
Another approach is to use clocks providing a global time reference (e.g., GPS, Galileo, and GLONASS). This concept may be used in conjunction with network time protocols as some protocols (e.g., PTP and NTP) allow master clocks to indicate explicitly that they are providing traceable time.
別のアプローチは、グローバルな時間基準を提供するクロックを使用することです（例：GPS、Galileo、GLONASS）。一部のプロトコル（PTPやNTPなど）では、マスタークロックが追跡可能な時間を提供していることを明示的に示すことができるため、この概念をネットワーク時間プロトコルと組み合わせて使用できます。
A single NTP server is identified by a hostname (or IP address) and an optional port number. If the port number is not indicated, it is assumed to be the standard NTP port (123).
単一のNTPサーバーは、ホスト名（またはIPアドレス）とオプションのポート番号で識別されます。ポート番号が示されていない場合は、標準のNTPポート（123）であると見なされます。
Two or more NTP servers MAY be listed at the same level in the session description to indicate that all of the listed servers deliver the same reference time and may be used interchangeably. RTP senders and receivers are assured proper synchronisation regardless of which server they choose and, in support of fault tolerance, may switch servers while streaming.
2つ以上のNTPサーバーがセッションの説明で同じレベルでリストされている場合があります。これは、リストされているすべてのサーバーが同じ参照時間を提供し、互換的に使用できることを示します。 RTPの送信側と受信側は、選択したサーバーに関係なく適切な同期が保証され、フォールトトレランスをサポートするために、ストリーミング中にサーバーを切り替えることができます。
The Precision Time Protocol (PTP) as standardised in IEEE 1588 provides a shared reference clock in a network. IEEE 1588 provides sub-microsecond synchronisation between devices on a LAN and typically locks within seconds at startup. With support from Ethernet switches, IEEE 1588 protocols can achieve nanosecond timing accuracy in LANs. Network interface chips and cards supporting hardware timestamping of timing-critical protocol messages are also available.
IEEE 1588で標準化されている高精度時間プロトコル（PTP）は、ネットワークで共有基準クロックを提供します。 IEEE 1588は、LAN上のデバイス間のサブマイクロ秒の同期を提供し、通常は起動時に数秒以内にロックします。イーサネットスイッチのサポートにより、IEEE 1588プロトコルは、LANでナノ秒のタイミング精度を実現できます。タイミングが重要なプロトコルメッセージのハードウェアタイムスタンプをサポートするネットワークインターフェイスチップとカードも利用できます。
Three flavours of IEEE 1588 are in use today:
IEEE 1588の3つのフレーバーが現在使用されています。
o IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". This is also known as IEEE1588v1 or PTPv1.
o IEEE 1588-2002 [IEEE1588-2002]：オリジナルの「ネットワーク化された測定および制御システム用の高精度クロック同期プロトコルの規格」。これは、IEEE1588v1またはPTPv1とも呼ばれます。
o IEEE 1588-2008 [IEEE1588-2008]: the second version of the "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". This is a revised version of the original IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002.
o IEEE 1588-2008 [IEEE1588-2008]：「ネットワーク化された測定および制御システム用の高精度クロック同期プロトコルの標準」の2番目のバージョン。これは、元のIEEE1588-2002標準の改訂版であり、IEEE1588v2またはPTPv2としても知られています。 IEEE 1588-2008は、IEEE 1588-2002とプロトコル互換性がありません。
o IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for Time Sensitive Applications in Bridged Local Area Networks". This is a profile of IEEE 1588-2008 that is Layer 2 only and is for use in Audio/Video Bridged LANs as described in IEEE 802.1BA-2011 [IEEE802.1BA-2011].
o IEEE 802.1AS [IEEE802.1AS-2011]：「ブリッジローカルエリアネットワークにおける時間に敏感なアプリケーションのタイミングと同期」これは、IEEE 1588-2008のプロファイルであり、レイヤ2のみであり、IEEE 802.1BA-2011 [IEEE802.1BA-2011]で説明されているオーディオ/ビデオブリッジLANで使用するためのものです。
Each IEEE 1588 clock is identified by a 64-bit Extended Unique Identifier (EUI-64) called a "ClockIdentity". A slave clock using one of the IEEE 1588 family of network time protocols acquires the ClockIdentity of the grandmaster clock that is the ultimate source of timing information for the network. A boundary clock, which is itself slaved to another boundary clock, or the grandmaster passes the grandmaster ClockIdentity through to its slaves.
各IEEE 1588クロックは、「ClockIdentity」と呼ばれる64ビットの拡張一意識別子（EUI-64）によって識別されます。 IEEE 1588ファミリーのネットワークタイムプロトコルの1つを使用するスレーブクロックは、ネットワークのタイミング情報の最終的なソースであるグランドマスタークロックのClockIdentityを取得します。それ自体が別の境界クロックのスレーブとなっている境界クロック、またはグランドマスターがグランドマスターのClockIdentityをスレーブに渡します。
Several instances of the IEEE 1588 protocol may operate independently on a single network, forming distinct PTP domains, each of which may have a different grandmaster clock. As the IEEE 1588 standards have evolved, the definition of PTP domains has changed. IEEE 1588-2002 identifies protocol subdomains by a textual name, but IEEE 1588-2008 identifies protocol domains using a numeric domain number. 802.1AS is a Layer 2 profile of IEEE 1588-2008 supporting a single numeric clock domain (0).
IEEE 1588プロトコルのいくつかのインスタンスは、単一のネットワーク上で独立して動作し、それぞれが異なるグランドマスタークロックを持つ別個のPTPドメインを形成する場合があります。 IEEE 1588標準が進化するにつれて、PTPドメインの定義が変更されました。 IEEE 1588-2002はプロトコルのサブドメインをテキスト名で識別しますが、IEEE 1588-2008は数値のドメイン番号を使用してプロトコルドメインを識別します。 802.1ASは、単一の数値クロックドメイン（0）をサポートするIEEE 1588-2008のレイヤー2プロファイルです。
When PTP domains are signalled via SDP, senders and receivers SHOULD check that both grandmaster ClockIdentity and the PTP domain match when determining clock equivalence.
PTPドメインがSDPを介して通知される場合、送信者と受信者は、クロック等価を決定するときにグランドマスターClockIdentityとPTPドメインの両方が一致することを確認する必要があります。
Two or more IEEE 1588 clocks MAY be listed at the same level in the session description to indicate that all of the listed clocks are candidate grandmaster clocks for the domain or deliver the same reference time and may be used interchangeably. RTP senders and receivers are assured proper synchronisation regardless of which synchronisation source they choose and, in support of fault tolerance, may switch the reference clock source while streaming.
2つ以上のIEEE 1588クロックがセッションの説明で同じレベルでリストされている場合があります。リストされているすべてのクロックは、ドメインのグランドマスタークロックの候補であるか、同じ参照時間を提供し、互換的に使用できます。 RTPの送信側と受信側は、選択する同期ソースに関係なく適切な同期が保証され、フォールトトレランスをサポートするために、ストリーミング中に基準クロックソースを切り替えることができます。
The PTP protocols employ a distributed election protocol called the "Best Master Clock Algorithm" (BMCA) to determine the active clock master. The clock master choices available to BMCA can be restricted or biased by configuration parameters to influence the election process. In some systems, it may be desirable to limit the number of possible PTP clock masters to avoid the need to re-signal timestamp reference clock sources when the clock master changes.
PTPプロトコルは、「ベストマスタークロックアルゴリズム」（BMCA）と呼ばれる分散選択プロトコルを使用して、アクティブなクロックマスターを決定します。 BMCAで利用できるクロックマスターの選択は、選定プロセスに影響を与えるように構成パラメーターによって制限またはバイアスすることができます。一部のシステムでは、可能なPTPクロックマスターの数を制限して、クロックマスターが変更されたときにタイムスタンプ基準クロックソースを再シグナリングする必要を回避することが望ましい場合があります。
Global reference clocks provide a source of traceable time, typically via a hardware radio receiver interface. Examples include GPS, Galileo, and GLONASS. Apart from the name of the reference clock system, no further identification is required.
グローバル基準クロックは、通常ハードウェアの無線受信機インターフェイスを介して、追跡可能な時間のソースを提供します。例としては、GPS、Galileo、GLONASSなどがあります。基準クロックシステムの名前は別として、それ以上の識別は必要ありません。
In other systems, all RTP senders and receivers may use a timestamp reference clock that is not provided by one of the methods listed above. Examples may include the reference time information provided by digital television or cellular services. These sources are identified as "private" reference clocks. All RTP senders and receivers in a session using a private reference clock are assumed to have a mechanism outside this specification for determining whether their timestamp reference clocks are equivalent.
他のシステムでは、すべてのRTP送信側と受信側が、上記の方法のいずれかで提供されていないタイムスタンプ基準クロックを使用する場合があります。例には、デジタルテレビまたは携帯電話サービスによって提供される参照時間情報が含まれます。これらのソースは、「プライベート」基準クロックとして識別されます。プライベート参照クロックを使用するセッションのすべてのRTP送信側と受信側は、タイムスタンプ参照クロックが同等かどうかを判断するために、この仕様外のメカニズムを備えていると想定されます。
[RFC3550] allows senders and receivers to either use a local wallclock reference for their NTP timestamps or, by setting the timestamp field to 0, supply no timestamps at all. Both are common practice in embedded RTP implementations. These clocks are identified as "local" and can, at best, be assumed to be equivalent to clocks originating from the same device.
[RFC3550]を使用すると、送信者と受信者はNTPタイムスタンプにローカルの壁時計参照を使用するか、タイムスタンプフィールドを0に設定して、タイムスタンプをまったく提供しないことができます。どちらも組み込みRTP実装では一般的な方法です。これらのクロックは「ローカル」として識別され、せいぜい、同じデバイスから発信されたクロックと同等であると想定できます。
A timestamp reference clock source may be labelled "traceable" if it is known to be delivering traceable time, provided adjustments are made for differing epochs, timezones, and leap seconds. Timestamps taken using clocks synchronised to a traceable time source can be directly compared even if the clocks are synchronised to different sources or via different mechanisms.
タイムスタンプ基準クロックソースは、異なるエポック、タイムゾーン、およびうるう秒に対して調整が行われる場合に、追跡可能な時間を提供していることがわかっている場合、「追跡可能」とラベル付けされます。追跡可能なタイムソースに同期されたクロックを使用して取得されたタイムスタンプは、クロックが異なるソースに同期されていたり、異なるメカニズムを介して同期されていても、直接比較できます。
Marking a clock as traceable allows additional information (e.g., IP addresses, PTP master identifiers, and the like) to be omitted from the SDP since any traceable clock available at the answerer is considered to be an appropriate timestamp reference clock. For example, an offerer could specify ts-refclk:ntp=/traceable/ and the answerer could use GPS as a reference clock since GPS is a source of traceable time.
クロックを追跡可能としてマークすると、応答側で利用可能な追跡可能なクロックはすべて適切なタイムスタンプ基準クロックと見なされるため、SDPから追加情報（IPアドレス、PTPマスター識別子など）を省略できます。たとえば、提供者はts-refclk：ntp = / traceable /を指定でき、GPSは追跡可能な時間のソースであるため、回答者はGPSを基準クロックとして使用できます。
Specification of the timestamp reference clock source may be at any or all levels (session, media, or source) of an SDP description (see level definitions in Section 3 earlier in this document for more information).
タイムスタンプ基準クロックソースの指定は、SDP記述の任意またはすべてのレベル（セッション、メディア、またはソース）で行うことができます（詳細については、このドキュメントの前のセクション3のレベル定義を参照してください）。
Timestamp reference clock source signalling included at the session level provides default parameters for all RTP sessions and sources in the session description. More specific signalling included at the media level overrides session-level signalling. More specific signalling included at the source level overrides media-level signalling.
セッションレベルに含まれるタイムスタンプ基準クロックソースシグナリングは、セッションの説明にあるすべてのRTPセッションとソースのデフォルトパラメータを提供します。メディアレベルに含まれるより具体的なシグナリングは、セッションレベルのシグナリングを上書きします。ソースレベルに含まれるより具体的なシグナリングは、メディアレベルのシグナリングを上書きします。
If timestamp reference clock source signalling is included anywhere in an SDP description, it must be properly defined for all levels in the description. This may simply be achieved by providing default signalling at the session level.
タイムスタンプ基準クロックソースシグナリングがSDP記述のどこかに含まれている場合、それは記述のすべてのレベルに対して適切に定義されている必要があります。これは、セッションレベルでデフォルトのシグナリングを提供することで簡単に実現できます。
Timestamp reference clock parameters may be repeated at a given level (i.e., for a session or source) to provide information about additional servers or clock sources. If the attribute is repeated at a given level, all clocks described at that level are assumed to be equivalent. Traceable time sources MUST NOT be mixed with non-traceable time sources at any given level.
タイムスタンプ基準クロックパラメータは、追加のサーバーまたはクロックソースに関する情報を提供するために、特定のレベルで（つまり、セッションまたはソースに対して）繰り返すことができます。属性が特定のレベルで繰り返される場合、そのレベルで記述されているすべてのクロックは同等であると見なされます。追跡可能なタイムソースは、特定のレベルで追跡不可能なタイムソースと混合してはなりません。
Note that clock source parameters may change from time to time, for example, as a result of a PTP grandmaster election. SIP [RFC3261] supports the re-signalling of updated SDP information; however, other protocols may require additional notification mechanisms.
たとえば、PTPグランドマスターの選出の結果として、クロックソースパラメータが時々変更される場合があることに注意してください。 SIP [RFC3261]は、更新されたSDP情報の再シグナリングをサポートします。ただし、他のプロトコルでは追加の通知メカニズムが必要になる場合があります。
General forms of usage:
一般的な使用方法：
session level: a=ts-refclk:<clksrc>
media level: a=ts-refclk:<clksrc>
source level: a=ssrc:<ssrc-id> ts-refclk:<clksrc> ABNF [RFC5234] grammar for the timestamp reference clock attribute:
ソースレベル：a = ssrc：<ssrc-id> ts-refclk：<clksrc> ABNF [RFC5234]タイムスタンプ参照クロック属性の文法：
; external references:
POS-DIGIT = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
CRLF = <See RFC 5234>
hostport = <See RFC 3261, with revisions from RFC 5954>
timestamp-refclk = "ts-refclk:" clksrc CRLF
timestamp-refclk = "ts-refclk：" clksrc CRLF
clksrc = ntp / ptp / gps / gal / glonass / local / private /
clksrc-ext
clksrc-ext = clksrc-param-name clksrc-param-value
clksrc-param-name = token
clksrc-param-value = ["=" byte-string ]
ntp = "ntp=" ntp-server-addr
ntp-server-addr = hostport / "/traceable/"
ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002"
/ "IEEE1588-2008"
/ "IEEE802.1AS-2011"
/ ptp-version-ext
ptp-version-ext = token
ptp-server = ptp-gmid [":" ptp-domain]
/ "traceable"
ptp-gmid = EUI64
ptp-domain = ptp-domain-name / ptp-domain-nmbr
; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-name = "domain-name=" 1*16ptp-domain-char
ptp-domain-char = %x21-7E
; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts
ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
ptp-domain-n1 = DIGIT ; 0-9
ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99
ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119
/ "12" %x30-37 ; 120-127
gps = "gps" gal = "gal" glonass = "glonass" local = "local" private = "private" [ ":traceable" ]
gps = "gps" gal = "gal" glonass = "glonass" local = "local" private = "private" ["：traceable"]
EUI64 = 7(2HEXDIG "-") 2HEXDIG
EUI64 = 7（2HEXDIG "-"）2HEXDIG
Figure 1: Timestamp Reference Clock Source Signalling
図1：タイムスタンプ基準クロックソースのシグナリング
Figure 2 shows an example SDP description with a timestamp reference clock source defined at the session level.
図2に、タイムスタンプ参照クロックソースがセッションレベルで定義されたSDP記述の例を示します。
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:ntp=/traceable/
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
Figure 2: Timestamp Reference Clock Definition at the Session Level
図2：セッションレベルでのタイムスタンプ基準クロックの定義
Figure 3 shows an example SDP description with timestamp reference clock definitions at the media level overriding the session-level defaults.
図3は、セッションレベルのデフォルトを上書きするメディアレベルでのタイムスタンプ参照クロック定義を含むSDP記述の例を示しています。
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
a=ts-refclk:ntp=203.0.113.10
a=ts-refclk:ntp=198.51.100.22
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
Figure 3: Timestamp Reference Clock Definition at the Media Level
図3：メディアレベルでのタイムスタンプ基準クロックの定義
Figure 4 shows an example SDP description with a timestamp reference clock definition at the source level overriding the session-level default.
図4は、セッションレベルのデフォルトを上書きするソースレベルのタイムスタンプ基準クロック定義を含むSDP記述の例を示しています。
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
Figure 4: Timestamp Reference Clock Signalling at the Source Level
図4：ソースレベルでのタイムスタンプ基準クロック信号
The media clock source for a stream determines the timebase used to advance the RTP timestamps included in RTP packets. The media clock may be asynchronously generated by the sender, it may be generated in fixed relationship to the reference clock, or it may be generated with respect to another stream on the network (which is presumably being received by the sender).
ストリームのメディアクロックソースは、RTPパケットに含まれるRTPタイムスタンプを進めるために使用されるタイムベースを決定します。メディアクロックは、送信者によって非同期に生成されたり、基準クロックと固定関係で生成されたり、ネットワーク上の別のストリーム（おそらく送信者によって受信されている）に対して生成されたりします。
In the simplest sender implementation, the sender generates media by sampling audio or video according to a free-running local clock. The RTP timestamps in media packets are advanced according to this media clock, and packet transmission is typically timed to regular intervals on this timeline. The sender may or may not include an NTP timestamp in sender reports to allow mapping of this asynchronous media clock to a reference clock.
最も単純な送信側の実装では、送信側は、フリーランニングのローカルクロックに従ってオーディオまたはビデオをサンプリングしてメディアを生成します。メディアパケットのRTPタイムスタンプは、このメディアクロックに従って進んでおり、パケット送信は通常、このタイムライン上の定期的な間隔で行われます。送信者は、この非同期メディアクロックを参照クロックにマッピングできるように、送信者レポートにNTPタイムスタンプを含める場合と含めない場合があります。
The asynchronously generated media clock is the assumed mode of operation when there is no signalling of the media clock source. Alternatively, an asynchronous media clock may be explicitly signalled.
非同期に生成されたメディアクロックは、メディアクロックソースのシグナリングがない場合の想定される動作モードです。あるいは、非同期メディアクロックを明示的に通知することもできます。
a=mediaclk:sender
a = mediaclk：転送
A media clock may be directly derived from a reference clock. For this case, it is required that a reference clock be specified with an a=ts-refclk attribute (Section 4.8).
メディアクロックは、基準クロックから直接派生させることができます。この場合、a = ts-refclk属性で基準クロックを指定する必要があります（セクション4.8）。
The signalling optionally indicates a media clock offset value. The offset indicates the RTP timestamp value at the epoch (time of origin) of the reference clock. To use the offset, implementations need to compute RTP timestamps from reference clocks. To simplify these calculations, streams utilizing offset signalling SHOULD use a TAI timestamp reference clock to avoid complications introduced by leap seconds. See [RFC7164] for further discussion of leap-second issues in timestamp reference clocks.
シグナリングは、オプションでメディアクロックオフセット値を示します。オフセットは、基準クロックのエポック（起点の時刻）でのRTPタイムスタンプ値を示します。オフセットを使用するには、実装で基準クロックからRTPタイムスタンプを計算する必要があります。これらの計算を簡略化するために、オフセットシグナリングを利用するストリームは、うるう秒によって生じる複雑さを回避するために、TAIタイムスタンプ基準クロックを使用する必要があります（SHOULD）。タイムスタンプ参照クロックのうるう秒の問題の詳細については、[RFC7164]を参照してください。
To compute the RTP timestamp against an IEEE 1588 (TAI-based) reference, the time elapsed between the 00:00:00 1 January 1970 IEEE 1588 epoch and the current time must be computed. Between the epoch and 1 January 2013, there were 15,706 days (including extra days during leap years). Since there are no leap seconds in a TAI reference, there are exactly 86,400 seconds during each of these days or a total of 1,356,998,400 seconds from the epoch to 00:00:00 1 January 2013. A 90 kHz RTP clock for a video stream would have advanced 122,129,856,000,000 units over this period. With a signalled offset of 0, the RTP clock value modulo the 32-bit unsigned RTP timestamp representation in the RTP header would have been 2,460,938,240 at 00:00:00 1 January 2013. If an offset of 23,465 had been signalled, the clock value would have been 2,460,961,705.
IEEE 1588（TAIベース）参照に対するRTPタイムスタンプを計算するには、1970年1月1日00:00:00 IEEE 1588エポックと現在の時刻の間の経過時間を計算する必要があります。エポックから2013年1月1日までの間に15,706日ありました（うるう年の追加日数を含む）。 TAI参照にはうるう秒がないため、これらの各日の間に正確に86,400秒、またはエポックから2013年1月1日までの合計で1,356,998,400秒があります。ビデオストリームの90 kHz RTPクロックは、この期間で122,129,856,000,000ユニットを進めました。通知されたオフセットが0の場合、RTPヘッダーの32ビットの符号なしRTPタイムスタンプ表現を法とするRTPクロック値は、2013年1月1日00:00:00に2,460,938,240でした。23,465のオフセットが通知された場合、クロック値2,460,961,705になります。
In order to use an NTP reference, the actual time elapsed between the 00:00:00 1 January 1900 NTP epoch to the current time must be computed. 2,208,988,800 seconds elapsed between the NTP epoch and 00:00:00 1 January 1970 [RFC0868]. Between the beginning of 1970 and 2013, there were 15,706 days elapsed (including extra days during leap years) and 25 leap seconds inserted. There is, therefore, a total of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1 January 2013. A 90 kHz RTP clock for a video stream would have advanced 320,938,850,250,000 units over this period. With a signalled offset of 0, the RTP clock value modulo the 32-bit unsigned representation would have been 1,714,023,696 at 00:00:00 1 January 2013.
NTPリファレンスを使用するには、1900年1月1日の00:00:00 NTPエポックから現在の時刻までの実際の時間を計算する必要があります。 NTPエポックから1970年1月1日00:00:00 [RFC0868]までの経過時間は2,208,988,800秒。 1970年の初めから2013年までの間に、15,706日が経過し（うるう年の追加日を含む）、25うるう秒が挿入されました。したがって、NTPエポックから2013年1月1日00:00:00までの合計時間は3,565,987,225秒です。ビデオストリームの90 kHz RTPクロックは、この期間で320,938,850,250,000ユニット進んでいます。信号オフセットが0の場合、32ビット符号なし表現を法とするRTPクロック値は、2013年1月1日00:00:00に1,714,023,696になります。
If no offset is signalled, the offset can be inferred at the receiver by examining RTCP sender reports that contain NTP and RTP timestamps, which combined define a mapping. The NTP/RTP timestamp mapping provided by RTCP sender reports (SRs) takes precedence over that signalled through SDP; however, the media clock rate implied by the SRs MUST be consistent with the rate signalled.
オフセットが通知されない場合、マッピングを定義するNTPおよびRTPタイムスタンプを含むRTCP送信者レポートを調べることにより、オフセットを受信者で推測できます。 RTCP送信者レポート（SR）によって提供されるNTP / RTPタイムスタンプマッピングは、SDPを通じて通知されたものよりも優先されます。ただし、SRによって暗示されるメディアクロックレートは、シグナリングされたレートと一致している必要があります。
A rate modifier may be specified. The modifier is expressed as the ratio of two integers and modifies the rate specified or implied by the media description by this ratio. If omitted, the rate is assumed to be the exact rate specified or implied by the media format. For example, without a rate specification, the RTP clock for an 8 kHz G.711 audio stream will advance exactly 8000 units for each second advance in the reference clock from which it is derived.
レート修飾子を指定できます。修飾子は2つの整数の比率で表され、メディアの説明で指定または暗黙指定されているレートをこの比率で変更します。省略した場合、レートはメディア形式で指定または暗黙指定された正確なレートであると見なされます。たとえば、レート指定がない場合、8 kHz G.711オーディオストリームのRTPクロックは、それが派生する基準クロックで1秒ごとに正確に8000単位進みます。
The rate modifier is primarily useful for accommodating certain "oddball" audio sample rates associated with NTSC video (see Figure 7). Modified rates are not advised for video streams that generally use a 90 kHz RTP clock regardless of frame rate or sample rate used for embedded audio.
レート修飾子は、NTSCビデオに関連する特定の「奇妙な」オーディオサンプルレートに対応するために主に役立ちます（図7を参照）。埋め込みオーディオに使用されるフレームレートやサンプルレートに関係なく、通常90 kHz RTPクロックを使用するビデオストリームの場合、修正レートはお勧めしません。
a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate
denominator>]
A common synchronisation architecture for audio/visual systems involves distributing a reference media clock from a master device to a number of slave devices, typically by means of a cable. Examples include audio word clock distribution and video black burst distribution. In this case, the media clock is locally generated, often by a crystal oscillator, and is not locked to a timestamp reference clock.
オーディオ/ビジュアルシステムの一般的な同期アーキテクチャでは、通常はケーブルを使用して、マスターデバイスから多数のスレーブデバイスに参照メディアクロックを配信します。例としては、オーディオワードクロック配信やビデオブラックバースト配信があります。この場合、メディアクロックはローカルで生成され、多くの場合水晶発振器によって生成され、タイムスタンプ基準クロックにロックされません。
To support this architecture across a network, a master clock identifier is associated with an RTP media stream carrying media clock timing information from a master device. The master clock identifier represents a media clock source in the master device. Slave devices in turn associate the master media clock identifier with streams they transmit, signalling the synchronisation relationship between the master and the transmitter's media clock.
ネットワーク全体でこのアーキテクチャをサポートするために、マスタークロック識別子は、マスターデバイスからのメディアクロックタイミング情報を運ぶRTPメディアストリームに関連付けられています。マスタークロック識別子は、マスターデバイスのメディアクロックソースを表します。スレーブデバイスは、マスターメディアクロック識別子を送信するストリームに関連付け、マスターとトランスミッターのメディアクロック間の同期関係を通知します。
Slave devices recover media clock timing from the clock master stream, using it to synchronise the slave's media clock with the master. If a common reference clock is available, NTP timestamps in the master clock RTP media stream are taken using the shared reference clock. The NTP timestamps communicate information about media clock timing (rate and phase) from the master to the slave devices. NTP timestamps are communicated in the usual RTP fashion via RTCP SRs, or via the [RFC6051] header extension. If no shared reference clock is available or signalled, a slave can synchronise to the master's media clock using RTP timestamps alone as described in Section 5.1 of [RFC3550].
スレーブデバイスは、クロックマスターストリームからメディアクロックタイミングを回復し、それを使用してスレーブのメディアクロックをマスターと同期します。共通の基準クロックが使用可能な場合、マスタークロックRTPメディアストリームのNTPタイムスタンプは、共有基準クロックを使用して取得されます。 NTPタイムスタンプは、マスターからスレーブデバイスへのメディアクロックタイミング（レートとフェーズ）に関する情報を伝達します。 NTPタイムスタンプは、RTCP SRまたは[RFC6051]ヘッダー拡張を介して通常のRTP方式で通信されます。 [RFC3550]のセクション5.1で説明されているように、共有リファレンスクロックが利用できない場合や信号が送信されない場合、スレーブはRTPタイムスタンプのみを使用してマスターのメディアクロックに同期できます。
Note that the slaving of a device media clock to a master device does not affect RTP inter-media synchronisation. Time-aligned playout of two or more RTP sources still relies upon NTP timestamps supplied via RTCP SRs or by the RFC 6051 timestamp header extension.
デバイスメディアクロックをマスターデバイスにスレーブ化しても、RTPのメディア間同期には影響しません。 2つ以上のRTPソースの時間調整されたプレイアウトは、RTCP SRまたはRFC 6051タイムスタンプヘッダー拡張によって提供されるNTPタイムスタンプに依拠します。
In a given system, master clock identifiers must uniquely identify a single media clock source. Such identifiers MAY be manually configured; however, identifiers SHOULD be generated according to the "short-term persistent RTCP CNAME" algorithm as described in [RFC7022]. Master clock identifiers not already in base64 format MUST be encoded as base64 strings when used in SDP. Although the CNAME algorithm is used to generate the master clock identifier, it is used to tag RTP sources in SDP descriptions and does not appear in RTCP as a CNAME.
特定のシステムでは、マスタークロック識別子は単一のメディアクロックソースを一意に識別する必要があります。このような識別子は手動で設定できます。ただし、[RFC7022]で説明されているように、識別子は「短期永続RTCP CNAME」アルゴリズムに従って生成する必要があります（SHOULD）。まだbase64形式になっていないマスタークロック識別子は、SDPで使用する場合、base64文字列としてエンコードする必要があります。 CNAMEアルゴリズムはマスタークロック識別子の生成に使用されますが、SDPの説明でRTPソースにタグを付けるために使用され、CNAMEとしてRTCPに表示されません。
A reference stream can be an RTP stream or an Audio Video Bridging (AVB) stream based on the [IEEE1722] standard.
参照ストリームは、[IEEE1722]標準に基づくRTPストリームまたはAudio Video Bridging（AVB）ストリームです。
An RTP clock master stream SHOULD be identified at the source level by an SSRC [RFC5576] and master clock identifier. An RTP stream that provides media clock timing directly from a reference media clock (e.g., internal crystal, audio word clock, or video black burst signal) SHOULD tag the stream as a master clock source using the "src:" prefix. If master clock identifiers are declared at the media or session level, all RTP sources at or below the level of declaration MUST provide equivalent timing to a slave receiver.
RTPクロックマスターストリームは、SSRC [RFC5576]とマスタークロック識別子によってソースレベルで識別される必要があります（SHOULD）。参照メディアクロックから直接メディアクロックタイミングを提供するRTPストリーム（たとえば、内部クリスタル、オーディオワードクロック、またはビデオブラックバースト信号）は、「src：」プレフィックスを使用してストリームにマスタークロックソースとしてタグを付ける必要があります（SHOULD）。マスタークロック識別子がメディアレベルまたはセッションレベルで宣言されている場合、宣言レベル以下のすべてのRTPソースは、スレーブレシーバーに同等のタイミングを提供する必要があります。
a=ssrc:<ssrc> mediaclk:id=src:<media-clktag> sender
a=mediaclk:id=src:<media-clktag> sender
A transmitted RTP stream slaved to the media clock master is signalled by including a master clock identifier:
メディアクロックマスターにスレーブ化された送信RTPストリームは、マスタークロック識別子を含めることによって通知されます。
a=mediaclk:id=<media-clktag> sender
An RTP media sender indicates that it is slaved to an IEEE 1722 clock master via a stream identifier (an EUI-64):
RTPメディアセンダーは、ストリーム識別子（EUI-64）を介してIEEE 1722クロックマスターにスレーブ化されていることを示します。
a=mediaclk:IEEE1722=<StreamID>
An RTP media sender may gateway IEEE 1722 media clock timing to RTP:
RTPメディア送信者は、IEEE 1722メディアクロックタイミングをRTPにゲートウェイできます。
a=mediaclk:id=src:<media-clktag> IEEE1722=<StreamID>
Specification of the media clock source may be at any or all levels (session, media, or source) of an SDP description (see level definitions (Section 3) earlier in this document for more information).
メディアクロックソースの指定は、SDP記述の任意またはすべてのレベル（セッション、メディア、またはソース）で行うことができます（詳細については、このドキュメントで前述したレベルの定義（セクション3）を参照してください）。
Media clock source signalling included at session level provides default parameters for all RTP sessions and sources in the session description. More specific signalling included at the media level overrides session-level signalling. Further, source-level signalling overrides media clock source signalling at the enclosing media level and session level.
セッションレベルで含まれるメディアクロックソースシグナリングは、セッションの説明にあるすべてのRTPセッションおよびソースのデフォルトパラメータを提供します。メディアレベルに含まれるより具体的なシグナリングは、セッションレベルのシグナリングを上書きします。さらに、ソースレベルのシグナリングは、囲んでいるメディアレベルとセッションレベルのメディアクロックソースシグナリングを上書きします。
Media clock source signalling may be present or absent on a per-stream basis. In the absence of media clock source signals, receivers assume an asynchronous media clock generated by the sender.
メディアクロックソースシグナリングは、ストリームごとに存在する場合と存在しない場合があります。メディアクロックソース信号がない場合、レシーバーは送信者によって生成された非同期メディアクロックを想定します。
Media clock source parameters may be repeated at a given level (i.e., for a session or source) to provide information about additional clock sources. If the attribute is repeated at a given level, all clocks described at that level are comparable clock sources and may be used interchangeably.
メディアクロックソースパラメータは、追加のクロックソースに関する情報を提供するために、特定のレベルで（つまり、セッションまたはソースに対して）繰り返すことができます。属性が特定のレベルで繰り返される場合、そのレベルで記述されているすべてのクロックは同等のクロックソースであり、互換的に使用できます。
General forms of usage:
一般的な使用方法：
session level: a=mediaclk:<mediaclock>
media level: a=mediaclk:<mediaclock>
source level: a=ssrc:<ssrc-id> mediaclk:<mediaclock>
ABNF [RFC5234] grammar for the media clock reference attribute:
メディアクロック参照属性のABNF [RFC5234]文法：
; external references:
integer = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
base64 = <See RFC 4566>
SP = <See RFC 5234>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
media-clksrc = "mediaclk:" [media-clkid SP] mediaclock
media-clksrc = "mediaclk：" [media-clkid SP] mediaclock
media-clkid = "id=" [ "src:" ] media-clktag
media-clktag = base64
mediaclock = sender / direct / ieee1722-streamid / mediaclock-ext
mediaclock-ext = mediaclock-param-name mediaclock-param-value
mediaclock-param-name = token
mediaclock-param-value = [ "=" byte-string ]
sender = "sender"
direct = "direct" [ "=" 1*DIGIT ] [SP rate]
rate = "rate=" integer "/" integer
ieee1722-streamid = "IEEE1722=" avb-stream-id
avb-stream-id = EUI64
EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 5: Media Clock Source Signalling
図5：メディアクロックソースのシグナリング
Figure 6 shows an example SDP description -- 8 channels of 24-bit, 48 kHz audio transmitted as a multicast stream. Media clock is derived directly from an IEEE 1588-2008 reference.
図6は、SDPの説明の例を示しています。マルチキャストストリームとして送信される24ビット、48 kHzオーディオの8チャネル。メディアクロックは、IEEE 1588-2008リファレンスから直接派生しています。
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/8
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424
Figure 6: Media Clock Directly Referenced to IEEE 1588-2008
図6：IEEE 1588-2008を直接参照するメディアクロック
Figure 7 shows an example SDP description -- 2 channels of 24-bit, 44056 kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-2008 reference clock.
図7は、SDPの説明の例を示しています。24ビットの2チャネル、44056 kHzのNTSC「プルダウン」メディアクロックは、IEEE 1588-2008基準クロックから直接派生しています。
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/44100/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424 rate=1000/1001
Figure 7: "Oddball" Sample Rate Directly Referenced to IEEE 1588-2008 Figure 8 shows the same 48 kHz audio transmission from Figure 6 with media clock derived from another RTP stream.
図7：IEEE 1588-2008を直接参照する「奇妙な」サンプルレート図8は、図6と同じ48 kHzオーディオ伝送と、別のRTPストリームから派生したメディアクロックを示しています。
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender
Figure 8: RTP Stream with Media Clock Slaved to a Master
図8：メディアクロックがマスターにスレーブ化されたRTPストリーム
Figure 9 shows the same 48 kHz audio transmission from Figure 6 with media clock derived from an IEEE 1722 AVB stream.
図9は、図6と同じ48 kHzオーディオ伝送と、IEEE 1722 AVBストリームから派生したメディアクロックを示しています。
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
Figure 9: RTP Stream with Media Clock Slaved to an IEEE 1722 Master Device
図9：メディアクロックがIEEE 1722マスターデバイスにスレーブ接続されたRTPストリーム
Signalling of timestamp reference clock source (Section 4.8) and media clock source (Section 5.4) is defined to be used either by applications that implement the SDP Offer/Answer model [RFC3264] or by applications that use SDP to describe media and transport configurations.
タイムスタンプ基準クロックソース（セクション4.8）およびメディアクロックソース（セクション5.4）のシグナリングは、SDPオファー/アンサーモデル[RFC3264]を実装するアプリケーション、またはメディアとトランスポート構成を記述するためにSDPを使用するアプリケーションのいずれかによって使用されるように定義されています。
A description SHOULD include both reference clock signalling and media clock signalling. If no reference clock is available, this SHOULD be signalled as a local reference (Section 4.6).
説明には、リファレンスクロックシグナリングとメディアクロックシグナリングの両方を含める必要があります。利用可能な基準クロックがない場合、これはローカル基準として通知されるべきです（セクション4.6）。
When no media clock signalling is present, an asynchronous media clock (Section 5.1) MUST be assumed. When no reference clock signalling is present, a local reference clock (Section 4.6) MUST be assumed.
メディアクロックシグナリングが存在しない場合、非同期メディアクロック（セクション5.1）を想定する必要があります。基準クロック信号が存在しない場合、ローカル基準クロック（セクション4.6）を想定する必要があります。
If a reference clock is not signalled or a local reference is specified, the corresponding media clock may be established as rate synchronised with no assurance of time synchronisation.
基準クロックが通知されない場合、またはローカル基準が指定されている場合、対応するメディアクロックは、時間同期が保証されていないレート同期として確立されます。
When the description signals a direct-referenced media clock (Section 5.2), reference clock signalling is REQUIRED. Asynchronous and stream-referenced media clocks (Section 5.3) MAY be specified with or without a reference clock signalling.
説明が直接参照されるメディアクロックを通知する場合（セクション5.2）、参照クロックシグナリングが必要です。非同期およびストリーム参照メディアクロック（5.3節）は、参照クロックシグナリングの有無にかかわらず指定できます（MAY）。
During offer/answer, clock source signalling via SDP uses a declarative model. Supported media and/or reference clocks are specified in the offered SDP description. The answerer may accept or reject the offer in an application-specific way depending on the clocks that are available and the clocks that are offered. For example, an answerer may choose to accept an offer that lacks a common clock by falling back to a lower-performance mode of operation (e.g., by assuming reference or media clocks are local rather than shared). Conversely, the answerer may choose to reject the offer when the offered clock specifications indicate that the available reference and/or media clocks are incompatible.
オファー/アンサー中、SDPを介したクロックソースシグナリングは宣言型モデルを使用します。サポートされているメディアやリファレンスクロックは、提供されているSDPの説明で指定されています。回答者は、利用可能なクロックと提供されているクロックに応じて、アプリケーション固有の方法でオファーを受け入れるか拒否することができます。たとえば、回答者は、より低いパフォーマンスの動作モードにフォールバックすることにより、共通クロックのないオファーを受け入れることを選択する場合があります（たとえば、参照クロックまたはメディアクロックが共有ではなくローカルであると想定することにより）。逆に、提供されたクロック仕様が、利用可能なリファレンスおよび/またはメディアクロックに互換性がないことを示している場合、回答者はオファーを拒否することを選択できます。
While negotiation of reference clock and media clock attributes is not defined in this document, negotiation MAY be accomplished using the capabilities negotiation procedures defined in [RFC5939].
参照クロックとメディアクロック属性のネゴシエーションはこのドキュメントでは定義されていませんが、[RFC5939]で定義されている機能ネゴシエーション手順を使用してネゴシエーションを実行できます（MAY）。
An offerer or answerer indicates support for media clock signalling by including a reference or media clock specification in the SDP description. An offerer or answerer without specific reference or media clocks to signal SHOULD indicate support for clock source signalling by including a local reference clock (Section 4.6) specification in the SDP description.
オファーまたはアンサーは、SDP記述にリファレンスまたはメディアクロック仕様を含めることにより、メディアクロックシグナリングのサポートを示します。シグナルを送る特定のリファレンスまたはメディアクロックがないオファーまたはアンサーは、ローカルリファレンスクロック（セクション4.6）仕様をSDP記述に含めることにより、クロックソースシグナリングのサポートを示す必要があります（SHOULD）。
If one or more of the reference clocks specified in the offer are usable by the answerer, the answerer SHOULD respond with an answer containing the subset of reference clock specifications in the offer that are usable by the answerer. If the answerer rejects the offer because the available reference clocks are incompatible, the rejection MUST contain at least one timestamp reference clock specification usable by the answerer so that appropriate information is available for diagnostics. If no external reference clock is available to the answerer, a local reference clock (Section 4.6) specification SHOULD be included in the rejection.
オファーで指定された1つ以上の参照クロックが回答者によって使用可能である場合、回答者は、回答者が使用できるオファー内の参照クロック仕様のサブセットを含む回答で応答する必要があります（SHOULD）。利用可能な参照クロックに互換性がないために回答者がオファーを拒否した場合、適切な情報を診断に利用できるように、拒否者は回答者が使用できる少なくとも1つのタイムスタンプ参照クロック仕様を含める必要があります。回答者が利用できる外部リファレンスクロックがない場合は、ローカルリファレンスクロック（セクション4.6）の仕様を拒否に含める必要があります。
In both offers and answers, multiple reference clock specifications indicate equivalent clocks from different sources that may be used interchangeably. RTP senders and receivers are assured proper synchronisation regardless of which of the specified sources is chosen and, in support of fault tolerance, may switch clock sources while streaming.
オファーとアンサーの両方で、複数の基準クロック仕様は、互換的に使用できる異なるソースからの同等のクロックを示しています。 RTPの送信側と受信側は、指定されたソースのどれが選択されているかに関係なく適切な同期が保証され、フォールトトレランスをサポートするために、ストリーミング中にクロックソースを切り替えることができます。
If the media clock mode specified in the offer is acceptable to the answerer, the answerer SHOULD respond with an answer containing the same media clock specification as the offer. If the answerer rejects the offer because the available reference clocks are incompatible, the rejection MUST contain a media clock specification supported by the answerer so that appropriate information is available for diagnostics. If no shared media clocks are available to the answerer, an asynchronous media clock (Section 5.1) specification SHOULD be included in the rejection.
オファーで指定されたメディアクロックモードが回答者に受け入れられる場合、回答者はオファーと同じメディアクロック仕様を含む回答で応答する必要があります（SHOULD）。利用可能な参照クロックに互換性がないために回答者がオファーを拒否した場合、適切な情報が診断に利用できるように、拒否には回答者がサポートするメディアクロック仕様が含まれている必要があります。回答者が利用できる共有メディアクロックがない場合は、非同期メディアクロック（セクション5.1）の仕様を拒否に含める必要があります（SHOULD）。
SDP can be employed outside of the offer/answer context, for instance, for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [RFC2974] or streamed through the Real Time Streaming Protocol (RTSP) [RFC2326].
SDPは、オファー/アンサーコンテキストの外で使用できます。たとえば、Session Announcement Protocol（SAP）[RFC2974]を通じてアナウンスされる、またはReal Time Streaming Protocol（RTSP）[RFC2326]を通じてストリーミングされるマルチメディアセッションなどです。
Devices using published descriptions to join sessions SHOULD assess their synchronisation compatibility with the described session based on the clock source signalling and SHOULD NOT attempt to join a session with incompatible reference or media clocks.
公開された説明を使用してセッションに参加するデバイスは、クロックソースシグナリングに基づいて、説明されたセッションとの同期の互換性を評価する必要があり（SHOULD NOT）、互換性のない参照またはメディアクロックでセッションに参加しようとしないでください（SHOULD NOT）。
Entities receiving and acting upon an SDP message should note that a session description cannot be trusted unless it has been obtained by an authenticated transport protocol from a known and trusted source. Many different transport protocols may be used to distribute a session description, and the nature of the authentication will differ from transport to transport. For some transports, security features are often not deployed. In case a session description has not been obtained in a trusted manner, the endpoint should exercise care because, among other attacks, the media sessions received may not be the intended ones, the destination where media is sent to may not be the expected one, and any of the parameters of the session may be incorrect.
SDPメッセージを受信して処理するエンティティは、認証されたトランスポートプロトコルによって既知の信頼できるソースから取得されていない限り、セッションの説明は信頼できないことに注意してください。多くの異なるトランスポートプロトコルを使用してセッションの説明を配布することができ、認証の性質はトランスポートごとに異なります。一部のトランスポートでは、セキュリティ機能が配備されていないことがよくあります。信頼できる方法でセッションの説明が取得されていない場合、エンドポイントは、他の攻撃の中でも、受信したメディアセッションが意図したものではない可能性があり、メディアの送信先が予期したものではない可能性があるため、注意が必要です。そして、セッションのパラメータのいずれかが正しくない可能性があります。
Incorrect reference or media clock parameters may cause devices or streams to synchronise to unintended clock sources. Normally, this simply results in failure to establish a session or failure to synchronise once connected. Enough devices fraudulently assigned to a specific clock source (e.g., a particular IEEE 1588 grandmaster) may, however, constitute a successful denial-of-service attack on that source. Devices MAY wish to validate the integrity of the clock description through some means before connecting to unfamiliar clock sources.
参照またはメディアクロックのパラメーターが正しくない場合、デバイスまたはストリームが意図しないクロックソースと同期する可能性があります。通常、これは単にセッションの確立の失敗、または接続後の同期の失敗につながります。ただし、特定のクロックソース（特定のIEEE 1588グランドマスターなど）に不正に割り当てられた十分なデバイスは、そのソースに対するサービス拒否攻撃を成功させる可能性があります。デバイスは、馴染みのないクロックソースに接続する前に、何らかの方法でクロックの説明の整合性を検証する必要があります。
The timestamp reference clocks negotiated by this protocol are used to provide media timing information to RTP. Negotiated timestamp reference clocks should not be relied upon to provide a secure time reference for security critical operations (e.g., the expiration of public key certificates).
このプロトコルによってネゴシエートされたタイムスタンプ基準クロックは、RTPにメディアタイミング情報を提供するために使用されます。ネゴシエートされたタイムスタンプ参照クロックは、セキュリティ上重要な操作（たとえば、公開鍵証明書の期限切れ）に安全な時間参照を提供するために信頼されるべきではありません。
This document defines two new SDP attributes: "ts-refclk" and "mediaclk", within the existing Internet Assigned Numbers Authority (IANA) registry of SDP Parameters.
このドキュメントでは、SDPパラメータの既存のInternet Assigned Numbers Authority（IANA）レジストリ内で、「ts-refclk」と「mediaclk」という2つの新しいSDP属性を定義しています。
This document also defines a new IANA registry subordinate to the IANA SDP Parameters registry: the Media Clock Source Parameters registry. Within this new registry, this document defines an initial set of three media clock source parameters. Further, this document defines a second new IANA registry subordinate to the IANA SDP Parameters registry: the Timestamp Reference Clock Source Parameters registry. Within this new registry, this document defines an initial six parameters.
このドキュメントでは、IANA SDPパラメータレジストリの下位にある新しいIANAレジストリであるMedia Clock Source Parametersレジストリも定義しています。この新しいレジストリ内で、このドキュメントは3つのメディアクロックソースパラメータの初期セットを定義します。さらに、このドキュメントでは、IANA SDPパラメータレジストリの下位にある2つ目の新しいIANAレジストリである、タイムスタンプリファレンスクロックソースパラメータレジストリを定義しています。この新しいレジストリ内で、このドキュメントは最初の6つのパラメータを定義します。
The SDP attribute "ts-refclk" defined by this document is registered with the IANA registry of SDP Parameters as follows:
このドキュメントで定義されているSDP属性「ts-refclk」は、次のようにSDPパラメータのIANAレジストリに登録されています。
SDP Attributes ( "att-field (both session and media level)" & "att-field (source level)" ):
SDP属性（ "att-field（セッションとメディアレベルの両方）"＆ "att-field（ソースレベル）"）：
Attribute name: ts-refclk
属性名：ts-refclk
Long form: Timestamp reference clock source
長い形式：タイムスタンプ基準クロックソース
Type of name: att-field
名前のタイプ：att-field
Type of attribute: Session, media, and source level
属性のタイプ：セッション、メディア、ソースレベル
Subject to charset: No
文字セットの対象：いいえ
Purpose: See Section 4 of this document
目的：このドキュメントのセクション4を参照してください
Reference: This document
参照：このドキュメント
Values: See Section 8.3 of this document
値：このドキュメントのセクション8.3を参照
Figure 10: Reference Clock SDP Parameter IANA Registration
図10：基準クロックのSDPパラメーターIANAの登録
The attribute has an extensible parameter field; therefore, a registry for these parameters is required. This new registry is defined in Section 8.3.
属性には拡張可能なパラメーターフィールドがあります。したがって、これらのパラメーターのレジストリーが必要です。この新しいレジストリはセクション8.3で定義されています。
The SDP attribute "mediaclk" defined by this document is registered with the IANA registry of SDP Parameters as follows:
このドキュメントで定義されているSDP属性「mediaclk」は、次のようにSDPパラメータのIANAレジストリに登録されています。
SDP Attributes ( "att-field (both session and media level)" & "att-field (source level)" ):
SDP属性（ "att-field（セッションとメディアレベルの両方）"＆ "att-field（ソースレベル）"）：
Attribute name: mediaclk
属性名：mediaclk
Long form: Media clock source
長い形式：メディアクロックソース
Type of name: att-field
名前のタイプ：att-field
Type of attribute: Session, media, and source level
属性のタイプ：セッション、メディア、ソースレベル
Subject to charset: No
文字セットの対象：いいえ
Purpose: See Section 5 of this document
目的：このドキュメントのセクション5を参照
Reference: This document
参照：このドキュメント
Values: See Section 8.4 of this document
値：このドキュメントのセクション8.4を参照
Figure 11: Media Clock SDP Parameter IANA Registration
図11：メディアクロックSDPパラメーターIANA登録
The attribute has an extensible parameter field; therefore, a registry for these parameters is required. The new registry is defined in Section 8.4.
属性には拡張可能なパラメーターフィールドがあります。したがって、これらのパラメーターのレジストリーが必要です。新しいレジストリはセクション8.4で定義されています。
This document creates a new IANA subregistry called the Timestamp Reference Clock Source Parameters registry, subordinate to the IANA SDP Parameters registry. Each entry in the Timestamp Reference Clock Source Parameters registry contains:
このドキュメントは、タイムスタンプリファレンスクロックソースパラメータレジストリと呼ばれる新しいIANAサブレジストリを作成し、IANA SDPパラメータレジストリに従属します。 Timestamp Reference Clock Source Parametersレジストリの各エントリには、次のものが含まれます。
Name: Token used in the SDP description (clksrc-param-name)
名前：SDPの説明で使用されるトークン（clksrc-param-name）
Long name: Descriptive name for the timestamp reference clock source
長い名前：タイムスタンプ参照クロックソースのわかりやすい名前
Reference: Reference to the document describing the SDP token (clksrc-param-name) and syntax for the optional value associated with the token (mediaclock-param-value)
参照：SDPトークン（clksrc-param-name）およびトークンに関連付けられたオプションの値（mediaclock-param-value）の構文を説明するドキュメントへの参照
Initial values for the Timestamp Reference Clock Source Parameters registry are given below.
Timestamp Reference Clock Source Parametersレジストリの初期値を以下に示します。
Future assignments are to be made through the Specification Required policy [RFC5226]. The Name field in the table corresponds to a new value corresponding to clksrc-param-name. The Reference must specify a syntax corresponding to clksrc-param-value.
今後の割り当ては、Specification Requiredポリシー[RFC5226]を通じて行われます。テーブルのNameフィールドは、clksrc-param-nameに対応する新しい値に対応しています。参照では、clksrc-param-valueに対応する構文を指定する必要があります。
+---------+------------------------------+--------------------------+
| Name | Long Name | Reference |
+---------+------------------------------+--------------------------+
| ntp | Network Time Protocol | This document, Section 4 |
| | | |
| ptp | Precision Time Protocol | This document, Section 4 |
| | | |
| gps | Global Positioning System | This document, Section 4 |
| | | |
| gal | Galileo | This document, Section 4 |
| | | |
| glonass | Global Navigation Satellite | This document, Section 4 |
| | System | |
| | | |
| local | Local Clock | This document, Section 4 |
| | | |
| private | Private Clock | This document, Section 4 |
+---------+------------------------------+--------------------------+
This document creates a new IANA subregistry called the Media Clock Source Parameters registry, subordinate to the IANA SDP Parameters registry. Each entry in the Media Clock Source Parameters registry contains:
このドキュメントは、メディアクロックソースパラメータレジストリと呼ばれる、IANA SDPパラメータレジストリに従属する新しいIANAサブレジストリを作成します。 Media Clock Source Parametersレジストリの各エントリには、次のものが含まれます。
Name: Token used in the SDP description (mediaclock-param-name)
名前：SDPの説明で使用されるトークン（mediaclock-param-name）
Long name: Descriptive name for the media clock source type
長い名前：メディアクロックソースタイプのわかりやすい名前
Reference: Reference to the document describing the SDP token (mediaclock-param-name) and syntax for the optional value associated with the token (mediaclock-param-value)
参照：SDPトークン（mediaclock-param-name）およびトークンに関連付けられたオプションの値（mediaclock-param-value）の構文を説明するドキュメントへの参照
Initial values for the Media Clock Source Parameters registry are given below.
Media Clock Source Parametersレジストリの初期値を以下に示します。
Future assignments are to be made through the Specification Required policy [RFC5226]. The Name field in the table corresponds to a new value corresponding to mediaclock-param-name. The Reference must specify a syntax corresponding to mediaclock-param-value.
今後の割り当ては、Specification Requiredポリシー[RFC5226]を通じて行われます。テーブルのNameフィールドは、mediaclock-param-nameに対応する新しい値に対応しています。参照では、mediaclock-param-valueに対応する構文を指定する必要があります。
+----------+-----------------------------+--------------------------+
| Name | Long Name | Reference |
+----------+-----------------------------+--------------------------+
| sender | Asynchronously Generated | This document, Section 5 |
| | Media Clock | |
| | | |
| direct | Direct-Referenced Media | This document, Section 5 |
| | Clock | |
| | | |
| IEEE1722 | IEEE1722 Media Stream | This document, Section 5 |
| | Identifier | |
+----------+-----------------------------+--------------------------+
[RFC5576] requires new source-level attributes to be registered with the IANA registry named "att-field (source level)".
[RFC5576]では、「att-field（source level）」という名前のIANAレジストリに新しいソースレベル属性を登録する必要があります。
The source-level SDP attribute "ts-refclk" defined by this document is registered with the "att-field (source level)" IANA registry of SDP Parameters, according to Figure 10.
このドキュメントで定義されているソースレベルのSDP属性「ts-refclk」は、図10に従って、SDPパラメータの「att-field（source level）」IANAレジストリに登録されています。
The source-level SDP attribute "mediaclk" defined by this document is registered with the "att-field (source level)" IANA registry of SDP Parameters, according to Figure 11.
このドキュメントで定義されているソースレベルのSDP属性「mediaclk」は、図11に従って、SDPパラメータの「att-field（source level）」IANAレジストリに登録されています。
The authors would like to thank Magnus Westerlund and Paul Kyzivat for valuable comments that resulted in important improvements to this document.
この文書の重要な改善につながった貴重なコメントを提供してくれたMagnus WesterlundとPaul Kyzivatに感謝します。
[IEEE1588-2002] IEEE, "1588-2002 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", October 2002, <http://standards.ieee.org/findstds/ standard/1588-2002.html>.
[IEEE1588-2002] IEEE、 "1588-2002-IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems"、2002年10月、<http://standards.ieee.org/findstds/ standard / 1588-2002。 html>。
[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>。
[IEEE1722] IEEE, "1722-2001 - IEEE Standard for Layer 2 Transport Protocol for Time Sensitive Applications in a Bridged Local Area Network", May 2011, <http://standards.ieee.org/findstds/ standard/1722-2011.html>.
[IEEE1722] IEEE、「1722-2001-ブリッジローカルエリアネットワークにおける時間に敏感なアプリケーションのためのレイヤ2トランスポートプロトコルのIEEE標準」、2011年5月、<http://standards.ieee.org/findstds/ standard / 1722-2011 .html>。
[IEEE802.1AS-2011] IEEE, "802.1AS-2011 - IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", February 2011, <http://standards.ieee.org/findstds/ standard/802.1AS-2011.html>.
[IEEE802.1AS-2011] IEEE、「802.1AS-2011-ローカルおよびメトロポリタンエリアネットワークのIEEE標準-ブリッジローカルエリアネットワークにおける時間依存アプリケーションのタイミングと同期」、2011年2月、<http://standards.ieee .org / findstds / standard / 802.1AS-2011.html>。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[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月。
[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月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「Session Description Protocol（SDP）のソース固有のメディア属性」、RFC 5576、2009年6月。
[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月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051] Perkins、C。およびT. Schierl、「RTPフローの迅速な同期」、RFC 6051、2010年11月。
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, September 2013.
[RFC7022] Begen、A.、Perkins、C.、Wing、D。、およびE. Rescorla、「RTP制御プロトコル（RTCP）の正規名（CNAME）を選択するためのガイドライン」、RFC 7022、2013年9月。
[AES11-2009] Audio Engineering Society, "AES11-2009: AES recommended practice for digital audio engineering - Synchronization of digital audio equipment in studio operations", February 2010, <http://www.aes.org/standards/>.
[AES11-2009]オーディオエンジニアリングソサエティ、「AES11-2009：デジタルオーディオエンジニアリングのためのAES推奨プラクティス-スタジオ操作におけるデジタルオーディオ機器の同期」、2010年2月、<http://www.aes.org/standards/>。
[IEEE802.1BA-2011] IEEE, "802.1BA-2011 - IEEE Standard for Local and metropolitan area networks -- Audio Video Bridging (AVB) Systems", September 2011, <http://standards.ieee.org/findstds/ standard/802.1BA-2011.html>.
[IEEE802.1BA-2011] IEEE、「802.1BA-2011-ローカルおよびメトロポリタンエリアネットワークのIEEE標準-オーディオビデオブリッジング（AVB）システム」、2011年9月、<http://standards.ieee.org/findstds/ standard / 802.1BA-2011.html>。
[IS-GPS-200F] Global Positioning Systems Directorate, "Navstar GPS Space Segment/Navigation User Segment Interfaces", IS-GPS-200F , September 2011, <http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>.
[IS-GPS-200F] Global Positioning Systems Directorate、「Navstar GPS Space Segment / Navigation User Segment Interfaces」、IS-GPS-200F、2011年9月、<http://www.navcen.uscg.gov/pdf/IS- GPS-200F.pdf>。
[Olsen] Olsen, D., "Time Accuracy Requirements in Audio Networks", April 2007, <http://www.ieee802.org/1/files/public/docs2007/ as-dolsen-time-accuracy-0407.pdf>.
[Olsen] Olsen、D.、「オーディオネットワークの時間精度要件」、2007年4月、<http://www.ieee802.org/1/files/public/docs2007/ as-dolsen-time-accuracy-0407.pdf >。
[RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983.
[RFC0868] Postel、J。およびK. Harrenstien、「Time Protocol」、STD 26、RFC 868、1983年5月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、2000年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939] Andreasen、F。、「Session Description Protocol（SDP）Capability Negotiation」、RFC 5939、2010年9月。
[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月。
[RFC7272] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., Montagud, M., and K. Gross, "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, June 2014.
[RFC7272] Brandenburg、R.、Stokking、H.、Deventer、O.、Boronat、F.、Montagud、M.、and K. Gross、 "RTS Control Protocol（RTCP）を使用した宛先間メディア同期（IDMS） "、RFC 7272、2014年6月。
[SMPTE-318M-1999] Society of Motion Picture & Television Engineers, "Television and Audio - Synchronization of 59.94- or 50-Hz Related Video and Audio Systems in Analog and Digital Areas - Reference Signals", ST 318:1999, <http://standards.smpte.org/>.
[SMPTE-318M-1999] Society of Motion Picture and Television Engineers、 "Television and Audio-Synchronization of 59.94- or 50-Hz Related Video and Audio Systems in Analog and Digital Areas-Reference Signals"、ST 318：1999、<http ：//standards.smpte.org/>。
Authors' Addresses
著者のアドレス
Aidan Williams Audinate Level 1, 458 Wattle St Ultimo, NSW 2007 Australia
Aidan Williams Audinateレベル1、458 Wattle St Ultimo、NSW 2007オーストラリア
Phone: +61 2 8090 1000
Fax: +61 2 8090 1001
EMail: aidan.williams@audinate.com
URI: http://www.audinate.com/
Kevin Gross AVA Networks Boulder, CO US
ケビングロスAVAネットワークボルダー、CO US
EMail: kevin.gross@avanw.com
URI: http://www.avanw.com/
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT The Netherlands
レイヴァンブランデンブルクTNO Brassersplein 2デルフト2612CTオランダ
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Hans Stokking TNO Brassersplein 2 Delft 2612CT The Netherlands
Hans Stokking TNO Brassersplein 2デルフト2612CTオランダ
EMail: hans.stokking@tno.nl