See also: IRC log
<dom> Slides for the meeting
<dom> HTA: [introducing the meeting with slide 2 and 3]
<dom> ScribeNick: varun
hta: slide 5
aboba: slide 7
aboba: Q1: JSEP reference for receiving multiple RTP encoding
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
... We are not mandating the receiver to receive multiple encodings.
... reject all the encoding except the first one (encoding)
aboba: yes
... The problem is the receiver cannot indicate from the receiver to accept simulcast streams
aboba: discuss further on the PR.
Justin: this version of the document solve the problem when a browser receives multiple encoding.
... or punt it to a future spec
... JSEP is going to advise, you get multiple encodings, then it answers just for one, because there is no api to control this.
... in the absence of an extension spec, adding text here is premature.
... we basically leave it as is.
hta: leave it undefined?
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.
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
stefanh: we should have some text here, referring to JSEP might be good enough.
Justin: Okay, we could point to the right place in JSEP. And the PR could then be on the right path then.
... update JSEP and then update what that says in the API document
Slide 10
Justin: is the whole thing sent or just the access_token not the other keys
... keyID gets added to the userID
... so dont need the rest
<dom> RFC 7635 Appendix B
aboba: RFC7635 appendix B
... stating the proposals #1 and #2
Cullen: kid, key, alg, the browser needs it not the js application
Justin: you pass the kid as the userid, the access_token as token. and
hta: so we do not need alg and key
... so we do not need alg and key?
xx: said Yes.
cullen: do we need both? like a password and token, how would it work? pass both?
hta: ask someone who knows how this works?
Justin: the only information you need over the wire is access_token and the userid attribute has the kid.
... use the credential type becomes ...
hta: if you are using oauth, access_token as token and kid as userid (username)? is this the proposal
aboba: sounds like we have a way forward
hta: stats has this too.
... we have only one and not a sequence
Cullen: the use case for stats to show the one that is currently in use
... although in this case it might be a different use-case
hta: so for someone who was not using SDP as the protocol and wanted to pass the fingerprint in
Cullen: being able to get all fingerprints seems like a good idea
hta: who generates the fingerprints
... if the browser generates the fingerprint uses the same algorithm as the cert.
<dom> " The browser selects the algorithm used to sign the certificate"
<dom> https://w3c.github.io/webrtc-pc/webrtc.html#dom-rtcpeerconnection-generatecertificate
aboba: explaining the text in the current spec
hta: stating the text is imprecise in the webrtc-pc spec, which needs clarification.
cullen: it seems we do not have the right people on the call. need martin, ekr may need to pitch in
stefanh: would there be more than 1 fingerprint in the SDP
Justin: yes, we could have 10 fingerprints.
stefanh: is this the browser doing this or someone else?
Justin: the original motivation was if the browser didnt use SDP
<dom> [EKR joins the call]
Justin: if you want hash agility, you need different certificates....
ekr: clarified...
... there is only one hash for a given cert
<inserted> aboba: ok, so a single attribute for the cert should be enough
Justin: there is no backwards compatibility issue, to clarify Cullen's question
<dom> Cullen: would people be OK to add a configuration option to say if you want a per-mid "done"?
<dom> Taylor: if we are to add a configuration option for it, wouldn't an event be simpler for per-mid "done"
Taylor: if you want to add it to the configuration, we could instead to an event per mid.
Justin: you hook up to the event if you want to else, then you do not need a configuration
... do we want extend the ice gathering state change or a new event
Cullen: a per m-line gathering would be nice to have
ekr: why is this required, what is the motivation for each m-line resolution/completion
... this is not for rollback...
Justin: if we are going to add ufrag then we need this
hta: we do not have an end of candidates per m-line. so we should treat them separately
Justin: we need to know if the end of candidates was from the current generation or a previous generation
ekr: not opposed to this, need more motivation or clarification
hta: action to Justin to create new issue for the m-line end of candidates
... we have consensus for adding ufrag to the end of candidates
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
Cullen: one way to handle this would be to handle zeros as an end of candidate
... and the browsers handle it because they know this is supposed to be the end of candidates and the applications would just not care
Justin: this would be ugly...
adam: <lost this bit>
hta: the ufrag could be add to the ice candidate event... but we need proposals, so people can discuss them when they become availabel
Slide 15
Justin: bernard proposal seems right
aboba: this is in the PR
adambe: ending a track will be look as muting...
<jesup> jesup: sounds good
<dom> Cullen: we just need Martin's attention!
Taylor: chrome waits 5 intervals of consent checks to fail before going to disconnected
Cullen: does not the behave draft say anything?
aboba: RFC7675 says something about failure not disconnected
Justin: it states 1 to 15 seconds range, it is unclear what the recommendation is
cullen: consecutive checks failed and not the first.
Taylor: will work on the PR
<dom> [in summary: issue 700 needs more discussion]
<dom> [in summary: Harald's proposed solution sounds good]