draft-ietf-avtext-multiple-clock-rates-01.txt   draft-ietf-avtext-multiple-clock-rates-02.txt 
Network Working Group M. Petit-Huguenin AVTEXT M. Petit-Huguenin
Internet-Draft Stonyfish, Inc. Internet-Draft Unaffiliated
Updates: 3550 (if approved) July 11, 2011 Updates: 3550 (if approved) January 3, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: January 12, 2012 Expires: July 6, 2012
Support for multiple clock rates in an RTP session Support for multiple clock rates in an RTP session
draft-ietf-avtext-multiple-clock-rates-01 draft-ietf-avtext-multiple-clock-rates-02
Abstract Abstract
This document clarifies the RTP specification when different clock This document clarifies the RTP specification when different clock
rates are used in an RTP session. It also provides guidance on how rates are used in an RTP session. It also provides guidance on how
to interoperate with legacy RTP implementations that use multiple to interoperate with legacy RTP implementations that use multiple
clock rates. clock rates.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on July 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 4 2.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 6
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Interoperability Analysis . . . . . . . . . . . . . . . . . . 7 4.2. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Interoperability Analysis . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 11
B.1. Modifications between Appendix B. Behavior of legacy implementations . . . . . . . . . 11
B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 11
B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11
B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 11
B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . . 11
C.1. Modifications between
draft-ietf-avtext-multiple-clock-rates-02 and
draft-ietf-avtext-multiple-clock-rates-01 . . . . . . . . 11
C.2. Modifications between
draft-ietf-avtext-multiple-clock-rates-01 and draft-ietf-avtext-multiple-clock-rates-01 and
draft-ietf-avtext-multiple-clock-rates-00 . . . . . . . . 9 draft-ietf-avtext-multiple-clock-rates-00 . . . . . . . . 12
B.2. Modifications between C.3. Modifications between
draft-ietf-avtext-multiple-clock-rates-00 and draft-ietf-avtext-multiple-clock-rates-00 and
draft-petithuguenin-avtext-multiple-clock-rates-01 . . . . 9 draft-petithuguenin-avtext-multiple-clock-rates-01 . . . . 12
B.3. Modifications between C.4. Modifications between
draft-petithuguenin-avtext-multiple-clock-rates-01 and draft-petithuguenin-avtext-multiple-clock-rates-01 and
draft-petithuguenin-avtext-multiple-clock-rates-00 . . . . 10 draft-petithuguenin-avtext-multiple-clock-rates-00 . . . . 12
B.4. Modifications between C.5. Modifications between
draft-petithuguenin-avtext-multiple-clock-rates-00 and draft-petithuguenin-avtext-multiple-clock-rates-00 and
draft-petithuguenin-avt-multiple-clock-rates-03 . . . . . 10 draft-petithuguenin-avt-multiple-clock-rates-03 . . . . . 12
B.5. Modifications between C.6. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-03 and draft-petithuguenin-avt-multiple-clock-rates-03 and
draft-petithuguenin-avt-multiple-clock-rates-02 . . . . . 10 draft-petithuguenin-avt-multiple-clock-rates-02 . . . . . 12
B.6. Modifications between C.7. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-02 and draft-petithuguenin-avt-multiple-clock-rates-02 and
draft-petithuguenin-avt-multiple-clock-rates-01 . . . . . 10 draft-petithuguenin-avt-multiple-clock-rates-01 . . . . . 12
B.7. Modifications between C.8. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-01 and draft-petithuguenin-avt-multiple-clock-rates-01 and
draft-petithuguenin-avt-multiple-clock-rates-00 . . . . . 10 draft-petithuguenin-avt-multiple-clock-rates-00 . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The clock rate is a parameter of the payload format. It is often 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 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]). the case (see e.g. the G722 and MPA audio codecs in [RFC3551]).
An RTP sender can switch between different payloads during the An RTP sender can switch between different payloads during the
lifetime of an RTP session and because clock rates are defined by lifetime of an RTP session and because clock rates are defined by
payload types, it is possible that the clock rate also varies during payload types, it is possible that the clock rate also varies during
skipping to change at page 4, line 19 skipping to change at page 5, line 19
algorithms listed in Section 2 are used with the new algorithm listed algorithms listed in Section 2 are used with the new algorithm listed
in Section 4. This sections are not normative. in Section 4. This sections are not normative.
2. Legacy RTP 2. Legacy RTP
The following sections describe the various ways legacy RTP The following sections describe the various ways legacy RTP
implementations behave when multiple clock rates are used. Legacy implementations behave when multiple clock rates are used. Legacy
RTP refers to RFC 3550 without the modifications introduced by this RTP refers to RFC 3550 without the modifications introduced by this
document. document.
[[We need to list here all the methods used in the field. Please
send them to the author. NDA can be arranged if needed]]
2.1. Different SSRC 2.1. Different SSRC
One way of managing multiple clock rates is to use a 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 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 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 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. points 2 and 3 of section 5.2 of RFC 3550.
On the other hand changing the SSRC can be a problem for some On the other hand changing the SSRC can be a problem for some
implementations designed to work only with unicast IP addresses, implementations designed to work only with unicast IP addresses,
skipping to change at page 4, line 44 skipping to change at page 5, line 41
beginning of the new stream and the first RTCP SR packet. This is 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 not different than what happen at the beginning of the RTP session
but it can be more annoying for the end-user. but it can be more annoying for the end-user.
2.2. Same SSRC 2.2. Same SSRC
The simplest way of managing multiple clock rates is to use the same The simplest way of managing multiple clock rates is to use the same
SSRC for all the payload types regardless of the clock rates. SSRC for all the payload types regardless of the clock rates.
Unfortunately there is no clear definition on how the RTP timestamp Unfortunately there is no clear definition on how the RTP timestamp
should be calculated in this case. The following subsection presents should be calculated in this case. The following subsections present
one algorithm used in the field. the algorithms used in the field.
2.2.1. Monotonic timestamps 2.2.1. Monotonic timestamps
The most common method of calculating the RTP timestamp ensures that This method of calculating the RTP timestamp ensures that the value
the value increases monotonically. The formula used by this method increases monotonically. The formula used by this method is as
is as follow: follow:
timestamp = previous_timestamp + (current_capture_time - timestamp = previous_timestamp + (current_capture_time -
previous_capture_time) * current_clock_rate previous_capture_time) * current_clock_rate
The problem with this method is that the jitter calculation on the The problem with this method is that the jitter calculation on the
receiving side gives invalid result during the transition between two receiving side gives invalid result during the transition between two
clock rates, as shown in Table 2. The capture and arrival time are 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 in seconds, starting at the beginning of the capture of the first
packet; clock rate is in Hz; the RTP timestamp does not include the packet; clock rate is in Hz; the RTP timestamp does not include the
random offset; the transit, jitter, and average jitter use the clock random offset; the transit, jitter, and average jitter use the clock
rate as unit. rate as unit.
+-------+-------+-----------+---------+---------+--------+----------+ +-------+-------+-----------+---------+---------+--------+----------+
| Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average |
skipping to change at page 5, line 45 skipping to change at page 6, line 41
(1) current_time_capture = current_timestamp - previous_timestamp) / (1) current_time_capture = current_timestamp - previous_timestamp) /
current_clock_rate + previous_time_capture current_clock_rate + previous_time_capture
(2) transit = current_clock_rate * (time_arrival - (2) transit = current_clock_rate * (time_arrival -
current_time_capture) current_time_capture)
(3) previous_time_capture = current_time_capture (3) previous_time_capture = current_time_capture
The main problem with this method, in addition to the fact that the 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 jitter calculation described in RFC 3550 cannot be used, is that is
it dependent on the previous RTP packets, packets that can be it dependent on the previous RTP packets, packets that can be
reordered or lost in the network. But it seems that this is what reordered or lost in the network.
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.
+-------+-------+-----------+---------+---------+--------+----------+
| 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 | 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, as long as the correct clock rates
are used. It seems that this is what most implementations are using.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Clock rate: The multiplier used to convert from a wallclock value in Clock rate: The multiplier used to convert from a wallclock value in
seconds to an equivalent RTP timestamp value (without the fixed seconds to an equivalent RTP timestamp value (without the fixed
random offset). Note that RFC 3550 uses various terms like "clock random offset). Note that RFC 3550 uses various terms like "clock
skipping to change at page 9, line 31 skipping to change at page 11, line 12
Variable Rate Audio Codecs", Variable Rate Audio Codecs",
draft-ietf-avt-variable-rate-audio-00 (work in progress), draft-ietf-avt-variable-rate-audio-00 (work in progress),
October 2004. October 2004.
Appendix A. Using a fixed clock rate Appendix A. Using a fixed clock rate
An alternate way of fixing the multiple clock rates issue was An alternate way of fixing the multiple clock rates issue was
proposed in [uRTR]. This document proposed to define a unified clock proposed in [uRTR]. This document proposed to define a unified clock
rate, but the proposal was rejected at IETF 61. rate, but the proposal was rejected at IETF 61.
Appendix B. Release notes Appendix B. Behavior of legacy implementations
B.1. libccrtp 2.0.2
This library uses the formula described in Section 2.2.2.
Note that this library uses gettimeofday(2) which is not guaranteed
to increment monotonically, like when the clock is adjusted by NTP.
B.2. libmediastreamer0 2.6.0
This library (which uses the oRTP library) uses the formula described
in Section 2.2.2.
Note that in some environments this library uses gettimeofday(2)
which is not guaranteed to increment monotonically.
B.3. libpjmedia 1.0
This library uses the formula described in Section 2.2.2.
B.4. Android RTP stack 4.0.3
This library changes the SSRC each time the format changes, as
described in Section 2.1.
Appendix C. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
B.1. Modifications between draft-ietf-avtext-multiple-clock-rates-01 C.1. Modifications between draft-ietf-avtext-multiple-clock-rates-02
and draft-ietf-avtext-multiple-clock-rates-01
o Readded the non-monotonic methods that was removed in a previous
version.
o Added analysis of FOSS RTP stacks.
o Changed author affiliation.
o Added AVTEXT area.
C.2. Modifications between draft-ietf-avtext-multiple-clock-rates-01
and draft-ietf-avtext-multiple-clock-rates-00 and draft-ietf-avtext-multiple-clock-rates-00
o New text says that the algorithms listed are the one currently o New text says that the algorithms listed are the one currently
known. known.
o Explains capture_time. o Explains capture_time.
o Nits. o Nits.
B.2. Modifications between draft-ietf-avtext-multiple-clock-rates-00 C.3. Modifications between draft-ietf-avtext-multiple-clock-rates-00
and draft-petithuguenin-avtext-multiple-clock-rates-01 and draft-petithuguenin-avtext-multiple-clock-rates-01
o Changed capture_state to capture_start. o Changed capture_state to capture_start.
B.3. Modifications between C.4. Modifications between
draft-petithuguenin-avtext-multiple-clock-rates-01 and draft-petithuguenin-avtext-multiple-clock-rates-01 and
draft-petithuguenin-avtext-multiple-clock-rates-00 draft-petithuguenin-avtext-multiple-clock-rates-00
o Clarified the goals for this documents o Clarified the goals for this documents
o Removed the non-monotonic method (replaced by Magnus formula). o Removed the non-monotonic method (replaced by Magnus formula).
o Moved the "RTP Sender and RTP Receiver section inside a new o Moved the "RTP Sender and RTP Receiver section inside a new
"Recommendations" section. "Recommendations" section.
o Inserted the new Sender formula inside the Recommendation section. o Inserted the new Sender formula inside the Recommendation section.
o Inserted the new jitter formula in the RTP Receiver section. o Inserted the new jitter formula in the RTP Receiver section.
o Emptied the Analysis sections. o Emptied the Analysis sections.
B.4. Modifications between C.5. Modifications between
draft-petithuguenin-avtext-multiple-clock-rates-00 and draft-petithuguenin-avtext-multiple-clock-rates-00 and
draft-petithuguenin-avt-multiple-clock-rates-03 draft-petithuguenin-avt-multiple-clock-rates-03
o Initial release for avtext WG. o Initial release for avtext WG.
B.5. Modifications between C.6. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-03 and draft-petithuguenin-avt-multiple-clock-rates-03 and
draft-petithuguenin-avt-multiple-clock-rates-02 draft-petithuguenin-avt-multiple-clock-rates-02
o Updated RFC reference. o Updated RFC reference.
B.6. Modifications between C.7. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-02 and draft-petithuguenin-avt-multiple-clock-rates-02 and
draft-petithuguenin-avt-multiple-clock-rates-01 draft-petithuguenin-avt-multiple-clock-rates-01
o Having multiple SRs in a compound RTCP packet is OK. o Having multiple SRs in a compound RTCP packet is OK.
o If RTCP is used, must send a BYE and not reuse the SSRC. o If RTCP is used, must send a BYE and not reuse the SSRC.
o Removed resolved notes. o Removed resolved notes.
o Acknowledged SIPit 26 survey. o Acknowledged SIPit 26 survey.
o Fixed some nits. o Fixed some nits.
B.7. Modifications between C.8. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-01 and draft-petithuguenin-avt-multiple-clock-rates-01 and
draft-petithuguenin-avt-multiple-clock-rates-00 draft-petithuguenin-avt-multiple-clock-rates-00
o Complete rewrite as a Standard Track I-D modifying RFC 3550. o Complete rewrite as a Standard Track I-D modifying RFC 3550.
Author's Address Author's Address
Marc Petit-Huguenin Marc Petit-Huguenin
Stonyfish, Inc. Unaffiliated
Email: petithug@acm.org Email: petithug@acm.org
 End of changes. 28 change blocks. 
60 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/