idnits 2.17.1 draft-petithuguenin-avt-multiple-clock-rates-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 30, 2009) is 5315 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-05 == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-18 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 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 Intended status: Standards Track September 30, 2009 5 Expires: April 3, 2010 7 Support for multiple clock rates in an RTP session 8 draft-petithuguenin-avt-multiple-clock-rates-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 3, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The usage of multiple clock rates in an RTP session is currently 47 underspecified. This document lists multiple ways to fix this 48 problem and is meant as a support for discussion. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. RTP Sender behavior . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Use the current clock rate . . . . . . . . . . . . . . . . 4 56 3.2. Use a fixed clock rate . . . . . . . . . . . . . . . . . . 4 57 3.3. Use a different SSRC . . . . . . . . . . . . . . . . . . . 5 58 3.4. Preferred RTP Sender behavior . . . . . . . . . . . . . . . 5 59 4. Receiver Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Use the current RTP clock rate . . . . . . . . . . . . . . 5 61 4.2. Guessing the clock rate . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 7 69 A.1. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 7 70 A.2. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The clock rate is a parameter of the payload format. It is often 76 defined as been the same as the sampling rate, but it is not always 77 the case (see e.g. the G722 and MPA audio codecs in [RFC3551]). 79 An RTP sender can switch between different payloads during the 80 lifetime of an RTP session and because clock rates are defined by 81 payload types, it is possible that the clock rate also varies during 82 an RTP session. 84 Changing the clock rate during an RTP session is not a problem for 85 the RTP receiver, as it always knows the clock rate associated with a 86 specific RTP packet. The RTP receiver also has no problem 87 calculating a clock rate independent interarrival jitter. 89 The problem is with reports carried in RTCP packets that contain 90 fields using units based on the clock rate. Because the RTCP packets 91 do not contain a field for the payload type, it is difficult for a 92 sender to choose or for a receiver to guess which clock rate to use 93 for this fields. 95 For example, lip synchronization can be incorrect if the RTP 96 timestamp in the RTCP SR packet use a different clock rate than 97 expected by the receiver. 99 Table 1 contains a non-exhaustive list of fields in RTCP packets that 100 use a clock rate: 102 +---------------------+------------------+------------------------+ 103 | Field name | RTCP packet type | Reference | 104 +---------------------+------------------+------------------------+ 105 | RTP timestamp | SR | [RFC3550] | 106 | Interarrival jitter | RR | [RFC3550] | 107 | min_jitter | XR Summary Block | [RFC3611] | 108 | max_jitter | XR Summary Block | [RFC3611] | 109 | mean_jitter | XR Summary Block | [RFC3611] | 110 | dev_jitter | XR Summary Block | [RFC3611] | 111 | Interarrival jitter | IJ | [RFC5450] | 112 | RTP timestamp | SMPTETC | [RFC5484] | 113 | Jitter | RSI Jitter Block | [I-D.ietf-avt-rtcpssm] | 114 | Median jitter | RSI Stats Block | [I-D.ietf-avt-rtcpssm] | 115 +---------------------+------------------+------------------------+ 117 Table 1 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 Clock rate: The multiplier used to convert from a wallclock value in 126 seconds to an equivalent RTP timestamp value (without the fixed 127 random offset). Note that [RFC3550] uses various terms like 128 "clock frequency", "media clock rate", "timestamp unit", 129 "timestamp frequency" and "RTP timestamp clock rate" as synonymous 130 to clock rate. 131 RTP Sender: A logical network element that sends RTP packets and 132 sends and receives RTCP packets. 133 RTP Receiver: A logical network element that receives RTP packets 134 and sends and receives RTCP packets. 136 3. RTP Sender behavior 138 An RTP sender can choose to implement a change in clock rate in 139 various ways. 141 3.1. Use the current clock rate 143 A RTP sender can switch between payload types set with different 144 clock rates on the same SSRC. The RTP sender uses the current clock 145 rate as the unit for the fields in the RTCP packets sent. 147 Pros: 148 * It is probably the simplest behavior to implement and various 149 implementations already follow this behavior. 150 Cons: 151 * This behavior seems to contradict [RFC3550] section 5.2. 152 * It is difficult for an RTCP receiver to guess the clock rate 153 used in the RTCP packets. 155 3.2. Use a fixed clock rate 157 As in the previous section, the RTP sender switches between different 158 clock rates on the same SSRC, but it always uses the same clock rate 159 as the unit for the fields in the RTCP packets sent. 161 There is different possible ways to choose this fixed clock rate: 162 o The first clock rate used on the RTP session. 163 o The highest clock rate that can be used on the RTP session. 165 o A unified clok rate, as defined in uRTR 166 [I-D.ietf-avt-variable-rate-audio]. 168 Pros: 169 * It is simple to implement. 170 Cons: 171 * There is obvious compatibility issues with implementations 172 using a different behavior. 173 * The fixed clock rate must be an integer multiple of the 174 possible clock rates. 175 * uRTR was rejected at IETF 61. 177 3.3. Use a different SSRC 179 Instead of using various clock rates in the same SSRC, an RTP sender 180 can use a different SSRC for each clock rate. 182 Pros: 183 * It is compliant with [RFC3550] section 5.2. 184 * As there can be be only one possible clock rate on a specific 185 SSRC, there is no ambiguity in the clock rate used in the RTCP 186 packets. 187 Cons: 188 * Changing the SSRC can be a problem for some implementations 189 designed to work only with unicast IP addresses, where having 190 multiple SSRCs is considered a corner case. 191 * Lip synchronization can be a problem in the interval between 192 the beginning of the new stream and the first RTCP SR packet. 193 This is not different than what happen at the beginning of the 194 RTP session but it can be more annoying for the end-user. The 195 RTP extension defined in [I-D.ietf-avt-rapid-rtp-sync] can be 196 used to accelerate the synchronization. 198 3.4. Preferred RTP Sender behavior 200 TBD 202 4. Receiver Behavior 204 4.1. Use the current RTP clock rate 206 An RTP Receiver can use the clock rate associated with the current 207 payload received in the RTP packets. There is a race condition 208 between the RTP and the RTCP packets that can create transient 209 problems. Also this method does not work for an RTCP monitor (i.e. 210 an RTCP receiver that does not receive the RTP packets). This method 211 will not work either if a fixed clock rate is used. 213 4.2. Guessing the clock rate 215 Instead of using the current RTP clock rate, an RTP receiver can use 216 the information in two consecutive SR packets to calculate the clock 217 rate used, i.e. if Ni is the NTP timestamp for the SR packet i, Ri 218 the RTP timestamp for the SR packet i and Nj and Rj the NTP timestamp 219 and RTP timestamp for the previous SR packet j, then the clock rate 220 can be guessed as the closest to (Ri - Rj) / (Ni - Nj). 222 5. Security Considerations 224 TBD 226 6. IANA Considerations 228 TBD 230 7. Acknowledgements 232 This document was written with the xml2rfc tool described in 233 [RFC2629]. 235 8. References 237 8.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 243 Jacobson, "RTP: A Transport Protocol for Real-Time 244 Applications", STD 64, RFC 3550, July 2003. 246 8.2. Informative References 248 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 249 June 1999. 251 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 252 Video Conferences with Minimal Control", STD 65, RFC 3551, 253 July 2003. 255 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 256 Protocol Extended Reports (RTCP XR)", RFC 3611, 257 November 2003. 259 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 260 RTP Streams", RFC 5450, March 2009. 262 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 263 RFC 5484, March 2009. 265 [I-D.ietf-avt-rapid-rtp-sync] 266 Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 267 Flows", draft-ietf-avt-rapid-rtp-sync-05 (work in 268 progress), July 2009. 270 [I-D.ietf-avt-rtcpssm] 271 Schooler, E., Ott, J., and J. Chesterfield, "RTCP 272 Extensions for Single-Source Multicast Sessions with 273 Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in 274 progress), March 2009. 276 [I-D.ietf-avt-variable-rate-audio] 277 Wenger, S. and C. Perkins, "RTP Timestamp Frequency for 278 Variable Rate Audio Codecs", 279 draft-ietf-avt-variable-rate-audio-00 (work in progress), 280 October 2004. 282 Appendix A. Release notes 284 This section must be removed before publication as an RFC. 286 A.1. Design Notes 288 (Empty) 290 A.2. TODO List 292 o Is it possible to guess the clock rate used in consecutive jitter 293 values? 295 Author's Address 297 Marc Petit-Huguenin 298 (Unaffiliated) 300 Email: petithug@acm.org