draft-ietf-avtext-multiple-clock-rates-09.txt   draft-ietf-avtext-multiple-clock-rates-10.txt 
Network Working Group M.P.H. 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: October 24, 2013 April 22, 2013 Expires: March 19, 2014 September 15, 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-09 draft-ietf-avtext-multiple-clock-rates-10
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. It updates RFC 3550.
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 October 24, 2013. This Internet-Draft will expire on March 19, 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 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . . . 12 C.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . 12
C.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 12 C.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
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,
e.g. 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 SSRC but unfortunately this advice has not
always been followed and some RTP implementations change the payload always been followed and some RTP implementations change the payload
in the same SSRC even if the different payloads use different clock in the same SSRC even if the different payloads use different clock
rates. rates.
skipping to change at page 4, line 21 skipping to change at page 4, line 21
Clock rate The multiplier used to convert from a wallclock value Clock rate The multiplier used to convert from a wallclock value
in seconds to an equivalent RTP timestamp value in seconds to an equivalent RTP timestamp value
(without the fixed random offset). Note that RFC 3550 (without the fixed random offset). Note that RFC 3550
uses various terms like "clock frequency", "media uses various terms like "clock frequency", "media
clock rate", "timestamp unit", "timestamp frequency", clock rate", "timestamp unit", "timestamp frequency",
and "RTP timestamp clock rate" as synonymous to clock and "RTP timestamp clock rate" as synonymous to clock
rate. rate.
RTP Sender A logical network element that sends RTP packets, RTP Sender A logical network element that sends RTP packets,
sends RTCP SR packets, and receives RTCP RR packets. sends RTCP SR packets, and receives RTCP reception
report blocks.
RTP Receiver A logical network element that receives RTP packets, RTP Receiver A logical network element that receives RTP packets,
receives RTCP SR packets, and sends RTCP RR packets. receives RTCP SR packets, and sends RTCP reception
report blocks.
3. Legacy RTP 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.
3.1. Different SSRC 3.1. Different SSRC
skipping to change at page 6, line 37 skipping to change at page 6, line 40
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. 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
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
skipping to change at page 7, line 40 skipping to change at page 7, line 42
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, Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu,
and Magnus Westerlund for their comments, suggestions and questions Jonathan Lennox and Magnus Westerlund for comments, suggestions and
that helped to improve this document. 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).
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
 End of changes. 10 change blocks. 
13 lines changed or deleted 15 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/