draft-perkins-avt-rapid-rtp-sync-00.txt   draft-perkins-avt-rapid-rtp-sync-01.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Standards Track October 25, 2008 Updates: RFC3550 January 12, 2009
Expires: April 28, 2009 (if approved)
Intended status: Standards Track
Expires: July 16, 2009
Rapid Synchronisation of RTP Flows Rapid Synchronisation of RTP Flows
draft-perkins-avt-rapid-rtp-sync-00.txt draft-perkins-avt-rapid-rtp-sync-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
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."
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 28, 2009. This Internet-Draft will expire on July 16, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 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.
Abstract Abstract
This memo outlines how RTP multimedia sessions are synchronised, and This memo outlines how RTP multimedia sessions are synchronised, and
discusses how rapidly such synchronisation can occur. It is shown discusses how rapidly such synchronisation can occur. We show that
that unicast sessions can be synchronised immediately in most cases. most RTP sessions can be synchronised immediately, but that the use
Multicast groups have longer synchronisation delay. A modification of video switching MCUs or large multicast (SSM) groups can greatly
to the RTCP timing rules is suggested to improve synchronisation time increase the initial synchronisation delay. This increased delay can
for SSM senders. A new RTP/AVPF feedback packet is defined to be unacceptable to some applications that use layered and/or multi-
improve general synchronisation times. description codecs.
This memo changes to the RTCP timing rules to reduce the initial
synchronisation delay for SSM sessions. A new RTP/AVPF feedback
packet is defined to allow video switching MCUs to request rapid
resynchronisation, and a new RTP header extension is defined to
support rapid synchronisation for late joiners.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Synchronisation of RTP Flows . . . . . . . . . . . . . . . . . 3 2. Synchronisation of RTP Flows . . . . . . . . . . . . . . . . . 3
3. Initial Synchronisation Delay . . . . . . . . . . . . . . . . . 4 2.1. Initial Synchronisation Delay . . . . . . . . . . . . . . 4
3.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . 4
3.2. Source Specific Multicast (SSM) Sessions . . . . . . . . . 5 2.1.2. Source Specific Multicast (SSM) Sessions . . . . . . . 5
3.3. Any Source Multicast (ASM) Sessions . . . . . . . . . . . . 6 2.1.3. Any Source Multicast (ASM) Sessions . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Discussion . . . . . . . . . . . . . . . . . . . . . . 6
5. Rapid Resynchronisation . . . . . . . . . . . . . . . . . . . . 6 2.2. Synchronisation for Late Joiners . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 3. In-band Synchronisation . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 4. Rapid Resynchronisation . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
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 an RTCP SR packet has been received for each flow. Recently, until an RTCP SR packet has been received for each flow. Recently,
concern has been expressed that this initial synchronisation delay is concern has been expressed that this initial synchronisation delay is
problematic for some applications, for example those using layered or problematic for some applications, for example those using layered or
multiple description video coding. This memo reviews the operation multiple description video coding. This memo reviews the operation
of RTP synchronisation, describes the initial synchronisation delay of RTP synchronisation, describes the initial synchronisation delay
that can be expected, and defines an enhancement to the Extended RTP that can be expected, and defines an enhancement to the Extended RTP
Profile for RTCP-based Feedback (RTP/AVPF) [2] to provide faster Profile for RTCP-based Feedback (RTP/AVPF) [2], and a new RTP header
synchronisation in some circumstances. extension, to provide faster synchronisation in some circumstances.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
2. Synchronisation of RTP Flows 2. Synchronisation of RTP Flows
RTP flows are synchronised by receivers based on information that is RTP flows are synchronised by receivers based on information that is
contained in RTCP SR packets generated by senders (specifically, the contained in RTCP SR packets generated by senders (specifically, the
NTP and RTP timestamps). Each media type is sent in a separate RTP NTP and RTP timestamps). Each type of media (e.g. audio or video) is
session, and the receiver associates RTP flows to be synchronised by sent in a separate RTP session, and the receiver associates RTP flows
means of the canonical end-point identifier (CNAME) item included in to be synchronised by means of the canonical end-point identifier
the RTCP Source Description (SDES) packets generated by the sender. (CNAME) item included in the RTCP Source Description (SDES) packets
To ensure synchronisation, an RTP sender MUST therefore send periodic generated by the sender. To ensure synchronisation, an RTP sender
compound RTCP packets following Section 6 of RFC 3550 [1]. 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 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 number of members in each RTP session, the fraction of those that are
sending data, the session bandwidth, the configured RTCP bandwidth sending data, the session bandwidth, the configured RTCP bandwidth
fraction, and whether the session is multicast or unicast (see RFC fraction, and whether the session is multicast or unicast (see RFC
3550 Section 6.2 for details). In summary, RTCP control traffic is 3550 Section 6.2 for details). In summary, RTCP control traffic is
allocated a small fraction, generally 5%, of the session bandwidth. allocated a small fraction, generally 5%, of the session bandwidth,
Of that RTCP bandwidth fraction, one quarter is allocated to active and of that fraction, one quarter is allocated to active RTP senders,
RTP senders, while receivers use the remaining three quarters (these while receivers use the remaining three quarters (these fractions can
fractions can be configured via SDP [4]). Each member of an RTP be configured via SDP [5]). Each member of an RTP session derives an
session derives an RTCP reporting interval based on these fractions, RTCP reporting interval based on these fractions, whether the session
whether the session is multicast or unicast, the number of members it is multicast or unicast, the number of members it has observed, and
has observed, and whether it is actively sending data or not. It whether it is actively sending data or not. It then sends a compound
then sends a compound RTCP packet on average once per reporting RTCP packet on average once per reporting interval (the actual packet
interval (the actual transmission delay for each packet is randomised transmission time is randomised in the range [0.5 ... 1.5] times the
in the range [0.5 ... 1.5] times the reporting interval to avoid reporting interval to avoid synchronisation of reports).
synchronisation of reports).
A minimum reporting interval of 5 seconds is RECOMMENDED, except that A minimum reporting interval of 5 seconds is RECOMMENDED, except that
the delay before sending the initial report "MAY be set to half the the delay before sending the initial report "MAY be set to half the
minimum interval to allow quicker notification that the new minimum interval to allow quicker notification that the new
participant is present" [1]. Also, for unicast sessions, "the delay participant is present" [1]. Also, for unicast sessions, "the delay
before sending the initial compound RTCP packet MAY be zero" [1]. In before sending the initial compound RTCP packet MAY be zero" [1]. In
addition, for unicast sessions, and for active senders in a multicast addition, for unicast sessions, and for active senders in a multicast
session, the fixed minimum reporting interval MAY be scaled to "360 session, the fixed minimum reporting interval MAY be scaled to "360
divided by the session bandwidth in kilobits/second. This minimum is divided by the session bandwidth in kilobits/second. This minimum is
smaller than 5 seconds for bandwidths greater than 72 kb/s." [1] smaller than 5 seconds for bandwidths greater than 72 kb/s." [1]
3. Initial Synchronisation Delay 2.1. Initial Synchronisation Delay
A multimedia session comprises a set of concurrent RTP sessions among A multimedia session comprises a set of concurrent RTP sessions among
a common group of participants, using one RTP session for each media a common group of participants, using one RTP session for each media
type. For example, a videoconference (which is a multimedia session) type. For example, a videoconference (which is a multimedia session)
might contain an audio RTP session and a video RTP session. To allow might contain an audio RTP session and a video RTP session. To allow
a receiver to synchronise the components of a multimedia session, a a receiver to synchronise the components of a multimedia session, a
compound RTCP packet containing an RTCP SR packet and an RTCP SDES compound RTCP packet containing an RTCP SR packet and an RTCP SDES
packet with a CNAME item MUST be sent to each of the RTP sessions in packet with a CNAME item MUST be sent to each of the RTP sessions in
the multimedia session. A receiver cannot synchronise playout across the multimedia session. A receiver cannot synchronise playout across
the multimedia session until such RTCP packets have been received on the multimedia session until such RTCP packets have been received on
all of the component RTP sessions. If there is no packet loss, this all of the component RTP sessions. If there is no packet loss, this
gives an expected initial synchronisation delay equal to the average gives an expected initial synchronisation delay equal to the average
time taken to receive the first RTCP packet in the RTP session with time taken to receive the first RTCP packet in the RTP session with
the longest RTCP reporting interval. This will vary between unicast the longest RTCP reporting interval. This will vary between unicast
and multicast RTP sessions. and multicast RTP sessions.
3.1. Unicast Sessions 2.1.1. Unicast Sessions
For unicast multimedia sessions, senders SHOULD transmit an initial For unicast multimedia sessions, senders SHOULD transmit an initial
compound RTCP packet (containing an RTCP SR packet and an RTCP SDES compound RTCP packet (containing an RTCP SR packet and an RTCP SDES
packet with a CNAME item) immediately on joining each RTP session in packet with a CNAME item) immediately on joining each RTP session in
the multimedia session. The individual RTP sessions are considered the multimedia session. The individual RTP sessions are considered
to be joined once any in-band signalling for NAT traversal (e.g. [5]) to be joined once any in-band signalling for NAT traversal (e.g. [6])
and/or security keying (e.g. [6],[7]) has concluded, and the media and/or security keying (e.g. [7],[8]) has concluded, and the media
path is open. This implies that the initial RTCP packet is sent in path is open. This implies that the initial RTCP packet is sent in
parallel with the first data packet following the guidance in RFC parallel with the first data packet following the guidance in RFC
3550 that "the delay before sending the initial compound RTCP packet 3550 that "the delay before sending the initial compound RTCP packet
MAY be zero" and, in the absence of any packet loss, flows can be MAY be zero" and, in the absence of any packet loss, flows can be
synchronised immediately. synchronised immediately.
Note that NAT pinholes, firewall holes, quality-of-service, and media Note that NAT pinholes, firewall holes, quality-of-service, and media
security keys should have been negotiated as part of the signalling, security keys should have been negotiated as part of the signalling,
whether in-band or out-of-band, before the first RTCP packet is sent. whether in-band or out-of-band, before the first RTCP packet is sent.
This should ensure that any middleboxes are ready to accept traffic, This should ensure that any middleboxes are ready to accept traffic,
and reduce the likelihood that the initial RTCP packet will be lost. and reduce the likelihood that the initial RTCP packet will be lost.
3.2. Source Specific Multicast (SSM) Sessions 2.1.2. Source Specific Multicast (SSM) Sessions
For multicast sessions, the delay before sending the initial RTCP For multicast sessions, the delay before sending the initial RTCP
packet, and hence the synchronisation delay, varies with the session packet, and hence the synchronisation delay, varies with the session
bandwidth and the number of members in the session. For a multicast bandwidth and the number of members in the session. For a multicast
multimedia session, the average synchronisation delay will depend on multimedia session, the average synchronisation delay will depend on
the slowest of the component RTP sessions; this will generally be the the slowest of the component RTP sessions; this will generally be the
session with the lowest bandwidth (assuming all the RTP sessions have session with the lowest bandwidth (assuming all the RTP sessions have
the same number of members). the same number of members).
When sending to a multicast group, the reduced minimum RTCP reporting When sending to a multicast group, the reduced minimum RTCP reporting
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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
delay will be 1.5 times these intervals. Note also that these RTCP delay will be 1.5 times these intervals. Note also that these RTCP
intervals are calculated assuming perfect knowledge of the number of intervals are calculated assuming perfect knowledge of the number of
members in the session. In practice, an implementation will have members in the session. In practice, an implementation will have
only limited knowledge of the size of the session when joining, and only limited knowledge of the size of the session when joining, and
will likely send its initial report early compared to these values, will likely send its initial report early compared to these values,
following the RTCP reconsideration rules. following the RTCP reconsideration rules.
3.3. Any Source Multicast (ASM) Sessions 2.1.3. Any Source Multicast (ASM) Sessions
(tbd) (tbd)
For ASM sessions, the fraction of members that are senders plays an For ASM sessions, the fraction of members that are senders plays an
important role, and imply more varation in average RTCP reporting important role, and imply more varation in average RTCP reporting
interval. interval.
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
codecs. The rationale for not sending immediate RTCP packets for codecs. The rationale for not sending immediate RTCP packets for
multicast groups is to avoid implosion of requests when large numbers multicast groups is to avoid implosion of requests when large numbers
of members simultaneously join the group ("flash crowd"). This is of members simultaneously join the group ("flash crowd"). This is
skipping to change at page 6, line 39 skipping to change at page 6, line 39
RTCP SR on joining a session (as is currenly allowed for unicast RTCP SR on joining a session (as is currenly allowed for unicast
sessions, which also don't suffer from the implosion problem). SSM sessions, which also don't suffer from the implosion problem). SSM
receivers using unicast feedback would not be allowed to send receivers using unicast feedback would not be allowed to send
immediate RTCP. This would be a change to RFC 3550, if accepted. immediate RTCP. This would be a change to RFC 3550, if accepted.
For ASM session... (tbd) For ASM session... (tbd)
In all cases, it is possible that the initial RTCP SR packet is lost. In all cases, it is possible that the initial RTCP SR packet is lost.
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. The following section defines a new is sent. This is undesirable. Section 4 defines a new RTP/AVPF
RTP/AVPF transport layer feedback message to request an RTCP SR be transport layer feedback message to request an RTCP SR be generated,
generated, allowing rapid resynchronisation. allowing rapid resynchronisation in the case of packet loss.
5. Rapid Resynchronisation 2.2. Synchronisation for Late Joiners
Synchronisation between RTP sessions is potentially slower for late
joiners, than for participants present at the start of the session.
The reasons for this are two-fold:
1. Many of the optimisations that allow rapid transmission of RTCP
SR packets apply only at the start of a session. This implies
that a new participant may have to wait a complete RTCP reporting
interval for each session before receiveing the necessary data to
synchronise media streams. This might potentially take several
seconds, depending on the configured session bandwidth and the
number of participants.
2. Additional synchronisation delay comes from the nature of the
RTCP timing rules. Packets are generated on average once per
reporting interval but with the exact transmission times being
randomised +/- 50% to avoid synchronisation of reports. This is
important to avoid network congestion in multicast sessions, but
does mean that the timing of RTCP SR reports for different RTP
sessions aren't synchronised. Accordingly, a receiver must
estimate the skew on the NTP-format clock in order to align RTP
timestamps across sessions. This estimation is an essential part
of an RTP synchronisation implementation, and can be done exactly
given sufficient reports. Collecting sufficient RTCP SR data to
perform this estimation, however, may require several reports,
further increasing the synchronisation delay.
These delays are likely an issue for tuning in to an onoing multicast
RTP session, or for video switching MCUs.
3. In-band Synchronisation
The RTP header extension mechanism defined in [4] can be adopted to
carry an OPTIONAL NTP format wall clock timestamp in RTP data
packets. If such a timestamp is included, it MUST correspond to the
same time instant as the RTP timestamp in the packet's header, and
MUST be derived from the same clock used to generate the NTP format
timestamps included in RTCP SR packets. The format of such a header
extension is show below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=4 | NTP format timestamp... |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| ... NTP format timestamp (cont) ... |n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...NTP (cont) | 0 (pad) | 0 (pad) | 0 (pad) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: it's unfortunate that three octets of padding are needed to
align the header extension. It may be worth defining a variant
that sends only the lower 56 bits of the NTP format timestamp, to
reduce the overheads (assuming the top 8 bits can be inferred),
although this is incompatible with the equivalent ISMA mechanism.
An NTP format wall clock timestamp may be included on any RTP packets
the sender chooses, but is expected to be most useful:
1. When sent on the RTP packets corresponding to a video random
access point, and on the associated audio packets, to allow rapid
synchronisation for late joiners and in video switching
scenarios.
2. When used with a layered, multi-description, or multi-view codec,
to provide exact synchronisation between layers, descriptions, or
views without requiring receivers to estimate clock skew between
wall and media clocks.
In all cases, irrespective of whether in-band NTP format timestamps
are included or not, regular RTCP SR packets MUST be sent to provide
backwards compatibility with receivers that synchronise RTP flows
according to RFC 3550 [1].
(tbd: signalling for this header extension)
4. Rapid Resynchronisation
The general format of an RTP/AVPF transport layer feedback message is The general format of an RTP/AVPF transport layer feedback message is
shown below. shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT=RTPFB=205 | length | |V=2|P| FMT | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
skipping to change at page 7, line 33 skipping to change at page 9, line 38
possible within the RTCP early feedback rules. That RTCP SR packet possible within the RTCP early feedback rules. That RTCP SR packet
MAY be sent as a non-compound RTCP packet, if this has been MAY be sent as a non-compound RTCP packet, if this has been
negotiated. negotiated.
The Feedback Control Information (FCI) part of the packet is emtpy. The Feedback Control Information (FCI) part of the packet is emtpy.
The SSRC of packet sender indicates the member that is unable to The SSRC of packet sender indicates the member that is unable to
synchronise media streams, while the SSRC of media source indicates synchronise media streams, while the SSRC of media source indicates
the sender of the media it is unable to synchronise. The lenght MUST the sender of the media it is unable to synchronise. The lenght MUST
equal 2. equal 2.
6. Security Considerations (tbd: discuss what happens if the feedback target is not co-located
with the sender)
5. Security Considerations
The security considerations of the RTP specification [1] and RTP/AVPF The security considerations of the RTP specification [1] and RTP/AVPF
profile [2] apply. No addtional security considerations apply due to profile [2] apply. No addtional security considerations apply due to
the RTP/AVPF rapid resynchronisation mechanism defined in Section 5. the RTP/AVPF rapid resynchronisation mechanism defined in Section 4.
7. IANA Considerations 6. IANA Considerations
(tbd - this needs to register the new RTP/AVPF transport layer (tbd - this needs to register the new RTP/AVPF transport layer
feedback packet type) feedback packet type)
7. Acknowledgements
This memo has benefitted from discussions with numerous members of
the IETF AVT working group, including Magnus Westerlund, Thomas
Schierl, and Jonathan Lennox. The mechanism in Section 3 was
suggested by Dave Singer, matching a similar mechanism specified by
ISMA.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"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] Singer, D. and H. Desineni, "A General Mechanism for RTP Header
Extensions", RFC 5285, July 2008.
8.2. Informative References 8.2. Informative References
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth [5] 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.
[5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [6] 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", draft-ietf-mmusic-ice-19 (work in
progress), October 2007. progress), October 2007.
[6] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security [7] 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 in Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-05 (work in
progress), September 2008. progress), September 2008.
[7] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path [8] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path
Key Agreement for Secure RTP", draft-zimmermann-avt-zrtp-09 Key Agreement for Secure RTP", draft-zimmermann-avt-zrtp-09
(work in progress), September 2008. (work in progress), September 2008.
Author's Address Author's Address
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
Sir Alwyn Williams Building Sir Alwyn Williams Building
Lilybank Gardens Lilybank Gardens
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
Email: csp@csperkins.org Email: csp@csperkins.org
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 29 change blocks. 
66 lines changed or deleted 184 lines changed or added

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