W3C WebRTC Working Group, 2 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Interim WEBRTC WG Meeting December 2, 2020

Description

December 2 Interim WEBRTC WG meeting

A

A

um So also, uh I encourage harold and janibar to try to manage the time, because we have an extremely packed agenda today uh and we're gonna try to make through make it through all of it. But uh people need to be very conscious of time.

A

Okay. So this is the agenda. We have harold for 10 minutes uh and then um on uh for 10 get into webrtc capabilities, for which we've allocated 15 um back to u.n for 10.. uh They have the nd use cases for 15 minutes and then the rest of the agenda. So hopefully we can make it through all of this, so I am going to turn over the uh floor to harold or insertable streams, and then you went so did no one uh volunteer prescribed.

A

B

Hear about here.

A

Yeah, that's okay. I think.

C

Okay, thank you. Thank you. Eric and I'll go quickly through the um through this. Basically, we have a couple of. I have a couple of decisions that need to be made on the on the insertable streams for real media and I'd like to have the working group look at them next slide.

C

So in the original in the proposal I made, I call it the three stages of the breakout box. Where stage two was opening up the media stream check, so that we can extract the media but leave all the feedback and signaling down below in the basement an extra.

C

So that's the how how you would use it next well stage. Three is the complete break apart, which that says that okay, you have to have you handle the media that goes in one direction and you also handle the feedback that goes in the other direction such as downstream has stopped. You don't need to sell anything more downstream, wants something different from what you're giving it and when ghido started implementing it. He said hey. This is approximately the same amount of complexity, I'm going to implement stage 3 first, so next slide.

C

So it turned out to be simple to implement, to take what I call stage 3, which I think is the final state.

C

I also looked at what it would take to actually shim the the proposed stage: 2 media process, immediate stream, track in javascript, and I'm not that great at javascript, but I think it's it will come out around 10 lines.

C

So, since less is more in the in the area of of specs and apis, I suggest that instead of having this uh processing media stream track be part of the spec.

C

We just delete it and add it as an example of how to handle things. If you don't just want to touch the media so comments questions. This is one of my two questions.

A

Sounds reasonable to me.

D

Yeah, that's good.

C

Okay and I'll do it and then, if someone wants to resurrect it, then I have to bring it up as an as a new new topic next slide.

C

This is from uh still then, and should we specify a face tracking api or body tracking api or object tracking api as part of the stuff that we specified and.

C

I'd like to have one, but the three questions I have is this a separable concern.

C

Is someone else addressing it.

C

If not, how do if both of those questions are answered, then? No, how do we start.

C

C

I suspect that there are other others who who are working on this. I see that suddenly, a link appeared in my life.

A

Yeah yeah, I inserted that that's a tensorflow example.

E

So there is also a phase detection api on the chrome platform status with a ycg editor's draft. As a subset of this, I guess of the shape, shape, detection, api.

F

I would also mention that cameras, for instance, do track faces for their internal computations, and sometimes they expose that data or they can expose that data. So if you have a getusermedia track in theory, you you could expose that kind of metadata that the camera is already computing.

F

So it seems that it would be good for having like some metadata. That would tell us what is the result of uh face tracking so that we could uh people could start writing things based on that metadata.

F

I I don't know where uh whether we want to face tracking that is isolated. That could use that could work on any track or just local tracks, but that that could be left to something else, but it seems that being able to define the metadatas might be useful for uh developers.

F

C

So the place I've seen suggested us as a place that they were linked together is actually specifying a means in the video frame construct of attaching metadata, such as a face description.

C

C

That might be a point, but that's also within the web. Codec working groups remit because we're reusing their video frame right.

G

Tim yeah, I I think, there's a slight I mean so the the place to look at this is that the this use case is for is for funny hats and you just can't do funny hats in a non-discriminatory way unless you've got a decent face tracker. So I think, like coming to your question about whether it's separable my view is that it isn't, because I don't see how you can address funny hats without having something that does does face tracking, and so it's sort of it isn't a separable issue.

G

Now you can delegate it, but you have to somewhere have to have somewhere to delegate it to, and I mean I I like what you're saying about like if the camera, if the hardware is capable of doing it. Yes, we should be using that.

F

So one point there um funny hat is just one transform. You could also do like face time where uh you show your tongue and then it's not a hat. It's your tongue that is changing you your face is, is a full unicorn that is, and there it's not just face tracking.

F

It's it's a it's a complex model, so the thing is like just tracking the face might be simple, but applications might want more than that and it's difficult to know where to stop in terms of which metadata to expose and what is actually necessary for the application right.

G

I think the risk, though, is that if we don't start somewhere we're going to end up with everybody implementing this in in 12 lines of bad javascript and we'll end up with something that is deeply discriminatory. For you know everybody um I think and and not meet the not meet the goal of even doing face tracking properly. For, for you know, a substantial proportion of the users. So I kind of I'm not fixed on how this is done, but I do think we need to address it.

H

um So from the web products side, uh I just wanted to mention that there are use cases for breakout box that uh have no need for face tracking right. um You know, like, like zoom, for instance, would like to have access to your video frames, but that doesn't necessarily, uh I guess I I take them back. Actually, as I say it, they may actually care about face tracking uh uh still, I think there are use cases uh in web codex generally for uh breakup box without face tracking. Oh.

G

Sure I mean I I think, uh for example, you know just turning the whole thing into black and white or or modeling an old tv, or something that there's tons of use cases, but specifically, we've called out face tracking, as as the kind of headline use case for this category and and so either. We need to take that out of the headline or we need to do it in a way. That's you know acceptable.

E

To me it sounds like we probably should discuss that requirement in the nv. Use cases, context right, but it's unseparable enough from the media capture, insertable stream context that it doesn't need to be part of that api and so can be left as a separate exercise. And again there is already an api. I don't know how good a feed it is with our model, but there is already an api being incubated in ycg to do face detection so.

C

It would be logical to include in the examples how to do face tracking using that api.

C

That may actually be a useful, useful addition to the to the document I mean the quality of uh implementation is that's a hard one.

B

Harald in which document is, for my note.

C

C

It's a dome insert of the link into the document. This shape detection, api.

C

It's a wicg document right, okay, so, if uh bernard, if you do donald knapp, you should probably probably get the link link on screen.

E

C

There's much strident previously.

C

So so back one see if we can see it.

C

Yep there it is no, that's the other.

E

I think he would need to reload, but let's not uh yeah, but.

C

B

C

I think that I think that's, uh I think it does it's reasonable to add an example using that that api and then we'll have to discuss again whether we need need to do more so I'll. Take that as instruct instructions to the editor and then we'll and then we'll leave the leave the bag open for now so status.

C

I have an experimental implementation done by guido, has landed in blink in chrome and it's available behind the flag, and I have a start of a specification and, of course the link is wrong. I'll fix that.

C

So that's the end of my segment. Thank you, incremented it in time.

A

A

Win, you went, I think, you're muted.

F

Yep back online, um so I was saying on the other side uh of the pond, so continuing with instable streams, but this time after the encoder or before the decoder, so we have made an ongoing safari experiment uh with support of the svm, transform, gs, transform and combination of both of them, with just transform running in background threads as a default.

F

It's now available in safari nightly. Last patch landed this yesterday or today I don't remember and of course it's behind a feature flag, so we decided, uh based on past discussions, we had in the past months to try a slightly different approach, which is to attach transform to senders and receivers. So you can see that there's uh the api that is in safari is adding one attribute transform to either sender or receiver.

F

The idea behind this this is that um what this feature is doing is really trying to get a frame, do some processing on it and then pass it on either to the network or to the decoder. So it's really a transform. There's, no idea of trying to get the frame and keep it or do something with it. It's really you you get it, you transform, transform it and then you pass it along. So it seems nice, given uh what what workforce group streams has this notion of transform to to use that model?

F

So, let's see now next slide what it gives us for s frame.

F

So what we added is a simple interface, a frame transform which has a constructor and which has a few methods to basically manage the encryption keys, and then all you have to do is to set sender.transform to a new transform to a new frame transform and then you can set the key and the same on the receiver. So it's very simple: it's very convenient. It works.

F

Well, we added the possibility to have the s frame, transform, expose, readable and write all gators next slide, and the idea behind that is that you can use via train transform not only as a whole but as a part of a generic transform. Let's say, for instance, that you have a transform that is adding some meta data at the end of frame then doing encryption.

F

There are cases like that, where you want to add like face tracking information and still encrypt it, so there it's good. If you could reuse the s1 transform to do the encryption, even though the appending of the metadata will be done in javascript um by making the s1 transform a generic transform stream. It's very easy. uh Let's say we have a readable and writable objects. Then you you just do a python, readable python to the sram, transform and bang.

F

You have a stream of friends that is encrypted or decrypted in that case, and then you can type it to your javascript transform that will do whatever it wants and then it will pipe it to the sender or receiver writeable.

F

So with that model we see that the combos are working. Fine in suffering, vs frame, transform is able to process either audio video or array buffers. So at the end, it's just an extreme transform is just taking bites, encrypting them and sending them. So there's no reason all three of them could not be supported. So that's what we've done next slide.

F

So the question is: can we update the current instable streams api to using the transform model?

F

So for that reason, given there's a need for javascript transform, we added in safari a specific script transform, but I will show later if we have time- and that is basically allowing you to do- javascript transform in a worker on and create frames.

F

But what I want to point out that there is that, given how instable stream is used currently where people are using it and they're implementing their transform as a transform stream. So what they're doing is they're taking the readable and writable that are exposed currently with the current api and they're piping it to a transform.

F

So it's very very easy to migrate this code to using the transform getter it. It's not changing a lot. It's not changing uh all the javascript. That is doing your transform. It's it's a few lines of code that you can change and it has a lot of benefits. I think.

F

So the first thing is that we are really talking about the transform so modeling what it is as a transform api is. Actually it actually makes sense, and it's it's beneficial. um We also like, if you look at compressed streams or encoded streams, they are not implemented as an array of readable and writable.

F

They are implemented as transform streams, and you could, for instance, think that maybe you could uh gzip and coded frames as well, and then you would be able to just set the transform uh on the sender to this uh native transform as well. So this is why I think the model there is right. The other thing I would mention is that riddle stream and right of both steam might not be enough in all cases.

F

uh We know, for instance, that in some cases we actually want to request a keyframe like if you're changing the encryption key, the transform actually wants that there will be a keyframe that should appear very soon and uh we do not have a great place with apis if we are just exposing readable writable.

F

But if we are exposing a transform, then there are places where we could put that method which are quite natural and it could be natural for speculators as well as developers and the other things I would mention in terms of benefits as the fact that we would longer expose readable streams which, with the issues like cloning, is potential food gun and we will be able to control the processing so that it's done in the background thread since doing the transform in a main thread is a potential food gun as well.

F

um So question: oh, no! Go back so I have two questions to the working group uh and I only have like two minutes left. So I'm not sure I will be able to get to the rest of uh the slides, but that's fine. The first question is: uh do the working group think that we could start adding the s4 and transform to istanbul streams to have spec uh along the lines, for instance, of the api that is currently in safari?

F

And the second question I have is whether uh the worker would think we should update the insertable streams, trust spec, to use the transform model. Instead of exposing veritable and writable objects directly.

C

I'd like to like to start off by saying that by asking is the transform attribute, modifiable.

F

We can decide we can decide that, for instance, it's modifiable, so it's it needs to be writable, because you need to assign it once. The question is whether you want to assign it twice and this we could decide either way either to throw or not yeah. So.

C

The so the reason I'm asking is that a major part of the hassle in getting to the insertable streams api was was to figure out how to make sure that the very first frame that came along was always handled, and we discovered that streams are somewhat weak in reconnections.

C

uh The other question the the worry I have with this is actually that the transfer model as described locks you too much into the single directional stream.

C

As I mentioned up in in the breakout box model, there is always two flows of data, so I think we'll end up in a situation where we expose multiple streams.

C

Both streams of media and streams of feedback data and locking us into a transform model will actually make that evolution harder, not easier.

C

So that's my main problems with this. This particular proposal.

C

Open for other comments.

A

So harold just a question is the idea that, for example, if your decrypter was for some reason too slow that that the feedback would propagate back, uh there would be back pressure that would propagate back into the rtb receiver.

C

And then back pressure is sometimes allows the mechanism- I was thinking more of things like well. When you negotiated the codec, it turned out that you had to do 320 by by 200 instead of 640 by 480..

C

So you will want to want to pass out the information after f to the encoder, which is exactly the opposite direction of where all the media is going.

F

So one use case that you already identify is um you you might want a keyframe and uh if you add the encoder side, the keyframe, you need to talk to the encoder, while usually the encoder is feeding you and then you send it, and so in the current safari api there's a method that is actually allowing you to request a keyframe and your your javascript.

F

You have a context and the context is allowing you to actually talk to the encoder and at any point in the transform you can talk to the encoder saying I want a keyframe and similarly, we added the same method so that on the receiver side you can request the keyframe and it will be sent over the network for tcp, so that the encoder on the other side will be notified, that it should send a keyframe as well and that's one way we could implement uh the the via the pipeline and that's that's working well, at least for requesting key frames.

F

um So far I haven't. I I'm not aware of any any other case where we would like additional um data to flow on the opposite way. So, for instance, uh controlling better the encoder, but I do not see how we could not fix that in the same manner, adding additional apis so that you can control the encoder. Somehow you request keyframe or you want to increase your qp or whatever it's not too difficult to add apis. There.

G

Isn't there a issue that your, if your transform changes the bandwidth requirements or changes, something about how the congestion control should work? Doesn't that mean that you have to transform the the request that you're sending out.

F

So I think that in that case we should think that on the encoder, the transform is just the prospecting of the encoder. So I hope that the bandwidth estimation should take into account the transform and somehow it's a difficult thing to to. You will need to talk to the encoder and say hey. I asked you to do one megabyte, but I'm measuring that you're doing more because of the transform, maybe in which case it will be up to the browser to say.

F

Okay, I will reduce it to 800 kilobytes, for instance, or it will be up to the javascript transform if we think we need to expose that kind of api.

G

Yeah, I need to think about that.

I

Sorry you anybody here, I think, um purely from an api point of view. I think it's it's an improvement to have it transform, because I was a little worried about the existing api uh that you have basically two ends of a cable and in order you're expected to put them both into uh from and two correctly um and there's nothing to prevent you from you know what this opens a lot of questions.

I

What happens if you feed in something that comes from a different center, for example, if you mix all these cables up so just having a simple transfer stream, I think is more uh makes it easier to understand what the intent is in the api.

C

I

C

Yeah my problem there is that, if, if this is only a temper, a temporary stage- and the next stage is where actually transform the feedback signals and and and attach the two sides entirely from each other right and the transfer model doesn't make sense.

F

uh Maybe it's it's very unclear now because we're talking about this uh signaling on the other on the other side, but we have only very few use cases or the current api is not tackling this. The transform api is only tackling this for request, quick frame which is already an improvement and which is very similar there. So it's very difficult to judge both approaches based on something where which is not precisely defined what we want to solve, and uh so I mean we.

F

We would need to make big improvements in precisely what we want to solve with the other signaling channel before judging either approaches there and I'm happy to do it. But I don't want to make the decision depending on that, because uh I think we we need. We need to make progress there and uh currently, with what we want to solve. It seems that the proposal there is an improvement.

C

So it's uh ex night and me to come up with the actual proposal for what what I think we should do next, so we're going to evaluate well. This is a proper help, so.

F

Back to the question, um so there are two questions. The first is so, let's talk about the first one. um Is there a consensus to add vstr and transform to instable streams throughout spec.

I

I think I would support that.

A

Yeah I I would not until we understand what all the use cases are for insertable streams.

F

Do you mean the ps4 in transform or the general.

A

Well, uh uh the the s frame transform, makes sense to me if it's, if the only use case is end-to-end encryption. But we've talked about other use. Cases such as taking the stream and like piping it into another transport or something like that which it wouldn't be. The transfer model.

E

So bernado are you, I'm not sure if you're saying it shouldn't be part of insideable stream, but a separate, spec or you're saying it's not good. It's the right model yet.

A

Well, I'm not clear what what all the use cases are that this spec is trying to address.

A

So if it's only antenna encryption, I understand what u.n is saying, but I've heard other things such as supporting other transports and stuff like that.

I

I think one benefit actually is that this constrains a little bit the number of use cases that we are aiming to solve, and uh I think this uh is a good replacement for the use cases that were mentioned from from the beginning.

I

um So if the existing api supports other use cases than the one they were designed for, that seems uh problematic a bit. So I think this is a good replacement.

F

And in general um we know two use cases. One is entry encryption, the other one is metadata insertion or things like that.

F

There it's supported. In both cases the overuse cases are less documented, so it would be good to document them with both approaches. You get the uncoded frames anyway, so if you want to send them to another transform or to serialize them through websocket, you can do that as well. There's no difference with any approaches.

A

Well, but in those other use cases the feedback does come into play um so understanding the feedback model, I think, is important for those other ones.

I

But the existing api doesn't handle that either. Does it.

A

No, no, basically, that you know, we've talked about it's a question of how far is this api going to go in terms of use cases you know are: are they going to extend it to support other transports? Other cases where the feedback becomes very important.

F

So when you say overtransport, currently it's tied to rtc rtp sender, so I don't really see which transport we are talking about. There.

A

Well, in theory at least because it's a stream, you could pipe this into web transport now, if that wouldn't work, because the congestion control would get all messed up, um but.

I

F

Would you do that yeah you? You want to use web codec there, where you have the encoder as a box, then you place the same as frame transform and then you pipe the results of the transform to uh the web. Sunspot. That's the model there, but I think that it's a separate world, except via the idea that you could reuse the svm transform, for instance, or javascript code, that you would write and, as I showed in the example vs trend transform, for instance, is taking encoded audio frames. So it's fully.

F

It's not related really to uh rtcrt sender, except that it needs put to to get either audio frames, video frames or buffers.

A

There are other use cases that have the same issue, though, that even the metadata once it gets too big, currently it'll break um anyway. That's just a question about the it's more of a question about how the congestion control works and whether it can be uh explicitly understood. I.

G

I kind of just I do like this. I think you should. We should go for it, because my first question when I looked at the original api is, is it a transform or not, and so like this helpfully answers the question without me having to ask it, so I think that's kind of indicative that it's useful.

C

It wasn't, it was defined as a socket in which the transport fits and that- and that was uh always a little bit hard for those who expect anything with readable writable to be a transformer.

I

I also think when we, when we uh accepted this document, it was contingent on that we would try to solve uh end-to-end encryption better than the original api was doing. So I think at this. uh This is a good step towards that. I think, by adding a transform at spring transport.

J

Yeah, I'm I'm, I supported in stream transform, although, in the example I saw that the key was exposed to javascript, and that was a concern when we decided not to.

F

J

Ahead, well, that that was just so is. Is there a way to use the string transfer without exposing the key to javascript.

F

Right um so the key is a crypto key, which is which can be either extractable or not. Extractable, right.

B

So if it's not extractable.

F

Then uh you, you cannot get it. You cannot get the key material from from the object, but you.

A

Need to create it.

F

Somehow and the creation of the key is not solved yet so you would still need to do that in javascript. At some point.

A

So I think we're reaching uh we're over time here. Is there something uh we should do on the mailing list? How do we follow up.

F

Yeah, it would be good to have an action item to understand how we can get consensus there.

C

F

C

The I think we have something approaching graph consensus stuff, defining the s frame, transform as an object, makes sense, but the actual actual api for plugging it into into the standard receiver is, I don't think we have consensus on that.

F

So if we go back to questions there are two questions. The first question seems yes, there is rough consensus and the second one we need to continue working on it and to get consensus so for the second one we check. So it seems there's a one action item for harald to provide use cases for the secondary channel and maybe bernard could also help because it seems you have use cases there and.

A

F

On that, we will be able to reassess uh the current model, the transfer model and then be able to validate either approach. Is that correct.

A

That sounds like a reasonable proposal.

F

A

We got that down in the notes.

B

I noted that we have rough consensus on uh an s frame transform, but not on how the api should look like, and that uh harald should follow up on use cases, and then we can take it from there. That makes sense. Okay, good.

A

All right uh so we're now at the capabilities portion of the agenda and I'm going to turn it over to yon ebar.

I

All right, thank you, so this is uh really slides from uh that. I prepared for an earlier meeting and uh was also presented to the ping a couple of months ago that we have the privacy interest group uh review uh some apis in both midi capture and here in webrtc, and uh specifically, they were mentioning uh sender, get capabilities and receiver get capabilities for audio and video.

I

The three issues they filed, uh which one is open and their get capability, seems to leak hardware capabilities without permission in two forms and then stats api should require additional permission and allow piggyback and get capabilities on most recent offer or answer from hendrix, such as the pr next slide.

I

So this is what we presented to them, uh basically that well, um while a site can learn about visitors, uh yeah a site could learn about a visitor's online hardware capabilities without a permission prompt or some other positive affirmative action by the visitor. That was the concern.

I

However, most of the same information is already available in the sdp offer from pc create offer, which is inherently needed, as it needs to be signaled by javascript to form uh to set up a peer-to-peer connection as described in json, and uh there are use cases for that that don't uh necessarily rely on camera microphone permission, which is data channels, receiving media and sending media other than cameron, microphones or screen capture, for example, streams captured from canvas or element or from other peer connections.

I

I

um So we already have fingerprinting notices in respect about this and bernard uh graciously provided a document. That's called graphics hardware, fingerprinting, uh which mentions which looked into this and says that information relating to graphics, hardware, capabilities provided by webrtc and stats and svc may also be inferred from other sources such as web tpu, webgl and performance api and therefore graphics.

I

Hardware, fingerprinting concerns are not where webrtc specific and that we would consider we would recommend, considering adding permission related to whether the page is permitted to know what graphics card where the user is running and that's a problem that's outside of rtc.

I

So the proposed solution for now was just to include a note relating to implementation issues with hardware capabilities and sorry, I misspoke we actually ran out of time to present this slide to the ping. But I believe.

A

I

Up with uh email later or at least on github, is that fair, github, okay, next slide.

I

So I guess, were there any questions on the previous slide, I should say first.

A

Or any disagreement with what's described there.

I

Right because this is basically our our working groups position uh on on this privacy issue, and so we would like to make sure that that is correct and that we can stand by that if there are no issues I'll just think about that I'll just continue on and please raise the issue if you can pick up some.

I

uh Similarly stats api should require additional permission. They said through two privacy harms uh leaking communication uh and plain text, uh while that might be useful consideration for webrtc identity, which supports isolated streams for regular streams. The web page already has prior access to audio and video and text. So that is not an issue and again hardware fingerprinting through the decoder, implementation and codec members in the stats api and those are certainly covered.

I

uh The issue there is similar to the previous slide. That's the next slide.

B

I

This one is from hendrick yeah.

B

Yes, I did want to follow up on uh exactly what the requirements are of gate get capabilities, um but I I think this because we have a packed agenda uh and this might get into a little bit of the nitty-gritty details. I'm happy to skip this and then, if time allows we can take it at the end.

A

Okay, uh well: how about, if we do this and we'll move on to johannes.

D

Yeah so hello, everyone, my name is johannes and I work with google and we have a proposal to add the extended media capabilities api to also include webrtc.

D

um So I guess you're familiar with the media capabilities api, but the idea is that a website should be able to just query and for particular particular video configuration and ask if this will be really a smooth experience and also it also. So it has three different results. It will say supported smooth and power efficient.

D

So the idea here is to extend that api to us include web.c both on the encode and the code side.

D

So it's currently. What we could do is from the rtc rtp receiver and rtc rtp sender to get call this get capabilities which will then just give a list of codecs. But you don't know that know the expected performance of these codecs.

E

D

So that's the proposal that I am I'm having and we would like to get input.

D

A

Is this uh kind of uh to help with web codecs, or is it just for? Is the idea that this would be used by webrtc folks.

D

Used by webrtc folks, so it's it's separate from web codex.

A

D

A

D

By like a application when it's when it when it should select the codec and resolution to use so then it can do a good selection. Before the meeting starts.

F

Yeah I like this approach. I think that in general, the closer we can get apis between regular streaming and webrtc verbatids, and this is one thing that we are seeing there. We we are seeing use cases where webrtc is used only for uh receiving not encoding at all and right.

A

F

Just a it's just a matter of technology and like being low, latency or not, that people are choosing webrtc versus uh non-webrtc, so getting api like media capabilities uh as a replacement as a future replacement to receiver standard gate capabilities seems good, especially since the the model is slightly better. It's asynchronous and we are seeing that synchronous get capabilities is difficult.

F

um There's there are also other parameters like superleads move power efficient, which might be nice, and the story in terms of sanitization or fingerprinting is, is a bit easier also to to handle. So uh I like this approach- and I I hope, like that- we can move forward with this.

I

Yeah, I think it looks good as well. uh Just a question is this everything we need to deprecate capabilities or is there more needed before we can do that.

D

I

um Does this fully replace get capabilities today? Now, okay,.

F

What is missing.

B

There's rtp header extensions and get capabilities.

A

Yeah, the thing is: get get capabilities mixes, currently the weber c1 right, it mixes rtp stuff with media stuff. So it's kind of this.

I

A

And you wouldn't want to shove the rtp stuff into the other one. So.

I

Right all the rtp stuff can be accessed. Synchronously, though right.

C

There's no, I wouldn't bet that, but okay, you would think so because it's mostly about is mostly software right. But I've been wrong before about that. That kind of stuff.

F

I, like that, you, you call rtp sender capabilities and you get rtp capabilities, so it seems like a good separation of concerns. There.

C

We do have some other access methods for rtp rtp header extensions, that we have.

C

B

All right, so I.

I

Have a question.

B

Is is it? um Do we give any sort of guidance in the spec how to define what you know smooth means or power efficient, because uh one difference between you know playing a youtube, video or something is within coding and decoding? uh What experience you get might depend a lot on. You know. Is this a one-person meeting or a 50-person meeting?

B

So I'm wondering if the, if it's less clear what this api should return or if this is just the browser's best guest.

D

I agree: that's that's one one of the problems I would say with the with the with the the airport that it wouldn't uh I mean it, wouldn't have the like at the best answer to to that meeting with the several participants and also with encoding and decoding, go on going on at the same time.

D

So the hope, but the hope is that it still provides valuable information for the for the website.

B

Yeah I I would agree that uh you know some rough information is is much better than uh no information at all, uh so I'm happy to to move forward with this, but it's been one of those questions. I've always wondered exactly what what it means to be power efficient.

F

So one example where it's a bit better as well is: we are trying in safari to say: okay, this codec is hardware supported, so it should be up in the list of get capabilities codecs. So we order the list thinking that yeah first codec is more power efficient and that's the way we're doing. But it's it's not great. It's it's better. If we could have just an attribute, saying yeah, it's more efficient.

H

From the spec side, when these booleans were defined the power efficient, the intention was that uh we not get too bogged down uh with like the details of like okay. What exactly is a power efficient power draw?

H

um uh The idea was that it was kind of a relative thing that, like if you have a software uh codec, uh you know at a low resolution which, on the given device, draws uh roughly the same amount of power as a hardware, codec or less power than a hardware codec on that same device uh for a different codec than we should call both codecs. You know power equipment um without being too worried about exactly how much power or or even whether or not it truly was decoded in hardware.

H

Having said all that, this spec is very vague on this point and I'd be happy to clarify what I just said. More.

H

D

So this is just like an example how you would call it so you define the like the audio and video content and just.

D

Call this asynchronous function. um I also have have it like a first slide with a few like uh wastes, but then they're more related to implementation issues.

D

D

But I guess, if you would have this general consensus, that a user shares hardware information, then this would be covered by that as well.

D

Thanks great to hear that you posted this.

B

So I heard positive feedback from everyone that spoke any objection, no.

I

I think it's all positive, I'm assuming it doesn't expose more information than get capabilities. It does is that fair.

A

Well, it does it does. I mean that's kind of the idea.

B

A

Does expose more.

B

But capabilities does not say anything about power efficient or smooth, or anything like that yeah. So I mean you could try and uh trial and error. You know, do a loopback call and like try to measure it yourself, but that's kind of right.

I

Well, I guess it's up to to that working group to get a ping review on this so I'll. I think.

E

It looks good positive with that.

I

E

Yeah I was going to ask about this: have you gotten any feedback already from the private cig, on on media capabilities.

D

uh So we have had some discussions with the the chrome. There is a team and I will be meeting tomorrow actually, um but I think it seemed quite positive and seemed not not too worried about the api.

D

That, from that point of view,.

A

Yeah, well I mean, unlike the get capabilities right, this could be subject to permission, so I think yeah from my perspective,.

D

I guess so so the since this this is an existing api, so the existing api does not have any permissions. As far as I know,.

H

That's that's correct. uh When the media capabilities api was launched um and like these privacy discussions came up, uh the the answer was was mostly that, like yes, we are exposing some information about your device uh performance, um uh but we expect devices to kind of fall into big buckets of uh common capabilities uh such that uh you know it. Every macbook looks relatively uh the same as every other macbook uh and every android phone looks the same as every other. You know like the with uh with some caveats right, um but uh uh yeah.

H

uh We there hasn't been a a uh a ping review of the api that, as far as I'm aware.

I

All right, well, I think, from our working group point of view. This seems like the right way to consolidate information in the proper place, because I know uh there's always going to be fingerprinting risk. Here I mean the websites today are already using things like navigator dot hardware concurrency, to try to figure out whether to.

J

I

So you know hd or not, so there are already similar uh concerns there. I guess so. Hopefully the privacy review will go well, but from our working group it seems like a better way to uh yeah yeah we're putting the information in the right place.

A

Is there an action item at some point for us to follow up with a ping together uh I mean I feel, like we've, had these very uh different interactions with ping and they're not unified in any way, I'm just asking.

A

Anyway, I think we've given our feedback on it right.

I

So hopefully uh I guess we would recommend you get you try to reach out and get the pink review.

D

I

E

So yeah, just to maybe another thought on this if the notion of permissions get into the picture and if we believe this is a better future for what you provide today with get capabilities, I think it would be useful for us to understand the impact on how one would use this income in combination with webrtc once a permission prompt comes up, and maybe that won't ever be the case, but but if there are significant changes in the underlying user interactions for that api, I think that would be useful for us to be.

J

A

A

I think we finished the discussion on um capabilities and then uh the floor is given to you when.

F

Okay, um so we are going to media capture um and we identify that web pages tend to favor using camera presets. So typically, a camera is working well for discrete resolutions like hd, sd and so on and discrete frame rates as well. And if you select, if the webpage is selecting something else, then maybe the user agent will try to down sample or do some things there to try to match what the webpage is asking, but usually web page is trying to get the native resolutions, because it's good for performances and image quality.

F

So there are ways to try to get to the camera process. You can use resize mode frame rate, ideal constraints with eight uh idle constraints, but really it's hard to master, and it's also difficult to get it right. Cross browser as well, and even though you get to a camera press set, there's no easy way to know whether the one that is found is the most suitable one.

F

So it's it's very difficult to to get it right and I believe that enrique is working on exposing pixel formats as well, which is a nice idea, and things might get even more complex if we start exposing that so the purpose of there is to define a more straightforward api. Basically, we would expose camera native presets, similarly to how it's done by vos to native applications.

F

Of course, we would only expose that after get user media granted. So that's why it's currently put in the media stream track level. That way, there's not really any more fingerprinting issue really because you already granted access to you to your your to your camera feed next slide. So let's look at uh what it could look like.

F

That's just a rough proposal, so the idea would be to have a dictionary of a media device preset with a width, an 8 and a frame rate as a range, and then there would be a getter at the mediastic trim track level to get uh the sequence of presets.

F

um We could add that somewhere else like get capabilities, maybe, but I thought that it's better to keep it separate, because cat capabilities is mostly about constraints and then there's a simple example there. Where you get the track from get media you you then select the best preset given the list of presets, and then you apply constraints and and you're done with it next slide.

F

The additional thing that would be nice is that we could reuse the same api, the same dictionary um to define what mock capture devices would be so so that way, we would be able by doing that, to test really how we are validating constraints in browsers, because our mug capture devices would be very similar to real devices, and we would be able to know when the user agent is down sampling, for instance, and when it is not so um matching ideal constraint computing find that distance.

F

We could see, we could be able to to test that. So that would be good and that's, of course, good for websites, because they would be able to use more realistic mob devices than they are currently like.

F

So that's the proposal, thoughts.

B

uh I like all of this, except for the fact that you open up the camera first and then you have the the presets, and then you apply constraints which I think would translate to the camera is open, and then you reconfigure the camera and it glitches out a bit.

B

So I think this would be user vistable that you're doing this in two steps.

F

Yes, and no uh it's up to the us user agent to do that, what we would be planning to do would be to start like start syncing up the camera until the get user media promise is resolved. So there will be a slight delay in the opening and then, as soon as the promise is resolved and the callback the javascript callback is synchronously implemented.

F

We have the final settings where we would open uh the device, so it would be only configured once there would be a slight delay, but I think it's it's fine this way and if implementations do not want to do that, they could still do what you're saying, which would be uh like what's available right now, and I believe that it will only happen the first time because the second time more, probably you have the device id. So probably you also have the presets so you're fine.

B

So there would be this window of time window of time where inside the promise resolve callback. That's when you apply constraints, and if you, if you missed that window the time, then it would open.

F

Basically, what you would do uh so you have a promise, there's a callback which is a webpage callback and then you would enqueue another callback for you to open the camera so that it's done synchronously yeah, that's one implementation, but it's so.

I

F

Up to you to do it.

I

I'm a bit concerned that this adds to the complexity, for he said there were already ways to do this, and I would have assumed that you could get most of the same benefit by specifying resize mode, none and then specifying close to the rest of the ideal resolution that you wanted and that it would return.

I

It would set the camera to the closest native resolution for you automatically and then you could use get settings to verify.

F

Whether what about the frame rate, for instance and also uh resize mode, is not always available, or maybe you have a width on a an a which is, let's say, 100 by 100., so maybe you will want 120 by 160 and then it's up to the user agent to to crop it or do things like that. But it's um it's really difficult. So then you would need to use aspect ratio as well, and that makes things complex.

I

You say complex, but not impossible.

F

uh Yeah, I mean nothing is impossible, I guess, but uh we would need people to implement uh precise mode properly and we will need the fitness distance to be uh implemented. The same in all browsers and all of this stuff as well.

F

I would not bet on that, so there we have something that native applications are used to. I don't believe that there's a fingerprinting issue, at least it's mitigated so we're closer to what native apps are doing. So why not.

I

Well, um well, I would actually hope that browsers would implement fitness distance consistently, and I know that firefox does not.

A

I

Implement resize mode, so I'm wondering how much of this would be alleviated if we got around to implementing that properly.

I

I

Yeah, I guess I would like to see more data about the difficulty with living. Without this.

F

um What do you think about the mock part.

I

I think the mocking part- I don't have a problem with okay.

B

And I I think it makes total sense to expose it this way, I'm still a little bit not sure about this idea of applying constraints. In the same like it works, I get it, it works. It's it just seems a bit strange to do it in two steps.

B

um I I do think that john evers like, if you do what he said like use the ideals. It's probably gonna work like 99 of the time, uh but I'm sure there's some odd camera, where the frame rate is messed up. So I'm wondering how important it is. uh I I think the real importance might come into when it comes to avoiding like mjpeg, decompression or stuff like that, but that's not really part of this proposal, so I I know I think I think it makes sense.

B

I I be happy to see it implemented, but I I'm also not sure if we can live like, maybe we can live without it. So I'm not really. I don't have a strong opinion.

F

uh I think it's it's true for uh with the nate for uh frame rate, uh I looked at a little bit of some of the macos and ios cameras and they have frame rates that are widely different. Some it's 10 some, it's 11, some, it's 15 16.. So if you select 15, for instance, uh maybe you will get it and that's fine or maybe it will be 30 frames and then uh safari will dance with that separate to 15 frames per second and that's a bit sad.

F

But maybe that's fine. I don't know.

A

Yeah, I think we're.

E

A

To close off this discussion to get on to the rest of the presentations, do we have uh next steps or.

I

I was just going to suggest: would it be useful to maybe expand resize mode, none to suggest that uh it might infer something about frame rate as well as with it right for.

I

Example that if you specify resize mode now and then the browser would try to find not only native resolutions but native frame rates for the closest.

F

Maybe or it should be frame rate decimation known, I guess something like that or not.

I

Or we could add that yeah.

A

All right all right, so we're gonna, move on and give the floor to tim.

G

Yeah great, thank you um next slide, please.

G

So these are use cases that you that we already kind of mentioned at tpac, and the idea is to try and expand on on the nv use cases, but basically learning from stuff that nearly works in webrtc one zero. um So like this isn't stuff, that's kind of totally uh out there totally weird it's like things that people are trying and doesn't don't quite work because we're missing some api points or some some features.

G

um When I first talked about this at tpac, it was pointed out that these aren't all new and so I've kind of rejigged it so that it tries to slide in with the existing use. Cases that are um that are in the document and sort of add, add a few requirements to those and then so.

G

There are four where we extend the existing ones, and there are three where I'm adding new uh new use cases and- and my hope is- to try and get some feedback from from the working group about which of these, we think are good candidates to work up into into adding as a full pr next slide. Please.

G

So um a quick summary on on the four we're going to kind of look at changing is um I want to improve the user experience for media calls that are preempted, particularly on mobile. I want to extend the use case for iot um to work in isolated networks.

G

uh I have a thing with funny hats, as you've heard, and I kind of want to put that somewhere. I want to put a tag down on it somewhere and um I think it's possible to do sfu and mcu in the browser with relatively small changes to the spec, and I think that would be useful add-on.

G

So uh next slide, please so the detail on this one. um Basically, when you have a gsm, call uh comes in and you're taking a um using webrtc in the browser, typically on a mobile that something will drop and which is annoying for the person who's who's, getting the incoming call, but it's not disastrous because at least they know what's happening, but the remote user has absolutely no idea why their video call is just frozen, and so the idea is to try and provide some mechanism for allowing the remote user to know what's happening.

G

um Kind of think of it as on hold music in effect or a message or something, and then the second thing is that once that's over, it would be really good if you could get the call back um and and there's a sort of side thing there, which is that if, in the meantime, somebody's browsed away, it would be good to be able to get that back as well. I'm less stuck on that, but I definitely think that you know during an in post an interruption.

G

You should be able to get back to where you were so. I don't know how you want to kind of if anyone's got like burning issues with them with these maybe uh speak now or or we could kind of pick them up at the end. I don't know how we'll work, but.

A

Why don't we ask them during? um I have a just a question when you say drop media. Do you for? Are you referring to incoming or outgoing.

G

um The behavior seems to be that um that quite often you'll lose the call completely.

G

Within typically within I mean I haven't tried it recently, but I've I, this is driven by the fact that a whole bunch of people who have implemented um what are effectively soft phones as native apps using web lib, because it's not possible to get this behavior correct in the browser. So my motivation is to try and kind of fix that.

G

G

um So I don't know if anybody else got anything else on this one.

G

So next slide, then, um so this is one about uh kind of baby monitors, respiration monitors and what you find is quite a lot of use cases that a lot of the time they're done the people viewing. The video are not that far away in the network terms from the device- and this is different from video conferencing, where typically we're all spread out over the internet. And what that means is that, if the internet, if the internet drops it's still useful to be able to communicate locally over the lan.

G

um So the idea here is that that, if you've already had a connection that was established, that they've already done an offer answer that you could somehow revive that without needing to go through the signaling server.

G

So that would allow you to continue monitoring the baby or restore a session to the baby, monitor from your you know your lounge or whatever, with that, even if your your your dsl's dropped um and that there are a bunch of use cases in particular, if you look at industrial internet where this is actually really really quite nice to um to have so I kind of- and I don't think it's super difficult, um I think it's perfectly kind of doable.

G

uh So that's that's a goal there. um Any immediate remarks on that.

F

Just want to mention that with service worker, for instance, you could have uh an offline page. So, even if your dsl connection is off, then you can load the webpage and yeah. Maybe this webpage would like to get access to the baby monitor or to the local camera.

F

I'm wondering why iot sensors could not be http servers, though, in which case once the signaling is done, and you know, where is the http server? You could tackle the http server to do the signaling and do like a regular webrtc connection. Yeah.

G

The issue is those things almost never have uh certificates, so so we're not able to do um do whatever you see with them. You.

E

G

It you get, I mean occasionally, you can, like brute force, a one in there, but it's it's a pain in the neck. Mostly those devices don't.

C

Okay, so you so you can't do https with them, but you can do you. You can do webrtc as long as the candidates are in the local network right you get a description from them.

G

Provided you can I mean the the the problem becomes, the the candidates. uh It actually comes down to being able to keep the uh candidates the same as last time or or make them guessable make them predictable.

F

Or even ndns candidates should be.

G

Right right, I mean there's a bunch of ways to solve this and it actually turns out mostly to be a nice problem, um but I I I didn't kind of want to do the solutions here.

C

I agree with the I agree with with the requirements.

G

Cool, um so let's move on to the next one, then uh yeah we kind of talked about this, but I can I again. I think we we do need to have some sense of face tracking kind of in the group um I I'm uncomfortable with it being delegated elsewhere, without us at least having it in there. Whether it needs to be a requirement here or not.

G

I I I'm prepared to um discuss or or or back down on or something, but but I do think we should have it somewhere in the group as a as a thing that we keep in mind because it it's definitely an issue for a lot of people, so we'll maybe we'll move on, because we've talked about this a little already so so next slide, please yeah um this one. This is.

G

This is really about um the idea that, uh as people get more and more bandwidth and more often get symmetrical bandwidth, it turns out that, like relatively small um conferences can be handled by their device, their own devices without needing a server and so to to handle the video mixing. So I'm interested in the idea that we could like run an sfu and an mcu in the browser you can kind of already do it with a with canvas, hacks and and web audio.

G

But I think if we actually had a requirement- and we had a use case for it in the document- then that would kind of drive some of the thinking around, maybe extending some of those apis or loosening some of them up, so that these things could could be could be done. um I suspect that kind of some of the insertable stream stuff maybe plays in here or I don't know.

A

Well, I I one thing: I'd like to get clarification: if you're talking about sfu, then you're requiring the browser to be able to receive simulcast, uh which is actually a pretty complicated thing, but is that really the requirement, or are you thinking of just just being able to receive multiple streams or I want to go down into it?.

G

Yeah, I I don't maybe yes, a few mcus is a is a mistake. Maybe maybe I should have put more generally conferencing engine, um so I mean you know. I've already done experiments with with audio conferencing in from purely in the browser and it and it works really really well actually shockingly well and um the video equivalent is um is unsatisfactory because then you end up having to effectively do a video mix on a canvas um which kind of actually works better than I expected.

G

But but you end up um basically re-encoding um you end up using many more hardware encoders than you should do, because you better end up re-encoding it multiple times so.

A

To be clear, what you want to do is take four like four streams and just shove them up on the screen in a more efficient way, just trying to understand no.

G

It's it's it's the outbound, so if I've got, if I have, if I'm hosting this, if I were hosting this meeting, you would all be sending your video streams to me and I would be doing a mix that would produce this bar at the bottom on a on a canvas, and I would then send out a single stream to each of you, which was the bottom bar um and and what happens at the moment. Is you end up re-encoding that bar for each uh for each recipient? Whereas that's completely unnecessary?

G

I only need to use one h264 or vp9 encoder to do that in theory, but the apis. Don't let me do that.

I

Well, the next topic on the slide: if we get time for it might help there right.

G

So, let's move on then next one um yeah. So these are the new new use cases, um decentralized web for kind of data, channelly, stuff, um low latency, p2p broadcast for auctions and betting and reduced complexity. Signaling. So next slide, please so yeah decentralized internet.

G

The idea is that, like there are a bunch of interesting p2p services that you can run in the browser these days and the problem is that what you see is that they are you end up having to re-architect them, whether they're running in p2p mode or whether you've got a small server like you know, a home server or something running that um that service and and so the idea is to somehow abstract the um the api somewhat so that the service is written to the fetch api.

G

But it may end up being uh getting its data over p2p link, rather than over, actually over https link or quick or whatever. And so the idea is to try and mock basically mock the result of a fetch, so that these things can use the same api and not care whether the data's arrived over a p2p link or or over a plain fetch, and it turns out, it's actually relatively simple to do.

G

If you could do data channels in service workers which, because they can already intercept fetch, um got a lot of interest from that from them from from matrix and obviously pipe. We would love to be able to do it as well.

F

I think some people are doing it already by intercepting in service worker, then sending it to a service worker client to press message and then doing the fetch doing the data channel thing in the web page and then sending back as postmessage the result to the service worker.

G

With iframes as well, um but it's ugly.

F

G

I mean, I think, that's that's kind of the point. All of these things are things that actually already sort of work, but they do it in an ugly or inefficient way, and the aim of these use cases is to try and push a little more efficiency and and beauty into the thing. um So maybe next slide yeah, I mean there's a bunch of use. Cases here for for um live.

G

Betting, um live auctions where low latency, but mass broadcast is something that um that's required, and there are a bunch of reasons why this turns out to be quite difficult to do at the moment, and one of them is audio auto play on a um a device that isn't sending media um it's just like the whole. The whole autoplay is horrifically um unpredictable, particularly on chrome, um and the other aspect is that a lot of these people have drm or or other assets, subtitle assets, and it would be good to have those somehow communicated.

G

I've been called out on the idea of necessarily doing overdose channels. um I don't it could be rtp extensions. There could be some other way, but it would be really good to get those out in a way that uh that can be consumed by the end points and ideally with as little change to the like their infrastructure as possible.

A

Just a question tim uh doesn't msc support this like if you, if you provide the data channel buffers to msc, can't you use like uh drm protected containerized media. Is that not.

G

True, I don't think you could feed it into a. I don't think, there's an easy way to feed that into a um into a video element, for example,.

A

No, it would be fed to the mse api.

G

I need to look at that dude, I mean um okay. Let me let me check whether that's.

K

Doable but I had the impression it wasn't you yes, okay, I think it's it's doable. You can pass use the data channel as a transport to reconstruct the thing and pass it to msc, but that's that's really going through a lot of hooks, and um I think I put a comment in the in the pr um there are other stuff we would like to be using to be able to use the video elements like the the media. People.

K

Do it so, for example, send several audio track with different languages and send different subtitles for different languages, but to be able to choose which one we actually play back or display, and right now, when the source is we're about to see stream, it just plays everything right. So let's say you do it? The old japanese way, with the uh a stereo channel with the the right in japanese and the left in english, then you're gonna have both language being played today.

K

If the source piped into the video element is, is a is a webrtc track and not in the other case. Well, there's a few subtleties like that, where the treatment of the media depending on the sources is different, which is uh problematic.

F

I'm no longer clear about this issue uh is it? Is this issue tackling um audio tracks coming from webrtc rtp pipeline, or is it about audio track data coming from data channels and then set to msc.

G

So the um from my perspective- and I think this is something that we probably end up needing to discuss in in more depth. uh From my perspective, this is about trying to take a video element and a video source.

G

You know so I've got a file on my server and I want to send it to 10 000 people or not a file, a live, a live stream, maybe it's a file, but but I, but it's got drm in it, and I want to send it to a bunch of video elements in browsers that already support that drm.

G

But if that's coming in over webrtc that won't work.

C

I think we're quickly running out of time, so so, let's, let's.

G

Let's move on to the the last one, which I think is um is interesting as well just cover that um so the idea here is that there are a lot of use cases where we don't need the full offer answer um for one reason or another. We kind of know what we're going to get, and this is often true for very small devices, which only have a very limited set of things or for servers that are ingesting data.

G

um So I was kind of interested in the idea of having a uri format that defines the minimum data that you need to get a kind of live webrtc connection and then have the rest of the optionalities be done as.

G

Configuration and it turns out that you only need about four variables to to to set up a webrtc connection, um and then, after that, you can kind of just send your video and things can work out what the tracks are or whatever, or you can signal additional data over the data channel. If you want to.

G

I mean I realize this is contentious in terms of big kind of not being offer answer, but I I think it's there's a bunch of web developers out there who would find this a much easier mindset.

C

There's a certain amount of.

C

Setting up connections without offer answer is, uh and is an element that runs through a lot of scenarios.

E

C

I mean public published subscribers, another name for the same thing.

A

Okay, we're almost out of time, but I I want to get clear what our next steps are.

G

So I think the the question I'd like to ask is: are there any of these that we we kind of don't want to talk about, but the way that I shouldn't work on like? Are there some that I should just eliminate.

C

I see them all.

A

C

Use cases yeah.

A

G

Okay, so I guess the next question is: what are my next steps? How do I best progress them much.

G

I'm not sure they're in a state to do that, but I'm happy to try.

A

uh How about um I think what my personal view would be to try to try to work. I will work with tim on all of these and try to. I think they would be good for a discussion in january, bring them back, maybe at the next level of detail, cool that makes sense.

B

You can summarize them in an in email thread: yeah an.

A

Email actually would be good yeah right.

I

Are we sure that the face tracking api is for this working group, so that seems kind of like a higher level thing that could apply outside of webrtc as well.

C

I

Could do face tracking on videos, images.

G

Yeah, maybe we we need to finesse the language on that, maybe it's not that with the apis there, but that we need some note there and whether it and whether it ends up being a use case. I don't know, but I I do want to kind of work it in somewhere into our documents. I think it's uh or not even the face tracking but the non-discriminatory requirement um right. I want that.

I

In some way yeah, I.

J

Think I think that, because.

E

I

Valid but whether it fits this audience.

E

But I think it would be fine to have like a requirement that we will not address ourselves but delegate to another group. I don't think that.

G

Yeah, okay, cool yeah.

A

G

E

A

We didn't get to- uh I guess, we'll, put out a doodle poll for our january meeting and hopefully take everything that we didn't get to and put put it on the agenda for january.

C

It's too, is it unrealistic to do a catch-up meeting in in december, there are some items downstream. That would really be nice to have a yes.

A

Well, uh let's ask just this group: uh you know we can always do another doodle poll. um What are you thinking harold just off the top of your head.

E

Two weeks from now.

C

Today is the second yeah so week week or 16th- that's probably the latest week. Okay,.

A

I will take an action item to put out the doodle poll and we'll see what comes back.

K

Sounds good sounds good. Thank.

A

You thanks everybody.

G

Thank you thank.

I

I