W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2017

Enabling simulcast in the answer

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 14 Apr 2017 12:57:11 +0200
Message-ID: <CALiegfkTr3kwqFNmmUSeZ5oB2v+y-_AO0D7tL+irMto_=haSmw@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,

Assuming the browser receives an SDP offer with a m=video section that
invites the browser to send simulcast:

  a=rid:1 recv
  a=rid:2 recv
  a=simulcast: recv rid=1;2

>From previous discussions I understand that, if the browser wishes to
honor the simulcast "invitation", it must create a new Transceiver and
fill `sendEncodings` parameters with the EXACT RID values given in the
offer. This is, something that would generate the following stuff in
the SDP answer (within the same m= section):

  a=rid:1 send
  a=rid:2 send
  a=simulcast: send rid=1;2


The first "problem" here is obvious: the JS app must "parse" the
received SDP offer in order to figure out the offered simulcast stuff
(offered RID values and directions).

What would happen if the JS app incorrectly sets the `sendEncodings`
with, for example, RID values not present in the received offer?


Here the second problem: After the first SDP O/A (in which the browser
successfully enabled sending simulcast) the remote sends a new SDP
re-offer with some simulcast related params modified, for example:

  a=rid:1 recv
  a=rid:4 recv
  a=simulcast: recv rid=1;4

(RID 2 was was removed and RID 4 was added).

What should do the JS in this case? and what would happen if it does
nothing but just call setRemoteDescription() + createAnswer() +
setLocalDescription()?



-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Friday, 14 April 2017 10:58:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:50 UTC