The command `selectStream` also supports optional boolean flags `audio`
and `video` that can be used to enable/disable receiving the corresponding
media from the stream.
The "sid" parameter of "requestOffer" messages is now checked to update
the current Janus connection when it matches the "sid" of the subscriber
rather than closing it and creating a new one.
Updating a connection is needed for clients to renegotiate their
received media without interrupting the current connection. For example,
to stop receiving video by triggering a new offer from Janus and then
setting the video transceiver direction as inactive before creating the
answer.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If a message includes a "sid" parameter and it does not match the one
from the publisher or the subscriber the message is ignored. However, if
the message does not include a "sid" parameter it is processed just like
before for backwards compatibility.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
A new ID is introduced for publishers and subscribers to be able to
identify different connections in the same session. While it was
possible to do that from the Janus handles this ID is meant to be shared
with the clients and set by the peer sending the offer, so it is set by
the client for publishers and by the signaling server for subscribers
(in which case the Janus handle is used).
This will make possible to know without any ambiguity if an offer/answer
belongs to an already existing connection or not. This can be used, for
example, to know if an offer represents an update or a new connection,
or to discard unneeded messages that might be sent in some corner cases
by the clients.
The ID name is "sid" for consistency with the property name used by the
internal signaling server of Talk.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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.
- 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.
