1 / 6

RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting

RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting. draft-ietf-xrblock-rtcp-xr-synchronization-01. Hitoshi Asaeda (asaeda@wide.ad.jp ) R. Huang (rachel.huang@huawei.com) Qin Wu (sunseawq@huawei.com). Updates Since Last Version.

ansel
Download Presentation

RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting draft-ietf-xrblock-rtcp-xr-synchronization-01 Hitoshi Asaeda (asaeda@wide.ad.jp ) R. Huang (rachel.huang@huawei.com) Qin Wu (sunseawq@huawei.com)

  2. Updates Since Last Version • Clarified definition of synchronization offset • The relative time difference of two media streams that need to be synchronized. • Explain how to use in-band mapping of RTP and NTP-format timestamps to calculate initial synchronization delay • The average time taken to receive the first RTP header extension containing in-band mapping of RTP and NTP-format timestamps. • Improved SDP section • - Added a subsection to include the extended syntax. • Added a subsection to clarify SDP Offer/Answer usage • Updated references • - Adding one reference, TR-126, to normative references • - Updating some references to the latest version.

  3. Issue# Reference Stream Chosen • In RTP flow synchronization offset metrics block, how to choose the reference stream hasn’t been addressed in previous version of the draft. • We propose to let the implementation choose which stream as the reference stream : • To support this, the SSRC of the reference stream field has been added to the report block in current draft.

  4. Issue# Signed vs. Unsigned • RTP flow synchronization offset metrics block Lacks indications to tell whether the reporting stream lags behind or heads before the reference stream • synchronization offset value is a 64-bit unsigned fixed-point number. • Proposal: Sign flag bit (in current version of the draft): • splitting one bit from “Reserved” field of Block header to do the indication. • Proposal: Signed value (proposed by Colin): • Using a signed 64-bit NTP timestamp format for synchronization offset . • Suggest to adopt the “signed value” proposal. • Easier for implementations. • Few bits are used in the most significant 32 bits.

  5. Issue# Beginning of Session • How to calculate the “beginning of session” for initial synchronization delay? • According to RFC 6051 Section 2.1.1: • The single RTP session is considered to be joined once any in-band signaling for NAT traversal has concluded and/or security keying has concluded, and the media path is open. • For a group of RTP sessions, the beginning of session could be: • The time when the first RTP session was joined as the beginning of the whole multimedia session. • The time when the last RTP session was joined as the beginning of the whole multimedia session. • The time when the session with the longest report interval was joined. • The report interval may change as session size change and stabilization takes several report interval . • We should get consensus in WG.

  6. Next Step • Address all the remaining issues we received. • Comments?

More Related