One document matched: draft-petithuguenin-avt-multiple-clock-rates-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<?rfc compact="yes" ?><?rfc strict="no" ?><?rfc symrefs="yes" ?><?rfc toc="yes" ?><rfc ipr="trust200902" docName="draft-petithuguenin-avt-multiple-clock-rates-02" category="std" updates="3550">
<front>
<title abbrev="Multiple Clock Rates">Support for multiple clock rates in an RTP session</title>
<author initials="M.P.H" surname="Petit-Huguenin" fullname="Marc Petit-Huguenin">
<organization>Unaffiliated</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="10" month="July" year="2010"/>
<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 changes the RTP specification by recommending to use a different SSRC for each clock rate in most of the cases.
</t>
</section>
<section 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>
<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 subsections present two variants.
</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 anchor="method3" title="Non-monotonic timestamps">
<t>
An alternate way of generating the RTP timestamps is to use the following formula:
</t>
<t>
timestamp = capture_time * clock_rate
</t>
<t>
With this formula, the jitter calculation is correct but the RTP timestamp values are no longer increasing monotonically as shown in <xref target="non-monotonic"/>.
RFC 3550 states that "[t]he sampling instant MUST be derived from a clock that increments monotonically[...]" but nowhere says that the RTP timestamp must increment monotonically.
</t>
<texttable anchor="non-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>1280</c><c>0.18</c><c>1600</c><c>0</c><c>0</c>
<c>0.1</c><c>16000</c><c>1600</c><c>0.2</c><c>1600</c><c>0</c><c>0</c>
<c>0.12</c><c>16000</c><c>1920</c><c>0.22</c><c>1600</c><c>0</c><c>0</c>
<c>0.14</c><c>16000</c><c>2240</c><c>0.24</c><c>1600</c><c>0</c><c>0</c>
<c>0.16</c><c>16000</c><c>2560</c><c>0.26</c><c>1600</c><c>0</c><c>0</c>
<c>0.14</c><c>8000</c><c>1120</c><c>0.24</c><c>800</c><c>0</c><c>0</c>
<c>0.16</c><c>8000</c><c>1280</c><c>0.26</c><c>800</c><c>0</c><c>0</c>
</texttable>
<t>
The advantage with this method is that it works with the jitter calculation described in RFC 3550, a long as the correct clock rates are used.
</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 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 is calculated as described in <xref target="method3"/>.
</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>
The RTP extension defined in <xref target="RAPID-SYNC"/> MAY be used to accelerate the synchronization.
</t>
</section>
<section title="RTP Receiver">
<t>
An RTP Receiver MUST be able to handle clock rate changes either on the same SSRC (<xref target="method1"/>) or on different SSRC (<xref target="method3"/>).
</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 title="Interoperability Analysis">
<t>
The next subsections analyze the various combinations between legacy RTP implementations and RTP implementations that follow this document specifications.
</t>
<section title="Legacy RTP Sender using different SSRC sending to new RTP Receiver">
<t>
Because a specific clock rate is associated to a specific SSRC, there is no ambiguity in the RTP timestamp received in the RTP packet or SR packet or in the jitter sent in the RR packet.
</t>
</section>
<section title="Legacy RTP Sender using same SSRC with monotonic timestamps sending to new RTP Receiver">
<t>
The new RTP Receiver will not be able to rebuild the correct RTP timestamp so the jitter will be incorrect.
Note that this is not different than if a legacy RTP Receiver is used.
</t>
</section>
<section title="Legacy RTP Sender using same SSRC with non-monotonic timestamps sending to new RTP Receiver">
<t>TBD
</t>
</section>
<section title="New RTP Sender using different SSRC sending to legacy RTP Receiver">
<t>
Because a specific clock rate is associated to a specific SSRC, there is no ambiguity in the RTP timestamp received in the RTP packet or SR packet or in the jitter sent in the RR packet.
Some legacy RTP implementations may have problems when receiving multiple SR packets.
</t>
</section>
<section title="New RTP Sender using different SSRC sending to new RTP Receiver">
<t>
Because a specific clock rate is associated to a specific SSRC, there is no ambiguity in the RTP timestamp received in the RTP packet or SR packet or in the jitter sent in the RR packet.
</t>
</section>
<section title="New RTP Sender using same SSRC with non-monotonic timestamps to legacy RTP Receiver">
<t>
Because this combination is used only when no RTCP packets are exchanged, there is no problem interpreting the RTCP field units.
Some legacy RTP implementations may have problems if the jitter clock rates are not correctly managed.
</t>
</section>
<section title="New RTP Sender using same SSRC with non-monotonic timestamps to new RTP Receiver">
<t>
Because this combination is used only when no RTCP packets are exchanged, there is no problem interpreting the RTCP field units.
</t>
</section>
</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 and Ali C. Begen for their comments, suggestions and questions that helped to improve this document.</t>
<t>Thanks to Robert Sparks and the attendants 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 xmlns:xi="http://www.w3.org/2001/XInclude" title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott 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 year="1997" month="March"/>
<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 type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/>
<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization/></author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization/></author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
<organization/></author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization/></author>
<date year="2003" month="July"/>
<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 type="TXT" octets="259985" target="http://www.rfc-editor.org/rfc/rfc3550.txt"/>
<format type="PS" octets="630740" target="http://www.rfc-editor.org/rfc/rfc3550.ps"/>
<format type="PDF" octets="504117" target="http://www.rfc-editor.org/rfc/rfc3550.pdf"/>
</reference>
</references>
<references xmlns:xi="http://www.w3.org/2001/XInclude" title="Informative References">
<reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author initials="M.T." surname="Rose" fullname="Marshall T. 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 year="1999" month="June"/>
<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 type="TXT" octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt"/>
<format type="HTML" octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html"/>
<format type="XML" octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml"/>
</reference>
<reference anchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization/></author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization/></author>
<date year="2003" month="July"/>
<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 type="TXT" octets="106621" target="http://www.rfc-editor.org/rfc/rfc3551.txt"/>
<format type="PS" octets="317286" target="http://www.rfc-editor.org/rfc/rfc3551.ps"/>
<format type="PDF" octets="237831" target="http://www.rfc-editor.org/rfc/rfc3551.pdf"/>
</reference>
<reference anchor="RFC3556">
<front>
<title>Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth</title>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization/></author>
<date year="2003" month="July"/>
<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 type="TXT" octets="15310" target="http://www.rfc-editor.org/rfc/rfc3556.txt"/>
</reference>
<reference anchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author initials="T." surname="Friedman" fullname="T. Friedman">
<organization/></author>
<author initials="R." surname="Caceres" fullname="R. Caceres">
<organization/></author>
<author initials="A." surname="Clark" fullname="A. Clark">
<organization/></author>
<date year="2003" month="November"/>
<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 type="TXT" octets="126736" target="http://www.rfc-editor.org/rfc/rfc3611.txt"/>
</reference>
<reference anchor="RFC5450">
<front>
<title>Transmission Time Offsets in RTP Streams</title>
<author initials="D." surname="Singer" fullname="D. Singer">
<organization/></author>
<author initials="H." surname="Desineni" fullname="H. Desineni">
<organization/></author>
<date year="2009" month="March"/>
<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 type="TXT" octets="17073" target="http://www.rfc-editor.org/rfc/rfc5450.txt"/>
</reference>
<reference anchor="RFC5484">
<front>
<title>Associating Time-Codes with RTP Streams</title>
<author initials="D." surname="Singer" fullname="D. Singer">
<organization/></author>
<date year="2009" month="March"/>
<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 type="TXT" octets="25408" target="http://www.rfc-editor.org/rfc/rfc5484.txt"/>
</reference>
<reference anchor="RFC5760">
<front>
<title>RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback</title>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization/></author>
<author initials="J." surname="Chesterfield" fullname="J. Chesterfield">
<organization/></author>
<author initials="E." surname="Schooler" fullname="E. Schooler">
<organization/></author>
<date year="2010" month="February"/>
<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 type="TXT" octets="160368" target="http://www.rfc-editor.org/rfc/rfc5760.txt"/>
</reference>
<reference anchor="RAPID-SYNC">
<front>
<title>Rapid Synchronisation of RTP Flows</title>
<author initials="C" surname="Perkins" fullname="Colin Perkins">
<organization/>
</author>
<author initials="T" surname="Schierl" fullname="Thomas Schierl">
<organization/>
</author>
<date month="July" day="9" 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. 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.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-avt-rapid-rtp-sync-12"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-rtp-sync-12.txt"/>
</reference>
<reference anchor="uRTR">
<front>
<title>RTP Timestamp Frequency for Variable Rate Audio Codecs</title>
<author initials="S" surname="Wenger" fullname="Stephen Wenger">
<organization/>
</author>
<author initials="C" surname="Perkins" fullname="Colin 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 -02 and -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 -01 and -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 20:57:50 |