idnits 2.17.1 draft-ietf-avtext-multiple-clock-rates-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2012) is 4179 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Petit-Huguenin 3 Internet-Draft Unaffiliated 4 Updates: 3550 (if approved) G. Zorn, Ed. 5 Intended status: Standards Track Network Zen 6 Expires: May 20, 2013 November 16, 2012 8 Support for Multiple Clock Rates in an RTP Session 9 draft-ietf-avtext-multiple-clock-rates-07 11 Abstract 13 This document clarifies the RTP specification when different clock 14 rates are used in an RTP session. It also provides guidance on how 15 to interoperate with legacy RTP implementations that use multiple 16 clock rates. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 20, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 5 58 3.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 6 59 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . . 7 61 4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 7 62 4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.4. Values Produced by Recommended Method . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Appendix A. Using a Fixed Clock Rate . . . . . . . . . . . . . . 10 71 Appendix B. Behavior of Legacy Implementations . . . . . . . . . 10 72 B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 10 73 B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 10 74 B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 10 75 B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 The clock rate is a parameter of the payload format. It is often 81 defined as been the same as the sampling rate but it is not always 82 the case (see e.g. the G722 and MPA audio codecs [RFC3551]). 84 An RTP sender can switch between different payloads during the 85 lifetime of an RTP session and because clock rates are defined by 86 payload types, it is possible that the clock rate also varies during 87 an RTP session. Schulzrinne, et al. [RFC3550] lists using multiple 88 clock rates as one of the reasons to not use different payloads on 89 the same SSRC but unfortunately this advice was not always followed 90 and some RTP implementations change the payload in the same SSRC even 91 if the different payloads use different clock rates. 93 This creates three problems: 95 o The method used to calculate the RTP timestamp field in an RTP 96 packet is underspecified. 98 o When the same SSRC is used for different clock rates, it is 99 difficult to know what clock rate was used for the RTP timestamp 100 field in an RTCP SR packet. 102 o When the same SSRC is used for different clock rates, it is 103 difficult to know what clock rate was used for the interarrival 104 jitter field in an RTCP RR packet. 106 Table 1 contains a non-exhaustive list of fields in RTCP packets that 107 uses a clock rate as unit: 109 +---------------------+------------------+-----------+ 110 | Field name | RTCP packet type | Reference | 111 +---------------------+------------------+-----------+ 112 | RTP timestamp | SR | [RFC3550] | 113 | Interarrival jitter | RR | [RFC3550] | 114 | min_jitter | XR Summary Block | [RFC3611] | 115 | max_jitter | XR Summary Block | [RFC3611] | 116 | mean_jitter | XR Summary Block | [RFC3611] | 117 | dev_jitter | XR Summary Block | [RFC3611] | 118 | Interarrival jitter | IJ | [RFC5450] | 119 | RTP timestamp | SMPTETC | [RFC5484] | 120 | Jitter | RSI Jitter Block | [RFC5760] | 121 | Median jitter | RSI Stats Block | [RFC5760] | 122 +---------------------+------------------+-----------+ 124 Table 1 126 This document first tries to list in Section 3 and subsections all of 127 the algorithms known to be used in existing RTP implementations at 128 the time of writing. These sections are not normative. 130 Section 4 and subsections then recommend a unique algorithm that 131 modifies RFC 3550. These sections are normative. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 In addition, this document uses the following terms: 140 Clock rate The multiplier used to convert from a wallclock value 141 in seconds to an equivalent RTP timestamp value 142 (without the fixed random offset). Note that RFC 3550 143 uses various terms like "clock frequency", "media 144 clock rate", "timestamp unit", "timestamp frequency", 145 and "RTP timestamp clock rate" as synonymous to clock 146 rate. 148 RTP Sender A logical network element that sends RTP packets, 149 sends RTCP SR packets, and receives RTCP RR packets. 151 RTP Receiver A logical network element that receives RTP packets, 152 receives RTCP SR packets, and sends RTCP RR packets. 154 3. Legacy RTP 156 The following sections describe the various ways legacy RTP 157 implementations behave when multiple clock rates are used. Legacy 158 RTP refers to RFC 3550 without the modifications introduced by this 159 document. 161 3.1. Different SSRC 163 One way of managing multiple clock rates is to use a different SSRC 164 for each different clock rate, as in this case there is no ambiguity 165 on the clock rate used by fields in the RTCP packets. This method 166 also seems to be the original intent of RTP as can be deduced from 167 points 2 and 3 of section 5.2 of RFC 3550. 169 On the other hand changing the SSRC can be a problem for some 170 implementations designed to work only with unicast IP addresses, 171 where having multiple SSRCs is considered a corner case. Lip 172 synchronization can also be a problem in the interval between the 173 beginning of the new stream and the first RTCP SR packet. This is 174 not different than what happen at the beginning of the RTP session 175 but it can be more annoying for the end-user. 177 3.2. Same SSRC 179 The simplest way of managing multiple clock rates is to use the same 180 SSRC for all the payload types regardless of the clock rates. 182 Unfortunately there is no clear definition on how the RTP timestamp 183 should be calculated in this case. The following subsections present 184 the algorithms used in the field. 186 3.2.1. Monotonic timestamps 188 This method of calculating the RTP timestamp ensures that the value 189 increases monotonically. The formula used by this method is as 190 follows: 192 timestamp = previous_timestamp 193 + (current_capture_time - previous_capture_time) 194 * current_clock_rate 196 The problem with this method is that the jitter calculation on the 197 receiving side gives an invalid result during the transition between 198 two clock rates, as shown in Table 2. The capture and arrival time 199 are in seconds, starting at the beginning of the capture of the first 200 packet; clock rate is in Hz; the RTP timestamp does not include the 201 random offset; the transit, jitter, and average jitter use the clock 202 rate as unit. 204 +-------+-------+-----------+---------+---------+--------+----------+ 205 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 206 | time | rate | timestamp | time | | | jitter | 207 +-------+-------+-----------+---------+---------+--------+----------+ 208 | 0 | 8000 | 0 | 0.1 | 800 | | | 209 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 210 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 211 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 212 | 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 | 213 | 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 | 214 | 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | 215 | 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | 216 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | 217 +-------+-------+-----------+---------+---------+--------+----------+ 219 Table 2 221 Calculating the correct transit time on the receiving side can be 222 done by using the following formulas: 224 1. current_capture_time = (current_timestamp - previous_timestamp) / 225 current_clock_rate + previous_capture_time 227 2. transit = current_clock_rate * (arrival_time - 228 current_capture_time) 230 3. previous_capture_time = current_capture_time 232 The main problem with this method, in addition to the fact that the 233 jitter calculation described in RFC 3550 cannot be used, is that is 234 it dependent on the previous RTP packets, packets that can be 235 reordered or lost in the network. 237 3.2.2. Non-monotonic timestamps 239 An alternate way of generating the RTP timestamps is to use the 240 following formula: 242 timestamp = capture_time * clock_rate 244 With this formula, the jitter calculation is correct but the RTP 245 timestamp values are no longer increasing monotonically as shown in 246 Table 3. RFC 3550 states that "[t]he sampling instant MUST be 247 derived from a clock that increments monotonically[...]" but nowhere 248 says that the RTP timestamp must increment monotonically. 250 +-------+-------+-----------+---------+---------+--------+----------+ 251 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 252 | time | rate | timestamp | time | | | jitter | 253 +-------+-------+-----------+---------+---------+--------+----------+ 254 | 0 | 8000 | 0 | 0.1 | 800 | | | 255 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 256 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 257 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 258 | 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 | 259 | 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 | 260 | 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 | 261 | 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 | 262 | 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 | 263 +-------+-------+-----------+---------+---------+--------+----------+ 265 Table 3 267 The advantage with this method is that it works with the jitter 268 calculation described in RFC 3550, as long as the correct clock rates 269 are used. It seems that this is what most implementations are using. 271 4. Recommendations 273 The following subsections describe behavioral recommendations for RTP 274 senders (with and without RTCP) and RTP receivers. 276 4.1. RTP Sender (with RTCP) 278 An RTP Sender with RTCP turned on MUST use a different SSRC for each 279 different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST 280 be used if the clock rate switches back to a value already seen in 281 the RTP stream. 283 To accelerate lip synchronization, the next compound RTCP packet sent 284 by the RTP sender MUST contain multiple SR packets, the first one 285 containing the mapping for the current clock rate and the next SR 286 packets containing the mapping for the other clock rates seen during 287 the last period. 289 The RTP extension defined in Perkins & Schierl [RFC6051] MAY be used 290 to accelerate the synchronization. 292 4.2. RTP Sender (without RTCP) 294 An RTP Sender with RTCP turned off (i.e. by setting the RS and RR 295 bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for 296 each different clock rate but MAY use different clock rates on the 297 same SSRC as long as the RTP timestamp is calculated as explained 298 below: 300 Each time the clock rate changes, the start_offset and capture_start 301 values are calculated with the following formulas: 303 start_offset += (capture_time - capture_start) * previous_clock_rate 304 capture_start = capture_time 306 For the first RTP packet, the values are initialized with the 307 following values: 309 start_offset = random_initial_offset 310 capture_start = capture_time 312 After eventually updating these values, the RTP timestamp is 313 calculated with the following formula: 315 timestamp = (capture_time - capture_start) * clock_rate 316 + start_offset 318 Note that in all the formulas, capture_start is the first instant the 319 new timestamp rate is used. 321 4.3. RTP Receiver 323 An RTP Receiver MUST calculate the jitter using the following 324 formula: 326 D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) 327 - (arrival_time_i * clock_rate_i - timestamp_i) 329 An RTP Receiver MUST be able to handle a compound RTCP packet with 330 multiple SR packets. 332 4.4. Values Produced by Recommended Method 334 The following table illustrates the timestamp and jitter values 335 produced when the recommended method is used. 337 +-------+-------+-----------+---------+---------+--------+----------+ 338 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 339 | time | rate | timestamp | time | | | jitter | 340 +-------+-------+-----------+---------+---------+--------+----------+ 341 | 0 | 8000 | 0 | 0.1 | 800 | | | 342 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 343 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 344 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 345 | 0.08 | 16000 | 640 | 0.18 | 1600 | 0 | 0 | 346 | 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 | 347 | 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 | 348 | 0.14 | 8000 | 1600 | 0.24 | 320 | 0 | 0 | 349 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 0 | 350 +-------+-------+-----------+---------+---------+--------+----------+ 352 Table 4 354 5. Security Considerations 356 This document is not believed to effect the security of the RTP 357 sessions described here in any way. 359 6. IANA Considerations 361 This document requires no IANA actions. 363 7. Acknowledgements 365 Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu, Bo 366 Burman and Magnus Westerlund for their comments, suggestions and 367 questions that helped to improve this document. 369 Thanks to Robert Sparks and the attendees of SIPit 26 for the survey 370 on multiple clock rates interoperability. 372 This document was written with the xml2rfc tool described in Rose 373 [RFC2629]. 375 8. References 377 8.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 383 Jacobson, "RTP: A Transport Protocol for Real-Time 384 Applications", STD 64, RFC 3550, July 2003. 386 8.2. Informative References 388 [I-D.ietf-avt-variable-rate-audio] 389 Wenger, S. and C. Perkins, "RTP Timestamp Frequency for 390 Variable Rate Audio Codecs", 391 draft-ietf-avt-variable-rate-audio-00 (work in progress), 392 October 2004. 394 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 395 June 1999. 397 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 398 Video Conferences with Minimal Control", STD 65, RFC 3551, 399 July 2003. 401 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 402 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 403 RFC 3556, July 2003. 405 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 406 Protocol Extended Reports (RTCP XR)", RFC 3611, 407 November 2003. 409 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 410 RTP Streams", RFC 5450, March 2009. 412 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 413 RFC 5484, March 2009. 415 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 416 Protocol (RTCP) Extensions for Single-Source Multicast 417 Sessions with Unicast Feedback", RFC 5760, February 2010. 419 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 420 Flows", RFC 6051, November 2010. 422 Appendix A. Using a Fixed Clock Rate 424 An alternate way of fixing the multiple clock rates issue was 425 proposed in [I-D.ietf-avt-variable-rate-audio]. This document 426 proposed to define a unified clock rate, but the proposal was 427 rejected at IETF 61. 429 Appendix B. Behavior of Legacy Implementations 431 B.1. libccrtp 2.0.2 433 This library uses the formula described in Section 3.2.2. 435 Note that this library uses gettimeofday(2) which is not guaranteed 436 to increment monotonically, like when the clock is adjusted by NTP. 438 B.2. libmediastreamer0 2.6.0 440 This library (which uses the oRTP library) uses the formula described 441 in Section 3.2.2. 443 Note that in some environments this library uses gettimeofday(2) 444 which is not guaranteed to increment monotonically. 446 B.3. libpjmedia 1.0 448 This library uses the formula described in Section 3.2.2. 450 B.4. Android RTP stack 4.0.3 452 This library changes the SSRC each time the format changes, as 453 described in Section 3.1. 455 Authors' Addresses 457 Marc Petit-Huguenin 458 Unaffiliated 460 Email: petithug@acm.org 462 Glen Zorn (editor) 463 Network Zen 464 227/358 Thanon Sanphawut 465 Bang Na, Bangkok 10260 466 Thailand 468 Phone: +66 (0) 909-201060 469 Email: glenzorn@gmail.com