idnits 2.17.1 draft-petithuguenin-avtext-multiple-clock-rates-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 (February 14, 2011) is 4814 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 (==), 5 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 Stonyfish, Inc. 4 Updates: 3550 (if approved) February 14, 2011 5 Intended status: Standards Track 6 Expires: August 18, 2011 8 Support for multiple clock rates in an RTP session 9 draft-petithuguenin-avtext-multiple-clock-rates-00 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. This document may not be modified, 22 and derivative works of it may not be created, except to format it 23 for publication as an RFC or to translate it into languages other 24 than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 18, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 5 60 2.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 6 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Interoperability Analysis . . . . . . . . . . . . . . . . . . 8 65 6.1. Legacy RTP Sender using different SSRC sending to new 66 RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.2. Legacy RTP Sender using same SSRC with monotonic 68 timestamps sending to new RTP Receiver . . . . . . . . . . 9 69 6.3. Legacy RTP Sender using same SSRC with non-monotonic 70 timestamps sending to new RTP Receiver . . . . . . . . . . 9 71 6.4. New RTP Sender using different SSRC sending to legacy 72 RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.5. New RTP Sender using different SSRC sending to new RTP 74 Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.6. New RTP Sender using same SSRC with non-monotonic 76 timestamps to legacy RTP Receiver . . . . . . . . . . . . 9 77 6.7. New RTP Sender using same SSRC with non-monotonic 78 timestamps to new RTP Receiver . . . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 85 Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 11 86 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 11 87 B.1. Modifications between 88 draft-petithuguenin-avtext-multiple-clock-rates-00 and 89 draft-petithuguenin-avt-multiple-clock-rates-03 . . . . . 11 90 B.2. Modifications between 91 draft-petithuguenin-avt-multiple-clock-rates-03 and 92 draft-petithuguenin-avt-multiple-clock-rates-02 . . . . . 11 93 B.3. Modifications between 94 draft-petithuguenin-avt-multiple-clock-rates-02 and 95 draft-petithuguenin-avt-multiple-clock-rates-01 . . . . . 11 97 B.4. Modifications between 98 draft-petithuguenin-avt-multiple-clock-rates-01 and 99 draft-petithuguenin-avt-multiple-clock-rates-00 . . . . . 11 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 1. Introduction 104 The clock rate is a parameter of the payload format. It is often 105 defined as been the same as the sampling rate but it is not always 106 the case (see e.g. the G722 and MPA audio codecs in [RFC3551]). 108 An RTP sender can switch between different payloads during the 109 lifetime of an RTP session and because clock rates are defined by 110 payload types, it is possible that the clock rate also varies during 111 an RTP session. RTP [RFC3550] lists using multiple clock rates as 112 one of the reasons to not use different payloads on the same SSRC but 113 unfortunately this advice was not always followed and some RTP 114 implementations change the payload in the same SSRC even if the 115 different payloads use different clock rates. 117 This creates three problems: 118 o The method used to calculate the RTP timestamp field in an RTP 119 packet is underspecified. 120 o When the same SSRC is used for different clock rates, it is 121 difficult to know what clock rate was used for the RTP timestamp 122 field in an RTCP SR packet. 123 o When the same SSRC is used for different clock rates, it is 124 difficult to know what clock rate was used for the interarrival 125 jitter field in an RTCP RR packet. 127 Table 1 contains a non-exhaustive list of fields in RTCP packets that 128 uses a clock rate as unit: 130 +---------------------+------------------+-----------+ 131 | Field name | RTCP packet type | Reference | 132 +---------------------+------------------+-----------+ 133 | RTP timestamp | SR | [RFC3550] | 134 | Interarrival jitter | RR | [RFC3550] | 135 | min_jitter | XR Summary Block | [RFC3611] | 136 | max_jitter | XR Summary Block | [RFC3611] | 137 | mean_jitter | XR Summary Block | [RFC3611] | 138 | dev_jitter | XR Summary Block | [RFC3611] | 139 | Interarrival jitter | IJ | [RFC5450] | 140 | RTP timestamp | SMPTETC | [RFC5484] | 141 | Jitter | RSI Jitter Block | [RFC5760] | 142 | Median jitter | RSI Stats Block | [RFC5760] | 143 +---------------------+------------------+-----------+ 145 Table 1 147 This document changes the RTP specification by recommending to use a 148 different SSRC for each clock rate in most of the cases. 150 2. Legacy RTP 152 The following sections describe the various ways legacy RTP 153 implementations behave when multiple clock rates are used. Legacy 154 RTP refers to RFC 3550 without the modifications introduced by this 155 document. 157 2.1. Different SSRC 159 One way of managing multiple clock rates is to use a different SSRC 160 for each different clock rate, as in this case there is no ambiguity 161 on the clock rate used by fields in the RTCP packets. This method 162 also seems to be the original intent of RTP as can be deduced from 163 points 2 and 3 of section 5.2 of RFC 3550. 165 On the other hand changing the SSRC can be a problem for some 166 implementations designed to work only with unicast IP addresses, 167 where having multiple SSRCs is considered a corner case. Lip 168 synchronization can also be a problem in the interval between the 169 beginning of the new stream and the first RTCP SR packet. This is 170 not different than what happen at the beginning of the RTP session 171 but it can be more annoying for the end-user. 173 2.2. Same SSRC 175 The simplest way of managing multiple clock rates is to use the same 176 SSRC for all the payload types regardless of the clock rates. 178 Unfortunately there is no clear definition on how the RTP timestamp 179 should be calculated in this case. The following subsections present 180 two variants. 182 2.2.1. Monotonic timestamps 184 The most common method of calculating the RTP timestamp ensures that 185 the value increases monotonically. The formula used by this method 186 is as follow: 188 timestamp = previous_timestamp + (current_capture_time - 189 previous_capture_time) * current_clock_rate 191 The problem with this method is that the jitter calculation on the 192 receiving side gives invalid result during the transition between two 193 clock rates, as shown in Table 2. The capture and arrival time are 194 in seconds, starting at the beginning of the capture of the first 195 packet; clock rate is in Hz; the RTP timestamp does not include the 196 random offset; the transit, jitter, and average jitter use the clock 197 rate as unit. 199 +-------+-------+-----------+---------+---------+--------+----------+ 200 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 201 | time | rate | timestamp | time | | | jitter | 202 +-------+-------+-----------+---------+---------+--------+----------+ 203 | 0 | 8000 | 0 | 0.1 | 800 | | | 204 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 205 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 206 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 207 | 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 | 208 | 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 | 209 | 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | 210 | 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | 211 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | 212 +-------+-------+-----------+---------+---------+--------+----------+ 214 Table 2 216 Calculating the correct transit time on the receiving side can be 217 done by using the following formulas: 219 (1) current_time_capture = current_timestamp - previous_timestamp) / 220 current_clock_rate + previous_time_capture 221 (2) transit = current_clock_rate * (time_arrival - 222 current_time_capture) 223 (3) previous_time_capture = current_time_capture 225 The main problem with this method, in addition to the fact that the 226 jitter calculation described in RFC 3550 cannot be used, is that is 227 it dependent on the previous RTP packets, packets that can be 228 reordered or lost in the network. But it seems that this is what 229 most implementations are using. 231 2.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 238 With this formula, the jitter calculation is correct but the RTP 239 timestamp values are no longer increasing monotonically as shown in 240 Table 3. RFC 3550 states that "[t]he sampling instant MUST be 241 derived from a clock that increments monotonically[...]" but nowhere 242 says that the RTP timestamp must increment monotonically. 244 +-------+-------+-----------+---------+---------+--------+----------+ 245 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 246 | time | rate | timestamp | time | | | jitter | 247 +-------+-------+-----------+---------+---------+--------+----------+ 248 | 0 | 8000 | 0 | 0.1 | 800 | | | 249 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 250 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 251 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 252 | 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 | 253 | 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 | 254 | 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 | 255 | 0.14 | 16000 | 2240 | 0.24 | 1600 | 0 | 0 | 256 | 0.16 | 16000 | 2560 | 0.26 | 1600 | 0 | 0 | 257 | 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 | 258 | 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 | 259 +-------+-------+-----------+---------+---------+--------+----------+ 261 Table 3 263 The advantage with this method is that it works with the jitter 264 calculation described in RFC 3550, a long as the correct clock rates 265 are used. 267 3. Terminology 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 271 document are to be interpreted as described in [RFC2119]. 273 Clock rate: The multiplier used to convert from a wallclock value in 274 seconds to an equivalent RTP timestamp value (without the fixed 275 random offset). Note that RFC 3550 uses various terms like "clock 276 frequency", "media clock rate", "timestamp unit", "timestamp 277 frequency", and "RTP timestamp clock rate" as synonymous to clock 278 rate. 279 RTP Sender: A logical network element that sends RTP packets, sends 280 RTCP SR packets, and receives RTCP RR packets. 281 RTP Receiver: A logical network element that receives RTP packets, 282 receives RTCP SR packets, and sends RTCP RR packets. 284 4. RTP Sender 286 An RTP Sender with RTCP turned off (i.e. by setting the RS and RR 287 bandwidth modifiers defined in [RFC3556] to 0) SHOULD use a different 288 SSRC for each different clock rate but MAY use different clock rates 289 on the same SSRC as long as the RTP timestamp is calculated as 290 described in Section 2.2.2. 292 An RTP Sender with RTCP turned on MUST use a different SSRC for each 293 different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST 294 be used if the clock rate switches back to a value already seen in 295 the RTP stream. 297 To accelerate lip synchronization, the next compound RTCP packet sent 298 by the RTP sender MUST contain multiple SR packets, the first one 299 containing the mapping for the current clock rate and the next SR 300 packets containing the mapping for the other clock rates seen during 301 the last period. 303 The RTP extension defined in [RFC6051] MAY be used to accelerate the 304 synchronization. 306 5. RTP Receiver 308 An RTP Receiver MUST be able to handle clock rate changes either on 309 the same SSRC (Section 2.1) or on different SSRC (Section 2.2.2). 311 An RTP Receiver MUST be able to handle a compound RTCP packet with 312 multiple SR packets. 314 For interoperability with legacy RTP implementations, an RTP receiver 315 MAY use the information in two consecutive SR packets to calculate 316 the clock rate used, i.e. if Ni is the NTP timestamp for the SR 317 packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the 318 NTP timestamp and RTP timestamp for the previous SR packet j, then 319 the clock rate can be guessed as the closest to (Ri - Rj) / (Ni - 320 Nj). 322 6. Interoperability Analysis 324 The next subsections analyze the various combinations between legacy 325 RTP implementations and RTP implementations that follow this document 326 specifications. 328 6.1. Legacy RTP Sender using different SSRC sending to new RTP Receiver 330 Because a specific clock rate is associated to a specific SSRC, there 331 is no ambiguity in the RTP timestamp received in the RTP packet or SR 332 packet or in the jitter sent in the RR packet. 334 6.2. Legacy RTP Sender using same SSRC with monotonic timestamps 335 sending to new RTP Receiver 337 The new RTP Receiver will not be able to rebuild the correct RTP 338 timestamp so the jitter will be incorrect. Note that this is not 339 different than if a legacy RTP Receiver is used. 341 6.3. Legacy RTP Sender using same SSRC with non-monotonic timestamps 342 sending to new RTP Receiver 344 TBD 346 6.4. New RTP Sender using different SSRC sending to legacy RTP Receiver 348 Because a specific clock rate is associated to a specific SSRC, there 349 is no ambiguity in the RTP timestamp received in the RTP packet or SR 350 packet or in the jitter sent in the RR packet. Some legacy RTP 351 implementations may have problems when receiving multiple SR packets. 353 6.5. New RTP Sender using different SSRC sending to new RTP Receiver 355 Because a specific clock rate is associated to a specific SSRC, there 356 is no ambiguity in the RTP timestamp received in the RTP packet or SR 357 packet or in the jitter sent in the RR packet. 359 6.6. New RTP Sender using same SSRC with non-monotonic timestamps to 360 legacy RTP Receiver 362 Because this combination is used only when no RTCP packets are 363 exchanged, there is no problem interpreting the RTCP field units. 364 Some legacy RTP implementations may have problems if the jitter clock 365 rates are not correctly managed. 367 6.7. New RTP Sender using same SSRC with non-monotonic timestamps to 368 new RTP Receiver 370 Because this combination is used only when no RTCP packets are 371 exchanged, there is no problem interpreting the RTCP field units. 373 7. Security Considerations 375 TBD 377 8. IANA Considerations 379 No IANA considerations. 381 9. Acknowledgements 383 Thanks to Colin Perkins and Ali C. Begen for their comments, 384 suggestions and questions that helped to improve this document. 386 Thanks to Robert Sparks and the attendants of SIPit 26 for the survey 387 on multiple clock rates interoperability. 389 This document was written with the xml2rfc tool described in 390 [RFC2629]. 392 10. References 394 10.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 400 Jacobson, "RTP: A Transport Protocol for Real-Time 401 Applications", STD 64, RFC 3550, July 2003. 403 10.2. Informative References 405 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 406 June 1999. 408 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 409 Video Conferences with Minimal Control", STD 65, RFC 3551, 410 July 2003. 412 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 413 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 414 RFC 3556, July 2003. 416 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 417 Protocol Extended Reports (RTCP XR)", RFC 3611, 418 November 2003. 420 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 421 RTP Streams", RFC 5450, March 2009. 423 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 424 RFC 5484, March 2009. 426 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 427 Protocol (RTCP) Extensions for Single-Source Multicast 428 Sessions with Unicast Feedback", RFC 5760, February 2010. 430 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 431 Flows", RFC 6051, November 2010. 433 [uRTR] Wenger, S. and C. Perkins, "RTP Timestamp Frequency for 434 Variable Rate Audio Codecs", 435 draft-ietf-avt-variable-rate-audio-00 (work in progress), 436 October 2004. 438 Appendix A. Using a fixed clock rate 440 An alternate way of fixing the multiple clock rates issue was 441 proposed in [uRTR]. This document proposed to define a unified clock 442 rate, but the proposal was rejected at IETF 61. 444 Appendix B. Release notes 446 This section must be removed before publication as an RFC. 448 B.1. Modifications between 449 draft-petithuguenin-avtext-multiple-clock-rates-00 and 450 draft-petithuguenin-avt-multiple-clock-rates-03 452 o Initial release for avtext WG. 454 B.2. Modifications between 455 draft-petithuguenin-avt-multiple-clock-rates-03 and 456 draft-petithuguenin-avt-multiple-clock-rates-02 458 o Updated RFC reference. 460 B.3. Modifications between 461 draft-petithuguenin-avt-multiple-clock-rates-02 and 462 draft-petithuguenin-avt-multiple-clock-rates-01 464 o Having multiple SRs in a compound RTCP packet is OK. 465 o If RTCP is used, must send a BYE and not reuse the SSRC. 466 o Removed resolved notes. 467 o Acknowledged SIPit 26 survey. 468 o Fixed some nits. 470 B.4. Modifications between 471 draft-petithuguenin-avt-multiple-clock-rates-01 and 472 draft-petithuguenin-avt-multiple-clock-rates-00 474 o Complete rewrite as a Standard Track I-D modifying RFC 3550. 476 Author's Address 478 Marc Petit-Huguenin 479 Stonyfish, Inc. 481 Email: petithug@acm.org