@@ -174,16 +174,34 @@ In response to an incoming invite, a client may do one of several things:
174174Clients may send more than one stream in a VoIP call. The streams should be
175175differentiated by including metadata in the [ ` m.call.invite ` ] ( /client-server-api/#mcallinvite ) ,
176176[ ` m.call.answer ` ] ( /client-server-api/#mcallanswer ) and [ ` m.call.negotiate ` ] ( /client-server-api/#mcallnegotiate )
177- events, using the ` sdp_stream_metadata ` property.
177+ events, using the ` sdp_stream_metadata ` property. An [ ` m.call.sdp_stream_metadata_changed ` ] ( /client-server-api/#mcallsdp_stream_metadata_changed )
178+ event can be sent when the metadata changes but no negotiation is required.
178179
179180` sdp_stream_metadata ` maps from the ` id ` of a stream in the session description,
180- to metadata about that stream. Currently only one property is defined for the
181- metadata. This is ` purpose ` , which should be a string indicating the purpose of
182- the stream. The following ` purpose ` s are defined:
181+ to metadata about that stream. Currently three properties are defined for the
182+ metadata: ` purpose ` , ` audio_muted ` and ` video_muted ` .
183+
184+ ` purpose ` should be a string indicating the purpose of the stream. The following
185+ ` purpose ` s are defined:
183186
184187* ` m.usermedia ` - stream that contains the webcam and/or microphone tracks
185188* ` m.screenshare ` - stream with the screen-sharing tracks
186189
190+ ` audio_muted ` and ` video_muted ` are booleans that indicate whether the audio and
191+ video tracks in the stream are muted, respectively. All tracks should be assumed
192+ unmuted unless specified otherwise.
193+
194+ Clients are recommended to not mute the audio of WebRTC tracks locally when an
195+ incoming stream has the ` audio_muted ` field set to ` true ` . This is because when
196+ the other user unmutes themselves, there may be a slight delay between their
197+ client sending audio and the [ ` m.call.sdp_stream_metadata_changed ` ] ( /client-server-api/#mcallsdp_stream_metadata_changed )
198+ event arriving and any audio sent in between will not be heard. The other user
199+ will still stop transmitting audio once they mute on their side, so no audio is
200+ sent without the user's knowledge.
201+
202+ The same suggestion does not apply to ` video_muted ` . Clients _ should_ mute video
203+ locally, so that the receiving side doesn't see a black video.
204+
187205If ` sdp_stream_metadata ` is present and an incoming stream is not listed in it,
188206the stream should be ignored. If a stream has a ` purpose ` of an unknown type, it
189207should also be ignored.
0 commit comments