feature: multiple sip subscriptions support

[digiboridev]

This changes allows to make multiple subscriptions for same event type. To do so it uses call_id from request for distinguish subscriptions, if no call_id provided its just falls back to event_type.

[januscla]

Thanks for your contribution, @digiboridev! Please make sure you sign our CLA, as it's a required step before we can merge this.

[lminiero]

I'll need time I don't have right now to review this, but I suspect using the call-ID will not be a good way to do this. A call-ID identifies a call, not an individual participant in a call, so if both of parties in a call are handled by Janus there will be ambiguity in what you'll send this subscription on.

I think that the only way to solve this might be to introduce a new plugin-specific unique ID that the API is aware of, that is returned by the plugin when a user first registers, e.g.,

1. the plugin introduces a new global map of unique IDs
2. a user sends a "register" (actual register, helper or guest, doesn't matter)
3. the plugin answers as usual, but also returns a unique ID, that identifies that handle univocally
4. all operations that need to apply to a specific call from a specific user perspective can refer to that unique ID, since it identifies a specific handle

This may be beyond the scope of this PR, meaning it's probably something I need to first do externally in a separate PR of my own, so that you can then refer to it later in this effort here.

[digiboridev]

I'll need time I don't have right now to review this, but I suspect using the call-ID will not be a good way to do this. A call-ID identifies a call, not an individual participant in a call, so if both of parties in a call are handled by Janus there will be ambiguity in what you'll send this subscription on.

I think that the only way to solve this might be to introduce a new plugin-specific unique ID that the API is aware of, that is returned by the plugin when a user first registers, e.g.,

1. the plugin introduces a new global map of unique IDs
2. a user sends a "register" (actual register, helper or guest, doesn't matter)
3. the plugin answers as usual, but also returns a unique ID, that identifies that handle univocally
4. all operations that need to apply to a specific call from a specific user perspective can refer to that unique ID, since it identifies a specific handle

This may be beyond the scope of this PR, meaning it's probably something I need to first do externally in a separate PR of my own, so that you can then refer to it later in this effort here.

Thanks for answer, i agree with you, the path chosen in this RP implicitly requires client to take care of uniqueness of call_id, but from Janus perspective it can't be garantied so it will lead to potential errors. Will glad to see proper solution from you.

[lminiero]

I'll try to prepare a PR in the next few days and let you know when it's available 🙏

[lminiero]

@digiboridev please refer to the PR above for the functionality I was talking about. Those new IDs can be considered 100% unique within the context of the SIP plugin in a specific Janus instance.