idnits 2.17.1 draft-ietf-avtext-multiple-clock-rates-01.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 (July 11, 2011) is 4672 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 Stonyfish, Inc. 4 Updates: 3550 (if approved) July 11, 2011 5 Intended status: Standards Track 6 Expires: January 12, 2012 8 Support for multiple clock rates in an RTP session 9 draft-ietf-avtext-multiple-clock-rates-01 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 January 12, 2012. 35 Copyright Notice 37 Copyright (c) 2011 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. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2.1. Monotonic timestamps . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Interoperability Analysis . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 9 69 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 9 70 B.1. Modifications between 71 draft-ietf-avtext-multiple-clock-rates-01 and 72 draft-ietf-avtext-multiple-clock-rates-00 . . . . . . . . 9 73 B.2. Modifications between 74 draft-ietf-avtext-multiple-clock-rates-00 and 75 draft-petithuguenin-avtext-multiple-clock-rates-01 . . . . 9 76 B.3. Modifications between 77 draft-petithuguenin-avtext-multiple-clock-rates-01 and 78 draft-petithuguenin-avtext-multiple-clock-rates-00 . . . . 10 79 B.4. Modifications between 80 draft-petithuguenin-avtext-multiple-clock-rates-00 and 81 draft-petithuguenin-avt-multiple-clock-rates-03 . . . . . 10 82 B.5. Modifications between 83 draft-petithuguenin-avt-multiple-clock-rates-03 and 84 draft-petithuguenin-avt-multiple-clock-rates-02 . . . . . 10 85 B.6. Modifications between 86 draft-petithuguenin-avt-multiple-clock-rates-02 and 87 draft-petithuguenin-avt-multiple-clock-rates-01 . . . . . 10 88 B.7. Modifications between 89 draft-petithuguenin-avt-multiple-clock-rates-01 and 90 draft-petithuguenin-avt-multiple-clock-rates-00 . . . . . 10 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 1. Introduction 95 The clock rate is a parameter of the payload format. It is often 96 defined as been the same as the sampling rate but it is not always 97 the case (see e.g. the G722 and MPA audio codecs in [RFC3551]). 99 An RTP sender can switch between different payloads during the 100 lifetime of an RTP session and because clock rates are defined by 101 payload types, it is possible that the clock rate also varies during 102 an RTP session. RTP [RFC3550] lists using multiple clock rates as 103 one of the reasons to not use different payloads on the same SSRC but 104 unfortunately this advice was not always followed and some RTP 105 implementations change the payload in the same SSRC even if the 106 different payloads use different clock rates. 108 This creates three problems: 109 o The method used to calculate the RTP timestamp field in an RTP 110 packet is underspecified. 111 o When the same SSRC is used for different clock rates, it is 112 difficult to know what clock rate was used for the RTP timestamp 113 field in an RTCP SR packet. 114 o When the same SSRC is used for different clock rates, it is 115 difficult to know what clock rate was used for the interarrival 116 jitter field in an RTCP RR packet. 118 Table 1 contains a non-exhaustive list of fields in RTCP packets that 119 uses a clock rate as unit: 121 +---------------------+------------------+-----------+ 122 | Field name | RTCP packet type | Reference | 123 +---------------------+------------------+-----------+ 124 | RTP timestamp | SR | [RFC3550] | 125 | Interarrival jitter | RR | [RFC3550] | 126 | min_jitter | XR Summary Block | [RFC3611] | 127 | max_jitter | XR Summary Block | [RFC3611] | 128 | mean_jitter | XR Summary Block | [RFC3611] | 129 | dev_jitter | XR Summary Block | [RFC3611] | 130 | Interarrival jitter | IJ | [RFC5450] | 131 | RTP timestamp | SMPTETC | [RFC5484] | 132 | Jitter | RSI Jitter Block | [RFC5760] | 133 | Median jitter | RSI Stats Block | [RFC5760] | 134 +---------------------+------------------+-----------+ 136 Table 1 138 This document first tries to list in Section 2 and subsections all 139 known algorithms used in existing RTP implementations at the time of 140 writing. This sections are not normative. 142 Section 4 and subsections then recommend a unique algorithm that 143 modifies [RFC3550]. This sections are normative. 145 Section 5 and subsections then analyze what happen when the legacy 146 algorithms listed in Section 2 are used with the new algorithm listed 147 in Section 4. This sections are not normative. 149 2. Legacy RTP 151 The following sections describe the various ways legacy RTP 152 implementations behave when multiple clock rates are used. Legacy 153 RTP refers to RFC 3550 without the modifications introduced by this 154 document. 156 [[We need to list here all the methods used in the field. Please 157 send them to the author. NDA can be arranged if needed]] 159 2.1. Different SSRC 161 One way of managing multiple clock rates is to use a different SSRC 162 for each different clock rate, as in this case there is no ambiguity 163 on the clock rate used by fields in the RTCP packets. This method 164 also seems to be the original intent of RTP as can be deduced from 165 points 2 and 3 of section 5.2 of RFC 3550. 167 On the other hand changing the SSRC can be a problem for some 168 implementations designed to work only with unicast IP addresses, 169 where having multiple SSRCs is considered a corner case. Lip 170 synchronization can also be a problem in the interval between the 171 beginning of the new stream and the first RTCP SR packet. This is 172 not different than what happen at the beginning of the RTP session 173 but it can be more annoying for the end-user. 175 2.2. Same SSRC 177 The simplest way of managing multiple clock rates is to use the same 178 SSRC for all the payload types regardless of the clock rates. 180 Unfortunately there is no clear definition on how the RTP timestamp 181 should be calculated in this case. The following subsection presents 182 one algorithm used in the field. 184 2.2.1. Monotonic timestamps 186 The most common method of calculating the RTP timestamp ensures that 187 the value increases monotonically. The formula used by this method 188 is as follow: 190 timestamp = previous_timestamp + (current_capture_time - 191 previous_capture_time) * current_clock_rate 193 The problem with this method is that the jitter calculation on the 194 receiving side gives invalid result during the transition between two 195 clock rates, as shown in Table 2. The capture and arrival time are 196 in seconds, starting at the beginning of the capture of the first 197 packet; clock rate is in Hz; the RTP timestamp does not include the 198 random offset; the transit, jitter, and average jitter use the clock 199 rate as unit. 201 +-------+-------+-----------+---------+---------+--------+----------+ 202 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 203 | time | rate | timestamp | time | | | jitter | 204 +-------+-------+-----------+---------+---------+--------+----------+ 205 | 0 | 8000 | 0 | 0.1 | 800 | | | 206 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 207 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 208 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 209 | 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 | 210 | 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 | 211 | 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | 212 | 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | 213 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | 214 +-------+-------+-----------+---------+---------+--------+----------+ 216 Table 2 218 Calculating the correct transit time on the receiving side can be 219 done by using the following formulas: 221 (1) current_time_capture = current_timestamp - previous_timestamp) / 222 current_clock_rate + previous_time_capture 223 (2) transit = current_clock_rate * (time_arrival - 224 current_time_capture) 225 (3) previous_time_capture = current_time_capture 227 The main problem with this method, in addition to the fact that the 228 jitter calculation described in RFC 3550 cannot be used, is that is 229 it dependent on the previous RTP packets, packets that can be 230 reordered or lost in the network. But it seems that this is what 231 most implementations are using. 233 3. Terminology 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in [RFC2119]. 239 Clock rate: The multiplier used to convert from a wallclock value in 240 seconds to an equivalent RTP timestamp value (without the fixed 241 random offset). Note that RFC 3550 uses various terms like "clock 242 frequency", "media clock rate", "timestamp unit", "timestamp 243 frequency", and "RTP timestamp clock rate" as synonymous to clock 244 rate. 245 RTP Sender: A logical network element that sends RTP packets, sends 246 RTCP SR packets, and receives RTCP RR packets. 247 RTP Receiver: A logical network element that receives RTP packets, 248 receives RTCP SR packets, and sends RTCP RR packets. 250 4. Recommendations 252 4.1. RTP Sender 254 An RTP Sender with RTCP turned off (i.e. by setting the RS and RR 255 bandwidth modifiers defined in [RFC3556] to 0) SHOULD use a different 256 SSRC for each different clock rate but MAY use different clock rates 257 on the same SSRC as long as the RTP timestamp without the random 258 offset is calculated as explained below: 260 [[This was designed to help VoIP implementations who anyway never 261 cared about RTCP. Do we want to keep this?]] 263 Each time the clock rate changes, the start_offset and capture_start 264 values are calculated with the following formulas: 266 start_offset = (capture_time - capture_start) * previous_clock_rate 267 capture_start = capture_time 269 For the first RTP packet, the values are initialized with the 270 following formulas: 272 start_offset = 0 273 capture_start = capture_time 275 After eventually updating this values, the RTP timestamp is 276 calculated with the following formula: 278 timestamp = (capture_time - capture_start) * clock_rate + 279 start_offset 281 Note that in all the formulas, capture_time is the first instant the 282 new timestamp rate is used. 284 An RTP Sender with RTCP turned on MUST use a different SSRC for each 285 different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST 286 be used if the clock rate switches back to a value already seen in 287 the RTP stream. 289 To accelerate lip synchronization, the next compound RTCP packet sent 290 by the RTP sender MUST contain multiple SR packets, the first one 291 containing the mapping for the current clock rate and the next SR 292 packets containing the mapping for the other clock rates seen during 293 the last period. 295 [[Some legacy implementations may dislike receiving multiple SR 296 packets. What should we do?]] 298 The RTP extension defined in [RFC6051] MAY be used to accelerate the 299 synchronization. 301 4.2. RTP Receiver 303 An RTP Receiver MUST calculate the jitter using the following 304 formula: 306 D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) - 307 (arrival_time_i * clock_rate_i - timestamp_i) 309 An RTP Receiver MUST be able to handle a compound RTCP packet with 310 multiple SR packets. 312 For interoperability with legacy RTP implementations, an RTP receiver 313 MAY use the information in two consecutive SR packets to calculate 314 the clock rate used, i.e. if Ni is the NTP timestamp for the SR 315 packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the 316 NTP timestamp and RTP timestamp for the previous SR packet j, then 317 the clock rate can be guessed as the closest to (Ri - Rj) / (Ni - 318 Nj). 320 5. Interoperability Analysis 322 The next subsections analyze the various combinations between legacy 323 RTP implementations and RTP implementations that follow this document 324 specifications. 326 TBD 328 6. Security Considerations 330 TBD 332 7. IANA Considerations 334 No IANA considerations. 336 8. Acknowledgements 338 Thanks to Colin Perkins, Ali C. Begen and Magnus Westerlund for their 339 comments, suggestions and questions that helped to improve this 340 document. 342 Thanks to Robert Sparks and the attendees of SIPit 26 for the survey 343 on multiple clock rates interoperability. 345 This document was written with the xml2rfc tool described in 346 [RFC2629]. 348 9. References 350 9.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 356 Jacobson, "RTP: A Transport Protocol for Real-Time 357 Applications", STD 64, RFC 3550, July 2003. 359 9.2. Informative References 361 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 362 June 1999. 364 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 365 Video Conferences with Minimal Control", STD 65, RFC 3551, 366 July 2003. 368 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 369 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 370 RFC 3556, July 2003. 372 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 373 Protocol Extended Reports (RTCP XR)", RFC 3611, 374 November 2003. 376 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 377 RTP Streams", RFC 5450, March 2009. 379 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 380 RFC 5484, March 2009. 382 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 383 Protocol (RTCP) Extensions for Single-Source Multicast 384 Sessions with Unicast Feedback", RFC 5760, February 2010. 386 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 387 Flows", RFC 6051, November 2010. 389 [uRTR] 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 Appendix A. Using a fixed clock rate 396 An alternate way of fixing the multiple clock rates issue was 397 proposed in [uRTR]. This document proposed to define a unified clock 398 rate, but the proposal was rejected at IETF 61. 400 Appendix B. Release notes 402 This section must be removed before publication as an RFC. 404 B.1. Modifications between draft-ietf-avtext-multiple-clock-rates-01 405 and draft-ietf-avtext-multiple-clock-rates-00 407 o New text says that the algorithms listed are the one currently 408 known. 409 o Explains capture_time. 410 o Nits. 412 B.2. Modifications between draft-ietf-avtext-multiple-clock-rates-00 413 and draft-petithuguenin-avtext-multiple-clock-rates-01 415 o Changed capture_state to capture_start. 417 B.3. Modifications between 418 draft-petithuguenin-avtext-multiple-clock-rates-01 and 419 draft-petithuguenin-avtext-multiple-clock-rates-00 421 o Clarified the goals for this documents 422 o Removed the non-monotonic method (replaced by Magnus formula). 423 o Moved the "RTP Sender and RTP Receiver section inside a new 424 "Recommendations" section. 425 o Inserted the new Sender formula inside the Recommendation section. 426 o Inserted the new jitter formula in the RTP Receiver section. 427 o Emptied the Analysis sections. 429 B.4. Modifications between 430 draft-petithuguenin-avtext-multiple-clock-rates-00 and 431 draft-petithuguenin-avt-multiple-clock-rates-03 433 o Initial release for avtext WG. 435 B.5. Modifications between 436 draft-petithuguenin-avt-multiple-clock-rates-03 and 437 draft-petithuguenin-avt-multiple-clock-rates-02 439 o Updated RFC reference. 441 B.6. Modifications between 442 draft-petithuguenin-avt-multiple-clock-rates-02 and 443 draft-petithuguenin-avt-multiple-clock-rates-01 445 o Having multiple SRs in a compound RTCP packet is OK. 446 o If RTCP is used, must send a BYE and not reuse the SSRC. 447 o Removed resolved notes. 448 o Acknowledged SIPit 26 survey. 449 o Fixed some nits. 451 B.7. Modifications between 452 draft-petithuguenin-avt-multiple-clock-rates-01 and 453 draft-petithuguenin-avt-multiple-clock-rates-00 455 o Complete rewrite as a Standard Track I-D modifying RFC 3550. 457 Author's Address 459 Marc Petit-Huguenin 460 Stonyfish, Inc. 462 Email: petithug@acm.org