Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3077: Support for multi-stream VoIP #3077

Merged
merged 19 commits into from
Jun 20, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
111 changes: 111 additions & 0 deletions proposals/3077-multi-stream-voip.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,111 @@
# MSC3077: Support for multi-stream VoIP

This MSC proposes a method for differentiating WebRTC streams from each other.

[MSC2746](https://github.com/matrix-org/matrix-doc/pull/2746) has improved VoIP
immeasurably. Yet, there is still no clear way to handle things such as
screen-sharing.

Simple VoIP calls only ever feature one stream, though often clients will want
to send multiple - usermedia, screensharing and possibly more. In a situation
with more streams, it can be very helpful to provide the other side with
metadata about the content of the streams.

## Proposal

This MSC proposes adding an `sdp_stream_metadata` field to the events containing
a session description i.e.:

+ [`m.call.invite`](https://spec.matrix.org/v1.7/client-server-api/#mcallinvite)
+ [`m.call.answer`](https://spec.matrix.org/v1.7/client-server-api/#mcallanswer)
+ [`m.call.negotiate`](https://spec.matrix.org/v1.7/client-server-api/#mcallnegotiate)

The `sdp_stream_metadata` field is an object in which each key is one stream
`id` in the session description. The values are objects with the
following fields:

+ `purpose` - a string indicating the purpose of the stream. For compatibility
dbkr marked this conversation as resolved.
Show resolved Hide resolved
between client the following values are defined:
+ `m.usermedia` - stream that contains the webcam and/or microphone tracks
+ `m.screenshare` - stream with the screen-sharing tracks

### Example

```JSON
{
"type": "m.call.invite",
"room_id": "!roomId",
"content": {
"call_id": "1414213562373095",
"invitee": "@bob:matrix.org",
"party_id": "1732050807568877",
"lifetime": "60000",
"capabilities": {
"m.call.transferee": true,
},
"offer": {
"sdp": "...",
"type": "offer",
},
"sdp_stream_metadata": {
"271828182845": {
"purpose": "m.screenshare",
},
"314159265358": {
"purpose": "m.usermedia",
},
},
"version": "1",
},
}
```

### Edge cases

+ 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.
SimonBrandner marked this conversation as resolved.
Show resolved Hide resolved

### Backwards compatibility

During the initial invite and answer exchange clients find out if the field
`sdp_stream_metadata` is missing. 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).

## Alternatives

Setting the stream `id`s to custom values had been considered. Though this is
possible on some platforms, it is not in browsers. That is because the `id`
property of `MediaStream` is _read-only_ as the [MDN Documentation
states](https://developer.mozilla.org/en-US/docs/Web/API/MediaStream/id).
Similar is true for SDP attributes.

This proposal is also more practical for cases where more complex metadata is
needed. For conferencing, a `user_id` field could be added to
the objects in `sdp_stream_metadata`; for differentiating between the front and rear camera of a
phone, a `camera_type` field could be added.

Previously, it has been thought that the `purpose` field has to be unique (or
another unique field has to be added), though this could only ever be important
if we wanted to replace a stream with another one in-place. It was deemed as a
rather uncommon thing for which there doesn't seem to be any use-case, so
uniqueness is not required.

## Unstable prefix

During development, the following fields should be used:

|Release |Development |
|----------------------------|-----------------------------------------------|
|`sdp_stream_metadata` |`org.matrix.msc3077.sdp_stream_metadata` |
|`m.call.sdp_stream_metadata`|`org.matrix.msc3077.call.sdp_stream_metadata` |

## Potential issues

None that I can think of.

## Security considerations
SimonBrandner marked this conversation as resolved.
Show resolved Hide resolved

None that I can think of.