draft-ietf-avtext-multiple-clock-rates-05.txt   draft-ietf-avtext-multiple-clock-rates-06.txt 
Network Working Group M. Petit-Huguenin Network Working Group M. Petit-Huguenin
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Updates: 3550 (if approved) G. Zorn, Ed. Updates: 3550 (if approved) G. Zorn, Ed.
Intended status: Standards Track Network Zen Intended status: Standards Track Network Zen
Expires: November 11, 2012 May 10, 2012 Expires: April 25, 2013 October 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-05 draft-ietf-avtext-multiple-clock-rates-06
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 November 11, 2012. This Internet-Draft will expire on April 25, 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 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . . 7 4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . . 7
4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 7 4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 7
4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Using a Fixed Clock Rate . . . . . . . . . . . . . . 10 Appendix A. Using a Fixed Clock Rate . . . . . . . . . . . . . . 9
Appendix B. Behavior of Legacy Implementations . . . . . . . . . 10 Appendix B. Behavior of Legacy Implementations . . . . . . . . . 10
B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 10 B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 10
B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 10 B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 10
B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 10 B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 10
B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 10 B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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
skipping to change at page 6, line 8 skipping to change at page 6, 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_capture_time = (current_timestamp - previous_timestamp) /
current_clock_rate + previous_time_capture current_clock_rate + previous_capture_time
2. transit = current_clock_rate * (time_arrival - 2. transit = current_clock_rate * (arrival_time -
current_time_capture) current_capture_time)
3. previous_time_capture = current_time_capture 3. previous_capture_time = current_capture_time
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:
skipping to change at page 7, line 9 skipping to change at page 7, line 9
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.
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 recievers 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
skipping to change at page 7, line 32 skipping to change at page 7, line 32
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 without the random offset is same SSRC as long as the RTP timestamp is calculated as explained
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) start_offset += (capture_time - capture_start) * previous_clock_rate
* 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 = 0 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_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.
skipping to change at page 8, line 22 skipping to change at page 8, line 20
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
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
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
the clock rate can be guessed as the closest to (Ri - Rj) / (Ni -
Nj).
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 and Magnus Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu and
Westerlund for their comments, suggestions and questions that helped Magnus Westerlund for their comments, suggestions and questions that
to improve this document. helped to improve this 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 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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
skipping to change at page 11, line 4 skipping to change at page 10, line 37
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 Unaffiliated
Email: petithug@acm.org Email: petithug@acm.org
Glen Zorn (editor) Glen Zorn (editor)
Network Zen Network Zen
227/358 Thanon Sanphawut 227/358 Thanon Sanphawut
Bang Na, Bangkok 10260 Bang Na, Bangkok 10260
Thailand Thailand
Phone: +66 (0) 87-0404617 Phone: +66 (0) 909-201060
Email: glenzorn@gmail.com Email: glenzorn@gmail.com
 End of changes. 17 change blocks. 
32 lines changed or deleted 23 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/