Network Working Group M. Petit-Huguenin
Internet-Draft (Unaffiliated)
Intended status: Standards Track September 30, 2009
Expires: April 3, 2010
Support for multiple clock rates in an RTP session
draft-petithuguenin-avt-multiple-clock-rates-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 3, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
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.
Petit-Huguenin Expires April 3, 2010 [Page 1]
Internet-Draft Multiple Clock Rates September 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RTP Sender behavior . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Use the current clock rate . . . . . . . . . . . . . . . . 4
3.2. Use a fixed clock rate . . . . . . . . . . . . . . . . . . 4
3.3. Use a different SSRC . . . . . . . . . . . . . . . . . . . 5
3.4. Preferred RTP Sender behavior . . . . . . . . . . . . . . . 5
4. Receiver Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Use the current RTP clock rate . . . . . . . . . . . . . . 5
4.2. Guessing the clock rate . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 7
A.1. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 7
A.2. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Petit-Huguenin Expires April 3, 2010 [Page 2]
Internet-Draft Multiple Clock Rates September 2009
1. Introduction
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 [RFC3551]).
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.
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.
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.
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.
Table 1 contains a non-exhaustive list of fields in RTCP packets that
use a clock rate:
+---------------------+------------------+------------------------+
| Field name | RTCP packet type | Reference |
+---------------------+------------------+------------------------+
| RTP timestamp | SR | [RFC3550] |
| Interarrival jitter | RR | [RFC3550] |
| min_jitter | XR Summary Block | [RFC3611] |
| max_jitter | XR Summary Block | [RFC3611] |
| mean_jitter | XR Summary Block | [RFC3611] |
| dev_jitter | XR Summary Block | [RFC3611] |
| Interarrival jitter | IJ | [RFC5450] |
| RTP timestamp | SMPTETC | [RFC5484] |
| Jitter | RSI Jitter Block | [I-D.ietf-avt-rtcpssm] |
| Median jitter | RSI Stats Block | [I-D.ietf-avt-rtcpssm] |
+---------------------+------------------+------------------------+
Table 1
Petit-Huguenin Expires April 3, 2010 [Page 3]
Internet-Draft Multiple Clock Rates September 2009
2. Terminology
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 [RFC2119].
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 [RFC3550] uses various terms like
"clock frequency", "media clock rate", "timestamp unit",
"timestamp frequency" and "RTP timestamp clock rate" as synonymous
to clock rate.
RTP Sender: A logical network element that sends RTP packets and
sends and receives RTCP packets.
RTP Receiver: A logical network element that receives RTP packets
and sends and receives RTCP packets.
3. RTP Sender behavior
An RTP sender can choose to implement a change in clock rate in
various ways.
3.1. Use the current clock rate
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.
Pros:
* It is probably the simplest behavior to implement and various
implementations already follow this behavior.
Cons:
* This behavior seems to contradict [RFC3550] section 5.2.
* It is difficult for an RTCP receiver to guess the clock rate
used in the RTCP packets.
3.2. Use a fixed clock rate
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.
There is different possible ways to choose this fixed clock rate:
o The first clock rate used on the RTP session.
o The highest clock rate that can be used on the RTP session.
Petit-Huguenin Expires April 3, 2010 [Page 4]
Internet-Draft Multiple Clock Rates September 2009
o A unified clok rate, as defined in uRTR
[I-D.ietf-avt-variable-rate-audio].
Pros:
* It is simple to implement.
Cons:
* There is obvious compatibility issues with implementations
using a different behavior.
* The fixed clock rate must be an integer multiple of the
possible clock rates.
* uRTR was rejected at IETF 61.
3.3. Use a different SSRC
Instead of using various clock rates in the same SSRC, an RTP sender
can use a different SSRC for each clock rate.
Pros:
* It is compliant with [RFC3550] section 5.2.
* 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.
Cons:
* 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 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 [I-D.ietf-avt-rapid-rtp-sync] can be
used to accelerate the synchronization.
3.4. Preferred RTP Sender behavior
TBD
4. Receiver Behavior
4.1. Use the current RTP clock rate
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.
Petit-Huguenin Expires April 3, 2010 [Page 5]
Internet-Draft Multiple Clock Rates September 2009
4.2. Guessing the clock rate
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).
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. Acknowledgements
This document was written with the xml2rfc tool described in
[RFC2629].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
Petit-Huguenin Expires April 3, 2010 [Page 6]
Internet-Draft Multiple Clock Rates September 2009
November 2003.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams",
RFC 5484, March 2009.
[I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-05 (work in
progress), July 2009.
[I-D.ietf-avt-rtcpssm]
Schooler, E., Ott, J., and J. Chesterfield, "RTCP
Extensions for Single-Source Multicast Sessions with
Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in
progress), March 2009.
[I-D.ietf-avt-variable-rate-audio]
Wenger, S. and C. Perkins, "RTP Timestamp Frequency for
Variable Rate Audio Codecs",
draft-ietf-avt-variable-rate-audio-00 (work in progress),
October 2004.
Appendix A. Release notes
This section must be removed before publication as an RFC.
A.1. Design Notes
(Empty)
A.2. TODO List
o Is it possible to guess the clock rate used in consecutive jitter
values?
Author's Address
Marc Petit-Huguenin
(Unaffiliated)
Email: petithug@acm.org
Petit-Huguenin Expires April 3, 2010 [Page 7]