draft-ietf-avtext-multiple-clock-rates-08.txt   draft-ietf-avtext-multiple-clock-rates-09.txt 
Network Working Group M. Petit-Huguenin Network Working Group M.P.H. Petit-Huguenin
Internet-Draft Impedance Mismatch 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 24, 2013 November 20, 2012 Expires: October 24, 2013 April 22, 2013
Support for Multiple Clock Rates in an RTP Session Support for Multiple Clock Rates in an RTP Session
draft-ietf-avtext-multiple-clock-rates-08 draft-ietf-avtext-multiple-clock-rates-09
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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 24, 2013. This Internet-Draft will expire on October 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . 5
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . . 6 4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . 6
4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 6 4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 6
4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Example Values . . . . . . . . . . . . . . . . . . . 9 Appendix A. Example Values . . . . . . . . . . . . . . . . . . . 9
Appendix B. Using a Fixed Clock Rate . . . . . . . . . . . . . . 10 Appendix B. Using a Fixed Clock Rate . . . . . . . . . . . . . . 11
Appendix C. Behavior of Legacy Implementations . . . . . . . . . 11 Appendix C. Behavior of Legacy Implementations . . . . . . . . . 11
C.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 11 C.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . 11
C.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11 C.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11
C.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 11 C.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . 12
C.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11 C.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 as identified in
defined as been the same as the sampling rate but it is not always RTP and RTCP by the payload type value. It is often defined as being
the case (see e.g. the G722 and MPA audio codecs [RFC3551]). the same as the sampling rate but that is not always 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 format, it is possible that the clock rate will also vary
an RTP session. Schulzrinne, et al. [RFC3550] lists using multiple during an RTP session. Schulzrinne, et al. [RFC3550] lists using
clock rates as one of the reasons to not use different payloads on multiple clock rates as one of the reasons to not use different
the same SSRC but unfortunately this advice was not always followed payloads on the same SSRC but unfortunately this advice has not
and some RTP implementations change the payload in the same SSRC even always been followed and some RTP implementations change the payload
if the different payloads use different clock rates. in the same SSRC even 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.
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 interarrival difficult to know what clock rate was used for the interarrival
jitter field in an RTCP RR packet. jitter field in an RTCP RR packet.
Table 1 contains a non-exhaustive list of fields in RTCP packets that Table 1 contains a non-exhaustive list of fields in RTCP packets that
uses a clock rate as unit: uses a clock rate as unit:
+---------------------+------------------+-----------+ +---------------------+------------------+------------+
| Field name | RTCP packet type | Reference | | Field name | RTCP packet type | Reference |
+---------------------+------------------+-----------+ +---------------------+------------------+------------+
| RTP timestamp | SR | [RFC3550] | | RTP timestamp | SR | [RFC3550] |
| Interarrival jitter | RR | [RFC3550] | | | | |
| min_jitter | XR Summary Block | [RFC3611] | | Interarrival jitter | RR | [RFC3550] |
| max_jitter | XR Summary Block | [RFC3611] | | | | |
| mean_jitter | XR Summary Block | [RFC3611] | | min_jitter | XR Summary Block | [RFC3611] |
| dev_jitter | XR Summary Block | [RFC3611] | | | | |
| Interarrival jitter | IJ | [RFC5450] | | max_jitter | XR Summary Block | [RFC3611] |
| RTP timestamp | SMPTETC | [RFC5484] | | | | |
| Jitter | RSI Jitter Block | [RFC5760] | | mean_jitter | XR Summary Block | [RFC3611] |
| Median jitter | RSI Stats Block | [RFC5760] | | | | |
+---------------------+------------------+-----------+ | 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 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 RFC 3550. These sections are normative. modifies RFC 3550. These sections are normative.
skipping to change at page 5, line 24 skipping to change at page 5, line 15
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 subsections present should be calculated in this case. The following subsections present
the algorithms used in the field. the algorithms used in the field.
3.2.1. Monotonic timestamps 3.2.1. Monotonic timestamps
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 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.
Calculating the correct transit time on the receiving side can be Calculating the correct transit time on the receiving side can be
skipping to change at page 6, line 10 skipping to change at page 5, line 48
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. reordered or lost in the network.
3.2.2. Non-monotonic timestamps 3.2.2. Non-monotonic timestamps
An alternate way of generating the RTP timestamps is to use the An alternate way of generating the RTP timestamps is to use the
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.
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.
skipping to change at page 6, line 45 skipping to change at page 6, line 37
by the RTP sender MUST contain multiple SR packets, the first one by the RTP sender MUST contain multiple SR packets, the first one
containing the mapping for the current clock rate and the next SR containing the mapping for the current clock rate and the next SR
packets containing the mapping for the other clock rates seen during packets containing the mapping for the other clock rates seen during
the last period. the last period.
The RTP extension defined in Perkins & Schierl [RFC6051] MAY be used The RTP extension defined in Perkins & Schierl [RFC6051] MAY be used
to accelerate the synchronization. to accelerate the synchronization.
4.2. RTP Sender (without RTCP) 4.2. RTP Sender (without RTCP)
An RTP Sender with RTCP turned off (i.e. by setting the RS and RR An RTP Sender with RTCP turned off (i.e. by setting the RS and RR
bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for
each different clock rate but MAY use different clock rates on the each different clock rate but MAY use different clock rates on the
same SSRC as long as the RTP timestamp is calculated as explained same SSRC as long as the RTP timestamp is calculated as explained
below: below:
Each time the clock rate changes, the start_offset and capture_start Each time the clock rate changes, the start_offset and capture_start
values are calculated with the following formulas: values are calculated with the following formulas:
start_offset += (capture_time - capture_start) * previous_clock_rate start_offset += (capture_time - capture_start) * previous_clock_rate
capture_start = capture_time capture_start = capture_time
For the first RTP packet, the values are initialized with the For the first RTP packet, the values are initialized with the
following values: following values:
start_offset = random_initial_offset start_offset = random_initial_offset
capture_start = capture_time capture_start = capture_time
After eventually updating these values, the RTP timestamp is After eventually updating these values, the RTP timestamp is
calculated with the following formula: calculated with the following formula:
timestamp = (capture_time - capture_start) * clock_rate timestamp = (capture_time - capture_start) * clock_rate
+ start_offset + start_offset
Note that in all the formulas, capture_start is the first instant the Note that in all the formulas, capture_start is the first instant
new timestamp rate is used. that the new timestamp rate is used. The output of the above method
is exemplified in Table 4.
4.3. RTP Receiver 4.3. RTP Receiver
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.
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, and Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu,
Magnus Westerlund for their comments, suggestions and questions that and Magnus Westerlund for their comments, suggestions and questions
helped to improve this document. that helped to improve this document.
Thanks to Bo Burman (who provided the values in Table 4). 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
skipping to change at page 8, line 29 skipping to change at page 8, line 23
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.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
8.2. Informative References 8.2. Informative References
[I-D.ietf-avt-variable-rate-audio] [I-D.ietf-avt-variable-rate-audio]
Wenger, S. and C. Perkins, "RTP Timestamp Frequency for Wenger, S. and C. Perkins, "RTP Timestamp Frequency for
Variable Rate Audio Codecs", Variable Rate Audio Codecs", draft-ietf-avt-variable-rate-
draft-ietf-avt-variable-rate-audio-00 (work in progress), audio-00 (work in progress), October 2004.
October 2004.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
RFC 3556, July 2003. 3556, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611, November
November 2003. 2003.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009. RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC
RFC 5484, March 2009. 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. Example Values Appendix A. Example Values
The following tables illustrate the timestamp and jitter values The following tables illustrate the timestamp and jitter values
produced when the various methods discussed in the text are used. produced when the various methods discussed in the text are used.
The values shown are purely exemplary, illustrative and non- The values shown are purely exemplary, illustrative and non-
normative. normative.
+-------+-------+-----------+---------+---------+--------+----------+ +--------+-------+-----------+---------+---------+--------+---------+
| 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.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | | | | | | | | |
| 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 | | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 | | | | | | | | |
| 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | | | | | | | | |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | | 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 Table 2: Monotonic Timestamps
+-------+-------+-----------+---------+---------+--------+----------+ +--------+-------+-----------+---------+---------+--------+---------+
| 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.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | | | | | | | | |
| 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 | | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 | | | | | | | | |
| 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 | | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 | | | | | | | | |
| 0.16 | 8000 | 1280 | 0.26 | 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 Table 3: Non-monotonic Timestamps
+-------+-------+-----------+---------+---------+--------+----------+ +--------+-------+-----------+---------+---------+--------+---------+
| 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.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | | | | | | | | |
| 0.08 | 16000 | 640 | 0.18 | 1600 | 0 | 0 | | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 | | | | | | | | |
| 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 | | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 0 | 0 | | | | | | | | |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 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 Table 4: Recommended Method for RTP Sender (without RTCP)
Appendix B. Using a Fixed Clock Rate 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 by Wenger & Perkins [I-D.ietf-avt-variable-rate-audio]. proposed by Wenger & Perkins [I-D.ietf-avt-variable-rate-audio].
This document proposed to define a unified clock rate, but the This document proposed to define a unified clock rate, but the
proposal was rejected at IETF 61. proposal was rejected at IETF 61.
Appendix C. Behavior of Legacy Implementations Appendix C. Behavior of Legacy Implementations
skipping to change at page 11, line 44 skipping to change at page 12, line 27
Impedance Mismatch 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) 8-1000-4155
Email: glenzorn@gmail.com Email: glenzorn@gmail.com
 End of changes. 31 change blocks. 
129 lines changed or deleted 163 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/