Interface JoinSessionConfig

The minimum delay (in milliseconds) after which we will retry sending the membership event if it failed to send.

The jitter (in milliseconds) which is added to callMemberEventRetryDelayMinimum before retrying sending the membership event. e.g. if this is set to 1000, then a random delay of between 0 and 1000 milliseconds will be added.

The delay (in milliseconds) after a member leaves before we create and publish a new key, because people tend to leave calls at the same time.

If true, generate and share a media key for this participant, and emit MatrixRTCSessionEvent.EncryptionKeyChanged when media keys for other participants become available.

The period (in milliseconds) with which we check that our membership event still exists on the server. If it is not found we create it again.

The timeout (in milliseconds) after we joined the call, that our membership should expire unless we have explicitly updated it.

The period (in milliseconds) that the client will send membership keep-alives to the server.

The timeout (in milliseconds) after which the server will consider the membership to have expired if it has not received a keep-alive from the client.

The minimum time (in milliseconds) between each attempt to send encryption key(s). e.g. if this is set to 1000, then we will send at most one key event every second.

The delay (in milliseconds) between creating and sending a new key and starting to encrypt with it. This gives other a chance to receive the new key to minimise the chance they don't get media they can't decrypt. The total time between a member leaving and the call switching to new keys is therefore: makeKeyDelay + useKeyDelay

Lets you configure how the events for the session are formatted.

• legacy: use one event with a membership array.
• MSC4143: use one event per membership (with only one membership per event) More details can be found in MSC4143 and by checking the types: CallMembershipDataLegacy and SessionMembershipData