|
|
@ -171,18 +171,34 @@ In response to an incoming invite, a client may do one of several things:
|
|
|
|
|
|
|
|
|
|
|
|
##### Streams
|
|
|
|
##### Streams
|
|
|
|
|
|
|
|
|
|
|
|
Clients are expected to send one stream with one track of kind `audio` (creating a
|
|
|
|
Clients may send more than one stream in a VoIP call. Metadata can be included in
|
|
|
|
voice call). They can optionally send a second track in the same stream of kind
|
|
|
|
the `m.call.invite`, `m.call.answer` and `m.call.negotiate` events to describe the
|
|
|
|
`video` (creating a video call).
|
|
|
|
streams being sent. This is the `sdp_stream_metadata` field.
|
|
|
|
|
|
|
|
|
|
|
|
Clients implementing this specification use the first stream and will ignore
|
|
|
|
This field is an object in which each key is one stream `id` in the session
|
|
|
|
any streamless tracks. Note that in the JavaScript WebRTC API, this means
|
|
|
|
description. The values are objects with the following fields:
|
|
|
|
`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
|
|
|
|
* `purpose` - a string indicating the purpose of the stream. For compatibility
|
|
|
|
track.
|
|
|
|
between client the following values are defined:
|
|
|
|
|
|
|
|
* `m.usermedia` - stream that contains the webcam and/or microphone tracks
|
|
|
|
A client may send other streams and tracks but the behaviour of the other party
|
|
|
|
* `m.screenshare` - stream with the screen-sharing tracks
|
|
|
|
with respect to presenting such streams and tracks is undefined.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
During the initial invite and answer exchange clients find out if the field
|
|
|
|
|
|
|
|
`sdp_stream_metadata` is missing. For backwards compatibility if it is not
|
|
|
|
|
|
|
|
present in the event sent by the opponent, 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, 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
|
|
|
|