-
Notifications
You must be signed in to change notification settings - Fork 384
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
@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? |
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>
proposals/4075-call-notify-event.md
Outdated
|
||
### Explicitly unspecified conditions | ||
|
||
- The duration of the ring sound is a deliberately chosen |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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>
Rendered
To-do:
04635eb
(#4075)Dependencies:
Implementations: