--- 1/draft-ietf-payload-rtp-ttml-05.txt 2019-11-19 09:13:12.990718708 -0800 +++ 2/draft-ietf-payload-rtp-ttml-06.txt 2019-11-19 09:13:13.026719631 -0800 @@ -1,18 +1,18 @@ A/V Transport Payloads Workgroup J. Sandford Internet-Draft British Broadcasting Corporation -Intended status: Standards Track 29 October 2019 -Expires: 1 May 2020 +Intended status: Standards Track 19 November 2019 +Expires: 22 May 2020 RTP Payload for TTML Timed Text - draft-ietf-payload-rtp-ttml-05 + draft-ietf-payload-rtp-ttml-06 Abstract This memo describes a Real-time Transport Protocol (RTP) payload format for TTML, an XML based timed text format for live and file based workflows from W3C. This payload format is specifically targeted at live workflows using TTML. Status of This Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -60,27 +60,26 @@ 6.1. TTML Processor profile . . . . . . . . . . . . . . . . . 7 6.1.1. Feature extension designation . . . . . . . . . . . . 7 6.1.2. Processor profile document . . . . . . . . . . . . . 7 6.1.3. Processor profile signalling . . . . . . . . . . . . 8 7. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9 8. Fragmentation of TTML Documents . . . . . . . . . . . . . . . 11 9. Protection Against Loss of Data . . . . . . . . . . . . . . . 11 10. Congestion Control Considerations . . . . . . . . . . . . . . 12 11. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 11.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 12 - 11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 12 + 11.2. SDP Considerations . . . . . . . . . . . . . . . . . . . 12 11.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13 - 11.3. Offer/Answer Considerations . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 - 15. Normative References . . . . . . . . . . . . . . . . . . . . 15 + 15. Normative References . . . . . . . . . . . . . . . . . . . . 14 16. Informative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction 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 live workflows @@ -152,47 +151,52 @@ | User Data Words... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RTP Payload Format for TTML 4.1. RTP Header Usage RTP packet header fields SHALL be interpreted as per RFC 3550 [RFC3550], with the following specifics: - 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. + 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. - 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 + 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. - Reserved: 16 bits These bits are reserved for future use and MUST be - set to 0x0 and ignored at receive. + Reserved: 16 bits + 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 - value specified in the Length field User - Data Words contains the text of the whole document being + value specified in the Length field + User Data Words 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 serialized in big endian 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. 4.2. Payload Data 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 @@ -405,24 +409,24 @@

Figure 4: Example TTML Document 8. Fragmentation of TTML Documents 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 - the MTU. In these cases, they may be split between multiple packets. - Where fragmentation is used, the following guidelines MUST be - followed: + 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: * 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. @@ -446,21 +450,21 @@ Consideration must be devoted to keeping loss of documents due to packet loss within acceptable limits. What is deemed acceptable 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 document. Documents MAY be sent without additional protection if end-to-end network conditions allow document loss to be within acceptable limits in all anticipated load conditions. Where such guarantees cannot be 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 technique. 10. Congestion Control Considerations Congestion control for RTP SHALL be used in accordance with [RFC3550], and with any applicable RTP profile: e.g., [RFC3551]. Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines criteria for when one is required to stop sending RTP Packet Streams. Applications implementing this standard MUST comply with [RFC8083] @@ -479,26 +483,26 @@ The default clock rate for TTML over RTP is 1000Hz. 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. 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 + 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. -11.2. Mapping to SDP +11.2. SDP Considerations The mapping of the application/ttml+xml media type and its parameters [TTML-MTPR] SHALL be done according to Section 3 of [RFC4855]. * The type name "application" goes in SDP "m=" as the media name. * The media subtype "ttml+xml" goes in SDP "a=rtpmap" as the encoding name, * The clock rate also goes in "a=rtpmap" as the clock rate. @@ -518,24 +522,20 @@ a=rtpmap:112 ttml+xml/90000 a=fmtp:112 charset=utf-8;codecs=im1t Figure 5: Example SDP mapping 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 IMSC 1 Text profile. -11.3. Offer/Answer Considerations - - All parameters are declarative. - 12. IANA Considerations No IANA action. 13. Security Considerations 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/ @@ -640,38 +640,33 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TECH3370] European Broadcasting Union, "TECH 3370 - EBU-TT PART 3: LIVE CONTRIBUTION", May 2017, . [TTML-MTPR] W3C - Timed Text Working Group, "TTML Media Type - Definition and Profile Registry", January 2017, + Definition and Profile Registry", April 2019, . [TTML2] W3C - Timed Text Working Group, "Timed Text Markup Language 2 (TTML2)", November 2018, . 16. Informative References [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, DOI 10.17487/RFC2648, August 1999, . - [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format - for Generic Forward Error Correction", RFC 2733, - DOI 10.17487/RFC2733, December 1999, - . - [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, . [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, . @@ -694,20 +689,24 @@ [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, . [RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, DOI 10.17487/RFC4734, December 2006, . + [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error + Correction", RFC 5109, DOI 10.17487/RFC5109, December + 2007, . + [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, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP