Notes from January 22, 2019 WebRTC WG Virtual Interim

Slides: WebRTCWG-2019-01-22



   - 12 issues were discussed.
   - 11 issues had consensus (8 with PRs ready, 1 where PR should be
   updated and 2 ready for PR).
   - 1 issue did not reach consensus: Should we remove
   getDefaultIceServers()? <>

New issues that needs to be filed:

   - Does degradationPreference affect which layers to drop first?
   - Does maxFramerate have any meaning for audio?
   - Should getParameters() work between SRD(offer) and SRD(answer)? There
   was a related issue about header extensions, I'm not sure if that was a
   separate issue or the same one.
   - Define how to recycle transceivers in simulcast cases.


*Issue 1896 <>/PR 2071
<>: Order of
RTCRtpSendParameters.encodings is not described (Harald)*

Discussion: It should be the order in the simulcast line, not the a=rid
line as proposed in the PR. Otherwise consensus.

Separate issue to be filed about what layers to drop first.

*Issue 1964 <>/PR 2073
<>: Effect of
RTCRtpSendParameters on Simulcast (Bernard)*

File a separate issue for if degradationPreference affects which layers to
drop first.

File a separate issue for if maxFramerate has any meaning for audio.

Consensus for PR.

*Issue 1982 <>/Issue 2032
<>/PR 2079
<>: Missing normative steps for
determining codecs (Jan-Ivar)*

File a separate issue about whether or not parameters should be obtainable
between SRD(offer) and SLD(answer). A related issue about header extensions
to be filed too.

Consensus for PR.

*Issue 2009 <>/PR 2078
<>: Clarify how codecs should be
prioritized (Henbos)*

Consensus for PR.

*Issue 2013 <>/PR 2067
<>: Valid RID values mismatch
between specs (Bernard)*

Consensus for PR.

*Issue 2014 <>: Not clear how
to set # of layers when answering an offer with a track (Amit)*

File a separate issue about how to recycle transceivers when simulcast is
used. Client can reduce the number of layers but not increase it.

Let’s make a PR.

*Issue 2023 <>/PR 2068
<>: Should we remove
getDefaultIceServers()? (Jan-Ivar)*

No browser has implemented this.

Cullen Jennings thinks this is useful and should not be removed. Youenn
mentions fingerprint issue and should the website trust the list?

Cullen: Several enterprise webrtc applications have requested this API.
Unclear how to do this without such an API. A webserver wouldn’t
dynamically know which enterprise is requesting.

Henrik wonders if this is a problem for the application, not the browser.

Harald points out there are no crbugs filed for this API.

No consensus.

*Issue 2028 <>/PR 2069
<>: setCodecPreferences and
RTX/RED/FEC codecs (Bernard)*

The discussions were mostly clarifying how setCodecPreferences() currently
works (empty list meaning “no preference” and InvalidModificationError
thrown if setCodecPreferences() is called with a list that wouldn’t work in
both the send and receive case).

Consensus for PR.

*Issue 2053 <>/PR 2075
<>: Do simulcast Offers need to
contain RIDs of all streams in both directions(Amit)*

Consensus for PR.

*Issue 2054 <>/PR 2075
<>: Mismatch between RID
restrictions and RTCRtpEncodingParameters (Amit)*

Consensus for PR.

*Issue 2061 <>/PR 2075
<>: Simulcast alternative layers
do not have API surface (Amit)*

Consensus for PR.

*Issue 2072 <>: ‘Create an
RtpSender’ doesn’t handle creating from SDP (Harald)*

Consensus. Let’s make a PR.

Received on Tuesday, 22 January 2019 17:23:47 UTC