From 671685e33009b174f668c5194c0fa33e07dab0e7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vin=20Commaille?= Date: Wed, 13 Mar 2024 10:32:28 +0100 Subject: [PATCH] Rework paragraph about streamless tracks and move to the end MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Kévin Commaille --- content/client-server-api/modules/voip_events.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/content/client-server-api/modules/voip_events.md b/content/client-server-api/modules/voip_events.md index 1e4c3db7..a95f94f5 100644 --- a/content/client-server-api/modules/voip_events.md +++ b/content/client-server-api/modules/voip_events.md @@ -189,17 +189,14 @@ If an incoming stream is not described in `sdp_stream_metadata` and a `purpose` of an unknown type (i.e. not `m.usermedia` or `m.screenshare`), it should be ignored. -Clients implementing this specification will ignore any streamless tracks. Note -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 -stream must be the same for both audio and video track. - 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). +Clients implementing this specification should ignore any streamless tracks. + ##### Invitees The `invitee` field should be added whenever the call is intended for one specific user, and should be set to the Matrix user ID of that user. Invites