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]