draft-ietf-avtext-multiple-clock-rates-03.txt   draft-ietf-avtext-multiple-clock-rates-04.txt 
Network Working Group M. Petit-Huguenin Network Working Group M. Petit-Huguenin
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Updates: 3550 (if approved) G. Zorn, Ed. Updates: 3550 (if approved) G. Zorn, Ed.
Intended status: Standards Track Network Zen Intended status: Standards Track Network Zen
Expires: October 24, 2012 April 22, 2012 Expires: October 25, 2012 April 23, 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-03 draft-ietf-avtext-multiple-clock-rates-04
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 October 24, 2012. This Internet-Draft will expire on October 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 6 3.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 5
3.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 7 3.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 6
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 11 Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 10
Appendix B. Behavior of legacy implementations . . . . . . . . . 11 Appendix B. Behavior of Legacy Implementations . . . . . . . . . 10
B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 11 B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 10
B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11 B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 10
B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 11 B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 10
B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11 B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 10
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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-00 . . . . . . . . 12
C.3. Modifications between
draft-ietf-avtext-multiple-clock-rates-00 and
draft-petithuguenin-avtext-multiple-clock-rates-01 . . . . 12
C.4. Modifications between
draft-petithuguenin-avtext-multiple-clock-rates-01 and
draft-petithuguenin-avtext-multiple-clock-rates-00 . . . . 12
C.5. Modifications between
draft-petithuguenin-avtext-multiple-clock-rates-00 and
draft-petithuguenin-avt-multiple-clock-rates-03 . . . . . 12
C.6. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-03 and
draft-petithuguenin-avt-multiple-clock-rates-02 . . . . . 12
C.7. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-02 and
draft-petithuguenin-avt-multiple-clock-rates-01 . . . . . 13
C.8. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-01 and
draft-petithuguenin-avt-multiple-clock-rates-00 . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 [RFC3551]). the case (see e.g. the G722 and MPA audio codecs [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
an RTP session. RTP [RFC3550] lists using multiple clock rates as an RTP session. Schulzrinne, et al. [RFC3550] lists using multiple
one of the reasons to not use different payloads on the same SSRC but clock rates as one of the reasons to not use different payloads on
unfortunately this advice was not always followed and some RTP the same SSRC but unfortunately this advice was not always followed
implementations change the payload in the same SSRC even if the and some RTP implementations change the payload in the same SSRC even
different payloads use different clock rates. if the different payloads use different clock rates.
This creates three problems: This creates three problems:
o The method used to calculate the RTP timestamp field in an RTP o The method used to calculate the RTP timestamp field in an RTP
packet is underspecified. packet is underspecified.
o When the same SSRC is used for different clock rates, it is 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 difficult to know what clock rate was used for the RTP timestamp
field in an RTCP SR packet. field in an RTCP SR packet.
skipping to change at page 5, line 10 skipping to change at page 4, line 10
| Median jitter | RSI Stats Block | [RFC5760] | | Median jitter | RSI Stats Block | [RFC5760] |
+---------------------+------------------+-----------+ +---------------------+------------------+-----------+
Table 1 Table 1
This document first tries to list in Section 3 and subsections all of This document first tries to list in Section 3 and subsections all of
the algorithms known to be used in existing RTP implementations at the algorithms known to be used in existing RTP implementations at
the time of writing. These sections are not normative. the time of writing. These sections are not normative.
Section 4 and subsections then recommend a unique algorithm that Section 4 and subsections then recommend a unique algorithm that
modifies [RFC3550]. These sections are normative. modifies RFC 3550. These sections are normative.
2. Terminology 2. 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]. In document are to be interpreted as described in RFC 2119 [RFC2119].
addition, this document uses the following terms: In addition, this document uses the following terms:
Clock rate The multiplier used to convert from a wallclock value Clock rate The multiplier used to convert from a wallclock value
in seconds to an equivalent RTP timestamp value in seconds to an equivalent RTP timestamp value
(without the fixed random offset). Note that RFC 3550 (without the fixed random offset). Note that RFC 3550
uses various terms like "clock frequency", "media uses various terms like "clock frequency", "media
clock rate", "timestamp unit", "timestamp frequency", clock rate", "timestamp unit", "timestamp frequency",
and "RTP timestamp clock rate" as synonymous to clock and "RTP timestamp clock rate" as synonymous to clock
rate. rate.
RTP Sender A logical network element that sends RTP packets, RTP Sender A logical network element that sends RTP packets,
skipping to change at page 6, line 29 skipping to change at page 5, line 29
This method of calculating the RTP timestamp ensures that the value This method of calculating the RTP timestamp ensures that the value
increases monotonically. The formula used by this method is as increases monotonically. The formula used by this method is as
follows: follows:
timestamp = previous_timestamp timestamp = previous_timestamp
+ (current_capture_time - previous_capture_time) + (current_capture_time - previous_capture_time)
* current_clock_rate * 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 an invalid result during the transition between
clock rates, as shown in Table 2. The capture and arrival time are two clock rates, as shown in Table 2. The capture and arrival time
in seconds, starting at the beginning of the capture of the first are 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 |
| time | rate | timestamp | time | | | jitter | | time | rate | timestamp | time | | | jitter |
+-------+-------+-----------+---------+---------+--------+----------+ +-------+-------+-----------+---------+---------+--------+----------+
| 0 | 8000 | 0 | 0.1 | 800 | | | | 0 | 8000 | 0 | 0.1 | 800 | | |
| 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
skipping to change at page 9, line 36 skipping to change at page 8, line 36
NTP timestamp and RTP timestamp for the previous SR packet j, then 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 - the clock rate can be guessed as the closest to (Ri - Rj) / (Ni -
Nj). Nj).
5. Security Considerations 5. Security Considerations
TBD TBD
6. IANA Considerations 6. IANA Considerations
This document requires no IANA actions.. This document requires no IANA actions.
7. Acknowledgements 7. Acknowledgements
Thanks to Colin Perkins, Ali C. Begen and Magnus Westerlund for their Thanks to Colin Perkins, Ali C. Begen and Magnus Westerlund for their
comments, suggestions and questions that helped to improve this comments, suggestions and questions that helped to improve this
document. document.
Thanks to Robert Sparks and the attendees of SIPit 26 for the survey Thanks to Robert Sparks and the attendees of SIPit 26 for the survey
on multiple clock rates interoperability. on multiple clock rates interoperability.
This document was written with the xml2rfc tool described in This document was written with the xml2rfc tool described in Rose
[RFC2629]. [RFC2629].
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
skipping to change at page 11, line 12 skipping to change at page 10, line 12
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, November 2010.
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 [I-D.ietf-avt-variable-rate-audio]. This document proposed in [I-D.ietf-avt-variable-rate-audio]. This document
proposed to define a unified clock rate, but the proposal was proposed to define a unified clock rate, but the proposal was
rejected at IETF 61. rejected at IETF 61.
Appendix B. Behavior of legacy implementations Appendix B. Behavior of Legacy Implementations
B.1. libccrtp 2.0.2 B.1. libccrtp 2.0.2
This library uses the formula described in Section 3.2.2. This library uses the formula described in Section 3.2.2.
Note that this library uses gettimeofday(2) which is not guaranteed Note that this library uses gettimeofday(2) which is not guaranteed
to increment monotonically, like when the clock is adjusted by NTP. to increment monotonically, like when the clock is adjusted by NTP.
B.2. libmediastreamer0 2.6.0 B.2. libmediastreamer0 2.6.0
skipping to change at page 11, line 38 skipping to change at page 10, line 38
B.3. libpjmedia 1.0 B.3. libpjmedia 1.0
This library uses the formula described in Section 3.2.2. This library uses the formula described in Section 3.2.2.
B.4. Android RTP stack 4.0.3 B.4. Android RTP stack 4.0.3
This library changes the SSRC each time the format changes, as This library changes the SSRC each time the format changes, as
described in Section 3.1. described in Section 3.1.
Appendix C. Release notes
This section must be removed before publication as an RFC.
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
o New text says that the algorithms listed are the one currently
known.
o Explains capture_time.
o Nits.
C.3. Modifications between draft-ietf-avtext-multiple-clock-rates-00
and draft-petithuguenin-avtext-multiple-clock-rates-01
o Changed capture_state to capture_start.
C.4. Modifications between
draft-petithuguenin-avtext-multiple-clock-rates-01 and
draft-petithuguenin-avtext-multiple-clock-rates-00
o Clarified the goals for this documents
o Removed the non-monotonic method (replaced by Magnus formula).
o Moved the "RTP Sender and RTP Receiver section inside a new
"Recommendations" section.
o Inserted the new Sender formula inside the Recommendation section.
o Inserted the new jitter formula in the RTP Receiver section.
o Emptied the Analysis sections.
C.5. Modifications between
draft-petithuguenin-avtext-multiple-clock-rates-00 and
draft-petithuguenin-avt-multiple-clock-rates-03
o Initial release for avtext WG.
C.6. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-03 and
draft-petithuguenin-avt-multiple-clock-rates-02
o Updated RFC reference.
C.7. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-02 and
draft-petithuguenin-avt-multiple-clock-rates-01
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 Removed resolved notes.
o Acknowledged SIPit 26 survey.
o Fixed some nits.
C.8. Modifications between
draft-petithuguenin-avt-multiple-clock-rates-01 and
draft-petithuguenin-avt-multiple-clock-rates-00
o Complete rewrite as a Standard Track I-D modifying RFC 3550.
Authors' Addresses Authors' Addresses
Marc Petit-Huguenin Marc Petit-Huguenin
Unaffiliated Unaffiliated
Email: petithug@acm.org Email: petithug@acm.org
Glen Zorn (editor) Glen Zorn (editor)
Network Zen Network Zen
227/358 Thanon Sanphawut 227/358 Thanon Sanphawut
Bang Na, Bangkok 10260 Bang Na, Bangkok 10260
Thailand Thailand
Phone: +66 (0) 87-0404617 Phone: +66 (0) 87-0404617
Email: glenzorn@gmail.com Email: glenzorn@gmail.com
 End of changes. 13 change blocks. 
147 lines changed or deleted 41 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/