Added support for data channel subprotocol #2157
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.
This is actually a subset of #1898, which is where we implemented support for real-time text to the SIP plugin using data channels. Per the standard, RTT on data channels requires a dedicated subprotocol, and since we didn't support it in Janus, that PR also implemented that part. That said, this feature doesn't really need to be tied to that effort, so I decided to make a separate PR instead, that we could merge sooner.
It's important to point out that the subprotocol is used when a new channel is created, and is not something you can change dynamically after a specific channel has been created. As such, you should always use it in conjunction with a label: this way, if the label doesn't exist, a new channel for it will be created, and the subprotocol you specified be assigned to it and used for all messages exchanged on it.
At the moment this only implements support for the feature, but no plugin really makes use of it. Anyway, it's easy to test with the EchoTest, since if you send data channel messages to that plugin with a specific label and opening a new channel with a specific subprotocol, it will use it for the response as well. As such, you can modify the echotest.js code like this:
and you should see the response coming from the label you specified, and on the subprotocol used for the new channel. The same can be done from a plugin code as well, by properly setting the
protocol
in thejanus_plugin_data
structure: