Rework paragraph

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

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.