By default, the "join" events contain the whole userdata as received
from the "auth" response. This might include a "displayname" field
containing the display name of the associated user.
For privacy reasons in certain scenarios, some attendees should not
be able to know which other users are connected to a room, therefore
the "displayname" should be hidden for them. By default, no filtering
occurrs.
The "mediaTypes" attribute is checked to know if a publisher needs to be
closed when the permissions are updated. However, that attribute was set
only when the publisher was initially created; due to this if a
publisher then used a renegotiation to add media not included in the
original offer the publisher would not be closed if the publishing
permission for that media was later revoked.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a publisher has a connection the publisher can update the
connection (for example, to add a video track to an audio only
connection) by sending an updated offer to Janus. Janus detects that,
adjusts the connection and then sends back an answer. Once the publisher
connection is updated Janus starts a renegotiation for the subscribers
and generates the offers to be sent to them.
The signaling server did not handle the event, so the offers were not
sent and the subscriber connections were not updated. Now the offers are
sent as needed, which makes possible for the renegotiation to be
completed by the clients.
In this case the "offer" message will also include an "update" parameter
so clients can differentiate between offers to create new connections or
update the existing one.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If a client publishes audio/video and no longer has the video permission,
the whole publisher will be closed. Previously this was only checking
the generic "media" permission.
Clients with permission "publish-media" can publish any audio/video. Other
clients need to have "publish-audio" and/or "publish-video" to publish the
corresponding media types. For this the SDP in the offer is parsed to check
what will be sent.
Can happen mostly during tests (e.g. TestClientTakeoverRoomSession)
where the new client could receive the "leave" event that was sent
before it joined the room (but got delivered after joining).
- Individually for each backend.
- For the proxy client (i.e. signaling server using cluster of proxies).
- For the proxy server / MCU.
The smallest bandwidth configured will be used, e.g. if a backend has a
larger limit than the MCU assigned for the stream, the limit of the MCU
server will be used.
