15:57:16 <RRSAgent> RRSAgent has joined #webrtc
15:57:16 <RRSAgent> logging to http://www.w3.org/2016/11/09-webrtc-irc
15:57:26 <Zakim> Zakim has joined #webrtc
15:57:35 <dom> Meeting: WebRTC Working Group Virtual Interim
15:58:34 <dom> dom has changed the topic to: WebRTC WG teleconf https://www.w3.org/2011/04/webrtc/wiki/November_9_2016
15:58:38 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/November_9_2016
15:59:35 <dom> Chair: HTA, stefanh
16:02:06 <dom> Present+ Dominique_Hazael-Massieux, Bernard_Aboba, Cullen_Jennings, Mihaly_Mzszaros, StefanH, TaylorB, TimPanton
16:02:15 <stefanh> stefanh has joined #webrtc
16:02:21 <fluffy_> fluffy_ has joined #webrtc
16:02:24 <burn> Present+ Dan_Burnett
16:02:50 <dom> Present+ Patrick_Rockhill, Harald_Alvestrand
16:02:55 <dom> ScribeNick: burn
16:03:16 <vivien> present+ Vivien_Lacourba
16:04:09 <hta1> hta1 has joined #webrtc
16:05:15 <burn> stefan:  welcome.  Editor resources are short through January, so everyone please submit PRs if possible in addition to issues.
16:05:50 <burn> aboba: (Reviewing slide 6 list of discussion topics)
16:06:47 <burn> ... (explaining slide 8)
16:07:28 <burn> ... (explaining slide 9)
16:08:25 <vivien> present+ Maire_Reavy, Randell_Jesup, Roland_Hedberg
16:08:26 <burn> ... Note that PR 926 clarifies receiver behavior
16:08:37 <DrAlex> DrAlex has joined #webrtc
16:09:08 <burn> ... (explains slide 10)  This is the proposed text, straight from JSEP.
16:10:01 <burn> ... does this match everyone's understanding? (silence)
16:10:15 <burn> ... any objections? (silence)
16:10:28 <burn> ... so agreement.
16:12:09 <burn> ... (slide 11 and 12)  Given some of these confusing statements, we are trying to figure out what we want
16:13:37 <burn> ... (slide 13) This is the recommendation in PRs 916/918.  There is an issue with this.  if direction is "inactive" sending might still be happening.  Will get to this later.
16:13:39 <vivien> present+ AlexG
16:13:58 <burn> hta: it should be that removing the track you don't send data anymore.
16:14:05 <burn> aboba:  is it reversible?
16:14:15 <burn> hta:  you can do addTrack where you've done removeTrack.
16:14:20 <burn> aboba: so it's not a stop
16:14:31 <burn> hta:  but you could end up with "inactive"
16:14:47 <vivien> present+ Jan-Ivar
16:14:57 <burn> aboba:  so are these actions, or the immediate state?  Taylor will discuss this more later.
16:15:06 <jib> jib has joined #webrtc
16:15:08 <burn> ... harald, please note these issues
16:15:57 <burn> ... (slide 14) on replaceTrack, is this right?
16:16:05 <burn> hta:  yes
16:16:39 <burn> fluffy:  agree with last bullet on slide
16:16:57 <burn> aboba:  (slide 15)
16:17:44 <burn> ... This has similar issues.  Again Taylor will address.  Thoughts about whether insertDTMF should throw?
16:18:04 <burn> cullen:  it needs to be possible to find out if it worked.  That depends on media flow, not signaling flow
16:18:14 <vivien> present+ Justin_Uberti
16:18:23 <burn> aboba: right.  insert should not appear successful even if it failed.
16:18:48 <burn> stefanh: to stop sender/receiver now what do you do?
16:19:35 <burn> aboba:  transceiver.stop is permanent.  setdirection doesn't take effect immediately.  for a sender, can setParameters with active to 'false'.  Not permanent
16:20:02 <burn> ... (slide 16, Misi takes over)
16:20:24 <burn> misi:  (explains slide 16)
16:21:09 <burn> ... (slide 17)
16:22:04 <burn> ... Note that not all info is used.  Only access_token, kid, and key need to be passed to ICE Agent.
16:22:35 <burn> ... (slide 18) Shows what info is needed and where in the process.
16:23:08 <peter> peter has joined #webrtc
16:23:24 <burn> ... Key is that there is a gap between RFC 7635 and the WebRTC APIs.
16:24:09 <burn> ... this should be addressed somewhere.  Perhaps an Informational RFC?
16:24:34 <burn> ... (slide 19)
16:25:40 <burn> justin:  can you explain more about why HMAC alg needs to be known during auth phase?
16:26:59 <burn> cullen:  we need more clarity.  should oauth server be getting info about supported algs from TURN server.
16:27:13 <burn> misi:  needs to get the longest key length supported.
16:27:32 <burn> ... eg if HMAC-256 it gives that key
16:28:25 <burn> cullen:  if TURN supported, eg. SHA-10000. Then auth server could generate material that is long enough.  Still missing something.  Doesn't matter what the client supports since it's only what the TURN server supports that matters.
16:28:52 <burn> misi:  There are only two today.
16:29:17 <burn> cullen:  this is about crypto agility for the future.  how do we design this to add a new crypto alg later.
16:30:10 <burn> misi:  (didnt' catch properly)
16:31:17 <burn> cullen:  which should tell the auth server the size of the key?  The web server or the TURN server?  We thnk of the auth server being tied to the TURN server so it knows what to do
16:31:50 <burn> misi:  but in auth server the key is not connected with the turn server.  The key is not shared.
16:32:17 <burn> cullen:  auth and turn servers need to share info already anyway.  They must at least be configured together anyway.
16:32:33 <burn> hta:  does the browser have to execute these MAC algs?
16:32:51 <burn> misi: yes, for every message.  normally SHA-1
16:33:34 <burn> justin:  the TURN server could do this.  What we need is for the key to be long enoguh for the algs the browser supports.  Today a 256 bit key would be plenty.  So how do we get the key into the PeerConnection?
16:33:50 <burn> ... this could be handled later between turn server and auth server.
16:34:28 <burn> misi:  (slide 20)
16:35:14 <burn> ... This is my proposal -- a new iceSupportedHMACAlgs attribute on PCs.
16:36:16 <burn> ... the other part is on the next slide (21), extending RTCIceServer with new accessToken attribute.
16:36:46 <burn> ... (slide 22)  if we make RTCIceServer a sequence we can express preference ordering
16:37:09 <burn> ... (slide 23) we would also need to adjust the error conditions
16:37:57 <burn> ... Also, what happens if STUN/TURN is not configured through app and is discovered somehow.  How would the PC signal what is has descovered?
16:39:04 <burn> hta:  no preference for how we address this.  We should probably accept this.
16:39:20 <burn> Justin:  wolud rather see an object than a parameter for future flexibility
16:39:30 <burn> misi:  such as what other info?
16:39:53 <burn> ... I don't think there is anything else.
16:40:06 <burn> justin: there may be a new alg in the future that needs different info
16:40:18 <burn> misi:  okay. but would need to change credential type as well
16:40:33 <burn> justin: yes.  the type would tell you what kind of object to expect
16:40:48 <burn> ... that way we don't pack too much into a top-level dictionary
16:41:08 <burn> cullen:  yes.  let's make sure we call the token the type it is as well rather than just "token"
16:41:21 <burn> justin:  only a minor change to make this an object
16:41:35 <burn> hta:  i think misi has a prior PR with the object syntax
16:41:57 <burn> misi:  yes.  i think it is not simple to implement, so I don't prefer that approach.
16:42:32 <burn> hta:  if you put in a union in a dictionary it gets complicated to add more variants.  adding more attributes migth be slightly better.
16:43:03 <burn> misi:  i welcome help in this.
16:43:34 <burn> stefanh:  do we want to be able to read out this info as well?
16:43:46 <burn> justin:  no
16:43:54 <burn> cullen:  we would need more explanation of how it works
16:44:13 <burn> hta:  need to say that oauth will proived enough material for whatever alg we need
16:44:35 <burn> justin:  today we can just return 256-bit key but in fututre need to understand how auth and turn servers will communicate.
16:44:43 <burn> cullen:  agreed.
16:44:52 <burn> hta:  who has action item?
16:45:11 <burn> ACTION: misi to do this with Cullen's help
16:46:08 <burn> misi:  about the RFC proposal, should we do this as well?  Wrtiting down how this works in WebRTC?  The current RFC doesn't talk about the STUN client and auth client interactionts.
16:46:33 <burn> cullen:  The webrtc doc should have informative text explaining this.
16:46:56 <burn> ... we can discuss which doc is the right place.
16:47:12 <burn> justin:  yes, let's write it now as a PR, then we can decide where it should go.
16:47:51 <vivien> scribe: stefanh
16:47:52 <stefanh> bernard: issue 822/PR850
16:48:14 <stefanh> Cullen: will go through error handling slides 24 and on
16:48:26 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/09-webrtc-minutes.html vivien
16:48:34 <stefanh> ....did a PR with Dan B's help
16:48:43 <stefanh> ....slide 25
16:49:09 <stefanh> ...Issue 1. SDP parsing error. Report line # where parsing broke.
16:49:27 <stefanh> ...hta asked if the line # info was for humans or machines
16:50:20 <stefanh> ....when that happens it is usaul to remove the line/attribute or whole m-line when you get this type of errors
16:51:15 <stefanh> hta: this explanation made a bit of sense. Reasonable to me, and sorts out what line number to report.
16:51:25 <stefanh> ....slide 25
16:51:31 <vivien> s/25/26/
16:52:03 <stefanh> ...Identity. Deals with what happens if the browser is not logged into the identity server
16:52:29 <stefanh> ....the info needs to be passed back to the user, who needs to log in
16:52:49 <stefanh> ...question is how to get back once the user has logged in
16:53:28 <stefanh> ....question is if there can be more than one identity provider configured at the same time or not. Spec is vague on this topic.
16:53:53 <stefanh> ....the way things are moving is that we would want to support multiple id providers.
16:54:44 <fippo> fippo has joined #webrtc
16:54:53 <stefanh> ...if we're to support that we need to pass info on what id provider to log on to - thus return the url in the error
16:55:18 <stefanh> ...did explanation make sense?
16:55:53 <stefanh> hta, bernard, stefanh (more): we understood the explanation
16:56:09 <stefanh> hta: need to make sure this is consisten across browsers
16:56:36 <stefanh> cullen: should I open a separate issue on whether we allow more than one identity provider
16:57:06 <stefanh> tim panton: we need to separate that out, there is a lot of complexity associated to multiple id providers
16:57:35 <vivien> present+ Peter
16:57:50 <vivien> present+ Shijun_Sun
16:57:53 <stefanh> cullen: my proposal to move forward: remove the url string from the PR, open a new Issue to sort if we should support several Id providers,
16:58:19 <stefanh> and await resolution of that issue.
16:58:50 <stefanh> moving on to taylor, slide 27, Issue 859/PR 895
16:59:12 <stefanh> ...about rollback. Mainly editorial.
16:59:26 <stefanh> ...already defined in JSEP
16:59:53 <stefanh> ...PR already merged in fact. Any objection? -- silence
17:00:13 <stefanh> ...note this is the only way a transceiver is removed.
17:00:37 <stefanh> ....Issue803/PR913 neg needed flag update for transceivers
17:01:03 <stefanh> ...cleaning up and rewriting in term of transceivers
17:01:36 <stefanh> ...e.g. creating and Answer does not clear flag any more
17:02:07 <stefanh> ...next slide 29
17:02:18 <stefanh> ...Issue803/PR913
17:02:37 <stefanh> ...see slide for details
17:03:14 <stefanh> ....slide 30 - here it gets a little compliated
17:03:36 <vivien> s/compliated/complicated/
17:04:24 <stefanh> ...direction does not fire negotiation needed event
17:06:20 <stefanh> DanB: Question: say next offer is sendrecv, which is in line with the tranceiver, but not with the answer that would trig a neg-needed event?
17:06:57 <stefanh> ...oh, realising this is fine.
17:07:24 <stefanh> ...but what happens if the offerer changes his mind?
17:07:51 <stefanh> hta: no need to wait for a neg needed to renegotiate
17:08:11 <stefanh> taylor: any more comments?
17:08:38 <stefanh> ...Slide 31 Issue801/PR920: mostly editorial
17:09:04 <stefanh> ...updating since we've intoduced ICE-transport object
17:09:26 <stefanh> ...and relying on state definitions
17:09:27 <vivien> s/intoduced/introduced/
17:10:07 <stefanh> ...slide 32 shows the PR example
17:10:56 <stefanh> ...any comments? --silence
17:11:06 <stefanh> bernard: sounds good!
17:11:16 <stefanh> ...on to issues
17:11:28 <stefanh> taylor: issue902
17:11:38 <vivien> Topic: WebRTC PC Issues
17:11:54 <stefanh> ...should SL/SR change transceiver.direction?
17:12:06 <vivien> Topic: Issue 902
17:12:12 <stefanh> ...that is slide 34
17:12:36 <stefanh> ...continued on slide 35
17:13:15 <stefanh> ...consider adding "negotiatedDirection"
17:14:14 <burn> instead of direction and negotiatedDirection, consider pendingDirection and currentDirection
17:14:45 <stefanh> ...slide 36: my rec is that direction is not changed by SL/SR
17:14:57 <stefanh> ...and perhaps add an extra attribute
17:15:09 <burn> +1 for two attributes in any case
17:15:36 <stefanh> bernard: is negotiated direction possible to detect by examining sender/receiver encoding.active?
17:15:47 <stefanh> taylor: no, I don't think so
17:16:15 <stefanh> ...would we like an extra attribute?
17:16:30 <stefanh> Many: we would like the extra attribute
17:16:47 <stefanh> Justin: agree, and direction should be updated by addTrack
17:17:20 <stefanh> taylor: I will take the action to create a PR
17:17:34 <stefanh> barnard, slide 37 Issue 927:
17:17:51 <stefanh> ...strawman proposal described
17:18:19 <stefanh> ...looks ok?
17:18:43 <stefanh> hta: clarify last step to talk about update neg needed flag
17:19:05 <stefanh> taylor slide 38
17:19:15 <stefanh> ...isue760&726
17:19:33 <stefanh> ...ufrag+mid and end-of-candidates
17:19:49 <vivien> Topic: Issue 760/Issue 726: Adding ufrag to candidates, and ufrag+mid to end-of-candidates
17:19:51 <stefanh> ...slide 39
17:20:12 <stefanh> ...describing earlier attempts to address this
17:20:37 <stefanh> ...that have been abandoned
17:21:16 <stefanh> ...slide 40: proposal to use "ICE action" event instead
17:21:54 <burn> yes, this is nicer and more future-proof.
17:21:59 <stefanh> ...slide 41 outlines rest of proposal
17:22:13 <stryx`> stryx` has joined #webrtc
17:22:32 <stefanh> ...slide 42 - how it would be used
17:23:07 <stefanh> ...do we want to go ahead with this?
17:23:30 <stefanh> Janivar: why do we have a getCand method instead of an attribute?
17:23:54 <stefanh> taylor: don't remeber the details, the crux is to add a new event
17:24:14 <stefanh> ...we can work details out
17:24:54 <stefanh> hta: I like this
17:25:02 <stefanh> petert: +1
17:25:38 <stefanh> janivar: why do we need new methods?
17:26:25 <stefanh> timp: you might not be bundling, trying to catch up if we address this?
17:26:36 <stefanh> taylor: this proposal is addressing that
17:26:56 <stefanh> justin: (scribe missed)
17:27:23 <stefanh> danb: we discussed this long at TPAC, I like this proposal (and it is futureproof as well)
17:28:03 <stefanh> taylor slide 43: question is if need to make cands not being a black box
17:28:27 <stefanh> hta: other problem with 757 is you get a problem with end-of-candidates
17:28:48 <stefanh> ...impossible to tell which transport it was for
17:29:43 <stefanh> ...legacy apps are waiting for a null candidate
17:30:13 <stefanh> janivar: i push for PR757, it seems to solve everything except for advanced usages
17:30:42 <stefanh> (a lot of echo, hard to hear)
17:31:04 <stefanh> end of call.
17:31:09 <stefanh> thanks all for coming
17:32:09 <dom> RRSAgent, draft minutes
17:32:09 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/09-webrtc-minutes.html dom
17:32:12 <dom> Zakim, bye
17:32:12 <Zakim> leaving.  As of this point the attendees have been Dominique_Hazael-Massieux, Bernard_Aboba, Cullen_Jennings, Mihaly_Mzszaros, StefanH, TaylorB, TimPanton, Dan_Burnett,
17:32:12 <Zakim> Zakim has left #webrtc
17:32:14 <dom> RRSAgent, draft minutes
17:32:14 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/09-webrtc-minutes.html dom
17:32:15 <Zakim> ... Patrick_Rockhill, Harald_Alvestrand, Vivien_Lacourba, Maire_Reavy, Randell_Jesup, Roland_Hedberg, AlexG, Jan-Ivar, Justin_Uberti, Peter, Shijun_Sun
17:32:17 <dom> RRSAgent, draft minutes
17:32:17 <RRSAgent> I have made the request to generate http://www.w3.org/2016/11/09-webrtc-minutes.html dom
17:35:37 <dom> dom has joined #webrtc