rtcp xr blocks for synchronization delay and offset metrics reporting
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


  • 93 Views
  • Uploaded on

RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting. draft-ietf-xrblock-rtcp-xr-synchronization-01. Hitoshi Asaeda ([email protected] ) R. Huang ([email protected]) Qin Wu ([email protected]). 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


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 ([email protected] )

R. Huang ([email protected])

Qin Wu ([email protected])

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