Lay foundations for plugin-specific unique session ID in SIP and NoSIP plugins #3607
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.
The SIP and NoSIP plugins were so far lacking a way to uniquely identify a session: in the SIP plugin, for instance, we could in theory use the Call-ID, but that property actually identifies a call, not a specific participant in a call: in case both caller and callee are handled by the same Janus instance, or different calls end up using the same Call-ID by accident, this would cause ambiguity. As a result, there was no unique ID we could use to univocally identify a specific participant in the SIP and NoSIP plugins, which could be a very useful feature to have, e.g., to add some synchronous management requests to the plugin. This came up in #3604 (review), for example, but another potential use case would be the RTP forwarders support in #3583, where having these unique IDs would be quite useful too.
This PR adds this functionality, by simply introducing these new IDs but not using them for anything. In the SIP plugin, they're returned as
unique_idas part of theregisteringandregisteredevents, while in the NoSIP plugin they're returned with theprocessedandgeneratedevents: these IDs won't change as long as the Janus handle responsible for that session is alive.Planning to merge soon as this doesn't have an impact on existing functionality (they don't do anything except return a new ID that's not used for anything right now), but it will be useful for future things.