Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-23 11:34:09 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Rework paragraph

Browse source 
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This commit is contained in:
Kévin Commaille 2024-03-13 10:50:35 +01:00
parent 671685e330
commit 02706b56cc
No known key found for this signature in database
GPG key ID: 29A48C1F03620416
1 changed files with 12 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
content/client-server-api/modules/voip_events.md
View file

@ -171,29 +171,29 @@ In response to an incoming invite, a client may do one of several things:
##### Streams
Clients may send more than one stream in a VoIP call. Metadata can be included in
the [`m.call.invite`](/client-server-api/#mcallinvite), [`m.call.answer`](/client-server-api/#mcallanswer)
and [`m.call.negotiate`](/client-server-api/#mcallnegotiate) events to describe
the streams being sent, using the `sdp_stream_metadata` property.
Clients may send more than one stream in a VoIP call. The streams should be
differentiated by including metadata in the [`m.call.invite`](/client-server-api/#mcallinvite),
[`m.call.answer`](/client-server-api/#mcallanswer) and [`m.call.negotiate`](/client-server-api/#mcallnegotiate)
events, using the `sdp_stream_metadata` property.
`sdp_stream_metadata` maps from the `id` of a stream in the session description,
to metadata about that stream. Currently only one property is defined for the
to metadata about that stream. Currently only one property is defined for the
metadata. This is `purpose`, which should be a string indicating the purpose of
the stream. The following `purpose`s are defined:
* `m.usermedia` - stream that contains the webcam and/or microphone tracks
* `m.screenshare` - stream with the screen-sharing tracks
If an incoming stream is not described in `sdp_stream_metadata` and
`sdp_stream_metadata` is present, the stream should be ignored. If a stream has
a `purpose` of an unknown type (i.e. not `m.usermedia` or `m.screenshare`), it
should be ignored.
If `sdp_stream_metadata` is present and an incoming stream is not listed in it,
the stream should be ignored. If a stream has a `purpose` of an unknown type, it
should also be ignored.
For backwards compatibility, if `sdp_stream_metadata` is not present in the
initial [`m.call.invite`](/client-server-api/#mcallinvite) or [`m.call.answer`](/client-server-api/#mcallanswer)
event sent by the other party, the client should ignore any new incoming streams
(i.e. it should use the first one) and it shouldn't send more than one stream
(i.e. clients cannot send a video feed and a screenshare at the same time).
event sent by the other party, the client should assume that this property is
not supported by the other party. It means that multiple streams cannot be
differentiated: the client should only use the first incoming stream and
shouldn't send more than one stream.
Clients implementing this specification should ignore any streamless tracks.