draft-ietf-avt-rapid-rtp-sync-06.txt   draft-ietf-avt-rapid-rtp-sync-07.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: RFC3550 T. Schierl
(if approved) Fraunhofer HHI (if approved) Fraunhofer HHI
Intended status: Standards Track October 26, 2009 Intended status: Standards Track November 9, 2009
Expires: April 29, 2010 Expires: May 13, 2010
Rapid Synchronisation of RTP Flows Rapid Synchronisation of RTP Flows
draft-ietf-avt-rapid-rtp-sync-06.txt draft-ietf-avt-rapid-rtp-sync-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on May 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
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 7, line 40 skipping to change at page 7, line 40
16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73 16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73
32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50 32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50 64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41 128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70 256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35 512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18 1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09 2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 1: Average RTCP reporting interval in seconds for an RTP Figure 1: Average initial synchronisation delay in seconds for an RTP
Session with 1 sender. Session with 1 sender.
These numbers assume a source specific multicast channel with a These numbers assume a source specific multicast channel with a
single active sender, assuming an average RTCP packet size of 70 single active sender, assuming an average RTCP packet size of 70
octets. These intervals are sufficient for lip-synchronisation octets. These intervals are sufficient for lip-synchronisation
without excessive delay, but might be viewed as having too much without excessive delay, but might be viewed as having too much
latency for synchronising parts of a layered video stream. latency for synchronising parts of a layered video stream.
The RTCP interval is randomised in the usual manner, so the minimum The RTCP interval is randomised in the usual manner, so the minimum
synchronisation delay will be half these intervals, and the maximum synchronisation delay will be half these intervals, and the maximum
skipping to change at page 8, line 43 skipping to change at page 8, line 43
16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47 16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47
32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73 32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50 64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41 128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70 256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35 512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18 1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09 2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04 4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 2: Average RTCP reporting interval in seconds for an RTP Figure 2: Average initial synchronisation delay in seconds for an RTP
Session with 2 senders. Session with 2 senders.
Session| Number of receivers: Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000 Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------ --+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69 8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69
16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34 16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34
32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67 32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67
64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84 64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84
128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42 128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42
256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71 256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85 512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43 1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21 2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11 4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11
Figure 3: Average RTCP reporting interval in seconds for an RTP Figure 3: Average initial synchronisation delay in seconds for an RTP
Session with 10 senders. Session with 10 senders.
2.1.4. Discussion 2.1.4. Discussion
For unicast sessions, the existing RTCP SR-based mechanism allows for For unicast sessions, the existing RTCP SR-based mechanism allows for
immediate synchronisation, provided the initial RTCP packet is not immediate synchronisation, provided the initial RTCP packet is not
lost. lost.
For SSM sessions, the initial synchronisation delay is sufficient for For SSM sessions, the initial synchronisation delay is sufficient for
lip-synchronisation, but may be larger than desired for some layered lip-synchronisation, but may be larger than desired for some layered
skipping to change at page 9, line 52 skipping to change at page 9, line 52
In this case, the receiver will not be able to synchronise the media In this case, the receiver will not be able to synchronise the media
until the reporting interval has passed, and the next RTCP SR packet until the reporting interval has passed, and the next RTCP SR packet
is sent. This is undesirable. Section 3.2 defines a new RTP/AVPF is sent. This is undesirable. Section 3.2 defines a new RTP/AVPF
transport layer feedback message to request an RTCP SR be generated, transport layer feedback message to request an RTCP SR be generated,
allowing rapid resynchronisation in the case of packet loss. allowing rapid resynchronisation in the case of packet loss.
2.2. Synchronisation for Late Joiners 2.2. Synchronisation for Late Joiners
Synchronisation between RTP sessions is potentially slower for late Synchronisation between RTP sessions is potentially slower for late
joiners than for participants present at the start of the session. joiners than for participants present at the start of the session.
The reasons for this are two-fold: The reasons for this are three-fold:
1. Many of the optimisations that allow rapid transmission of RTCP 1. Many of the optimisations that allow rapid transmission of RTCP
SR packets apply only at the start of a session. This implies SR packets apply only at the start of a session. This implies
that a new participant may have to wait a complete RTCP reporting that a new participant may have to wait a complete RTCP reporting
interval for each session before receiving the necessary data to interval for each session before receiving the necessary data to
synchronise media streams. This might potentially take several synchronise media streams. This might potentially take several
seconds, depending on the configured session bandwidth and the seconds, depending on the configured session bandwidth and the
number of participants. number of participants.
2. Additional synchronisation delay comes from the nature of the 2. Additional synchronisation delay comes from the nature of the
 End of changes. 7 change blocks. 
8 lines changed or deleted 8 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/