See also: IRC log
stefan: welcome. Editor resources are short through January, so everyone please submit PRs if possible in addition to issues.
aboba: (Reviewing slide 6 list of discussion topics)
aboba: (explaining slide 8)
... (explaining slide 9)
... Note that PR 926 clarifies receiver behavior
... (explains slide 10) This is the proposed text, straight
from JSEP.
... does this match everyone's understanding? (silence)
... any objections? (silence)
... so agreement.
aboba: (slide 11 and 12) Given some of these confusing statements,
we are trying to figure out what we want
... (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.
hta: it should be that removing the track you don't send data anymore.
aboba: is it reversible?
hta: you can do addTrack where you've done removeTrack.
aboba: so it's not a stop
hta: but you could end up with "inactive"
aboba: so are these actions, or
the immediate state? Taylor will discuss this more later.
... harald, please note these issues
... (slide 14) on replaceTrack, is this right?
hta: yes
fluffy: agree with last bullet on slide
aboba: (slide 15)
... This has similar issues. Again Taylor will address.
Thoughts about whether insertDTMF should throw?
cullen: it needs to be possible to find out if it worked. That depends on media flow, not signaling flow
aboba: right. insert should not appear successful even if it failed.
stefanh: to stop sender/receiver now what do you do?
aboba: transceiver.stop is permanent. setdirection doesn't take effect immediately. for a sender, can setParameters with active to 'false'. Not permanent
misi: (explains slide 16)
... (slide 17)
... Note that not all info is used. Only access_token, kid, and
key need to be passed to ICE Agent.
... (slide 18) Shows what info is needed and where in the
process.
... Key is that there is a gap between RFC 7635 and the WebRTC
APIs.
... this should be addressed somewhere. Perhaps an
Informational RFC?
... (slide 19)
justin: can you explain more about why HMAC alg needs to be known during auth phase?
cullen: we need more clarity. should oauth server be getting info about supported algs from TURN server.
misi: needs to get the longest
key length supported.
... eg if HMAC-256 it gives that key
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.
misi: There are only two today.
cullen: this is about crypto agility for the future. how do we design this to add a new crypto alg later.
misi: (didnt' catch properly)
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
misi: but in auth server the key is not connected with the turn server. The key is not shared.
cullen: auth and turn servers need to share info already anyway. They must at least be configured together anyway.
hta: does the browser have to execute these MAC algs?
misi: yes, for every message. normally SHA-1
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?
... this could be handled later between turn server and auth
server.
misi: (slide 20)
... This is my proposal -- a new iceSupportedHMACAlgs attribute
on PCs.
... the other part is on the next slide (21), extending
RTCIceServer with new accessToken attribute.
... (slide 22) if we make RTCIceServer a sequence we can
express preference ordering
... (slide 23) we would also need to adjust the error
conditions
... Also, what happens if STUN/TURN is not configured through
app and is discovered somehow. How would the PC signal what is
has descovered?
hta: no preference for how we address this. We should probably accept this.
Justin: wolud rather see an object than a parameter for future flexibility
misi: such as what other
info?
... I don't think there is anything else.
justin: there may be a new alg in the future that needs different info
misi: okay. but would need to change credential type as well
justin: yes. the type would tell
you what kind of object to expect
... that way we don't pack too much into a top-level
dictionary
cullen: yes. let's make sure we call the token the type it is as well rather than just "token"
justin: only a minor change to make this an object
hta: i think misi has a prior PR with the object syntax
misi: yes. i think it is not simple to implement, so I don't prefer that approach.
hta: if you put in a union in a dictionary it gets complicated to add more variants. adding more attributes migth be slightly better.
misi: i welcome help in this.
stefanh: do we want to be able to read out this info as well?
justin: no
cullen: we would need more explanation of how it works
hta: need to say that oauth will proived enough material for whatever alg we need
justin: today we can just return 256-bit key but in fututre need to understand how auth and turn servers will communicate.
cullen: agreed.
hta: who has action item?
<scribe> ACTION: misi to do this with Cullen's help [recorded in http://www.w3.org/2016/11/09-webrtc-minutes.html#action01]
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.
cullen: The webrtc doc should
have informative text explaining this.
... we can discuss which doc is the right place.
justin: yes, let's write it now as a PR, then we can decide where it should go.
Cullen: will go through error
handling slides 24 and on
... did a PR with Dan B's help
... slide 25
... Issue 1. SDP parsing error. Report line # where parsing
broke.
... hta asked if the line # info was for humans or
machines
... when that happens it is usaul to remove the line/attribute
or whole m-line when you get this type of errors
hta: this explanation made a bit of sense. Reasonable to me, and sorts out what line number to report.
Cullen: slide 26
... Identity. Deals with what happens if the browser is not
logged into the identity server
... the info needs to be passed back to the user, who needs to
log in
... question is how to get back once the user has logged
in
... question is if there can be more than one identity provider
configured at the same time or not. Spec is vague on this
topic.
... the way things are moving is that we would want to support
multiple id providers.
... 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
... did explanation make sense?
hta, bernard, stefanh (more): we understood the explanation
hta: need to make sure this is consisten across browsers
cullen: should I open a separate issue on whether we allow more than one identity provider
tim panton: we need to separate that out, there is a lot of complexity associated to multiple id providers
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,
and await resolution of that issue.
moving on to taylor, slide 27, Issue 859/PR 895
Taylor: about rollback. Mainly
editorial.
... already defined in JSEP
... PR already merged in fact. Any objection? -- silence
... note this is the only way a transceiver is removed.
Taylor: Issue803/PR913 neg needed flag update for
transceivers
... cleaning up and rewriting in term of transceivers
... e.g. creating and Answer does not clear flag any more
... next slide 29
... Issue803/PR913
... see slide for details
... slide 30 - here it gets a little complicated
... direction does not fire negotiation needed event
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?
... oh, realising this is fine.
... but what happens if the offerer changes his mind?
hta: no need to wait for a neg needed to renegotiate
taylor: any more comments?
taylor: Slide 31 Issue801/PR920: mostly editorial
... updating since we've introduced ICE-transport object
... and relying on state definitions
... slide 32 shows the PR example
... any comments? --silence
bernard: sounds good!
... on to issues
taylor: issue902
taylor: should SL/SR change transceiver.direction?
taylor: that is slide 34
...continued on slide 35
taylor: consider adding "negotiatedDirection"
<burn> instead of direction and negotiatedDirection, consider pendingDirection and currentDirection
taylor: slide 36: my rec
is that direction is not changed by SL/SR
... and perhaps add an extra attribute
<burn> +1 for two attributes in any case
bernard: is negotiated direction possible to detect by examining sender/receiver encoding.active?
taylor: no, I don't think
so
... would we like an extra attribute?
Many: we would like the extra attribute
Justin: agree, and direction should be updated by addTrack
taylor: I will take the action to create a PR
bernard, slide 37 Issue 927:
taylor: strawman proposal
described
... looks ok?
hta: clarify last step to talk about update neg needed flag
taylor slide 38
Taylor: isue760&726
... ufrag+mid and end-of-candidates
Taylor: slide 39
... describing earlier attempts to address this
... that have been abandoned
... slide 40: proposal to use "ICE action" event instead
<burn> yes, this is nicer and more future-proof.
Taylor: slide 41 outlines rest of
proposal
... slide 42 - how it would be used
... do we want to go ahead with this?
Jan-Ivar: why do we have a getCand method instead of an attribute?
taylor: don't remeber the
details, the crux is to add a new event
... we can work details out
hta: I like this
petert: +1
jan-ivar: why do we need new methods?
timp: you might not be bundling, trying to catch up if we address this?
taylor: this proposal is addressing that
justin: (scribe missed)
danb: we discussed this long at TPAC, I like this proposal (and it is futureproof as well)
taylor: slide 43: question is if need to make cands not being a black box
hta: other problem with 757 is
you get a problem with end-of-candidates
... impossible to tell which transport it was for
... legacy apps are waiting for a null candidate
jan-ivar: I push for PR757, it seems to solve everything except for advanced usages
(a lot of echo, hard to hear)
Item postponed to a future meeting due to lack of time.
end of call.
thanks all for coming
[NEW] ACTION: misi to do this with Cullen's help [recorded in http://www.w3.org/2016/11/09-webrtc-minutes.html#action01]
[End of minutes]