For browsers that don't support headerBytesSent in RTCOutboundRtpStreamStats
neither headerBytesReceived in RTCInboundRtpStreamStats, we are now able
to calculate upload and download rates.
We are also able to get transportStats information for browsers that
don't support iceTransport attribute of RTCDtlsTransport.
As far as I could understand, polls are tightly coupled with the meeting
main content area, or at least they were and we still have to deal with
this close relation between them. Not sure if it's something we'll keep
this way forever but, from my candid perspective, looks like this is already
diverging inside the poll model. Polls are indexed by presentation pages,
screenshare or even something called "public" that I'm not 100% what
actually means. My best guess is anything besides the first and the second.
The polling stop process lacks to inform which pollId is scoped at source
so it relies on akka-apps to discover based on the current state of other
apps. This looks like the major problem over this polling termination issue.
Made a few changes at the running poll getter fallback at the polling stop
process. Following the premise that there is only one running poll available,
we make sure to return a valid running poll (if there's one).
Added support for getStats in screenshare's service. This works similar
to the getStats for video provider, and the information retrieved from
screenshare is added to the video information for cameras.
Add an option to set a default logo to be placed for all created meetings.
The default logo is inserted as a create meeting param for all meetings that
do not have a `logo` param defined. Two new properties were included at
bigbluebutton-web configuration:
- [Boolean] `useDefaultLogo`: enables/disables the use of the default logo
disabled as default
- [String] `defaultLogoURL`: The default logo URL to be fetched by the client
bigbluebutton logo as default
We now retrieve update information about active video peers, and calculates
download and upload rates. These rates are the sum of data transfered in
all video peers.
Screenshare stats is not being added to the sum, yet.
Setting the waiting state false as default was leaving an open gap where
the users still did not have a valid breakout room's join url and it's
join button enabled.
Change the first waiting state to true and handle the join type as the
component finishes mounting. If it's a free to choose room scenario,
dispatch the whole Promise based solution and let it manage the waiting
state as the interval checks for the URL response.
