draft-ietf-avtext-multiple-clock-rates-07.txt   draft-ietf-avtext-multiple-clock-rates-08.txt 
Network Working Group M. Petit-Huguenin Network Working Group M. Petit-Huguenin
Internet-Draft Unaffiliated Internet-Draft Impedance Mismatch
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: May 20, 2013 November 16, 2012 Expires: May 24, 2013 November 20, 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-07 draft-ietf-avtext-multiple-clock-rates-08
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 May 20, 2013. This Internet-Draft will expire on May 24, 2013.
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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 5 3.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 5
3.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 6 3.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 6
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . . 7 4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . . 6
4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 7 4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 6
4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Values Produced by Recommended Method . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Example Values . . . . . . . . . . . . . . . . . . . 9
Appendix A. Using a Fixed Clock Rate . . . . . . . . . . . . . . 10 Appendix B. Using a Fixed Clock Rate . . . . . . . . . . . . . . 10
Appendix B. Behavior of Legacy Implementations . . . . . . . . . 10 Appendix C. Behavior of Legacy Implementations . . . . . . . . . 11
B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 10 C.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 11
B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 10 C.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11
B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 10 C.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 11
B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11 C.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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
skipping to change at page 5, line 36 skipping to change at page 5, line 36
* 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 an invalid result during the transition between receiving side gives an invalid result during the transition between
two clock rates, as shown in Table 2. The capture and arrival time 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 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 |
| 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 Calculating the correct transit time on the receiving side can be
done by using the following formulas: done by using the following formulas:
1. current_capture_time = (current_timestamp - previous_timestamp) / 1. current_capture_time = (current_timestamp - previous_timestamp) /
current_clock_rate + previous_capture_time current_clock_rate + previous_capture_time
2. transit = current_clock_rate * (arrival_time - 2. transit = current_clock_rate * (arrival_time -
current_capture_time) current_capture_time)
3. previous_capture_time = current_capture_time 3. previous_capture_time = current_capture_time
skipping to change at page 6, line 34 skipping to change at page 6, line 18
following formula: following formula:
timestamp = capture_time * clock_rate timestamp = capture_time * clock_rate
With this formula, the jitter calculation is correct but the RTP With this formula, the jitter calculation is correct but the RTP
timestamp values are no longer increasing monotonically as shown in timestamp values are no longer increasing monotonically as shown in
Table 3. RFC 3550 states that "[t]he sampling instant MUST be Table 3. RFC 3550 states that "[t]he sampling instant MUST be
derived from a clock that increments monotonically[...]" but nowhere derived from a clock that increments monotonically[...]" but nowhere
says that the RTP timestamp must increment monotonically. 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 The advantage with this method is that it works with the jitter
calculation described in RFC 3550, as long as the correct clock rates calculation described in RFC 3550, as long as the correct clock rates
are used. It seems that this is what most implementations are using. are used. It seems that this is what most implementations are using.
4. Recommendations 4. Recommendations
The following subsections describe behavioral recommendations for RTP The following subsections describe behavioral recommendations for RTP
senders (with and without RTCP) and RTP receivers. senders (with and without RTCP) and RTP receivers.
4.1. RTP Sender (with RTCP) 4.1. RTP Sender (with RTCP)
skipping to change at page 8, line 25 skipping to change at page 7, line 35
An RTP Receiver MUST calculate the jitter using the following An RTP Receiver MUST calculate the jitter using the following
formula: formula:
D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j)
- (arrival_time_i * clock_rate_i - timestamp_i) - (arrival_time_i * clock_rate_i - timestamp_i)
An RTP Receiver MUST be able to handle a compound RTCP packet with An RTP Receiver MUST be able to handle a compound RTCP packet with
multiple SR packets. multiple SR packets.
4.4. Values Produced by Recommended Method
The following table illustrates the timestamp and jitter values
produced when the recommended method is used.
+-------+-------+-----------+---------+---------+--------+----------+
| 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 | 640 | 0.18 | 1600 | 0 | 0 |
| 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 |
| 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 0 | 0 |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 0 |
+-------+-------+-----------+---------+---------+--------+----------+
Table 4
5. Security Considerations 5. Security Considerations
This document is not believed to effect the security of the RTP This document is not believed to effect the security of the RTP
sessions described here in any way. sessions described here in any way.
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, Harald Alvestrand, Qin Wu, Bo Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu, and
Burman and Magnus Westerlund for their comments, suggestions and Magnus Westerlund for their comments, suggestions and questions that
questions that helped to improve this document. helped to improve this document.
Thanks to Bo Burman (who provided the values in Table 4).
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 Rose 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
skipping to change at page 10, line 22 skipping to change at page 9, line 15
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams",
RFC 5484, March 2009. RFC 5484, March 2009.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. Sessions with Unicast Feedback", RFC 5760, February 2010.
[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. Example Values
The following tables illustrate the timestamp and jitter values
produced when the various methods discussed in the text are used.
The values shown are purely exemplary, illustrative and non-
normative.
+-------+-------+-----------+---------+---------+--------+----------+
| 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
+-------+-------+-----------+---------+---------+--------+----------+
| 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
+-------+-------+-----------+---------+---------+--------+----------+
| 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 | 640 | 0.18 | 1600 | 0 | 0 |
| 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 |
| 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 0 | 0 |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 0 |
+-------+-------+-----------+---------+---------+--------+----------+
Table 4
Appendix B. 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 by Wenger & Perkins [I-D.ietf-avt-variable-rate-audio].
proposed to define a unified clock rate, but the proposal was This document proposed to define a unified clock rate, but the
rejected at IETF 61. proposal was rejected at IETF 61.
Appendix B. Behavior of Legacy Implementations Appendix C. Behavior of Legacy Implementations
B.1. libccrtp 2.0.2 C.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 C.2. libmediastreamer0 2.6.0
This library (which uses the oRTP library) uses the formula described This library (which uses the oRTP library) uses the formula described
in Section 3.2.2. in Section 3.2.2.
Note that in some environments this library uses gettimeofday(2) Note that in some environments this library uses gettimeofday(2)
which is not guaranteed to increment monotonically. which is not guaranteed to increment monotonically.
B.3. libpjmedia 1.0 C.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 C.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.
Authors' Addresses Authors' Addresses
Marc Petit-Huguenin Marc Petit-Huguenin
Unaffiliated Impedance Mismatch
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) 909-201060 Phone: +66 (0) 909-201060
 End of changes. 17 change blocks. 
90 lines changed or deleted 95 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/