rfc8759xml2.original.xml | rfc8759.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="utf-8"?> | <?xml version='1.0' encoding='utf-8'?> | |||
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process | <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> | |||
or - mmark.miek.nl" --> | ||||
<rfc version="3" ipr="trust200902" docName="draft-ietf-payload-rtp-ttml-06" subm | <rfc number="8759" xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="t | |||
issionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/ | rust200902" | |||
XInclude" consensus="true"> | docName="draft-ietf-payload-rtp-ttml-06" submissionType="IETF" | |||
category="std" xml:lang="en" consensus="true" obsoletes="" | ||||
updates="" sortRefs="true" symRefs="true" tocInclude="true"> | ||||
<front> | <front> | |||
<title abbrev="RTP Payload for TTML Timed Text">RTP Payload for TTML Timed Text< | ||||
/title><seriesInfo value="draft-ietf-payload-rtp-ttml-06" stream="IETF" status=" | <title abbrev="RTP Payload for TTML Timed Text">RTP Payload for Timed Text Marku | |||
standard" name="Internet-Draft"></seriesInfo> | p Language (TTML)</title> | |||
<author initials="J." surname="Sandford" fullname="James Sandford"><organization | <seriesInfo name="RFC" value="8759"/> | |||
>British Broadcasting Corporation</organization><address><postal><street>Dock Ho | ||||
use, MediaCityUK</street> | <author initials="J." surname="Sandford" fullname="James Sandford"> | |||
<organization>British Broadcasting Corporation</organization> | ||||
<address> | ||||
<postal> | ||||
<street>Dock House, MediaCityUK</street> | ||||
<city>Salford</city> | <city>Salford</city> | |||
<country>United Kingdom</country> | <country>United Kingdom</country> | |||
</postal><phone>+44 30304 09549</phone> | </postal> | |||
<phone>+44 30304 09549</phone> | ||||
<email>james.sandford@bbc.co.uk</email> | <email>james.sandford@bbc.co.uk</email> | |||
</address></author> | </address> | |||
<date year="2019" month="November" day="19"></date> | </author> | |||
<date month="March" year="2020"/> | ||||
<area>Internet</area> | <area>Internet</area> | |||
<workgroup>A/V Transport Payloads Workgroup</workgroup> | <workgroup>A/V Transport Payloads Workgroup</workgroup> | |||
<keyword>subtitles</keyword> | ||||
<keyword>captions</keyword> | ||||
<keyword>imsc</keyword> | ||||
<keyword>media</keyword> | ||||
<keyword>streaming</keyword> | ||||
<keyword>sdp</keyword> | ||||
<keyword>xml</keyword> | ||||
<abstract> | <abstract> | |||
<t>This memo describes a Real-time Transport Protocol (RTP) payload format for T | <t>This memo describes a Real-time Transport Protocol (RTP) payload format for | |||
TML, an XML based timed text format for live and file based workflows from W3C. | Timed Text Markup Language (TTML), an XML-based timed text format from | |||
This payload format is specifically targeted at live workflows using TTML.</t> | W3C. This payload format is specifically targeted at streaming workflows using | |||
TTML.</t> | ||||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section anchor="introduction"> | ||||
<section anchor="introduction"><name>Introduction</name> | <name>Introduction</name> | |||
<t>TTML (Timed Text Markup Language)<xref target="TTML2"></xref> is a media type | <t>TTML (Timed Text Markup Language) <xref target="TTML2"/> is a media type for | |||
for describing timed text such as closed captions and subtitles in television w | describing timed text, such as closed captions and subtitles in television | |||
orkflows or broadcasts as XML. This document specifies how TTML should be mapped | workflows or broadcasts, as XML. This document specifies how TTML should be | |||
into an RTP stream in live workflows including, but not restricted to, those de | mapped into an RTP stream in streaming workflows, including (but not restricted | |||
scribed in the television broadcast oriented EBU-TT Part 3<xref target="TECH3370 | to) those described in the television-broadcast-oriented European Broadcasting | |||
"></xref> specification. This document does not define a media type for TTML but | Union Timed Text (EBU-TT) Part 3 <xref | |||
makes use of the existing application/ttml+xml media type <xref target="TTML-MT | target="TECH3370"/> specification. This document does not define a media type | |||
PR"></xref>.</t> | for TTML but makes use of the existing application/ttml+xml media type <xref | |||
</section> | target="TTML-MTPR"/>.</t> | |||
<section anchor="conventions-definitions-and-abbreviations"><name>Conventions, D | ||||
efinitions, and Abbreviations</name> | ||||
<t>Unless otherwise stated, the term "document" refers to the TTML doc | ||||
ument being transmitted in the payload of the RTP packet(s).</t> | ||||
<t>The term "word" refers to a data word aligned to a specified number | ||||
of bits in a computing sense and not to refer to linguistic words that might ap | ||||
pear in the transported text.</t> | ||||
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>& | ||||
quot;, "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", &q | ||||
uot;<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bc | ||||
p14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp | ||||
14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp | ||||
14>OPTIONAL</bcp14>" in this document are to be interpreted as described in | ||||
BCP14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and o | ||||
nly when, they appear in all capitals, as shown here.</t> | ||||
</section> | </section> | |||
<section anchor="media-format-description"><name>Media Format Description</name> | <section anchor="conventions-definitions-and-abbreviations"> | |||
<name>Conventions and Definitions</name> | ||||
<t>Unless otherwise stated, the term "document" refers to the TTML document | ||||
being transmitted in the payload of the RTP packet(s).</t> | ||||
<t>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.</t> | ||||
<section anchor="relation-to-other-text-payload-types"><name>Relation to Other T | <t> | |||
ext Payload Types</name> | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
<t>Prior payload types for text are not suited to the carriage of closed caption | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | |||
s in Television Workflows. RFC 4103 for Text Conversation <xref target="RFC4103" | NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | |||
></xref> is intended for low data rate conversation with its own session managem | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
ent and minimal formatting capabilities. RFC 4734 Events for Modem, Fax, and Tex | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are | |||
t Telephony Signals <xref target="RFC4734"></xref> deals in large parts with the | to be interpreted as | |||
control signalling of facsimile and other systems. RFC 4396 for 3rd Generation | described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> | |||
Partnership Project (3GPP) Timed Text <xref target="RFC4396"></xref> describes t | when, and only when, they appear in all capitals, as shown here. | |||
he carriage of a timed text format with much more restricted formatting capabili | </t> | |||
ties than TTML. The lack of an existing format for TTML or generic XML has neces | ||||
sitated the creation of this payload format.</t> | ||||
</section> | </section> | |||
<section anchor="ttml2"><name>TTML2</name> | <section anchor="media-format-description"> | |||
<t>TTML2 (Timed Text Markup Language, Version 2)<xref target="TTML2"></xref> is | <name>Media Format Description</name> | |||
an XML-based markup language for describing textual information with associated | <section anchor="relation-to-other-text-payload-types"> | |||
timing metadata. One of its primary use cases is the description of subtitles an | <name>Relation to Other Text Payload Types</name> | |||
d closed captions. A number of profiles exist that adapt TTML2 for use in specif | <t>Prior payload types for text are not suited to the carriage of closed | |||
ic contexts <xref target="TTML-MTPR"></xref>. These include both file based and | captions in television workflows. "RTP Payload for Text Conversation" <xref | |||
streaming workflows.</t> | target="RFC4103"/> is intended for low data rate conversation with its own | |||
session management and minimal formatting capabilities. "Definition of Events fo | ||||
r | ||||
Modem, Fax, and Text Telephony Signals" <xref target="RFC4734"/> deals in large | ||||
parts with the control signalling of facsimile and other systems. "RTP Payload F | ||||
ormat for | ||||
3rd Generation Partnership Project (3GPP) Timed Text" <xref | ||||
target="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.</t> | ||||
</section> | ||||
<section anchor="ttml2"> | ||||
<name>TTML2</name> | ||||
<t>TTML2 (Timed Text Markup Language, Version 2) <xref target="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 <xref target="TTML-MTPR"/>. These include both file-based | ||||
and streaming workflows.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="payload-format"><name>Payload Format</name> | <section anchor="payload-format"> | |||
<t>In addition to the required RTP headers, the payload contains a section for t | <name>Payload Format</name> | |||
he TTML document being transmitted (User Data Words), and a field for the Length | <t>In addition to the required RTP headers, the payload contains a section for | |||
of that data. Each RTP payload contains one or part of one TTML document.</t> | the TTML document being transmitted (User Data Words) and a field for the | |||
<t>A representation of the payload format for TTML is <xref target="FigRTPFormat | length of that data. Each RTP payload contains one or part of one TTML | |||
"></xref>.</t> | document.</t> | |||
<figure anchor="FigRTPFormat"><name>RTP Payload Format for TTML </name> | <t>A representation of the payload format for TTML is <xref target="FigRTPFormat | |||
<sourcecode type="ascii-art"> 0 1 2 | "/>.</t> | |||
3 | ||||
<figure anchor="FigRTPFormat"> | ||||
<name>RTP Payload Format for TTML </name> | ||||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
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 | 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 | | |V=2|P|X| CC |M| PT | Sequence Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Timestamp | | | Timestamp | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Synchronization Source (SSRC) Identifier | | | Synchronization Source (SSRC) Identifier | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reserved | Length | | | Reserved | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| User Data Words... | | User Data Words... | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
</sourcecode> | ]]></artwork> | |||
</figure> | </figure> | |||
<section anchor="rtpHeaderUsage"><name>RTP Header Usage</name> | <section anchor="rtpHeaderUsage"> | |||
<t>RTP packet header fields SHALL be interpreted as per RFC 3550 <xref target="R | <name>RTP Header Usage</name> | |||
FC3550"></xref>, with the following specifics:</t> | <t>RTP packet header fields <bcp14>SHALL</bcp14> be interpreted, as per <xref | |||
target="RFC3550"/>, with the following specifics:</t> | ||||
<dl newline="true"> | <dl newline="true" spacing="normal"> | |||
<dt>Marker Bit (M): 1 bit</dt> | <dt>Marker Bit (M): 1 bit</dt> | |||
<dd><t>The Marker Bit is set to "1" to indicate the last packet of a d | <dd>The marker bit is set to "1" to indicate the last packet of a | |||
ocument. Otherwise set to "0". Note: The first packet might also be th | document. Otherwise, set to "0". Note: The first packet might also be the | |||
e last.</t> | last.</dd> | |||
</dd> | ||||
<dt>Timestamp: 32 bits</dt> | <dt>Timestamp: 32 bits</dt> | |||
<dd><t>The RTP Timestamp encodes the epoch of the TTML document in User Data Wor | <dd>The RTP Timestamp encodes the epoch of the TTML document in User Data | |||
ds. Further detail on its usage may be found in <xref target="payloadProc"></xre | Words. Further detail on its usage may be found in <xref | |||
f>. The clock frequency used is dependent on the application and is specified in | target="payloadProc"/>. The clock frequency used is dependent on the | |||
the media type rate parameter as per <xref target="rate"></xref>. Documents spr | application and is specified in the media type rate parameter, as per <xref | |||
ead across multiple packets MUST use the same timestamp but different consecutiv | target="rate"/>. Documents spread across multiple packets <bcp14>MUST</bcp14> | |||
e Sequence Numbers. Sequential documents MUST NOT use the same timestamp. Becau | use the same timestamp but different consecutive Sequence Numbers. Sequential | |||
se packets do not represent any constant duration, the timestamp cannot be used | documents <bcp14>MUST NOT</bcp14> use the same timestamp. Because packets do | |||
to directly infer packet loss.</t> | not represent any constant duration, the timestamp cannot be used to directly | |||
</dd> | infer packet loss.</dd> | |||
<dt>Reserved: 16 bits</dt> | <dt>Reserved: 16 bits</dt> | |||
<dd><t>These bits are reserved for future use and MUST be set to 0x0 and ignored | ||||
at receive.</t> | <dd>These bits are reserved for future use and <bcp14>MUST</bcp14> be set to | |||
</dd> | 0x0 and ignored upon reception.</dd> | |||
<dt>Length: 16 bits</dt> | <dt>Length: 16 bits</dt> | |||
<dd><t>The length of User Data Words in bytes.</t> | <dd>The length of User Data Words in bytes.</dd> | |||
</dd> | <dt>User Data Words: The length of User Data Words <bcp14>MUST</bcp14> match | |||
<dt>User Data Words: The length of User Data Words MUST match the value specifie | the value specified in the Length field</dt> | |||
d in the Length field</dt> | <dd>The User Data Words section contains the text of the whole document being tr | |||
<dd><t>User Data Words contains the text of the whole document being transmitted | ansmitted | |||
or a part of the document being transmitted. Documents using character encoding | or a part of the document being transmitted. Documents using character | |||
s where characters are not represented by a single byte MUST be serialized in bi | encodings where characters are not represented by a single byte | |||
g endian order, a.k.a. network byte order. Where a document will not fit within | <bcp14>MUST</bcp14> be serialised in big-endian order, a.k.a., network byte | |||
the Path MTU, it may be fragmented across multiple packets. Further detail on fr | order. Where a document will not fit within the Path MTU, it may be fragmented | |||
agmentation may be found in <xref target="fragmentation"></xref>.</t> | across multiple packets. Further detail on fragmentation may be found in <xref | |||
</dd> | target="fragmentation"/>.</dd> | |||
</dl> | </dl> | |||
</section> | </section> | |||
<section anchor="payload-data"><name>Payload Data</name> | <section anchor="payload-data"> | |||
<t>TTML documents define a series of changes to text over time. TTML documents c | <name>Payload Data</name> | |||
arried in User Data Words are encoded in accordance with one or more of the defi | <t>TTML documents define a series of changes to text over time. TTML documents | |||
ned TTML profiles specified in the TTML registry <xref target="TTML-MTPR"></xref | carried in User Data Words are encoded in accordance with one or more of the | |||
>. These profiles specify the document structure used, systems models, timing, a | defined TTML profiles specified in the TTML registry <xref | |||
nd other considerations. TTML profiles may restrict the complexity of the change | target="TTML-MTPR"/>. These profiles specify the document structure used, | |||
s and operational requirements may limit the maximum duration of TTML documents | systems models, timing, and other considerations. TTML profiles may restrict | |||
by a deployment configuration. Both of these cases are out of scope of this docu | the complexity of the changes, and operational requirements may limit the | |||
ment.</t> | maximum duration of TTML documents by a deployment configuration. Both of | |||
<t>Documents carried over RTP MUST conform to the following profile in addition | these cases are out of scope of this document.</t> | |||
to any others used.</t> | <t>Documents carried over RTP <bcp14>MUST</bcp14> conform to the following | |||
profile, in addition to any others used.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="payload-content-restrictions"><name>Payload content restriction | <section anchor="payload-content-restrictions"> | |||
s</name> | <name>Payload Content Restrictions</name> | |||
<t>This section defines constraints on the content of TTML documents carried ove | <t>This section defines constraints on the content of TTML documents carried | |||
r RTP.</t> | over RTP.</t> | |||
<t>Multiple TTML subtitle streams MUST NOT be interleaved in a single RTP stream | <t>Multiple TTML subtitle streams <bcp14>MUST NOT</bcp14> be interleaved in a | |||
.</t> | single RTP stream.</t> | |||
<t>The TTML document instance's root <tt>tt</tt> element in the <tt>http://www.w | <t>The TTML document instance's root <tt>tt</tt> element in the | |||
3.org/ns/ttml</tt> namespace MUST include a <tt>timeBase</tt> attribute in the < | <tt>http://www.w3.org/ns/ttml</tt> namespace <bcp14>MUST</bcp14> include a | |||
tt>http://www.w3.org/ns/ttml#parameter</tt> namespace containing the value <tt>m | <tt>timeBase</tt> attribute in the | |||
edia</tt>.</t> | <tt>http://www.w3.org/ns/ttml#parameter</tt> namespace containing the value | |||
<t>This is equivalent to the TTML2 content profile definition document in <xref | <tt>media</tt>.</t> | |||
target="FigContProf"></xref>.</t> | <t>This is equivalent to the TTML2 content profile definition document in | |||
<figure anchor="FigContProf"><name>TTML2 Content Profile Definition for Document | <xref target="FigContProf"/>.</t> | |||
s Carried Over RTP </name> | <figure anchor="FigContProf"> | |||
<sourcecode type="xml"><?xml version="1.0" encoding="UTF-8&quo | <name>TTML2 Content Profile Definition for Documents Carried over RTP </name> | |||
t;?> | <sourcecode type="xml"> | |||
<profile xmlns="http://www.w3.org/ns/ttml#parameter" | <![CDATA[ | |||
xmlns:ttm="http://www.w3.org/ns/ttml#metadata" | <?xml version="1.0" encoding="UTF-8"?> | |||
xmlns:tt="http://www.w3.org/ns/ttml" | <profile xmlns="http://www.w3.org/ns/ttml#parameter" | |||
type="content" | xmlns:ttm="http://www.w3.org/ns/ttml#metadata" | |||
designator="urn:ietf:rfc:XXXX#content" | xmlns:tt="http://www.w3.org/ns/ttml" | |||
combine="mostRestrictive"> | type="content" | |||
<features xml:base="http://www.w3.org/ns/ttml/feature/"> | designator="urn:ietf:rfc:8759#content" | |||
<tt:metadata> | combine="mostRestrictive"> | |||
<ttm:desc> | <features xml:base="http://www.w3.org/ns/ttml/feature/"> | |||
<tt:metadata> | ||||
<ttm:desc> | ||||
This document is a minimal TTML2 content profile | This document is a minimal TTML2 content profile | |||
definition document intended to express the | definition document intended to express the | |||
minimal requirements to apply when carrying TTML | minimal requirements to apply when carrying TTML | |||
over RTP. | over RTP. | |||
</ttm:desc> | </ttm:desc> | |||
</tt:metadata> | </tt:metadata> | |||
<feature value="required">#timeBase-media</feature> | <feature value="required">#timeBase-media</feature> | |||
; | <feature value="prohibited">#timeBase-smpte</feature> | |||
<feature value="prohibited">#timeBase-smpte</feature& | <feature value="prohibited">#timeBase-clock</feature> | |||
gt; | </features> | |||
<feature value="prohibited">#timeBase-clock</feature& | </profile> | |||
gt; | ]]> | |||
</features> | ||||
</profile> | ||||
</sourcecode> | </sourcecode> | |||
</figure> | </figure> | |||
</section> | </section> | |||
<section anchor="payloadProc"><name>Payload processing requirements</name> | <section anchor="payloadProc"> | |||
<name>Payload Processing Requirements</name> | ||||
<t>This section defines constraints on the processing of the TTML documents carr ied over RTP.</t> | <t>This section defines constraints on the processing of the TTML documents carr ied over RTP.</t> | |||
<t>If a TTML document is assessed to be invalid then it MUST be discarded. This | <t>If a TTML document is assessed to be invalid, then it <bcp14>MUST</bcp14> be | |||
includes empty documents, i.e. those of zero length. When processing a valid doc | discarded. This includes empty documents, i.e., those of zero length. When | |||
ument, the following requirements apply.</t> | processing a valid document, the following requirements apply.</t> | |||
<t>Each TTML document becomes active at its epoch E. E MUST be set to the RTP Ti | <t>Each TTML document becomes active at its epoch E. E <bcp14>MUST</bcp14> be | |||
mestamp in the header of the RTP packet carrying the TTML document. Computed TTM | set to the RTP Timestamp in the header of the RTP packet carrying the TTML | |||
L media times are offset relative to E in accordance with Section I.2 of <xref t | document. Computed TTML media times are offset relative to E, in accordance | |||
arget="TTML2"></xref>.</t> | with Section I.2 of <xref target="TTML2"/>.</t> | |||
<t>When processing a sequence of TTML documents each delivered in the same RTP s | <t>When processing a sequence of TTML documents, where each is delivered in | |||
tream, exactly zero or one document SHALL be considered active at each moment in | the same RTP stream, exactly zero or one document <bcp14>SHALL</bcp14> be | |||
the RTP time line. In the event that a document D<sub>n-1</sub> with E<sub>n-1< | considered active at each moment in the RTP time line. | |||
/sub> is active, and document D<sub>n</sub> is delivered with E<sub>n</sub> wher | In the event that a document | |||
e E<sub>n-1</sub> < E<sub>n</sub>, processing of D<sub>n-1</sub> MUST be stop | D<sub>n-1</sub> with E<sub>n-1</sub> is active, and document D<sub>n</sub> is | |||
ped at E<sub>n</sub> and processing of D<sub>n</sub> MUST begin.</t> | delivered with E<sub>n</sub> where E<sub>n-1</sub> < E<sub>n</sub>, | |||
<t>When all defined content within a document has ended then processing of the d | processing of D<sub>n-1</sub> <bcp14>MUST</bcp14> be stopped at E<sub>n</sub> | |||
ocument MAY be stopped. This can be tested by constructing the intermediate sync | and processing of D<sub>n</sub> <bcp14>MUST</bcp14> begin.</t> | |||
hronic document sequence from the document, as defined by <xref target="TTML2">< | <t>When all defined content within a document has ended, then processing of the | |||
/xref>. If the last intermediate synchronic document in the sequence is both act | document <bcp14>MAY</bcp14> be stopped. This can be tested by constructing the | |||
ive and contains no region elements, then all defined content within the documen | intermediate synchronic document sequence from the document, as defined by | |||
t has ended.</t> | <xref target="TTML2"/>. If the last intermediate synchronic document in the | |||
<t>As described above, the RTP Timestamp does not specify the exact timing of th | sequence is both active and contains no region elements, then all defined | |||
e media in this payload format. Additionally, documents may be fragmented across | content within the document has ended.</t> | |||
multiple packets. This renders the RTCP jitter calculation unusable.</t> | <t>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.</t> | ||||
<section anchor="ttml-processor-profile"><name>TTML Processor profile</name> | <section anchor="ttml-processor-profile"> | |||
<name>TTML Processor Profile</name> | ||||
<section anchor="feature-extension-designation"><name>Feature extension designat | <section anchor="feature-extension-designation"> | |||
ion</name> | <name>Feature Extension Designation</name> | |||
<t>This specification defines the following TTML feature extension designation:< /t> | <t>This specification defines the following TTML feature extension designation:< /t> | |||
<ul empty="true"> | ||||
<ul> | <li><tt>urn:ietf:rfc:8759#rtp-relative-media-time</tt></li> | |||
<li><t>urn:ietf:rfc:XXXX#rtp-relative-media-time</t> | ||||
</li> | ||||
</ul> | </ul> | |||
<t>The namespace <tt>urn:ietf:rfc:XXXX</tt> is as defined by <xref target="RFC26 | ||||
48"></xref>.</t> | <t>The namespace <tt>urn:ietf:rfc:8759</tt> is as defined by <xref target="RFC26 | |||
<t>A TTML content processor supports the <tt>#rtp-relative-media-time</tt> featu | 48"/>.</t> | |||
re extension if it processes media times in | <t>A TTML content processor supports the <tt>#rtp-relative-media-time</tt> | |||
accordance with the payload processing requirements specified in this document, | feature extension if it processes media times in accordance with the payload | |||
i.e. that the epoch E is set to the | processing requirements specified in this document, i.e., that the epoch E is | |||
time equivalent to the RTP Timestamp as detailed above in <xref target="payloadP | set to the time equivalent to the RTP Timestamp, as detailed above in <xref | |||
roc"></xref>.</t> | target="payloadProc"/>.</t> | |||
</section> | </section> | |||
<section anchor="processor-profile-document"><name>Processor profile document</n | <section anchor="processor-profile-document"> | |||
ame> | <name>Processor Profile Document</name> | |||
<t>The required syntax and semantics declared in the minimal TTML2 processor pro | <t>The required syntax and semantics declared in the minimal TTML2 processor | |||
file in <xref target="FigProcProf"></xref> MUST be supported by the receiver, | profile in <xref target="FigProcProf"/> <bcp14>MUST</bcp14> be supported by | |||
as signified by those <tt>feature</tt> or <tt>extension</tt> elements whose <tt> | the receiver, | |||
value</tt> attribute is set to <tt>required</tt>.</t> | as signified by those <tt>feature</tt> or <tt>extension</tt> elements whose | |||
<figure anchor="FigProcProf"><name>TTML2 Processor Profile Definition for Proces | <tt>value</tt> attribute is set to <tt>required</tt>.</t> | |||
sing Documents Carried Over RTP </name> | <figure anchor="FigProcProf"> | |||
<sourcecode type="xml"><?xml version="1.0" encoding="UTF-8&quo | <name>TTML2 Processor Profile Definition for Processing Documents Carried over | |||
t;?> | RTP </name> | |||
<profile xmlns="http://www.w3.org/ns/ttml#parameter" | <sourcecode type="xml"> | |||
xmlns:ttm="http://www.w3.org/ns/ttml#metadata" | <![CDATA[ | |||
xmlns:tt="http://www.w3.org/ns/ttml" | <?xml version="1.0" encoding="UTF-8"?> | |||
type="processor" | <profile xmlns="http://www.w3.org/ns/ttml#parameter" | |||
designator="urn:ietf:rfc:XXXX#processor" | xmlns:ttm="http://www.w3.org/ns/ttml#metadata" | |||
combine="mostRestrictive"> | xmlns:tt="http://www.w3.org/ns/ttml" | |||
<features xml:base="http://www.w3.org/ns/ttml/feature/"> | type="processor" | |||
<tt:metadata> | designator="urn:ietf:rfc:8759#processor" | |||
<ttm:desc> | combine="mostRestrictive"> | |||
<features xml:base="http://www.w3.org/ns/ttml/feature/"> | ||||
<tt:metadata> | ||||
<ttm:desc> | ||||
This document is a minimal TTML2 processor profile | This document is a minimal TTML2 processor profile | |||
definition document intended to express the | definition document intended to express the | |||
minimal requirements of a TTML processor able to | minimal requirements of a TTML processor able to | |||
process TTML delivered over RTP according to | process TTML delivered over RTP according to | |||
RFC XXXX. | RFC 8759. | |||
</ttm:desc> | </ttm:desc> | |||
</tt:metadata> | </tt:metadata> | |||
<feature value="required">#timeBase-media</feature> | <feature value="required">#timeBase-media</feature> | |||
; | <feature value="optional"> | |||
<feature value="optional"> | ||||
#profile-full-version-2 | #profile-full-version-2 | |||
</feature> | </feature> | |||
</features> | </features> | |||
<extensions xml:base="urn:ietf:rfc:XXXX"> | <extensions xml:base="urn:ietf:rfc:8759"> | |||
<extension restricts="#timeBase-media" value="required | <extension restricts="#timeBase-media" value="required"> | |||
"> | ||||
#rtp-relative-media-time | #rtp-relative-media-time | |||
</extension> | </extension> | |||
</extensions> | </extensions> | |||
</profile> | </profile> | |||
]]> | ||||
</sourcecode> | </sourcecode> | |||
</figure> | </figure> | |||
<t>Note that this requirement does not imply that the receiver needs to support | <t>Note that this requirement does not imply that the receiver needs to | |||
either TTML1 | support either TTML1 or TTML2 profile processing, i.e., the TTML2 | |||
or TTML2 profile processing, i.e. the TTML2 <tt>#profile-full-version-2</tt> fea | <tt>#profile-full-version-2</tt> feature or any of | |||
ture or any of | ||||
its dependent features.</t> | its dependent features.</t> | |||
</section> | </section> | |||
<section anchor="codecs"><name>Processor profile signalling</name> | <section anchor="codecs"> | |||
<t>The <tt>codecs</tt> media type parameter MUST specify at least one processor | <name>Processor Profile Signalling</name> | |||
profile. Short codes for TTML profiles are registered at <xref target="TTML-MTPR | <t>The <tt>codecs</tt> media type parameter <bcp14>MUST</bcp14> specify at | |||
"></xref>. The processor profiles specified in <tt>codecs</tt> MUST be compatibl | least one processor profile. Short codes for TTML profiles are registered at | |||
e with the processor profile specified in this document. Where multiple options | <xref target="TTML-MTPR"/>. The processor profiles specified in | |||
exist in <tt>codecs</tt> for possible processor profile combinations (i.e. separ | <tt>codecs</tt> <bcp14>MUST</bcp14> be compatible with the processor profile | |||
ated by <tt>|</tt> operator), every permitted option MUST be compatible with the | specified in this document. Where multiple options exist in <tt>codecs</tt> | |||
processor profile specified in this document. Where processor profiles other th | for possible processor profile combinations (i.e., separated by <tt>|</tt> | |||
an the one specified in this document are advertised in the <tt>codecs</tt> para | operator), every permitted option <bcp14>MUST</bcp14> be compatible with the | |||
meter, the requirements of the processor profile specified in this document MAY | processor profile specified in this document. Where processor profiles (other | |||
be signalled additionally using the <tt>+</tt> operator with its registered shor | than the one specified in this document) are advertised in the <tt>codecs</tt> | |||
t code.</t> | parameter, the requirements of the processor profile specified in this | |||
<t>A processor profile (X) is compatible with the processor profile specified he | document <bcp14>MAY</bcp14> be signalled, additionally using the <tt>+</tt> | |||
re (P) if X includes all the features and extensions in P, identified by their c | operator with its registered short code.</t> | |||
haracter content, and the <tt>value</tt> attribute of each is at least as restri | <t>A processor profile (X) is compatible with the processor profile specified | |||
ctive as the <tt>value</tt> attribute of the feature or extension in P that has | here (P) if X includes all the features and extensions in P (identified by | |||
the same character content. The term "restrictive" here is as defined | their character content) and the <tt>value</tt> attribute of each is, at least, | |||
in <xref target="TTML2"></xref> Section 6.</t> | as restrictive as the <tt>value</tt> 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 <xref target="TTML2"/>.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="payload-examples"><name>Payload Examples</name> | <section anchor="payload-examples"> | |||
<t><xref target="FigEGDoc"></xref> is an example of a valid TTML document that m | <name>Payload Examples</name> | |||
ay be carried using the payload format described in this document.</t> | <t><xref target="FigEGDoc"/> is an example of a valid TTML document that may | |||
<figure anchor="FigEGDoc"><name>Example TTML Document </name> | be carried using the payload format described in this document.</t> | |||
<sourcecode type="xml"><?xml version="1.0" encoding="UTF-8&quo | <figure anchor="FigEGDoc"> | |||
t;?> | <name>Example TTML Document</name> | |||
<tt xml:lang="en" | <sourcecode type="xml"> | |||
xmlns="http://www.w3.org/ns/ttml" | <![CDATA[ | |||
xmlns:ttm="http://www.w3.org/ns/ttml#metadata" | <?xml version="1.0" encoding="UTF-8"?> | |||
xmlns:ttp="http://www.w3.org/ns/ttml#parameter" | <tt xml:lang="en" | |||
xmlns:tts="http://www.w3.org/ns/ttml#styling" | xmlns="http://www.w3.org/ns/ttml" | |||
ttp:timeBase="media" | xmlns:ttm="http://www.w3.org/ns/ttml#metadata" | |||
> | xmlns:ttp="http://www.w3.org/ns/ttml#parameter" | |||
<head> | xmlns:tts="http://www.w3.org/ns/ttml#styling" | |||
<metadata> | ttp:timeBase="media" | |||
<ttm:title>Timed Text TTML Example</ttm:title> | > | |||
<ttm:copyright>The Authors (c) 2006</ttm:copyright> | <head> | |||
</metadata> | <metadata> | |||
<styling> | <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 | s1 specifies default color, font, and text alignment | |||
--> | --> | |||
<style xml:id="s1" | <style xml:id="s1" | |||
tts:color="white" | tts:color="white" | |||
tts:fontFamily="proportionalSansSerif" | tts:fontFamily="proportionalSansSerif" | |||
tts:fontSize="100%" | tts:fontSize="100%" | |||
tts:textAlign="center" | tts:textAlign="center" | |||
/> | /> | |||
</styling> | </styling> | |||
<layout> | <layout> | |||
<region xml:id="subtitleArea" | <region xml:id="subtitleArea" | |||
style="s1" | style="s1" | |||
tts:extent="78% 11%" | tts:extent="78% 11%" | |||
tts:padding="1% 5%" | tts:padding="1% 5%" | |||
tts:backgroundColor="black" | tts:backgroundColor="black" | |||
tts:displayAlign="after" | tts:displayAlign="after" | |||
/> | /> | |||
</layout> | </layout> | |||
</head> | </head> | |||
<body region="subtitleArea"> | <body region="subtitleArea"> | |||
<div> | <div> | |||
<p xml:id="subtitle1" dur="5.0s" style="s1&quo | <p xml:id="subtitle1" dur="5.0s" style="s1"> | |||
t;> | ||||
How truly delightful! | How truly delightful! | |||
</p> | </p> | |||
</div> | </div> | |||
</body> | </body> | |||
</tt> | </tt> | |||
]]> | ||||
</sourcecode> | </sourcecode> | |||
</figure> | </figure> | |||
</section> | </section> | |||
<section anchor="fragmentation"><name>Fragmentation of TTML Documents</name> | <section anchor="fragmentation"> | |||
<t>Many of the use cases for TTML are low bit-rate with RTP packets expected to | <name>Fragmentation of TTML Documents</name> | |||
fit within the Path MTU. However, some documents may exceed the Path MTU. In the | <t>Many of the use cases for TTML are low bit-rate with RTP packets expected | |||
se cases, they may be split between multiple packets. Where fragmentation is use | to fit within the Path MTU. However, some documents may exceed the Path | |||
d, the following guidelines MUST be followed:</t> | MTU. In these cases, they may be split between multiple packets. Where | |||
fragmentation is used, the following guidelines <bcp14>MUST</bcp14> be | ||||
followed:</t> | ||||
<ul> | <ul> | |||
<li><t>It is RECOMMENDED that documents be fragmented as seldom as possible, i.e | <li><t>It is <bcp14>RECOMMENDED</bcp14> that documents be fragmented as seldom | |||
., the least possible number of fragments is created out of a document.</t> | as possible, i.e., the least possible number of fragments is created out of a | |||
document.</t> | ||||
</li> | </li> | |||
<li><t>Text strings MUST split at character boundaries. This enables decoding of | <li><t>Text strings <bcp14>MUST</bcp14> split at character boundaries. This | |||
partial documents. As a consequence, document fragmentation requires knowledge | enables decoding of partial documents. As a consequence, document | |||
of the UTF-8/UTF-16 encoding formats to determine character boundaries.</t> | fragmentation requires knowledge of the UTF-8/UTF-16 encoding formats to | |||
determine character boundaries.</t> | ||||
</li> | </li> | |||
<li><t>Document fragments SHOULD be protected against packet losses. More inform | <li><t>Document fragments <bcp14>SHOULD</bcp14> be protected against packet | |||
ation can be found in <xref target="lossOfData"></xref></t> | losses. More information can be found in <xref target="lossOfData"/>.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>When a document spans more than one RTP packet, the entire document is obtain | <t>When a document spans more than one RTP packet, the entire document is | |||
ed by concatenating User Data Words from each consecutive contributing packet in | obtained by concatenating User Data Words from each consecutive contributing | |||
ascending order of Sequence Number.</t> | packet in ascending order of Sequence Number.</t> | |||
<t>As described in <xref target="payloadProc"></xref>, only zero or one TTML doc | <t>As described in <xref target="payloadProc"/>, only zero or one TTML | |||
ument may be active at any point in time. As such, there MUST only be one docume | document may be active at any point in time. As such, there | |||
nt transmitted for a given RTP Timestamp. Furthermore, as stated in <xref target | <bcp14>MUST</bcp14> only be one document transmitted for a given RTP | |||
="rtpHeaderUsage"></xref>, the Marker Bit MUST be set for a packet containing th | Timestamp. Furthermore, as stated in <xref target="rtpHeaderUsage"/>, the | |||
e last fragment of a document. A packet following one where the Marker Bit is se | marker bit <bcp14>MUST</bcp14> be set for a packet containing the last | |||
t contains the first fragment of a new document. The first fragment might also b | fragment of a document. A packet following one where the marker bit is set | |||
e the last.</t> | contains the first fragment of a new document. The first fragment might also | |||
be the last.</t> | ||||
</section> | </section> | |||
<section anchor="lossOfData"><name>Protection Against Loss of Data</name> | <section anchor="lossOfData"> | |||
<t>Consideration must be devoted to keeping loss of documents due to packet loss | <name>Protection against Loss of Data</name> | |||
within acceptable limits. What is deemed acceptable limits is dependant on the | <t>Consideration must be devoted to keeping loss of documents due to packet | |||
TTML profile(s) used and use case among other things. As such, specific limits a | loss within acceptable limits. What is deemed acceptable limits is dependent | |||
re outside the scope of this document.</t> | on the TTML profile(s) used and use case, among other things. As such, specific | |||
<t>Documents MAY be sent without additional protection if end-to-end network con | limits are outside the scope of this document.</t> | |||
ditions allow document loss to be within acceptable limits in all anticipated lo | <t>Documents <bcp14>MAY</bcp14> be sent without additional protection if | |||
ad conditions. Where such guarantees cannot be provided, implementations MUST us | end-to-end network conditions guarantee that document loss will be within | |||
e a mechanism to protect against packet loss. Potential mechanisms include FEC < | acceptable limits under all anticipated load conditions. Where such guarantees | |||
xref target="RFC5109"></xref>, retransmission <xref target="RFC4588"></xref>, du | cannot be provided, implementations <bcp14>MUST</bcp14> use a mechanism to | |||
plication <xref target="ST2022-7"></xref>, or an equivalent technique.</t> | protect against packet loss. Potential mechanisms include Forward Error | |||
Correction (FEC) <xref target="RFC5109"/>, retransmission <xref | ||||
target="RFC4588"/>, duplication <xref target="ST2022-7"/>, or an equivalent | ||||
technique.</t> | ||||
</section> | </section> | |||
<section anchor="congestion-control-considerations"><name>Congestion Control Con | <section anchor="congestion-control-considerations"> | |||
siderations</name> | <name>Congestion Control Considerations</name> | |||
<t>Congestion control for RTP SHALL be used in accordance with <xref target="RFC | <t>Congestion control for RTP <bcp14>SHALL</bcp14> be used in accordance with | |||
3550"></xref>, and with any applicable RTP profile: e.g., <xref target="RFC3551" | <xref target="RFC3550"/> and with any applicable RTP profile, e.g., <xref | |||
></xref>. Circuit Breakers <xref target="RFC8083"></xref> is an update to RTP <x | target="RFC3551"/>. "Multimedia Congestion Control: Circuit Breakers for | |||
ref target="RFC3550"></xref> that defines criteria for when one is required to s | Unicast RTP Sessions" <xref target="RFC8083"/> is an update to | |||
top sending RTP Packet Streams. Applications implementing this standard MUST com | "RTP: A Transport Protocol for Real-time | |||
ply with <xref target="RFC8083"></xref> with particular attention paid to Sectio | Applications" <xref target="RFC3550"/>, which defines criteria for when one is r | |||
n 4.4 on Media Usability. <xref target="RFC8085"></xref> provides additional inf | equired to | |||
ormation on the best practices for applying congestion control to UDP streams.</ | stop sending RTP packet streams. Applications implementing this standard | |||
t> | <bcp14>MUST</bcp14> comply with <xref target="RFC8083"/>, with particular | |||
attention paid to Section <xref target="RFC8083" sectionFormat="bare" section="4 | ||||
.4"/> | ||||
on Media Usability. <xref target="RFC8085"/> provides additional information | ||||
on the best practices for applying congestion control to UDP streams.</t> | ||||
</section> | </section> | |||
<section anchor="payload-format-parameters"><name>Payload Format Parameters</nam | <section anchor="payload-format-parameters"> | |||
e> | <name>Payload Format Parameters</name> | |||
<t>This RTP payload format is identified using the existing application/ttml+xml | <t>This RTP payload format is identified using the existing | |||
media type as registered with IANA <xref target="IANA"></xref> and defined in < | application/ttml+xml media type as registered with IANA <xref target="IANA"/> | |||
xref target="TTML-MTPR"></xref>.</t> | and defined in <xref target="TTML-MTPR"/>.</t> | |||
<section anchor="rate"><name>Clock Rate</name> | <section anchor="rate"> | |||
<t>The default clock rate for TTML over RTP is 1000Hz. The clock rate SHOULD be | <name>Clock Rate</name> | |||
included in any advertisements of the RTP stream where possible. This parameter | <t>The default clock rate for TTML over RTP is 1000 Hz. The clock rate | |||
has not been added to the media type definition as it is not applicable to TTML | <bcp14>SHOULD</bcp14> be included in any advertisements of the RTP stream | |||
usage other than within RTP streams. In other contexts, timing is defined within | where possible. This parameter has not been added to the media type definition | |||
the TTML document.</t> | as it is not applicable to TTML usage other than within RTP streams. In other | |||
<t>When choosing a clock rate, implementers should consider what other media the | contexts, timing is defined within the TTML document.</t> | |||
ir TTML streams may be used in conjunction with (e.g. video or audio). In these | <t>When choosing a clock rate, implementers should consider what other media | |||
situations, it is RECOMMENDED that streams use the same clock source and clock r | their TTML streams may be used in conjunction with (e.g., video or audio). In | |||
ate as the related media. As TTML streams may be aperiodic, implementers should | these situations, it is <bcp14>RECOMMENDED</bcp14> that streams use the same | |||
also consider the frequency range over which they expect packets to be sent and | clock source and clock rate as the related media. As TTML streams may be | |||
the temporal resolution required.</t> | aperiodic, implementers should also consider the frequency range over which | |||
they expect packets to be sent and the temporal resolution required.</t> | ||||
</section> | </section> | |||
<section anchor="sdp-considerations"><name>SDP Considerations</name> | <section anchor="sdp-considerations"> | |||
<t>The mapping of the application/ttml+xml media type and its parameters <xref t | <name>Session Description Protocol (SDP) Considerations</name> | |||
arget="TTML-MTPR"></xref> SHALL be done according to Section 3 of <xref target=" | <t>The mapping of the application/ttml+xml media type and its parameters <xref | |||
RFC4855"></xref>.</t> | target="TTML-MTPR"/> <bcp14>SHALL</bcp14> be done according to | |||
<xref target="RFC4855" sectionFormat="of" section="3"/>.</t> | ||||
<ul> | <ul> | |||
<li><t>The type name "application" goes in SDP "m=" as the m edia name.</t> | <li><t>The type name "application" goes in SDP "m=" as the media name.</t> | |||
</li> | </li> | |||
<li><t>The media subtype "ttml+xml" goes in SDP "a=rtpmap" a s the encoding name,</t> | <li><t>The media subtype "ttml+xml" goes in SDP "a=rtpmap" as the encoding name. </t> | |||
</li> | </li> | |||
<li><t>The clock rate also goes in "a=rtpmap" as the clock rate.</t> | <li><t>The clock rate also goes in "a=rtpmap" as the clock rate.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>Additional format specific parameters as described in the media type specific | <t>Additional format-specific parameters, as described in the media type | |||
ation SHALL be included in the SDP file in "a=fmtp" as a semicolon sep | specification, <bcp14>SHALL</bcp14> be included in the SDP file in "a=fmtp" as | |||
arated list of "parameter=value" pairs as described in <xref target="R | a semicolon-separated list of "parameter=value" pairs, as described in <xref | |||
FC4855"></xref>. The <tt>codecs</tt> parameter MUST be included in the <tt>a=fmt | target="RFC4855"/>. The <tt>codecs</tt> parameter <bcp14>MUST</bcp14> be | |||
p</tt> line of the SDP file. Specific requirements for the "codecs" pa | included in the <tt>a=fmtp</tt> line of the SDP file. Specific requirements | |||
rameter are included in <xref target="codecs"></xref>.</t> | for the "codecs" parameter are included in <xref target="codecs"/>.</t> | |||
<section anchor="examples"><name>Examples</name> | <section anchor="examples"> | |||
<t>A sample SDP mapping is presented in <xref target="FigSDP"></xref>.</t> | <name>Examples</name> | |||
<figure anchor="FigSDP"><name>Example SDP mapping </name> | <t>A sample SDP mapping is presented in <xref target="FigSDP"/>.</t> | |||
<sourcecode type="text">m=application 30000 RTP/AVP 112 | <figure anchor="FigSDP"> | |||
<name>Example SDP Mapping </name> | ||||
<sourcecode type="sdp"> | ||||
<![CDATA[ | ||||
m=application 30000 RTP/AVP 112 | ||||
a=rtpmap:112 ttml+xml/90000 | a=rtpmap:112 ttml+xml/90000 | |||
a=fmtp:112 charset=utf-8;codecs=im1t | a=fmtp:112 charset=utf-8;codecs=im2t | |||
]]> | ||||
</sourcecode> | </sourcecode> | |||
</figure> | </figure> | |||
<t>In this example, a dynamic payload type 112 is used. The 90 kHz RTP timestamp | <t>In this example, a dynamic payload type 112 is used. The 90 kHz RTP | |||
rate is specified in the "a=rtpmap" line after the subtype. | timestamp rate is specified in the "a=rtpmap" line after the subtype. | |||
The codecs parameter defined in the "a=fmtp" line indicates that the T | The codecs parameter defined in the "a=fmtp" line indicates that the TTML data | |||
TML data conforms to IMSC 1 Text profile.</t> | conforms to Internet Media and Captions (IMSC) 1.1 Text profile <xref | |||
target="TTML-IMSC1.1"/>.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="iana-considerations"><name>IANA Considerations</name> | <section anchor="iana-considerations"> | |||
<t>No IANA action.</t> | <name>IANA Considerations</name> | |||
<t>This document has no IANA actions.</t> | ||||
</section> | </section> | |||
<section anchor="security"><name>Security Considerations</name> | <section anchor="security"> | |||
<t>RTP packets using the payload format defined in this specification are subjec | <name>Security Considerations</name> | |||
t to the security considerations discussed in the RTP specification <xref target | <t>RTP packets using the payload format defined in this specification are | |||
="RFC3550"></xref> , and in any applicable RTP profile such as RTP/AVP <xref tar | subject to the security considerations discussed in the RTP specification | |||
get="RFC3551"></xref>, RTP/AVPF <xref target="RFC4585"></xref>, RTP/SAVP <xref t | <xref target="RFC3550"/> and in any applicable RTP profile, such as RTP/AVP | |||
arget="RFC3711"></xref>, or RTP/SAVPF <xref target="RFC5124"></xref>. However, | <xref target="RFC3551"/>, RTP/AVPF <xref target="RFC4585"/>, RTP/SAVP <xref | |||
as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | target="RFC3711"/>, or RTP/SAVPF <xref target="RFC5124"/>. | |||
Media Security Solution" <xref target="RFC7202"></xref> discusses, it is no | ||||
t an RTP payload format's responsibility to discuss or mandate what solutions ar | ||||
e used to meet the basic security goals like confidentiality, integrity, and sou | ||||
rce authenticity for RTP in general. This responsibility lays on anyone using R | ||||
TP in an application. They can find guidance on available security mechanisms a | ||||
nd important considerations in "Options for Securing RTP Sessions" <xr | ||||
ef target="RFC7201"></xref>. Applications SHOULD use one or more appropriate st | ||||
rong security mechanisms. The rest of this Security Considerations section disc | ||||
usses the security impacting properties of the payload format itself.</t> | ||||
<t>To avoid potential buffer overflow attacks, receivers should take care to val | ||||
idate that the User Data Words in the RTP payload are of the appropriate length | ||||
(using the Length field).</t> | ||||
<t>This payload format places no specific restrictions on the size of TTML docum | ||||
ents that may be transmitted. As such, malicious implementations could be used t | ||||
o perform denial-of-service (DoS) attacks. RFC 4732 <xref target="RFC4732"></xre | ||||
f> provides more information on DoS attacks and describes some mitigation strate | ||||
gies. Implementers should take into consideration that the size and frequency of | ||||
documents transmitted using this format may vary over time. As such, sender imp | ||||
lementations should avoid producing streams that exhibit DoS-like behaviour and | ||||
receivers should avoid false identification of a legitimate stream as malicious. | ||||
</t> | ||||
<t>As with other XML types and as noted in RFC 7303 <xref target="RFC7303"></xre | ||||
f>, XML Media Types, Section 10, repeated expansion of maliciously constructed X | ||||
ML entities can be used to consume large amounts of memory, which may cause XML | ||||
processors in constrained environments to fail.</t> | ||||
<t>In addition, because of the extensibility features for TTML and of XML in gen | ||||
eral, it is possible that "application/ttml+xml" may describe content | ||||
that has security implications beyond those described here. However, TTML does n | ||||
ot provide for any sort of active or executable content, and if the processor fo | ||||
llows 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 p | ||||
rocessor recognizes and processes the additional content, or where further proce | ||||
ssing of that content is dispatched to other processors, would security issues p | ||||
otentially arise. And in that case, they would fall outside the domain of this R | ||||
TP payload format and the application/ttml+xml registration document.</t> | ||||
<t>Although not prohibited, there are no expectations that XML signatures or enc | ||||
ryption would normally be employed.</t> | ||||
<t>Further information related to privacy and security at a document level can b | ||||
e found in TTML 2 Appendix P <xref target="TTML2"></xref>.</t> | ||||
</section> | ||||
<section anchor="acknowledgements"><name>Acknowledgements</name> | However, as | |||
<t>Thanks to Nigel Megitt, James Gruessing, Robert Wadge, Andrew Bonney, James W | "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media | |||
eaver, John Fletcher, Frans De jong, and Willem Vermost for their valuable feedb | Security Solution" <xref target="RFC7202"/> discusses, it is not an RTP | |||
ack throughout the development of this document. Thanks to the W3C Timed Text Wo | payload format's responsibility to discuss or mandate what solutions are used | |||
rking Group and EBU Timed Text working group for their substantial efforts in de | to meet the basic security goals (like confidentiality, integrity, and source | |||
veloping the timed text formats this payload format is intended to carry.</t> | 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" <xref | ||||
target="RFC7201"/>. Applications <bcp14>SHOULD</bcp14> 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.</t> | ||||
<t>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).</t> | ||||
<t>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. <xref | ||||
target="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.</t> | ||||
<t>As with other XML types and as noted in <xref target="RFC7303" | ||||
section="10" sectionFormat="of">"XML Media Types"</xref>, | ||||
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.</t> | ||||
<t>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.</t> | ||||
<t>Although not prohibited, there are no expectations that XML signatures or | ||||
encryption would normally be employed.</t> | ||||
<t>Further information related to privacy and security at a document level can | ||||
be found in Appendix P of <xref target="TTML2"/>.</t> | ||||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<references><name>Normative References</name> | <references> | |||
<name>Normative References</name> | ||||
<reference anchor="TECH3370" target="https://tech.ebu.ch/publications/tech3370"> | <reference anchor="TECH3370" target="https://tech.ebu.ch/publications/tech3370"> | |||
<front> | <front> | |||
<title>TECH 3370 - EBU-TT PART 3: LIVE CONTRIBUTION</title> | <title>EBU-TT, Part 3, Live Subtitling Applications: System Model and | |||
Content Profile for Authoring and Contribution</title> | ||||
<author> | <author> | |||
<organization>European Broadcasting Union</organization> | <organization>European Broadcasting Union</organization> | |||
</author> | </author> | |||
<date year="2017" month="May"></date> | <date year="2017" month="May"/> | |||
</front> | </front> | |||
<seriesInfo name="EBU-TT" value="Part 3"/> | ||||
<seriesInfo name="Tech" value="3370"/> | ||||
</reference> | </reference> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550. xml"/> | |||
<reference anchor="TTML2" target="https://www.w3.org/TR/ttml2/"> | <reference anchor="TTML2" target="https://www.w3.org/TR/ttml2/"> | |||
<front> | <front> | |||
<title>Timed Text Markup Language 2 (TTML2)</title> | <title>Timed Text Markup Language 2 (TTML2)</title> | |||
<author> | <author initials="G." surname="Adams" fullname="Glenn Adams" role="editor"> | |||
<organization>W3C - Timed Text Working Group</organization> | <organization/> | |||
</author> | </author> | |||
<date year="2018" month="November"></date> | <author initials="C." surname="Concolato" fullname="Cyril Concolato" role="e | |||
ditor"/> | ||||
<date year="2018" month="November"/> | ||||
</front> | </front> | |||
<seriesInfo name="W3C Recommendation" value="REC-ttml2-20181108"/> | ||||
</reference> | </reference> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8083. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8083. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4855. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4855. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4103. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4103. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7303. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7303. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085. xml"/> | |||
<reference anchor="TTML-MTPR" target="https://www.w3.org/TR/ttml-profile-registr y/"> | <reference anchor="TTML-MTPR" target="https://www.w3.org/TR/ttml-profile-registr y/"> | |||
<front> | <front> | |||
<title>TTML Media Type Definition and Profile Registry</title> | <title>TTML Media Type Definition and Profile Registry</title> | |||
<author> | <author initials="G." surname="Adams" fullname="Glenn Adams" role="editor"> | |||
<organization>W3C - Timed Text Working Group</organization> | <organization/> | |||
</author> | </author> | |||
<date year="2019" month="April"></date> | <author initials="M." surname="Dolan" fullname="Mike Dolan" role="editor"> | |||
<organization/> | ||||
</author> | ||||
<date year="2019" month="April"/> | ||||
</front> | </front> | |||
<!-- <seriesInfo name="W3C Working Group Note" | ||||
value="NOTE-ttml-profile-registry-20190411"/> --> | ||||
<refcontent>W3C Working Group Note</refcontent> | ||||
</reference> | </reference> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/> | |||
<reference anchor="IANA" target="https://www.iana.org/assignments/media-types/me dia-types.xhtml#application"> | <reference anchor="IANA" target="https://www.iana.org/assignments/media-types"> | |||
<front> | <front> | |||
<title>IANA - Media Types - Application</title> | <title>Media Types</title> | |||
<author> | <author> | |||
<organization>IANA</organization> | <organization>IANA</organization> | |||
</author> | </author> | |||
<date year="2019" month="February"></date> | ||||
</front> | </front> | |||
</reference> | </reference> | |||
</references> | </references> | |||
<references><name>Informative References</name> | <references> | |||
<name>Informative References</name> | ||||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4396. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4396. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7201. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7201. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2648. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2648. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5109. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5109. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4588. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4588. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7202. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7202. xml"/> | |||
<reference anchor="TTML-IMSC1.1" target="https://www.w3.org/TR/ttml-imsc1.1/"> | ||||
<front> | ||||
<title>TTML Profiles for Internet Media Subtitles and Captions 1.1</title> | ||||
<author initials="P." surname="Lemieux" fullname="Pierre Lemieux" role="edit | ||||
or"/> | ||||
<date year="2018" month="November"/> | ||||
</front> | ||||
<seriesInfo name="W3C Recommendation" value="REC-ttml-imsc1.1-20181108"/> | ||||
</reference> | ||||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3551. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3551. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4732. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4732. xml"/> | |||
<reference anchor="ST2022-7" target="https://ieeexplore.ieee.org/document/871682 2"> | <reference anchor="ST2022-7" target="https://ieeexplore.ieee.org/document/871682 2"> | |||
<front> | <front> | |||
<title>ST 2022-7:2019 - Seamless Protection Switching of SMPTE ST 2022 IP Da tagrams</title> | <title>Seamless Protection Switching of RTP Datagrams</title> | |||
<author> | <author> | |||
<organization>SMPTE</organization> | <organization>SMPTE</organization> | |||
</author> | </author> | |||
<date year="2019" month="November"></date> | <date year="2019" month="May"/> | |||
</front> | </front> | |||
<seriesInfo name="ST" value="2022-7:2019"/> | ||||
<seriesInfo name="DOI" value="10.5594/SMPTE.ST2022-7.2019"/> | ||||
</reference> | </reference> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711. xml"/> | |||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4734. xml"/> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4734. xml"/> | |||
</references> | </references> | |||
<section anchor="rfc-editor-considerations"><name>RFC Editor Considerations</nam | <section anchor="acknowledgements" numbered="false"> | |||
e> | <name>Acknowledgements</name> | |||
<t>Note to RFC Editor: This section may be removed after carrying out all the in | <t>Thanks to <contact fullname="Nigel Megitt"/>, <contact fullname="James | |||
structions of this section.</t> | Gruessing"/>, <contact fullname="Robert Wadge"/>, <contact fullname="Andrew | |||
<t>The namespace <tt>urn:ietf:rfc:XXXX</tt> is to be replaced with the namespace | Bonney"/>, <contact fullname="James Weaver"/>, <contact fullname="John | |||
for this document once it has received an RFC number.</t> | Fletcher"/>, <contact fullname="Frans | |||
<t><tt>RFC XXXX</tt> in <xref target="FigProcProf"></xref> is to be replaced wit | de Jong"/>, and <contact fullname="Willem Vermost"/> for their valuable | |||
h the RFC number for this document.</t> | 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.</t> | ||||
</section> | </section> | |||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 78 change blocks. | ||||
456 lines changed or deleted | 535 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |