There's a very odd getUserMedia call tucked into the base ErrorScreen.
There's no rationale in either the commit or PR that added them, but the
intention seems to be stopping audio on client crash.
Using getUserMedia like that will have no effect other than an odd
permission prompt on iframe-based environments or a webcam activation
flash after the client crashes.
Remove ErrorScreen's getUserMedia call as well as the HTMLMedia pause
call - both should be handled gracefully by AudioManager's forceExitAudio
triggered by the StopAudioTracks event (also ErrorScreen). If there's an
edge case where it isn't properly stopped, we'll have to tackle it
there.
* feat(plugins): add chat server command and chat message type `plugin`
This commit adds the required code for the plugins SDK's chat server
command `CHAT_SEND_MESSAGE`, which allows plugins to send chat
messages. Messages sent by plugins are identified by the message
type `plugin` and belong to the user (senderID) of the client that
sent it. Plugin messages are not displayed by the client itself because
these messages are meant to be custom-rendered by plugins, typically by
the plugin that sent them.
* feat(plugins): add message metadata
Plugin name and plugin custom metadata are stored in message's metadata,
so plugins need it to identify messages when applying custom render.
* feat(chat): removes specific code for plugin messages
Removes specific akka messages, handlers and routes for plugin messages
and adds metadata parameter in `GroupChatMsgFromUser`.
* feat(chat): adds option parameter to mutation
Adds optional parameter `metadata` to the already existing mutation
`chatSendMessage` and use this mutation for plugin chat server command.
* feat(chat): rendering of plugin messages
This commit implements the correct rendering of plugin messages, which
is:
- Plugin messages with metadata attribute `custom` set to true are not
rendered by the client, and are meant to be custom-rendered by
plugins.
- Plugin messages with metadata attribute `custom` set to false are
rendered by the client as being sent by the user that triggered it.
* Update sdk version to v0.0.56
* update sdk version to v0.0.57
Jitter evaluation, as an alert trigger, was changed in 3.0 to get the internal
average jitter used in the conn-status component data (which is total jitter
delay divided by jitterbuffer emit events). This was done accidentally and that
metric is _very_ different from the one used in 2.7 (point-in-time jitter from
remote-inbound-rtp/inbound-rtp, highest on the interval, gathered on
/utils/stats.js). The alert thresholds were preserved, which makes it overly
sensitive in regards to jitter (and thus causes it to be critical whenever the
user is in audio).
Remove jitter as a connection status alert trigger, which fixes the
false positive. The implementation on <= 2.7 is also not ideal - if
anything, it generates false negatives. That's why I'm removing jitter for
the time being since it's ill-suited (at least in the way it's used)
for what we want to achieve.
