mirror of
https://git.anonymousland.org/anonymousland/synapse.git
synced 2025-08-01 19:46:09 -04:00
Merge branch 'develop' of github.com:matrix-org/synapse into registration-api-changes
This commit is contained in:
commit
bf6fa6dd3d
73 changed files with 8192 additions and 3952 deletions
|
@ -1182,16 +1182,16 @@ This event is sent by the caller when they wish to establish a call.
|
|||
- ``type`` : "string" - The type of session description, in this case 'offer'
|
||||
- ``sdp`` : "string" - The SDP text of the session description
|
||||
|
||||
``m.call.candidate``
|
||||
``m.call.candidates``
|
||||
This event is sent by callers after sending an invite and by the callee after answering.
|
||||
Its purpose is to give the other party an additional ICE candidate to try using to
|
||||
Its purpose is to give the other party additional ICE candidates to try using to
|
||||
communicate.
|
||||
|
||||
Required keys:
|
||||
- ``call_id`` : "string" - The ID of the call this event relates to
|
||||
- ``version`` : "integer" - The version of the VoIP specification this messages
|
||||
adheres to. his specification is version 0.
|
||||
- ``candidate`` : "candidate object" - Object describing the candidate.
|
||||
- ``candidates`` : "array of candidate objects" - Array of object describing the candidates.
|
||||
|
||||
``Candidate Object``
|
||||
|
||||
|
@ -1249,7 +1249,33 @@ Or a rejected call:
|
|||
<------- m.call.hangup
|
||||
|
||||
Calls are negotiated according to the WebRTC specification.
|
||||
|
||||
|
||||
|
||||
Glare
|
||||
-----
|
||||
This specification aims to address the problem of two users calling each other
|
||||
at roughly the same time and their invites crossing on the wire. It is a far
|
||||
better experience for the users if their calls are connected if it is clear
|
||||
that their intention is to set up a call with one another.
|
||||
|
||||
In Matrix, calls are to rooms rather than users (even if those rooms may only
|
||||
contain one other user) so we consider calls which are to the same room.
|
||||
|
||||
The rules for dealing with such a situation are as follows:
|
||||
|
||||
- If an invite to a room is received whilst the client is preparing to send an
|
||||
invite to the same room, the client should cancel its outgoing call and
|
||||
instead automatically accept the incoming call on behalf of the user.
|
||||
- If an invite to a room is received after the client has sent an invite to the
|
||||
same room and is waiting for a response, the client should perform a
|
||||
lexicographical comparison of the call IDs of the two calls and use the
|
||||
lesser of the two calls, aborting the greater. If the incoming call is the
|
||||
lesser, the client should accept this call on behalf of the user.
|
||||
|
||||
The call setup should appear seamless to the user as if they had simply placed
|
||||
a call and the other party had accepted. Thusly, any media stream that had been
|
||||
setup for use on a call should be transferred and used for the call that
|
||||
replaces it.
|
||||
|
||||
Profiles
|
||||
========
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue