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.
Use the 'reject' method when we want to reject an incoming call
rather than end one that's in progress. Also get our error messages
right for the other side rejecting the call (albeit still with
placeholder dialog-box UX).
Requires https://github.com/matrix-org/matrix-js-sdk/pull/1510
The js-sdk supports glare but we didn't support it, which means the
js-sdk will still do glare but we didn't know about it, leaving the
UI in horribly broken states where the js-sdk would be on a call but
the app didn't think it was.
Fixes https://github.com/vector-im/element-web/issues/5770
* Remove the two separate enumerations of call state: now everything
uses the js-sdk version of call state. Stop adding a separate
'call_state' field onto the call object(!)
* Better reflection of the actual state of the call in the call bar,
so when it's connecting, it says connecting, and only says 'active call'
when the call is actually active.
* More typey goodness
and remove the old conference call stuff while we're at it: enough
time should have passed since those mistakes that we can move on.
The old conference call rooms will still appear for anyone whose
account dates back to that time, but they've presumably been appearing
in any other matrix client they used too.
