We are moving to use remote publishers and also we use attendees, and now we have a problem on servers which we remote publishing to - they don’t have a list of attendees. I don’t know how to get around it now without hacks, since we can’t add remote publisher as attendee.
To work around this we are doing add_remote_publisher with stub stream, without sending publish_remotely to source server, and adding metadata flag with attendee=true. I don’t like this solution because we have to work with this additional flag on remote servers and with attendees on source - two different ways to work with.
I don’t think this is something that needs to be solved at the Janus level. Attendees are subscribers who aren’t publishing, and those are always specific to the Janus instance they’re connected to, unlike publishers that may need to be remotized. To me this sounds like something that should be advertised out of band.
Not really, attendees in janus are publishers which doesn’t have any streams published. I understand your point in simple case - when janus used for delivery and clients doesn’t care who joined to room. In case when notify_joining is enabled and logic on clients app uses this info to show who joined room it can be important. Janus could be used as participants tracker of room and business logic can be built around it.
e.g. in our case attendee is a publisher, which doesn’t publish video but publishes audio stream to audiobridge - if attendee starts to publish video it becomes publisher seamlessly. We have multi-server environment in which every server is a different customers environment - we build decentalized network with federation of group calls. If attendees information could be shared across janus it can remove additional complexity for business logic level. This is just an option of how janus could be used.
Which is basically what I said, though: unless you have out of band mechanisms to be notified about existing publishers, you have to join as a publisher just for the join/leave events even when you’re a basic subscriber.
The APIs we added for remote publishers are explicitly tied to active publishers, since as soon as one is added (even before media comes in) it’s advertised to all attendees. Adding state to remote publishers (published/not published/etc.) would greatly complicate their management and it’s something I’d rather avoid.