draft-ietf-payload-rtp-ttml-01.txt   draft-ietf-payload-rtp-ttml-02.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: Informational April 25, 2019 Intended status: Standards Track June 11, 2019
Expires: October 27, 2019 Expires: December 13, 2019
RTP Payload for TTML Timed Text RTP Payload for TTML Timed Text
draft-ietf-payload-rtp-ttml-01 draft-ietf-payload-rtp-ttml-02
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 October 27, 2019. This Internet-Draft will expire on December 13, 2019.
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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions, Definitions, and Abbreviations . . . . . . . . . 2 2. Conventions, Definitions, and Abbreviations . . . . . . . . . 2
3. Media Format Description . . . . . . . . . . . . . . . . . . 3 3. Media Format Description . . . . . . . . . . . . . . . . . . 3
3.1. Relation to Other Text Payload Types . . . . . . . . . . 3 3.1. Relation to Other Text Payload Types . . . . . . . . . . 3
3.2. TTML2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 3 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 4 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 4
4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. TTML Profile for RTP Carriage . . . . . . . . . . . . 5 4.2.1. TTML Profile for RTP Carriage . . . . . . . . . . . . 5
5. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 8 5. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9
6. Congestion Control Considerations . . . . . . . . . . . . . . 9 6. Congestion Control Considerations . . . . . . . . . . . . . . 10
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 10 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11
7.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 10 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 11
7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11 7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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 (also known as describing timed text such as closed captions (also known as
subtitles) in television workflows or broadcasts as XML. This subtitles) in television workflows or broadcasts as XML. This
document specifies how TTML should be mapped into an RTP stream in document specifies how TTML should be mapped into an RTP stream in
live workflows including, but not restricted to, those described in live workflows including, but not restricted to, those described in
the television broadcast oriented EBU-TT Part 3[TECH3370] the television broadcast oriented EBU-TT Part 3[TECH3370]
specification. This document does not define a media type for TTML specification. This document does not define a media type for TTML
skipping to change at page 3, line 27 skipping to change at page 3, line 27
[RFC4103] is intended for low data rate conversation with its own [RFC4103] is intended for low data rate conversation with its own
session management and minimal formatting capabilities. RFC 4734 session management and minimal formatting capabilities. RFC 4734
Events for Modem, Fax, and Text Telephony Signals [RFC4734] deals in Events for Modem, Fax, and Text Telephony Signals [RFC4734] deals in
large parts with the control signalling of facsimile and other large parts with the control signalling of facsimile and other
systems. RFC 4396 for 3rd Generation Partnership Project (3GPP) systems. RFC 4396 for 3rd Generation Partnership Project (3GPP)
Timed Text [RFC4396] describes the carriage of a timed text format Timed Text [RFC4396] describes the carriage of a timed text format
with much more restricted formatting capabilities than TTML. The with much more restricted formatting capabilities than TTML. The
lack of an existing format for TTML or generic XML has necessitated lack of an existing format for TTML or generic XML has necessitated
the creation of this payload format. the creation of this payload format.
3.2. TTML2
TTML2 (Timed Text Markup Language, Version 2)[TTML2] is an XML-based
markup language for describing textual information with associated
timing metadata. One of its primary use cases is the description of
subtitles and closed captions. A number of profiles exist that adapt
TTML2 for use in specific contexts [TTML-MTPR]. These include both
file based and streaming workflows.
4. Payload Format 4. Payload Format
In addition to the required RTP headers, the payload contains a In addition to the required RTP headers, the payload contains a
section for the TTML document being transmitted (User Data Words), section for the TTML document being transmitted (User Data Words),
and a field for the Length of that data. Each RTP payload contains and a field for the Length of that data. Each RTP payload contains
one or part of one TTML document. one or part of one TTML document.
A representation of the payload format for TTML is Figure 1. A representation of the payload format for TTML is Figure 1.
0 1 2 3 0 1 2 3
skipping to change at page 5, line 48 skipping to change at page 6, line 32
<feature value="prohibited">#timeBase-clock</feature> <feature value="prohibited">#timeBase-clock</feature>
</features> </features>
</profile> </profile>
4.2.1.2. Payload processing requirements 4.2.1.2. Payload processing requirements
If the TTML document payload is assessed to be invalid then it MUST If the TTML document payload is assessed to be invalid then it MUST
be discarded. When processing a valid document, the following be discarded. When processing a valid document, the following
requirements apply. requirements apply.
The epoch E relative to which computed TTML media times are offset Each TTML document becomes active at the epoch E. E MUST be set to
MUST be set to the RTP Timestamp in the header of the RTP packet in the RTP Timestamp in the header of the RTP packet carrying the TTML
which the TTML document instance is carried. document. Computed TTML media times are offset relative to E.
When processing a sequence of TTML documents each delivered in the When processing a sequence of TTML documents each delivered in the
same RTP stream, exactly zero or one document SHALL be considered same RTP stream, exactly zero or one document SHALL be considered
active at each moment in the RTP time line. active at each moment in the RTP time line. In the event that a
document D_(n-1) with E_(n-1) is active, and document D_(n) is
Each TTML document becomes active at E. In the event that a document delivered with E_(n) where E_(n-1) < E_(n), processing of D_(n-1)
D_(n-1) with E_(n-1) is active, and document D_(n) is delivered with MUST be stopped at E_(n) and processing of D_(n) MUST begin.
E_(n) where E_(n-1) < E_(n), processing of D_(n-1) MUST be stopped at
E_(n) and processing of D_(n) MUST begin.
When all defined content within a document has ended then processing When all defined content within a document has ended then processing
of the document MAY be stopped. This can be tested by constructing of the document MAY be stopped. This can be tested by constructing
the intermediate synchronic document sequence from the document, as the intermediate synchronic document sequence from the document, as
defined by TTML2. If the last intermediate synchronic document in defined by TTML2. If the last intermediate synchronic document in
the sequence is both active and contains no region elements, then all the sequence is both active and contains no region elements, then all
defined content within the document has ended. defined content within the document has ended.
4.2.1.2.1. TTML Processor profile 4.2.1.2.1. TTML Processor profile
skipping to change at page 7, line 38 skipping to change at page 8, line 38
</extensions> </extensions>
</profile> </profile>
Note that this requirement does not imply that the receiver needs to Note that this requirement does not imply that the receiver needs to
support either TTML1 or TTML2 profile processing, i.e. the TTML2 support either TTML1 or TTML2 profile processing, i.e. the TTML2
"#profile-full-version-2" feature or any of its dependent features. "#profile-full-version-2" feature or any of its dependent features.
4.2.1.2.1.3. Processor profile signalling 4.2.1.2.1.3. Processor profile signalling
The "codecs" media type parameter MUST specify at least one processor The "codecs" media type parameter MUST specify at least one processor
profile. The processor profiles specified in "codecs" MUST be profile. Short codes for TTML profiles are registered at
[TTML-MTPR]. The processor profiles specified in "codecs" MUST be
compatible with the processor profile specified in this document. compatible with the processor profile specified in this document.
Where multiple options exist in "codecs" for possible processor Where multiple options exist in "codecs" for possible processor
profile combinations (i.e. separated by "|" operator), every profile combinations (i.e. separated by "|" operator), every
permitted option MUST be compatible with the processor profile permitted option MUST be compatible with the processor profile
specified in this document. Where processor profiles other than the specified in this document. Where processor profiles other than the
one specified in this document are advertised in the "codecs" one specified in this document are advertised in the "codecs"
parameter, the requirements of the processor profile specified in parameter, the requirements of the processor profile specified in
this document MAY be signalled additionally using the "+" operator this document MAY be signalled additionally using the "+" operator
with its registered short code. with its registered short code.
A processor profile (X) is compatible with the processor profile in A processor profile (X) is compatible with the processor profile in
this document (P) if X includes all the features and extensions in P, this document (P) if X includes all the features and extensions in P,
identified by their character content, and the "value" attribute of identified by their character content, and the "value" attribute of
each is at least as restrictive as the "value" attribute of the each is at least as restrictive as the "value" attribute of the
feature or extension in P that has the same character content. The feature or extension in P that has the same character content. The
term "restrictive" here is as defined in [TTML2] Section 6. term "restrictive" here is as defined in [TTML2] Section 6.
Note that short codes for TTML profiles are registered at
[TTML-MTPR].
4.2.1.2.2. EBU-TT Live considerations
EBU-TT Live is a profile of TTML intended to support live
contribution of TTML documents as a stream independently of the
carriage mechanism. When EBU-TT Live documents are carried in an RTP
stream, or when the TTML documents being transferred over RTP use
EBU-TT Live semantics, the following considerations apply:
E is considered to be the Availability Time as defined by EBU-TT
Live. It is an error if two documents are delivered such that
E_(n-1) < E_(n) and the "ebuttp:sequenceNumber" of E_(n-1) is greater
than the "ebuttp:sequenceNumber" of E_(n). Every EBU-TT Live
document in a single RTP stream MUST have a
"ebuttp:sequenceIdentifier" with the same value.
5. Payload Examples 5. Payload Examples
The following is an example of a valid TTML document that may be The following is an example of a valid TTML document that may be
carried using the payload format described in this document: carried using the payload format described in this document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<tt xml:lang="en" <tt xml:lang="en"
xmlns="http://www.w3.org/ns/ttml" xmlns="http://www.w3.org/ns/ttml"
xmlns:ttm="http://www.w3.org/ns/ttml#metadata" xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter" xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
skipping to change at page 10, line 8 skipping to change at page 11, line 8
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[RFC3550], and with any applicable RTP profile: e.g., RFC 3551 [RFC3550], and with any applicable RTP profile: e.g., RFC 3551
[RFC3551]. An additional requirement if best-effort service is being [RFC3551]. An additional requirement if best-effort service is being
used is users of this payload format MUST monitor packet loss to used is users of this payload format MUST monitor packet loss to
ensure that the packet loss rate is within acceptable parameters. ensure that the packet loss rate is within acceptable parameters.
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
and applications implementing this standard MUST comply with it. RFC and applications implementing this standard MUST comply with it. RFC
8085 [RFC8083] provides additional information on the best practices 8085 [RFC8085] provides additional information on the best practices
for applying congestion control to UDP streams. for applying congestion control to UDP streams.
7. Payload Format Parameters 7. Payload Format Parameters
This RTP payload format is identified using the existing application/ This RTP payload format is identified using the existing application/
ttml+xml media type as registered with IANA [IANA] and defined in ttml+xml media type as registered with IANA [IANA] and defined in
[TTML-MTPR]. [TTML-MTPR].
7.1. Clock Rate 7.1. Clock Rate
skipping to change at page 12, line 31 skipping to change at page 13, line 31
processors, would security issues potentially arise. And in that processors, would security issues potentially arise. And in that
case, they would fall outside the domain of this RTP payload format case, they would fall outside the domain of this RTP payload format
and the application/ttml+xml registration document. and the application/ttml+xml registration document.
Although not prohibited, there are no expectations that XML Although not prohibited, there are no expectations that XML
signatures or encryption would normally be employed. signatures or encryption would normally be employed.
Further information related to privacy and security at a document Further information related to privacy and security at a document
level can be found in TTML 2 Appendix P [TTML2]. level can be found in TTML 2 Appendix P [TTML2].
10. References 10. Acknowledgements
10.1. Normative References Thanks to Nigel Megitt, James Gruessing, Robert Wadge, Andrew Bonney,
James Weaver, John Fletcher, Frans De jong, and Villem Vermost for
their valuable feedback throughout the development of this draft.
Thanks to the W3C Timed Text Working Group and EBU Timed Text working
group for their substantial efforts in developing the timed text
formats this payload format is intended to carry.
11. References
11.1. Normative References
[IANA] "IANA - Media Types - Application", February 2019, [IANA] "IANA - Media Types - Application", February 2019,
<https://www.iana.org/assignments/media-types/ <https://www.iana.org/assignments/media-types/
media-types.xhtml#application>. media-types.xhtml#application>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
<https://www.rfc-editor.org/info/rfc4103>. <https://www.rfc-editor.org/info/rfc4103>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>. <https://www.rfc-editor.org/info/rfc4855>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014, DOI 10.17487/RFC7303, July 2014,
<https://www.rfc-editor.org/info/rfc7303>. <https://www.rfc-editor.org/info/rfc7303>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", RFC 8083, Circuit Breakers for Unicast RTP Sessions", RFC 8083,
DOI 10.17487/RFC8083, March 2017, DOI 10.17487/RFC8083, March 2017,
<https://www.rfc-editor.org/info/rfc8083>. <https://www.rfc-editor.org/info/rfc8083>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[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] [TECH3370]
"TECH 3370 - EBU-TT PART 3: LIVE CONTRIBUTION", May 2017, "TECH 3370 - EBU-TT PART 3: LIVE CONTRIBUTION", May 2017,
<https://tech.ebu.ch/publications/tech3370>. <https://tech.ebu.ch/publications/tech3370>.
[TTML-MTPR] [TTML-MTPR]
"TTML Media Type Definition and Profile Registry", January "TTML Media Type Definition and Profile Registry", January
2017, <https://www.w3.org/TR/ttml-profile-registry/>. 2017, <https://www.w3.org/TR/ttml-profile-registry/>.
[TTML2] "Timed Text Markup Language 2 (TTML2)", November 2018, [TTML2] "Timed Text Markup Language 2 (TTML2)", November 2018,
<https://www.w3.org/TR/ttml2/>. <https://www.w3.org/TR/ttml2/>.
10.2. Informative References 11.2. 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>.
[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>.
skipping to change at page 14, line 21 skipping to change at page 15, line 26
Generation Partnership Project (3GPP) Timed Text", Generation Partnership Project (3GPP) Timed Text",
RFC 4396, DOI 10.17487/RFC4396, February 2006, RFC 4396, DOI 10.17487/RFC4396, February 2006,
<https://www.rfc-editor.org/info/rfc4396>. <https://www.rfc-editor.org/info/rfc4396>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>.
[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>.
[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
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<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
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <https://www.rfc-editor.org/info/rfc7202>. 2014, <https://www.rfc-editor.org/info/rfc7202>.
Appendix A. RFC Editor Considerations Appendix A. RFC Editor Considerations
Note to RFC Editor: This section may be removed after carrying out Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section. all the instructions of this section.
The namespace "urn:ietf:rfc:XXXX" is to be replaced with the The namespace "urn:ietf:rfc:XXXX" is to be replaced with the
namespace for this document once it has received an RFC number. namespace for this document once it has received an RFC number.
Appendix B. Acknowledgements
Thanks to Nigel Megitt, James Gruessing, Robert Wadge, Andrew Bonney,
James Weaver, John Fletcher, Frans De jong, and Villem Vermost for
their valuable feedback throughout the development of this draft.
Thanks to the W3C Timed Text Working Group and EBU Timed Text working
group for their substantial efforts in developing the timed text
formats this payload format is intended to carry.
Author's Address Author's Address
James Sandford James Sandford
British Broadcasting Corporation British Broadcasting Corporation
Dock House, MediaCityUK Dock House, MediaCityUK
Salford Salford
United Kingdom United Kingdom
Phone: +44 30304 09549 Phone: +44 30304 09549
Email: james.sandford@bbc.co.uk Email: james.sandford@bbc.co.uk
 End of changes. 21 change blocks. 
69 lines changed or deleted 64 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/