draft-ietf-avt-rapid-rtp-sync-08.txt   draft-ietf-avt-rapid-rtp-sync-09.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 December 22, 2009 Intended status: Standards Track January 8, 2010
Expires: June 25, 2010 Expires: July 12, 2010
Rapid Synchronisation of RTP Flows Rapid Synchronisation of RTP Flows
draft-ietf-avt-rapid-rtp-sync-08.txt draft-ietf-avt-rapid-rtp-sync-09.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 June 25, 2010. This Internet-Draft will expire on July 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 14, line 19 skipping to change at page 14, line 19
Note: The inclusion of an RTP header extension will reduce the Note: The inclusion of an RTP header extension will reduce the
efficiency of RTP header compression, if it is used. Furthermore, efficiency of RTP header compression, if it is used. Furthermore,
middle boxes which do not understand the header extensions may remove middle boxes which do not understand the header extensions may remove
them or may not update the content according to this memo. them or may not update the content according to this memo.
In all cases, irrespective of whether in-band NTP timestamp format In all cases, irrespective of whether in-band NTP timestamp format
timestamps are included or not, regular RTCP SR packets MUST be sent timestamps are included or not, regular RTCP SR packets MUST be sent
to provide backwards compatibility with receivers that synchronise to provide backwards compatibility with receivers that synchronise
RTP flows according to [1], and robustness in the face of middleboxes RTP flows according to [1], and robustness in the face of middleboxes
(RTP translators) that might strip RTP header extensions. The sender (RTP translators) that might strip RTP header extensions. If the
reports are also required to receive the upper 8 bit of the Seconds Variant B/56-bit NTP RTP header extension is used, RTCP sender
of the NTP timestamp format timestamp not included in the Variant reports MUST be used to derive the upper 8 bit of the Seconds for the
B/56-bit NTP RTP header extension (although this may generally be NTP timestamp format timestamp.
inferred from context).
When the SDP is used, the use of the RTP header extensions defined When the SDP is used, the use of the RTP header extensions defined
above MUST be indicated as specified in [6]. Therefore the following above MUST be indicated as specified in [6]. Therefore the following
URIs MUST be used: URIs MUST be used:
o The URI used for signalling the use of Variant A/64-bit NTP RTP o The URI used for signalling the use of Variant A/64-bit NTP RTP
header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-64". header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-64".
o The URI used for signalling the use of Variant B/56-bit NTP RTP o The URI used for signalling the use of Variant B/56-bit NTP RTP
header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-56". header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-56".
 End of changes. 5 change blocks. 
10 lines changed or deleted 9 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/