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