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.

Table of Contents

1.  Introduction
2.  Terminology
3.  RTP Sender behavior
    3.1.  Use the current clock rate
    3.2.  Use a fixed clock rate
    3.3.  Use a different SSRC
    3.4.  Preferred RTP Sender behavior
4.  Receiver Behavior
    4.1.  Use the current RTP clock rate
    4.2.  Guessing the clock rate
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Release notes
    A.1.  Design Notes
    A.2.  TODO List
§  Author's Address

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] (Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” July 2003.)).

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:

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) 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] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) 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:

• The first clock rate used on the RTP session.
• The highest clock rate that can be used on the RTP session.
• A unified clok rate, as defined in uRTR (Wenger, S. and C. Perkins, “RTP Timestamp Frequency for Variable Rate Audio Codecs,” October 2004.) [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] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) 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] (Perkins, C. and T. Schierl, “Rapid Synchronisation of RTP Flows,” July 2009.) 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.

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] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.).

8.  References

8.1. Normative References

8.2. Informative References

Appendix A.  Release notes

This section must be removed before publication as an RFC.

A.1.  Design Notes

(Empty)

A.2.  TODO List

• Is it possible to guess the clock rate used in consecutive jitter values?

Author's Address