One document matched: draft-ietf-avtext-multiple-clock-rates-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc compact="yes" ?>
<?rfc strict="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-ietf-avtext-multiple-clock-rates-01" ipr="trust200902" updates="3550">
<front>
<title abbrev="Multiple Clock Rates">Support for multiple clock rates in an RTP session</title>
<author fullname="Marc Petit-Huguenin" initials="M.P.H" surname="Petit-Huguenin">
<organization>Stonyfish, Inc.</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="11" month="July" year="2011"/>
<abstract>
<t>
This document clarifies the RTP specification when different clock rates are used in an RTP session.
It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The clock rate is a parameter of the payload format.
It is often defined as been the same as the sampling rate but it is not always the case (see e.g. the G722 and MPA audio codecs in <xref target="RFC3551"/>).
</t>
<t>
An RTP sender can switch between different payloads during the lifetime of an RTP session and because clock rates are defined by payload types, it is possible that the clock rate also varies during an RTP session.
<xref target="RFC3550">RTP</xref> lists using multiple clock rates as one of the reasons to not use different payloads on the same SSRC but unfortunately this advice was not always followed and some RTP implementations change the payload in the same SSRC even if the different payloads use different clock rates.
</t>
<t>
This creates three problems:
<list style="symbols">
<t>The method used to calculate the RTP timestamp field in an RTP packet is underspecified.</t>
<t>When the same SSRC is used for different clock rates, it is difficult to know what clock rate was used for the RTP timestamp field in an RTCP SR packet.</t>
<t>When the same SSRC is used for different clock rates, it is difficult to know what clock rate was used for the interarrival jitter field in an RTCP RR packet.</t>
</list>
</t>
<t>
<xref target="fields"/> contains a non-exhaustive list of fields in RTCP packets that uses a clock rate as unit:
</t>
<texttable anchor="fields">
<ttcol>Field name</ttcol>
<ttcol>RTCP packet type</ttcol>
<ttcol>Reference</ttcol>
<c>RTP timestamp</c> <c>SR</c> <c>
<xref target="RFC3550"/>
</c>
<c>Interarrival jitter</c> <c>RR</c> <c>
<xref target="RFC3550"/>
</c>
<c>min_jitter</c> <c>XR Summary Block</c> <c>
<xref target="RFC3611"/>
</c>
<c>max_jitter</c> <c>XR Summary Block</c> <c>
<xref target="RFC3611"/>
</c>
<c>mean_jitter</c> <c>XR Summary Block</c> <c>
<xref target="RFC3611"/>
</c>
<c>dev_jitter</c> <c>XR Summary Block</c> <c>
<xref target="RFC3611"/>
</c>
<c>Interarrival jitter</c> <c>IJ</c> <c>
<xref target="RFC5450"/>
</c>
<c>RTP timestamp</c> <c>SMPTETC</c> <c>
<xref target="RFC5484"/>
</c>
<c>Jitter</c> <c>RSI Jitter Block</c> <c>
<xref target="RFC5760"/>
</c>
<c>Median jitter</c> <c>RSI Stats Block</c> <c>
<xref target="RFC5760"/>
</c>
</texttable>
<t>
This document first tries to list in <xref target="legacy"/> and subsections all known algorithms used in existing RTP implementations at the time of writing.
This sections are not normative.
</t>
<t>
<xref target="recommendations"/> and subsections then recommend a unique algorithm that modifies <xref target="RFC3550"/>.
This sections are normative.
</t>
<t>
<xref target="analysis"/> and subsections then analyze what happen when the legacy algorithms listed in <xref target="legacy"/> are used with the new algorithm listed in <xref target="recommendations"/>.
This sections are not normative.
</t>
</section>
<section anchor="legacy" title="Legacy RTP">
<t>
The following sections describe the various ways legacy RTP implementations behave when multiple clock rates are used.
Legacy RTP refers to RFC 3550 without the modifications introduced by this document.
</t>
<t>
[[We need to list here all the methods used in the field. Please send them to the author. NDA can be arranged if needed]]
</t>
<section anchor="method1" title="Different SSRC">
<t>
One way of managing multiple clock rates is to use a different SSRC for each different clock rate, as in this case there is no ambiguity on the clock rate used by fields in the RTCP packets.
This method also seems to be the original intent of RTP as can be deduced from points 2 and 3 of section 5.2 of RFC 3550.
</t>
<t>
On the other hand changing the SSRC can be a problem for some implementations designed to work only with unicast IP addresses, where having multiple SSRCs is considered a corner case.
Lip synchronization can also be a problem in the interval between the beginning of the new stream and the first RTCP SR packet.
This is not different than what happen at the beginning of the RTP session but it can be more annoying for the end-user.
</t>
</section>
<section title="Same SSRC">
<t>
The simplest way of managing multiple clock rates is to use the same SSRC for all the payload types regardless of the clock rates.
</t>
<t>
Unfortunately there is no clear definition on how the RTP timestamp should be calculated in this case.
The following subsection presents one algorithm used in the field.
</t>
<section anchor="method2" title="Monotonic timestamps">
<t>
The most common method of calculating the RTP timestamp ensures that the value increases monotonically.
The formula used by this method is as follow:
</t>
<t>
timestamp = previous_timestamp + (current_capture_time - previous_capture_time) * current_clock_rate
</t>
<t>
The problem with this method is that the jitter calculation on the receiving side gives invalid result during the transition between two clock rates, as shown in <xref target="monotonic"/>.
The capture and arrival time are in seconds, starting at the beginning of the capture of the first packet; clock rate is in Hz; the RTP timestamp does not include the random offset; the transit, jitter, and average jitter use the clock rate as unit.
</t>
<texttable anchor="monotonic">
<ttcol>Capt. time</ttcol>
<ttcol>Clock rate</ttcol>
<ttcol>RTP timestamp</ttcol>
<ttcol>Arrival time</ttcol>
<ttcol>Transit</ttcol>
<ttcol>Jitter</ttcol>
<ttcol>Average jitter</ttcol>
<c>0</c>
<c>8000</c>
<c>0</c>
<c>0.1</c>
<c>800</c>
<c/>
<c/>
<c>0.02</c>
<c>8000</c>
<c>160</c>
<c>0.12</c>
<c>800</c>
<c>0</c>
<c>0</c>
<c>0.04</c>
<c>8000</c>
<c>320</c>
<c>0.14</c>
<c>800</c>
<c>0</c>
<c>0</c>
<c>0.06</c>
<c>8000</c>
<c>480</c>
<c>0.16</c>
<c>800</c>
<c>0</c>
<c>0</c>
<c>0.08</c>
<c>16000</c>
<c>800</c>
<c>0.18</c>
<c>2080</c>
<c>480</c>
<c>30</c>
<c>0.1</c>
<c>16000</c>
<c>1120</c>
<c>0.2</c>
<c>2080</c>
<c>0</c>
<c>28</c>
<c>0.12</c>
<c>16000</c>
<c>1440</c>
<c>0.22</c>
<c>2080</c>
<c>0</c>
<c>26</c>
<c>0.14</c>
<c>8000</c>
<c>1600</c>
<c>0.24</c>
<c>320</c>
<c>720</c>
<c>70</c>
<c>0.16</c>
<c>8000</c>
<c>1760</c>
<c>0.26</c>
<c>320</c>
<c>0</c>
<c>65</c>
</texttable>
<t>
Calculating the correct transit time on the receiving side can be done by using the following formulas:
</t>
<t>
<list style="hanging">
<t hangText="(1)">current_time_capture = current_timestamp - previous_timestamp) / current_clock_rate + previous_time_capture</t>
<t hangText="(2)">transit = current_clock_rate * (time_arrival - current_time_capture)</t>
<t hangText="(3)">previous_time_capture = current_time_capture</t>
</list>
</t>
<t>
The main problem with this method, in addition to the fact that the jitter calculation described in RFC 3550 cannot be used, is that is it dependent on the previous RTP packets, packets that can be reordered or lost in the network.
But it seems that this is what most implementations are using.
</t>
</section>
</section>
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
<t>
<list style="hanging">
<t hangText="Clock rate:">
The multiplier used to convert from a wallclock value in seconds to an equivalent RTP timestamp value (without the fixed random offset).
Note that RFC 3550 uses various terms like "clock frequency", "media clock rate", "timestamp unit", "timestamp frequency", and "RTP timestamp clock rate" as synonymous to clock rate.
</t>
<t hangText="RTP Sender:">
A logical network element that sends RTP packets, sends RTCP SR packets, and receives RTCP RR packets.
</t>
<t hangText="RTP Receiver:">
A logical network element that receives RTP packets, receives RTCP SR packets, and sends RTCP RR packets.
</t>
</list>
</t>
</section>
<section anchor="recommendations" title="Recommendations">
<section title="RTP Sender">
<t>
An RTP Sender with RTCP turned off (i.e. by setting the RS and RR bandwidth modifiers defined in <xref target="RFC3556"/> to 0) SHOULD use a different SSRC for each different clock rate but MAY use different clock rates on the same SSRC as long as the RTP timestamp without the random offset is calculated as explained below:
</t>
<t>
[[This was designed to help VoIP implementations who anyway never cared about RTCP. Do we want to keep this?]]
</t>
<t>
Each time the clock rate changes, the start_offset and capture_start values are calculated with the following formulas:
</t>
<figure>
<artwork><![CDATA[
start_offset = (capture_time - capture_start) * previous_clock_rate
capture_start = capture_time
]]></artwork>
</figure>
<t>
For the first RTP packet, the values are initialized with the following formulas:
</t>
<figure>
<artwork><![CDATA[
start_offset = 0
capture_start = capture_time
]]></artwork>
</figure>
<t>
After eventually updating this values, the RTP timestamp is calculated with the following formula:
</t>
<t>
timestamp = (capture_time - capture_start) * clock_rate + start_offset
</t>
<t>Note that in all the formulas, capture_time is the first instant the new timestamp rate is used.</t>
<t>
An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate.
An RTCP BYE MUST be sent and a new SSRC MUST be used if the clock rate switches back to a value already seen in the RTP stream.
</t>
<t>
To accelerate lip synchronization, the next compound RTCP packet sent by the RTP sender MUST contain multiple SR packets, the first one containing the mapping for the current clock rate and the next SR packets containing the mapping for the other clock rates seen during the last period.
</t>
<t>
[[Some legacy implementations may dislike receiving multiple SR packets. What should we do?]]
</t>
<t>
The RTP extension defined in <xref target="RFC6051"/> MAY be used to accelerate the synchronization.
</t>
</section>
<section title="RTP Receiver">
<t>
An RTP Receiver MUST calculate the jitter using the following formula:
</t>
<t>
D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) - (arrival_time_i * clock_rate_i - timestamp_i)
</t>
<t>
An RTP Receiver MUST be able to handle a compound RTCP packet with multiple SR packets.
</t>
<t>
For interoperability with legacy RTP implementations, an RTP receiver MAY use the information in two consecutive SR packets to calculate the clock rate used, i.e. if Ni is the NTP timestamp for the SR packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the NTP timestamp and RTP timestamp for the previous SR packet j, then the clock rate can be guessed as the closest to (Ri - Rj) / (Ni - Nj).
</t>
</section>
</section>
<section anchor="analysis" title="Interoperability Analysis">
<t>
The next subsections analyze the various combinations between legacy RTP implementations and RTP implementations that follow this document specifications.
</t>
<t>TBD</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>No IANA considerations.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Colin Perkins, Ali C. Begen and Magnus Westerlund for their comments, suggestions and questions that helped to improve this document.</t>
<t>Thanks to Robert Sparks and the attendees of SIPit 26 for the survey on multiple clock rates interoperability.</t>
<t>This document was written with the xml2rfc tool described in <xref target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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.
</t>
</list>
</t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization/>
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization/>
</author>
<author fullname="R. Frederick" initials="R." surname="Frederick">
<organization/>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization/>
</author>
<date month="July" year="2003"/>
<abstract>
<t>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<format octets="259985" target="http://www.rfc-editor.org/rfc/rfc3550.txt" type="TXT"/>
<format octets="630740" target="http://www.rfc-editor.org/rfc/rfc3550.ps" type="PS"/>
<format octets="504117" target="http://www.rfc-editor.org/rfc/rfc3550.pdf" type="PDF"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="June" year="1999"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2629"/>
<format octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
<reference anchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization/>
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization/>
</author>
<date month="July" year="2003"/>
<abstract>
<t>This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="65"/>
<seriesInfo name="RFC" value="3551"/>
<format octets="106621" target="http://www.rfc-editor.org/rfc/rfc3551.txt" type="TXT"/>
<format octets="317286" target="http://www.rfc-editor.org/rfc/rfc3551.ps" type="PS"/>
<format octets="237831" target="http://www.rfc-editor.org/rfc/rfc3551.pdf" type="PDF"/>
</reference>
<reference anchor="RFC3556">
<front>
<title>Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth</title>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization/>
</author>
<date month="July" year="2003"/>
<abstract>
<t>This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3556"/>
<format octets="15310" target="http://www.rfc-editor.org/rfc/rfc3556.txt" type="TXT"/>
</reference>
<reference anchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author fullname="T. Friedman" initials="T." surname="Friedman">
<organization/>
</author>
<author fullname="R. Caceres" initials="R." surname="Caceres">
<organization/>
</author>
<author fullname="A. Clark" initials="A." surname="Clark">
<organization/>
</author>
<date month="November" year="2003"/>
<abstract>
<t>This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3611"/>
<format octets="126736" target="http://www.rfc-editor.org/rfc/rfc3611.txt" type="TXT"/>
</reference>
<reference anchor="RFC5450">
<front>
<title>Transmission Time Offsets in RTP Streams</title>
<author fullname="D. Singer" initials="D." surname="Singer">
<organization/>
</author>
<author fullname="H. Desineni" initials="H." surname="Desineni">
<organization/>
</author>
<date month="March" year="2009"/>
<abstract>
<t>This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5450"/>
<format octets="17073" target="http://www.rfc-editor.org/rfc/rfc5450.txt" type="TXT"/>
</reference>
<reference anchor="RFC5484">
<front>
<title>Associating Time-Codes with RTP Streams</title>
<author fullname="D. Singer" initials="D." surname="Singer">
<organization/>
</author>
<date month="March" year="2009"/>
<abstract>
<t>This document describes a mechanism for associating \%time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5484"/>
<format octets="25408" target="http://www.rfc-editor.org/rfc/rfc5484.txt" type="TXT"/>
</reference>
<reference anchor="RFC5760">
<front>
<title>RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback</title>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization/>
</author>
<author fullname="J. Chesterfield" initials="J." surname="Chesterfield">
<organization/>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization/>
</author>
<date month="February" year="2010"/>
<abstract>
<t>This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5760"/>
<format octets="160368" target="http://www.rfc-editor.org/rfc/rfc5760.txt" type="TXT"/>
</reference>
<reference anchor="RFC6051">
<front>
<title>Rapid Synchronisation of RTP Flows</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<author fullname="T. Schierl" initials="T." surname="Schierl">
<organization/>
</author>
<date month="November" year="2010"/>
<abstract>
<t>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.</t><t> 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. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6051"/>
<format octets="53503" target="http://www.rfc-editor.org/rfc/rfc6051.txt" type="TXT"/>
</reference>
<reference anchor="uRTR">
<front>
<title>RTP Timestamp Frequency for Variable Rate Audio Codecs</title>
<author fullname="Stephen Wenger" initials="S" surname="Wenger">
<organization/>
</author>
<author fullname="Colin Perkins" initials="C" surname="Perkins">
<organization/>
</author>
<date month="October" year="2004"/>
<abstract>
<t>
This memo discusses the problems of audio codecs with variable external sampling rates.
Historically, for audio codecs, the RTP timestamp frequency was chosen to match the sampling rate of the audio codec.
However, this choice is nowadays more difficult to justify, because of the advent of audio codecs (and, even more important, practical use cases) that support multiple sample rates and the switch between the sample rates during the lifetime of an RTP session.
This Internet draft addresses the problem by suggesting that RTP Payload RFCs for such codecs to utilize a single, high, unified RTP timestamp frequency.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-avt-variable-rate-audio-00"/>
</reference>
</references>
<section title="Using a fixed clock rate">
<t>
An alternate way of fixing the multiple clock rates issue was proposed in <xref target="uRTR"/>.
This document proposed to define a unified clock rate, but the proposal was rejected at IETF 61.
</t>
</section>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between draft-ietf-avtext-multiple-clock-rates-01 and draft-ietf-avtext-multiple-clock-rates-00">
<t>
<list style="symbols">
<t>New text says that the algorithms listed are the one currently known.</t>
<t>Explains capture_time.</t>
<t>Nits.</t>
</list>
</t>
</section>
<section title="Modifications between draft-ietf-avtext-multiple-clock-rates-00 and draft-petithuguenin-avtext-multiple-clock-rates-01">
<t>
<list style="symbols">
<t>Changed capture_state to capture_start.</t>
</list>
</t>
</section>
<section title="Modifications between draft-petithuguenin-avtext-multiple-clock-rates-01 and draft-petithuguenin-avtext-multiple-clock-rates-00">
<t>
<list style="symbols">
<t>Clarified the goals for this documents</t>
<t>Removed the non-monotonic method (replaced by Magnus formula).</t>
<t>Moved the "RTP Sender and RTP Receiver section inside a new "Recommendations" section.</t>
<t>Inserted the new Sender formula inside the Recommendation section.</t>
<t>Inserted the new jitter formula in the RTP Receiver section.</t>
<t>Emptied the Analysis sections.</t>
</list>
</t>
</section>
<section title="Modifications between draft-petithuguenin-avtext-multiple-clock-rates-00 and draft-petithuguenin-avt-multiple-clock-rates-03">
<t>
<list style="symbols">
<t>Initial release for avtext WG.</t>
</list>
</t>
</section>
<section title="Modifications between draft-petithuguenin-avt-multiple-clock-rates-03 and draft-petithuguenin-avt-multiple-clock-rates-02">
<t>
<list style="symbols">
<t>Updated RFC reference.</t>
</list>
</t>
</section>
<section title="Modifications between draft-petithuguenin-avt-multiple-clock-rates-02 and draft-petithuguenin-avt-multiple-clock-rates-01">
<t>
<list style="symbols">
<t>Having multiple SRs in a compound RTCP packet is OK.</t>
<t>If RTCP is used, must send a BYE and not reuse the SSRC.</t>
<t>Removed resolved notes.</t>
<t>Acknowledged SIPit 26 survey.</t>
<t>Fixed some nits.</t>
</list>
</t>
</section>
<section title="Modifications between draft-petithuguenin-avt-multiple-clock-rates-01 and draft-petithuguenin-avt-multiple-clock-rates-00">
<t>
<list style="symbols">
<t>Complete rewrite as a Standard Track I-D modifying RFC 3550.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:03:53 |