draft-ietf-avt-rapid-rtp-sync-03.txt   draft-ietf-avt-rapid-rtp-sync-04.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 June 30, 2009 Intended status: Standards Track July 3, 2009
Expires: January 1, 2010 Expires: January 4, 2010
Rapid Synchronisation of RTP Flows Rapid Synchronisation of RTP Flows
draft-ietf-avt-rapid-rtp-sync-03.txt draft-ietf-avt-rapid-rtp-sync-04.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 January 1, 2010. This Internet-Draft will expire on January 4, 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 5, line 14 skipping to change at page 5, line 14
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-format timestamp and the RTP timestamp). Synchronisation NTP-format timestamp and the RTP timestamp). Synchronisation
requires that a common reference clock MUST be used to generate the 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. NTP-format timestamps in a set of flows that are to be synchronised.
Furthermore, to achieve more rapid and accurate synchronisation, it Furthermore, to achieve more rapid and accurate synchronisation, it
is RECOMMENDED that senders and receivers use a common reference is RECOMMENDED that senders and receivers use a common reference
clock where possible (recognising that this is often not possible clock with common properties, especially timebase, where possible
when RTP is used outside of controlled environments); the means by (recognising that this is often not possible when RTP is used outside
which that common reference clock is distributed are outside the 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. scope of this memo.
For multimedia sessions, each type of media (e.g. audio or video) is 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 sent in a separate RTP session, and the receiver associates RTP flows
to be synchronised by means of the canonical end-point identifier to be synchronised by means of the canonical end-point identifier
(CNAME) item included in the RTCP Source Description (SDES) packets (CNAME) item included in the RTCP Source Description (SDES) packets
generated by the sender or signalled out of band [10]. For layered generated by the sender or signalled out of band [10]. For layered
media, different layers can be sent in different RTP sessions, or media, different layers can be sent in different RTP sessions, or
using different SSRC values within a single RTP session; in both using different SSRC values within a single RTP session; in both
cases, the CNAME is used to identify flows to be synchronised. To cases, the CNAME is used to identify flows to be synchronised. To
 End of changes. 4 change blocks. 
7 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/