draft-ietf-avtext-multiple-clock-rates-10.txt   draft-ietf-avtext-multiple-clock-rates-11.txt 
Network Working Group M. Petit-Huguenin Network Working Group M. 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: March 19, 2014 September 15, 2013 Expires: May 27, 2014 November 23, 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-10 draft-ietf-avtext-multiple-clock-rates-11
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. It updates RFC 3550. clock rates. It updates RFC 3550.
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 March 19, 2014. This Internet-Draft will expire on May 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
The clock rate is a parameter of the payload format as identified in The clock rate is a parameter of the payload format as identified in
RTP and RTCP by the payload type value. It is often defined as being RTP and RTCP by the payload type value. It is often defined as being
the same as the sampling rate but that is not always the case (see, the same as the sampling rate but that is not always the case (see,
for example, the G722 and MPA audio codecs [RFC3551]). for example, 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 format, it is possible that the clock rate will also vary payload format, it is possible that the clock rate will also vary
during an RTP session. Schulzrinne, et al. [RFC3550] lists using during an RTP session. Schulzrinne, et al. [RFC3550] lists using
multiple clock rates as one of the reasons to not use different multiple clock rates as one of the reasons to not use different
payloads on the same SSRC but unfortunately this advice has not payloads on the same Synchronization Source (SSRC). Unfortunately
always been followed and some RTP implementations change the payload this advice has not always been followed and some RTP implementations
in the same SSRC even if the different payloads use different clock change the payload in the same SSRC even if the different payloads
rates. 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 Sender Report (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 Receiver Report (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] | | Interarrival jitter | RR | [RFC3550] |
skipping to change at page 4, line 43 skipping to change at page 4, line 43
document. document.
3.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.
not different than what happen at the beginning of the RTP session
but it can be more annoying for the end-user.
3.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.
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
skipping to change at page 5, line 23 skipping to change at page 5, line 21
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 (Appendix A). The capture and
are in seconds, starting at the beginning of the capture of the first arrival time are in seconds, starting at the beginning of the capture
packet; clock rate is in Hz; the RTP timestamp does not include the of the first packet; clock rate is in Hz; the RTP timestamp does not
random offset; the transit, jitter, and average jitter use the clock include the random offset; the transit, jitter, and average jitter
rate as unit. use the clock 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
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)
skipping to change at page 6, line 6 skipping to change at page 6, line 4
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 (Appendix A). RFC 3550 states that "[t]he sampling instant
derived from a clock that increments monotonically[...]" but nowhere MUST be derived from a clock that increments monotonically[...]" but
says that the RTP timestamp must increment monotonically. nowhere 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
(based on a survey done at Sipit26 and on a survey of open source
implementations, see Appendix C).
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)
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
be used if the clock rate switches back to a value already seen in be used if the clock rate switches back to a value already seen in
the RTP stream. the RTP stream.
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 subsequent
packets containing the mapping for the other clock rates seen during SR packet(s) containing the mapping for the other clock rates seen
the last period. during 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. having set the RS and RR An RTP Sender with RTCP turned off (i.e. having set 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
skipping to change at page 7, line 18 skipping to change at page 7, line 18
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 Note that in all the formulas, capture_start is the first instant
that the new timestamp rate is used. The output of the above method that the new timestamp rate is used. The output of the above method
is exemplified in Table 4. is exemplified in Table 4 (Appendix A).
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 When the algorithm described in Section 4.1 is used the security
sessions described here in any way. considerations described in RFC 3550 apply.
The algorithm described in Section 4.2 is new and so its security
properties were not considered in RFC 3550. Although the RTP
timestamp is initialized with a random value like before, the
timestamp value depends on the current and previous clock rates and
this may or may not introduce a security vulnerability in the
protocol.
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, Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu,
Jonathan Lennox and Magnus Westerlund for comments, suggestions and Jonathan Lennox, Barry Leiba, David Harrington, Stephen Farrell,
questions that helped to improve this document. Spencer Dawkins, Wassim Haddad and Magnus Westerlund for comments,
suggestions and questions 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 of
Appendix A).
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
 End of changes. 19 change blocks. 
33 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/