idnits 2.17.1 draft-ietf-avt-rtp-toffset-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 381. 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 Copyright Line does not match the current year -- 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 (March 11, 2008) is 5883 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT D. Singer 3 Internet-Draft Apple Computer Inc. 4 Intended status: Standards Track H. Desineni 5 Expires: September 12, 2008 Qualcomm 6 March 11, 2008 8 Transmission Time offsets in RTP streams 9 draft-ietf-avt-rtp-toffset-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 12, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes a method to inform RTP clients when RTP 43 packets are transmitted at a time other than their 'nominal' 44 transmission time. It also provides a mechanism to provide improved 45 inter-arrival jitter reports from the clients, that take into account 46 the reported transmission times. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 52 3. Transmission offset . . . . . . . . . . . . . . . . . . . . . 5 53 4. Extended Jitter Reports . . . . . . . . . . . . . . . . . . . 8 54 5. Signaling (setup) information . . . . . . . . . . . . . . . . 9 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 57 8. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 12 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 59 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 61 Intellectual Property and Copyright Statements . . . . . . . . . . 16 63 1. Introduction 65 In the RTP specification [RFC3550] network jitter calculations are 66 based on the presumption that packets are transmitted essentially in 67 accordance with their RTP timestamps. This must be true, of course, 68 on average over longer time intervals, as the client is playing the 69 packets out according to those timestamps. However, for individual 70 packets, this may under some circumstances not be true: 72 o When the data rate of the stream is bursty, such as with video 73 where I-frames may be significantly larger than P or B frames, 74 traffic smoothing may need to be applied to maintain an 75 appropriate data rate. 77 o In video which has forward decode dependencies, frames may need to 78 be transmitted in decoding order (the sequence number order) but 79 with, of course, presentation timestamps. Under these 80 circumstances the transmission time of a frame sent early in 81 sequence does not correspond to its RTP timestamp. 83 o When re-transmissions are sent, the re-transmitted packet clearly 84 has a different actual transmission time from the original, even 85 though they share the same timestamp. 87 Under some circumstances it can help the receiver, or intermediate 88 network elements, to know the actual transmission time of the packet. 89 This RTP header extension element allows the communication of this 90 information. 92 The RTP specification does not define a transmission timestamp, and 93 nor does this specification. This specification merely provides 94 information on the relationship between the relative transmission 95 times and relative RTP timestamps. 97 This specification allows the transmitter to indicate to the receiver 98 any known variation between the spacing of transmission times and the 99 spacing of RTP timestamps; any unreported variation introduced at or 100 after the point of measurement of the transmission time will be 101 treated as network jitter by the receiver. The definition of the 102 point where the transmission time is measured or defined is left to 103 the transmitter, though it should, of course, be consistent from 104 packet to packet. 106 This information can also be of use to report the inter-arrival 107 jitter caused by the network, excluding that introduced by the 108 source. A new RTCP packet is defined to enable this reporting. 110 2. Requirements notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Transmission offset 118 Classically a pair of RTP packets with timestamps S2 and S1 are 119 transmitted with a time interval between them of (S2 - S1). This 120 specification permits sending an offset value O in each packet, O1 121 and O2. One characteristic of these offsets is that the original 122 transmission interval can be deduced to be (S2 + O2) - (S1 + O1). 124 More precisely, the offset is defined as follows (with the function 125 RtoN converting from RTP to NTP times, and NtoR doing the reverse): 127 o Take an RTP stream that has a recent RTCP sender report relating 128 RTP timestamp S0 to NTP timestamp N0; 130 o consider a packet sent after that with RTP timestamp S1. 131 Nominally this is sent at N1 = (N0 + RtoN(S1 - S0)); 133 o If it was actually sent at a different time, Na, then the offset 134 value O1 is O1 = NtoR(Na - N1). 136 The transmission time is signalled to the receiver in-band using The 137 IETF Generic RTP header extension [hdrext]. The payload of this 138 extension (the transmitted value) is a 24-bit signed integer. When 139 added to the RTP timestamp of the packet, it represents the 140 "effective" RTP transmission time of the packet, on the RTP 141 timescale. The reported transmission time T1 of a packet with 142 timestamp S1 and an offset of O1, from the above equations, is T1 = 143 S1+O1 (though of course the transmission time values only have 144 meaning when two or more are compared). 146 The form of the transmission offset extension block is as follows: 148 0 1 2 3 149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | ID | len=2 | transmission offset | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 The length field takes the value 2 to indicate that 3 bytes follow. 156 The sign of the offset value depends greatly on the choice of the 157 initial mapping of RTP to NTP times. In general, without scanning a 158 stream entirely it is not possible to ensure that this mapping would 159 keep all the offsets positive; therefore this specification allows 160 negative values. 162 Imagine a stream with the following timestamps and sizes in bytes: 164 200 2kb 165 300 4kb 166 400 2kb 167 500 12kb 168 600 ...effective end of stream 170 This has 20KB spread over 400 time units, i.e. on average 1 kb per 20 171 time-units. We traffic-smooth this, and establish that given a 172 transmission time of x for the first packet, we would transmit the 173 following packets at the given intervals later: 175 x + 000 2kb 176 x + 040 4kb 177 x + 120 2kb 178 x + 160 12kb 179 x + 400 ...effective end of stream 181 The choice of x is esssentially arbitrary: only relative values of 182 timestamps matter. Now, let's say I claim on the first packet that 183 it went out *at* its RTP timestamp, i.e. with an offset of 0, i.e. x 184 is 200. Then the offset values are 186 0 187 -60 188 -80 189 -140 191 This is because in this case, I traffic-smooth this because 192 conceptually I think of sending the small packets 'early'. But since 193 only the relative values are significant, it is just as valid to say 194 x is 400, whereupon the offset values are 196 200 197 140 198 120 199 60 201 In a stream where this extension is not in effect (i.e. not declared 202 or negotiated), the actual transmission offset is therefore unknown. 203 However, when the extension is in effect for the stream, it MAY be 204 omitted in those packets for which the offset is 0 (zero); that is, 205 packets sent at their nominal time do not need this extension 206 tagging. Therefore the implied transmission time of an un-tagged RTP 207 packet depends on whether the extension is in effect for the stream 208 (and therefore the transmission offset is 0) or not (whereupon the 209 transmission offset is unknown). 211 The jitter calculations performed by an RTP client MUST NOT use these 212 transmission offsets. In general, the sender (or intermediate 213 network elements doing RTP analysis) cannot always know whether the 214 offsets have been taken into account or not, and for consistency 215 therefore, the jitter calculation should continue to operate on the 216 'raw' reception times. However, see the section on extended jitter 217 reports, below. 219 There are no extension attributes defined for this extension. 221 It is structurally possible to have more than one extension of the 222 same type in a packet. However, this extension is only defined for 223 the source to report, and intermediate network nodes that are not the 224 source of the RTP session MUST NOT add this extension (whether or not 225 it was previously present) and MUST NOT alter the existing 226 transmission offset value in a packet, if the extension is already 227 present. 229 (Of course, it is clear that network elements that terminate an RTP 230 flow, and are the source for a new RTP flow, can add a transmission 231 offset extension header to the RTP packets of the new flow, if 232 desired.) 234 4. Extended Jitter Reports 236 The inter arrival jitter computed as defined in Sec 6.4.1 of RFC3550 237 provides inter-arrival jitter reports which include any source- 238 introduced jitter (transmission time offsets). If it is desired to 239 indicate the actual network jitter, excluding the source-introduced 240 jitter, the new RTCP packet type defined here may be used. 242 It has the following form: 244 0 1 2 3 245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 hdr |V=2|P| RC | PT=IJ=195 | length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | interarrival jitter | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 . . 252 . . 253 . . 254 | interarrival jitter | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 If present, this RTCP packet must be placed after a receiver report 258 (inside a compound RTCP packet), and MUST have the same value for RC 259 as the receiver report. The content is exactly that number of 260 interarrival jitter calculations, calculated using the same formula 261 as for sender and receiver reports, but taking into account the 262 transmission offsets for the streams (if any); that is, using the 263 values T1=S1+O1, T2 etc. as defined above, instead of S1, S2 etc.. 264 (If no transmission offset information is given for a stream, then 265 the value of interarrival jitter in this packet and in the receiver 266 report will be identical). 268 Precisely, the replacement equation for the equation in the RTP 269 specification is, where Rj is the most recent arrival time: 271 D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi)) 272 = (Rj - (Sj + Oj)) - (Ri - (Si + Oi)) 274 5. Signaling (setup) information 276 The URI for declaring this header extension in an extmap attribute is 277 "urn:ietf:params:rtp-hdrext:toffset". There is no additional setup 278 information needed for this extension (no extensionattributes). 280 6. Security Considerations 282 The given transmission offsets are only informative and it is hard to 283 see security considerations from associating them with media streams. 285 7. IANA Considerations 287 The RTCP packet type used for the adjusted interarrival jitter needs 288 to be registered, in accordance with section 15 of [RFC3550]. The 289 abbreviation is "IJ", the full name is "Extended inter-arrival jitter 290 report", the suggested value is 195, and the specification is this 291 document. 293 The name toffset needs to be registered into the rtp-hdrext section 294 of the urn:ietf: namespace, referring to RFCxxxx. 296 8. RFC Editor Considerations 298 The reference to an Internet Draft needs to be updated to the RFC 299 when it is published (which should be before this draft). 301 RFCxxxx in the IANA considerations needs to be updated with the 302 number of this RFC. 304 9. Acknowledgments 306 Ron Frederick, Colin Perkins, and Steve Casner all contributed 307 substantially to this document, and their help and contributions 308 helped turn an idea into a specification. 310 10. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 316 Jacobson, "RTP: A Transport Protocol for Real-Time 317 Applications", RFC 3550, STD 0064, July 2003. 319 [hdrext] Singer, D., "A general mechanism for RTP Header 320 Extensions", ID draft-ietf-avt-rtp-hdrext-08, 321 October 2006. 323 Authors' Addresses 325 David Singer 326 Apple Computer Inc. 327 1 Infinite Loop 328 Cupertino, CA 95014 329 US 331 Phone: +1 408 996 1010 332 Email: singer@apple.com 334 Harikishan Desineni 335 Qualcomm 336 5775 Morehouse Drive 337 San Diego, CA 92121 338 US 340 Phone: +1 858 845 8996 341 Email: hd@qualcomm.com 343 Full Copyright Statement 345 Copyright (C) The IETF Trust (2008). 347 This document is subject to the rights, licenses and restrictions 348 contained in BCP 78, and except as set forth therein, the authors 349 retain all their rights. 351 This document and the information contained herein are provided on an 352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 359 Intellectual Property 361 The IETF takes no position regarding the validity or scope of any 362 Intellectual Property Rights or other rights that might be claimed to 363 pertain to the implementation or use of the technology described in 364 this document or the extent to which any license under such rights 365 might or might not be available; nor does it represent that it has 366 made any independent effort to identify any such rights. Information 367 on the procedures with respect to rights in RFC documents can be 368 found in BCP 78 and BCP 79. 370 Copies of IPR disclosures made to the IETF Secretariat and any 371 assurances of licenses to be made available, or the result of an 372 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 374 specification can be obtained from the IETF on-line IPR repository at 375 http://www.ietf.org/ipr. 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights that may cover technology that may be required to implement 380 this standard. Please address the information to the IETF at 381 ietf-ipr@ietf.org. 383 Acknowledgment 385 Funding for the RFC Editor function is provided by the IETF 386 Administrative Support Activity (IASA).