idnits 2.17.1 draft-asaeda-xrblock-rtcp-xr-synchronization-07.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 (July 16, 2012) is 4299 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) == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-13 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Asaeda 3 Internet-Draft Keio University 4 Intended status: Standards Track R. Huang 5 Expires: January 17, 2013 Q. Wu 6 Huawei 7 July 16, 2012 9 RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting 10 draft-asaeda-xrblock-rtcp-xr-synchronization-07 12 Abstract 14 This document defines two RTCP XR Report Blocks and associated with 15 SDP parameters that allow the reporting of synchronization delay and 16 offset metrics for use in a range of RTP applications. 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 17, 2013. 35 Copyright Notice 37 Copyright (c) 2012 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. RTP Flows Initial Synchronization Delay Report Block . . . . . 4 57 4.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 5 58 4.2. Definition of Fields in RTP Flow Initial 59 Synchronization Delay Metrics Block . . . . . . . . . . . 5 60 5. RTP Flows Synchronization Offset Metrics Block . . . . . . . . 6 61 5.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 6 62 5.2. Definition of Fields in RTP Flow General 63 Synchronization Offset Metrics Block . . . . . . . . . . . 6 64 6. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 72 A.1. draft-asaeda-xrblock-rtcp-xr-syncronization-07 . . . . . . 9 73 A.2. draft-asaeda-xrblock-rtcp-xr-syncronization-06 . . . . . . 10 74 A.3. draft-asaeda-xrblock-rtcp-xr-syncronization-05 . . . . . . 10 75 A.4. draft-asaeda-xrblock-rtcp-xr-syncronization-04 . . . . . . 10 76 A.5. draft-asaeda-xrblock-rtcp-xr-syncronization-03 . . . . . . 10 77 A.6. draft-asaeda-xrblock-rtcp-xr-syncronization-02 . . . . . . 10 78 A.7. draft-asaeda-xrblock-rtcp-xr-syncronization-01 . . . . . . 10 79 A.8. draft-asaeda-xrblock-rtcp-xr-syncronization-00 . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 This draft defines two new block types to augment those defined in 85 [RFC3611], for use in a range of RTP applications. 87 The first new block type supports reporting of Initial 88 Synchronization Delay to establish multimedia session. Information 89 is recorded about time difference between the start of RTP sessions 90 and the time the RTP receiver acquires all components of RTP sessions 91 in the multimedia session [RFC6051]. 93 The second new block type supports reporting of the relative 94 synchronization offset time of two arbitrary streams (e.g., between 95 audio and video streams), with the same RTCP CNAME included in RTCP 96 SDES packets [RFC3550]. Information is recorded about the 97 synchronization offset time of each RTP stream relative to the 98 reference RTP stream with the same CNAME and General Synchronization 99 Offset of zero. 101 These metrics belong to the class of terminal related transport level 102 metrics defined in [MONARCH]. 104 2. Terminology 106 2.1. Standards Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 In addition, the following terms are defined: 114 Initial Synchronization Delay: 116 A multimedia session comprises a set of concurrent RTP sessions 117 among a common group of participants, using one RTP session for 118 each media type. Initial synchronization Delay is the average 119 time for receiver to synchronize the components of a multimedia 120 session [RFC6051]. 122 Synchronization Offset: 124 The absolute delay variance of the measured RTP stream relative to 125 the reference RTP stream in the multimedia session. 127 3. Applicability 129 The report blocks defined in this document could be used by dedicated 130 network monitoring applications. 132 When joining each session in layered video sessions [RFC6190] or the 133 multimedia session, a receiver may not synchronize playout across the 134 multimedia session or layered video session until RTCP SR packets 135 have been received on all of the component RTP sessions. The 136 component RTP session are referred to as each RTP session for each 137 media type in multimedia session or separate RTP session for each 138 layer in the layered video session. For unicast session, the delay 139 due to negotiation of NAT pinholes, firewall holes, quality-of- 140 service, and media security keys is contributed to such initial 141 synchronization playout. For multicast session, such initial 142 synchronization delay varies with the session bandwidth, the number 143 of members, and the number of senders in the session. The RTP flow 144 Initial synchronization delay block can be used to report the initial 145 synchronization delay to receive all the RTP streams belonging to the 146 same multimedia session or layered video session. In the absence of 147 packet loss, the initial synchronization delay equals to the average 148 time taken to receive the first RTCP packet in the RTP session with 149 the longest RTCP reporting interval. In the presence of packet loss, 150 the media synchronization needs to based on the in-band mapping of 151 RTP and NTP-format timestamps [RFC6051] or wait until the reporting 152 interval has passed, and the next RTCP SR packet is sent. 154 In an RTP multimedia session, there can be an arbitrary number of 155 streams carried in different RTP sessions, with the same RTCP CNAME. 156 These streams may be not synchronized with each other. For example, 157 one audio stream and one video stream belong to the same session and 158 audio stream are transmitted lag behind video stream for multiple 159 tens of milliseconds. The RTP Flows Synchronization Offset block can 160 be used to report such synchronization offset between video stream 161 and audio stream. 163 4. RTP Flows Initial Synchronization Delay Report Block 165 This block is sent by RTP receivers and reports Initial 166 synchronization delay beyond the information carried in the standard 167 RTCP packet format. Information is recorded about time difference 168 between the start of RTP sessions and the time the RTP receiver 169 acquires all components of RTP sessions [RFC6051]. 171 4.1. Metric Block Structure 173 The RTP Flows Initial Synchronization Delay Report Block has the 174 following format: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | BT=RFISD | Reserved | Block length=2 | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | SSRC of Source | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Initial Synchronization Delay | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 4.2. Definition of Fields in RTP Flow Initial Synchronization Delay 187 Metrics Block 189 Block type (BT): 8 bits 191 The Statistics Summary Report Block is identified by the constant 192 . 194 Block length: 16 bits 196 The constant 2, in accordance with the definition of this field in 197 Section 3 of RFC 3611 [RFC3611]. 199 SSRC of Source: 32 bits 201 The SSRC of the media source SHALL be set to the value of the SSRC 202 identifier carried in an arbitrary RTP stream belonging to the 203 same multimedia session. 205 Initial Synchronization Delay: 32 bits 207 The average delay, expressed in units of 1/65536 seconds, from the 208 RTCP packets received on all of the components RTP sessions to the 209 beginning of session [RFC6051]. The value is calculated based on 210 the information contained in RTCP SR packets or the in-band 211 mapping of RTP and NTP-format timestamps [RFC6051]. If there is 212 no packet loss, the initial synchronization delay is expected to 213 be equal to the average time taken to receive the first RTCP 214 packet in the RTP session with the longest RTCP reporting 215 interval. 217 If the measurement is unavailable, the value of this field with 218 all bits set to 1 SHOULD be reported. 220 5. RTP Flows Synchronization Offset Metrics Block 222 In the RTP multimedia sessions, there can be an arbitrary number of 223 streams and each stream (e.g., audio stream or video stream) is sent 224 in a separate RTP stream. The receiver associates RTP streams to be 225 synchronized by means of RTCP CNAME contained in the RTCP Source 226 Description (SDES) packets [RFC3550]. 228 This block is sent by RTP receivers and reports synchronization 229 offset of the arbitrary two RTP streams that needs to be synchronized 230 in the RTP multimedia session. Information is recorded about the 231 actual delay variance of the measured RTP stream relative to he 232 reference RTP stream with the same CNAME. The reference RTP stream 233 can be chosen as the arbitrary stream with minimum delay according to 234 the common criterion defined in section 6.2.2.1 of [Y.1540]. 236 5.1. Metric Block Structure 238 The RTP Flow General Synchronization Offset Report Block has the 239 following format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | BT=RFSO | Reserved | Block length=3 | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | SSRC of source | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Synchronization Offset, most significant word | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Synchronization Offset, least significant word | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 5.2. Definition of Fields in RTP Flow General Synchronization Offset 254 Metrics Block 256 Block type (BT): 8 bits 258 The RTP Flow General Synchronization Offset Report Block is 259 identified by the constant . 261 Block length: 16 bits 263 The constant 3, in accordance with the definition of this field in 264 Section 3 of RFC 3611 [RFC3611]. 266 SSRC of Source: 32 bits 268 The SSRC of the media source SHALL be set to the value of the SSRC 269 identifier of the reference RTP stream to which the XR relates. 271 Synchronization Offset: 64 bits 273 The synchronization offset of one RTP stream relative to the 274 reference RTP stream with the same CNAME. The Synchronization 275 Offset of the reference stream should be zero. This value is 276 calculated based on the interarrival time between an arbitrary RTP 277 packet and the reference RTP packet with the same CNAME, and 278 timestamps of this arbitrary RTP packet and the reference RTP 279 packet with the same CNAME. The value of this field is 280 represented using a 64-bit NTP-format timestamp as defined in 281 [RFC5905], which is 64-bit unsigned fixed-point number with the 282 integer part in the first 32 bits and the fractional part in the 283 last 32 bits. 285 If the measurement is unavailable, the value of this field with 286 all bits set to 1 SHOULD be reported. 288 6. SDP Signaling 290 Two new parameters are defined for the two report blocks defined in 291 this document to be used with Session Description Protocol (SDP) 292 [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 293 They have the following syntax within the "rtcp-xr" attribute 294 [RFC3611]: 296 rtcp-xr-attrib = "a=rtcp-xr:" 297 [xr-format *(SP xr-format)] CRLF 298 xr-format = RTP-flows-init-syn-delay 299 / RTP-flows-syn-offset 300 RTP-flows-init-syn-delay = "RTP-flows-init-syn-delay" 301 ["=" max-size] 302 RTP-flow-syn-offset = "RTP-flows-syn-offset" 303 ["=" max-size] 304 max-size = 1*DIGIT ; maximum block size in octets 306 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 307 and the full syntax of the "rtcp-xr" attribute. 309 7. IANA Considerations 311 New report block types for RTCP XR are subject to IANA registration. 313 For general guidelines on IANA allocations for RTCP XR, refer to 314 Section 6.2 of [RFC3611]. 316 This document assigns two new block type values in the RTCP XR Block 317 Type Registry: 319 Name: RFISD 320 Long Name: RTP Flows Initial Synchronization Delay 321 Value 322 Reference: Section 4 324 Name: RFSO 325 Long Name: RTP Flows Synchronization Offset Metrics Block 326 Value 327 Reference: Section 5 329 This document also registers two new SDP [RFC4566] parameters for the 330 "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 332 * "RTP-flows-init-syn-delay" 333 * "RTP-flows-syn-offset" 335 The contact information for the registrations is: 337 Qin Wu 338 sunseawq@huawei.com 339 101 Software Avenue, Yuhua District 340 Nanjing, Jiangsu 210012, China 342 8. Security Considerations 344 The new RTCP XR report blocks proposed in this document introduces no 345 new security considerations beyond those described in [RFC3611]. 347 9. Acknowledgements 349 The authors would like to thank Bill Ver Steeg, David R Oran, Ali 350 Begen, Colin Perkins, Roni Even, Kevin Gross, Jing Zhao, Fernando 351 Boronat Segui, Youqing Yang, Wenxiao Yu and Yinliang Hu for their 352 valuable comments and suggestions on this document. 354 10. References 355 10.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 361 Jacobson, "RTP: A Transport Protocol for Real-Time 362 Applications", STD 64, RFC 3550, July 2003. 364 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 365 Protocol Extended Reports (RTCP XR)", RFC 3611, 366 November 2003. 368 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 369 Description Protocol", RFC 4566, July 2006. 371 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 372 Specifications: ABNF", STD 68, RFC 5234, January 2008. 374 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 375 Time Protocol Version 4: Protocol and Algorithms 376 Specification", RFC 5905, June 2010. 378 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 379 Flows", RFC 6051, November 2010. 381 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 382 "RTP Payload Format for Scalable Video Coding", RFC 6190, 383 May 2011. 385 10.2. Informative References 387 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 388 ID draft-ietf-avtcore-monarch-13, May 2012. 390 [Y.1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and 391 availability performance parameters", November 2007. 393 Appendix A. Change Log 395 Note to the RFC-Editor: please remove this section prior to 396 publication as an RFC. 398 A.1. draft-asaeda-xrblock-rtcp-xr-syncronization-07 400 Editorial changes are made from the previous version 06. 402 A.2. draft-asaeda-xrblock-rtcp-xr-syncronization-06 404 The following are the major changes compared to previous version 05: 406 o Define synchronization offset as 64 bit NTP-format timestamp to 407 meet synchronization resolution requirements for some RTP 408 applications. 409 o Add the definition of Initial Synchronization Delay in section 2. 410 o Other editorial changes. 412 A.3. draft-asaeda-xrblock-rtcp-xr-syncronization-05 414 The following are the major changes compared to previous version 04: 416 o Remove per packet reporting and only report a single value of 417 general synchronization offset. 419 A.4. draft-asaeda-xrblock-rtcp-xr-syncronization-04 421 The following are the major changes compared to previous version 03: 423 o Add a definition for synchronization offset. 424 o Use additional text in applicability section to clarify the 425 difference between synchronization delay and offset. 426 o Add a reference to tell how to select the reference stream. 427 o Other Editorial Changes. 429 A.5. draft-asaeda-xrblock-rtcp-xr-syncronization-03 431 The following are the major changes compared to previous version 02: 433 o Support multiple general synchronization offset reporting. 434 o Other Editorial Changes. 436 A.6. draft-asaeda-xrblock-rtcp-xr-syncronization-02 438 The following are the major changes compared to previous version 01: 440 o Clarify which synchronization is reported in section 4 and 5. 441 o Allow calculating the synchronization delay based on RTP header 442 extension defined in RFC6051 443 o Explain what the components of RTP session are in section 3. 445 A.7. draft-asaeda-xrblock-rtcp-xr-syncronization-01 447 The following are the major changes compared to previous version: 449 o Separate Synchronization Delay and Offset Metrics Block into two 450 independent block based on comments on the list. 452 A.8. draft-asaeda-xrblock-rtcp-xr-syncronization-00 454 The following are the major changes compared to previous version: 456 This document is separated from 457 draft-wu-xrblock-rtcp-xr-quality-monitoring-01 with some editorial 458 changes and focuses on RTP Flow Initial Synchronization Delay and 459 RTP Flows General Synchronization Offset. 461 Authors' Addresses 463 Hitoshi Asaeda 464 Keio University 465 Graduate School of Media and Governance 466 5322 Endo 467 Fujisawa, Kanagawa 252-0882 468 Japan 470 Email: asaeda@wide.ad.jp 472 Rachel Huang 473 Huawei Technologies Co., Ltd. 474 101 Software Avenue, Yuhua District 475 Nanjing, Jiangsu 210012 476 China 478 Email: Rachel@huawei.com 480 Qin Wu 481 Huawei Technologies Co., Ltd. 482 101 Software Avenue, Yuhua District 483 Nanjing, Jiangsu 210012 484 China 486 Email: sunseawq@huawei.com