IRC log of webrtc on 2017-03-01

Timestamps are in UTC.

15:09:08 [RRSAgent]
RRSAgent has joined #webrtc
15:09:08 [RRSAgent]
logging to http://www.w3.org/2017/03/01-webrtc-irc
15:09:18 [Zakim]
Zakim has joined #webrtc
15:10:14 [vivien]
Meeting: WebRTC and Media Capture Virtual Interim
15:10:19 [vivien]
Agenda: https://www.w3.org/2011/04/webrtc/wiki/March_1_2017
15:10:50 [vivien]
Chair: Bernard, Harald, Stefan
15:12:52 [vivien]
RRSAgent, make logs public
15:48:48 [fluffy]
fluffy has joined #webrtc
15:50:44 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/01-webrtc-minutes.html vivien
15:54:45 [vivien]
present+ Vivien_Lacourba
15:55:09 [vivien]
present+ Cullen_Jennings, Bernard_Aboba
15:56:00 [youenn]
youenn has joined #webrtc
15:58:52 [vivien]
present+ Misi, Patrick_Rockhill
15:59:50 [stefanh]
stefanh has joined #webrtc
16:00:04 [vivien]
present+ Stefan_Hakansson, Sherwim_Sim, Harald_Alvestrand
16:00:04 [hta1]
hta1 has joined #webrtc
16:00:12 [sherwinsim]
sherwinsim has joined #webrtc
16:00:34 [vivien]
present+ Taylor_Brandstetter
16:04:27 [vivien]
present+ Youenn_Fablet, HyukHoon_Shim
16:05:14 [vivien]
present+ Andy_Hutton
16:05:18 [jib]
jib has joined #webrtc
16:05:34 [vivien]
scribe: stefanh
16:05:43 [vivien]
present+ Jan-Ivar_Bruaroey
16:06:09 [stefanh]
hta: Welcome, Intro parts, including IPR policy
16:06:42 [stefanh]
...going to discuss Issues and PRs. Hope to get webrtc-pc to CR real soon, but need the spec to stabilize
16:06:50 [Misi]
Misi has joined #webrtc
16:07:17 [stefanh]
....for each issue/bug we need to decide if it needs fixing now (and if so: how) or if it can wait for a later spec version.
16:07:40 [vivien]
present+ Adam_Bergkvist
16:08:08 [stefanh]
....Going to cover 5 PRs today, hopefully we can decide to merge as many as possible of them and some Issues where we need more discussion to determine what to do.
16:08:17 [vivien]
WebRTC-PC Pull Requests
16:08:19 [stefanh]
...Let's start with PRs.
16:08:24 [vivien]
Topic: Issue 116/PR 1030: Sender and Receiver getStats Selectors (Jan-Ivar)
16:08:44 [stefanh]
J-I: PR 1030/Issue 116:
16:09:03 [stefanh]
....(see slide 7)
16:09:08 [vivien]
-> https://github.com/w3c/webrtc-stats/issues/116 Issue 116
16:09:23 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/1030 PR 1030
16:09:25 [stefanh]
....uses sender and recevier as selectors rather than track.
16:09:42 [stefanh]
....plus a selector algorithm
16:09:56 [stefanh]
....described in the slide.
16:11:12 [stefanh]
....note that Inbound and Outbound in the slide are mixed up (may be corrected to a later version of the slides before making and uploading a pdf)
16:12:26 [stefanh]
....was looking for language that associated a sender/receiver with its stats object, may need better than I have here in the proposal
16:13:15 [stefanh]
hta: trying to remember the name. RTPStream corresponds to an encoding.
16:13:37 [stefanh]
J-I: any objections on the concept? (More details one the next slide)
16:14:07 [stefanh]
....Slide 8....
16:15:31 [stefanh]
....main value of a selector: some users have up to 50 tracks for a peer connection, being able to select on track (or sender/receiver) helps a lot
16:16:23 [vivien]
present+ Randell_Jesup, Shijun_Sun
16:16:51 [stefanh]
adambe: Has there been any discussion on deprecating the selector completely and instead have getStats on a sender/receiver?
16:17:07 [stefanh]
Cullen: that sounds like a better API to me
16:17:36 [stefanh]
hta: Implementation wise it is easier to add a new API than a new selector
16:17:57 [stefanh]
...not speccing a selector would make sense.
16:18:17 [stefanh]
J-I: I am open for another API than using a selector.
16:18:44 [stefanh]
...are we talking about sender.getStats etc.?
16:18:55 [stefanh]
adambe: yes, essentially?
16:19:11 [stefanh]
bernard: how to get ICE stats and so on?
16:19:48 [stefanh]
adam: have getStats on PeerConnection would give you ICE stats?
16:20:30 [stefanh]
J-I: One way would be to merge this PR and than another to add getStats on sender/receiver.
16:21:01 [stefanh]
hta: if we keep track as selector merging this PR makes sense.
16:21:44 [stefanh]
bernard: are we adding getStats to other objects (like ICE transport, ....)?
16:22:15 [stefanh]
hta: with chairs hat: we don't want to add APIs we do not have requests for.
16:22:29 [stefanh]
J-I: filtering in JS is easy.
16:23:21 [stefanh]
hta: getStats on new objects would need someone driving it - would be a new a feature.
16:24:10 [vivien]
present+ Maire_Reavy
16:24:44 [stefanh]
J-I: if we modify this PR to just get the algorithm in, and merge, would that be OK?
16:25:28 [stefanh]
hta: conclusion: merge algorithm, keep track as selector, treat getTrack proposals for other object as new feature request.
16:26:00 [stefanh]
Cullen: we also need to fix the selector algorithm to make it correct in terms of SSRC
16:26:15 [stefanh]
Done with that one.
16:26:42 [stefanh]
Taylor: hybrid OAUTH solution.
16:26:44 [vivien]
Topic: Issue 714/PR 1033: “Hybrid” OAuth Solution (Taylor)
16:26:45 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/714 Issue 714
16:26:45 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/1033 PR 1033
16:26:54 [stefanh]
....captures the consensus of last meeting
16:27:25 [vivien]
(jan-ivar had to leave the call)
16:28:25 [stefanh]
....160 bit conflict.
16:29:03 [stefanh]
....seems like an Issue
16:29:33 [stefanh]
People agree, and proposes this is a bug in 7635
16:29:53 [stefanh]
Justin will look into what to do about 7635 and 160 bit
16:30:12 [stefanh]
Taylor
16:30:22 [stefanh]
....slide 11
16:30:53 [stefanh]
Cullen: we should just decide we need crypto agility
16:31:03 [vivien]
present+ Justin_Uberti
16:32:03 [stefanh]
Taylor: we need a standardized way to truncate a key. To be done at IETF side?
16:32:24 [stefanh]
Cullen: we should decide in IETF that we truncate, and how.
16:32:33 [stefanh]
Justin: we need this written down.
16:32:53 [stefanh]
hta: any target at IETF we can ask to sort this?
16:33:38 [stefanh]
Action on Taylor and Justin to sort things out with IETF.
16:33:38 [trackbot]
Error finding 'on'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
16:33:48 [vivien]
-> https://tools.ietf.org/html/rfc7635 RFC 7635 Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization
16:34:27 [stefanh]
hta: if the PR can be modified to work regardless of the solution to the truncating problem we can do that and merge.
16:34:43 [vivien]
Action Taylor and Justin to sort crypto things out with IETF regarding RFC 7635.
16:34:43 [trackbot]
Created ACTION-123 - And justin to sort crypto things out with ietf regarding rfc 7635. [on Taylor Brandstetter - due 2017-03-08].
16:34:44 [stefanh]
...Taylor, do you think that would be possible?
16:35:18 [stefanh]
Taylor: yes, and can put a sentence saying truncation is TBD and the rest should be mergable.
16:35:35 [vivien]
Topic: Issue 795/PR 1038: RTCDataChannel id assignment (Taylor)
16:35:35 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/795 Issue 795
16:35:35 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/1038 PR 1038
16:35:35 [stefanh]
....DataChannel Id
16:36:24 [stefanh]
....proposed solution: id returns null until negotiated.
16:36:38 [stefanh]
Randell: sounds like a reasonable solution to me.
16:37:13 [stefanh]
Bernard: +1, Cullen +1
16:37:27 [stefanh]
hta: ready to merge, will do tomorrow
16:38:01 [stefanh]
Cullen: do we need anything added to JSEP for datachannel Id? File a bug in that case.
16:38:11 [stefanh]
....unverified media
16:38:13 [vivien]
Topic: Issue 849/PR 1026: Specify an AllowUnverifiedMedia RTCConfiguration property (Fluffy)
16:38:13 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/849 Issue 849
16:38:13 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/1026 PR 1026
16:38:30 [stefanh]
....can happen in some cases
16:39:19 [stefanh]
...receiving media that is valid in some sense, but unclear who sends it
16:40:04 [stefanh]
...with this flag set, it allows this media to be played even though the fingerprint has not been verified
16:40:25 [stefanh]
...the application knows that the media is unverified
16:40:49 [vivien]
s/..../... /g
16:40:53 [stefanh]
....an atacker would be would need to intercept the signaling to launch an attack
16:41:06 [stefanh]
....and can then do a lot of badder things
16:41:43 [stefanh]
....also: I've added a timer, though its value is doubtful
16:42:14 [stefanh]
....we've talked about this before, and deided to write a PR and look at it and that's where we are
16:42:46 [vivien]
s/deided/decided/
16:42:53 [stefanh]
Randell: seems reasonable, not sure we need a timer. Seems simpler to not having to worry about timers
16:43:30 [stefanh]
Justin: this is a corner case since most of the time it won't work becuase you need candidates to puch holes
16:43:48 [vivien]
s/becuase/because/
16:43:59 [stefanh]
Randell/Cullen: in some (e.g. corporate) scenarios it works.
16:44:28 [stefanh]
Justin: this will add complexity, and is it worth it?
16:45:16 [stefanh]
Cullen: NAT pass through will work in many cases
16:45:40 [stefanh]
Justin: still unsure (details about ICE and DTLS and stuff)
16:46:16 [stefanh]
Cullen: pr_answer will contain ICE stuff but not correct fingerprint
16:46:53 [vivien]
present+ Alexandre_Gouaillard
16:47:07 [stefanh]
...correction: you will have a fingerprint of something but not audio
16:48:12 [stefanh]
Justin: you could make this work with pr_answer with the right fingerprint
16:48:46 [stefanh]
....we need a clearer (signaling) example
16:49:19 [stefanh]
Cullen: I have presented this several times, and I don't know what would be clearer example
16:50:09 [stefanh]
Justin: we need something where the PeerConnection is not killed because wrong fingerprint
16:50:32 [stefanh]
Cullen: Ice happens to the gateway
16:51:28 [stefanh]
(scribe not keeping up on all details)
16:51:45 [stefanh]
....I can try to draw something more crisp
16:52:22 [vivien]
present+ Peter_Thatcher
16:53:17 [stefanh]
(lots of discussion on details)
16:53:18 [vivien]
present+ simon?
16:54:26 [stefanh]
Justin/Peter: would like to see more exact info on the offers and answers
16:54:40 [stefanh]
Peter: volonteering to work with Cullen on this.
16:54:47 [vivien]
Topic: Issue 305/PR 1023: Describe what happens when media changes (Fluffy)
16:54:47 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/305 Issue 305
16:54:47 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/1023 PR 1023
16:54:54 [stefanh]
Cullen: media changes
16:55:15 [stefanh]
...what happens? This PR documents what we agreed at TPAC
16:56:23 [stefanh]
...says what to do when you do need to scale the video
16:57:21 [stefanh]
...we choose to crop off video over black bars
16:57:48 [stefanh]
Randell: I'me fine with this
16:57:58 [stefanh]
Bernard: OK to merge?
16:58:14 [vivien]
(no objection)
16:58:20 [stefanh]
(no one objects - let's merge)
16:58:35 [vivien]
Topic: Issue 1024/PR 1025: Codecs[] can be reordered or removed but not modified (Taylor)
16:58:35 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/1024 Issue 1024
16:58:35 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/1025 PR 1025
16:58:52 [stefanh]
Taylor: reorder or remove codecs, but not modify
17:00:26 [vivien]
WebRTC PC Issues
17:00:31 [vivien]
Topic: Issue 1040: Codecs supporting multiple clock rates/packetization-mode (Bernard)
17:00:31 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/1040
17:00:35 [stefanh]
Bernard: Issue 1040
17:01:42 [stefanh]
....what do you get on getCapabilities
17:01:52 [stefanh]
....MIME type is not sufficient
17:02:11 [stefanh]
....does not describe packetization mode
17:02:34 [stefanh]
....minimu solution: add stuff according to slide 19
17:02:58 [hta1]
Bernard!!!!!!!!!
17:03:03 [vivien]
s/minimu/minimum/
17:03:07 [stefanh]
...but if we add attributes, can they be set?
17:03:18 [stefanh]
....or modified?
17:03:44 [stefanh]
...two questions: do we add the attributes, and can they be modified?
17:04:28 [stefanh]
back to PR1025: do we accept this?
17:04:36 [stefanh]
many: agree.
17:04:43 [stefanh]
decided to merge 1025.
17:04:50 [stefanh]
back to Issue 1040
17:04:57 [vivien]
s/back to/Harald: point of order, back to/
17:06:04 [stefanh]
(discussion on 1040)
17:07:22 [stefanh]
Peter: we can separate two things: the app can ask the browser what it is capable of, and set what is used
17:07:40 [stefanh]
...how much flexibility do we want to offer in 1.0?
17:08:18 [stefanh]
Cullen: maybe it is usable with only the MIME type
17:08:43 [stefanh]
Randell: good point, the application can live with what the browser negotiated
17:09:09 [stefanh]
...I doubt the application would fiddle
17:09:33 [stefanh]
hta: the one use I have for the packetization mode is if the application would want to remove one
17:10:05 [stefanh]
...only case it makes sense is if it talks to someone that supports both but wants to steer which is used
17:10:21 [stefanh]
Cullen: SDP munging
17:10:48 [stefanh]
Randell: still struggling to find a use use case
17:11:18 [stefanh]
Bernard: looking beyond packetization mode, and look at stereo vs. mono
17:11:39 [stefanh]
Bernard: do we need additional attributes?
17:11:52 [stefanh]
Peter: I think so
17:13:12 [stefanh]
Taylor: packetization mode is different
17:14:23 [stefanh]
Jesup: for h264 it's a combination of profile and packetization mode
17:14:36 [stefanh]
hta: don't forget assymetry allowed
17:14:58 [stefanh]
Peter: can someone make it clear to me how bad it is for h264?
17:16:00 [stefanh]
Randell: in real world situations I see in the order of single digits
17:17:43 [stefanh]
hta: are we saying that capabilities should have one item for everyting the UA would use a new PT for?
17:17:53 [stefanh]
Bernard: yes, essentially
17:18:24 [stefanh]
Peter: should we have coded specific attributes?
17:18:50 [stefanh]
hta: would like to have it completely symmetrical with the codec description
17:19:15 [stefanh]
Peter: what is the full set we want?
17:20:25 [stefanh]
bernard: proposing to add only clockRate and sdpFmtpLine at the moment
17:20:54 [stefanh]
(People seem to like this)
17:21:14 [stefanh]
bernard: second question: can we modify/change?
17:21:31 [stefanh]
Peter: no, if you want to change it should be done elsewhere
17:21:59 [stefanh]
Taylor: can we add number of channels?
17:22:16 [stefanh]
bernard: would not add a new line, but we can add it
17:22:25 [vivien]
Topic: Issue 1022: sdpFmtpLine isn’t very convenient (Taylor)
17:22:25 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/1022
17:22:28 [stefanh]
Taylor: Issue 1022
17:23:05 [stefanh]
....can we simplify by adding a dictionary?
17:23:21 [stefanh]
Peter: perhaps a list of attributes would be better?
17:25:20 [stefanh]
bernard: if we're never going to modify sdpFmtpLines we do not gain much with a dictionary.
17:27:45 [stefanh]
skipping to FooError
17:27:47 [vivien]
Topic: Issue 845: “Throw a FooError” steps not consistent (Taylor)
17:27:48 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/845
17:28:01 [stefanh]
taylor: just proposing consitent terminology
17:28:23 [stefanh]
Many: seems reasonable
17:28:31 [stefanh]
Taylor: I can write a PR
17:28:36 [vivien]
Topic: Issue 1021: Parameter for packetization interval (Bernard)
17:28:36 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/1021
17:28:39 [stefanh]
Bernard: ptime
17:28:45 [stefanh]
....found by Varun
17:28:58 [stefanh]
....need to mess with SDP
17:29:19 [stefanh]
....question is if Varun talks about ptime or maxptime
17:29:41 [stefanh]
Peter: opus supports only certain ptimes
17:29:54 [stefanh]
Randell: same in many other codecs
17:30:05 [stefanh]
....who or what actually cares?
17:30:16 [stefanh]
....ptime is advisory anyway
17:31:10 [stefanh]
(many) when you want longer frames to reduce overhead, and shorter with networked mikes in conf rooms
17:31:41 [stefanh]
Peter: I want the app to be able to pick from ptimes supported
17:32:29 [stefanh]
...maybe out of scope for 1.0 and more an ortc thing
17:32:55 [stefanh]
hta: sounds to me that this is not for 1.0
17:33:24 [stefanh]
Cullen: it seems reasonable to allow the application to hint what it would want
17:33:44 [stefanh]
...same like turning off VAD
17:33:57 [stefanh]
Randell: agree
17:34:23 [stefanh]
hta: only thing small enough for 1.0 is a hint (single value).
17:34:35 [stefanh]
Randell will draft a PR for us!
17:35:29 [stefanh]
end of meeting
17:35:46 [vivien]
(times up, not discussed today are Issues 526 and Issue 763)
17:35:55 [vivien]
RRSAgent, draft minutes
17:35:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/01-webrtc-minutes.html vivien
18:31:33 [vivien]
Zakim, bye
18:31:33 [Zakim]
leaving. As of this point the attendees have been Vivien_Lacourba, Cullen_Jennings, Bernard_Aboba, Misi, Patrick_Rockhill, Stefan_Hakansson, Sherwim_Sim, Harald_Alvestrand,
18:31:33 [Zakim]
Zakim has left #webrtc
18:31:36 [Zakim]
... Taylor_Brandstetter, Youenn_Fablet, HyukHoon_Shim, Andy_Hutton, Jan-Ivar_Bruaroey, Adam_Bergkvist, Randell_Jesup, Shijun_Sun, Maire_Reavy, Justin_Uberti, Alexandre_Gouaillard,
18:31:36 [Zakim]
... Peter_Thatcher, simon?
20:35:46 [stryx`]
stryx` has joined #webrtc
22:56:10 [stryx`]
stryx` has joined #webrtc
23:13:19 [adamR]
adamR has joined #webrtc