draft-ietf-avt-rapid-rtp-sync-09.txt   draft-ietf-avt-rapid-rtp-sync-10.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Updates: RFC3550 T. Schierl Updates: 3550 (if approved) T. Schierl
(if approved) Fraunhofer HHI Intended status: Standards Track Fraunhofer HHI
Intended status: Standards Track January 8, 2010 Expires: November 6, 2010 May 5, 2010
Expires: July 12, 2010
Rapid Synchronisation of RTP Flows Rapid Synchronisation of RTP Flows
draft-ietf-avt-rapid-rtp-sync-09.txt draft-ietf-avt-rapid-rtp-sync-10.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 12, 2010.
Copyright Notice
Copyright (c) 2010 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This memo outlines how RTP sessions are synchronised, and discusses This memo outlines how RTP sessions are synchronised, and discusses
how rapidly such synchronisation can occur. We show that most RTP how rapidly such synchronisation can occur. We show that most RTP
sessions can be synchronised immediately, but that the use of video sessions can be synchronised immediately, but that the use of video
switching multipoint conference units (MCUs) or large source specific switching multipoint conference units (MCUs) or large source specific
multicast (SSM) groups can greatly increase the synchronisation multicast (SSM) groups can greatly increase the synchronisation
delay. This increase in delay can be unacceptable to some delay. This increase in delay can be unacceptable to some
applications that use layered and/or multi-description codecs. applications that use layered and/or multi-description codecs.
skipping to change at page 3, line 5 skipping to change at page 1, line 32
This memo introduces three mechanisms to reduce the synchronisation This memo introduces three mechanisms to reduce the synchronisation
delay for such sessions. First, it updates the RTP Control Protocol delay for such sessions. First, it updates the RTP Control Protocol
(RTCP) timing rules to reduce the initial synchronisation delay for (RTCP) timing rules to reduce the initial synchronisation delay for
SSM sessions. Second, a new feedback packet is defined for use with SSM sessions. Second, a new feedback packet is defined for use with
the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing
video switching MCUs to rapidly request resynchronisation. Finally, video switching MCUs to rapidly request resynchronisation. Finally,
new RTP header extensions are defined to allow rapid synchronisation new RTP header extensions are defined to allow rapid synchronisation
of late joiners, and guarantee correct timestamp based decoding order of late joiners, and guarantee correct timestamp based decoding order
recovery for layered codecs in the presence of clock skew. recovery for layered codecs in the presence of clock skew.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 http://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 November 6, 2010.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Synchronisation of RTP Flows . . . . . . . . . . . . . . . . . 5 2. Synchronisation of RTP Flows . . . . . . . . . . . . . . . . . 4
2.1. Initial Synchronisation Delay . . . . . . . . . . . . . . 6 2.1. Initial Synchronisation Delay . . . . . . . . . . . . . . 5
2.1.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . 6 2.1.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . 5
2.1.2. Source Specific Multicast (SSM) Sessions . . . . . . . 7 2.1.2. Source Specific Multicast (SSM) Sessions . . . . . . . 6
2.1.3. Any Source Multicast (ASM) Sessions . . . . . . . . . 8 2.1.3. Any Source Multicast (ASM) Sessions . . . . . . . . . 7
2.1.4. Discussion . . . . . . . . . . . . . . . . . . . . . . 9 2.1.4. Discussion . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Synchronisation for Late Joiners . . . . . . . . . . . . . 9 2.2. Synchronisation for Late Joiners . . . . . . . . . . . . . 8
3. Reducing RTP Synchronisation Delays . . . . . . . . . . . . . 10 3. Reducing RTP Synchronisation Delays . . . . . . . . . . . . . 9
3.1. Reduced Initial RTCP Interval for SSM Senders . . . . . . 10 3.1. Reduced Initial RTCP Interval for SSM Senders . . . . . . 9
3.2. Rapid Resynchronisation Request . . . . . . . . . . . . . 11 3.2. Rapid Resynchronisation Request . . . . . . . . . . . . . 10
3.3. In-band Delivery of Synchronisation Metadata . . . . . . . 12 3.3. In-band Delivery of Synchronisation Metadata . . . . . . . 11
4. Application to Decoding Order Recovery in Layered Codecs . . . 14 4. Application to Decoding Order Recovery in Layered Codecs . . . 13
4.1. In-band Synchronisation for Decoding Order Recovery . . . 15 4.1. In-band Synchronisation for Decoding Order Recovery . . . 14
4.2. Timestamp based decoding order recovery . . . . . . . . . 16 4.2. Timestamp based decoding order recovery . . . . . . . . . 15
4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
When using RTP to deliver multimedia content it's often necessary to When using RTP to deliver multimedia content it's often necessary to
synchronise playout of audio and video components of a presentation. synchronise playout of audio and video components of a presentation.
This is achieved using information contained in RTP Control Protocol This is achieved using information contained in RTP Control Protocol
(RTCP) Sender Report (SR) packets [1]. These are sent periodically, (RTCP) Sender Report (SR) packets [1]. These are sent periodically,
and the components of a multimedia session cannot be synchronised and the components of a multimedia session cannot be synchronised
until sufficient RTCP SR packets have been received for each RTP flow until sufficient RTCP SR packets have been received for each RTP flow
to allow the receiver to establish mappings between the media clock to allow the receiver to establish mappings between the media clock
skipping to change at page 20, line 8 skipping to change at page 19, line 8
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[2] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [2] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control Protocol "Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Schooler, E., Ott, J., and J. Chesterfield, "RTCP Extensions [4] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
for Single-Source Multicast Sessions with Unicast Feedback", Protocol (RTCP) Extensions for Single-Source Multicast Sessions
draft-ietf-avt-rtcpssm-18 (work in progress), March 2009. with Unicast Feedback", RFC 5760, February 2010.
[5] Johansson, I. and M. Westerlund, "Support for Reduced-Size [5] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities and Real-Time Transport Control Protocol (RTCP): Opportunities and
Consequences", RFC 5506, April 2009. Consequences", RFC 5506, April 2009.
[6] Singer, D. and H. Desineni, "A General Mechanism for RTP Header [6] Singer, D. and H. Desineni, "A General Mechanism for RTP Header
Extensions", RFC 5285, July 2008. Extensions", RFC 5285, July 2008.
[7] Mills, D., "Network Time Protocol (Version 3) Specification, [7] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992. Implementation", RFC 1305, March 1992.
[8] Schierl, T. and S. Wenger, "Signaling media decoding dependency [8] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency
in Session Description Protocol (SDP)", in the Session Description Protocol (SDP)", RFC 5583,
draft-ietf-mmusic-decoding-dependency-08 (work in progress), July 2009.
April 2009.
8.2. Informative References 8.2. Informative References
[9] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP [9] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP
Payload Format for SVC Video", draft-ietf-avt-rtp-svc-18 (work Payload Format for SVC Video", draft-ietf-avt-rtp-svc-21 (work
in progress), March 2009. in progress), April 2010.
[10] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media [10] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media
Attributes in the Session Description Protocol (SDP)", Attributes in the Session Description Protocol (SDP)",
draft-ietf-mmusic-sdp-source-attributes-02 (work in progress), RFC 5576, June 2009.
October 2008.
[11] Casner, S., "Session Description Protocol (SDP) Bandwidth [11] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003. July 2003.
[12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in Offer/Answer Protocols", RFC 5245, April 2010.
progress), October 2007.
[13] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security [13] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security
(DTLS) Extension to Establish Keys for Secure Real-time (DTLS) Extension to Establish Keys for Secure Real-time
Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-05 (work Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-07 (work
in progress), September 2008. in progress), February 2009.
[14] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path [14] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path
Key Agreement for Secure RTP", draft-zimmermann-avt-zrtp-13 Key Agreement for Unicast Secure RTP",
(work in progress), January 2009. draft-zimmermann-avt-zrtp-18 (work in progress), April 2010.
[15] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [15] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[16] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-Based [16] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-Based
Rapid Acquisition of Multicast RTP Sessions", Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-05 (work in progress), draft-ietf-avt-rapid-acquisition-for-rtp-09 (work in progress),
November 2009. April 2010.
[17] Bont, F., Doehla, S., Schmidt, M., and R. Sperschneider, "RTP [17] de Bont, F., Doehla, S., Schmidt, M., and R. Sperschneider,
Payload Format for Elementary Streams with MPEG Surround multi- "RTP Payload Format for Elementary Streams with MPEG Surround
channel audio", draft-ietf-avt-rtp-mps-02 (work in progress), Multi-Channel Audio", RFC 5691, October 2009.
January 2009.
[18] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [18] 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, March 2004. RFC 3711, March 2004.
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
 End of changes. 13 change blocks. 
87 lines changed or deleted 79 lines changed or added

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