Subject: [rtcweb] Proposal for using RID-based simulcast SDP in JSEP

From: Peter Thatcher <[email-masked]>
Date: Thu, 5 Nov 2015 16:02:58 +0900

I propose we update JSEP to include the use of RID-based simulcast in the
following way:

1.  createOffer will include a "a=rid:$RID send" line for each of the RIDs
provided in PeerConnection.addTransceiver's "sendEncodings" field and one
"a=simulcast send" line referencing all those RIDs.  The RID lines will
contain all of the constraints that the browser supports.  Browsers SHOULD
support max-br, but none of the constraints are mandatory to implement.
Obviously if sendEncodings isn't present, then none of this is included.

2.  setLocalDescription with such an offer and then a setRemoteDescription
with an answer will cause the encodings in
RtpSender.getParameters().encodings to contain an encoding for each of the
matching "a=rid:$RID recv" lines contained in the answer.  If the RID line
constraints any of the supported constraints, they will be reflected in the
RtpEncodingParameters.  Browsers SHOULD map max-br to
RtpEncodingParameters.maxBitrate.  If "a=simulcast" is not present in the
answer, one encoding will be present in the encodings, with no constraints
set.

3.  createAnswer responding to an offer with simulcast will respond with an
"a=rid:$RID send" line for each of the "a=rid:$RID send" lines in the offer
that the browser supports.  If the browser does not support one of the
constraints, such as max-width, max-height, or pt, then the browser will
remove the rid line from the answer.

4.  setLocalDescription with such an answer will cause the encodings in
RtpSender.getParameters().encodings to to contain an encoding for each of
the matching "a=rid:$RID recv" lines contained in the answer.  If the RID
line constraints any of the supported constraints, they will be reflected
in the RtpEncodingParameters.  Browsers SHOULD map max-br to
RtpEncodingParameters.maxBitrate

5.  If an answer in setRemoteDescription constraints a RID beyond what the
browser supports, then the browser can reject the remote description.  For
example, if the browser does not support pt constraints, and the remote
answer constrains the PT, the browser can reject the call to
setRemoteDescription.

Here is an example of an offer from a browser:

pc.addTransceiver("video", {sendEncodings: [{rid: "A"}, {rid: "B"}, {rid:
"C"}]});
pc.createOffer();

m=video ...
...
a=rid:A send max-br
a=rid:B send max-br
a=rid:C send max-br
a=simulcast:send rid=A,B,C

And and answer from an MCU:

m=video ...
...
a=rid:A recv max-br=1000000
a=rid:B recv max-br=500000
a=rid:C recv max-br=200000
a=simulcast:recv rid=A,B,C

And the encodings seen by the Javascript:

sender.getParameters().encodings === [
  {rid: "A", maxBitrate: 1000000},
  {rid: "B", maxBitrate: 500000},
  {rid: "C", maxBitrate: 200000}
];

And here is an example of an offer from an MCU:

m=video...
...
a=rid:A recv
a=rid:B recv
a=rid:C recv max-goats=42
a=simulcast:recv rid=A,B,C

And the answer from a call to PeerConnection.createAnswer:

pc.createAnswer();

m=video...
...
a=rid:A send
a=rid:B send
a=simulcast:recv rid=A.B

And the encodings seen by the Javascript:

sender.getParameters().encodings === [
  {rid: "A"},
  {rid: "B"},
  {rid: "C"}
];

Notice that C was dropped because the browser doesn't support max-goats.

And, finally if the browser offers this:

m=video...
...
a=rid:A send
a=rid:B send
a=rid:C send
a=simulcast:send rid=A,B,C

And the MCU answers with this:

m=video...
...
a=rid:A recv
a=rid:B recv
a=rid:C recv max-goats=42
a=simulcast:recv rid=A,B,C

or this:

m=video...
...
a=rid:A recv
a=rid:B recv
a=rid:C recv pt=42
a=simulcast:recv rid=A,B,C

And the browser doesn't support max-goats= or pt=, then the browser can
reject the answer from the call to setRemoteDescription.