See also: IRC log
<dom> Slides for this call
<dom> ScribeNick: varun
Slide 5: Discussions for today
Slide 7: WebRTC PR 996
<dom> Issue 979 When is an RTCSctpTransport Created and Destroyed?
<dom> PR 996 addressing issue 979
Taylor: recommends that the Sctp association can be created only when the setRemoteDescription is applied
Bernard: alternative would be to have it created in the localDescription and the "max-message-size" value settable when the remote description is available
Harald: it would be possible to do this earlier, when the PRANSWER is available
Bernard: the problem is that currently there is no state in the SCTP transport
pthatcher: not have it in the peerconnection until the stable state is achieved.
taylor: we perhaps need it in the
pranswer state, because the developer can read the
max-message-size and use it.
... will update the PR.
<dom> Issue 116 RTCPeerConnection.getStats: What to do with 'selector' argument?
<dom> Add an explicit stats selection algorithm
can someone take over if I get involved?
harald: explaining the issue, and the differences between Chrome and Firefox.
Why not just return: RTCMediaStreamTrackStats and RTCRTPStreamStats
jan-ivar: explaining why there might be need some recursive stats, not just the track.
varun: I have not seen
use cases with selectors where you would need everything e.g.
transports info
... just returning the RTC RTP stream stats and @@@ would be sufficient
RTCRTPStreamStats covers the inbound and outbound stats.
<varun> My proposal: RTCInboundRTPStreamStats, RTCOutboundRTPStreamStats, RTCRTPStreamStats, and RTCMediaStreamTrackStats.
<dom> PR 988 Add RTCOfferOptions.reofferOptions
jan-ivar to make a proposal for tracks and sender/receiver as a selector for getStats()
pthatcher: should reofferCodecs be added?
juberti: maybe solve this in jsep
first, and later in the pc-spec.
... the idea in JSEP is to reoffer non-connection stuff. this
might be a nice fallback in case we are unable to solve this in
JSEP.
... can we generalise this: reofferCodecs, reofferExtensions,
... etc.
<dom> Issue 961 Effect of a BYE on RtpReceiver.track
bernard: I'll be
sumitting different PRs for different pieces of this
... have a PR for aspect B
... and will work on one for aspect A
... ignore the BYE for FEC / RTX
bernard/pthatcher: bye responds to the primary ssrc
<dom> Issue 962 Event when a transceiver is stopped via remote action
SLide: 17
Justin: on the previous issue, why dont we do the same thing?
bernard: in an SFU case, you
receive a BYE and then start getting the media again.
... so it seems more likely that is the main difference
... transceiver.stopped is due to remote action
justin: agrees
bernard: will submit a PR.
<dom> Issue 404 Revive createObjectURL?
Stefanh: all vendor prefixes were removed and counters show that the former is much more common
jesup: we would like to see it go away.
burn: the reason we removed it was not clear on how to spec it and how it should work.
jan-ivar: we should remove it.
shijun: would like to remove this as well
juberti/harald: we should remove it. But I do not know how many apps will break. We need to do some work to get people away from the API, because the usage of this API is high.
jesup: should make a deprecation warnings in the logs and discuss-webrtc. If not in release notes.
<dom> Issue 425 Do we update legacy methods to keep up with the spec?
Slide 23
jan-ivar: we kept the legacy guM
callback method. but we have made changes which affects the
legacy api
... so it kinda goes against the reason of keeping the old api,
however, wanted to highlight the issue.
burn: one impression, people expected that the error handling would become better. That is different from keeping the legacy API.
<scribe> ACTION: do nothing [recorded in http://www.w3.org/2017/01/25-webrtc-minutes.html#action01]
<trackbot> Error finding 'do'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
<dom> Issue 426 Move "advanced" out of the Constrainable pattern
harald: jan-ivar recommended moving advanced from constraibale out, so that it can be used elsewhere.
jan-ivar: arguing for the constrainable pattern because it can be used in other specs, for image-capture. min-max-ideal was sufficient for many cases and advanced is mostly not needed.
burn: on principle I agree, but advanced in several places in the spec, it is used in many places in a normative way. So would consider not removing it.
dom: could use a flag instead. if
the flag is set, then you can use the advanced algorithm.
... and not set then use the simpler algorithm.
harald: image-capture adds more constraints, and uses advanced as well
burn: I was under the impression that this was a strong problem based on what Jan-Ivar said. If not, let's not take any action now..
jan-ivar: image capture constraints that apply to video are applied immediately, and for the images when the getPhoto() is called.
finally, no action for issue 426
<dom> Issue 714 STUN/TURN OAuth token auth parameter passing
<dom> Separated auth dictionaries for STUN/TURN (PR 1000)
misi: too late to do a separated option or should pursue the hybrid option.
justin: prefers to #3. Is not sure how much it will break the existing things.
stefanh: hesitant to break people's code.
misi: it will be hard to add the "realm" to hybrid option. It wont be clear to the developer where to add the "realm"
justin: not sure why it could not be added in some place.
misi: is hybrid is the way?
halard: since we do not want to break spec, we would have to do the hybrid anyway.
bernard: +1 for hybrid.
harald: make username optional?
thanks dom. harald needs to confirm.
<Misi> Yes
<Misi> hybrid is the final word.
<vivien> trackbot, end meeting