19:49:45 RRSAgent has joined #webrtc 19:49:45 logging to http://www.w3.org/2016/08/23-webrtc-irc 19:49:47 RRSAgent, make logs world 19:49:47 Zakim has joined #webrtc 19:49:49 Zakim, this will be RTC 19:49:49 ok, trackbot 19:49:50 Meeting: Web Real-Time Communications Working Group Teleconference 19:49:50 Date: 23 August 2016 19:53:24 Chair: HTA, StefanH 19:53:25 hta1 has joined #webrtc 19:53:30 Agenda: https://www.w3.org/2011/04/webrtc/wiki/August_23_2016 19:53:54 -> https://docs.google.com/presentation/d/13tcE4rd7S80JJW_uX6iWNIs6v2Uwvrc4eiep2-ldnfk/edit#slide=id.g2bc53b137_010 Slides for the meeting 19:58:01 varun has joined #webrtc 19:58:52 mreavy has joined #webrtc 20:00:53 fluffy has joined #webrtc 20:01:05 stefanh has joined #webrtc 20:01:59 Present+ DomHM, BernardA, AdamR, Harald, Cullen, Randell, StefanH, Varun 20:03:27 jesup has joined #webrtc 20:05:49 Present+ Shijun, Sherwin 20:08:28 HTA: [introducing the meeting with slide 2 and 3] 20:09:45 Shijun has joined #webrtc 20:09:52 ScribeNick: varun 20:10:05 hta: slide 5 20:11:00 aboba: slide 7 20:11:04 Topci: Issue 685 / PR 759 20:11:18 s/Topci/Topic/ 20:12:11 aboba: Q1: JSEP reference for receiving multiple RTP encoding 20:14:56 Cullen: make sure this does not force the browser to do something they are not supposed to do. Although do not want to expressly remove the possibility for some future spec to extend it 20:15:24 Cullen: We are not mandating the receiver to receive multiple encodings. 20:15:58 Cullen: reject all the encoding except the first one (encoding) 20:16:01 aboba: yes 20:17:18 aboba: The problem is the receiver cannot indicate from the receiver to accept simulcast streams 20:18:28 Present+ DanBurnett 20:18:42 Who is speaking, justin? 20:18:49 Present+ Justin 20:19:11 Call-in user 2 is Taylor + Justin, I think 20:19:37 Ok thanks 20:20:10 aboba: discuss further on the PR. 20:20:36 Justin: this version of the document solve the problem when a browser receives multiple encoding. 20:20:45 Justin: or punt it to a future spec 20:21:31 Justin: JSEP is going to advise, you get multiple encodings, then it answers just for one, because there is no api to control this. 20:21:51 Justin: in the absence of an extension spec, adding text here is premature. 20:22:35 adambe has joined #webrtc 20:22:40 Justin: we basically leave it as is. 20:22:49 hta: leave it undefined? 20:23:15 Justin: the behaviour needs to be defined in JSEP, since the actual processing is done in JSEP and need not be in the API spec. 20:23:52 aboba: The text is in the API document because the RtpSender has the equivalent test. Which is why it needs to to be in RtpReceiver 20:25:12 stefanh: we should have some text here, referring to JSEP might be good enough. 20:25:40 Justin: Okay, we could point to the right place in JSEP. And the PR could then be on the right path then. 20:26:00 Justin: update JSEP and then update what that says in the API document 20:26:08 Topic: ISSUE 714 / PR 740 20:26:37 Slide 10 20:28:59 Justin: is the whole thing sent or just the access_token not the other keys 20:29:12 Justin: keyID gets added to the userID 20:29:22 Justin: so dont need the rest 20:29:34 -> https://tools.ietf.org/html/rfc7635#appendix-B RFC 7635 Appendix B 20:29:39 aboba: RFC7635 appendix B 20:30:55 aboba: stating the proposals #1 and #2 20:31:55 Cullen: kid, key, alg, the browser needs it not the js application 20:32:27 Justin: you pass the kid as the userid, the access_token as token. and 20:32:39 hta: so we do not need alg and key 20:32:41 hta: so we do not need alg and key? 20:32:52 xx: said Yes. 20:32:59 drno has joined #webrtc 20:33:33 cullen: do we need both? like a password and token, how would it work? pass both? 20:33:51 hta: ask someone who knows how this works? 20:34:33 Justin: the only information you need over the wire is access_token and the userid attribute has the kid. 20:35:09 Justin: use the credential type becomes ... 20:36:13 Present+ Nils_Ohlmeier 20:36:52 hta: if you are using oauth, access_token as token and kid as userid (username)? is this the proposal 20:37:14 aboba: sounds like we have a way forward 20:37:24 Topic: ISSUE 720 / PR 738 20:38:51 hta: stats has this too. 20:39:05 hta: we have only one and not a sequence 20:39:23 Cullen: the use case for stats to show the one that is currently in use 20:39:38 Cullen: although in this case it might be a different use-case 20:39:56 hta: so for someone who was not using SDP as the protocol and wanted to pass the fingerprint in 20:40:24 Cullen: being able to get all fingerprints seems like a good idea 20:40:38 hta: who generates the fingerprints 20:41:18 hta: if the browser generates the fingerprint uses the same algorithm as the cert. 20:41:35 " The browser selects the algorithm used to sign the certificate" 20:41:44 https://w3c.github.io/webrtc-pc/webrtc.html#dom-rtcpeerconnection-generatecertificate 20:42:28 aboba: explaining the text in the current spec 20:44:58 hta: stating the text is imprecise in the webrtc-pc spec, which needs clarification. 20:45:29 cullen: it seems we do not have the right people on the call. need martin, ekr may need to pitch in 20:46:06 stefanh: would there be more than 1 fingerprint in the SDP 20:46:20 Justin: yes, we could have 10 fingerprints. 20:46:35 stefanh: is this the browser doing this or someone else? 20:47:11 Justin: the original motivation was if the browser didnt use SDP 20:47:16 Present+ EKR 20:47:20 [EKR joins the call] 20:49:13 Justin: if you want hash agility, you need different certificates.... 20:49:18 ekr: clarified... 20:49:40 someone needs to write that for the minutes. I lost the actual resolution 20:49:49 Topic: ISSUE 726 / PR 757 20:50:13 s/someone needs to write that for the minutes. I lost the actual resolution/ekr: there is only one hash for a given cert 20:50:37 i/Topic: ISSUE 726/aboba: ok, so a single attribute for the cert should be enough 20:51:36 Justin: there is no backwards compatibility issue, to clarify Cullen's question 20:52:14 Cullen: would people be OK to add a configuration option to say if you want a per-mid "done"? 20:52:29 Taylor: if we are to add a configuration option for it, wouldn't an event be simpler for per-mid "done" 20:52:41 Taylor: if you want to add it to the configuration, we could instead to an event per mid. 20:53:26 Justin: you hook up to the event if you want to else, then you do not need a configuration 20:53:54 Justin: do we want extend the ice gathering state change or a new event 20:54:18 Cullen: a per m-line gathering would be nice to have 20:54:46 ekr: why is this required, what is the motivation for each m-line resolution/completion 20:54:57 ekr: this is not for rollback... 20:55:15 Justin: if we are going to add ufrag then we need this 20:56:14 hta: we do not have an end of candidates per m-line. so we should treat them separately 20:56:36 Justn: we need to know if the end of candidates was from the current generation or a previous generation 20:56:57 s/Justn/Justin 20:57:24 ekr: not opposed to this, need more motivation or clarification 20:58:08 hta: action to Justin to create new issue for the m-line end of candidates 20:58:48 hta: we have consensus for adding ufrag to the end of candidates 21:00:53 Taylor: if you do not have the end of candidates from the initial offer, then it become ambiguous if we have other generations of candidates 21:01:45 Cullen: one way to handle this would be to handle zeros as an end of candidate 21:02:18 Cullen: and the browsers handle it because they know this is supposed to be the end of candidates and the applications would just not care 21:02:26 Justin: this would be ugly... 21:02:55 adam: 21:04:10 hta: the ufrag could be add to the ice candidate event... but we need proposals, so people can discuss them when they become availabel 21:04:37 Topic: Issue 732/PR 758 21:04:50 Slide 15 21:06:03 Justin: bernard proposal seems right 21:06:28 aboba: this is in the PR 21:06:49 adambe: ending a track will be look as muting... 21:07:08 jesup: sounds good 21:07:10 ISSUE 678 21:07:17 Topic: ISSUE 678 21:07:27 adambe has joined #webrtc 21:07:40 Cullen: we just need Martin's attention! 21:07:41 Topic Issue 692 21:07:49 s/Topic /Topic: / 21:09:21 can someone else take over the scribing? 21:10:14 Taylor: chrome waits 5 intervals of consent checks to fail before going to disconnected 21:11:19 Cullen: does not the behave draft say anything? 21:11:42 aboba: RFC7675 says something about failure not disconnected 21:12:57 Justin: it states 1 to 15 seconds range, it is unclear what the recommendation is 21:13:14 cullen: consecutive checks failed and not the first. 21:21:26 Taylor: will work on the PR 21:22:21 Topic: ISSUE 700 21:33:23 [in summary: issue 700 needs more discussion] 21:33:27 Topic: ISSUE 729 22:54:40 Zakim has left #webrtc 23:18:06 mreavy_ has joined #webrtc 23:50:46 jesup has left #webrtc