[要約] RFC 8759は、TTMLタイムドテキストのRTPペイロードに関する仕様です。このRFCの目的は、リアルタイム通信プロトコル（RTP）を使用してTTMLタイムドテキストを伝送するための標準化を提供することです。
Internet Engineering Task Force (IETF) J. Sandford
Request for Comments: 8759 British Broadcasting Corporation
Category: Standards Track March 2020
ISSN: 2070-1721
RTP Payload for Timed Text Markup Language (TTML)
Timed Text Markup Language（TTML）のRTPペイロード
Abstract
概要
This memo describes a Real-time Transport Protocol (RTP) payload format for Timed Text Markup Language (TTML), an XML-based timed text format from W3C. This payload format is specifically targeted at streaming workflows using TTML.
このメモは、Timed Text Markup Language（TTML）のリアルタイムトランスポートプロトコル（RTP）ペイロード形式、W3CのXMLベースの時間付きテキスト形式について説明しています。このペイロード形式は、特にTTMLを使用したストリーミングワークフローを対象としています。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8759.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8759で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions and Definitions
3. Media Format Description
3.1. Relation to Other Text Payload Types
3.2. TTML2
4. Payload Format
4.1. RTP Header Usage
4.2. Payload Data
5. Payload Content Restrictions
6. Payload Processing Requirements
6.1. TTML Processor Profile
6.1.1. Feature Extension Designation
6.1.2. Processor Profile Document
6.1.3. Processor Profile Signalling
7. Payload Examples
8. Fragmentation of TTML Documents
9. Protection against Loss of Data
10. Congestion Control Considerations
11. Payload Format Parameters
11.1. Clock Rate
11.2. Session Description Protocol (SDP) Considerations
11.2.1. Examples
12. IANA Considerations
13. Security Considerations
14. Normative References
15. Informative References
Acknowledgements
Author's Address
TTML (Timed Text Markup Language) [TTML2] is a media type for describing timed text, such as closed captions and subtitles in television workflows or broadcasts, as XML. This document specifies how TTML should be mapped into an RTP stream in streaming workflows, including (but not restricted to) those described in the television-broadcast-oriented European Broadcasting Union Timed Text (EBU-TT) Part 3 [TECH3370] specification. This document does not define a media type for TTML but makes use of the existing application/ ttml+xml media type [TTML-MTPR].
TTML（Timed Text Markup Language）[TTML2]は、テレビのワークフローや放送のクローズドキャプションや字幕などのTimed TextをXMLとして記述するためのメディアタイプです。このドキュメントでは、ストリーミングワークフローでTTMLをRTPストリームにマッピングする方法を指定します。これには、テレビ放送指向の欧州放送連合の時間制限付きテキスト（EBU-TT）パート3 [TECH3370]仕様で説明されているものも含まれます（これに限定されません）。このドキュメントでは、TTMLのメディアタイプを定義していませんが、既存のapplication / ttml + xmlメディアタイプ[TTML-MTPR]を利用しています。
Unless otherwise stated, the term "document" refers to the TTML document being transmitted in the payload of the RTP packet(s).
特に明記しない限り、「ドキュメント」という用語は、RTPパケットのペイロードで送信されるTTMLドキュメントを指します。
The term "word" refers to a data word aligned to a specified number of bits in a computing sense and not to linguistic words that might appear in the transported text.
「ワード」という用語は、計算の意味で指定されたビット数に揃えられたデータワードを指し、転送されたテキストに現れる可能性のある言語ワードを指しません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Prior payload types for text are not suited to the carriage of closed captions in television workflows. "RTP Payload for Text Conversation" [RFC4103] is intended for low data rate conversation with its own session management and minimal formatting capabilities. "Definition of Events for Modem, Fax, and Text Telephony Signals" [RFC4734] deals in large parts with the control signalling of facsimile and other systems. "RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text" [RFC4396] describes the carriage of a timed text format with much more restricted formatting capabilities than TTML. The lack of an existing format for TTML or generic XML has necessitated the creation of this payload format.
以前のテキストのペイロードタイプは、テレビのワークフローでのクローズドキャプションのキャリッジには適していません。 「RTP Payload for Text Conversation」[RFC4103]は、独自のセッション管理と最小限のフォーマット機能を備えた低データレートの会話を対象としています。 「モデム、ファックス、およびテキストテレフォニー信号のイベントの定義」[RFC4734]は、ファクシミリやその他のシステムの制御シグナリングを主に扱っています。 「第3世代パートナーシッププロジェクト（3GPP）時限テキストのRTPペイロード形式」[RFC4396]では、TTMLよりも制限されたフォーマット機能を備えた時限テキスト形式のキャリッジについて説明しています。 TTMLまたは汎用XMLの既存の形式がないため、このペイロード形式を作成する必要がありました。
TTML2 (Timed Text Markup Language, Version 2) [TTML2] is an XML-based markup language for describing textual information with associated timing metadata. One of its primary use cases is the description of subtitles and closed captions. A number of profiles exist that adapt TTML2 for use in specific contexts [TTML-MTPR]. These include both file-based and streaming workflows.
TTML2（Timed Text Markup Language、Version 2）[TTML2]は、関連するタイミングメタデータとともにテキスト情報を記述するためのXMLベースのマークアップ言語です。その主な使用例の1つは、字幕の説明です。 TTML2を特定のコンテキストで使用するために適合させるプロファイルがいくつか存在します[TTML-MTPR]。これらには、ファイルベースのワークフローとストリーミングワークフローの両方が含まれます。
In addition to the required RTP headers, the payload contains a section for the TTML document being transmitted (User Data Words) and a field for the length of that data. Each RTP payload contains one or part of one TTML document.
ペイロードには、必要なRTPヘッダーに加えて、送信されるTTMLドキュメントのセクション（ユーザーデータワード）とそのデータの長さのフィールドが含まれます。各RTPペイロードには、1つのTTMLドキュメントの1つまたは一部が含まれています。
A representation of the payload format for TTML is Figure 1.
TTMLのペイロード形式を図1に示します。
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|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source (SSRC) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Data Words...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP Payload Format for TTML
図1：TTMLのRTPペイロード形式
RTP packet header fields SHALL be interpreted, as per [RFC3550], with the following specifics:
RTPパケットヘッダーフィールドは、[RFC3550]に従って次の詳細で解釈される必要があります。
Marker Bit (M): 1 bit The marker bit is set to "1" to indicate the last packet of a document. Otherwise, set to "0". Note: The first packet might also be the last.
マーカービット（M）：1ビットマーカービットは "1"に設定され、ドキュメントの最後のパケットを示します。それ以外の場合は、「0」に設定します。注：最初のパケットが最後のパケットになる場合もあります。
Timestamp: 32 bits The RTP Timestamp encodes the epoch of the TTML document in User Data Words. Further detail on its usage may be found in Section 6. The clock frequency used is dependent on the application and is specified in the media type rate parameter, as per Section 11.1. Documents spread across multiple packets MUST use the same timestamp but different consecutive Sequence Numbers. Sequential documents MUST NOT use the same timestamp. Because packets do not represent any constant duration, the timestamp cannot be used to directly infer packet loss.
タイムスタンプ：32ビットRTPタイムスタンプは、TTMLドキュメントのエポックをユーザーデータワードにエンコードします。その使用法の詳細については、セクション6を参照してください。使用されるクロック周波数は、アプリケーションに依存し、セクション11.1のように、メディアタイプレートパラメーターで指定されます。複数のパケットにまたがるドキュメントは、同じタイムスタンプを使用する必要がありますが、連続するシーケンス番号は異なります。順次ドキュメントは同じタイムスタンプを使用してはなりません。パケットは一定の持続時間を表すものではないため、タイムスタンプを使用してパケット損失を直接推測することはできません。
Reserved: 16 bits These bits are reserved for future use and MUST be set to 0x0 and ignored upon reception.
予約済み：16ビットこれらのビットは将来の使用のために予約されており、0x0に設定して受信時に無視する必要があります。
Length: 16 bits The length of User Data Words in bytes.
長さ：16ビットユーザーデータワードの長さ（バイト単位）。
User Data Words: The length of User Data Words MUST match the value specified in the Length field The User Data Words section contains the text of the whole document being transmitted or a part of the document being transmitted. Documents using character encodings where characters are not represented by a single byte MUST be serialised in big-endian order, a.k.a., network byte order. Where a document will not fit within the Path MTU, it may be fragmented across multiple packets. Further detail on fragmentation may be found in Section 8.
ユーザーデータワード：ユーザーデータワードの長さは、長さフィールドで指定された値と一致する必要があります。ユーザーデータワードセクションには、送信されるドキュメント全体または送信されるドキュメントの一部のテキストが含まれます。文字が1バイトで表されない文字エンコーディングを使用するドキュメントは、ビッグエンディアン順、つまりネットワークバイト順でシリアル化する必要があります。ドキュメントがパスMTU内に収まらない場合、複数のパケットにフラグメント化される可能性があります。断片化の詳細については、セクション8を参照してください。
TTML documents define a series of changes to text over time. TTML documents carried in User Data Words are encoded in accordance with one or more of the defined TTML profiles specified in the TTML registry [TTML-MTPR]. These profiles specify the document structure used, systems models, timing, and other considerations. TTML profiles may restrict the complexity of the changes, and operational requirements may limit the maximum duration of TTML documents by a deployment configuration. Both of these cases are out of scope of this document.
TTMLドキュメントは、時間の経過に伴うテキストへの一連の変更を定義します。ユーザーデータワードで運ばれるTTMLドキュメントは、TTMLレジストリ[TTML-MTPR]で指定された1つ以上の定義済みTTMLプロファイルに従ってエンコードされます。これらのプロファイルは、使用されるドキュメント構造、システムモデル、タイミング、およびその他の考慮事項を指定します。 TTMLプロファイルは変更の複雑さを制限する可能性があり、運用要件はデプロイメント構成によってTTMLドキュメントの最大期間を制限する可能性があります。これらのケースはどちらもこのドキュメントの範囲外です。
Documents carried over RTP MUST conform to the following profile, in addition to any others used.
RTPで伝送されるドキュメントは、使用される他のドキュメントに加えて、次のプロファイルに準拠する必要があります。
This section defines constraints on the content of TTML documents carried over RTP.
このセクションでは、RTPで伝送されるTTMLドキュメントのコンテンツに対する制約を定義します。
Multiple TTML subtitle streams MUST NOT be interleaved in a single RTP stream.
複数のTTML字幕ストリームを単一のRTPストリームにインターリーブしてはなりません（MUST NOT）。
The TTML document instance's root "tt" element in the "http://www.w3.org/ns/ttml" namespace MUST include a "timeBase" attribute in the "http://www.w3.org/ns/ttml#parameter" namespace containing the value "media".
「http://www.w3.org/ns/ttml」名前空間のTTMLドキュメントインスタンスのルート「tt」要素には、「http://www.w3.org/ns/ttmlに「timeBase」属性が含まれている必要があります。 #parameter "ネームスペース。値は" media "です。
This is equivalent to the TTML2 content profile definition document in Figure 2.
これは、図2のTTML2コンテンツプロファイル定義ドキュメントに相当します。
<?xml version="1.0" encoding="UTF-8"?>
<profile xmlns="http://www.w3.org/ns/ttml#parameter"
xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
xmlns:tt="http://www.w3.org/ns/ttml"
type="content"
designator="urn:ietf:rfc:8759#content"
combine="mostRestrictive">
<features xml:base="http://www.w3.org/ns/ttml/feature/">
<tt:metadata>
<ttm:desc>
This document is a minimal TTML2 content profile
definition document intended to express the
minimal requirements to apply when carrying TTML
over RTP.
</ttm:desc>
</tt:metadata>
<feature value="required">#timeBase-media</feature>
<feature value="prohibited">#timeBase-smpte</feature>
<feature value="prohibited">#timeBase-clock</feature>
</features>
</profile>
Figure 2: TTML2 Content Profile Definition for Documents Carried over RTP
図2：RTPで伝送されるドキュメントのTTML2コンテンツプロファイル定義
This section defines constraints on the processing of the TTML documents carried over RTP.
このセクションでは、RTPで伝送されるTTMLドキュメントの処理に関する制約を定義します。
If a TTML document is assessed to be invalid, then it MUST be discarded. This includes empty documents, i.e., those of zero length. When processing a valid document, the following requirements apply.
TTMLドキュメントが無効であると評価された場合は、破棄する必要があります。これには、空のドキュメント、つまり長さがゼロのドキュメントが含まれます。有効なドキュメントを処理する場合、次の要件が適用されます。
Each TTML document becomes active at its epoch E. E MUST be set to the RTP Timestamp in the header of the RTP packet carrying the TTML document. Computed TTML media times are offset relative to E, in accordance with Section I.2 of [TTML2].
各TTMLドキュメントは、そのエポックEでアクティブになります。Eは、TTMLドキュメントを運ぶRTPパケットのヘッダーのRTPタイムスタンプに設定する必要があります。 [TTML2]のセクションI.2に従って、計算されたTTMLメディア時間はEに対してオフセットされます。
When processing a sequence of TTML documents, where each is delivered in the same RTP stream, exactly zero or one document SHALL be considered active at each moment in the RTP time line. In the event that a document D_(n-1) with E_(n-1) is active, and document D_(n) is delivered with E_(n) where E_(n-1) < E_(n), processing of D_(n-1) MUST be stopped at E_(n) and processing of D_(n) MUST begin.
同じRTPストリームで配信される一連のTTMLドキュメントを処理する場合、RTPタイムラインの各瞬間に正確に0または1つのドキュメントがアクティブであると見なされます。 E_（n-1）を持つドキュメントD_（n-1）がアクティブで、ドキュメントD_（n）がE_（n）とともに配信される場合、E_（n-1）<E_（n）、の処理D_（n-1）はE_（n）で停止する必要があり、D_（n）の処理を開始する必要があります。
When all defined content within a document has ended, then processing of the document MAY be stopped. This can be tested by constructing the intermediate synchronic document sequence from the document, as defined by [TTML2]. If the last intermediate synchronic document in the sequence is both active and contains no region elements, then all defined content within the document has ended.
ドキュメント内のすべての定義済みコンテンツが終了すると、ドキュメントの処理が停止する場合があります。これは、[TTML2]で定義されているように、ドキュメントから中間同期ドキュメントシーケンスを作成することでテストできます。シーケンス内の最後の中間同期ドキュメントがアクティブで、リージョン要素が含まれていない場合、ドキュメント内で定義されているすべてのコンテンツが終了しています。
As described above, the RTP Timestamp does not specify the exact timing of the media in this payload format. Additionally, documents may be fragmented across multiple packets. This renders the RTCP jitter calculation unusable.
上記のように、RTPタイムスタンプは、このペイロード形式でメディアの正確なタイミングを指定しません。さらに、ドキュメントは複数のパケットにわたってフラグメント化される場合があります。これにより、RTCPジッタの計算が使用できなくなります。
This specification defines the following TTML feature extension designation:
この仕様では、次のTTML機能拡張の指定を定義しています。
"urn:ietf:rfc:8759#rtp-relative-media-time"
The namespace "urn:ietf:rfc:8759" is as defined by [RFC2648].
名前空間「urn：ietf：rfc：8759」は、[RFC2648]で定義されています。
A TTML content processor supports the "#rtp-relative-media-time" feature extension if it processes media times in accordance with the payload processing requirements specified in this document, i.e., that the epoch E is set to the time equivalent to the RTP Timestamp, as detailed above in Section 6.
このドキュメントで指定されているペイロード処理要件に従ってメディア時間を処理する場合、つまりエポックEがRTPに相当する時間に設定されている場合、TTMLコンテンツプロセッサは「＃rtp-relative-media-time」機能拡張をサポートします。セクション6で詳しく説明したタイムスタンプ。
The required syntax and semantics declared in the minimal TTML2 processor profile in Figure 3 MUST be supported by the receiver, as signified by those "feature" or "extension" elements whose "value" attribute is set to "required".
図3の最小限のTTML2プロセッサプロファイルで宣言された必要な構文とセマンティクスは、「value」属性が「required」に設定されている「feature」または「extension」要素によって示されるように、レシーバーでサポートされている必要があります。
<?xml version="1.0" encoding="UTF-8"?>
<profile xmlns="http://www.w3.org/ns/ttml#parameter"
xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
xmlns:tt="http://www.w3.org/ns/ttml"
type="processor"
designator="urn:ietf:rfc:8759#processor"
combine="mostRestrictive">
<features xml:base="http://www.w3.org/ns/ttml/feature/">
<tt:metadata>
<ttm:desc>
This document is a minimal TTML2 processor profile
definition document intended to express the
minimal requirements of a TTML processor able to
process TTML delivered over RTP according to
RFC 8759.
</ttm:desc>
</tt:metadata>
<feature value="required">#timeBase-media</feature>
<feature value="optional">
#profile-full-version-2
</feature>
</features>
<extensions xml:base="urn:ietf:rfc:8759">
<extension restricts="#timeBase-media" value="required">
#rtp-relative-media-time
</extension>
</extensions>
</profile>
Figure 3: TTML2 Processor Profile Definition for Processing Documents Carried over RTP
図3：RTPを介して実行されるドキュメントを処理するためのTTML2プロセッサプロファイル定義
Note that this requirement does not imply that the receiver needs to support either TTML1 or TTML2 profile processing, i.e., the TTML2 "#profile-full-version-2" feature or any of its dependent features.
この要件は、レシーバーがTTML1またはTTML2プロファイル処理、つまりTTML2 "＃profile-full-version-2"機能またはその依存機能のいずれかをサポートする必要があることを意味しないことに注意してください。
The "codecs" media type parameter MUST specify at least one processor profile. Short codes for TTML profiles are registered at [TTML-MTPR]. The processor profiles specified in "codecs" MUST be compatible with the processor profile specified in this document. Where multiple options exist in "codecs" for possible processor profile combinations (i.e., separated by "|" operator), every permitted option MUST be compatible with the processor profile specified in this document. Where processor profiles (other than the one specified in this document) are advertised in the "codecs" parameter, the requirements of the processor profile specified in this document MAY be signalled, additionally using the "+" operator with its registered short code.
「コーデック」メディアタイプパラメータは、少なくとも1つのプロセッサプロファイルを指定する必要があります。 TTMLプロファイルの短いコードは[TTML-MTPR]に登録されています。 「コーデック」で指定されたプロセッサプロファイルは、このドキュメントで指定されたプロセッサプロファイルと互換性がある必要があります。可能なプロセッサプロファイルの組み合わせ（つまり、「|」演算子で区切られている）の「コーデック」に複数のオプションが存在する場合、許可されるすべてのオプションは、このドキュメントで指定されているプロセッサプロファイルと互換性がある必要があります。 （このドキュメントで指定されているもの以外の）プロセッサプロファイルが "codecs"パラメータでアドバタイズされる場合、このドキュメントで指定されているプロセッサプロファイルの要件は、追加の "+"演算子とその登録されたショートコードを使用して通知できます。
A processor profile (X) is compatible with the processor profile specified here (P) if X includes all the features and extensions in P (identified by their character content) and the "value" attribute of each is, at least, as restrictive as the "value" attribute of the feature or extension in P that has the same character content. The term "restrictive" here is as defined in Section 6 of [TTML2].
プロセッサプロファイル（X）は、XがPのすべての機能と拡張（文字内容で識別される）を含み、それぞれの「値」属性が少なくとも次のように制限されている場合、ここで指定されたプロセッサプロファイル（P）と互換性があります。同じ文字内容を持つ、Pの機能または拡張機能の「値」属性。ここでの「制限的」という用語は、[TTML2]のセクション6で定義されています。
Figure 4 is an example of a valid TTML document that may be carried using the payload format described in this document.
図4は、このドキュメントで説明されているペイロード形式を使用して伝送できる有効なTTMLドキュメントの例です。
<?xml version="1.0" encoding="UTF-8"?>
<tt xml:lang="en"
xmlns="http://www.w3.org/ns/ttml"
xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
xmlns:tts="http://www.w3.org/ns/ttml#styling"
ttp:timeBase="media"
>
<head>
<metadata>
<ttm:title>Timed Text TTML Example</ttm:title>
<ttm:copyright>The Authors (c) 2006</ttm:copyright>
</metadata>
<styling>
<!--
s1 specifies default color, font, and text alignment
-->
<style xml:id="s1"
tts:color="white"
tts:fontFamily="proportionalSansSerif"
tts:fontSize="100%"
tts:textAlign="center"
/>
</styling>
<layout>
<region xml:id="subtitleArea"
style="s1"
tts:extent="78% 11%"
tts:padding="1% 5%"
tts:backgroundColor="black"
tts:displayAlign="after"
/>
</layout>
</head>
<body region="subtitleArea">
<div>
<p xml:id="subtitle1" dur="5.0s" style="s1">
How truly delightful!
</p>
</div>
</body>
</tt>
Figure 4: Example TTML Document
図4：TTMLドキュメントの例
Many of the use cases for TTML are low bit-rate with RTP packets expected to fit within the Path MTU. However, some documents may exceed the Path MTU. In these cases, they may be split between multiple packets. Where fragmentation is used, the following guidelines MUST be followed:
TTMLの使用例の多くは、ビットレートが低く、RTPパケットはパスMTU内に収まることが期待されています。ただし、一部のドキュメントはパスMTUを超える場合があります。これらの場合、それらは複数のパケット間で分割される場合があります。断片化が使用される場合、次のガイドラインに従う必要があります。
* It is RECOMMENDED that documents be fragmented as seldom as possible, i.e., the least possible number of fragments is created out of a document.
* ドキュメントは可能な限りフラグメント化しないことをお勧めします。つまり、ドキュメントから作成されるフラグメントの数は最小限に抑えられます。
* Text strings MUST split at character boundaries. This enables decoding of partial documents. As a consequence, document fragmentation requires knowledge of the UTF-8/UTF-16 encoding formats to determine character boundaries.
* テキスト文字列は文字の境界で分割する必要があります。これにより、部分的なドキュメントのデコードが可能になります。その結果、ドキュメントの断片化には、文字の境界を決定するために、UTF-8 / UTF-16エンコード形式の知識が必要です。
* Document fragments SHOULD be protected against packet losses. More information can be found in Section 9.
* 文書の断片は、パケット損失から保護されるべきです（SHOULD）。詳細については、セクション9を参照してください。
When a document spans more than one RTP packet, the entire document is obtained by concatenating User Data Words from each consecutive contributing packet in ascending order of Sequence Number.
ドキュメントが複数のRTPパケットにまたがる場合、連続する各寄与パケットからのユーザーデータワードをシーケンス番号の昇順で連結することにより、ドキュメント全体が取得されます。
As described in Section 6, only zero or one TTML document may be active at any point in time. As such, there MUST only be one document transmitted for a given RTP Timestamp. Furthermore, as stated in Section 4.1, the marker bit MUST be set for a packet containing the last fragment of a document. A packet following one where the marker bit is set contains the first fragment of a new document. The first fragment might also be the last.
セクション6で説明したように、どの時点でもアクティブにできるTTMLドキュメントは0または1つだけです。そのため、特定のRTPタイムスタンプに対して送信されるドキュメントは1つだけでなければなりません。さらに、セクション4.1で述べたように、マーカービットはドキュメントの最後のフラグメントを含むパケットに設定する必要があります。マーカービットが設定されているパケットに続くパケットには、新しいドキュメントの最初のフラグメントが含まれています。最初のフラグメントは最後のフラグメントである場合もあります。
Consideration must be devoted to keeping loss of documents due to packet loss within acceptable limits. What is deemed acceptable limits is dependent on the TTML profile(s) used and use case, among other things. As such, specific limits are outside the scope of this document.
パケット損失によるドキュメントの損失を許容範囲内に保つことに専念する必要があります。許容される制限と見なされるのは、とりわけ、使用されるTTMLプロファイルと使用例によって異なります。そのため、特定の制限はこのドキュメントの範囲外です。
Documents MAY be sent without additional protection if end-to-end network conditions guarantee that document loss will be within acceptable limits under all anticipated load conditions. Where such guarantees cannot be provided, implementations MUST use a mechanism to protect against packet loss. Potential mechanisms include Forward Error Correction (FEC) [RFC5109], retransmission [RFC4588], duplication [ST2022-7], or an equivalent technique.
予想されるすべての負荷条件でドキュメントの損失が許容範囲内になることがエンドツーエンドのネットワーク条件で保証されている場合、ドキュメントは追加の保護なしで送信される場合があります。そのような保証を提供できない場合、実装はパケット損失から保護するメカニズムを使用しなければなりません（MUST）。潜在的なメカニズムには、Forward Error Correction（FEC）[RFC5109]、再送信[RFC4588]、複製[ST2022-7]、または同等の手法が含まれます。
Congestion control for RTP SHALL be used in accordance with [RFC3550] and with any applicable RTP profile, e.g., [RFC3551]. "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions" [RFC8083] is an update to "RTP: A Transport Protocol for Real-time Applications" [RFC3550], which defines criteria for when one is required to stop sending RTP packet streams. Applications implementing this standard MUST comply with [RFC8083], with particular attention paid to Section 4.4 on Media Usability. [RFC8085] provides additional information on the best practices for applying congestion control to UDP streams.
RTPの輻輳制御は、[RFC3550]および適用可能なRTPプロファイル（[RFC3551]など）に従って使用する必要があります（SHALL）。 「マルチメディア輻輳制御：ユニキャストRTPセッションのサーキットブレーカー」[RFC8083]は、「RTP：リアルタイムアプリケーション用のトランスポートプロトコル」[RFC3550]のアップデートで、RTPパケットストリームの送信を停止する必要がある場合の基準を定義しています。この標準を実装するアプリケーションは、[RFC8083]に準拠する必要があり、特にメディアのユーザビリティに関するセクション4.4に注意を払う必要があります。 [RFC8085]は、輻輳制御をUDPストリームに適用するためのベストプラクティスに関する追加情報を提供します。
This RTP payload format is identified using the existing application/ ttml+xml media type as registered with IANA [IANA] and defined in [TTML-MTPR].
このRTPペイロード形式は、IANA [IANA]に登録され、[TTML-MTPR]で定義されている既存のapplication / ttml + xmlメディアタイプを使用して識別されます。
The default clock rate for TTML over RTP is 1000 Hz. The clock rate SHOULD be included in any advertisements of the RTP stream where possible. This parameter has not been added to the media type definition as it is not applicable to TTML usage other than within RTP streams. In other contexts, timing is defined within the TTML document.
RTP over RTPのデフォルトのクロックレートは1000 Hzです。クロックレートは、可能な場合、RTPストリームのアドバタイズに含める必要があります（SHOULD）。このパラメーターは、RTPストリーム内以外のTTMLの使用には適用されないため、メディアタイプ定義には追加されていません。他のコンテキストでは、タイミングはTTMLドキュメント内で定義されます。
When choosing a clock rate, implementers should consider what other media their TTML streams may be used in conjunction with (e.g., video or audio). In these situations, it is RECOMMENDED that streams use the same clock source and clock rate as the related media. As TTML streams may be aperiodic, implementers should also consider the frequency range over which they expect packets to be sent and the temporal resolution required.
クロックレートを選択する場合、実装者はTTMLストリームを他のどのメディアと組み合わせて使用できるか（ビデオやオーディオなど）を考慮する必要があります。これらの状況では、ストリームが関連するメディアと同じクロックソースとクロックレートを使用することが推奨されます。 TTMLストリームは非周期的である可能性があるため、実装者は、パケットが送信されることを期待する周波数範囲と必要な時間分解能も考慮する必要があります。
The mapping of the application/ttml+xml media type and its parameters [TTML-MTPR] SHALL be done according to Section 3 of [RFC4855].
application / ttml + xmlメディアタイプとそのパラメーターのマッピング[TTML-MTPR]は、[RFC4855]のセクション3に従って行う必要があります。
* The type name "application" goes in SDP "m=" as the media name.
* タイプ名「アプリケーション」は、メディア名としてSDP「m =」に入ります。
* The media subtype "ttml+xml" goes in SDP "a=rtpmap" as the encoding name.
* メディアサブタイプ「ttml + xml」は、エンコーディング名としてSDP「a = rtpmap」に入ります。
* The clock rate also goes in "a=rtpmap" as the clock rate.
* クロックレートは、クロックレートとして「a = rtpmap」にも含まれます。
Additional format-specific parameters, as described in the media type specification, SHALL be included in the SDP file in "a=fmtp" as a semicolon-separated list of "parameter=value" pairs, as described in [RFC4855]. The "codecs" parameter MUST be included in the "a=fmtp" line of the SDP file. Specific requirements for the "codecs" parameter are included in Section 6.1.3.
メディアタイプの仕様で説明されているように、[RFC4855]で説明されているように、「a = fmtp」のSDPファイルに「parameter = value」ペアのセミコロン区切りのリストとして追加のフォーマット固有のパラメータを含める必要があります。 「コーデック」パラメータは、SDPファイルの「a = fmtp」行に含める必要があります。 「コーデック」パラメータの特定の要件は、セクション6.1.3に含まれています。
A sample SDP mapping is presented in Figure 5.
SDPマッピングの例を図5に示します。
m=application 30000 RTP/AVP 112
a=rtpmap:112 ttml+xml/90000
a=fmtp:112 charset=utf-8;codecs=im2t
Figure 5: Example SDP Mapping
図5：SDPマッピングの例
In this example, a dynamic payload type 112 is used. The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line after the subtype. The codecs parameter defined in the "a=fmtp" line indicates that the TTML data conforms to Internet Media and Captions (IMSC) 1.1 Text profile [TTML-IMSC1.1].
この例では、動的ペイロードタイプ112が使用されています。 90 kHz RTPタイムスタンプレートは、サブタイプの後の "a = rtpmap"行で指定されます。 「a = fmtp」行で定義されているコーデックパラメータは、TTMLデータがインターネットメディアおよびキャプション（IMSC）1.1テキストプロファイル[TTML-IMSC1.1]に準拠していることを示しています。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile, such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals (like confidentiality, integrity, and source authenticity) for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this Security Considerations section discusses the security impacting properties of the payload format itself.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]およびRTP / AVP [RFC3551]、RTP / AVPF [RFC4585]、RTP / SAVPなどの該当するすべてのRTPプロファイルで説明されているセキュリティの考慮事項に従います。 [RFC3711]、またはRTP / SAVPF [RFC5124]。ただし、「RTPプロトコルフレームワークのセキュリティ保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]が説明しているように、基本的なセキュリティ目標を達成するために使用されるソリューションを議論または義務付けることは、RTPペイロード形式の責任ではありません（一般にRTPの機密性、整合性、およびソースの信頼性）。この責任は、アプリケーションでRTPを使用するすべての人にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは、「RTPセッションを保護するためのオプション」[RFC7201]にあります。アプリケーションは、1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。このセキュリティの考慮事項セクションの残りの部分では、ペイロード形式自体のセキュリティに影響を与えるプロパティについて説明します。
To avoid potential buffer overflow attacks, receivers should take care to validate that the User Data Words in the RTP payload are of the appropriate length (using the Length field).
潜在的なバッファオーバーフロー攻撃を回避するために、受信者はRTPペイロードのユーザーデータワードが適切な長さであることを検証するように注意する必要があります（長さフィールドを使用）。
This payload format places no specific restrictions on the size of TTML documents that may be transmitted. As such, malicious implementations could be used to perform denial-of-service (DoS) attacks. [RFC4732] provides more information on DoS attacks and describes some mitigation strategies. Implementers should take into consideration that the size and frequency of documents transmitted using this format may vary over time. As such, sender implementations should avoid producing streams that exhibit DoS-like behaviour, and receivers should avoid false identification of a legitimate stream as malicious.
このペイロード形式では、送信できるTTMLドキュメントのサイズに特定の制限はありません。そのため、悪意のある実装がサービス拒否（DoS）攻撃の実行に使用される可能性があります。 [RFC4732]は、DoS攻撃に関する詳細情報を提供し、いくつかの緩和戦略について説明します。実装者は、このフォーマットを使用して送信されるドキュメントのサイズと頻度が時間とともに変化する可能性があることを考慮する必要があります。そのため、送信側の実装では、DoSのような動作を示すストリームの生成を回避し、受信側では、正当なストリームが悪意のあるストリームであると誤って識別することを回避する必要があります。
As with other XML types and as noted in Section 10 of "XML Media Types" [RFC7303], repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail.
他のXMLタイプと同様に、「XMLメディアタイプ」[RFC7303]のセクション10に記載されているように、悪意を持って作成されたXMLエンティティを繰り返し拡張すると大量のメモリが消費され、制約のある環境のXMLプロセッサで障害が発生する可能性があります。
In addition, because of the extensibility features for TTML and of XML in general, it is possible that "application/ttml+xml" may describe content that has security implications beyond those described here. However, TTML does not provide for any sort of active or executable content, and if the processor follows only the normative semantics of the published specification, this content will be outside TTML namespaces and may be ignored. Only in the case where the processor recognizes and processes the additional content or where further processing of that content is dispatched to other processors would security issues potentially arise. And in that case, they would fall outside the domain of this RTP payload format and the application/ttml+xml registration document.
さらに、TTMLとXMLの拡張機能のため、一般的に、「application / ttml + xml」は、ここで説明されているものを超えてセキュリティに影響を与えるコンテンツを記述している可能性があります。ただし、TTMLはいかなる種類のアクティブまたは実行可能なコンテンツも提供しません。プロセッサーが公開された仕様の規範的なセマンティクスのみに従う場合、このコンテンツはTTML名前空間の外にあり、無視される可能性があります。プロセッサが追加コンテンツを認識して処理する場合、またはそのコンテンツのさらなる処理が他のプロセッサにディスパッチされる場合にのみ、セキュリティの問題が発生する可能性があります。そしてその場合、それらはこのRTPペイロード形式とapplication / ttml + xml登録ドキュメントのドメインの外に落ちます。
Although not prohibited, there are no expectations that XML signatures or encryption would normally be employed.
禁止されていませんが、XML署名または暗号化が通常使用されることは期待されていません。
Further information related to privacy and security at a document level can be found in Appendix P of [TTML2].
ドキュメントレベルでのプライバシーとセキュリティに関する詳細情報は、[TTML2]の付録Pにあります。
[IANA] IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[IANA] IANA、「メディアタイプ」、<https://www.iana.org/assignments/media-types>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <https://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G。、およびP. Jones、「RTP Payload for Text Conversation」、RFC 4103、DOI 10.17487 / RFC4103、2005年6月、<https://www.rfc-editor.org/info/rfc4103>。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <https://www.rfc-editor.org/info/rfc4855>.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<https://www.rfc-editor.org/info/rfc4855>。
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <https://www.rfc-editor.org/info/rfc7303>.
[RFC7303] Thompson、H。およびC. Lilley、「XML Media Types」、RFC 7303、DOI 10.17487 / RFC7303、2014年7月、<https://www.rfc-editor.org/info/rfc7303>。
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.
[RFC8083] Perkins、C。およびV. Singh、「Multimedia Congestion Control：Circuit Breakers for Unicast RTP Sessions」、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<https://www.rfc-editor.org/info / rfc8083>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https://www.rfc-editor.org / info / rfc8085>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[TECH3370] European Broadcasting Union, "EBU-TT, Part 3, Live Subtitling Applications: System Model and Content Profile for Authoring and Contribution", EBU-TT Part 3, Tech 3370, May 2017, <https://tech.ebu.ch/publications/tech3370>.
[TECH3370]欧州放送連合、「EBU-TT、パート3、ライブ字幕アプリケーション：オーサリングとコントリビューションのためのシステムモデルとコンテンツプロファイル」、EBU-TTパート3、Tech 3370、2017年5月、<https：//tech.ebu .ch / publications / tech3370>。
[TTML-MTPR] Adams, G., Ed. and M. Dolan, Ed., "TTML Media Type Definition and Profile Registry", W3C Working Group Note, April 2019, <https://www.w3.org/TR/ttml-profile-registry/>.
[TTML-MTPR]アダムス、G、エド。およびM. Dolan、Ed。、「TTML Media Type Definition and Profile Registry」、W3Cワーキンググループノート、2019年4月、<https://www.w3.org/TR/ttml-profile-registry/>。
[TTML2] Adams, G., Ed. and C. Concolato, Ed., "Timed Text Markup Language 2 (TTML2)", W3C Recommendation REC-ttml2-20181108, November 2018, <https://www.w3.org/TR/ttml2/>.
[TTML2]アダムス、G、エド。およびC. Concolato、編、「Timed Text Markup Language 2（TTML2）」、W3C勧告REC-ttml2-20181108、2018年11月、<https://www.w3.org/TR/ttml2/>。
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, DOI 10.17487/RFC2648, August 1999, <https://www.rfc-editor.org/info/rfc2648>.
[RFC2648] Moats、R。、「IETFドキュメントのURN名前空間」、RFC 2648、DOI 10.17487 / RFC2648、1999年8月、<https://www.rfc-editor.org/info/rfc2648>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<https：//www.rfc-editor。 org / info / rfc3551>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<https://www.rfc-editor.org/info/rfc3711>。
[RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text", RFC 4396, DOI 10.17487/RFC4396, February 2006, <https://www.rfc-editor.org/info/rfc4396>.
[RFC4396] Rey、J。およびY. Matsui、「RTP Payload Format for 3rd Generation Partnership Project（3GPP）Timed Text」、RFC 4396、DOI 10.17487 / RFC4396、2006年2月、<https：//www.rfc-editor。 org / info / rfc4396>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J。、レオン、D。、宮崎、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<https：/ /www.rfc-editor.org/info/rfc4588>。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, <https://www.rfc-editor.org/info/rfc4732>.
[RFC4732] Handley、M.、Ed。、Rescorla、E.、Ed。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、DOI 10.17487 / RFC4732、2006年12月、<https：// www。 rfc-editor.org/info/rfc4732>。
[RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, DOI 10.17487/RFC4734, December 2006, <https://www.rfc-editor.org/info/rfc4734>.
[RFC4734] Schulzrinne、H。およびT. Taylor、「Definition of Events for Modem、Fax、and Text Telephony Signals」、RFC 4734、DOI 10.17487 / RFC4734、2006年12月、<https://www.rfc-editor.org / info / rfc4734>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A。、編、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<https://www.rfc-editor.org/info/rfc5109> 。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<https ：//www.rfc-editor.org/info/rfc5124>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<https://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <https://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<https：//www.rfc- editor.org/info/rfc7202>。
[ST2022-7] SMPTE, "Seamless Protection Switching of RTP Datagrams", ST 2022-7:2019, DOI 10.5594/SMPTE.ST2022-7.2019, May 2019, <https://ieeexplore.ieee.org/document/8716822>.
[ST2022-7] SMPTE、「RTPデータグラムのシームレス保護切り替え」、ST 2022-7：2019、DOI 10.5594 / SMPTE.ST2022-7.2019、2019年5月、<https://ieeexplore.ieee.org/document/8716822> 。
[TTML-IMSC1.1] Lemieux, P., Ed., "TTML Profiles for Internet Media Subtitles and Captions 1.1", W3C Recommendation REC-ttml-imsc1.1-20181108, November 2018, <https://www.w3.org/TR/ttml-imsc1.1/>.
[TTML-IMSC1.1] Lemieux、P。、編、「インターネットメディアの字幕とキャプション1.1のTTMLプロファイル」、W3C勧告REC-ttml-imsc1.1-20181108、2018年11月、<https：//www.w3 .org / TR / ttml-imsc1.1 />。
Acknowledgements
謝辞
Thanks to Nigel Megitt, James Gruessing, Robert Wadge, Andrew Bonney, James Weaver, John Fletcher, Frans de Jong, and Willem Vermost for their valuable feedback throughout the development of this document. Thanks to the W3C Timed Text Working Group and EBU Timed Text Working Group for their substantial efforts in developing the timed text format this payload format is intended to carry.
このドキュメントの開発を通じて貴重なフィードバックを提供してくれたNigel Megitt、James Gruessing、Robert Wadge、Andrew Bonney、James Weaver、John Fletcher、Frans de Jong、およびWillem Vermostに感謝します。 W3CのTimed Text Working GroupとEBU Timed Text Working Groupのおかげで、このペイロード形式で使用することを目的としたTimed Text形式の開発に多大な労力を費やしてくれました。
Author's Address
著者のアドレス
James Sandford British Broadcasting Corporation Dock House, MediaCityUK Salford United Kingdom
James Sandford British Broadcasting Corporation Dock House、MediaCityUKサルフォードイギリス
Phone: +44 30304 09549
Email: james.sandford@bbc.co.uk