See also: IRC log
Erik: [introducing the first
virtual interim of WebRTC WG]
... reminder about W3C patent Policy
... Goal: making progress to move toward transition to
Candidate Recommendation
... goal is to publish an editors draft after this meeting
... Meeting is being recorded
... waiting for recording and start of the hangout
session
erik: Welcome everybody, if you
can't join the Hangout, please join IRC and let us know
... a slide for you Adam
PR #447: Add contribution guidelines
adamB: pr447 include guidelines for contributions to the draft
bernard: is there anything committer should be aware of?
admaB: yes, there is a section about line wrapping for example, for the automatic checking.
fluffy: can we put automatic checking in a separate PR?
adamB: yes, you can see a corresponding comment.
dom: it is not enforced yet in
the repo. It would be a good thing for people to start doing it
though.
... while we are on this topic, a heads up, hopefully in a few
weeks there should be a new way to put IDL code in the
specs.
... obviously I will let people know when it happens.
bernard: particular, when there are new things we should start doing, a post on the mailing list would be welcome.
adamB: I was not aware that we were not enforcing this on the specs. I think my personal view is that doing automatically line wrapping will make things more difficult. But ... we can try to use it and see.
erik: so are we ok to move on, Cullen?
fluffy: I was just requesting that one PR maps to one feature, not several features. Easier reviewing.
erik: ok, next.
erik: I think there is actually
an extra PR we forgot to put in this list.
... if you see anything missing, please let us know, maybe on
IRC.
... having said that, did anybody already see something
missing?
bernard: I had a list, and put it in the slides, so I believe everything is there.
harald: 454 is included.
erik: cullen, your turn.
cullen: last time we spoke on
setParams Async, it seemed ok, but Harald raised a few timing
problems
... what happen if you have "overlapping" setParams call ? do
you queue them? In which order should you handle it.
... I think this is the open issue we need to resolve, before
we write anything about it in the draft.
... harald since you raised the issue, would you mind to
comment.
harald: yes, I realized after the
discussion that you won't be able to resolve things on the
thread to be able to know what to set and what happen
eventually.
... in some cases, depending on orders of calls, and timing of
promise resolving, you have not consistent behavior.
... is it so complicated that we should stay with Synchronous,
or can we actually write it down and fully specify it?
UNKNOWN:there were some discussions about codec change for example, changing software codec to hardware codec, discovering that this codec is already in use, it might not be done synchronuously.
Peter: the rid should be read only
justin: I'm pretty sure we will encounter cases where we need time before vetting off parameters
peter: can we live with it being sync ?
cullen: there is no way, we are going to need async.
peter: I'm more concerned about justin other use case.
harald: when you do getParam, you
return a conceptually generated value .... and if you set
param, it should still be the same params, otherwise, setParam
should fail
... that would enforce consistency.
cullen: that would be the most miserable API from user exeprience
harald: for anything that does not have a race condition, it would just work.
justin: is it clear how you could arrive to a discrepancy in the params ?
cullen: what you propose harald would work.
adamB: can we have some failure happen at anytime, anyhow, to have a process to report problems. Say we keep it async, and if it fails, we report it.
harald: that would be an event, not a promise.
justin: we should still entertain it.
roman: it feels like we are arriving to a transactional model. It would be cleaner also.
justin: right, but it is almost like a batch set, batch set. Any error would be surface through the failed promise.
roman: yes, but you would have some sort of object way to percolate the info up through the promise.
justin: again, why async is problematic again ?
harald: if we have a transaction mechanism like roman proposed, then it is ok. Otherwise it s problematic. we have to be sure that the behavior is predictable.
peter: otherwise we have the same problem we are having when set..... is called twice, before the first one resolves.
cullen: I feel like calling things twice before the first call resolves would happen frequently enough not to be a corner case.
harald: the place where we could copy this mechanism from is Dynamic DNS.
cullen: so justin, I'm trying to design your thinking, when you call setParams, if there is already a setParams promise queue or being processed, it instantaneously fails.
peter: then what happen in this (more convoluted case)
justin: params should not be set until setParam() resolved.
bernard: just to be clear, get is always sync, right?
harald: yes
erik: just checking on time, and the notes.
<hta> Harald promises to create a pull request against Cullen's pull request to make this modification.
peter: if setParam is called while a previous call is unresolved, then fail right away.
justin: if we think there is a case for multiple calls, we can then queue, but as of now, there is no such case.
erik: are we going ahead with justin proposal (vs harald's)?
justin: yes, but harald said he would write the PR against it :)
erik: great, can't get better than that
bernard: next slide will be fast.
bernard: proposal to add support for v flag (RFC6464)
<jesup> +1 for adding this
<jesup> don't care about the name ;-)
bernard: instead of using audio level, you could rely on "v" to know who is speaking
harald: voice activated flag sounds like a good name.
<jesup> AudioActivityIndicator
<jesup> Or voice.
justin: we talk about this at TPAC. we decided not to do it, because it does not get sent down from mixer. In this case (p2p), I can see how it could make sense.
bernard: the use case for this is a very simple UI, for mesh conference.
<dom> I'm neutral on adding it; but please let's not use "v" as a name :)
justin: this is gonna lead to a future where someone will ask for the mixer to send the info down.
cullen: the mixer equivalent is the crsc list
justin: in all fairness, some people use the list to determine background noise (??)
jesup: I can see a use for that, as people try to code SFU in the browser.
bernard: let's try to keep it in the p2p model.
cullen: if the signaling is such, that you do not use that bit, what happen?
bernard: it s just unset
justin: you mean undefined
bernard: yes
cullen: I like that
all: can we just use another name for it?
harald: seems good to me
erik: does sanybody oppose to
this?
... ok, consensus it is.
erik: rollback
peter: so I went ahead and put
some text about the rollback.
... somebody had already put the nullable part
... I just made it a little bit more explicit what would happen
during the rollback, and also pointers to JSEP.
... it s just slightly more explicit
erik: anybody has any comment on this?
cullen: looks like a notarial change, so ...
harald: I like it ....
erik: ok, next, ice transport policy
bernard: there was a discrepancy
between the draft and JSEP.
... our first attempt at fixing it raised backward
compatibility and extensibility issues
... harald proposed another solution.
... we just want to ask the browser guys if that will be a
problem?
justin: I'm not sure I would deb on board as the migration, but the move to a string would be good in the future.
peter: what's the point of having a string? I don't get it.
cullen: so we could return an error. also ENUM are broken in IDL.
peter: ah ok, enum are broken.
bernard: so what should we do?
jib: comment on enum.
... you have no choice if you don't want the browser to choke
on the type.
... that s why we used strings for optional constraints.
justin: we want the browser to
NICELY fail when it bumps into something it does not know. With
string you can ignore it, not with ENUM.
... I would prefer to keep an enum, but well define the values
in the enum.
cullen: use case with red and
green relays.
... the question is then, how do we extend it? if we do not
extend it, enum is fine.
bernard: PR 432 should be rolled back, and ENUM could be OK.
justin: yeah, I guess, do we want to speak about which values should be in there?
dom: technically, the enum is reflecting what is in JSEP
bernard: has anybody implemented none already?
jib: firefox has.
cullen: what are the privacy implications?
justin: my thinking about this
has changed across time.
... originally it was because gathering was starting right
away
... right now, you need to wait for a call.
... now is maybe not the right time to speak about that. if
someone wants to keep none, then let's hear the rationale
bernard: ok, let's write down
that we need to speak about "none"
... I think we can move on
erik: can we speak about that on discuss-public as well?
erik: issue 389, peter
peter: reading the slide.
erik: anybody has any comment on that?
jib: it just reminds me that
there is another occasion where the peer connection can close
itself.
... in that case, having a state is important for the
user.
... but if the user must close it, then he/she does not need a
state.
harald: so when you call closed on a peer connection, how do yo know it is actually closed?
peter: so if all the ice connection state are closed, then the peer connection is closed?
harald: I think that you NEED to call close() for the peer connection is closed.
<dom> +1 to adambe to update "signalling state is closed" to "connection state is closed" (if we adopt this)
Conclusion for Issue 389: add the "closed" state.
Harald: set all three states to closed.
Peter will make the relevant PR.
Bernard: reviews two use cases.
... Screen sharing conference with devices of different framerates.
scaleResolutionDownBy generates streams with dfifferent
resolutions. maxFramerate generates streams within device max
framerate.
... Video conference is an example where
scaleResolutionDownBy would be useful (thumbnails get
scaleResolutionDownBy).
Cullen: don't care about scale so
much, but care deeply about the maxFramerate, because of the
interaction with a bridge.
... Telling a high bandwidth browser what to do in
that context gives you a direct impact on user experience
Cullen notes that screen share in simulcast situation is another example (low framerate for unchanging presentation).
Justin: If you really want to make changes based on changes to framerate not on under user control, this gives you a way to handle that.
Cullen: But we are primarily interested in a different use case, where the capture rate and the maxframerate are not the same.
Justin: probably simplest to just go with maxFrameRate.
(No objections)
Decision: maxFramerate, already in the spec, will be maintained.
Erik: Now on Issue 370: add drop option
Bernard: How does a simulcast sender stop sending
simulcast layers? Note that the firing of a circuit breaker
could cause this to be required.
... (Aside: how does the application know the
circuit breaker has fired)?
Bernards reminds that degredationPreference is codec independent, where priority is within a codec-specfic context.
Bernard asks whether these are enough to do what we want?
Note that priority determines the QoS marking; it may also guide encoder behavior (preference of encoding to drop if all cannot be sent simultaneously)
Bernard notes that there may be a conflict here with circuit breakers.
Harald asks to confirm that circuit breakers talks about transport, basically?
Varun notes that circuit breakers is not all-or-nothing, if you detect it before the "all or nothing" level, you can shut off individual ssrcs.
Does priority apply across audio and video streams? Bernard answers that it is not just within a sender, but applies across all senders.
That might be confusing, but Harald notes that this is a matter for the IETF transport draft, which is designed not to starve any stream completely.
Cullen says that circuit breakers tells you about number of bits in a congestion context, transport tells you about allocating them within the context, this tells the encoder about relative priority at the level of layers.
Bernard: Is this enough information for app writers?
Cullen: Maybe not. Harald, does this match your understanding?
Harald: It would be logical to see that it is application dependent within a specific context. It might be logical to give priority to the smallest stream, so something always get through.
<Erik> 15 mins remaining
Justin: Minimum qp is the only way for the application to express this; "don't send this unless you can send at least this good"?
Cullen: WebRTC has no answer to the question to "what's the point at which you give up and stop sending video"?
Justin: it's browser dependent
right now.
... We need to consider two different scenarios. The second of
those is the minimum qp example. I also have concerns that this
is doing both DSCP marking and bit apporitionment.
The group will discuss how to solve this use case, possibly by looking the minimum qp stuff from ortc.
Harald notes that the 1.0 aim is also to stop adding new features.
Conclusion: Drop is not sufficient, and the group needs to figure out what to do beyond that, but it is post 1.0 work. At the moment, signaling or stats review is available.
Issue 442 up next.
Taylor notes that finished checking is ambiguous, since late candidates may cause you to re-start checking.
The trickle ICE spec gives you end-of-candidates indication, but there is nothing available to signal that in WebRTC.
First question: should 'failed' only occur after local and remote gathering is done?
This would make 'failed' more definitive, and confirms that only an ICE restart would enable recovery. That would also match trickle ICE definition. This also allows the ICE agent to conclude ICE more quickly in aggressive nomination
If the app never sends end-of-candidates, though, they would never see failed. That may be uncommon, since gathering is finished by the time failed is reached.
Apps can also determine this themselves.
Taylor's recommendation is that "failed" means you are done with local gathering. It can flip back if you get a new candidate.
Cullen asks a question about user experience: I want to differentiate between 'trying to get you a connection' and 'sorry, can't connect'. How do I do that?
Taylor: the application can send then if the peer connection ICE state has failed and the local gathering has concluded.
Bernard: is this ever a final thing? We may have a new interface come up in the case of an initial 'failed'
Justin: If you are doing ICE, that's the time to be bringing up interfaces. Failed should be terminal.
Bernard: so you wouldn't signal failed until there were no candidates that might be added.
Justin: yes
Jan-Ivar: I don't think that it is necessary to be terminal, if a new candidate comes in.
<Erik> 5 mins
Justin: failed in ICE is just a time-out. All the mandatory time out periods have elapsed.
Bernard: If you have an ICE restart to get out of that, you get a new timer state.
Peter: what is the technical value for 'failed' to be terminal?
[Several--don't send end of candidates if you plan to bring up new interfaces]
Application may not have end of candidates.
Conclusion: Peter, Justin, Taylor will noodle on this and take it to the list.
Taylor: if you have been disconnected, does that mean you will never get out of disconnected, and does that mean "failed" as well?
This gives applications a way to know when ICE restart is absolutely needed.
Bernard: remember that when consent is gone, it's gone.
Conclusion: the question of whether disconnected should be read as 'failed' will also be taken to the list.
Bernard suggests that this topic might require a design meeting or interim.
Harald: might be a joint IETF or even solely IETF issue, since this is largely trickle-ice behavior question.
<varun> +1 to do an interim for the failed scenario case.
Justin: let's try this on the list first, before getting a design meeting together.
Conclusion: agreed to try on the list first, since many of the same people would be in both groups.
Chairs: thanks for joining.