[rtcweb] JSEP Question: Receipt of an offer requesting sending of simulcast

Bernard Aboba <bernard.aboba@gmail.com> Sun, 04 November 2018 19:30 UTC

MIME-Version: 1.0
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 04 Nov 2018 14:30:23 -0500
Message-ID: <CAOW+2dt9wd7NqhaFL97qoBx5toyw_WOFxesk=WGVTZEgJcLX1w@mail.gmail.com>
To: RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000603ca80579dbcda5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/TlQtj-y6-T0DMdrhsUKmFPDlra8>
Subject: [rtcweb] JSEP Question: Receipt of an offer requesting sending of simulcast
Precedence: list

In a conferencing scenario, typically the conference server will send an
Offer to the browser, since it alone knows how many conference participants
there are, and therefore how many m-lines to include.  In such a scenario
it is also common for the conference server to receive simulcast from the
browser.

Therefore in order to make such a scenario work, it is necessary for the
browser to be able to receive an Offer from the conference server
indicating the desire for the browser to send simulcast, and for the
browser to generate an appropriate Answer to the conference server.

A WPT test for this scenario has been suggested (see:
https://github.com/web-platform-tests/wpt/pull/13902 ) and in developing
the test, it would be helpful to understand how things are supposed to
work, exactly.

JSEP Section 3.7 currently states:

   In addition, JSEP does not provide a mechanism to handle an incoming
   offer requesting simulcast from the JSEP endpoint.  This means that
   setting up simulcast in the case where the JSEP endpoint receives the

   initial offer requires out-of-band signaling or SDP inspection.
   However, in the case where the JSEP endpoint sets up simulcast in its
   in initial offer, any established simulcast streams will continue to
   work upon receipt of an incoming re-offer.  Future versions of this
   specification may add additional APIs to handle the incoming initial
   offer scenario.


draft-ietf-mmusic-simulcast makes it clear how a conferencing server can
request that the browser send simulcast, namely by including a=rid:X recv
lines, so there does seem to be a mechanism, but the boundaries of what it
supports and does not support is somewhat fuzzy.

For example, it is not currently clear (at least to me) exactly how much of
the SDP in the Offer is reflected in the encoding parameters that manifest
on the Answering side.  I would expect the number of encodings and the rids
to show up in transceiver.sender.getParameters().  But should anything else
be expected?  For example, if the SDP in the Offer contains max-fr, will
this be reflected in values of the maxFramerate attribute of the encodings
on the Answering side?  Is there any circumstance in which the Answerer
will find other encoding parameters set, such as maxBitrate or
resolutionScaleDownBy?

[rtcweb] JSEP Question: Receipt of an offer reque… Bernard Aboba