Summary of decisions at January 25th Virtual Interim

To allow those who were not present to get to know what was decided (and 
to enable them to raise their voice if they do not agree), and to make 
sure we got it right. Please let us know if we missed something or got 
something wrong.

Refer to the slides at 
https://www.w3.org/2011/04/webrtc/wiki/images/9/95/WebRTCWG-2017-01-25.pdf

The minutes are at https://www.w3.org/2017/01/25-webrtc-minutes


webrtc-pc
---------
Issue 979/PR 996: When is an RTCSctpTransport Created and Destroyed?:
DECISION: RTCSctpTransport is created after application of a remote 
description since that is when both the remote and local port are known 
and the association can be established; this is the earliest time 
datachannels can be used, and the earliest time a value is available for 
maxmessagesize (which is the main point of the object). We can create it 
on pr-answer (if not for pr-answer, it would be logical to create it 
when entering a stable state).

PR 988: Add RTCOfferOptions.reofferOptions: DECISION: We will not merge
this one. Discussion in JSEP will result in either asking for this 
again, asking for something else, or dropping the issue.

Issue 709: offerToReceiveAudio/offerToReceiveVideo remain in
implementations: DECISION to add this back into the spec (in the
compatibility section). Note that only the binary/boolean version will
be added back in (indicating that you are offering to receive one track)

Issue 961: Effect of a BYE on RTCRtpReceiver.track: Bernard's proposed
resolution was generally liked, but there are some corner cases to sort. 
DECISION: to go in the direction of Bernard's proposed resolution. There 
was a question on which SSRCs will fire the onmute Event Handler for the 
received track.  There was DECIDED that it would not be fired by 
receiving a BYE on fec.ssrc or rtx.ssrc.

Issue 962: Event when a transceiver is stopped via remote action:
Bernard's proposed solution was liked, DECISION to add to spec.

Issue 714/PR 1000: STUN/TURN auth credential management (OAuth):
DECISION: got with the "hybrid" API, and make username optional.

We also talked about Issue 116/PR 990: Add an explicit stats selection 
algorithm: but did not reach a decision.
two things noted: J-I would prefer something recursive instead of a
fixed list. Several preferred having sender/receiver as selcetor instead 
of track. J-I will craft a worked example of what will be returned under 
a recursive algorithm; and J-I will craft a PR for selecting on 
sender/receiver rather than track, as a basis for further discussion.


mediacapture-main
-----------------
Issue 404: Revive createObjectURL?: The idea of reviving was disliked.
DECISION: do not revive. (Implementors promised to add deprecation
warnings and similar, and demo code etc. will be gone through to change
to .srcObject.)

Issue 425: Do we update legacy methods to keep up with the spec?:
DECISION: do nothing (for the time being at least). Note that this means 
that legacy methods are shims over the main methods, and changes and 
clarifications in the main spec will also change the legacy methods.

Issue 426: Move “advanced” out of constrainable pattern: DECISION: defer 
this discussion until there is some spec that intend to use
constrainable pattern and does not like to implement advanced.


Stefan for the chairs

Received on Friday, 27 January 2017 18:58:25 UTC