Apply suggestions on VoIP module

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This commit is contained in:
Kévin Commaille 2024-02-28 21:47:51 +01:00
parent 83b3c676f3
commit 8ce2b946ab
No known key found for this signature in database
GPG key ID: 29A48C1F03620416

View file

@ -172,16 +172,17 @@ 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. Metadata can be included in
the `m.call.invite`, `m.call.answer` and `m.call.negotiate` events to describe the the [`m.call.invite`](/client-server-api/#mcallinvite), [`m.call.answer`](/client-server-api/#mcallanswer)
streams being sent. This is the `sdp_stream_metadata` field. and [`m.call.negotiate`](/client-server-api/#mcallnegotiate) events to describe
the streams being sent, using the `sdp_stream_metadata` property.
This field is an object in which each key is one stream `id` in the session `sdp_stream_metadata` maps from the `id` of a stream in the session description,
description. The values are objects with the following fields: 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:
* `purpose` - a string indicating the purpose of the stream. For compatibility * `m.usermedia` - stream that contains the webcam and/or microphone tracks
between client the following values are defined: * `m.screenshare` - stream with the screen-sharing tracks
* `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 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 `sdp_stream_metadata` is present, the stream should be ignored. If a stream has
@ -193,12 +194,11 @@ that in the JavaScript WebRTC API, this means `addTrack()` must be passed two
parameters: a track and a stream, not just a track, and in a video call the parameters: a track and a stream, not just a track, and in a video call the
stream must be the same for both audio and video track. stream must be the same for both audio and video track.
During the initial invite and answer exchange clients find out if the field For backwards compatibility, if `sdp_stream_metadata` is not present in the
`sdp_stream_metadata` is missing. For backwards compatibility if it is not initial [`m.call.invite`](/client-server-api/#mcallinvite) or [`m.call.answer`](/client-server-api/#mcallanswer)
present in the event sent by the opponent, the client should ignore any new event sent by the other party, the client should ignore any new incoming streams
incoming streams (i.e. it should use the first one) and it shouldn't send more (i.e. it should use the first one) and it shouldn't send more than one stream
than one stream (i.e. clients cannot send a video feed and a screenshare at the (i.e. clients cannot send a video feed and a screenshare at the same time).
same time, as is the case in current clients).
##### Invitees ##### Invitees
The `invitee` field should be added whenever the call is intended for one The `invitee` field should be added whenever the call is intended for one