-
Notifications
You must be signed in to change notification settings - Fork 497
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
Tab for list of calls with bridged users #5782
Comments
The design aspect part needs support and implementation in the SDK: matrix-org/matrix-ios-sdk#1396 |
Updated description with video: |
I think this is a really interesting idea, thanks! We'll need for the voip and design teams to consider this proposal strategically so I'm removing my assignment from this issue. |
Some thoughts on how to implement this, as i'm reading it; For this feature (together with matrix-org/matrix-ios-sdk#1396), there likely needs to be specification support detailing PSTN voip bridging, to make clients such as element ios handle these types of calls properly. This would need to be handled as a specification proposal. Next to that, I'd say that MSC3401 is relevant here, but that the voip bridging room is also of interest to this feature. I'd also like to personally note that iOS itself has a native "calls" app, which lists historical calls itself, it may be worth exploring a way to expose matrix-bridged-PSTN natively to iOS, to have it take advantage of contacts cross-referencing on the system side, if possible. It could also be possible to leave historical calls entirely to the calls app, and focus on improving that instead. |
Thanks for your thoughts on it. Searching through MSCs i found matrix-org/matrix-spec-proposals#1840, which would actually allow to implement the call list based on the room type. Can i ask what is the state of MSC1840? It seems not to be progressing at the time. For the native "calls" app we have tried different things, but ultimately have two remaining issues: one is the consistency in behavior is not satisfied: in some cases it is not possible to start calls through the matrix client from the native call list. And the other is that we d like to present one place or "app" to have everything ready for the user; chats, contacts, calls in one place. |
Your use case
In an environment where the user has the ability to start outgoing calls or receive incoming calls from a non-matrix network from non-matrix users (typically Numbers from a PSTN network) via a bridge device, it is beneficial to separate the rooms created with these bridged users in its own list of calls. This is because the available interactions with these non-matrix users are different than with matrix-users and the management of direct contacts is kept simple by not having them polluted by this kind of rooms.
This list of calls should be shown depending of the availability of a PSTN bridge.
Design aspects:
As the PSTN bridge creates a matrix user as a proxy for each PSTN number, it would be needed to distinguish this kind of special matrix user from a normal matrix user. Based on the presence of such a special matrix user within a room, the room itself can then be considered a "call" room to be presented in the call list and be excluded from being presented in the list of direct rooms or group rooms.
Created a video for demonstration purpose:
(https://aarenet-my.sharepoint.com/:v:/p/simon_wiedmer/ERSzUmOQMTRPhFjJfvFndxIBh_NBh2PBogLvOzCfPMHgRA?e=GrQwRb)
The text was updated successfully, but these errors were encountered: