WebRTC WG Virtual Interim

14 Jan 2016

Agenda & Slides

See also: IRC log


Harald, Erik Lagerway, Dan Burnett, AlexandreG, Vivien, AdamBe, AndyH, SherwinSim, PeterT, TaylorB, BernardA, Dom, AdamR, Cullen, Shijun, Randell, Varun, Tim Panton, Roman Shpount, Mathieu Hofman, Justin, Alan Johnston, Ted Hardie, Jan-Ivar, Maire Reavy
Harald, Erik Lagerway
AlexandreG, Ted Hardie



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

Contribution guidelines

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.

Pull requests

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.

PR #434: Change setParameters call to be Async

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.

PR #454: Add contributing source voice activity flag

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?

PR #462: Add PeerConnection.activeSender() and update early media example

harald: seems good to me

erik: does sanybody oppose to this?
... ok, consensus it is.

PR #463: Add more explicit language about transceivers, MIDs and rollbacks

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

ISSUE #441: RTCIceTransports needs to be DOMString not enum?

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?

ISSUE #389: Should have a "closed" RTCPeerConnectionState

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.

ISSUE #412: Framerate knob for simulcast

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.

ISSUE #370: Add drop option for RTCDegradationPreference

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.

ISSUE #442: Impossible to know if ICE agent is "finished checking", for "failed" and "completed" states

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.

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/01/15 12:57:01 $