idnits 2.17.1 draft-ietf-avtext-multiple-clock-rates-03.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 (April 22, 2012) is 4385 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: October 24, 2012 April 22, 2012 8 Support for multiple clock rates in an RTP session 9 draft-ietf-avtext-multiple-clock-rates-03 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 October 24, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 6 58 3.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 7 59 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.1. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 9 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 11 69 Appendix B. Behavior of legacy implementations . . . . . . . . . 11 70 B.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . . 11 71 B.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 11 72 B.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . . 11 73 B.4. Android RTP stack 4.0.3 . . . . . . . . . . . . . . . . . 11 74 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . . 11 75 C.1. Modifications between 76 draft-ietf-avtext-multiple-clock-rates-02 and 77 draft-ietf-avtext-multiple-clock-rates-01 . . . . . . . . 11 78 C.2. Modifications between 79 draft-ietf-avtext-multiple-clock-rates-01 and 80 draft-ietf-avtext-multiple-clock-rates-00 . . . . . . . . 12 81 C.3. Modifications between 82 draft-ietf-avtext-multiple-clock-rates-00 and 83 draft-petithuguenin-avtext-multiple-clock-rates-01 . . . . 12 84 C.4. Modifications between 85 draft-petithuguenin-avtext-multiple-clock-rates-01 and 86 draft-petithuguenin-avtext-multiple-clock-rates-00 . . . . 12 87 C.5. Modifications between 88 draft-petithuguenin-avtext-multiple-clock-rates-00 and 89 draft-petithuguenin-avt-multiple-clock-rates-03 . . . . . 12 90 C.6. Modifications between 91 draft-petithuguenin-avt-multiple-clock-rates-03 and 92 draft-petithuguenin-avt-multiple-clock-rates-02 . . . . . 12 93 C.7. Modifications between 94 draft-petithuguenin-avt-multiple-clock-rates-02 and 95 draft-petithuguenin-avt-multiple-clock-rates-01 . . . . . 13 96 C.8. Modifications between 97 draft-petithuguenin-avt-multiple-clock-rates-01 and 98 draft-petithuguenin-avt-multiple-clock-rates-00 . . . . . 13 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 101 1. Introduction 103 The clock rate is a parameter of the payload format. It is often 104 defined as been the same as the sampling rate but it is not always 105 the case (see e.g. the G722 and MPA audio codecs [RFC3551]). 107 An RTP sender can switch between different payloads during the 108 lifetime of an RTP session and because clock rates are defined by 109 payload types, it is possible that the clock rate also varies during 110 an RTP session. RTP [RFC3550] lists using multiple clock rates as 111 one of the reasons to not use different payloads on the same SSRC but 112 unfortunately this advice was not always followed and some RTP 113 implementations change the payload in the same SSRC even if the 114 different payloads use different clock rates. 116 This creates three problems: 118 o The method used to calculate the RTP timestamp field in an RTP 119 packet is underspecified. 121 o When the same SSRC is used for different clock rates, it is 122 difficult to know what clock rate was used for the RTP timestamp 123 field in an RTCP SR packet. 125 o When the same SSRC is used for different clock rates, it is 126 difficult to know what clock rate was used for the interarrival 127 jitter field in an RTCP RR packet. 129 Table 1 contains a non-exhaustive list of fields in RTCP packets that 130 uses a clock rate as unit: 132 +---------------------+------------------+-----------+ 133 | Field name | RTCP packet type | Reference | 134 +---------------------+------------------+-----------+ 135 | RTP timestamp | SR | [RFC3550] | 136 | Interarrival jitter | RR | [RFC3550] | 137 | min_jitter | XR Summary Block | [RFC3611] | 138 | max_jitter | XR Summary Block | [RFC3611] | 139 | mean_jitter | XR Summary Block | [RFC3611] | 140 | dev_jitter | XR Summary Block | [RFC3611] | 141 | Interarrival jitter | IJ | [RFC5450] | 142 | RTP timestamp | SMPTETC | [RFC5484] | 143 | Jitter | RSI Jitter Block | [RFC5760] | 144 | Median jitter | RSI Stats Block | [RFC5760] | 145 +---------------------+------------------+-----------+ 147 Table 1 149 This document first tries to list in Section 3 and subsections all of 150 the algorithms known to be used in existing RTP implementations at 151 the time of writing. These sections are not normative. 153 Section 4 and subsections then recommend a unique algorithm that 154 modifies [RFC3550]. These sections are normative. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. In 161 addition, this document uses the following terms: 163 Clock rate The multiplier used to convert from a wallclock value 164 in seconds to an equivalent RTP timestamp value 165 (without the fixed random offset). Note that RFC 3550 166 uses various terms like "clock frequency", "media 167 clock rate", "timestamp unit", "timestamp frequency", 168 and "RTP timestamp clock rate" as synonymous to clock 169 rate. 171 RTP Sender A logical network element that sends RTP packets, 172 sends RTCP SR packets, and receives RTCP RR packets. 174 RTP Receiver A logical network element that receives RTP packets, 175 receives RTCP SR packets, and sends RTCP RR packets. 177 3. Legacy RTP 179 The following sections describe the various ways legacy RTP 180 implementations behave when multiple clock rates are used. Legacy 181 RTP refers to RFC 3550 without the modifications introduced by this 182 document. 184 3.1. Different SSRC 186 One way of managing multiple clock rates is to use a different SSRC 187 for each different clock rate, as in this case there is no ambiguity 188 on the clock rate used by fields in the RTCP packets. This method 189 also seems to be the original intent of RTP as can be deduced from 190 points 2 and 3 of section 5.2 of RFC 3550. 192 On the other hand changing the SSRC can be a problem for some 193 implementations designed to work only with unicast IP addresses, 194 where having multiple SSRCs is considered a corner case. Lip 195 synchronization can also be a problem in the interval between the 196 beginning of the new stream and the first RTCP SR packet. This is 197 not different than what happen at the beginning of the RTP session 198 but it can be more annoying for the end-user. 200 3.2. Same SSRC 202 The simplest way of managing multiple clock rates is to use the same 203 SSRC for all the payload types regardless of the clock rates. 205 Unfortunately there is no clear definition on how the RTP timestamp 206 should be calculated in this case. The following subsections present 207 the algorithms used in the field. 209 3.2.1. Monotonic timestamps 211 This method of calculating the RTP timestamp ensures that the value 212 increases monotonically. The formula used by this method is as 213 follows: 215 timestamp = previous_timestamp 216 + (current_capture_time - previous_capture_time) 217 * current_clock_rate 219 The problem with this method is that the jitter calculation on the 220 receiving side gives invalid result during the transition between two 221 clock rates, as shown in Table 2. The capture and arrival time are 222 in seconds, starting at the beginning of the capture of the first 223 packet; clock rate is in Hz; the RTP timestamp does not include the 224 random offset; the transit, jitter, and average jitter use the clock 225 rate as unit. 227 +-------+-------+-----------+---------+---------+--------+----------+ 228 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 229 | time | rate | timestamp | time | | | jitter | 230 +-------+-------+-----------+---------+---------+--------+----------+ 231 | 0 | 8000 | 0 | 0.1 | 800 | | | 232 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 233 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 234 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 235 | 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 | 236 | 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 | 237 | 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | 238 | 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | 239 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | 240 +-------+-------+-----------+---------+---------+--------+----------+ 242 Table 2 244 Calculating the correct transit time on the receiving side can be 245 done by using the following formulas: 247 1. current_time_capture = current_timestamp - previous_timestamp) / 248 current_clock_rate + previous_time_capture 250 2. transit = current_clock_rate * (time_arrival - 251 current_time_capture) 253 3. previous_time_capture = current_time_capture 255 The main problem with this method, in addition to the fact that the 256 jitter calculation described in RFC 3550 cannot be used, is that is 257 it dependent on the previous RTP packets, packets that can be 258 reordered or lost in the network. 260 3.2.2. Non-monotonic timestamps 262 An alternate way of generating the RTP timestamps is to use the 263 following formula: 265 timestamp = capture_time * clock_rate 267 With this formula, the jitter calculation is correct but the RTP 268 timestamp values are no longer increasing monotonically as shown in 269 Table 3. RFC 3550 states that "[t]he sampling instant MUST be 270 derived from a clock that increments monotonically[...]" but nowhere 271 says that the RTP timestamp must increment monotonically. 273 +-------+-------+-----------+---------+---------+--------+----------+ 274 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 275 | time | rate | timestamp | time | | | jitter | 276 +-------+-------+-----------+---------+---------+--------+----------+ 277 | 0 | 8000 | 0 | 0.1 | 800 | | | 278 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 279 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 280 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 281 | 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 | 282 | 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 | 283 | 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 | 284 | 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 | 285 | 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 | 286 +-------+-------+-----------+---------+---------+--------+----------+ 288 Table 3 290 The advantage with this method is that it works with the jitter 291 calculation described in RFC 3550, as long as the correct clock rates 292 are used. It seems that this is what most implementations are using. 294 4. Recommendations 296 4.1. RTP Sender 298 An RTP Sender with RTCP turned off (i.e. by setting the RS and RR 299 bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for 300 each different clock rate but MAY use different clock rates on the 301 same SSRC as long as the RTP timestamp without the random offset is 302 calculated as explained below: 304 [[This was designed to help VoIP implementations who anyway never 305 cared about RTCP. Do we want to keep this?]] 307 Each time the clock rate changes, the start_offset and capture_start 308 values are calculated with the following formulas: 310 start_offset = (capture_time - capture_start) * previous_clock_rate 311 capture_start = capture_time 313 For the first RTP packet, the values are initialized with the 314 following values: 316 start_offset = 0 317 capture_start = capture_time 319 After eventually updating these values, the RTP timestamp is 320 calculated with the following formula: 322 timestamp = (capture_time - capture_start) * clock_rate + 323 start_offset 325 Note that in all the formulas, capture_time is the first instant the 326 new timestamp rate is used. 328 An RTP Sender with RTCP turned on MUST use a different SSRC for each 329 different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST 330 be used if the clock rate switches back to a value already seen in 331 the RTP stream. 333 To accelerate lip synchronization, the next compound RTCP packet sent 334 by the RTP sender MUST contain multiple SR packets, the first one 335 containing the mapping for the current clock rate and the next SR 336 packets containing the mapping for the other clock rates seen during 337 the last period. 339 [[Some legacy implementations may dislike receiving multiple SR 340 packets. What should we do?]] 342 The RTP extension defined in Perkins & Schierl [RFC6051] MAY be used 343 to accelerate the synchronization. 345 4.2. RTP Receiver 347 An RTP Receiver MUST calculate the jitter using the following 348 formula: 350 D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) - 351 (arrival_time_i * clock_rate_i - timestamp_i) 353 An RTP Receiver MUST be able to handle a compound RTCP packet with 354 multiple SR packets. 356 For interoperability with legacy RTP implementations, an RTP receiver 357 MAY use the information in two consecutive SR packets to calculate 358 the clock rate used, i.e. if Ni is the NTP timestamp for the SR 359 packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the 360 NTP timestamp and RTP timestamp for the previous SR packet j, then 361 the clock rate can be guessed as the closest to (Ri - Rj) / (Ni - 362 Nj). 364 5. Security Considerations 366 TBD 368 6. IANA Considerations 370 This document requires no IANA actions.. 372 7. Acknowledgements 374 Thanks to Colin Perkins, Ali C. Begen and Magnus Westerlund for their 375 comments, suggestions and questions that helped to improve this 376 document. 378 Thanks to Robert Sparks and the attendees of SIPit 26 for the survey 379 on multiple clock rates interoperability. 381 This document was written with the xml2rfc tool described in 382 [RFC2629]. 384 8. References 386 8.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 392 Jacobson, "RTP: A Transport Protocol for Real-Time 393 Applications", STD 64, RFC 3550, July 2003. 395 8.2. Informative References 397 [I-D.ietf-avt-variable-rate-audio] 398 Wenger, S. and C. Perkins, "RTP Timestamp Frequency for 399 Variable Rate Audio Codecs", 400 draft-ietf-avt-variable-rate-audio-00 (work in progress), 401 October 2004. 403 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 404 June 1999. 406 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 407 Video Conferences with Minimal Control", STD 65, RFC 3551, 408 July 2003. 410 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 411 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 412 RFC 3556, July 2003. 414 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 415 Protocol Extended Reports (RTCP XR)", RFC 3611, 416 November 2003. 418 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 419 RTP Streams", RFC 5450, March 2009. 421 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 422 RFC 5484, March 2009. 424 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 425 Protocol (RTCP) Extensions for Single-Source Multicast 426 Sessions with Unicast Feedback", RFC 5760, February 2010. 428 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 429 Flows", RFC 6051, November 2010. 431 Appendix A. Using a fixed clock rate 433 An alternate way of fixing the multiple clock rates issue was 434 proposed in [I-D.ietf-avt-variable-rate-audio]. This document 435 proposed to define a unified clock rate, but the proposal was 436 rejected at IETF 61. 438 Appendix B. Behavior of legacy implementations 440 B.1. libccrtp 2.0.2 442 This library uses the formula described in Section 3.2.2. 444 Note that this library uses gettimeofday(2) which is not guaranteed 445 to increment monotonically, like when the clock is adjusted by NTP. 447 B.2. libmediastreamer0 2.6.0 449 This library (which uses the oRTP library) uses the formula described 450 in Section 3.2.2. 452 Note that in some environments this library uses gettimeofday(2) 453 which is not guaranteed to increment monotonically. 455 B.3. libpjmedia 1.0 457 This library uses the formula described in Section 3.2.2. 459 B.4. Android RTP stack 4.0.3 461 This library changes the SSRC each time the format changes, as 462 described in Section 3.1. 464 Appendix C. Release notes 466 This section must be removed before publication as an RFC. 468 C.1. Modifications between draft-ietf-avtext-multiple-clock-rates-02 469 and draft-ietf-avtext-multiple-clock-rates-01 471 o Readded the non-monotonic methods that was removed in a previous 472 version. 474 o Added analysis of FOSS RTP stacks. 476 o Changed author affiliation. 478 o Added AVTEXT area. 480 C.2. Modifications between draft-ietf-avtext-multiple-clock-rates-01 481 and draft-ietf-avtext-multiple-clock-rates-00 483 o New text says that the algorithms listed are the one currently 484 known. 486 o Explains capture_time. 488 o Nits. 490 C.3. Modifications between draft-ietf-avtext-multiple-clock-rates-00 491 and draft-petithuguenin-avtext-multiple-clock-rates-01 493 o Changed capture_state to capture_start. 495 C.4. Modifications between 496 draft-petithuguenin-avtext-multiple-clock-rates-01 and 497 draft-petithuguenin-avtext-multiple-clock-rates-00 499 o Clarified the goals for this documents 501 o Removed the non-monotonic method (replaced by Magnus formula). 503 o Moved the "RTP Sender and RTP Receiver section inside a new 504 "Recommendations" section. 506 o Inserted the new Sender formula inside the Recommendation section. 508 o Inserted the new jitter formula in the RTP Receiver section. 510 o Emptied the Analysis sections. 512 C.5. Modifications between 513 draft-petithuguenin-avtext-multiple-clock-rates-00 and 514 draft-petithuguenin-avt-multiple-clock-rates-03 516 o Initial release for avtext WG. 518 C.6. Modifications between 519 draft-petithuguenin-avt-multiple-clock-rates-03 and 520 draft-petithuguenin-avt-multiple-clock-rates-02 522 o Updated RFC reference. 524 C.7. Modifications between 525 draft-petithuguenin-avt-multiple-clock-rates-02 and 526 draft-petithuguenin-avt-multiple-clock-rates-01 528 o Having multiple SRs in a compound RTCP packet is OK. 530 o If RTCP is used, must send a BYE and not reuse the SSRC. 532 o Removed resolved notes. 534 o Acknowledged SIPit 26 survey. 536 o Fixed some nits. 538 C.8. Modifications between 539 draft-petithuguenin-avt-multiple-clock-rates-01 and 540 draft-petithuguenin-avt-multiple-clock-rates-00 542 o Complete rewrite as a Standard Track I-D modifying RFC 3550. 544 Authors' Addresses 546 Marc Petit-Huguenin 547 Unaffiliated 549 Email: petithug@acm.org 551 Glen Zorn (editor) 552 Network Zen 553 227/358 Thanon Sanphawut 554 Bang Na, Bangkok 10260 555 Thailand 557 Phone: +66 (0) 87-0404617 558 Email: glenzorn@gmail.com