idnits 2.17.1 draft-petithuguenin-avt-multiple-clock-rates-02.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 10, 2010) is 5011 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) == Outdated reference: A later version (-13) exists of draft-ietf-avt-rapid-rtp-sync-12 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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) July 10, 2010 5 Intended status: Standards Track 6 Expires: January 11, 2011 8 Support for multiple clock rates in an RTP session 9 draft-petithuguenin-avt-multiple-clock-rates-02 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 11, 2011. 35 Copyright Notice 37 Copyright (c) 2010 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 -02 and -01 . . . . . . . . . . . . 10 85 B.2. Modifications between -01 and -00 . . . . . . . . . . . . 10 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Introduction 90 The clock rate is a parameter of the payload format. It is often 91 defined as been the same as the sampling rate but it is not always 92 the case (see e.g. the G722 and MPA audio codecs in [RFC3551]). 94 An RTP sender can switch between different payloads during the 95 lifetime of an RTP session and because clock rates are defined by 96 payload types, it is possible that the clock rate also varies during 97 an RTP session. RTP [RFC3550] lists using multiple clock rates as 98 one of the reasons to not use different payloads on the same SSRC but 99 unfortunately this advice was not always followed and some RTP 100 implementations change the payload in the same SSRC even if the 101 different payloads use different clock rates. 103 This creates three problems: 104 o The method used to calculate the RTP timestamp field in an RTP 105 packet is underspecified. 106 o When the same SSRC is used for different clock rates, it is 107 difficult to know what clock rate was used for the RTP timestamp 108 field in an RTCP SR packet. 109 o When the same SSRC is used for different clock rates, it is 110 difficult to know what clock rate was used for the interarrival 111 jitter field in an RTCP RR packet. 113 Table 1 contains a non-exhaustive list of fields in RTCP packets that 114 uses a clock rate as unit: 116 +---------------------+------------------+-----------+ 117 | Field name | RTCP packet type | Reference | 118 +---------------------+------------------+-----------+ 119 | RTP timestamp | SR | [RFC3550] | 120 | Interarrival jitter | RR | [RFC3550] | 121 | min_jitter | XR Summary Block | [RFC3611] | 122 | max_jitter | XR Summary Block | [RFC3611] | 123 | mean_jitter | XR Summary Block | [RFC3611] | 124 | dev_jitter | XR Summary Block | [RFC3611] | 125 | Interarrival jitter | IJ | [RFC5450] | 126 | RTP timestamp | SMPTETC | [RFC5484] | 127 | Jitter | RSI Jitter Block | [RFC5760] | 128 | Median jitter | RSI Stats Block | [RFC5760] | 129 +---------------------+------------------+-----------+ 131 Table 1 133 This document changes the RTP specification by recommending to use a 134 different SSRC for each clock rate in most of the cases. 136 2. Legacy RTP 138 The following sections describe the various ways legacy RTP 139 implementations behave when multiple clock rates are used. Legacy 140 RTP refers to RFC 3550 without the modifications introduced by this 141 document. 143 2.1. Different SSRC 145 One way of managing multiple clock rates is to use a different SSRC 146 for each different clock rate, as in this case there is no ambiguity 147 on the clock rate used by fields in the RTCP packets. This method 148 also seems to be the original intent of RTP as can be deduced from 149 points 2 and 3 of section 5.2 of RFC 3550. 151 On the other hand changing the SSRC can be a problem for some 152 implementations designed to work only with unicast IP addresses, 153 where having multiple SSRCs is considered a corner case. Lip 154 synchronization can also be a problem in the interval between the 155 beginning of the new stream and the first RTCP SR packet. This is 156 not different than what happen at the beginning of the RTP session 157 but it can be more annoying for the end-user. 159 2.2. Same SSRC 161 The simplest way of managing multiple clock rates is to use the same 162 SSRC for all the payload types regardless of the clock rates. 164 Unfortunately there is no clear definition on how the RTP timestamp 165 should be calculated in this case. The following subsections present 166 two variants. 168 2.2.1. Monotonic timestamps 170 The most common method of calculating the RTP timestamp ensures that 171 the value increases monotonically. The formula used by this method 172 is as follow: 174 timestamp = previous_timestamp + (current_capture_time - 175 previous_capture_time) * current_clock_rate 177 The problem with this method is that the jitter calculation on the 178 receiving side gives invalid result during the transition between two 179 clock rates, as shown in Table 2. The capture and arrival time are 180 in seconds, starting at the beginning of the capture of the first 181 packet; clock rate is in Hz; the RTP timestamp does not include the 182 random offset; the transit, jitter, and average jitter use the clock 183 rate as unit. 185 +-------+-------+-----------+---------+---------+--------+----------+ 186 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 187 | time | rate | timestamp | time | | | jitter | 188 +-------+-------+-----------+---------+---------+--------+----------+ 189 | 0 | 8000 | 0 | 0.1 | 800 | | | 190 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 191 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 192 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 193 | 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 | 194 | 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 | 195 | 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 | 196 | 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 | 197 | 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 | 198 +-------+-------+-----------+---------+---------+--------+----------+ 200 Table 2 202 Calculating the correct transit time on the receiving side can be 203 done by using the following formulas: 205 (1) current_time_capture = current_timestamp - previous_timestamp) / 206 current_clock_rate + previous_time_capture 207 (2) transit = current_clock_rate * (time_arrival - 208 current_time_capture) 209 (3) previous_time_capture = current_time_capture 211 The main problem with this method, in addition to the fact that the 212 jitter calculation described in RFC 3550 cannot be used, is that is 213 it dependent on the previous RTP packets, packets that can be 214 reordered or lost in the network. But it seems that this is what 215 most implementations are using. 217 2.2.2. Non-monotonic timestamps 219 An alternate way of generating the RTP timestamps is to use the 220 following formula: 222 timestamp = capture_time * clock_rate 224 With this formula, the jitter calculation is correct but the RTP 225 timestamp values are no longer increasing monotonically as shown in 226 Table 3. RFC 3550 states that "[t]he sampling instant MUST be 227 derived from a clock that increments monotonically[...]" but nowhere 228 says that the RTP timestamp must increment monotonically. 230 +-------+-------+-----------+---------+---------+--------+----------+ 231 | Capt. | Clock | RTP | Arrival | Transit | Jitter | Average | 232 | time | rate | timestamp | time | | | jitter | 233 +-------+-------+-----------+---------+---------+--------+----------+ 234 | 0 | 8000 | 0 | 0.1 | 800 | | | 235 | 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 | 236 | 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 | 237 | 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 | 238 | 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 | 239 | 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 | 240 | 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 | 241 | 0.14 | 16000 | 2240 | 0.24 | 1600 | 0 | 0 | 242 | 0.16 | 16000 | 2560 | 0.26 | 1600 | 0 | 0 | 243 | 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 | 244 | 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 | 245 +-------+-------+-----------+---------+---------+--------+----------+ 247 Table 3 249 The advantage with this method is that it works with the jitter 250 calculation described in RFC 3550, a long as the correct clock rates 251 are used. 253 3. Terminology 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 257 document are to be interpreted as described in [RFC2119]. 259 Clock rate: The multiplier used to convert from a wallclock value in 260 seconds to an equivalent RTP timestamp value (without the fixed 261 random offset). Note that RFC 3550 uses various terms like "clock 262 frequency", "media clock rate", "timestamp unit", "timestamp 263 frequency", and "RTP timestamp clock rate" as synonymous to clock 264 rate. 265 RTP Sender: A logical network element that sends RTP packets, sends 266 RTCP SR packets, and receives RTCP RR packets. 267 RTP Receiver: A logical network element that receives RTP packets, 268 receives RTCP SR packets, and sends RTCP RR packets. 270 4. RTP Sender 272 An RTP Sender with RTCP turned off (i.e. by setting the RS and RR 273 bandwidth modifiers defined in [RFC3556] to 0) SHOULD use a different 274 SSRC for each different clock rate but MAY use different clock rates 275 on the same SSRC as long as the RTP timestamp is calculated as 276 described in Section 2.2.2. 278 An RTP Sender with RTCP turned on MUST use a different SSRC for each 279 different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST 280 be used if the clock rate switches back to a value already seen in 281 the RTP stream. 283 To accelerate lip synchronization, the next compound RTCP packet sent 284 by the RTP sender MUST contain multiple SR packets, the first one 285 containing the mapping for the current clock rate and the next SR 286 packets containing the mapping for the other clock rates seen during 287 the last period. 289 The RTP extension defined in [RAPID-SYNC] MAY be used to accelerate 290 the synchronization. 292 5. RTP Receiver 294 An RTP Receiver MUST be able to handle clock rate changes either on 295 the same SSRC (Section 2.1) or on different SSRC (Section 2.2.2). 297 An RTP Receiver MUST be able to handle a compound RTCP packet with 298 multiple SR packets. 300 For interoperability with legacy RTP implementations, an RTP receiver 301 MAY use the information in two consecutive SR packets to calculate 302 the clock rate used, i.e. if Ni is the NTP timestamp for the SR 303 packet i, Ri the RTP timestamp for the SR packet i and Nj and Rj the 304 NTP timestamp and RTP timestamp for the previous SR packet j, then 305 the clock rate can be guessed as the closest to (Ri - Rj) / (Ni - 306 Nj). 308 6. Interoperability Analysis 310 The next subsections analyze the various combinations between legacy 311 RTP implementations and RTP implementations that follow this document 312 specifications. 314 6.1. Legacy RTP Sender using different SSRC sending to new RTP Receiver 316 Because a specific clock rate is associated to a specific SSRC, there 317 is no ambiguity in the RTP timestamp received in the RTP packet or SR 318 packet or in the jitter sent in the RR packet. 320 6.2. Legacy RTP Sender using same SSRC with monotonic timestamps 321 sending to new RTP Receiver 323 The new RTP Receiver will not be able to rebuild the correct RTP 324 timestamp so the jitter will be incorrect. Note that this is not 325 different than if a legacy RTP Receiver is used. 327 6.3. Legacy RTP Sender using same SSRC with non-monotonic timestamps 328 sending to new RTP Receiver 330 TBD 332 6.4. New RTP Sender using different SSRC sending to legacy RTP Receiver 334 Because a specific clock rate is associated to a specific SSRC, there 335 is no ambiguity in the RTP timestamp received in the RTP packet or SR 336 packet or in the jitter sent in the RR packet. Some legacy RTP 337 implementations may have problems when receiving multiple SR packets. 339 6.5. New RTP Sender using different SSRC sending to new RTP Receiver 341 Because a specific clock rate is associated to a specific SSRC, there 342 is no ambiguity in the RTP timestamp received in the RTP packet or SR 343 packet or in the jitter sent in the RR packet. 345 6.6. New RTP Sender using same SSRC with non-monotonic timestamps to 346 legacy RTP Receiver 348 Because this combination is used only when no RTCP packets are 349 exchanged, there is no problem interpreting the RTCP field units. 350 Some legacy RTP implementations may have problems if the jitter clock 351 rates are not correctly managed. 353 6.7. New RTP Sender using same SSRC with non-monotonic timestamps to 354 new RTP Receiver 356 Because this combination is used only when no RTCP packets are 357 exchanged, there is no problem interpreting the RTCP field units. 359 7. Security Considerations 361 TBD 363 8. IANA Considerations 365 No IANA considerations. 367 9. Acknowledgements 369 Thanks to Colin Perkins and Ali C. Begen for their comments, 370 suggestions and questions that helped to improve this document. 372 Thanks to Robert Sparks and the attendants of SIPit 26 for the survey 373 on multiple clock rates interoperability. 375 This document was written with the xml2rfc tool described in 376 [RFC2629]. 378 10. References 380 10.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 386 Jacobson, "RTP: A Transport Protocol for Real-Time 387 Applications", STD 64, RFC 3550, July 2003. 389 10.2. Informative References 391 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 392 June 1999. 394 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 395 Video Conferences with Minimal Control", STD 65, RFC 3551, 396 July 2003. 398 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 399 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 400 RFC 3556, July 2003. 402 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 403 Protocol Extended Reports (RTCP XR)", RFC 3611, 404 November 2003. 406 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 407 RTP Streams", RFC 5450, March 2009. 409 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 410 RFC 5484, March 2009. 412 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 413 Protocol (RTCP) Extensions for Single-Source Multicast 414 Sessions with Unicast Feedback", RFC 5760, February 2010. 416 [RAPID-SYNC] 417 Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 418 Flows", draft-ietf-avt-rapid-rtp-sync-12 (work in 419 progress), July 2010. 421 [uRTR] Wenger, S. and C. Perkins, "RTP Timestamp Frequency for 422 Variable Rate Audio Codecs", 423 draft-ietf-avt-variable-rate-audio-00 (work in progress), 424 October 2004. 426 Appendix A. Using a fixed clock rate 428 An alternate way of fixing the multiple clock rates issue was 429 proposed in [uRTR]. This document proposed to define a unified clock 430 rate, but the proposal was rejected at IETF 61. 432 Appendix B. Release notes 434 This section must be removed before publication as an RFC. 436 B.1. Modifications between -02 and -01 438 o Having multiple SRs in a compound RTCP packet is OK. 439 o If RTCP is used, must send a BYE and not reuse the SSRC. 440 o Removed resolved notes. 441 o Acknowledged SIPit 26 survey. 442 o Fixed some nits. 444 B.2. Modifications between -01 and -00 446 o Complete rewrite as a Standard Track I-D modifying RFC 3550. 448 Author's Address 450 Marc Petit-Huguenin 451 Unaffiliated 453 Email: petithug@acm.org