idnits 2.17.1 draft-ietf-avtext-multiple-clock-rates-11.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 : ---------------------------------------------------------------------------- No issues found here. 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 23, 2013) is 3800 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 (==), 3 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 Impedance Mismatch 4 Updates: 3550 (if approved) G. Zorn, Ed. 5 Intended status: Standards Track Network Zen 6 Expires: May 27, 2014 November 23, 2013 8 Support for Multiple Clock Rates in an RTP Session 9 draft-ietf-avtext-multiple-clock-rates-11 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. It updates RFC 3550. 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 27, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . 5 58 3.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . 5 59 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . 6 61 4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 6 62 4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Example Values . . . . . . . . . . . . . . . . . . . 9 70 Appendix B. Using a Fixed Clock Rate . . . . . . . . . . . . . . 11 71 Appendix C. Behavior of Legacy Implementations . . . . . . . . . 11 72 C.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . 11 73 C.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11 74 C.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . 12 75 C.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 The clock rate is a parameter of the payload format as identified in 81 RTP and RTCP by the payload type value. It is often defined as being 82 the same as the sampling rate but that is not always the case (see, 83 for example, the G722 and MPA audio codecs [RFC3551]). 85 An RTP sender can switch between different payloads during the 86 lifetime of an RTP session and because clock rates are defined by 87 payload format, it is possible that the clock rate will also vary 88 during an RTP session. Schulzrinne, et al. [RFC3550] lists using 89 multiple clock rates as one of the reasons to not use different 90 payloads on the same Synchronization Source (SSRC). Unfortunately 91 this advice has not always been followed and some RTP implementations 92 change the payload in the same SSRC even if the different payloads 93 use different clock rates. 95 This creates three problems: 97 o The method used to calculate the RTP timestamp field in an RTP 98 packet is underspecified. 100 o When the same SSRC is used for different clock rates, it is 101 difficult to know what clock rate was used for the RTP timestamp 102 field in an RTCP Sender Report (SR) packet. 104 o When the same SSRC is used for different clock rates, it is 105 difficult to know what clock rate was used for the interarrival 106 jitter field in an RTCP Receiver Report (RR) packet. 108 Table 1 contains a non-exhaustive list of fields in RTCP packets that 109 uses a clock rate as unit: 111 +---------------------+------------------+------------+ 112 | Field name | RTCP packet type | Reference | 113 +---------------------+------------------+------------+ 114 | RTP timestamp | SR | [RFC3550] | 115 | | | | 116 | Interarrival jitter | RR | [RFC3550] | 117 | | | | 118 | min_jitter | XR Summary Block | [RFC3611] | 119 | | | | 120 | max_jitter | XR Summary Block | [RFC3611] | 121 | | | | 122 | mean_jitter | XR Summary Block | [RFC3611] | 123 | | | | 124 | dev_jitter | XR Summary Block | [RFC3611] | 125 | | | | 126 | Interarrival jitter | IJ | [RFC5450] | 127 | | | | 128 | RTP timestamp | SMPTETC | [RFC5484] | 129 | | | | 130 | Jitter | RSI Jitter Block | [RFC5760] | 131 | | | | 132 | Median jitter | RSI Stats Block | [RFC5760] | 133 +---------------------+------------------+------------+ 135 Table 1 137 This document first tries to list in Section 3 and subsections all of 138 the algorithms known to be used in existing RTP implementations at 139 the time of writing. These sections are not normative. 141 Section 4 and subsections then recommend a unique algorithm that 142 modifies RFC 3550. These sections are normative. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 In addition, this document uses the following terms: 151 Clock rate The multiplier used to convert from a wallclock value 152 in seconds to an equivalent RTP timestamp value 153 (without the fixed random offset). Note that RFC 3550 154 uses various terms like "clock frequency", "media 155 clock rate", "timestamp unit", "timestamp frequency", 156 and "RTP timestamp clock rate" as synonymous to clock 157 rate. 159 RTP Sender A logical network element that sends RTP packets, 160 sends RTCP SR packets, and receives RTCP reception 161 report blocks. 163 RTP Receiver A logical network element that receives RTP packets, 164 receives RTCP SR packets, and sends RTCP reception 165 report blocks. 167 3. Legacy RTP 169 The following sections describe the various ways legacy RTP 170 implementations behave when multiple clock rates are used. Legacy 171 RTP refers to RFC 3550 without the modifications introduced by this 172 document. 174 3.1. Different SSRC 176 One way of managing multiple clock rates is to use a different SSRC 177 for each different clock rate, as in this case there is no ambiguity 178 on the clock rate used by fields in the RTCP packets. This method 179 also seems to be the original intent of RTP as can be deduced from 180 points 2 and 3 of section 5.2 of RFC 3550. 182 On the other hand, changing the SSRC can be a problem for some 183 implementations designed to work only with unicast IP addresses, 184 where having multiple SSRCs is considered a corner case. Lip 185 synchronization can also be a problem in the interval between the 186 beginning of the new stream and the first RTCP SR packet. 188 3.2. Same SSRC 190 The simplest way of managing multiple clock rates is to use the same 191 SSRC for all the payload types regardless of the clock rates. 193 Unfortunately there is no clear definition on how the RTP timestamp 194 should be calculated in this case. The following subsections present 195 the algorithms used in the field. 197 3.2.1. Monotonic timestamps 199 This method of calculating the RTP timestamp ensures that the value 200 increases monotonically. The formula used by this method is as 201 follows: 203 timestamp = previous_timestamp 204 + (current_capture_time - previous_capture_time) 205 * current_clock_rate 207 The problem with this method is that the jitter calculation on the 208 receiving side gives an invalid result during the transition between 209 two clock rates, as shown in Table 2 (Appendix A). The capture and 210 arrival time are in seconds, starting at the beginning of the capture 211 of the first packet; clock rate is in Hz; the RTP timestamp does not 212 include the random offset; the transit, jitter, and average jitter 213 use the clock rate as unit. 215 Calculating the correct transit time on the receiving side can be 216 done by using the following formulas: 218 1. current_capture_time = (current_timestamp - previous_timestamp) / 219 current_clock_rate + previous_capture_time 221 2. transit = current_clock_rate * (arrival_time - 222 current_capture_time) 224 3. previous_capture_time = current_capture_time 226 The main problem with this method, in addition to the fact that the 227 jitter calculation described in RFC 3550 cannot be used, is that is 228 it dependent on the previous RTP packets, packets that can be 229 reordered or lost in the network. 231 3.2.2. Non-monotonic timestamps 233 An alternate way of generating the RTP timestamps is to use the 234 following formula: 236 timestamp = capture_time * clock_rate 237 With this formula, the jitter calculation is correct but the RTP 238 timestamp values are no longer increasing monotonically as shown in 239 Table 3 (Appendix A). RFC 3550 states that "[t]he sampling instant 240 MUST be derived from a clock that increments monotonically[...]" but 241 nowhere says that the RTP timestamp must increment monotonically. 243 The advantage with this method is that it works with the jitter 244 calculation described in RFC 3550, as long as the correct clock rates 245 are used. It seems that this is what most implementations are using 246 (based on a survey done at Sipit26 and on a survey of open source 247 implementations, see Appendix C). 249 4. Recommendations 251 The following subsections describe behavioral recommendations for RTP 252 senders (with and without RTCP) and RTP receivers. 254 4.1. RTP Sender (with RTCP) 256 An RTP Sender with RTCP turned on MUST use a different SSRC for each 257 different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST 258 be used if the clock rate switches back to a value already seen in 259 the RTP stream. 261 To accelerate lip synchronization, the next compound RTCP packet sent 262 by the RTP sender MUST contain multiple SR packets, the first one 263 containing the mapping for the current clock rate and the subsequent 264 SR packet(s) containing the mapping for the other clock rates seen 265 during the last period. 267 The RTP extension defined in Perkins & Schierl [RFC6051] MAY be used 268 to accelerate the synchronization. 270 4.2. RTP Sender (without RTCP) 272 An RTP Sender with RTCP turned off (i.e. having set the RS and RR 273 bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for 274 each different clock rate but MAY use different clock rates on the 275 same SSRC as long as the RTP timestamp is calculated as explained 276 below: 278 Each time the clock rate changes, the start_offset and capture_start 279 values are calculated with the following formulas: 281 start_offset += (capture_time - capture_start) * previous_clock_rate 282 capture_start = capture_time 283 For the first RTP packet, the values are initialized with the 284 following values: 286 start_offset = random_initial_offset 287 capture_start = capture_time 289 After eventually updating these values, the RTP timestamp is 290 calculated with the following formula: 292 timestamp = (capture_time - capture_start) * clock_rate 293 + start_offset 295 Note that in all the formulas, capture_start is the first instant 296 that the new timestamp rate is used. The output of the above method 297 is exemplified in Table 4 (Appendix A). 299 4.3. RTP Receiver 301 An RTP Receiver MUST calculate the jitter using the following 302 formula: 304 D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) 305 - (arrival_time_i * clock_rate_i - timestamp_i) 307 An RTP Receiver MUST be able to handle a compound RTCP packet with 308 multiple SR packets. 310 5. Security Considerations 312 When the algorithm described in Section 4.1 is used the security 313 considerations described in RFC 3550 apply. 315 The algorithm described in Section 4.2 is new and so its security 316 properties were not considered in RFC 3550. Although the RTP 317 timestamp is initialized with a random value like before, the 318 timestamp value depends on the current and previous clock rates and 319 this may or may not introduce a security vulnerability in the 320 protocol. 322 6. IANA Considerations 324 This document requires no IANA actions. 326 7. Acknowledgements 327 Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu, 328 Jonathan Lennox, Barry Leiba, David Harrington, Stephen Farrell, 329 Spencer Dawkins, Wassim Haddad and Magnus Westerlund for comments, 330 suggestions and questions that helped to improve this document. 332 Thanks to Bo Burman (who provided the values in Table 4 of 333 Appendix A). 335 Thanks to Robert Sparks and the attendees of SIPit 26 for the survey 336 on multiple clock rates interoperability. 338 This document was written with the xml2rfc tool described in Rose 339 [RFC2629]. 341 8. References 343 8.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 349 Jacobson, "RTP: A Transport Protocol for Real-Time 350 Applications", STD 64, RFC 3550, July 2003. 352 8.2. Informative References 354 [I-D.ietf-avt-variable-rate-audio] 355 Wenger, S. and C. Perkins, "RTP Timestamp Frequency for 356 Variable Rate Audio Codecs", draft-ietf-avt-variable-rate- 357 audio-00 (work in progress), October 2004. 359 [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, 360 June 1999. 362 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 363 Video Conferences with Minimal Control", STD 65, RFC 3551, 364 July 2003. 366 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 367 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 368 3556, July 2003. 370 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 371 Protocol Extended Reports (RTCP XR)", RFC 3611, November 372 2003. 374 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 375 RTP Streams", RFC 5450, March 2009. 377 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 378 5484, March 2009. 380 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 381 Protocol (RTCP) Extensions for Single-Source Multicast 382 Sessions with Unicast Feedback", RFC 5760, February 2010. 384 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 385 Flows", RFC 6051, November 2010. 387 Appendix A. Example Values 389 The following tables illustrate the timestamp and jitter values 390 produced when the various methods discussed in the text are used. 392 The values shown are purely exemplary, illustrative and non- 393 normative. 395 +--------+-------+-----------+---------+---------+--------+---------+ 396 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 397 | time | rate | timestamp | time | | | jitter | 398 +--------+-------+-----------+---------+---------+--------+---------+ 399 | 0 | 8000 | 0 | 0.1 | 800 | | | 400 | | | | | | | | 401 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 402 | | | | | | | | 403 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 404 | | | | | | | | 405 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 406 | | | | | | | | 407 | 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 | 408 | | | | | | | | 409 | 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 | 410 | | | | | | | | 411 | 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | 412 | | | | | | | | 413 | 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | 414 | | | | | | | | 415 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | 416 +--------+-------+-----------+---------+---------+--------+---------+ 418 Table 2: Monotonic Timestamps 420 +--------+-------+-----------+---------+---------+--------+---------+ 421 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 422 | time | rate | timestamp | time | | | jitter | 423 +--------+-------+-----------+---------+---------+--------+---------+ 424 | 0 | 8000 | 0 | 0.1 | 800 | | | 425 | | | | | | | | 426 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 427 | | | | | | | | 428 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 429 | | | | | | | | 430 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 431 | | | | | | | | 432 | 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 | 433 | | | | | | | | 434 | 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 | 435 | | | | | | | | 436 | 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 | 437 | | | | | | | | 438 | 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 | 439 | | | | | | | | 440 | 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 | 441 +--------+-------+-----------+---------+---------+--------+---------+ 443 Table 3: Non-monotonic Timestamps 445 +--------+-------+-----------+---------+---------+--------+---------+ 446 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 447 | time | rate | timestamp | time | | | jitter | 448 +--------+-------+-----------+---------+---------+--------+---------+ 449 | 0 | 8000 | 0 | 0.1 | 800 | | | 450 | | | | | | | | 451 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 452 | | | | | | | | 453 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 454 | | | | | | | | 455 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 456 | | | | | | | | 457 | 0.08 | 16000 | 640 | 0.18 | 1600 | 0 | 0 | 458 | | | | | | | | 459 | 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 | 460 | | | | | | | | 461 | 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 | 462 | | | | | | | | 463 | 0.14 | 8000 | 1600 | 0.24 | 320 | 0 | 0 | 464 | | | | | | | | 465 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 0 | 466 +--------+-------+-----------+---------+---------+--------+---------+ 468 Table 4: Recommended Method for RTP Sender (without RTCP) 470 Appendix B. Using a Fixed Clock Rate 472 An alternate way of fixing the multiple clock rates issue was 473 proposed by Wenger & Perkins [I-D.ietf-avt-variable-rate-audio]. 474 This document proposed to define a unified clock rate, but the 475 proposal was rejected at IETF 61. 477 Appendix C. Behavior of Legacy Implementations 479 C.1. libccrtp 2.0.2 481 This library uses the formula described in Section 3.2.2. 483 Note that this library uses gettimeofday(2) which is not guaranteed 484 to increment monotonically, like when the clock is adjusted by NTP. 486 C.2. libmediastreamer0 2.6.0 488 This library (which uses the oRTP library) uses the formula described 489 in Section 3.2.2. 491 Note that in some environments this library uses gettimeofday(2) 492 which is not guaranteed to increment monotonically. 494 C.3. libpjmedia 1.0 496 This library uses the formula described in Section 3.2.2. 498 C.4. Android RTP stack 4.0.3 500 This library changes the SSRC each time the format changes, as 501 described in Section 3.1. 503 Authors' Addresses 505 Marc Petit-Huguenin 506 Impedance Mismatch 508 Email: petithug@acm.org 510 Glen Zorn (editor) 511 Network Zen 512 227/358 Thanon Sanphawut 513 Bang Na, Bangkok 10260 514 Thailand 516 Phone: +66 (0) 8-1000-4155 517 Email: glenzorn@gmail.com