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