MSC4075: MatrixRTC Call Ringing

[toger5]

Rendered

Implementations:
ElementWeb sending rings: matrix-org/matrix-react-sdk#11870
ElementWeb ringing: matrix-org/matrix-react-sdk#11870

Ruma notify event support: ruma/ruma#1704

ElementX android sending rings: TODO
ElementX android ringing: TODO

ElementX ios sending rings: TODO
ElementX ios ringing: TODO

[uhoreg]

@toger5 You've added some implementations in the PR description. Do these implement the MSC in full, or are there parts of the MSC that are still lacking implementation?

[toger5]

Yes it's implemented in full. At least on the platforms shown in the description (EW).

There are optional configurations that are still missing. (Allowing to send a notification to a specific subset of users) but the API for this is already part of the SDK. There is no ui for this however and we are not sure we want that in EW.

[giomfo]

@toger5 is this m.call.notify event encrypted when it is sent in an encrypted room?
I think it is, so the Push notification could not be filtered server side. The notification will be filtered locally by the client.
Note: If this event is encrypted, the call notification may have some trouble in encrypted mentions-only rooms, like it is described in
MSC3996: Encrypted mentions-only rooms. Indeed the encrypted event will not be pushed by the server in that case.

[toger5]

That is good to know. I am wondering if a @room notify event should be unencrypted in that case. This would sacrifice privacy but make it more reliable.
If this is transparent to the user that could be acceptable maybe.

[toger5]

Thanks for also linking MSC3996.

[toger5]

I added a Limitations and recommendations section so this is explicitly mentioned.

[td-famedly]

Instead of hardcoding 10 seconds, I am assuming the clients could probably just look at the lifetime field for the invite event mapped to call_id from the notify event.

[toger5]

Which invite event are you referring to? The general idea is to allow the receiver to choose a ring duration and not the sender.
So reading from any event would result in someone else choosing how long you device should ring.

[td-famedly]

The general idea is to allow the receiver to choose a ring duration and not the sender.

To me that sounds a bit counter intuitive, f.ex I would not want to stop ringing the device after 10 seconds if the m.call.invite lifetime was 60 seconds and I can still pick up the call. Or does the "stop ringing after 10 seconds" also automatically send a reject then? (might be out of scope for this PR)

[toger5]

This is independent of the legacy call invite event. It is just what we use for matrix RTC sessions where there is no enforced call buildup procedure. (You just post your state event)
So most likely there is no call.invite event which lifetime could be used. The call notify event is the one that could include a lifetime. But we decided against that as described in the msc and the comment above.
It's also a slightly different semantic since the calling participant can stay in the call for however long they desire. Where a call invite has a Lifetime.