Does a thirdparty protocol lookup to the homeserver to get the
corresponding native/virtual user for a matrix ID. Stores the
mappings in room account data. Involves some slightly nasty workarounds
for that fact that room account data has no local echo.
If your homeserver is configured with an experiment `widget_build_url`, this
will take over the functionality of the call buttons and turn them into a
general widget installer.
First attempt at this was sending everything from
RTCPeerConnection.getStats() as a separate item in the rageshake,
but the rageshake server doesn't handle that in a particularly sensible
way and it's probably better to pick & choose what data we want explicitly
from a privacy PoV. This summarises the candidates used for the calls into
the log that will be included in rageshakes so we can diagnose connectivity
issues from rageshakes.
Requires https://github.com/matrix-org/matrix-js-sdk/pull/1584
The accompanying element-web PR with the config documentation should
explain what this is & why. Internally, this breaks the assumption
that call.roomId is the room that the call appears in for the user.
call.roomId may now be a 'virtual' room while the react SDK actually
displays it in a different room. React SDK always stores the calls
under the user-facing rooms, and provides a function to get the
user-facing room for a given call.
Queries the homeserver for PSTN protocol support, and if found,
the add-room button on the DM rooms list section opens a context
menu instead with a 'dial pad' option as well as the current 'start chat'
dialog. Entering a number into this and pressing dial performs
a thirdparty user query for the given string and starts a DM with that
user.
Currently just by adding /holdcall and /unholdcall slash commands
The only place the hold status of the call is currently represented
is when the call is a voice call and you're viewing a different room:
it's not wired up when you're viewing the room because that currently
uses the room status bar which it won't do with the new UI.
Also convert VideoFeed to typescript, and remove videoview because
it essentially just managed the fullscreen functionality, but we'll
want and 'on hold' representation (and probably chrome for hagnup etc)
in the fullscreen UI too, so let's just make CallView the thing that
gets fullscreened.
David Baker