W3C WebRTC Working Group, 26 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: WEBRTC WG Virtual Interim November 26, 2019

Description

Recording of the W3C WEBRTC WG virtual interim of November 26, 2019.

A

And, as everyone knows, we abide by the patent policy and only people in companies listed on this link are allowed to make sense of contributions.

A

Purpose of the meeting is to decide on issues blocking the final candidate recommendation or over to CPC we're also trying to make progress on stats and privacy issues, and we expect to reissue a CR of whoever to see bazillion stats after this meeting some basic info, if you're here you probably know this and the slides are up on the wiki and this meeting is now being recorded. So this is what we're trying to do today, a number of issues on wherever to CPC stats and media capture. So this is on the agenda.

A

So do you want to talk to it Henrik and do we want any describe we do need to scribe? Actually do we have a scribe is Dom here? No, hmm so who's gonna be the scribe. That.

A

Is a very good question.

A

Corrine, can you hear us yes, I can? Will you be the scribe.

B

Sure I can scrub in your seat. Okay,.

A

Thank you. Okay,.

A

C

All right, so a number of features have been moved. The at-risk features as well as since we've had a feature. Freeze, we've, we've said anything: that's anything has been moved to the extensions to a separate spec and I ended up just creating one on my personal github, so it it's at web bridge. The extension we have the following.

C

A three features have been you there: the get get default, ice servers max frame rate and oh uh also, some new features there, like the player, delay hint and adaptive P time and and there's other discussions that I haven't gone through yet but I'm wondering if the working group would like to adopt the extension spec. um Basically I want I want future discussions to well, it needs a working group. It needs a home so that it's not just my opinion.

D

That will be in favor of other things, that.

A

Gets the understanding is, it would just be an editor's draft and then, when we go to ask for a working with working draft people.

B

Could comment on it? Yes, so this is not a mature spec, it just its aspect that needs a home yeah, it's probably no better home than this working group. I.

E

Think it's it's also fine to have. Whoever does the extensions back there I would tend to think that it would remain a working draft forever and whenever a feature like is shipping, then we could put it in Weber CPC if it makes more sense if it if it does not make more sense, we can leave it there, but yeah. Some of these features might end up going inwards, PC so yeah.

A

I forget implement it yeah.

F

If they get implemented, could we just after we ship about assume 100 CR make a web Odyssey? Why don't one or we was a tree yeah which are minor additions, I would say: I can.

E

Do reading stand out? Basically, so oh that's.

A

What that's, what we're all hoping, yeah.

G

Yeah that makes sense.

G

D

Seem to have constant adult.

D

Good dum-dum can really take care of reading Enrico yeah.

B

Okay, great well.

D

It does magic, okay,.

A

Okay, so let's get into the things we want to discuss today, oops.

D

Harold, okay, I'll start with the Sun codex thing, and the nice thing about this particular issue is that this seems to have gone away from completely different reasons. When the issue focused on the fact that the payload type was was being updated in an inconsistent manner between two different liquors and now it's gone from one of them. So it's not the problem anymore and so I propose that we kills this issue saying that this is not a precise problem and let's open a new one and of course, henyk took up the challenge.

D

So, okay, let's get rid of this one first, it doesn't anyone object to closing. Is you well.

G

Our FTP guy is away this week, so I wasn't able to get on the percent feedback from him that this is actually resolved, but there's so even if the payload type values cannot change their meaning, cannot change. Can the actual value change from the vehicle? And now you.

D

A as I understand it you can add more codex, more payload types with the same codec, that's perfectly legal and all the time yeah.

H

Different parameters.

D

Often, and but once you've assigned the payload type, the codec you can it's it'll always be that colic, you can't reuse it ever.

G

All right, no I think it's good to close the issue and then I'll ask our got to reopen the issue. If it's still an issue. Okay sounds good.

D

Henyk immediately took up the challenge and then and laughs and file a new issue, which is something with which I then put on the next stress. Okay,.

A

So, just to make sure 2/3 1/3 is closed and we have consensus: okay, 2, 3, 6, 9,.

I

F

D

So this problem is a little bit more actual I mean perspec received. Colleagues is only set when the type is also appear on search.

D

Or in the remote sponsor, but that means that when we're doing the offer, it's not or it's a previous value, because the reason it's a but it's a bug- I mean, strictly speaking what sins and receive colleagues isn't affecting anything down in the machinery. But it's confusing not to have it right, because when we offer a new pillow type in a renegotiation, it's possible that the answer to that offer gets delayed so long that the media sent with a new payload type arrives before before.

D

We see that the answer right and we know what pillow target is because we we created it, but it's it seems rather silly not to show it to the to the user that this. This is the colleague type for that and the analytical place to show that this in really in received codex yeah. If I'm.

B

D

We just move the busy codex setting part out of the if the scription is also block, saying that we do this for every offer. Announcer yeah.

A

Yeah I think that makes sense. The only thing that's a little bit weird is, if you're doing something like send only.

D

A

That case well, do it do we, if you doing safe direction, is send only, would you have a receiver.

D

B

You probably would it just wouldn't yeah just.

C

What you receive codex to the codex in the description negotiated for receiving and I mean I guess if, if, if you're negotiating not to receive anything, that should be an empty list, hmm maybe there's room for interpretation. If you actually include something or not, but.

D

That seems that seems logical I mean adding a comments to the to the sentence, saying that this means that, if you're, if your son only earth is empty, yeah.

B

Otherwise makes make sense.

C

So because, because early media is possible, I you can you can receive media before if I. If the answer then I think you should see which codex you are willing to receive. Even therefore you that the answer it makes sense.

I

C

I think we should do this yep.

D

D

And I'll create the PR for it, so.

G

Now we're starting.

D

G

H

G

H

G

Right so set parameters and get parameters has some racy behavior, and there are two problems and I want us to talk about this one first, but it's already called a and B in the on the github repo, so I'm still calling a beat here. So the first problem is that get parameters is not really a true getter.

H

G

H

Has side effects because.

G

It jumps D transaction ID, every time you call it. So if you, for instance, do this, where you call it, then you call some unrelated function that internally, you know also calls get parameters for an unrelated reason. When you come back to the main function, loop and you're trying to set the parameters you get it, you can get an invalid state error based on logic in that function in this case bar. So that's one problem that doesn't seem good. The other one is that we can also have a race with a remote simulcast offer.

G

If you get parameters, and then you wait a little bit and then you call set parameters because- and that's because when when said remote description gets a simulcast offer, it clears the internal slot that we return, which causes that set parameters to fail, because it says parameters are not the ones I've got. So how do we solve this next slide?.

G

So the solution came up with is to queue a task in get parameters to clear the internal slot last returned parameters and, in addition on the increment transaction ID, when this internal slot is not so this creates an envelope. Basically that get parameters that you have to use, get parameter.

G

You get parameters in if you want to call set parameters, so it solves, be its navigator with no discernible side effects, which means you can call get parameters, call some unrelated function without wondering it calls get parameters because we don't bump the transaction ID, so set parameter, still always works rather than fail intermittently. So.

D

This here's a problem sure if someone would underlay the function called set parameters.

A

G

The the unrelated function, in this case it's asynchronous function if it calls an asynchronous one set. Parameters is asynchronous, so it's actually not possible to the parameters synchronously all you're doing is you know when the parameters the parameters can only change asynchronously. Basically, so that's.

C

What so that works, but also I would argue that if you have an unrelated function that calls set parameters, it's not really an unrelated function.

D

Inside so that between tasks, all functions will necessarily return the same get parameters. Yes,.

G

D

Same values will get /, yes, okay, and so that that means that you say that set parameters can only be called in the same execution that gets it.

D

Lost time with where we decide this transaction mechanism, that was felt to be a so and so obnoxious that we said no, we won't do that right.

G

Unfortunately, the transaction ID is obnoxious in different ways right. It's a choice.

D

Of obnoxiousness.

D

E

One question: why Cannot we bump the transaction ID when the parameters are actually modified, meaning when you set some things or you set parameters or you apply or description, or you do some things like that. Why cannot we do that? Well,.

G

If we go back to the previous slide and we have these problems, none of these problems are so okay, so that would solve the problem. B is what you're saying if we only incremental when the value changed.

D

So that would require us to sort store all the parameters not compare them. Yes,.

G

For B, but it would not solve problem a which is. We have racy behavior with my negotiation.

E

May not be a it might not be a permanent, a might not be a problem. Actually, if you're doing get parameters, and then you are modifying your object and you're all set parameters on modified object, it might be good to actually throw.

D

This was actually, this was actually considered a feature at the time. Yeah right.

A

G

But what I don't.

A

Like about it, I mean, if you did call scizor scizor, set remote description right, you would want in a you would want it to fail exactly.

F

G

The reason I don't like it is, if you use perfect negotiation or if you just use on negotiation needed to abstract away negotiation. The assumption is that you can then call these high-level methods on the pair connection object without worrying about signaling state at all, and this breaks that because it'll work most of the time, but some of the time it'll sail, and it won't be obvious. What just happened was that you happen to race with negotiation, which was happening in the background, so to speak. Well,.

A

You would you would know right, because, basically you would know that something changed it and that's why it failed. So.

G

You would where you would know, after the fact that it fails yes, yeah.

C

I do think it's a food gun I think when you think about rollback and rolling back recieved codex, which there is a future slide for there's more recent right. I mean there's more reasons that it could fail. You could say that's a feature, but I. Is it useful to be able to get parameters and then change stuff, and then it fails?

C

It seems like the the safe and most straightforward and user-friendly way to use this API is to call get parameters and then call set parameters in the same task and I don't see any reason to allow other ways to use this. It's like we have plenty of food cans in WebRTC, and this is one foot can less like hey. That's good, see us losing any real use case from allowing this.

F

Since, at the same time, I would say that it's not necessarily obvious that when you call get powders, you immediately have with your solutions to call set parameters immediately without any weight on anything, because maybe you have some legitimate reasons to call some a synchronous function in your logic code, and then it doesn't work anymore. There might be some existing code right now, based on the old behavior. That is actually doing that properly and yeah from logging for some things, and then it would break here.

G

Here's my point about that. That code is racy dirty.

F

G

F

You ever get a well if.

G

It's not doing simulcast, maybe, but if it gets a simulcast incoming offer, you could intermittently get an error for this, where the.

F

Ladies, just maybe, is just calculating the pairs of proper parameters, initially sunny setting them into into anything coatings of your of the Trentham transceiver transceiver parameters. So all the parameters are good from the start. He does negotiation and after that Oh context change in the cold I'm going to set the parameters. That was not necessarily a new negotiation happening and then still the same thing. That code could be written and you would break that. The.

G

Other thing that might raise well, what we have here is this construct of get to parameters which is synchronous and then modify them and set them back now. Think about. If you have this being done on a button, click or something you can actually have this race against other iterations of itself right. So it's it's kind of it's risky to get a copy of something and then wait a little bit and then set it back. That's the yeah.

A

E

G

Definition of a race right.

E

The get parameter set parameters- API is not great at all, but right.

G

But javascript was supposed to be the antidote and not have racist. The way other programming languages have, and here we're we're, defining an API that has those yeah.

D

We're kind of this rediscovering that JavaScript doesn't live up to promises, yeah right.

C

Right it lives up to the capital promise.

H

C++ code I would agree with you.

D

Because the future will never change I mean I mean the big big question seems to be whether or not the.

D

E

Might be worth experimenting, I.

C

F

It's a good idea, I think it's a good idea, but I think it might breaks my code to do such a change now I. So we need to be cautious and probably try to see if there's actually anyone doing that right now in the code, verification.

F

So I would try to get some numbers on on that. In the sense it's a good idea, but it needs to be made, maybe more obvious in API that it is happening that you need to do it directly. You.

E

Could have a sensible.

C

Error message: when you implement this well.

G

It would be very obvious if you go to the second slide again since I didn't get to cover solution, a they're. Basically, why don't I see the host like? Yes? Basically, it would always fail. So it will be quite obvious that this is required.

D

So we probably have to introduce it by the usual way of something up: a used country and company use company usage to prick sending a deprecation message and, and then they're then starting to fade. It.

D

Usually, usually it's.

F

Doable just like need to be careful about making such a change in your solution. You say that you won't want to only increment a transaction ID when less returned parameters. In is no that's only in which context exactly where's.

G

The market produce.

F

G

The part that solves be basically that, if there's, if you're in the same task and there's no basically, if we queue a task and all out the last parameters, then that means, if less parameters is not null, it means we're in the same task or I mean yes,.

J

Basically, incremented.

C

Multiple times, if you've already called get time each this, what if I said yes.

D

So so the reason for having a transaction ID at all mister. Third, it's the way we can detect them. If someone gets back does get parameters then waits a bit and then the parameters and it will succeed if the parameters are not changed, but the transaction ID has changed and right. That is a change. So then that's required for the solution to a it always failed.

D

So I think it sounds like we have consensus that we will. We won't get to be the specified behavior and then, but it's it will take information so while to get there should.

H

We add app to the.

D

Spec saying that there's some backwards compatible call, there might be a backwards. Bible call that me. It means it doesn't fail at once.

F

E

Easier to implementations that are planning to do that soon, I guess or in in in I, guess Chrome Canary. You would ship it very soon and and fire bit as well.

D

Ship and application progress on sometime yeah, not.

G

Know if we get.

D

F

Also one thing that I see in your solution: you say increment transaction ID, in which situation do we say that transaction ID is a number we should probably not say incremented. Just change, okay right now, transaction ID for me is a UID random string, yeah.

G

This was assigned a simplification, yeah.

F

Yeah, it just make sure that we don't have increment in the final paper. Just change something.

A

Here the action item is to create a PR.

C

A

Okay, all right.

G

The an issue here is, if can simulcast offers renegotiate rids our IDs, and we looked at J SEP and it says, offers and answers inside an existing session follow the rules of initial negotiation. Such an offer may propose a change in the number of written use, but to avoid races with media &. Events with proposed changes should use a new ID rather than reusing. One of the previous values and rates without proposed changes should without changes, should reused a since the old IDs.

G

So that's from remote offers, and that differs from the local sign work for a transceiver. We say once the envelope for simulcast is determined. Layers can be removed and may be that difference is fine, because we can't really control what comes in into a remote offer, and we don't have that many options or actually like just lent out rejecting as if remote offers are invalid, is support poor choice.

G

So we have to do something so or inter not so we could leave this as is, and leave user agents to come up with something or we could for interrupt. We could have WebRTC PC dictate stronger requirements, for our implementations must respond to this. So if we want to do that, then both suggestions here, you know I- don't have a good PR here. I'm just posing questions so once send the codings length is more than one.

G

Basically when we have simulcast, then if another incoming simulcast offer comes in what do we do and how do we interpret this update to our encoding, so the options that I see is to and this these may not all be compliant with JSF so, but just to have it all, the options ignore.

H

All changes to.

G

Existing inklings there's one option: we can update the encoding and their order based on the matching writs and then I have a question there.

G

Whether order is significant and I forget, or we can update encodings based on order, and that would allow me to move rent values around, but no other, but otherwise don't allow renaming or just erase all encodings and replace with new ones and I broke out a separate question of what do we do with new new encodings that we discover no matter how we discover them based on whether the ID these are new or whether there are more than there was before we add those new encodings, or do we ignore them?

G

And similarly for removing things, basically things that are that we have before but are not in.

H

G

New offer: do we remove missing encodings? Do we leave them alone, or do we maybe set active to false I, don't know, discuss.

C

My gut reaction so take that with a grain of salt is that the order is significant. So if you have a and B and then you have B and a what you've done, is you renamed it B&E, renamed B to a and.

D

That it completely horrible, given that when the packet comes in behavior,.

K

C

D

The name change right.

C

Like that's the you should use a new ID part which I think.

D

I think that's.

G

Right but um but a must does only dictates what you emit it doesn't we cannot dictate what input we get in only how we affect behave to it, so we still have to decide if someone sends us SDP. That is these things. I.

C

Want, if they, if the, if the input is ABC I want I, want the encoding parameters to return order, ABC and right yeah.

A

I think you basically have a problem with resolving glare here because say you do air transceiver, add a bunch of encoding, said local and then you find oh I got another I got a remote offer. Now you've got a problem because you can't really roll it back.

G

You can't roll back what you said in that transceiver. Well, this is the micelle.

H

G

H

I, don't think they thought about it's.

G

Not about roll back but let's say you did this: what should happen? Should the Ramona? We could decide that the Ramona forgets to totally trash what we said in that transceiver.

C

And what what do implementations do with this? Do we just reject the SDP or does magic happen.

A

Well, I think I think Ivan. We should probably try it out henrik, but the problem. Like here's a weird example say you set 3/3 encodings in set local right. You did and reserve set three and then you get an offer for two: you you do roll back and what will happen? I doubt this will succeed. Will it I.

C

A

C

Back when you just use whatever excuse before idea,.

A

Right yeah because you already see already created three encoding, zinia transceiver right so rolling it back you. You still have a contradiction between the offer and the and the existing encodings.

A

We should try it, but I suspect it errors.

G

Well, I, guess it's not totally true that the if you I, think the way we the reason we added this in a transceiver was to simplify and say you create the layers once if you have different layers, you know stop that transceiver and create a new one. That's the logo.

C

If that's what we want, then we should just reject right. You.

J

Mean to reject an offer.

C

Throw an exception, you don't set, it.

C

Even once, if want the layers to be well yeah, but what how about the question do we do? We want to be able to support reconfiguring and transceivers with SDP, but not with ABI.

D

I prefer to reject it because making life making life more complicated for ourselves, it seems, seems like a like a bad option. Yeah.

L

D

Been spending so many cycles on simulcasts that allowing random complication because of YouTube just that we don't really think make sense yeah unless.

C

We have a used case that we're trying to support then I think to be consistent with a transceiver. We should just reject well.

G

C

G

But so this is so I think I agree that calling a transceiver and setting up encoding and then simultaneously allowing simulcast offers from the other side that's an edge case. We don't need to support yeah.

A

That wouldn't happen very often yeah.

G

All right, then, what about a assignment, an SF user, sends you one simulcast offer and then a few seconds later it sends you a different one and it added it. Added on on the layer, it removed a layer or yeah.

A

G

Thing that can happen. It's.

A

The conference participants change.

C

Might happen if the if the M section has been associated with the transceiver than the it's fixed.

G

Well, jcf does say that such an offer may propose a change in the number of ribs. Do you want to disallow that I.

C

G

G

And I don't have a strong stake, so others need to protest.

A

Yeah I, don't think you would change like I, don't think the SFU would change the number of ribs in the offer. It would change the number of em lines because the participants change, but it wouldn't change the ritz.

C

If we want to reach PR, we should not add features that we don't have.

B

A use case for yeah I, don't think we ever use case for this.

G

This is still valid, J sub, so we don't have any statement that says so interesting. It can be, can mean ignoring it, that's an option or it can mean failing the set remote description amendment we.

C

Can always say, execute the steps of J sub, except if the he reads change then abort or not.

I

L

D

Guy, if the other guys it has, is working on the assumption that we have changed the race and we haven't all hell's going to break up make use is a safer option.

C

Before, in other places in this Bank, we say you know what must follow the process generating offer described in jessup, except the user agent must treat stopping transceiver as bla bla bla bla, like we've done em and we've amended J cept with a sentence like that, and we could do the same for this.

D

Frozen anticipation for a vision right.

G

Yeah, but in this case we don't really have to contradict chase that either it says an offer. May that's only about what you produce? It's not what comes in right, so this normative language is not relevant on inputs. So I don't know if they're so similar language for how to treat input. But it's going to be valid problem.

G

Yes, we can do that.

A

Mm-Hmm, so can someone state exactly what.

B

We're or work what we've concluded here for the record. We.

C

Conclude that we, if, if there is change in an income coming offered, we reject the offer.

A

Okay Kareem, have you got that.

G

Reject there's not it's a dubious word.

D

Here so when the the sets remote description operation will fail with.

K

A

K

With a suitable, suitable error, it will fail and it will not have applied in the description.

K

Next slide: okay,.

D

Okay, yes, so I looked carefully at the completed States and it says that there are five conditions in order to have has a completely safe. It should be the state be completed after finished. Gary has to receive the education and the number remote tenets which chrome doesn't support personnel, so we'll never get that finished. Checking all kinda spares and found the connection so file connection five permissions, so yeah.

D

If it finds Kenneth pair, that's working. It goes to checking that goes to it goes to connected and so that it then it doesn't go to checking from taken to committed burns in the case where the last can be faced. Thank you, sir.

D

Only one, if there's only one them it's possible that all the other things happen before and I mean it's not possible a Crone, but did you are other bird, but this it's possible that all the other conditions can be satisfied before we finished checking the scan it and in that case I think we have found the state where it goes to check from checking to completed so I think the answer is yes son. We should rather back Ellen I, don't know to respect to say this might happen.

C

Cuz I agree with that cuz you can view completed as a subset of connected. So it's not it's not really. It's not. Two different states like if you see a chain of states that you visit like it's when you reach there, your complete that there's there's no intermediate state well,.

G

The states are mutually exclusive if we're talking about the same completed well,.

C

Okay, that's it's true.

G

It may be poorly defined with this anyway,.

C

I agree with a donut okay.

G

C

G

Completed means completed but not connected. Is that fair? No, when.

D

You're in completed you're also connected right.

D

L

D

C

Connected means connected means, you you are connected, but you have more pairs to check and completed means. You are connected and you don't have anymore pairs to check. Thanks.

G

Yeah I got it backwards. Okay,.

A

So yeah next step is to prepare a PR.

C

Okay and right so if we investigated that the lifecycle transfers I mean a code pen and it's indeed asymmetrical, and that if you are the offers, the transports are created at such local description and if you are the answer that this transport I created, etcetera. My description answer and the reason that we have this asymmetry is for the early media use case so or and for bundling as well. So so you could, you could offer, and in case the other end point doesn't support, bundling.

C

You will have several transports created and then, when you receive the answer, all the additional transports will go away if bundling was supported because you only need one transport and, if bundling wasn't supported you'll keep all the transports alive.

C

Well, what this means is that the transports you have when you really have local offer state are really just transports that are on offer and so like all the following. Slides will be about rollback. So the if you have something that's on offer that might not apply yeah. You have to you have to remove this when you roll back and right now we don't update the the transport internal slots when we roll back.

C

So the proposal is to remember the the transport slots that they were in the stable state and if you roll back, then you do revert to transport to that value. So in the most cases this will go back to null yep. You go back to the previous transport.

G

Early media can't happen on the initial negotiation. Is that right.

C

Well in any, you can think of the bundling case that the point is the point is when you you, when you have an offer, you may have a temporary transport object and if you roll back, then you you would remove the transport because it wouldn't exist anymore right. The transport is created as part of the offer. So if we roll back, we roll back anything that was caused by an offer. Then we have to roll back transfers like.

G

It seems a little ugly that we create all these objects and then, when the answer comes in, we go oh, never mind and we create different objects. It's.

D

Only maybe just.

G

Do it when the answer come.

D

We don't, we don't create different objects, we throw away.

D

C

D

C

And and the cotton works in in Chrome, but it the the it may be ugly, but it's it's needed to fully represent what can happen for, for the bundling being rejected the use case and and I think we should just live with that, because this is what's implemented, PR and it already works, and it makes sense. So that's.

A

C

Let's to revert them yep.

G

Yeah I think I'll defer to those who have implemented this and I agree well,.

A

We're trying to implement it. That's we just want to clarify this.

C

Well, the bundling confusing is always confusion is already implemented. The the bogging in the spec is that when you do rollback the according to spec, you use have these transports that don't map to anything in JSF, because you can never clean it up so that as a peer and okay. So let's record the decision and go to the next slide. So it's a similar problem here right so black in our previous slide, we decided to receive codecs are something that you set on offer. So this should sound similar to the previous slide.

C

Well, if you, if you have something that's on offer, rollback needs to revert it right, yeah, so yeah and- and we need to do this- was receive codecs because of early media. We don't need to do this with send codecs because send codecs is only updated when you set the answer, meaning you go back to stable state, so it's only applies for receive codecs. The proposal is to yeah revert the value.

C

J

It works for me.

C

J

B

A

B

Except for this one, okay, except this and oh right, so well, there's here's! The question, though, like considering.

C

We have so well now that we're reverting this beautiful internal slots. That means, if you do get parameters, and then you do roll back and then you do set parameters. The parameters will have changed. This is why I like any verse thing where you don't support asynchronous stuff, because then this issue becomes a non-issue I move.

G

The slider head, yeah yeah,.

C

This is already solved, but otherwise I would suggest that we add a you know. We clarify the perfect negotiation example with how to protect against this, but not needed. I think we can go to the next slide. Okay and- and then this is also part of thinking about what happens when you're doing when you do rollback, and one of the things that you can do is restart ice, which means that in this case pc1 is, is it wants to restart ice?

C

It starts generating new candidates, but then it it needs to rollback because it receives an offer from the other end point.

C

What would happen like because the other end point has you sent you an offer? It's the it's an unlikely R. That will mean that it won't have set the offer that you just rolled back, which means if it tries to do a dice candidate with the new candidates you generated that will throw an exception.

C

So I looked at this and I thought. How is this a problem? Do we need to document it and then, with discussions with Johnny very base? It sits like this. This is, this is not special for rollback. This is already case if you the case, if you have multiple incoming offers in offer, collisions and so I think this is like a possible foot gun, but it's a rollback purposes. I think we can close this issue and we've already filed an issue to add an example about that to perfect negotiation.

C

I think we should just make sure that that example takes this into account, but my proposal is: we close this issue, there's no issue with rollback and ice restart, yeah.

G

If I could try to clarify that, so this is not unique to ice. We starts so we can close this issue there's and nothing really goes wrong. There's the case where you get noisy errors from a nice candidate if you implement the polite and impolite perfect negotiation strategy, and so I opened.

G

Another issue to the spec right now does not talk about perfect negotiation, because it's not really an issue for implementers, but it might be a good idea to at least at an example of how to do perfect, perfect negotiation and there we would be able to explain how to work around this and the only way to work around it right now, unless we want to add change, this back more is to basically let JavaScript handle this, and the issue is briefly explained if you're the impolite peer.

G

That means, if impolite and return basically ignoring incoming offers and because we never set that offer on the peer connection object. If your connection object has no way to to to know what the would be offered would have been, and it doesn't have enough information to then silence any incoming candidates on that offer. So the JavaScript will need a boolean that basically say I just ignored the remote description, so that isit candidate may now produce failures for a couple of seconds, because there are probably candidates coming in after that offer.

G

So but I don't think we need to discuss that here. Other, but I would like to add an example on perfect-perfect negotiation in the spec I I.

C

Do think the spec deserves a perfect negotiation example, because it's yeah, it's it's quite complicated and there's this like there's one way to use the api's perfectly and then there's a million ways to do it incorrectly. So it's good, if that's actually in part of the spec and not part of a blog post yeah. Well, it can also be a part of a blog post. Okay,.

A

So but I love, I think we have agreement to close this one. Okay,.

G

J

G

We have consensus that an example or does that is that needed? Yes,.

A

C

Okay, next slide, so the RTC error. So today, like the specs Esther, so an RTC error, it's just a dumb exception and today's implementations throws the operation error. It seems if you, if you inspect the JavaScript the object, you'll see name operation, error messages, its back I, don't know. For some reason. Stacking message is the same thing, and so this is like this is what you see, but the spec says you should do RTR, which looks different than the as illustrated here.

C

The name is RTC error, and it also has additional fields and the additional fields they're like they're nice to have there. They are unlikely to cause cause backwards, compatibility issues, but if people inspect the name, that would be probably be a hurdle, and so the proposal is to to still still have this RTC error, but the RTC error constructs itself with the backwards compatible, name and and I need to look at the details.

C

If this can always be operation, error or if we need to have different operation, different names used here, I think probably we can just always hard code. This operation, error and I need to look into that that the point is: are we okay with RTC error, using a different name than our DC error, for instance? So that's that's the proposal and then then the well then they're just to point out. No one's actually implemented these. So the question is: do we need to mark the the additional fields as at risk.

E

You're saying that the name that is used in all browsers, basically so from Firefox, that's.

C

What I need to try out in practice? I didn't have time but I. It looks like most most when I searched around in chromium. It looks like operation. Error is thing, but yeah. The the point of this. The assumption that, if we want to do this, is that this actually source solves compatibility issues so I this is assuming. We do have names that are interoperable already and we don't want to change them yet.

G

C

Here is to aligned with implementations, but.

G

If implements don't agree, then we can't solve that. Obviously yeah.

A

Well, well, I mean we could, we could be still basically say you use the existing name and have the additional fields. So, yes,.

C

J

B

A

We have to yeah all.

I

A

Good, so next step is to make a PR right. Yes, okay,.

A

All right next, one wherever to see stats.

D

So this is just a matter of I would call it elegance I mean when I looked at the rtcdatachannel stats, for instance, it has a data channel at the fire field and without it you wouldn't know which data channel you were talking about and I mean it would simply be a mean mean yes that and so other stats are and do not feel that can be missing. Princeton's the channel count in RTC Kulik stats.

D

The only place you want to use it at the moment is for stereo audio. When you have video or you're a mono, you just skip the field, so it's just a matter of making spec easy to reads to say that in these cases here you have the word required. It's a dictionary and I think that's tutorial. There's no code changes in the clients and those code changes in the in this X. So it should do this, but I think but I don't see that we need to do it before Sierra. It.

E

Might allow you to to write more precise tests? Yes, I mean.

D

As I said, these are fields earth for which the stats are already meaningless without them, so the tests can event test tested it now present, but it certainly allows you to automate some testing yeah.

A

Any objections to this well.

G

The only problem might be with non-mandatory stats that are required. Is that confusing computo.

D

These are, this is just suggesting members of individual stats dictionaries.

A

D

Mean if you produce this that- and you have to include this field- if you don't produce this- that it has no relevance right.

G

Myself, yeah, okay, I, like it, okay,.

D

E

Okay, so we are back to network type discussion, so probably everybody remembers that the network type stat has privacy issues and has no consensus between implementers. So we touch shipping some result, but orden, these particular status, not as much as other stats to discuss this particular stat. It was not clear whether the use cases could be fulfilled with more private, neutral stats or not so clearly, we could try to improve this particle stat based on more precise use cases and maybe come up with a solution that could ship in all browsers.

E

Currently, it's not the case, so I believe it's not like all of the stats. So my proposal is to move move east at to the extension spec that we just which you have in a rumor team working group and continue working on it.

E

Possibly this does not require any change to implementations, so implementations shipping it currently will be compliant and implementations, not even would still be combined as well, and once it's in the extensions back could refine it. So maybe we can sign more for solutions. Maybe you can remove some values so reduce the granularity. Maybe we can reduce the exposure of is that only it catches a bit granted only for Basilica. It can impair their. There are different ideas. There yeah I think we we should try to work on it in power, so.

D

We do have an experimental stats document which is also living in the Hendrix annex.

D

And if you're thinking some, it is in an adoptable state, the.

C

The web RTC, the my other.

D

Remember to see.

C

Yeah I I think I think we've put stuff there. I mean let's just quick, look right, so it contains content type and the reason we put it. There was because content type was right.

C

It mostly contains stats that are well defined, but but we weren't sure if they were useful, so we didn't want to add them to the main stats or it contains this content type, one which is based on a RTP Heather extension, which again is well defined, but it hasn't been published as an as an as a draft. It's on the right.

C

Basically, yes, the short answer is, is yes, I think we can, we can adopt it and and refine it. It.

D

Okay, that's proposal. Okay, wizard opens oh.

A

C

A

So clearly, we're gonna remove the nut move, the network type to the extensions back. Yes,.

E

A

Okay, media capture and streams.

E

So the ping working would find an issue saying even devices is leaking fingerprinting in version it should be behind a permission from so we we made some efforts to limit profile provided information by default.

E

So currently the spec is mandating to expose at most one device of each type, no device ID, and then it gets you the media is cold. Then we will provide all available information.

E

The there are few cases where we could actually try to strengthen the model and make it as if any my devices it we are in a prompt, so one possibility is to remove the right information and the other is to expose no device information at all by default. So next slide.

E

So the first item is to remove device information. Why should we do that? So one of the issue is that usually you can have a website where you will take a photo, so you we grant catches, ready access and the website will use the camera to take a photo and that's all then on next visits seems get you Delia was granted device info permission is granted and then the device info permission is granted for basically a long time.

E

Sone user next visits, the user did not grant access to camera, but the website knows all about your device setup. So clearly, that's not great and we could try to improve things without breaking stuff. The second issue is that device information is very difficult to understand. I believe that no browser is exposing it to user, because nobody found a good way to the describe it in a in a meaningful way to users. So it's not controllable by users.

E

Users cannot actually say: oh I want to remove device in for permission or I want to grant device information. We can grant camera microphones, but not the device info permission. Also. We also tried internally to exploit some API to be able to expose device info permission and it was actually a nightmare. So it's not only users. It's also developers that are not able to understand this permission.

E

Also, this permission is no longer really needed right. The expected flow, the flow that we actually want to enforce, is to call getusermedia first and then you require any devices, and most pages will anyway need to do that.

E

The first time you visit cases as well so I think we should simplify the spec and simplify all of these by replacing the device info permission bye-bye Justin, into an onslaught that is torn the page, so the slot so there's a cure for it. Six four one first slot on the page would be denied by default, which means that you do not expose any information by default and it's granted after once a success will get you the media, call on that page.

E

If the page goes away and the slug goes away and you, if you need to get all this information, you will need to contact. You submit your game as a side note. This float can still be modified, so if it granted, it can go to denied by pewter region.

E

During the some of the page, there are at least two to use cases, but I'm, aware of where it might be useful is when the user is explicitly revoking access, so it will stop capture and it will deny access to the page, so there it makes sense to revoke a bicycle access as well, and the second case is when the page is not capturing time, for instance, the user agent could practically say you will need to be prompted again forget to the media. So you will not.

E

You will not get access to device info permission anymore,.

E

So that's it for the proposal.

G

I think I, like the intent I'm a little concerned that it's not expandable so and that it would be hard for other specifications to extend this to, for example, speaker devices just use an example even.

H

If we end up doing something.

G

Different for that I mean yes yeah. The plan is to do something different right, so I was wondering if we could get the same effect by instead of having an internal slot. We already have language on enumerate devices to filter out camera and microphone based on feature policy, so I'm wondering if we could express the the same net effect by modifying it there. So what so, so.

E

Basically, only.

G

E

G

Devices you filter out on camera devices that don't have permission so.

E

I, don't think it's extendable if you set an internal slot on the page, another another that can say. Oh this slot. Actually we change it to that value in that, even in most cases, right yeah. It.

G

Might be simple.

E

As adding a future policy and I, don't see the benefit of a our future policy, I'm.

G

Saying we already have language I believe for for future policy, where, if, if an iframe only has a microphone exposed, you only get microphones and anna-marie devices, I believe yeah.

E

G

I'm saying we could do that, we could do. We could accomplish the same thing here by saying: don't expose cameras that don't have permission right.

A

G

That I think would give me the same thing: yeah.

A

Except except yours, works for the speaker to any bar right.

G

And then a speaker device, speaker extension spec, could then say the same thing for speakers.

C

Yes, just for up sake of its rating options, you, you could also have two different permissions and say if either get used to media permission or device in for permission is granted. Then.

E

By the page right, it's not something, but that is not well-defined and that ends up being implementing one way in a browser and another way in a new browser. And then you you have like vastly different behaviors. That's not. The idea of the PR is to have like something that is very consistent, really implement and when the repairs will understand it.

G

Right- and it may be that so I agree with the overall intent and the maybe extend ability could be done simply by calling making a definition. You know in a bold the where.

E

G

Internal slot and then other specs. We call it that way. Right.

E

And usually we do that when I know the spec is requiring this kind of extension and I'm building building it right now, that's fine as well to be future proof. Okay,.

C

So it sounds like we agree. We should just like update the PR and then take it from there.

D

It seems to make that make life simpler and simpler is good.

E

E

Next slide, so so now that you have removed this, there's still the fact that we are lee akeem when we are allowing some implementations to leak, whether camera or microphone into the given system, then the information might be useful. It's not clear to me: it's actually useful. No, it might be useful. It's not actually clear to me whether it's actually used by web pages or not so that I don't know if the page can have a dedicated UI.

E

If there's capture devices or not so, for instance, show that a red icon, if there's a capture devices and not and not, show it. If there's no capture devices I'm, not sure web pages are doing it right now. So let's still there's potential issue.

E

So there are different potential solutions.

E

We could mandate to enumerate always one camera and one microphone, and when you call catch me catch you, the media, you are actually in relating the fact that your camera is gone just at the same time. We could make any devices return an empty list and then we need to provide a way to render different you guys, let's just properties or something like that- it's not clear to me! Yet what we should do, um maybe we should, at the end of the day, just kill enemy device still and done with it.

E

So my proposal for 1ce window. Basically, it's a stay to school, meaning that the spec allows usage terms to not click on information and the spec allows user agents to leak. Some very limited amount of information and birth track. I hope we can continue working on it and succeed. Issue.

B

E

Pin working group will probably come to us and say: hey, does this issue, so it would be good that we have consensus on what we want for this version of is back I.

G

D

Hear what Harold said? Sorry, oh I, think that this makes sense. I mean it it's convoluted both knowing that what we do is have some degree of backwards compatibility and knowing that and trying to figure out what requirements are each level to to consider so so I'm in favor of not not trying to hurry up on this one right.

G

Yeah yeah I think I agree. There's some value I! Think in we've gotten this on screen capture as well. That websites don't want to have a button for a screen capture. If screen capture doesn't work which happens on Android devices, for example, so knowing whether you can ask the user for camera or microphone or not that's a concept, I think is useful and the spec does allow user agents to turn off this behavior and basically, where the user gets to say.

G

Yeah I know, I, have a camera microphone, but I choose never to use those and not reveal that, because I don't want to replay all of that to the websites. That's a user choice.

G

C

Kind of like I kind of like this, either just rejecting or returning an empty list unless we know that we're breaking a lot of websites, yeah.

E

Initially, we were thinking about the entry list using the empty list, but we were not sure whether it would break the webpages or not like I. Don't I don't do at all whether or not hey.

C

Yeah I would like to find that out because I mean if, if, if we don't have permissions, to show you list of devices, then we should shouldn't pretend that we do unless they think right I mean unless we think that the the the pain working group will agree to exposing this, but I got the impression that they are not happy with expressing any of this stuff and I don't see a very compelling use case to actually like yeah, it's backwards compatible. But it's not really a use case that I would like to support.

C

So unless we have data saying this will break the web, I think we should just fix the mistake, but that that's based on not knowing how this is used in the real world, but.

G

When you say use case like having a button yeah, do you mean having a button for a camera microphone.

E

Websites that will not true camera battle, I haven't seen that kind of you I mean be web sites. Yeah.

C

Me neither and.

D

Okay, so there is a way to find a find out. A little bit more would be to hack a browser to not just to return the empty list and then put a five or more popular chap applications and see if you can actually then or.

C

Even throw an exception, but that one might be more risky like.

G

Firefox already has a Firefox already has a prep for this, which is used by tor, browsers and others, where we do create a fake devices.

D

Is different from returning the lists yeah.

F

D

Returning entities, this thing that might not be welcome battable right, it will be identical to present behavior. If you analysts, I.

E

Can take the action to actually hack web key, we return p.m. taste and go to a few popular yeah Sam. You.

A

Can you go on I'm.

E

Pretty sure I will end up, saying: hey it's working can.

C

E

Actually a read but yeah we can do it actually.

G

I went to taki, he died Oh on a cell phone where I didn't have Android permission for camera microphone and it would not. Let me turn on camera or microphone, because the way tested I had to go to a different web page that just called getusermedia and then I got the OS prompt and then I went back to talkie and then I could click the buttons I think they were using some mechanism for detecting, probably an Android devices, whether to ask at all a.

C

Suggestion suggestion throw an exception, because it would be really obvious to a website that hey I'm, doing something I'm not allowed to do rather than oh, the user doesn't have a camera or microphone.

D

Is the same same same so weirdness moving, move anybody to devices behind it behind the permission and move the whole call behind information.

D

Yeah I mean that's a breaking change for sure I mean we might not care about most of the cases that break, but it's a breaking change. Yeah I definitely go for doing. Go for doing these payments to backup for how what a face post.

D

A

E

A

Need to move on okay,.

E

I think an action to do that that said, Safari is not supported in all weather, see web sites, so it would be cool if some people on Chrome could do to do it as well in a website's bottom in support, chrome, okay, okay, you should 69, so it would have been nice if we actually enforced user gesture. Forget user media from the start.

E

We cannot do it anymore. It's probably not web contact able to mandate it, but it would still be good to try to to enforce it in a few. In a few cases, one issue that I was made aware by web developers is the case where a user enters a video call user denies camera microphone access initially because they only want to listen and later on.

E

Do you actually want to ask the question so they they want to turn the microphone, but, of course, if you do call it user media, it will be denied so the constructions they have is basically to reload the page. It works in Safari, probably in Firefox as well. You can provide hints to the user to reset permission using the browser UI so that that should work in Chrome and Firefox, probably in Safari as well for an edge case, but still it's it's it's not great.

E

So one purpose all I have is that if getusermedia is triggered by we usage, it's yes, sir and permission is denied. We set permission to prompt and proceed.

E

The scope we we are planning to do in Safari is to only.

E

Override her permission for temporary permissions and temporary permissions is a concept that exists in Firefox and Safari. Basically, its permissions with lifetime is paged. I, don't think chrome has such concept I.

D

Think from always stores stores the result of after accept or deny right now so.

E

Yeah I wanted to discuss this proposal, I'm, not sure, there's any spec change or maybe we could provide some spec changes. But what do you think.

G

Yeah I was going to ask is anything in the spec that prevents Safari from doing this now, I think.

E

E

Temporary permissions right right.

G

There's a concept of one-time permission that and privacy indicators I have to go away when the last track is stopped for live indicator and that's a separate, accessible indicator before permission. But that's all it says: yeah.

C

Well, while permissions and prompts, and all that stuff is somewhere in between spec and and up to the ground, sir I I do think, like that son like whether or not you display a prompt I, think will influence whether or not people call the API, so I do think. All the browser's should should do the same in the spec should like I like this.

G

Well, I, don't know that we're suggesting anything here. So you know there's no PRI like to move on.

E

G

Okay, I, don't know, I think we can skip it. Okay,.

D

So there's what there's one thing about about rolling back to the permission, it is look glowing rolling back to prompt, which is that I fear the loop that says: hey give us permission to a camera, no give us permission to the camera, no to the camera and.

G

I commented an issue that you know this would remove. The only incentive to not spam on page load is that you.

E

Would actually risk.

G

Being blocked, yeah.

E

If you have a user click, then the only way the user can probably do. Things is probably to close the page and Martha will be able to cross the page or the user will be able to deny or for Wes. In that case it will not be anymore, so you grab to up to two solutions. The.

G

User agents can already, you know, work on the best I, don't know that we know the best behavior yet so I don't think a spec should necessarily come in and say it knows. The best way, I think an experimentation here is good.

G

Alright, so I have five minutes for my slides.

A

Yeah go ahead. Alright.

G

So basically, a the ping opened another issue which was only reveal labels of devices users given permission to because the privacy climate has changed basically- and this goes beyond fingerprinting and exposing info on all of a user's devices beyond the granted ones. Also reveals actual private information to user, didn't intend to share about what they owned and what's I have like that next slide.

G

But hold on which devices has used a given permission to, and so I actually found out in both Safari and Chrome. When it says the site wants to use your camera and microphone, it's actually cameras and microphones, plural, so you're sharing all your devices. It means that not revealing labels would have no meaningful, no meaningful difference in Safari or Chrome Firefox. On the other hand, by default only gives you one time permission to one device now to be fair. If you do click the remember this decision, we also grant to all devices on next page.

G

So the issue here is Firefox shares all labels instead of all devices. So if we take the ping request literally, it would only make Firefox non-compliant, which is the most private option and forcing it actually to weaken its privacy to comply if it wants to implement in content device selection or it would need, it would suffer a prompt like this, where you just get question marks from the other devices, so I kind of view. This as pink people can see in the window when the reality is that three out of four houses are missing.

G

A wall where people just can see us and walk in so I think what ping really means here is that they want a privacy by default flow, which they posted an issue where the site asks for a category or category of devices, and then the browser prompts the user for one, many or all of the devices, and then the site gains access to only the device and label of hardware that the user selects. So Firefox mostly does this already by default, but others do not, and so next slide is: how do we?

G

How did we get here?

G

Why do we expose our labels to make in content device selection possible- and here are two examples from hangouts and appearance and as far as I know, there's no other reason, and it's not terribly exciting, to see these selectors that you know they're not terribly exciting after seven years of really revealing all this information they're, basically just glorified Pickers, the next slide.

G

In hindsight, this could have been done in Chrome, meaning the browser could prompt instead and here, a couple of prompts that are just modeled on the success of get display media, where we do exactly that and in chrome selectors, remove the need to grant all devices, and there may be other reasons to grant all devices that this was I, think a primary motivator because you want to be able to- and this is still clunky in Firefox in content device selection.

G

You pick a device in the list and then Firefox also prompts you get two prompts some other benefits of this is that for desktop user agents cannot implement previews for all choices, even non-choice and ones. For instance, you could put all the cameras with a grid.

G

You might want to not want to do that on the initial prompt, because it could scare users, but on Reese electing on changing your device that might be useful on mobile eyes can actually be tricky because most mobile devices, don't the hardware, doesn't allow you to open one more than one device at a time, and there are tricks that a browser can do that. Are hard to get right, like temporarily mute the current device in order to show a preview of a different device stuff like that next light?

G

So this is a hard problem that we've currently foisted on sites and they haven't been very productive, but then counter-argument most users have one camera or they have an easily distinguishable front or back camera, which you can use. Websites can use constraints to find that one so for most users having a selector is too much information. So Firefox is worse on that one next slide.

G

So how do we solve this? So one solution is obvious: is to have a dedicated in user experience in the browser for users with a single device versus multiple devices, so a dedicated in Chrome device selector when the user has multiple devices.

G

So this proposal here at PR 644, is to mandate a selector and gum Gettys media, like Firefox, has, unless the constraints provided reduced to one device, so this would mean a following changes: if we consider a user which previously has persistent permission for camera, if you just call get using media video, true, you want to get granted if the user has only one camera. Otherwise you get a selector if you specify facing mode. This is how Firefox works.

G

Already constraints are ideal by default, so that doesn't you still get a selector in Firefox and the benefit is that the user facing camera is now just a default choice and that selector the same thing with the device ID and the wear at time or not going yeah.

E

What happens if you're in front and then the user is saying? Oh you.

G

E

Will actually plug in a camera, because, oh no, that's not the one I want you know. Well, then,.

G

So, ideally, the user agent should update the list right.

E

You're going from prom to select oven.

G

A

Firefox implements.

G

The selector in the prompt right so just like forget, display media. The prompt is the selector right. So it's saying the site wants to use your camera, and here you get to pick which camera or microphone so the.

G

But the the last line in this table here is where you specify an exact device ID, for instance, with an exact constraint. In that case, it's clear that the website is only asking for a specific device and that reduces to approval denied, so browsers could have. Firefox could have a much simpler user interface in that case, and but it doesn't at the moment, it still gives you a quite noisy selector, so gain.

E

I solve the last case. I would prefer a thicker as well so that, as a user, I wouldn't know which camera I will grant. If I have to camera, then having a presentation of what will be shown to the webpage is actually nice sure.

D

Like this, one I mean speaking because it's the last minute and is that it please currently the perused cases.

D

In the case, where you have two cameras and you and your you're currently Department and it's consistent about picking the better camera, if.

D

This behavior that the user has gotten used to a Nicole and a programmer asks has allowed for now. Now with this it would it it would be proper pop-up, a selector in the middle of the flow that is entirely a gratuitous, since the already has access to all the cameras, there's no permission involved and in the previous selection of the that the browser did was consistent for that browser and those those cameras. So we're introducing the memory another step in the a in a startup flow, with no benefit that I can see the.

G

E

See some benefits I agree that we have to think a lot particle model, because there are some potential relations between we need to fix.

G

E

G

Clarify I, don't think this breaks any and any infant hangouts that implements a picker has to use the exact divided constraint if it wants to avoid a really weird awkward behavior than Firefox and I believe it already does, if you already know which device to use their license use last time, you pass that in right and then it just works like before.

J

G

C

G

Just made to say that the only weirdness here is that the current prompts that are vague. Don't actually tell you which camera you're sharing, and this will force browsers to to include that in the prompt.

D

The principal side of thing is that which I think we're stepping over the edge from of stepping too far into those into the area of specs trying to mandate user interfaces. Yeah well.

G

The goal would be for the spec if the ping, in order to satisfy the ping, it has to be the. If you see I changed the title here from not the only revealed labels of devices user has chosen because and all the educate in all the tricky cases. Here it wasn't the user that chose the device. It was the browser. So that's what this gets at. So it doesn't try to mandate how to do your UX.

G

It mandates that you're, you fairly ask the user so that what device has been granted is clear and meaningful and right now it's not I.

B

A

We're out of time, I.

E

Just want to mention that if you, if you're just requesting camera, probably the prompt is only about camera right in all browsers, but still we are announcing all the microphones and we should not and that we should fix it.

A

C

This would only apply when, when you supplied constraints where multiple devices could potentially apply, it's not exact. So so, instead of the tiebreaker being completely up to the browser, you're saying that the the tiebreaker is, the decision actually picks in a selector menu which cameras open well,.

G

Either a site is asking for a particular device or is asking for what else the user to pick a device, and you can already know that by calling enumerate devices to get the number of devices must get here, and the benefit of all is that we could retire label from enumerate devices entirely.

E

Yep, it would be nice to remove labels. I still think that thinking that the webpage is nice and will force a specific device. Selection is a potential issue to the people.

G

Right I think it minimum the user agents that grant all devices should say some in the prompt and yes and it's tricky.

D

G

Right and that gets tricky because all it may be all devices at the time that the prompt is shown because you haven't plugged in anything, but you could plug in something after the fact and in Access in s access, 2.2 yeah. So it's all current and future cameras in this session old cameras right well in Chrome, it's persistent! So it's all cameras forever! Yeah I'll tell you look.

D

I

Thanks everybody, ok, stop recording.