From 02706b56cc34bd7e5e12d836d5faa8e418dfcd84 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vin=20Commaille?= Date: Wed, 13 Mar 2024 10:50:35 +0100 Subject: [PATCH] Rework paragraph MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Kévin Commaille --- .../client-server-api/modules/voip_events.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/client-server-api/modules/voip_events.md b/content/client-server-api/modules/voip_events.md index a95f94f5..4df0ba13 100644 --- a/content/client-server-api/modules/voip_events.md +++ b/content/client-server-api/modules/voip_events.md @@ -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.