MSC2747: VoIP call transfers #2747
Conversation
|
No implementation exists yet: submitting for early review in advance of starting impl. |
turt2live
added
kind:feature
| It continues to do so until the original call has either been replaced by the new call or the | ||
| replacement has failed. | ||
| * If the replace event has a `target_room` specified and the user is not already in the specified | ||
| room, it waits for an invite to that room to arrive, then accepts the invite. Once in the room, |
There was a problem hiding this comment.
What happens if the invite never arrives (e.g. federation/networking/implementation bug)? Should we specify a lifetime in m.call.replaces as well or should we just advise clients to stop waiting after a "reasonable" amount of time?
There was a problem hiding this comment.
Hmm - a lifetime field feels more like the time that specific event is valid for (eg. if an invite exceeds its lifetime after you've sent an answer but before the call's connected, you'd continue with the call). Feels OK to let clients decide how long to wait, although we might need to add a way for the transferee to say, "I tried, but it didn't work".
Variety of typo fixes & clarifications Co-authored-by: Brendan Abolivier <babolivier@matrix.org>
| a normal incoming call from the transferor rather than being presented as a call to the | ||
| transfer target. | ||
|
|
||
| Consideration was given to using a more generic event to refer conversations in general |
There was a problem hiding this comment.
"Breakout rooms" are becoming a more and more requested feature thanks to COVID and how useful they are in Zoom and BBB. I continue to wonder if it would be better to have a generic "please take this room somewhere else" mechanism rather than having it VoIP specific. What are the specific VoIP semantics that justify making this VoIP specific?
There was a problem hiding this comment.
Mostly that we specify call IDs for the call to create or wait for, plus party IDs.
Sends an m.call.replaces event and flag for whether to advertise support. MSC2747 (matrix-org/matrix-spec-proposals#2747)
Adapt the InviteDialog to select a transfer target Doesn't support supplying a roo mID fr the transfer: just leaves the transferee to work out how to contact the target themselves. MSC2747 (matrix-org/matrix-spec-proposals#2747) Requires matrix-org/matrix-js-sdk#1558
Co-authored-by: Brendan Abolivier <babolivier@matrix.org>
| * `target_room`: Optional. If specified, the transferee client waits for an invite | ||
| to this room and joins it (possibly waiting for user confirmation) and then continues | ||
| the transfer in this room. If absent, the transferee contacts the Matrix User ID | ||
| given in the `target_user` field in a room of its choosing. |
There was a problem hiding this comment.
A room may not always be joinable by ID, i.e. if the room was created on a server, that doesn't exist anymore. In general, I don't think you should join a room by the server part from the ID. I suggest adding an additional via field here, so that the room will be joined via one of the servers in that list. You should probably put the server of the target user there. Alternatively, the server to join via could be extracted from the target users mxid.
If this is not present and the users don't share a room, should a new one be created? Then you probably need to wait for them to join the room to send the call events?
There was a problem hiding this comment.
Yep - hence them having to wait for an invite to the room. There shouldn't be any need to wait for them to join the room before calling: in fact in future we'll probably need to include metadata in the invite to say the inviter is trying to call, so the invitee has some way of knowing someone's trying to call them, which right now they don't.
There was a problem hiding this comment.
Oh, right, I missed that part, my bad, sorry about the noise :D
turt2live
moved this from Awaiting SCT input
to Temp column 001
in Spec Core Team Backlog
turt2live
added
the
needs-implementation
Defines a mechanism for transferring a party in a VoIP call to a different party.
Rendered