(WIP) Data track signaling

[ladvoc]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 00c694f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

💥 An error occurred when fetching the changed packages and changesets in this PR

Some errors occurred when validating the changesets config:
The package or glob expression "github.com/livekit/protocol" specified in the `fixed` option does not match any package in the project. You may have misspelled the package name or provided an invalid glob expression. Note that glob expressions must be defined according to https://www.npmjs.com/package/micromatch.

[boks1971]

Typed out a long message and my laptop power went out :-(

Trying again
I think it is better for client (i. e. publisher of data track) to generate this. Reason being generating this for distributed room would be complicated. Something that would be good to avoid.

SFU can generate a different ID for subscriber side. And communicate that to subscribing client using one of two options

1. A signal message to indicate mapping of handle ID -> track SID when a subscription happens. One issue is some data track packets arriving before signal messages arrives. Given that late joining subscriber will anyway not get all packets, this can be thought of a slightly delayed start.
2. Send as a header extension in the first 10 - 20 packets. The risk is all these packets getting lost. For media, this is usually handled by sending end adding that extension till the receiver sends an RTCP report. We can do this as this will introduce two important things for data tracks (extensions and feedback report). Feedback report can also be used for NACK + retransmission down the line. For this case, the feedback report could be something like RTCP Receiver Report.

If we do it, handle can be removed from DataTrackInfo as it does not have any use.

[boks1971]

Tried to compile and push, but still merge conflicts. Tried resolving conflicts and it became a major disaster. Will look at this more later.