idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-synchronization-09.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 26, 2014) is 3710 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) == Missing Reference: 'RFCXXXX' is mentioned on line 578, but not defined == Unused Reference: 'RFC6390' is defined on line 518, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 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 NICT 4 Intended status: Standards Track Q. Wu 5 Expires: August 30, 2014 R. Huang 6 Huawei 7 February 26, 2014 9 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for 10 Synchronization Delay and Offset Metrics Reporting 11 draft-ietf-xrblock-rtcp-xr-synchronization-09 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 30, 2014. 36 Copyright Notice 38 Copyright (c) 2014 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 . . . . . . . . 7 66 4.1. Metric Block Structure . . . . . . . . . . . . . . . . . . 7 67 4.2. Definition of Fields in RTP Flow General 68 Synchronization Offset Metrics Block . . . . . . . . . . . 8 69 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 9 71 5.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Appendix A. Metrics represented using RFC6390 Template . . . . . 12 79 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 13 80 B.1. draft-ietf-xrblock-rtcp-xr-syncronization-09 . . . . . . . 14 81 B.2. draft-ietf-xrblock-rtcp-xr-syncronization-08 . . . . . . . 14 82 B.3. draft-ietf-xrblock-rtcp-xr-syncronization-07 . . . . . . . 14 83 B.4. draft-ietf-xrblock-rtcp-xr-syncronization-06 . . . . . . . 14 84 B.5. draft-ietf-xrblock-rtcp-xr-syncronization-05 . . . . . . . 14 85 B.6. draft-ietf-xrblock-rtcp-xr-syncronization-04 . . . . . . . 14 86 B.7. draft-ietf-xrblock-rtcp-xr-syncronization-03 . . . . . . . 14 87 B.8. draft-ietf-xrblock-rtcp-xr-syncronization-02 . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 1.1. Synchronization Delay and Offset Metrics Reporting Blocks 94 This document defines two new block types to augment those defined in 95 [RFC3611], for use in a range of RTP applications. 97 The first new block type supports reporting of Initial 98 Synchronization Delay to establish multimedia session. Information 99 is recorded about time difference between the start of RTP sessions 100 and the time the RTP receiver acquires all components of RTP sessions 101 in the multimedia session [RFC6051]. 103 The second new block type supports reporting of the relative 104 synchronization offset time of two arbitrary streams (e.g., between 105 audio and video streams), with the same RTCP CNAME included in RTCP 106 Source description items (SDES) packets [RFC3550]. 108 These metrics belong to the class of transport level metrics defined 109 in [RFC6792]. 111 1.2. RTCP and RTCP XR Reports 113 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 114 defined an extensible structure for reporting using an RTCP Extended 115 Report (XR). This document defines a new Extended Report block for 116 use with [RFC3550] and [RFC3611]. 118 1.3. Performance Metrics Framework 120 The RTP Monitoring Architectures [RFC6792] provides guideline for 121 reporting block format using RTCP XR. The new report block described 122 in this memo is in compliance with the monitoring architecture 123 specified in [RFC6792]. 125 1.4. Applicability 127 When joining each session in layered video sessions [RFC6190] or the 128 multimedia session, a receiver may not synchronize playout across the 129 multimedia session or layered video session until RTCP Sender Report 130 (SR) packets have been received on all components of RTP sessions. 131 The component RTP session are referred to as each RTP session for 132 each media type in multimedia session or separate RTP session for 133 each layer in the layered video session. For multicast session, the 134 initial synchronization delay metric varies with the session 135 bandwidth, the number of members, and the number of senders in the 136 session. The RTP flow Initial synchronization delay block defined in 137 this document can be used to report such metric, i.e., the initial 138 synchronization delay to receive all the RTP streams belonging to the 139 same multimedia session or layered video session. In the absence of 140 packet loss, the initial synchronization delay equals to the average 141 time taken to receive the first RTCP packet in the RTP session with 142 the longest RTCP reporting interval. In the presence of packet loss, 143 the media synchronization should rely on the in-band mapping of RTP 144 and NTP-format timestamps [RFC6051] or wait until the reporting 145 interval has passed, and the next RTCP SR packet is sent. 147 Receivers of the RTP flow initial synchronization delay block could 148 use this metric to compare with targets (i.e., Service Level 149 Agreement or thresholds of the system) to help ensure the quality of 150 real-time application performance. 152 In an RTP multimedia session, there can be an arbitrary number of 153 streams carried in different RTP sessions, with the same RTCP CNAME. 154 These streams may be not synchronized with each other. For example, 155 one audio stream and one video stream belong to the same session, and 156 the audio stream is transmitted lagging behind video stream for 157 multiple tens of milliseconds [TR-126]. The RTP Flows 158 Synchronization Offset block can be used to report such 159 synchronization offset between video stream and audio stream. This 160 block is also applied to the case where an RTP session can contain 161 media streams with media from multiple media types. The metrics 162 defined in the RTP flows synchronization Offset block can be used by 163 the network manager for trouble shooting and dealing with user 164 experience issues. 166 2. Terminology 168 2.1. Standards Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 In addition, the following terms are defined: 176 Initial Synchronization Delay: 178 A multimedia session comprises a set of concurrent RTP sessions 179 among a common group of participants, using one RTP session for 180 each media type. The initial synchronization Delay is the average 181 time for receiver to synchronize all components of a multimedia 182 session [RFC6051]. 184 Synchronization Offset: 186 Synchronization between two media streams must be maintained to 187 ensure satisfactory Quality of Experience (QoE). Two media 188 streams can be of the same or different media type belonging to 189 one RTP session or in different media types belonging to one 190 multimedia session. The Synchronization Offset is the relative 191 time difference of the two media streams that need to be 192 synchronized. 194 3. RTP Flows Initial Synchronization Delay Report Block 196 This block is sent by RTP receivers and reports Initial 197 synchronization delay beyond the information carried in the standard 198 RTCP packet format. Information is recorded about time difference 199 between the start of multimedia session and the time when the RTP 200 receiver acquires all components of RTP sessions [RFC6051] measured 201 at the receiving end of RTP stream. 203 This block needs only be exchanged occasionally, for example sent 204 once at the start of RTP session. 206 3.1. Metric Block Structure 208 The RTP Flows Initial Synchronization Delay Report Block has the 209 following format: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | BT=RFISD | Reserved | Block length=2 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | SSRC of Source | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Initial Synchronization Delay | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 1: Report Block Structure 223 3.2. Definition of Fields in RTP Flow Initial Synchronization Delay 224 Metrics Block 226 Block type (BT): 8 bits 228 The RTP Flows Initial Synchronization Delay Report Block is 229 identified by the constant . 231 [Note to RFC Editor: please replace RFISD with the IANA provided 232 RTCP XR block type for this block.] 234 Reserved: 8 bits 236 This field is reserved for future definition. In the absence of 237 such a definition, the bits in this field MUST be set to zero and 238 ignored by the receiver. 240 Block length: 16 bits 242 The constant 2, in accordance with the definition of this field in 243 Section 3 of RFC 3611 [RFC3611]. 245 SSRC of source: 32 bits 247 The SSRC of the media source SHALL be set to the value of the SSRC 248 identifier carried in any arbitrary component of RTP sessions 249 belonging to the same multimedia session. 251 Initial Synchronization Delay: 32 bits 253 The average delay, expressed in units of 1/65536 seconds, from the 254 beginning of multimedia session [RFC6051] to the time when RTCP 255 packets are received on all of the components RTP sessions. It is 256 recommended that the beginning of multimedia session is chosen as 257 the time when the receiver has joined the first RTP session of the 258 multimedia session. The value of the initial synchronization 259 delay is calculated based on received RTCP SR packets or the RTP 260 header extension containing in-band mapping of RTP and NTP-format 261 timestamps [RFC6051]. If there is no packet loss, the initial 262 synchronization delay is expected to be equal to the average time 263 taken to receive the first RTCP packet in the RTP session with the 264 longest RTCP reporting interval or the average time taken to 265 receive the first RTP header extension containing in-band mapping 266 of RTP and NTP-format timestamps. 268 If the measurement is unavailable, the value of this field with 269 all bits set to 1 MUST be reported. 271 4. RTP Flows Synchronization Offset Metrics Block 273 In the RTP multimedia sessions or one RTP session, there can be an 274 arbitrary number of Media streams and each media stream (e.g., audio 275 stream or video stream) is sent in a separate RTP stream. In case of 276 one RTP session, each media stream or each medium uses different 277 SSRC. The receiver associates RTP streams to be synchronized by 278 means of RTCP CNAME contained in the RTCP Source Description (SDES) 279 packets [RFC3550]. 281 This block is sent by RTP receivers and reports synchronization 282 offset of two arbitrary RTP streams that needs to be synchronized in 283 the RTP multimedia session. Information is recorded about the 284 relative average time difference between two arbitrary RTP streams 285 (one is reporting stream, the other is reference stream) with the 286 same CNAME and measured at the receiving end of RTP stream. In order 287 to tell what the offset of reporting stream is relative to, the block 288 for reference stream with synchronization offset of zero should be 289 reported. 291 Instances of this Block refer by Synchronization source (SSRC) to the 292 separate auxiliary Measurement Information block [RFC6776] which 293 describes measurement periods in use (see [RFC6776] section 4.2). 294 This metrics block relies on the measurement period in the 295 Measurement Information block indicating the span of the report and 296 SHOULD be sent in the same compound RTCP packet as the measurement 297 information block. If the measurement period is not received in the 298 same compound RTCP packet as this Block, this Block MUST be 299 discarded. 301 4.1. Metric Block Structure 303 The RTP Flow General Synchronization Offset Report Block has the 304 following format: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | BT=RFSO | I | Reserved | Block length=3 | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | SSRC of source | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Synchronization Offset, most significant word | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Synchronization Offset, least significant word | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 2: Report Block Structure 320 4.2. Definition of Fields in RTP Flow General Synchronization Offset 321 Metrics Block 323 Block type (BT): 8 bits 325 The RTP Flow General Synchronization Offset Report Block is 326 identified by the constant . 328 [Note to RFC Editor: please replace RFSO with the IANA provided 329 RTCP XR block type for this block.] 331 Interval Metric Flag (I): 2 bits 333 This field is used to indicate whether the Burst/Gap Discard 334 Summary Statistics metrics are Sampled, Interval or Cumulative 335 metrics: 337 I=10: Interval Duration - the reported value applies to the 338 most recent measurement interval duration between successive 339 metrics reports. 340 I=11: Cumulative Duration - the reported value applies to the 341 accumulation period characteristic of cumulative measurements. 342 I=01: Sampled Value - the reported value is a sampled 343 instantaneous value. 345 In this document, the value I=00 is the reserved value and MUST 346 NOT be used. If the value I=00 is received, then the XR block 347 MUST be ignored by the receiver. 349 Reserved: 6 bits 351 This field is reserved for future definition. In the absence of 352 such a definition, the bits in this field MUST be set to zero and 353 MUST be ignored by the receiver. 355 Block length: 16 bits 357 The constant 3, in accordance with the definition of this field in 358 Section 3 of RFC 3611 [RFC3611]. 360 SSRC of Source: 32 bits 362 The SSRC of the media source SHALL be set to the value of the SSRC 363 identifier of the reporting RTP stream to which the XR relates. 365 Synchronization Offset: 64 bits 367 The synchronization offset of the reporting RTP stream relative to 368 the reference stream with the same CNAME. The calculation of 369 Synchronization Offset is similar to Difference D calculation in 370 the RFC3550. That is to say, if Si is the NTP timestamp from the 371 reporting RTP packet i, and Ri is the time of arrival in NTP 372 timestamp units for reporting RTP packet i, Sj is the NTP 373 timestamp from the reference RTP packet j, and Rj is the time of 374 arrival in NTP timestamp units for reference RTP packet j, then 375 the value of the synchronization offset D may be expressed as 377 D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) 379 If in-band delivery of NTP-format timestamps is supported 380 [RFC6051], Si and Sj should be obtained directly from the RTP 381 packets where NTP timestamps are available. If not, Si and Sj 382 should be calculated from their corresponding RTP timestamps. The 383 value of the synchronization offset is represented using a 64-bit 384 signed NTP-format timestamp as defined in [RFC5905], which is 64- 385 bit signed fixed-point number with the integer part in the first 386 32 bits and the fractional part in the last 32 bits. A positive 387 value of the synchronization offset means that the reporting 388 stream leads before the reference stream, while a negative one 389 means the reporting stream lags behind the reference stream. The 390 synchronization offset of zero means the stream is the reference 391 stream. 393 If the measurement is unavailable, the value of this field with 394 all bits set to 1 MUST be reported. 396 5. SDP Signaling 398 [RFC3611] defines the use of SDP (Session Description Protocol) 399 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 400 without prior signaling. 402 5.1. SDP rtcp-xr-attrib Attribute Extension 404 Two new parameters are defined for the two report blocks defined in 405 this document to be used with Session Description Protocol (SDP) 406 [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 407 They have the following syntax within the "rtcp-xr" attribute 408 [RFC3611]: 410 xr-format = xr-rfisd-block 411 / xr-rfso-block 413 xr-rfisd-block = "rtp-flow-init-syn-delay" 414 xr-rfso-block = "rtp-flow-syn-offset" 416 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 417 and the full syntax of the "rtcp-xr" attribute. 419 5.2. Offer/Answer Usage 421 When SDP is used in offer-answer context, the SDP Offer/Answer usage 422 defined in [RFC3611] applies. 424 6. IANA Considerations 426 New report block types for RTCP XR are subject to IANA registration. 427 For general guidelines on IANA allocations for RTCP XR, refer to 428 Section 6.2 of [RFC3611]. 430 This document assigns two new block type values in the RTCP XR Block 431 Type Registry: 433 Name: RFISD 434 Long Name: RTP Flows Initial Synchronization Delay 435 Value 436 Reference: Section 3 438 Name: RFSO 439 Long Name: RTP Flows Synchronization Offset Metrics Block 440 Value 441 Reference: Section 4 443 This document also registers two new SDP [RFC4566] parameters for the 444 "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 446 * "rtp-flow-init-syn-delay " 447 * "rtp-flow-syn-offset" 449 The contact information for the registrations is: 451 RAI Area Directors 452 454 7. Security Considerations 456 When using Secure RTP [RFC3711], or other media layer security, 457 reporting accurate synchronisation offset information can expose some 458 details about the timing of the cryptographic operations that are 459 used to protect the media. There is a possibility that this timing 460 information might enable a side-channel attack on the encryption. 461 For environments where this attack is a concern, implementations need 462 to take care to ensure cryptographic processing and media compression 463 take the same amount of time irrespective of the media content, to 464 avoid the potential attack. 466 Besides this, it is believed that this RTCP XR block introduces no 467 new security considerations beyond those described in [RFC3611]. 469 8. Acknowledgements 471 The authors would like to thank Bill Ver Steeg, David R Oran, Ali 472 Begen, Colin Perkins, Roni Even, Kevin Gross, Jing Zhao, Fernando 473 Boronat Segui, Mario Montagud Climent, Youqing Yang, Wenxiao Yu and 474 Yinliang Hu,Jonathan Lennox, Stephen Farrel for their valuable 475 comments and suggestions on this document. 477 9. References 479 9.1. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 485 Jacobson, "RTP: A Transport Protocol for Real-Time 486 Applications", STD 64, RFC 3550, July 2003. 488 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 489 Protocol Extended Reports (RTCP XR)", RFC 3611, 490 November 2003. 492 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 493 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 494 RFC 3711, March 2004. 496 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 497 Description Protocol", RFC 4566, July 2006. 499 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 500 Specifications: ABNF", STD 68, RFC 5234, January 2008. 502 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 503 Time Protocol Version 4: Protocol and Algorithms 504 Specification", RFC 5905, June 2010. 506 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 507 Flows", RFC 6051, November 2010. 509 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 510 "RTP Payload Format for Scalable Video Coding", RFC 6190, 511 May 2011. 513 [RFC6776] Wu, Q., "Measurement Identity and information Reporting 514 using SDES item and XR Block", RFC 6776, August 2012. 516 9.2. Informative References 518 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 519 Performance Metric Development", RFC 6390, October 2011. 521 [RFC6792] Wu, Q., "Guidelines for Use of the RTP Monitoring 522 Framework", RFC 6792, November 2012. 524 [TR-126] BBF Forum, "Triple-play Services Quality of Experience 525 (QoE) Requirements", December 2006. 527 [Y.1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and 528 availability performance parameters", November 2007. 530 Appendix A. Metrics represented using RFC6390 Template 532 RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC 533 number, when assigned. 535 a. Initial Synchronization Delay Metric 537 * Metric Name: RTP Initial Synchronization Delay 539 * Metric Description: See Section 2.1,Initial Synchronization 540 Delay term [RFCXXXX]. 542 * Method of Measurement or Calculation: See section 3.2, Initial 543 Synchronization Delay definition [RFCXXXX]. 545 * Units of Measurement: See section 3.2, Initial Synchronization 546 Delay definition [RFCXXXX]. 548 * Measurement Point(s) with Potential Measurement Domain: See 549 section 3, 1st paragraph [RFCXXXX]. 551 * Measurement Timing: See section 3, 2nd paragraph [RFCXXXX] for 552 measurement timing. 554 * Use and applications: See section 1.4 [RFCXXXX]. 556 * Reporting model: See RFC3611. 558 b. Synchronization Offset Metric 560 * Metric Name: RTP Synchronization Offset Delay 562 * Metric Description: See Section 2.1, Synchronization Offset 563 term [RFCXXXX]. 565 * Method of Measurement or Calculation: See section 4.2, Initial 566 Synchronization Delay definition [RFCXXXX]. 568 * Units of Measurement: See section 4.2, Initial Synchronization 569 Delay definition [RFCXXXX]. 571 * Measurement Point(s) with Potential Measurement Domain: See 572 section 4, 2nd paragraph [RFCXXXX]. 574 * Measurement Timing: See section 4, 3rd paragraph [RFCXXXX] for 575 measurement timing and section 4.2 [RFCXXXX] for Interval 576 Metric flag. 578 * Use and applications: See section 1.4 [RFCXXXX]. 580 * Reporting model: See RFC3611. 582 Appendix B. Change Log 584 Note to the RFC-Editor: please remove this section prior to 585 publication as an RFC. 587 B.1. draft-ietf-xrblock-rtcp-xr-syncronization-09 589 The following are the major changes compared to previous version: 591 Some Editorial changes based on IESG Review comments. 593 B.2. draft-ietf-xrblock-rtcp-xr-syncronization-08 595 The following are the major changes compared to previous version: 597 Some Editorial changes based on Gen-Art Reviewer comments. 599 B.3. draft-ietf-xrblock-rtcp-xr-syncronization-07 601 The following are the major changes compared to previous version: 603 Minor Editorial changes. 605 B.4. draft-ietf-xrblock-rtcp-xr-syncronization-06 607 The following are the major changes compared to previous version: 609 Some Editorial changes. 611 B.5. draft-ietf-xrblock-rtcp-xr-syncronization-05 613 The following are the major changes compared to previous version: 615 Editorial changes and typo fixed. 617 B.6. draft-ietf-xrblock-rtcp-xr-syncronization-04 619 The following are the major changes compared to previous version: 621 Additional text to clarify on how to distinguish report stream 622 from reference stream. 623 Other Editorial changes. 625 B.7. draft-ietf-xrblock-rtcp-xr-syncronization-03 627 The following are the major changes compared to previous version: 629 Remove the need to signal the reference source in the 630 synchronisation offset metrics RTCP XR report. 631 Apply RFC6390 template to metrics in the appendix. 632 Other editorial changes to get inline with other XRBLOCK drafts. 634 B.8. draft-ietf-xrblock-rtcp-xr-syncronization-02 636 The following are the major changes compared to previous version: 638 Editorial change based on comments raised on the list and in the 639 IETF85 meeting 641 Authors' Addresses 643 Hitoshi Asaeda 644 National Institute of Information and Communications Technology 645 4-2-1 Nukui-Kitamachi 646 Koganei, Tokyo 184-8795 647 Japan 649 Email: asaeda@nict.go.jp 651 Qin Wu 652 Huawei Technologies Co., Ltd. 653 101 Software Avenue, Yuhua District 654 Nanjing, Jiangsu 210012 655 China 657 Email: bill.wu@huawei.com 659 Rachel Huang 660 Huawei Technologies Co., Ltd. 661 101 Software Avenue, Yuhua District 662 Nanjing, Jiangsu 210012 663 China 665 Email: Rachel@huawei.com