rtcp xr blocks for synchronization delay and offset metrics reporting n.
Download
Skip this Video
Download Presentation
RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting

Loading in 2 Seconds...

play fullscreen
1 / 6

RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting - PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting' - ansel


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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)

slide2

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.
slide3

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.
slide4

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.
slide5

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.
slide6

Next Step

  • Address all the remaining issues we received.
  • Comments?
ad