draft-ietf-avtext-multiple-clock-rates-02.txt   draft-ietf-avtext-multiple-clock-rates-03.txt 
AVTEXT M. Petit-Huguenin Network Working Group M. Petit-Huguenin
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Updates: 3550 (if approved) January 3, 2012 Updates: 3550 (if approved) G. Zorn, Ed.
Intended status: Standards Track Intended status: Standards Track Network Zen
Expires: July 6, 2012 Expires: October 24, 2012 April 22, 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-02 draft-ietf-avtext-multiple-clock-rates-03
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 July 6, 2012. This Internet-Draft will expire on October 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 5 3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 5 3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 6 3.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 7
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 9
5. Interoperability Analysis . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 11 Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 11
Appendix B. Behavior of legacy implementations . . . . . . . . . 11 Appendix B. Behavior of legacy implementations . . . . . . . . . 11
B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 11 B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 11
B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11 B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11
B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 11 B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 11
B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11 B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . . 11 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . . 11
C.1. Modifications between C.1. Modifications between
draft-ietf-avtext-multiple-clock-rates-02 and draft-ietf-avtext-multiple-clock-rates-02 and
draft-ietf-avtext-multiple-clock-rates-01 . . . . . . . . 11 draft-ietf-avtext-multiple-clock-rates-01 . . . . . . . . 11
skipping to change at page 2, line 51 skipping to change at page 2, line 50
draft-petithuguenin-avtext-multiple-clock-rates-01 and draft-petithuguenin-avtext-multiple-clock-rates-01 and
draft-petithuguenin-avtext-multiple-clock-rates-00 . . . . 12 draft-petithuguenin-avtext-multiple-clock-rates-00 . . . . 12
C.5. 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 . . . . . 12 draft-petithuguenin-avt-multiple-clock-rates-03 . . . . . 12
C.6. 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 . . . . . 12 draft-petithuguenin-avt-multiple-clock-rates-02 . . . . . 12
C.7. 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 . . . . . 12 draft-petithuguenin-avt-multiple-clock-rates-01 . . . . . 13
C.8. 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 . . . . . 13 draft-petithuguenin-avt-multiple-clock-rates-00 . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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 in [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. RTP [RFC3550] lists using multiple clock rates as
one of the reasons to not use different payloads on the same SSRC but one of the reasons to not use different payloads on the same SSRC but
unfortunately this advice was not always followed and some RTP unfortunately this advice was not always followed and some RTP
implementations change the payload in the same SSRC even if the implementations change the payload in the same SSRC even if the
different payloads use different clock rates. different payloads use different clock rates.
skipping to change at page 4, line 50 skipping to change at page 5, line 5
| mean_jitter | XR Summary Block | [RFC3611] | | mean_jitter | XR Summary Block | [RFC3611] |
| dev_jitter | XR Summary Block | [RFC3611] | | dev_jitter | XR Summary Block | [RFC3611] |
| Interarrival jitter | IJ | [RFC5450] | | Interarrival jitter | IJ | [RFC5450] |
| RTP timestamp | SMPTETC | [RFC5484] | | RTP timestamp | SMPTETC | [RFC5484] |
| Jitter | RSI Jitter Block | [RFC5760] | | Jitter | RSI Jitter Block | [RFC5760] |
| Median jitter | RSI Stats Block | [RFC5760] | | Median jitter | RSI Stats Block | [RFC5760] |
+---------------------+------------------+-----------+ +---------------------+------------------+-----------+
Table 1 Table 1
This document first tries to list in Section 2 and subsections all This document first tries to list in Section 3 and subsections all of
known algorithms used in existing RTP implementations at the time of the algorithms known to be used in existing RTP implementations at
writing. This 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]. This sections are normative. modifies [RFC3550]. These sections are normative.
Section 5 and subsections then analyze what happen when the legacy 2. Terminology
algorithms listed in Section 2 are used with the new algorithm listed
in Section 4. This sections are not normative.
2. Legacy RTP The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. In
addition, this document uses the following terms:
Clock rate The multiplier used to convert from a wallclock value
in seconds to an equivalent RTP timestamp value
(without the fixed random offset). Note that RFC 3550
uses various terms like "clock frequency", "media
clock rate", "timestamp unit", "timestamp frequency",
and "RTP timestamp clock rate" as synonymous to clock
rate.
RTP Sender A logical network element that sends RTP packets,
sends RTCP SR packets, and receives RTCP RR packets.
RTP Receiver A logical network element that receives RTP packets,
receives RTCP SR packets, and sends RTCP RR packets.
3. 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.
2.1. Different SSRC 3.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,
where having multiple SSRCs is considered a corner case. Lip where having multiple SSRCs is considered a corner case. Lip
synchronization can also be a problem in the interval between the synchronization can also be a problem in the interval between the
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 3.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 subsections present should be calculated in this case. The following subsections present
the algorithms used in the field. the algorithms used in the field.
2.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
follow: follows:
timestamp = previous_timestamp
+ (current_capture_time - previous_capture_time)
* current_clock_rate
timestamp = previous_timestamp + (current_capture_time -
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 6, line 32 skipping to change at page 7, line 8
| 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | | 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | | 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 |
+-------+-------+-----------+---------+---------+--------+----------+ +-------+-------+-----------+---------+---------+--------+----------+
Table 2 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_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 -
current_time_capture) 2. transit = current_clock_rate * (time_arrival -
(3) previous_time_capture = current_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. reordered or lost in the network.
2.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
skipping to change at page 7, line 29 skipping to change at page 8, line 6
| 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 | | 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 |
| 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 | | 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 |
+-------+-------+-----------+---------+---------+--------+----------+ +-------+-------+-----------+---------+---------+--------+----------+
Table 3 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.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Clock rate: The multiplier used to convert from a wallclock value in
seconds to an equivalent RTP timestamp value (without the fixed
random offset). Note that RFC 3550 uses various terms like "clock
frequency", "media clock rate", "timestamp unit", "timestamp
frequency", and "RTP timestamp clock rate" as synonymous to clock
rate.
RTP Sender: A logical network element that sends RTP packets, sends
RTCP SR packets, and receives RTCP RR packets.
RTP Receiver: A logical network element that receives RTP packets,
receives RTCP SR packets, and sends RTCP RR packets.
4. Recommendations 4. Recommendations
4.1. RTP Sender 4.1. RTP Sender
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 defined in [RFC3556] to 0) SHOULD use a different bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for
SSRC for each different clock rate but MAY use different clock rates each different clock rate but MAY use different clock rates on the
on the same SSRC as long as the RTP timestamp without the random same SSRC as long as the RTP timestamp without the random offset is
offset is calculated as explained below: calculated as explained below:
[[This was designed to help VoIP implementations who anyway never [[This was designed to help VoIP implementations who anyway never
cared about RTCP. Do we want to keep this?]] cared about RTCP. Do we want to keep this?]]
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 formulas: following values:
start_offset = 0 start_offset = 0
capture_start = capture_time capture_start = capture_time
After eventually updating this 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_time is the first instant the Note that in all the formulas, capture_time is the first instant the
new timestamp rate is used. new timestamp rate is used.
An RTP Sender with RTCP turned on MUST use a different SSRC for each An RTP Sender with RTCP turned on MUST use a different SSRC for each
different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST
skipping to change at page 8, line 50 skipping to change at page 9, line 8
To accelerate lip synchronization, the next compound RTCP packet sent To accelerate lip synchronization, the next compound RTCP packet sent
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.
[[Some legacy implementations may dislike receiving multiple SR [[Some legacy implementations may dislike receiving multiple SR
packets. What should we do?]] packets. What should we do?]]
The RTP extension defined in [RFC6051] MAY be used to accelerate the The RTP extension defined in Perkins & Schierl [RFC6051] MAY be used
synchronization. to accelerate the synchronization.
4.2. RTP Receiver 4.2. 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.
For interoperability with legacy RTP implementations, an RTP receiver For interoperability with legacy RTP implementations, an RTP receiver
MAY use the information in two consecutive SR packets to calculate MAY use the information in two consecutive SR packets to calculate
the clock rate used, i.e. if Ni is the NTP timestamp for the SR the clock rate used, i.e. if Ni is the NTP timestamp for the SR
packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the
NTP timestamp and RTP timestamp for the previous SR packet j, then 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. Interoperability Analysis 5. Security Considerations
The next subsections analyze the various combinations between legacy
RTP implementations and RTP implementations that follow this document
specifications.
TBD
6. Security Considerations
TBD TBD
7. IANA Considerations 6. IANA Considerations
No IANA considerations. This document requires no IANA actions..
8. 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
[RFC2629]. [RFC2629].
9. References 8. References
9.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.
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.
9.2. Informative References 8.2. Informative References
[I-D.ietf-avt-variable-rate-audio]
Wenger, S. and C. Perkins, "RTP Timestamp Frequency for
Variable Rate Audio Codecs",
draft-ietf-avt-variable-rate-audio-00 (work in progress),
October 2004.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "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",
skipping to change at page 10, line 49 skipping to change at page 11, line 5
[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.
[uRTR] Wenger, S. and C. Perkins, "RTP Timestamp Frequency for
Variable Rate Audio Codecs",
draft-ietf-avt-variable-rate-audio-00 (work in progress),
October 2004.
Appendix A. Using a fixed clock rate 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 [I-D.ietf-avt-variable-rate-audio]. This document
rate, but the proposal was rejected at IETF 61. proposed to define a unified clock rate, but the proposal was
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 2.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
This library (which uses the oRTP library) uses the formula described This library (which uses the oRTP library) uses the formula described
in Section 2.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 B.3. libpjmedia 1.0
This library uses the formula described in Section 2.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 2.1. described in Section 3.1.
Appendix C. Release notes Appendix C. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
C.1. Modifications between draft-ietf-avtext-multiple-clock-rates-02 C.1. Modifications between draft-ietf-avtext-multiple-clock-rates-02
and draft-ietf-avtext-multiple-clock-rates-01 and draft-ietf-avtext-multiple-clock-rates-01
o Readded the non-monotonic methods that was removed in a previous o Readded the non-monotonic methods that was removed in a previous
version. version.
skipping to change at page 13, line 6 skipping to change at page 13, line 14
o Updated RFC reference. o Updated RFC reference.
C.7. 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.
C.8. 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 Authors' Addresses
Marc Petit-Huguenin Marc Petit-Huguenin
Unaffiliated Unaffiliated
Email: petithug@acm.org Email: petithug@acm.org
Glen Zorn (editor)
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-0404617
Email: glenzorn@gmail.com
 End of changes. 44 change blocks. 
95 lines changed or deleted 96 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/