OfficialDakari
/
matrix-dart-sdk
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

chore: update voip readme

This commit is contained in:
td 2024-04-26 20:07:20 +05:30 committed by GitHub
parent d7d5c245c1
commit 66bd16208d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
lib/src/voip/README.md
View File

@ -3,12 +3,12 @@
Supports Supports
- 1:1 webrtc calls - 1:1 webrtc calls
- Group calls with: - Group calls with:
- mesh webrtc calls - Mesh webrtc calls
- just handling state of calls and signallnig for e2ee keys in sfu mode (check `isLivekitCall`) - just handling state of calls and signallnig for e2ee keys in sfu mode f.ex (Livekit calls)
Places where we diverted from spec afaik: Places where we diverted from spec afaik:
- To enable p2p calls between devices of the same user, pass a `invitee_device_id` to the `m.call.invite` method - To enable p2p calls between devices of the same user, pass a `invitee_device_id` to the `m.call.invite` method
- **to-device call events such as in msc3401 MUST `room_id` to map the event to a room** - **to-device call events such as in msc3401 MUST have a `room_id` to map the event to a room**
## Overview ## Overview
@ -22,8 +22,6 @@ Places where we diverted from spec afaik:
All communication for group calls happens over to-device events except the `com.famedly.call.member` event. All communication for group calls happens over to-device events except the `com.famedly.call.member` event.
Sends the `com.famedly.call.member` event to signal an active membership. The format has to be the following: Sends the `com.famedly.call.member` event to signal an active membership. The format has to be the following:
### Events - ### Events -
@ -36,10 +34,11 @@ Sends the `com.famedly.call.member` event to signal an active membership. The fo
"backend": { "backend": {
"type": "mesh" "type": "mesh"
}, },
"call_id": "!qoQQTYnzXOHSdEgqQp:im.staging.famedly.de", "call_id": "",
"device_id": "YVGPEWNLDD", "device_id": "YVGPEWNLDD",
"expires_ts": 1705152401042, "expires_ts": 1705152401042,
"scope": "m.room" "scope": "m.room",
"membershipID": "gor1Gt5BCIlyrxjyHnaEJQ==",
} }
] ]
} }
@ -50,8 +49,8 @@ Sends the `com.famedly.call.member` event to signal an active membership. The fo
- **call_id**: the call id, currently setting it to the roomId makes the call for the whole room, this is to avoid parallel calls starting up. For user scoped calls in a room you could set this to `AuserId:BuserId`. The sdk does not restrict setting roomId for user scoped calls atm. - **call_id**: the call id, currently setting it to the roomId makes the call for the whole room, this is to avoid parallel calls starting up. For user scoped calls in a room you could set this to `AuserId:BuserId`. The sdk does not restrict setting roomId for user scoped calls atm.
- **device_id**: The sdk supports calling between devices of same users, so this needs to be set to the sender device id. - **device_id**: The sdk supports calling between devices of same users, so this needs to be set to the sender device id.
- **expires_ts**: ms since epoch when this membership event should be considered expired. Check `lib/src/voip/utils/constants.dart` for current values of how long the inital period is and how often this gets autoupdated. - **expires_ts**: ms since epoch when this membership event should be considered expired. Check `lib/src/voip/utils/constants.dart` for current values of how long the inital period is and how often this gets autoupdated.
- **scope**: room scoped calls are `m.room`, user scoped can be `m.user` - **scope**: room scoped calls are `m.room`, user scoped can be `m.user`.
- **membershipID**: used by mesh group calls to terminate stale calls. to-device events where sender_session_id do not match the membershipID from the state event should be ignored. Similarly existing calls with a mismatched session id should be terminated.
#### The backend can be either `mesh` or `livekit` #### The backend can be either `mesh` or `livekit`
@ -79,13 +78,10 @@ When in SFU/Livekit mode, the sdk can handle sending and requesting encryption k
- sending: `com.famedly.call.encryption_keys` - sending: `com.famedly.call.encryption_keys`
- requesting: `com.famedly.call.encryption_keys.request` - requesting: `com.famedly.call.encryption_keys.request`
As usual remember to send the `party_id`/`sender_session_id` to map your keys to the right userId and deviceId
You need to implement `EncryptionKeyProvider` and set the override the methods to interact with your actual keyProvider. The main one as of now is `onSetEncryptionKey`. You need to implement `EncryptionKeyProvider` and set the override the methods to interact with your actual keyProvider. The main one as of now is `onSetEncryptionKey`.
You can request missing keys whenever needed using `groupCall.requestEncrytionKey(remoteParticipants)`. You can request missing keys whenever needed using `groupCall.requestEncrytionKey(remoteParticipants)`.
## 1:1 calls ## 1:1 calls
### 1. Basic call flow ### 1. Basic call flow
@ -260,4 +256,4 @@ When the media stream changes, we can change the UI display according to the pri
Short note on a difference between canHandleNewCall and glare stuff - Short note on a difference between canHandleNewCall and glare stuff -
- canHandleNewCall should be set to false only if the client can see a connected call. This prevents any other user's call and fires a handleMissedCall. - canHandleNewCall should be set to false only if the client can see a connected call. This prevents any other user's call and fires a handleMissedCall.
- glare stuff on the other hand tries to handle collision of invites, if both clients get a invite from one another at the same time, one of the invites should be discarded. (Ideally the other one should be answered by default, but for now we just decided to let it ring to avoid unexpected answers.) - glare stuff on the other hand tries to handle collision of invites, if both clients get a invite from one another at the same time, one of the invites should be discarded. (Ideally the other one should be answered by default, but for now we just decided to let it ring to avoid unexpected answers.)