idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-synchronization-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 : ---------------------------------------------------------------------------- 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 date (February 1, 2013) is 4102 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 normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. 'TR-126' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Asaeda 3 Internet-Draft NICT 4 Intended status: Standards Track R. Huang 5 Expires: August 5, 2013 Q. Wu 6 Huawei 7 February 1, 2013 9 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for 10 Synchronization Delay and Offset Metrics Reporting 11 draft-ietf-xrblock-rtcp-xr-synchronization-02 13 Abstract 15 This document defines two RTP Control Protocol (RTCP) Extended Report 16 (XR) Blocks that allow the reporting of synchronization delay and 17 offset metrics for use in a range of RTP applications. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 5, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Synchronization Delay and Offset Metrics Reporting 55 Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 57 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 58 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 61 3. RTP Flows Initial Synchronization Delay Report Block . . . . . 5 62 3.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 5 63 3.2. Definition of Fields in RTP Flow Initial 64 Synchronization Delay Metrics Block . . . . . . . . . . . 5 65 4. RTP Flows Synchronization Offset Metrics Block . . . . . . . . 6 66 4.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 7 67 4.2. Definition of Fields in RTP Flow General 68 Synchronization Offset Metrics Block . . . . . . . . . . . 7 69 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 8 71 5.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 79 A.1. draft-ietf-xrblock-rtcp-xr-syncronization-02 . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 1.1. Synchronization Delay and Offset Metrics Reporting Blocks 86 This draft defines two new block types to augment those defined in 87 [RFC3611], for use in a range of RTP applications. 89 The first new block type supports reporting of Initial 90 Synchronization Delay to establish multimedia session. Information 91 is recorded about time difference between the start of RTP sessions 92 and the time the RTP receiver acquires all components of RTP sessions 93 in the multimedia session [RFC6051]. 95 The second new block type supports reporting of the relative 96 synchronization offset time of two arbitrary streams (e.g., between 97 audio and video streams), with the same RTCP CNAME included in RTCP 98 SDES packets [RFC3550]. Information is recorded about the 99 synchronization offset time of each RTP stream relative to the 100 reference RTP stream with the same CNAME and General Synchronization 101 Offset of zero. 103 These metrics belong to the class of transport level metrics defined 104 in [RFC6792]. 106 1.2. RTCP and RTCP XR Reports 108 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 109 defined an extensible structure for reporting using an RTCP Extended 110 Report (XR). This document defines a new Extended Report block for 111 use with [RFC3550] and [RFC3611]. 113 1.3. Performance Metrics Framework 115 The RTP Monitoring Architectures [RFC6792] provides guideline for 116 reporting block format using RTCP XR. The new report block described 117 in this memo is in compliance with the monitoring architecture 118 specified in [RFC6792]. 120 1.4. Applicability 122 When joining each session in layered video sessions [RFC6190] or the 123 multimedia session, a receiver may not synchronize playout across the 124 multimedia session or layered video session until RTCP SR packets 125 have been received on all components of RTP sessions. The component 126 RTP session are referred to as each RTP session for each media type 127 in multimedia session or separate RTP session for each layer in the 128 layered video session. For multicast session, the initial 129 synchronization delay metric varies with the session bandwidth, the 130 number of members, and the number of senders in the session. The RTP 131 flow Initial synchronization delay block defined in this document can 132 be used to report such metric, i.e., the initial synchronization 133 delay to receive all the RTP streams belonging to the same multimedia 134 session or layered video session. In the absence of packet loss, the 135 initial synchronization delay equals to the average time taken to 136 receive the first RTCP packet in the RTP session with the longest 137 RTCP reporting interval. In the presence of packet loss, the media 138 synchronization should rely on the in-band mapping of RTP and NTP- 139 format timestamps [RFC6051] or wait until the reporting interval has 140 passed, and the next RTCP SR packet is sent. 142 Receivers of the RTP flow initial synchronization delay block could 143 use this metric to compare with targets (i.e., Service Level 144 Agreement or thresholds of the system) to help ensure the quality of 145 real-time application performance. 147 In an RTP multimedia session, there can be an arbitrary number of 148 streams carried in different RTP sessions, with the same RTCP CNAME. 149 These streams may be not synchronized with each other. For example, 150 one audio stream and one video stream belong to the same session, and 151 the audio stream is transmitted lagging behind video stream for 152 multiple tens of milliseconds [TR-126]. The RTP Flows 153 Synchronization Offset block can be used to report such 154 synchronization offset between video stream and audio stream. The 155 metrics defined in the RTP flows synchronization Offset block can be 156 used by network manager for trouble shooting and dealing with user 157 experience issues. 159 2. Terminology 161 2.1. Standards Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 In addition, the following terms are defined: 169 Initial Synchronization Delay: 171 A multimedia session comprises a set of concurrent RTP sessions 172 among a common group of participants, using one RTP session for 173 each media type. The initial synchronization Delay is the average 174 time for receiver to synchronize all components of a multimedia 175 session [RFC6051]. 177 Synchronization Offset: 179 Synchronization between two media streams must be maintained to 180 ensure satisfactory QoE. Two media streams can be of the same 181 media type belonging to one RTP session or in different media 182 types belonging to one multimedia session. The Synchronization 183 Offset is the relative time difference of the two media streams 184 that need to be synchronized. 186 3. RTP Flows Initial Synchronization Delay Report Block 188 This block is sent by RTP receivers and reports Initial 189 synchronization delay beyond the information carried in the standard 190 RTCP packet format. Information is recorded about time difference 191 between the start of multimedia session and the time when the RTP 192 receiver acquires all components of RTP sessions [RFC6051]. 194 3.1. Metric Block Structure 196 The RTP Flows Initial Synchronization Delay Report Block has the 197 following format: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | BT=RFISD | Reserved | Block length=2 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | SSRC of Source | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Initial Synchronization Delay | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 3.2. Definition of Fields in RTP Flow Initial Synchronization Delay 210 Metrics Block 212 Block type (BT): 8 bits 214 The RTP Flows Initial Synchronization Delay Report Block is 215 identified by the constant . 217 Reserved: 8 bits 219 This field is reserved for future definition. In the absence of 220 such a definition, the bits in this field MUST be set to zero and 221 MUST be ignored by the receiver. 223 Block length: 16 bits 225 The constant 2, in accordance with the definition of this field in 226 Section 3 of RFC 3611 [RFC3611]. 228 SSRC of source: 32 bits 230 The SSRC of the media source SHALL be set to the value of the SSRC 231 identifier carried in any arbitrary component of RTP sessions 232 belonging to the same multimedia session. 234 Initial Synchronization Delay: 32 bits 236 The average delay, expressed in units of 1/65536 seconds, from the 237 beginning of multimedia session [RFC6051] to the time when RTCP 238 packets are received on all of the components RTP sessions. It is 239 recommended that the beginning of multimedia session is chosen as 240 the time when the receiver has joined the first RTP session of the 241 multimedia session. The value of the initial synchronization 242 delay is calculated based on received RTCP SR packets or the RTP 243 header extension containing in-band mapping of RTP and NTP-format 244 timestamps [RFC6051]. If there is no packet loss, the initial 245 synchronization delay is expected to be equal to the average time 246 taken to receive the first RTCP packet in the RTP session with the 247 longest RTCP reporting interval or the average time taken to 248 receive the first RTP header extension containing in-band mapping 249 of RTP and NTP- format timestamps. 251 If the measurement is unavailable, the value of this field with 252 all bits set to 1 MUST be reported. 254 4. RTP Flows Synchronization Offset Metrics Block 256 In the RTP multimedia sessions, there can be an arbitrary number of 257 Media streams and each media stream (e.g., audio stream or video 258 stream) is sent in a separate RTP stream. The receiver associates 259 RTP streams to be synchronized by means of RTCP CNAME contained in 260 the RTCP Source Description (SDES) packets [RFC3550]. 262 This block is sent by RTP receivers and reports synchronization 263 offset of the arbitrary two RTP streams that needs to be synchronized 264 in the RTP multimedia session. Information is recorded about the 265 relative average time difference between the reporting stream and the 266 reference stream with the same CNAME. For multimedia session with 267 multiple media types (e.g., audio and video), it is recommended to 268 choose the stream with the lower bandwidth as the reference stream. 269 For layered video sessions, it is recommended to use the base layer 270 stream as the reference stream. 272 4.1. Metric Block Structure 274 The RTP Flow General Synchronization Offset Report Block has the 275 following format: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | BT=RFSO | Reserved | Block length=4 | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | SSRC of source | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | SSRC of reference | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Synchronization Offset, most significant word | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Synchronization Offset, least significant word | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 4.2. Definition of Fields in RTP Flow General Synchronization Offset 292 Metrics Block 294 Block type (BT): 8 bits 296 The RTP Flow General Synchronization Offset Report Block is 297 identified by the constant . 299 Reserved: 8 bits 301 This field is reserved for future definition. In the absence of 302 such a definition, the bits in this field MUST be set to zero and 303 MUST be ignored by the receiver. 305 Block length: 16 bits 307 The constant 4, in accordance with the definition of this field in 308 Section 3 of RFC 3611 [RFC3611]. 310 SSRC of Source: 32 bits 312 The SSRC of the media source SHALL be set to the value of the SSRC 313 identifier of the reporting RTP stream to which the XR relates. 315 SSRC of Reference: 32 bits 317 The SSRC of the reference stream SHALL be set to the value of the 318 SSRC identifier of the reference RTP stream to which the XR 319 relates. 321 Synchronization Offset: 64 bits 323 The synchronization offset of the reporting RTP stream relative to 324 the reference RTP stream with the same CNAME. The calculation of 325 Synchronization Offset is similar to Difference D calculation in 326 the RFC3550. That is to say, if Si is the NTP timestamp from the 327 reporting RTP packet i, and Ri is the time of arrival in NTP 328 timestamp units for reporting RTP packet i, Sj is the NTP 329 timestamp from the reference RTP packet j, and Rj is the time of 330 arrival in NTP timestamp units for reference RTP packet j, then 331 the value of the synchronization offset D may be expressed as 333 D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) 335 If in-band delivery of NTP-format timestamps is supported 336 [RFC6051], Si and Sj should be obtained directly from the RTP 337 packets where NTP timestamps are available. If not, Si and Sj 338 should be calculated from their corresponding RTP timestamps. The 339 value of the synchronization offset is represented using a 64- bit 340 signed NTP-format timestamp as defined in [RFC5905], which is 64- 341 bit signed fixed-point number with the integer part in the first 342 32 bits and the fractional part in the last 32 bits. A positive 343 value of the synchronization offset means that the reporting 344 stream leads before the reference stream, while a negative value 345 means that the reporting stream lags behind the reference stream. 347 If the measurement is unavailable, the value of this field with 348 all bits set to 1 MUST be reported. 350 5. SDP Signaling 352 [RFC3611] defines the use of SDP (Session Description Protocol) 353 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 354 without prior signaling. 356 5.1. SDP rtcp-xr-attrib Attribute Extension 358 Two new parameters are defined for the two report blocks defined in 359 this document to be used with Session Description Protocol (SDP) 360 [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 361 They have the following syntax within the "rtcp-xr" attribute 363 [RFC3611]: 365 xr-format = xr-rfisd-block 366 / xr-rfso-block 368 xr-rfisd-block = " init-syn-delay" 369 xr-rfso-block = " syn-offset" 371 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 372 and the full syntax of the "rtcp-xr" attribute. 374 5.2. Offer/Answer Usage 376 When SDP is used in offer-answer context, the SDP Offer/Answer usage 377 defined in [RFC3611] applies. 379 6. IANA Considerations 381 New report block types for RTCP XR are subject to IANA registration. 382 For general guidelines on IANA allocations for RTCP XR, refer to 383 Section 6.2 of [RFC3611]. 385 This document assigns two new block type values in the RTCP XR Block 386 Type Registry: 388 Name: RFISD 389 Long Name: RTP Flows Initial Synchronization Delay 390 Value 391 Reference: Section 3 393 Name: RFSO 394 Long Name: RTP Flows Synchronization Offset Metrics Block 395 Value 396 Reference: Section 4 398 This document also registers two new SDP [RFC4566] parameters for the 399 "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 401 * "xr-rfisd " 402 * "xr-rfso" 404 The contact information for the registrations is: 406 Qin Wu 407 sunseawq@huawei.com 408 101 Software Avenue, Yuhua District 409 Nanjing, Jiangsu 210012, China 411 7. Security Considerations 413 The new RTCP XR report blocks proposed in this document introduces no 414 new security considerations beyond those described in [RFC3611]. 416 8. Acknowledgements 418 The authors would like to thank Bill Ver Steeg, David R Oran, Ali 419 Begen, Colin Perkins, Roni Even, Kevin Gross, Jing Zhao, Fernando 420 Boronat Segui, Mario Montagud Climent, Youqing Yang, Wenxiao Yu and 421 Yinliang Hu for their valuable comments and suggestions on this 422 document. 424 9. References 426 9.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 432 Jacobson, "RTP: A Transport Protocol for Real-Time 433 Applications", STD 64, RFC 3550, July 2003. 435 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 436 Protocol Extended Reports (RTCP XR)", RFC 3611, 437 November 2003. 439 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 440 Description Protocol", RFC 4566, July 2006. 442 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 443 Specifications: ABNF", STD 68, RFC 5234, January 2008. 445 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 446 Time Protocol Version 4: Protocol and Algorithms 447 Specification", RFC 5905, June 2010. 449 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 450 Flows", RFC 6051, November 2010. 452 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 453 "RTP Payload Format for Scalable Video Coding", RFC 6190, 454 May 2011. 456 [TR-126] BBF Forum, "Triple-play Services Quality of Experience 457 (QoE) Requirements", December 2006. 459 9.2. Informative References 461 [RFC6792] Wu, Q., "Guidelines for Use of the RTP Monitoring 462 Framework", RFC 6792, November 2012. 464 [Y.1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and 465 availability performance parameters", November 2007. 467 Appendix A. Change Log 469 Note to the RFC-Editor: please remove this section prior to 470 publication as an RFC. 472 A.1. draft-ietf-xrblock-rtcp-xr-syncronization-02 474 The following are the major changes compared to previous version: 476 Editorial change based on comments raised on the list and in the 477 IETF85 meeting 479 Authors' Addresses 481 Hitoshi Asaeda 482 National Institute of Information and Communications Technology 483 4-2-1 Nukui-Kitamachi 484 Koganei, Tokyo 184-8795 485 Japan 487 Email: asaeda@nict.go.jp 489 Rachel Huang 490 Huawei Technologies Co., Ltd. 491 101 Software Avenue, Yuhua District 492 Nanjing, Jiangsu 210012 493 China 495 Email: Rachel@huawei.com 496 Qin Wu 497 Huawei Technologies Co., Ltd. 498 101 Software Avenue, Yuhua District 499 Nanjing, Jiangsu 210012 500 China 502 Email: sunseawq@huawei.com