Add support for receiving offers in Streaming plugin #3199
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the Streaming plugin, it's always the plugin that generates an SDP offer, and the subscriber that provides an answer: this is something we decided to do on purpose since, when creating a mountpoint, we know the constraints and the available media already, and so it made much more sense to prepare an offer ourselves with those constraints in mind, rather than waiting for an offer and then try to match it. VideoRoom subscribers work the same way for exactly the same reason.
That said, the Streaming plugin is what we also use in our WHEP server prototype, and unfortunately, while previous versions of the specification supported this mode, the latest version of the draft now forces WHEP servers to receive an offer from viewers instead, and generate an answer accordingly. I don't like this approach at all, but if we want Janus to be used as a WHEP server, we must unfortunately support this ugly mode as well.
This PR is a first attempt at doing exactly that. It allows a subscriber to provide an SDP offer when sending a
watch
request, at which the Streaming plugin will respond with an SDP answer that matches the mountpoint configuration. To make things simpler, in this new offer-mode the plugin ignores any of the properties we typically support when handling awatch
request: this means you can't, for instance, narrow down the list of streams you're interested in. The plugin will simply try to match incoming m-lines with available m-lines in the mountpoint, going in order: so, if the subscriber sent an offer with a single audio m-line and a single video m-line, but the mountpoint has multiple audio and/or video m-lines, the matching will proceed in order, so you'll get what you get (more than often the first m-lines in the mountpoint, assuming codecs match). I don't plan to change this behaviour in the short term.Notice that the Streaming plugin demo in the repo has not been updated, and so will not support this mode: if you want to test this functionality with that demo, you'll have to modify it yourself. This new mode was specifically conceived and added for WHEP servers, which means I'll add a way to test this in our simple-whep-server instead. I'll copy a link to the related PR here when it's available.