Clarify status of RTP Header Extension for Absolute Capture Time

[dontcallmedom]

the spec links to RTP Header Extension for Absolute Capture Time as a reference; that document is not a standards, but claims that "once experience has shown that it is useful, we intend to make a proposal based on it for standardization in the IETF."

Since that feature has been added 4 years ago, I assume experience has shown it to be useful or not at this point.

If it's not, we should probably remove the feature. If it is, it would be good to have an IETF reference to replace the webrtc.org one.

[dontcallmedom]

@drkron you seem to have been the committer for the document on webrtc.org - do you know if there are any plans to bringing this to the IETF?

[drkron]

Sorry for the delay, I'm just back from vacation.

webrtc.org was moved to a new hosting solution and as part of that the RTP header extension documention was moved from GitHub to the WebRTC repository. My CL just moved the documentation.

@Arctunix Do you know the plans for this extension?

[Arctunix]

@Orphis has been looking into standardizing this extension.

It's worth noting that although the original document was written four years ago, it wasn't until a few months ago that it was "implemented enough" in Meet to provide us with any learnings. I think the key takeaway so far is that the design itself and its implementation in WebRTC seem to be quite robust but the overall feature is a) finicky to use through the Web APIs (the formula for calculating one-way delay is very confusing) and b) vulnerable to "other" code (e.g. non-WebRTC server code) doing erroneously timestamp conversions.

[alvestrand]

Presented at IETF as https://docs.google.com/presentation/d/15gUqky5i2YF3NxP6efoImLalvvo2ez_C1NTU248wVGU/edit?usp=sharing - slide 56