idnits 2.17.1 draft-petithuguenin-avt-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 (January 10, 2011) is 4852 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) January 10, 2011 5 Intended status: Standards Track 6 Expires: July 14, 2011 8 Support for multiple clock rates in an RTP session 9 draft-petithuguenin-avt-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 July 14, 2011. 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 2.2.2. Non-monotonic timestamps . . . . . . . . . . . . . . . 5 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Interoperability Analysis . . . . . . . . . . . . . . . . . . 7 62 6.1. Legacy RTP Sender using different SSRC sending to new 63 RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.2. Legacy RTP Sender using same SSRC with monotonic 65 timestamps sending to new RTP Receiver . . . . . . . . . . 8 66 6.3. Legacy RTP Sender using same SSRC with non-monotonic 67 timestamps sending to new RTP Receiver . . . . . . . . . . 8 68 6.4. New RTP Sender using different SSRC sending to legacy 69 RTP Receiver . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.5. New RTP Sender using different SSRC sending to new RTP 71 Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6.6. New RTP Sender using same SSRC with non-monotonic 73 timestamps to legacy RTP Receiver . . . . . . . . . . . . 8 74 6.7. New RTP Sender using same SSRC with non-monotonic 75 timestamps to new RTP Receiver . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 82 Appendix A. Using a fixed clock rate . . . . . . . . . . . . . . 10 83 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 10 84 B.1. Modifications between -03 and -02 . . . . . . . . . . . . 10 85 B.2. Modifications between -02 and -01 . . . . . . . . . . . . 10 86 B.3. Modifications between -01 and -00 . . . . . . . . . . . . 10 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 The clock rate is a parameter of the payload format. It is often 92 defined as been the same as the sampling rate but it is not always 93 the case (see e.g. the G722 and MPA audio codecs in [RFC3551]). 95 An RTP sender can switch between different payloads during the 96 lifetime of an RTP session and because clock rates are defined by 97 payload types, it is possible that the clock rate also varies during 98 an RTP session. RTP [RFC3550] lists using multiple clock rates as 99 one of the reasons to not use different payloads on the same SSRC but 100 unfortunately this advice was not always followed and some RTP 101 implementations change the payload in the same SSRC even if the 102 different payloads use different clock rates. 104 This creates three problems: 105 o The method used to calculate the RTP timestamp field in an RTP 106 packet is underspecified. 107 o When the same SSRC is used for different clock rates, it is 108 difficult to know what clock rate was used for the RTP timestamp 109 field in an RTCP SR packet. 110 o When the same SSRC is used for different clock rates, it is 111 difficult to know what clock rate was used for the interarrival 112 jitter field in an RTCP RR packet. 114 Table 1 contains a non-exhaustive list of fields in RTCP packets that 115 uses a clock rate as unit: 117 +---------------------+------------------+-----------+ 118 | Field name | RTCP packet type | Reference | 119 +---------------------+------------------+-----------+ 120 | RTP timestamp | SR | [RFC3550] | 121 | Interarrival jitter | RR | [RFC3550] | 122 | min_jitter | XR Summary Block | [RFC3611] | 123 | max_jitter | XR Summary Block | [RFC3611] | 124 | mean_jitter | XR Summary Block | [RFC3611] | 125 | dev_jitter | XR Summary Block | [RFC3611] | 126 | Interarrival jitter | IJ | [RFC5450] | 127 | RTP timestamp | SMPTETC | [RFC5484] | 128 | Jitter | RSI Jitter Block | [RFC5760] | 129 | Median jitter | RSI Stats Block | [RFC5760] | 130 +---------------------+------------------+-----------+ 132 Table 1 134 This document changes the RTP specification by recommending to use a 135 different SSRC for each clock rate in most of the cases. 137 2. Legacy RTP 139 The following sections describe the various ways legacy RTP 140 implementations behave when multiple clock rates are used. Legacy 141 RTP refers to RFC 3550 without the modifications introduced by this 142 document. 144 2.1. Different SSRC 146 One way of managing multiple clock rates is to use a different SSRC 147 for each different clock rate, as in this case there is no ambiguity 148 on the clock rate used by fields in the RTCP packets. This method 149 also seems to be the original intent of RTP as can be deduced from 150 points 2 and 3 of section 5.2 of RFC 3550. 152 On the other hand changing the SSRC can be a problem for some 153 implementations designed to work only with unicast IP addresses, 154 where having multiple SSRCs is considered a corner case. Lip 155 synchronization can also be a problem in the interval between the 156 beginning of the new stream and the first RTCP SR packet. This is 157 not different than what happen at the beginning of the RTP session 158 but it can be more annoying for the end-user. 160 2.2. Same SSRC 162 The simplest way of managing multiple clock rates is to use the same 163 SSRC for all the payload types regardless of the clock rates. 165 Unfortunately there is no clear definition on how the RTP timestamp 166 should be calculated in this case. The following subsections present 167 two variants. 169 2.2.1. Monotonic timestamps 171 The most common method of calculating the RTP timestamp ensures that 172 the value increases monotonically. The formula used by this method 173 is as follow: 175 timestamp = previous_timestamp + (current_capture_time - 176 previous_capture_time) * current_clock_rate 178 The problem with this method is that the jitter calculation on the 179 receiving side gives invalid result during the transition between two 180 clock rates, as shown in Table 2. The capture and arrival time are 181 in seconds, starting at the beginning of the capture of the first 182 packet; clock rate is in Hz; the RTP timestamp does not include the 183 random offset; the transit, jitter, and average jitter use the clock 184 rate as unit. 186 +-------+-------+-----------+---------+---------+--------+----------+ 187 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 188 | time | rate | timestamp | time | | | jitter | 189 +-------+-------+-----------+---------+---------+--------+----------+ 190 | 0 | 8000 | 0 | 0.1 | 800 | | | 191 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 192 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 193 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 194 | 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 | 195 | 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 | 196 | 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | 197 | 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | 198 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | 199 +-------+-------+-----------+---------+---------+--------+----------+ 201 Table 2 203 Calculating the correct transit time on the receiving side can be 204 done by using the following formulas: 206 (1) current_time_capture = current_timestamp - previous_timestamp) / 207 current_clock_rate + previous_time_capture 208 (2) transit = current_clock_rate * (time_arrival - 209 current_time_capture) 210 (3) previous_time_capture = current_time_capture 212 The main problem with this method, in addition to the fact that the 213 jitter calculation described in RFC 3550 cannot be used, is that is 214 it dependent on the previous RTP packets, packets that can be 215 reordered or lost in the network. But it seems that this is what 216 most implementations are using. 218 2.2.2. Non-monotonic timestamps 220 An alternate way of generating the RTP timestamps is to use the 221 following formula: 223 timestamp = capture_time * clock_rate 225 With this formula, the jitter calculation is correct but the RTP 226 timestamp values are no longer increasing monotonically as shown in 227 Table 3. RFC 3550 states that "[t]he sampling instant MUST be 228 derived from a clock that increments monotonically[...]" but nowhere 229 says that the RTP timestamp must increment monotonically. 231 +-------+-------+-----------+---------+---------+--------+----------+ 232 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 233 | time | rate | timestamp | time | | | jitter | 234 +-------+-------+-----------+---------+---------+--------+----------+ 235 | 0 | 8000 | 0 | 0.1 | 800 | | | 236 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 237 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 238 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 239 | 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 | 240 | 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 | 241 | 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 | 242 | 0.14 | 16000 | 2240 | 0.24 | 1600 | 0 | 0 | 243 | 0.16 | 16000 | 2560 | 0.26 | 1600 | 0 | 0 | 244 | 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 | 245 | 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 | 246 +-------+-------+-----------+---------+---------+--------+----------+ 248 Table 3 250 The advantage with this method is that it works with the jitter 251 calculation described in RFC 3550, a long as the correct clock rates 252 are used. 254 3. Terminology 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in [RFC2119]. 260 Clock rate: The multiplier used to convert from a wallclock value in 261 seconds to an equivalent RTP timestamp value (without the fixed 262 random offset). Note that RFC 3550 uses various terms like "clock 263 frequency", "media clock rate", "timestamp unit", "timestamp 264 frequency", and "RTP timestamp clock rate" as synonymous to clock 265 rate. 266 RTP Sender: A logical network element that sends RTP packets, sends 267 RTCP SR packets, and receives RTCP RR packets. 268 RTP Receiver: A logical network element that receives RTP packets, 269 receives RTCP SR packets, and sends RTCP RR packets. 271 4. RTP Sender 273 An RTP Sender with RTCP turned off (i.e. by setting the RS and RR 274 bandwidth modifiers defined in [RFC3556] to 0) SHOULD use a different 275 SSRC for each different clock rate but MAY use different clock rates 276 on the same SSRC as long as the RTP timestamp is calculated as 277 described in Section 2.2.2. 279 An RTP Sender with RTCP turned on MUST use a different SSRC for each 280 different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST 281 be used if the clock rate switches back to a value already seen in 282 the RTP stream. 284 To accelerate lip synchronization, the next compound RTCP packet sent 285 by the RTP sender MUST contain multiple SR packets, the first one 286 containing the mapping for the current clock rate and the next SR 287 packets containing the mapping for the other clock rates seen during 288 the last period. 290 The RTP extension defined in [RFC6051] MAY be used to accelerate the 291 synchronization. 293 5. RTP Receiver 295 An RTP Receiver MUST be able to handle clock rate changes either on 296 the same SSRC (Section 2.1) or on different SSRC (Section 2.2.2). 298 An RTP Receiver MUST be able to handle a compound RTCP packet with 299 multiple SR packets. 301 For interoperability with legacy RTP implementations, an RTP receiver 302 MAY use the information in two consecutive SR packets to calculate 303 the clock rate used, i.e. if Ni is the NTP timestamp for the SR 304 packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the 305 NTP timestamp and RTP timestamp for the previous SR packet j, then 306 the clock rate can be guessed as the closest to (Ri - Rj) / (Ni - 307 Nj). 309 6. Interoperability Analysis 311 The next subsections analyze the various combinations between legacy 312 RTP implementations and RTP implementations that follow this document 313 specifications. 315 6.1. Legacy RTP Sender using different SSRC sending to new RTP Receiver 317 Because a specific clock rate is associated to a specific SSRC, there 318 is no ambiguity in the RTP timestamp received in the RTP packet or SR 319 packet or in the jitter sent in the RR packet. 321 6.2. Legacy RTP Sender using same SSRC with monotonic timestamps 322 sending to new RTP Receiver 324 The new RTP Receiver will not be able to rebuild the correct RTP 325 timestamp so the jitter will be incorrect. Note that this is not 326 different than if a legacy RTP Receiver is used. 328 6.3. Legacy RTP Sender using same SSRC with non-monotonic timestamps 329 sending to new RTP Receiver 331 TBD 333 6.4. New RTP Sender using different SSRC sending to legacy RTP Receiver 335 Because a specific clock rate is associated to a specific SSRC, there 336 is no ambiguity in the RTP timestamp received in the RTP packet or SR 337 packet or in the jitter sent in the RR packet. Some legacy RTP 338 implementations may have problems when receiving multiple SR packets. 340 6.5. New RTP Sender using different SSRC sending to new RTP Receiver 342 Because a specific clock rate is associated to a specific SSRC, there 343 is no ambiguity in the RTP timestamp received in the RTP packet or SR 344 packet or in the jitter sent in the RR packet. 346 6.6. New RTP Sender using same SSRC with non-monotonic timestamps to 347 legacy RTP Receiver 349 Because this combination is used only when no RTCP packets are 350 exchanged, there is no problem interpreting the RTCP field units. 351 Some legacy RTP implementations may have problems if the jitter clock 352 rates are not correctly managed. 354 6.7. New RTP Sender using same SSRC with non-monotonic timestamps to 355 new RTP Receiver 357 Because this combination is used only when no RTCP packets are 358 exchanged, there is no problem interpreting the RTCP field units. 360 7. Security Considerations 362 TBD 364 8. IANA Considerations 366 No IANA considerations. 368 9. Acknowledgements 370 Thanks to Colin Perkins and Ali C. Begen for their comments, 371 suggestions and questions that helped to improve this document. 373 Thanks to Robert Sparks and the attendants of SIPit 26 for the survey 374 on multiple clock rates interoperability. 376 This document was written with the xml2rfc tool described in 377 [RFC2629]. 379 10. References 381 10.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 387 Jacobson, "RTP: A Transport Protocol for Real-Time 388 Applications", STD 64, RFC 3550, July 2003. 390 10.2. Informative References 392 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 393 June 1999. 395 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 396 Video Conferences with Minimal Control", STD 65, RFC 3551, 397 July 2003. 399 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 400 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 401 RFC 3556, July 2003. 403 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 404 Protocol Extended Reports (RTCP XR)", RFC 3611, 405 November 2003. 407 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 408 RTP Streams", RFC 5450, March 2009. 410 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 411 RFC 5484, March 2009. 413 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 414 Protocol (RTCP) Extensions for Single-Source Multicast 415 Sessions with Unicast Feedback", RFC 5760, February 2010. 417 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 418 Flows", RFC 6051, November 2010. 420 [uRTR] Wenger, S. and C. Perkins, "RTP Timestamp Frequency for 421 Variable Rate Audio Codecs", 422 draft-ietf-avt-variable-rate-audio-00 (work in progress), 423 October 2004. 425 Appendix A. Using a fixed clock rate 427 An alternate way of fixing the multiple clock rates issue was 428 proposed in [uRTR]. This document proposed to define a unified clock 429 rate, but the proposal was rejected at IETF 61. 431 Appendix B. Release notes 433 This section must be removed before publication as an RFC. 435 B.1. Modifications between -03 and -02 437 o Updated RFC reference. 439 B.2. Modifications between -02 and -01 441 o Having multiple SRs in a compound RTCP packet is OK. 442 o If RTCP is used, must send a BYE and not reuse the SSRC. 443 o Removed resolved notes. 444 o Acknowledged SIPit 26 survey. 445 o Fixed some nits. 447 B.3. Modifications between -01 and -00 449 o Complete rewrite as a Standard Track I-D modifying RFC 3550. 451 Author's Address 453 Marc Petit-Huguenin 454 Unaffiliated 456 Email: petithug@acm.org