Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for sending abs-capture-time RTP extension #217

Draft
wants to merge 4 commits into
base: v3
Choose a base branch
from

Conversation

ibc
Copy link
Member

@ibc ibc commented Sep 28, 2022

Since recent versions, Chromium/Chrome has support for sending the abs-capture-time RTP extension, however it lacks some stuff (read the issue in the link below):

  • Negotiate the header extension.
  • Collect capture time for audio and video and have the info sent with the header extension.
  • Receive the header extension and use its info.

NOTE: If the second bullet is true it means that, even forcing the extension to be sent via SDP munging, it's not sending useful content ¯_(ツ)_/¯

This PR forces negotiation of the abs-capture-time for sending by means of local SDP offer munging.

@ibc ibc requested a review from jmillan September 28, 2022 12:30
@jmillan
Copy link
Member

jmillan commented Sep 28, 2022

Does it need be exposed in the public API?

Why not simply always force it in chrome74.ts until it's done by the implementation itself?

@ibc
Copy link
Member Author

ibc commented Sep 28, 2022

Does it need be exposed in the public API?

Why not simply always force it in chrome74.ts until it's done by the implementation itself?

No need to send an extra header (it means more bandwidth usage) if it's not gonna be consumed.

@jmillan
Copy link
Member

jmillan commented Sep 28, 2022

No need to send an extra header (it means more bandwidth usage) if it's not gonna be consumed.

But by the time Chrome decides to expose it always (as it does with the rest of them), it will be sent always as the rest of unsolicited extra headers, am I wrong?

@ibc
Copy link
Member Author

ibc commented Sep 28, 2022

No need to send an extra header (it means more bandwidth usage) if it's not gonna be consumed.

But by the time Chrome decides to expose it always (as it does with the rest of them), it will be sent always as the rest of unsolicited extra headers, am I wrong?

Right. I'll remove the param.

@ibc
Copy link
Member Author

ibc commented Oct 26, 2022

finally nobody seems to need this feature so I'll convert to a draft.

@ibc ibc marked this pull request as draft October 26, 2022 11:59
@fippo
Copy link
Contributor

fippo commented Nov 2, 2022

This PR forces negotiation of the abs-capture-time for sending by means of local SDP offer munging.

Your SDP O/A foo is weak son :trollface:
It is entirely sufficient to add that extmap to the remote answer to cause the sender to send the extension as demonstrated by this fiddle. O/A with quirks!

@ibc
Copy link
Member Author

ibc commented Nov 3, 2022

It is entirely sufficient to add that extmap to the remote answer to cause the sender to send the extension

It shouldn't work ¯_(ツ)_/¯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants