One document matched: draft-petithuguenin-avt-multiple-clock-rates-00.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-00" category="std">
<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="30" month="September" year="2009"/>
<abstract>
<t>
The usage of multiple clock rates in an RTP session is currently underspecified.
This document lists multiple ways to fix this problem and is meant as a support for discussion.
</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.
</t>
<t>
Changing the clock rate during an RTP session is not a problem for the RTP receiver, as it always knows the clock rate associated with a specific RTP packet.
The RTP receiver also has no problem calculating a clock rate independent interarrival jitter.
</t>
<t>
The problem is with reports carried in RTCP packets that contain fields using units based on the clock rate.
Because the RTCP packets do not contain a field for the payload type, it is difficult for a sender to choose or for a receiver to guess which clock rate to use for this fields.
</t>
<t>
For example, lip synchronization can be incorrect if the RTP timestamp in the RTCP SR packet use a different clock rate than expected by the receiver.
</t>
<t><xref target="fields"/> contains a non-exhaustive list of fields in RTCP packets that use a clock rate:</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="I-D.ietf-avt-rtcpssm"/></c>
<c>Median jitter</c> <c>RSI Stats Block</c> <c><xref target="I-D.ietf-avt-rtcpssm"/></c>
</texttable>
</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 <xref target="RFC3550"/> 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 and sends and receives RTCP packets.
</t>
<t hangText="RTP Receiver:">
A logical network element that receives RTP packets and sends and receives RTCP packets.
</t>
</list>
</t>
</section>
<section title="RTP Sender behavior">
<t>
An RTP sender can choose to implement a change in clock rate in various ways.
</t>
<section title="Use the current clock rate">
<t>
A RTP sender can switch between payload types set with different clock rates on the same SSRC.
The RTP sender uses the current clock rate as the unit for the fields in the RTCP packets sent.
</t>
<t>
<list style="hanging">
<t hangText="Pros:">
<list style="symbols">
<t>It is probably the simplest behavior to implement and various implementations already follow this behavior.</t>
</list>
</t>
<t hangText="Cons:">
<list style="symbols">
<t>This behavior seems to contradict <xref target="RFC3550"/> section 5.2.</t>
<t>It is difficult for an RTCP receiver to guess the clock rate used in the RTCP packets.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Use a fixed clock rate">
<t>
As in the previous section, the RTP sender switches between different clock rates on the same SSRC, but it always uses the same clock rate as the unit for the fields in the RTCP packets sent.
</t>
<t>There is different possible ways to choose this fixed clock rate:
<list style="symbols">
<t>The first clock rate used on the RTP session.</t>
<t>The highest clock rate that can be used on the RTP session.</t>
<t>A unified clok rate, as defined in <xref target="I-D.ietf-avt-variable-rate-audio">uRTR</xref>.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Pros:">
<list style="symbols">
<t>It is simple to implement.</t>
</list>
</t>
<t hangText="Cons:">
<list style="symbols">
<t>There is obvious compatibility issues with implementations using a different behavior.</t>
<t>The fixed clock rate must be an integer multiple of the possible clock rates.</t>
<t>uRTR was rejected at IETF 61.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Use a different SSRC">
<t>
Instead of using various clock rates in the same SSRC, an RTP sender can use a different SSRC for each clock rate.
</t>
<t>
<list style="hanging">
<t hangText="Pros:">
<list style="symbols">
<t>It is compliant with <xref target="RFC3550"/> section 5.2.</t>
<t>As there can be be only one possible clock rate on a specific SSRC, there is no ambiguity in the clock rate used in the RTCP packets.</t>
</list>
</t>
<t hangText="Cons:">
<list style="symbols">
<t>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.</t>
<t>
Lip synchronization can 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.
The RTP extension defined in <xref target="I-D.ietf-avt-rapid-rtp-sync"/> can be used to accelerate the synchronization.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Preferred RTP Sender behavior">
<t>TBD</t>
</section>
</section>
<section title="Receiver Behavior">
<section title="Use the current RTP clock rate">
<t>
An RTP Receiver can use the clock rate associated with the current payload received in the RTP packets. There is a race condition between the RTP and the RTCP packets that can create transient problems.
Also this method does not work for an RTCP monitor (i.e. an RTCP receiver that does not receive the RTP packets).
This method will not work either if a fixed clock rate is used.
</t>
</section>
<section title="Guessing the clock rate">
<t>
Instead of using the current RTP clock rate, an RTP receiver can 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 title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
<section title="Acknowledgements">
<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" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<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="ftp://ftp.isi.edu/in-notes/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" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<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="ftp://ftp.isi.edu/in-notes/rfc3550.txt"/>
<format type="PS" octets="630740" target="ftp://ftp.isi.edu/in-notes/rfc3550.ps"/>
<format type="PDF" octets="504117" target="ftp://ftp.isi.edu/in-notes/rfc3550.pdf"/>
</reference>
</references>
<references xmlns:xi="http://www.w3.org/2001/XInclude" title="Informative References">
<reference anchor="RFC2629" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<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="ftp://ftp.isi.edu/in-notes/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" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<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="ftp://ftp.isi.edu/in-notes/rfc3551.txt"/>
<format type="PS" octets="317286" target="ftp://ftp.isi.edu/in-notes/rfc3551.ps"/>
<format type="PDF" octets="237831" target="ftp://ftp.isi.edu/in-notes/rfc3551.pdf"/>
</reference>
<reference anchor="RFC3611" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<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="ftp://ftp.isi.edu/in-notes/rfc3611.txt"/>
</reference>
<reference anchor="RFC5450" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5450.xml">
<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="ftp://ftp.isi.edu/in-notes/rfc5450.txt"/>
</reference>
<reference anchor="RFC5484" xml:base="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5484.xml">
<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="ftp://ftp.isi.edu/in-notes/rfc5484.txt"/>
</reference>
<reference anchor="I-D.ietf-avt-rapid-rtp-sync" xml:base="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rapid-rtp-sync.xml">
<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="13" year="2009"/>
<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-05"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-rtp-sync-05.txt"/>
</reference>
<reference anchor="I-D.ietf-avt-rtcpssm" xml:base="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rtcpssm.xml">
<front>
<title>RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback</title>
<author initials="E" surname="Schooler" fullname="Eve Schooler">
<organization/>
</author>
<author initials="J" surname="Ott" fullname="Joerg Ott">
<organization/>
</author>
<author initials="J" surname="Chesterfield" fullname="Julian Chesterfield">
<organization/>
</author>
<date month="March" day="26" year="2009"/>
<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 not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Ott et al. Internet Draft - Expires Sept 2009 [page 2] RTCP with Unicast Feedback</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-avt-rtcpssm-18"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-18.txt"/>
</reference>
<reference anchor="I-D.ietf-avt-variable-rate-audio">
<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="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Design Notes">
<t>(Empty)
</t>
</section>
<section title="TODO List">
<t>
<list style="symbols">
<t>Is it possible to guess the clock rate used in consecutive jitter values?</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:39:42 |