draft-ietf-payload-rtp-ttml-05.txt   draft-ietf-payload-rtp-ttml-06.txt 
A/V Transport Payloads Workgroup J. Sandford A/V Transport Payloads Workgroup J. Sandford
Internet-Draft British Broadcasting Corporation Internet-Draft British Broadcasting Corporation
Intended status: Standards Track 29 October 2019 Intended status: Standards Track 19 November 2019
Expires: 1 May 2020 Expires: 22 May 2020
RTP Payload for TTML Timed Text RTP Payload for TTML Timed Text
draft-ietf-payload-rtp-ttml-05 draft-ietf-payload-rtp-ttml-06
Abstract Abstract
This memo describes a Real-time Transport Protocol (RTP) payload This memo describes a Real-time Transport Protocol (RTP) payload
format for TTML, an XML based timed text format for live and file format for TTML, an XML based timed text format for live and file
based workflows from W3C. This payload format is specifically based workflows from W3C. This payload format is specifically
targeted at live workflows using TTML. targeted at live workflows using TTML.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 May 2020. This Internet-Draft will expire on 22 May 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 27
6.1. TTML Processor profile . . . . . . . . . . . . . . . . . 7 6.1. TTML Processor profile . . . . . . . . . . . . . . . . . 7
6.1.1. Feature extension designation . . . . . . . . . . . . 7 6.1.1. Feature extension designation . . . . . . . . . . . . 7
6.1.2. Processor profile document . . . . . . . . . . . . . 7 6.1.2. Processor profile document . . . . . . . . . . . . . 7
6.1.3. Processor profile signalling . . . . . . . . . . . . 8 6.1.3. Processor profile signalling . . . . . . . . . . . . 8
7. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9 7. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9
8. Fragmentation of TTML Documents . . . . . . . . . . . . . . . 11 8. Fragmentation of TTML Documents . . . . . . . . . . . . . . . 11
9. Protection Against Loss of Data . . . . . . . . . . . . . . . 11 9. Protection Against Loss of Data . . . . . . . . . . . . . . . 11
10. Congestion Control Considerations . . . . . . . . . . . . . . 12 10. Congestion Control Considerations . . . . . . . . . . . . . . 12
11. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 11. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12
11.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 12 11.2. SDP Considerations . . . . . . . . . . . . . . . . . . . 12
11.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13 11.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13
11.3. Offer/Answer Considerations . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
15. Normative References . . . . . . . . . . . . . . . . . . . . 15 15. Normative References . . . . . . . . . . . . . . . . . . . . 14
16. Informative References . . . . . . . . . . . . . . . . . . . 16 16. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 17 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
TTML (Timed Text Markup Language)[TTML2] is a media type for TTML (Timed Text Markup Language)[TTML2] is a media type for
describing timed text such as closed captions and subtitles in describing timed text such as closed captions and subtitles in
television workflows or broadcasts as XML. This document specifies television workflows or broadcasts as XML. This document specifies
how TTML should be mapped into an RTP stream in live workflows how TTML should be mapped into an RTP stream in live workflows
skipping to change at page 4, line 26 skipping to change at page 4, line 26
| User Data Words... | User Data Words...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP Payload Format for TTML Figure 1: RTP Payload Format for TTML
4.1. RTP Header Usage 4.1. RTP Header Usage
RTP packet header fields SHALL be interpreted as per RFC 3550 RTP packet header fields SHALL be interpreted as per RFC 3550
[RFC3550], with the following specifics: [RFC3550], with the following specifics:
Marker Bit (M): 1 bit The Marker Bit is set to "1" to indicate the Marker Bit (M): 1 bit
last packet of a document. Otherwise set to "0". Note: The first The Marker Bit is set to "1" to indicate the last packet of a
packet might also be the last. document. Otherwise set to "0". Note: The first packet might
also be the last.
Timestamp: 32 bits The RTP Timestamp encodes the epoch of the TTML Timestamp: 32 bits
document in User Data Words. Further detail on its usage may be The RTP Timestamp encodes the epoch of the TTML document in User
found in Section 6. The clock frequency used is dependent on the 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 application and is specified in the media type rate parameter as
per Section 11.1. Documents spread across multiple packets MUST per Section 11.1. Documents spread across multiple packets MUST
use the same timestamp but different consecutive Sequence Numbers. use the same timestamp but different consecutive Sequence Numbers.
Sequential documents MUST NOT use the same timestamp. Because Sequential documents MUST NOT use the same timestamp. Because
packets do not represent any constant duration, the timestamp packets do not represent any constant duration, the timestamp
cannot be used to directly infer packet loss. cannot be used to directly infer packet loss.
Reserved: 16 bits These bits are reserved for future use and MUST be Reserved: 16 bits
set to 0x0 and ignored at receive. These bits are reserved for future use and MUST be set to 0x0 and
ignored at receive.
Length: 16 bits The length of User Data Words in bytes. Length: 16 bits
The length of User Data Words in bytes.
User Data Words: The length of User Data Words MUST match the User Data Words: The length of User Data Words MUST match the
value specified in the Length field User value specified in the Length field
Data Words contains the text of the whole document being User Data Words contains the text of the whole document being
transmitted or a part of the document being transmitted. transmitted or a part of the document being transmitted.
Documents using character encodings where characters are not Documents using character encodings where characters are not
represented by a single byte MUST be serialized in big endian represented by a single byte MUST be serialized in big endian
order, a.k.a. network byte order. Where a document will not fit order, a.k.a. network byte order. Where a document will not fit
within the MTU, it may be fragmented across multiple packets. within the Path MTU, it may be fragmented across multiple packets.
Further detail on fragmentation may be found in Section 8. Further detail on fragmentation may be found in Section 8.
4.2. Payload Data 4.2. Payload Data
TTML documents define a series of changes to text over time. TTML TTML documents define a series of changes to text over time. TTML
documents carried in User Data Words are encoded in accordance with documents carried in User Data Words are encoded in accordance with
one or more of the defined TTML profiles specified in the TTML one or more of the defined TTML profiles specified in the TTML
registry [TTML-MTPR]. These profiles specify the document structure registry [TTML-MTPR]. These profiles specify the document structure
used, systems models, timing, and other considerations. TTML used, systems models, timing, and other considerations. TTML
profiles may restrict the complexity of the changes and operational profiles may restrict the complexity of the changes and operational
skipping to change at page 11, line 8 skipping to change at page 11, line 8
</p> </p>
</div> </div>
</body> </body>
</tt> </tt>
Figure 4: Example TTML Document Figure 4: Example TTML Document
8. Fragmentation of TTML Documents 8. Fragmentation of TTML Documents
Many of the use cases for TTML are low bit-rate with RTP packets Many of the use cases for TTML are low bit-rate with RTP packets
expected to fit within the MTU. However, some documents may exceed expected to fit within the Path MTU. However, some documents may
the MTU. In these cases, they may be split between multiple packets. exceed the Path MTU. In these cases, they may be split between
Where fragmentation is used, the following guidelines MUST be multiple packets. Where fragmentation is used, the following
followed: guidelines MUST be followed:
* It is RECOMMENDED that documents be fragmented as seldom as * It is RECOMMENDED that documents be fragmented as seldom as
possible, i.e., the least possible number of fragments is created possible, i.e., the least possible number of fragments is created
out of a document. out of a document.
* Text strings MUST split at character boundaries. This enables * Text strings MUST split at character boundaries. This enables
decoding of partial documents. As a consequence, document decoding of partial documents. As a consequence, document
fragmentation requires knowledge of the UTF-8/UTF-16 encoding fragmentation requires knowledge of the UTF-8/UTF-16 encoding
formats to determine character boundaries. formats to determine character boundaries.
skipping to change at page 11, line 49 skipping to change at page 11, line 49
Consideration must be devoted to keeping loss of documents due to Consideration must be devoted to keeping loss of documents due to
packet loss within acceptable limits. What is deemed acceptable packet loss within acceptable limits. What is deemed acceptable
limits is dependant on the TTML profile(s) used and use case among limits is dependant on the TTML profile(s) used and use case among
other things. As such, specific limits are outside the scope of this other things. As such, specific limits are outside the scope of this
document. document.
Documents MAY be sent without additional protection if end-to-end Documents MAY be sent without additional protection if end-to-end
network conditions allow document loss to be within acceptable limits network conditions allow document loss to be within acceptable limits
in all anticipated load conditions. Where such guarantees cannot be in all anticipated load conditions. Where such guarantees cannot be
provided, implementations MUST use a mechanism to protect against provided, implementations MUST use a mechanism to protect against
packet loss. Potential mechanisms include FEC [RFC2733], packet loss. Potential mechanisms include FEC [RFC5109],
retransmission [RFC4588], duplication [ST2022-7], or an equivalent retransmission [RFC4588], duplication [ST2022-7], or an equivalent
technique. technique.
10. Congestion Control Considerations 10. Congestion Control Considerations
Congestion control for RTP SHALL be used in accordance with Congestion control for RTP SHALL be used in accordance with
[RFC3550], and with any applicable RTP profile: e.g., [RFC3551]. [RFC3550], and with any applicable RTP profile: e.g., [RFC3551].
Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines
criteria for when one is required to stop sending RTP Packet Streams. criteria for when one is required to stop sending RTP Packet Streams.
Applications implementing this standard MUST comply with [RFC8083] Applications implementing this standard MUST comply with [RFC8083]
skipping to change at page 12, line 34 skipping to change at page 12, line 34
The default clock rate for TTML over RTP is 1000Hz. The clock rate The default clock rate for TTML over RTP is 1000Hz. The clock rate
SHOULD be included in any advertisements of the RTP stream where SHOULD be included in any advertisements of the RTP stream where
possible. This parameter has not been added to the media type possible. This parameter has not been added to the media type
definition as it is not applicable to TTML usage other than within definition as it is not applicable to TTML usage other than within
RTP streams. In other contexts, timing is defined within the TTML RTP streams. In other contexts, timing is defined within the TTML
document. document.
When choosing a clock rate, implementers should consider what other When choosing a clock rate, implementers should consider what other
media their TTML streams may be used in conjunction with (e.g. video media their TTML streams may be used in conjunction with (e.g. video
or audio). In these situations, it is RECOMMENDED that streams use or audio). In these situations, it is RECOMMENDED that streams use
the same clock source and Clock Rate as the related media. As TTML the same clock source and clock rate as the related media. As TTML
streams may be aperiodic, implementers should also consider the streams may be aperiodic, implementers should also consider the
frequency range over which they expect packets to be sent and the frequency range over which they expect packets to be sent and the
temporal resolution required. temporal resolution required.
11.2. Mapping to SDP 11.2. SDP Considerations
The mapping of the application/ttml+xml media type and its parameters The mapping of the application/ttml+xml media type and its parameters
[TTML-MTPR] SHALL be done according to Section 3 of [RFC4855]. [TTML-MTPR] SHALL be done according to Section 3 of [RFC4855].
* The type name "application" goes in SDP "m=" as the media name. * The type name "application" goes in SDP "m=" as the media name.
* The media subtype "ttml+xml" goes in SDP "a=rtpmap" as the * The media subtype "ttml+xml" goes in SDP "a=rtpmap" as the
encoding name, encoding name,
* The clock rate also goes in "a=rtpmap" as the clock rate. * The clock rate also goes in "a=rtpmap" as the clock rate.
skipping to change at page 13, line 24 skipping to change at page 13, line 24
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=im1t
Figure 5: Example SDP mapping Figure 5: Example SDP mapping
In this example, a dynamic payload type 112 is used. The 90 kHz RTP 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. timestamp rate is specified in the "a=rtpmap" line after the subtype.
The codecs parameter defined in the "a=fmtp" line indicates that the The codecs parameter defined in the "a=fmtp" line indicates that the
TTML data conforms to IMSC 1 Text profile. TTML data conforms to IMSC 1 Text profile.
11.3. Offer/Answer Considerations
All parameters are declarative.
12. IANA Considerations 12. IANA Considerations
No IANA action. No IANA action.
13. Security Considerations 13. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550] , and in any applicable RTP profile such as specification [RFC3550] , and in any applicable RTP profile such as
RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/
skipping to change at page 16, line 4 skipping to change at page 15, line 48
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TECH3370] European Broadcasting Union, "TECH 3370 - EBU-TT PART 3: [TECH3370] European Broadcasting Union, "TECH 3370 - EBU-TT PART 3:
LIVE CONTRIBUTION", May 2017, LIVE CONTRIBUTION", May 2017,
<https://tech.ebu.ch/publications/tech3370>. <https://tech.ebu.ch/publications/tech3370>.
[TTML-MTPR] [TTML-MTPR]
W3C - Timed Text Working Group, "TTML Media Type W3C - Timed Text Working Group, "TTML Media Type
Definition and Profile Registry", January 2017, Definition and Profile Registry", April 2019,
<https://www.w3.org/TR/ttml-profile-registry/>. <https://www.w3.org/TR/ttml-profile-registry/>.
[TTML2] W3C - Timed Text Working Group, "Timed Text Markup [TTML2] W3C - Timed Text Working Group, "Timed Text Markup
Language 2 (TTML2)", November 2018, Language 2 (TTML2)", November 2018,
<https://www.w3.org/TR/ttml2/>. <https://www.w3.org/TR/ttml2/>.
16. Informative References 16. Informative References
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
DOI 10.17487/RFC2648, August 1999, DOI 10.17487/RFC2648, August 1999,
<https://www.rfc-editor.org/info/rfc2648>. <https://www.rfc-editor.org/info/rfc2648>.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733,
DOI 10.17487/RFC2733, December 1999,
<https://www.rfc-editor.org/info/rfc2733>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>. <https://www.rfc-editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
skipping to change at page 17, line 10 skipping to change at page 16, line 51
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732, Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006, DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>. <https://www.rfc-editor.org/info/rfc4732>.
[RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for [RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for
Modem, Fax, and Text Telephony Signals", RFC 4734, Modem, Fax, and Text Telephony Signals", RFC 4734,
DOI 10.17487/RFC4734, December 2006, DOI 10.17487/RFC4734, December 2006,
<https://www.rfc-editor.org/info/rfc4734>. <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>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>. 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>. <https://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
 End of changes. 21 change blocks. 
36 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/