Network Working Group                                  M. Petit-Huguenin
Internet-Draft                                            (Unaffiliated)
Updates: 3550 (if approved)                                March 8, 2010
Intended status: Standards Track
Expires: September 9, 2010


           Support for multiple clock rates in an RTP session
            draft-petithuguenin-avt-multiple-clock-rates-01

Abstract

   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.

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 September 9, 2010.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of



Petit-Huguenin          Expires September 9, 2010               [Page 1]


Internet-Draft            Multiple Clock Rates                March 2010


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Different SSRC . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Same SSRC  . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.2.1.  Monotonic timestamps . . . . . . . . . . . . . . . . .  4
       2.2.2.  Non-monotonic timestamps . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Interoperability Analysis  . . . . . . . . . . . . . . . . . .  7
     6.1.  Legacy RTP Sender using different SSRC sending to new
           RTP Receiver . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  Legacy RTP Sender using same SSRC with monotonic
           timestamps sending to new RTP Receiver . . . . . . . . . .  8
     6.3.  Legacy RTP Sender using same SSRC with non-monotonic
           timestamps sending to new RTP Receiver . . . . . . . . . .  8
     6.4.  New RTP Sender using different SSRC sending to legacy
           RTP Receiver . . . . . . . . . . . . . . . . . . . . . . .  8
     6.5.  New RTP Sender using different SSRC sending to new RTP
           Receiver . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.6.  New RTP Sender using same SSRC with non-monotonic
           timestamps to legacy RTP Receiver  . . . . . . . . . . . .  8
     6.7.  New RTP Sender using same SSRC with non-monotonic
           timestamps to new RTP Receiver . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Using a fixed clock rate  . . . . . . . . . . . . . . 10
   Appendix B.  Release notes . . . . . . . . . . . . . . . . . . . . 10
     B.1.  Modifications between -01 and -00  . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10







Petit-Huguenin          Expires September 9, 2010               [Page 2]


Internet-Draft            Multiple Clock Rates                March 2010


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.  RTP [RFC3550] 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.

   This creates three problems:
   o  The method used to calculate the RTP timestamp field in an RTP
      packet is underspecified.
   o  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.
   o  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.

   Table 1 contains a non-exhaustive list of fields in RTCP packets that
   uses a clock rate as unit:

          +---------------------+------------------+-----------+
          | 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 | [RFC5760] |
          | Median jitter       | RSI Stats Block  | [RFC5760] |
          +---------------------+------------------+-----------+

                                  Table 1

   This document changes the RTP specification by recommending to use a
   different SSRC for each clock rate in most of the cases.




Petit-Huguenin          Expires September 9, 2010               [Page 3]


Internet-Draft            Multiple Clock Rates                March 2010


2.  Legacy RTP

   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.

   [[Perhaps SIPit would be a good place to collect data on the methods
   used by real implementations]]

2.1.  Different SSRC

   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.

   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.

2.2.  Same SSRC

   The simplest way of managing multiple clock rates is to use the same
   SSRC for all the payload types regardless of the clock rates.

   Unfortunately there is no clear definition on how the RTP timestamp
   should be calculated in this case.  The following subsections present
   two variants.

2.2.1.  Monotonic timestamps

   The most common method of calculating the RTP timestamp ensures that
   the value increases monotonically.  The formula used by this method
   is as follow:

   timestamp = previous_timestamp + (current_capture_time -
   previous_capture_time) * current_clock_rate

   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 Table 2.  The capture and arrival time are
   in seconds, starting at the beginning of the capture of the first



Petit-Huguenin          Expires September 9, 2010               [Page 4]


Internet-Draft            Multiple Clock Rates                March 2010


   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.

   +-------+-------+-----------+---------+---------+--------+----------+
   | Capt. | Clock | RTP       | Arrival | Transit | Jitter | Average  |
   | time  | rate  | timestamp | time    |         |        | jitter   |
   +-------+-------+-----------+---------+---------+--------+----------+
   | 0     | 8000  | 0         | 0.1     | 800     |        |          |
   | 0.02  | 8000  | 160       | 0.12    | 800     | 0      | 0        |
   | 0.04  | 8000  | 320       | 0.14    | 800     | 0      | 0        |
   | 0.06  | 8000  | 480       | 0.16    | 800     | 0      | 0        |
   | 0.08  | 16000 | 800       | 0.18    | 2080    | 480    | 30       |
   | 0.1   | 16000 | 1120      | 0.2     | 2080    | 0      | 28       |
   | 0.12  | 16000 | 1440      | 0.22    | 2080    | 0      | 26       |
   | 0.14  | 8000  | 1600      | 0.24    | 320     | 720    | 70       |
   | 0.16  | 8000  | 1760      | 0.26    | 320     | 0      | 65       |
   +-------+-------+-----------+---------+---------+--------+----------+

                                  Table 2

   Calculating the correct transit time on the receiving side can be
   done by using the following formulas:

   (1)  current_time_capture = current_timestamp - previous_timestamp) /
      current_clock_rate + previous_time_capture
   (2)  transit = current_clock_rate * (time_arrival -
      current_time_capture)
   (3)  previous_time_capture = current_time_capture

   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.

2.2.2.  Non-monotonic timestamps

   An alternate way of generating the RTP timestamps is to use the
   following formula:

   timestamp = capture_time * clock_rate

   With this formula, the jitter calculation is correct but the RTP
   timestamp values are no longer increasing monotonically as shown in
   Table 3.  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.



Petit-Huguenin          Expires September 9, 2010               [Page 5]


Internet-Draft            Multiple Clock Rates                March 2010


   +-------+-------+-----------+---------+---------+--------+----------+
   | Capt. | Clock | RTP       | Arrival | Transit | Jitter | Average  |
   | time  | rate  | timestamp | time    |         |        | jitter   |
   +-------+-------+-----------+---------+---------+--------+----------+
   | 0     | 8000  | 0         | 0.1     | 800     |        |          |
   | 0.02  | 8000  | 160       | 0.12    | 800     | 0      | 0        |
   | 0.04  | 8000  | 320       | 0.14    | 800     | 0      | 0        |
   | 0.06  | 8000  | 480       | 0.16    | 800     | 0      | 0        |
   | 0.08  | 16000 | 1280      | 0.18    | 1600    | 0      | 0        |
   | 0.1   | 16000 | 1600      | 0.2     | 1600    | 0      | 0        |
   | 0.12  | 16000 | 1920      | 0.22    | 1600    | 0      | 0        |
   | 0.14  | 16000 | 2240      | 0.24    | 1600    | 0      | 0        |
   | 0.16  | 16000 | 2560      | 0.26    | 1600    | 0      | 0        |
   | 0.14  | 8000  | 1120      | 0.24    | 800     | 0      | 0        |
   | 0.16  | 8000  | 1280      | 0.26    | 800     | 0      | 0        |
   +-------+-------+-----------+---------+---------+--------+----------+

                                  Table 3

   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.


3.  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 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.
   RTP Sender:  A logical network element that sends RTP packets, sends
      RTCP SR packets and receives RTCP RR packets.
   RTP Receiver:  A logical network element that receives RTP packets,
      receives RTCP SR packets and sends RTCP RR packets.


4.  RTP Sender

   An RTP Sender with RTCP turned off (i.e. by setting the RS and RR
   bandwidth modifiers defined in [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



Petit-Huguenin          Expires September 9, 2010               [Page 6]


Internet-Draft            Multiple Clock Rates                March 2010


   described in Section 2.2.2.

   [[It is probably easier to implement for VoIP products that do not
   use RTCP and so do not care about lip synchronization or jitter
   calculation]]

   An RTP Sender with RTCP turned on MUST use a different SSRC for each
   different clock rate.

   [[Can the SSRC be reused when switching back to the old clock rate
   less than 2T?  If not should a BYE be sent?]]

   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.

   [[Is it authorized by the RTCP syntax to have multiple SR in a
   compound packet?]]

   The RTP extension defined in [RAPID-SYNC] MAY be used to accelerate
   the synchronization.


5.  RTP Receiver

   An RTP Receiver MUST be able to handle clock rate changes either on
   the same SSRC (Section 2.1) or on different SSRC (Section 2.2.2).

   [[What about legacy RTP implementations implementing the method in
   Section 2.2.1?]]

   An RTP Receiver MUST be able to handle a compound RTCP packet with
   multiple SR packets.

   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).


6.  Interoperability Analysis

   The next subsections analyze the various combinations between legacy



Petit-Huguenin          Expires September 9, 2010               [Page 7]


Internet-Draft            Multiple Clock Rates                March 2010


   RTP implementations and RTP implementations that follow this document
   specifications.

6.1.  Legacy RTP Sender using different SSRC sending to new RTP Receiver

   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.

6.2.  Legacy RTP Sender using same SSRC with monotonic timestamps
      sending to new RTP Receiver

   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.

6.3.  Legacy RTP Sender using same SSRC with non-monotonic timestamps
      sending to new RTP Receiver

   TBD

6.4.  New RTP Sender using different SSRC sending to legacy RTP Receiver

   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.

6.5.  New RTP Sender using different SSRC sending to new RTP Receiver

   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.

6.6.  New RTP Sender using same SSRC with non-monotonic timestamps to
      legacy RTP Receiver

   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.

6.7.  New RTP Sender using same SSRC with non-monotonic timestamps to
      new RTP Receiver

   Because this combination is used only when no RTCP packets are
   exchanged, there is no problem interpreting the RTCP field units.




Petit-Huguenin          Expires September 9, 2010               [Page 8]


Internet-Draft            Multiple Clock Rates                March 2010


7.  Security Considerations

   TBD


8.  IANA Considerations

   No IANA considerations.


9.  Acknowledgements

   Thanks to Colin Perkins and Ali C. Begen for their comments,
   suggestions and questions that helped to improve this document.

   This document was written with the xml2rfc tool described in
   [RFC2629].


10.  References

10.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.

10.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.

   [RFC3556]  Casner, S., "Session Description Protocol (SDP) Bandwidth
              Modifiers for RTP Control Protocol (RTCP) Bandwidth",
              RFC 3556, July 2003.

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611,
              November 2003.

   [RFC5450]  Singer, D. and H. Desineni, "Transmission Time Offsets in



Petit-Huguenin          Expires September 9, 2010               [Page 9]


Internet-Draft            Multiple Clock Rates                March 2010


              RTP Streams", RFC 5450, March 2009.

   [RFC5484]  Singer, D., "Associating Time-Codes with RTP Streams",
              RFC 5484, March 2009.

   [RFC5760]  Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
              Protocol (RTCP) Extensions for Single-Source Multicast
              Sessions with Unicast Feedback", RFC 5760, February 2010.

   [RAPID-SYNC]
              Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
              Flows", draft-ietf-avt-rapid-rtp-sync-09 (work in
              progress), January 2010.

   [uRTR]     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.  Using a fixed clock rate

   An alternate way of fixing the multiple clock rates issue was
   proposed in [uRTR].  This document proposed to define a unified clock
   rate, but the proposal was rejected at IETF 61.


Appendix B.  Release notes

   This section must be removed before publication as an RFC.

B.1.  Modifications between -01 and -00

   o  Complete rewrite as a Standard Track I-D modifying RFC 3550.


Author's Address

   Marc Petit-Huguenin
   (Unaffiliated)

   Email: petithug@acm.org









Petit-Huguenin          Expires September 9, 2010              [Page 10]