Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4075: MatrixRTC Call Ringing #4075

Open
wants to merge 12 commits into
base: main
Choose a base branch
from
Open

Conversation

toger5
Copy link

@toger5 toger5 commented Nov 8, 2023

Rendered

To-do:

  • How do you decline a call?
  • Implementations using revised format from 04635eb (#4075)
  • This looks very similar to m.call.invite but with much less info. Have we taken into account learnings from this existing capability?

Dependencies:

Implementations:

Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
@turt2live turt2live changed the title MatrixRTC Call Ringing MSC4075: MatrixRTC Call Ringing Nov 8, 2023
@turt2live turt2live added voip proposal A matrix spec change proposal kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Nov 8, 2023
Signed-off-by: Timo K <toger5@hotmail.de>
proposals/4075-call-notify-event.md Show resolved Hide resolved
proposals/4075-call-notify-event.md Outdated Show resolved Hide resolved
proposals/4075-call-notify-event.md Show resolved Hide resolved
Signed-off-by: Timo K <toger5@hotmail.de>
toger5 added a commit to toger5/ruma that referenced this pull request Nov 22, 2023
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075)

Signed-off-by: Timo K <toger5@hotmail.de>
toger5 added a commit to toger5/ruma that referenced this pull request Nov 22, 2023
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075)

Signed-off-by: Timo K <toger5@hotmail.de>
toger5 added a commit to toger5/ruma that referenced this pull request Nov 24, 2023
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075)

Signed-off-by: Timo K <toger5@hotmail.de>
toger5 added a commit to toger5/ruma that referenced this pull request Nov 24, 2023
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075)

Signed-off-by: Timo K <toger5@hotmail.de>
toger5 added a commit to toger5/ruma that referenced this pull request Nov 24, 2023
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075)

Signed-off-by: Timo K <toger5@hotmail.de>
toger5 added a commit to toger5/ruma that referenced this pull request Nov 24, 2023
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075)

Signed-off-by: Timo K <toger5@hotmail.de>
@uhoreg
Copy link
Member

uhoreg commented Jan 24, 2024

@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
Copy link
Author

toger5 commented Jan 24, 2024

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.

Signed-off-by: Timo K <toger5@hotmail.de>

### Explicitly unspecified conditions

- The duration of the ring sound is a deliberately chosen

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Signed-off-by: Timo K <toger5@hotmail.de>
@ara4n ara4n mentioned this pull request Nov 25, 2024
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal voip
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants