[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-perkins-avt-rapid-rtp-sync) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 6051

Network Working Group                                         C. Perkins
Internet-Draft                                     University of Glasgow
Updates: 3550 (if approved)                                   T. Schierl
Intended status: Standards Track                          Fraunhofer HHI
Expires: December 1, 2010                                   May 30, 2010


                   Rapid Synchronisation of RTP Flows
                  draft-ietf-avt-rapid-rtp-sync-11.txt

Abstract

   This memo outlines how RTP sessions are synchronised, and discusses
   how rapidly such synchronisation can occur.  We show that most RTP
   sessions can be synchronised immediately, but that the use of video
   switching multipoint conference units (MCUs) or large source specific
   multicast (SSM) groups can greatly increase the synchronisation
   delay.  This increase in delay can be unacceptable to some
   applications that use layered and/or multi-description codecs.

   This memo introduces three mechanisms to reduce the synchronisation
   delay for such sessions.  First, it updates the RTP Control Protocol
   (RTCP) timing rules to reduce the initial synchronisation delay for
   SSM sessions.  Second, a new feedback packet is defined for use with
   the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing
   video switching MCUs to rapidly request resynchronisation.  Finally,
   new RTP header extensions are defined to allow rapid synchronisation
   of late joiners, and guarantee correct timestamp based decoding order
   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 December 1, 2010.

Copyright Notice



Perkins & Schierl       Expires December 1, 2010                [Page 1]

Internet-Draft             RTP Synchronisation                  May 2010


   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

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Synchronisation of RTP Flows . . . . . . . . . . . . . . . . .  4
     2.1.  Initial Synchronisation Delay  . . . . . . . . . . . . . .  5
       2.1.1.  Unicast Sessions . . . . . . . . . . . . . . . . . . .  5
       2.1.2.  Source Specific Multicast (SSM) Sessions . . . . . . .  6
       2.1.3.  Any Source Multicast (ASM) Sessions  . . . . . . . . .  7
       2.1.4.  Discussion . . . . . . . . . . . . . . . . . . . . . .  8
     2.2.  Synchronisation for Late Joiners . . . . . . . . . . . . .  8
   3.  Reducing RTP Synchronisation Delays  . . . . . . . . . . . . .  9
     3.1.  Reduced Initial RTCP Interval for SSM Senders  . . . . . .  9
     3.2.  Rapid Resynchronisation Request  . . . . . . . . . . . . . 10
     3.3.  In-band Delivery of Synchronisation Metadata . . . . . . . 11
   4.  Application to Decoding Order Recovery in Layered Codecs . . . 13
     4.1.  In-band Synchronisation for Decoding Order Recovery  . . . 14
     4.2.  Timestamp based decoding order recovery  . . . . . . . . . 15
     4.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20












Perkins & Schierl       Expires December 1, 2010                [Page 2]

Internet-Draft             RTP Synchronisation                  May 2010


1.  Introduction

   When using RTP to deliver multimedia content it's often necessary to
   synchronise playout of audio and video components of a presentation.
   This is achieved using information contained in RTP Control Protocol
   (RTCP) Sender Report (SR) packets [1].  These are sent periodically,
   and the components of a multimedia session cannot be synchronised
   until sufficient RTCP SR packets have been received for each RTP flow
   to allow the receiver to establish mappings between the media clock
   used for each RTP flow, and the common (NTP-format) reference clock
   used to establish synchronisation.

   Recently, concern has been expressed that this synchronisation delay
   is problematic for some applications, for example those using layered
   or multi-description video coding.  This memo reviews the operations
   of RTP synchronisation, and describes the synchronisation delay that
   can be expected.  Three backwards compatible extensions to the basic
   RTP synchronisation mechanism are proposed:

   o  The RTCP transmission timing rules are relaxed for SSM senders, to
      reduce the initial synchronisation latency for large SSM groups.
      See Section 3.1.

   o  An enhancement to the Extended RTP Profile for RTCP-based Feedback
      (RTP/AVPF) [2] is defined to allow receivers to request additional
      RTCP SR packets, providing the metadata needed to synchronise RTP
      flows.  This can reduce the synchronisation delay when joining
      sessions with large RTCP reporting intervals, in the presence of
      packet loss, or when video switching MCUs are employed.  See
      Section 3.2.

   o  Two RTP header extensions are defined, to deliver synchronisation
      metadata in-band with RTP data packets.  These extensions provide
      synchronisation metadata that is aligned with RTP data packets,
      and so eliminate the need to estimate clock-skew between flows
      before synchronisation.  They can also reduce the need to receive
      RTCP SR packets before flows can be synchronised, although it does
      not eliminate the need for RTCP.  See Section 3.3.

   The immediate use-case for these extensions is to reduce the delay
   due to synchronisation when joining a layered video session (e.g. an
   H.264/SVC session in NI-T mode [9]).  The extensions are not specific
   to layered coding, however, and can be used in any environment when
   synchronisation latency is an issue.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].



Perkins & Schierl       Expires December 1, 2010                [Page 3]

Internet-Draft             RTP Synchronisation                  May 2010


2.  Synchronisation of RTP Flows

   RTP flows are synchronised by receivers based on information that is
   contained in RTCP SR packets generated by senders (specifically, the
   NTP-format timestamp and the RTP timestamp).  Synchronisation
   requires that a common reference clock MUST be used to generate the
   NTP-format timestamps in a set of flows that are to be synchronised
   (i.e. when synchronising several RTP flows, the RTP timestamps for
   each flow are derived from separate, and media specific, clocks, but
   the NTP format timestamps in the RTCP SR packets of all flows to be
   synchronised MUST be sampled from the same clock).  To achieve faster
   and more accurate synchronisation, it is further RECOMMENDED that
   senders and receivers use a synchronised common NTP format reference
   clock with common properties, especially timebase, where possible
   (recognising that this is often not possible when RTP is used outside
   of controlled environments); the means by which that common reference
   clock and its properties are signalled and distributed is outside the
   scope of this memo.

   For multimedia sessions, each type of media (e.g. audio or video) is
   sent in a separate RTP session, and the receiver associates RTP flows
   to be synchronised by means of the canonical end-point identifier
   (CNAME) item included in the RTCP Source Description (SDES) packets
   generated by the sender or signalled out of band [10].  For layered
   media, different layers can be sent in different RTP sessions, or
   using different SSRC values within a single RTP session; in both
   cases, the CNAME is used to identify flows to be synchronised.  To
   ensure synchronisation, an RTP sender MUST therefore send periodic
   compound RTCP packets following Section 6 of RFC 3550 [1].

   The timing of these periodic compound RTCP packets will depend on the
   number of members in each RTP session, the fraction of those that are
   sending data, the session bandwidth, the configured RTCP bandwidth
   fraction, and whether the session is multicast or unicast (see RFC
   3550 Section 6.2 for details).  In summary, RTCP control traffic is
   allocated a small fraction, generally 5%, of the session bandwidth,
   and of that fraction, one quarter is allocated to active RTP senders,
   while receivers use the remaining three quarters (these fractions can
   be configured via SDP [11]).  Each member of an RTP session derives
   an RTCP reporting interval based on these fractions, whether the
   session is multicast or unicast, the number of members it has
   observed, and whether it is actively sending data or not.  It then
   sends a compound RTCP packet on average once per reporting interval
   (the actual packet transmission time is randomised in the range [0.5
   ... 1.5] times the reporting interval to avoid synchronisation of
   reports).

   A minimum reporting interval of 5 seconds is RECOMMENDED, except that



Perkins & Schierl       Expires December 1, 2010                [Page 4]

Internet-Draft             RTP Synchronisation                  May 2010


   the delay before sending the initial report "MAY be set to half the
   minimum interval to allow quicker notification that the new
   participant is present" [1].  Also, for unicast sessions, "the delay
   before sending the initial compound RTCP packet MAY be zero" [1].  In
   addition, for unicast sessions, and for active senders in a multicast
   s