W3C WebRTC Working Group, 14 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: WEBRTC WG interim 2021-12-14

Description

See also minutes at https://www.w3.org/2021/12/14-webrtc-minutes.html

04:26 Call for Adoption of Region Capture
20:30 Call for Adoption of Media Capture Transform
29:10 WebRTC Encoded Transform - key frame request API
43:15 Issue #2698 / PR #2704 - add PAC timer; "new"→"failed"
47:35 Issue 47: RTP Header Extension Encryption
56:00 Issue 69: ptime is mentioned but not actually settable
59:21 WebRTC-NV Use Cases CfC
1:00:00 Low-latency P2P Broadcast
1:12:11 Decentralized Internet
1:21:40 Reduced Complexity Signaling
1:30:36 requirements N30, N31, N32, N33
1:43:04 requirements N34, N35, N36, N37, N38, N39

A

Okay, so let's get started. This is the last webrtc working group meeting of the year, it's december 14th and I think we're going to have a full two hours ahead of us.

A

So a bit about the ipr policy we conform to the w3c patent policy and only people in companies that are listed on the page are allowed to make substantive contributions.

A

uh We're going to cover the calls for adoption that went out and completed yesterday. uh U.N will talk about whether to see encoder, transform api.

A

We'll then get into a few prs and issues from over to cpc and where we see extensions and the final 40 minutes or so of the meeting will be devoted to the call for consensus on whether to see and be.

A

Write a little bit about the meeting. We do need a scribe. Do we have a volunteer.

A

You don't have to get everything, just understand the decisions and write them down.

A

Someone got a volunteer.

A

We do need this, so we don't get a volunteer. It'll won't be much of a meeting.

A

Can I enlist you dumb.

B

uh I can't stay until the end, so if someone comes.

A

Oh, that would be not be good, then um we do need, because we're going to get into the weber cmd use cases and need to figure out need to write things down.

A

Any volunteers.

A

Can we draft you ben.

C

D

It needs to be on the irc.

B

Take note somewhere and then send them to me at the end, and I I'll publish them somewhere. So if you want to do that locally on a google doc or whatever, the only thing we need is nuts.

A

Okay, thank you. Thank you. Ben all, right a little bit about the code of conduct. We operate under the w3c code of ethics and professional conduct, so it's fine to be passionate, but let's try to keep things cordial and professional a little bit about the meeting we are still being recorded so be on your wrist behavior.

A

To get, we probably will need a q so we're going to type plus q in minus q.

A

um I'm going to ask uh harold: can you run the queue because I'm probably going to be talking a lot and if, if you're talking, maybe yanivar can run the queue, but let's I'll ask you to do it primarily and then ask use headphones when speaking, so we can avoid the echo and please state your name.

A

um I don't think we'll need a sense of the room, but if we do we can use polls just a reminder about document status, just because something's in the repo doesn't imply it's been adopted. That requires a call for adoption which we're going to be talking about editors drafts, don't necessarily represent working group consensus. We have an example of that here.

A

With the end, the use cases, uh but we try to run the call for consensus on the mailings to determine that uh we can merge prs that lack it, and we did do that for weber to see in the use cases.

A

Okay. So here's what we have uh we're gonna have talk about the calls for adoption, the transform, as we said and finally get into the use cases so call for adoption and um actually, if harold, you could also look at the time we're going to try to run this uh to about 8, 30, pacific, so the half of the hour okay. So we had uh the first one is region capture.

A

We had a cfa announcement that ended on december 13th. We had seven folks uh for adoption, one with concerns and then one objection, so we're going to talk about the concerns and objection.

A

So one of the concerns came from jan ivar. I don't know yanivar. Do you want to speak to this.

C

uh Sure, uh well, the slide conference as well is basically that uh we think this is a good feature, uh but we would uh it seems better. Our preference would be to restrict this to get viewport media which we're uh we have. uh We owe a standards document on, but we have some consensus about how to proceed there. So that's good um and because that that's a use case where that makes a lot of sense to us, because the application has full control and direct control over the page and they have.

C

uh We can imagine applications and use cases where cropping and the entire not capturing the entire document. It makes a lot of sense. It seems less good of a fit for get display. Media, mostly because we feel get display. Media has some uh use uh security concerns in that it's not always clear to users the scope of what they're capturing and that we worry that this cropping feature uh exacerbates the misunderstanding.

C

Further in that you're not you're, not just cropping uh one document you're, not just cropping a part of one document, you're actually cropping the tab container uh and all navigation on that page, and is that clear? It's already on clear and get display media, sometimes sorry about the dog, uh but uh we worried that this is the wrong foundation to build a document cropping tool on top of.

A

Okay, thanks johnny, but we also had an objection from un. uh Do you want to speak to this u.n sure.

D

So I also think that there's a use case there and the current draft is addressing this with the assumptions on get report, media or capture, handle basically and get viewer media is fully unspecified, so it's unclear how there would be a one with the other and capture handle is also uh fully unspecified, so it's unclear uh how it will interact and the idea that um a single solution should apply to both of them- maybe maybe not, but it's it's really difficult uh to reason about it.

D

Reason about this assumption, that is in the draft, because we we don't have captcha and all we don't have get viewport media. So I think we should be clear about the scope and there the scope is not clear. So it would be good to say, okay if we really want to go for it.

D

Let's uh focus on uh supporting relation capture in get report, media or get support for region capture in galaxy media plus capture handle and then have a solution, and then we can be very specific and we can try to have a more uh generic.

E

Mechanism, you want to extend.

D

It to get your pump media later on or, on the contrary, from get your media to get display media. But.

E

D

I feel like we we're not in a position yet to uh I think we we need to work on the foundation and then then on that, but I'm fully supportive of working on that.

A

Okay, uh actually, why don't we have uh a little discussion? I don't know if there's anyone in the queue.

E

um A lot here, I'm in the queue and the.

F

Team is also there.

E

Excellent, so uh please forgive me if I uh so this is my first call for adoption, so it could be, or it is the first one that I can remember right now. So if uh I'm a bit off topic- or if I don't understand the procedure 100, then please, let me know so. I would like to address both concerns and objections.

E

uh Number one about get viewer media. I agree that uh this will be very useful with get viewport media. um Unfortunately, git viewport media has been always in the pipeline for over a year now, and I think that we need to make progress.

E

Second, I think that get display media will always be interesting and it will always be a venue by which some users are going to start self-capture, and I think that's why we uh we would want to support it anyway, and I think that it's relatively easy to make sure that the mechanism works equally well for get viewport media and get display media, and I think the currently proposed mechanism does just that um second about capture handle.

E

I disagree with you and some assertion that uh that region capture requires capture handle uh right now we are only pitching uh region capture for self capture and what you can do is you can just optimistically hope optimistically called crop2, hoping that the user indeed chose to capture the current tab, and you would just get an exception if you chose to if the user chose to capture anything else, because then crop2 is just invalid, as it's currently specified and in the future, when we do want to expand this, to also work for cross tab capture, then we'll need capture handle and that's why we're not discussing that option just yet, because capture handle is still upcoming.

B

A

Yeah. Thank you for that clarification.

A

Anyone else in the cube.

G

Yeah, I'm tim hansen, I'm in the queue um I wanted to ask anybody, I'm trying to understand what the perceived risk is of doing this now you're saying that there's a you potential user confusion, but this is surely this just reduces the thing that, like it reduces exposure rather than like, the user has already agreed to share to to capture this thing, and the only thing this does is reduce it. I got, I don't see what the risk is there.

G

Maybe I'm missing something.

C

I know that that's a good question, but so it's hard to explain, but um let me try again the uh the the distance between what a user may think they're capturing and what their actual capital and what they're actually capturing increases here. Because not only are you, I think a lot of people already would be surprised to learn that when they share a presentation like this we're looking at a set of slides right now, I think bernard is presenting. If bernard were to type a new url in this tab and go to a different page.

C

We would see that.

A

C

Not not actually he's not actually and his entire user interface experience is that you know you want to present. You click yes and you get these thumbnails to pick from and there's my slides. I see my slides and I pick those but you're not actually capturing the slides, you're you're capturing the tab container that happens to contain that slide. Google docs document right now, so we're capturing one level up.

C

So if you hit the back button, for instance, if bernard were to hit this back button in the slide's presentation right now, he might accidentally share whatever he browsed before the meeting correct. So now we're adding.

A

A cropping control.

F

C

Of that, that sort of builds on the user's understanding that oh you're capturing a document, now you can even capture the subpart of that document. It becomes even more confusing. I think that you still have the gotcha of the back button, but if you hit the back button now, not only are you no longer broadcasting that small part of your page, but your I'm guessing cropping would turn off and you will not.

E

C

E

Entire capture and.

C

E

Would actually uh turn off because currently region capture pre-assumes uh presupposes that you're capturing yourself. So if you're, you know both the capture and the capture, the capturing entity and the capture identity are in scope. At the same time, right they go out of scope. At the same time, too,.

G

So I'm I'm still not feeling that there's a bigger risk here I mean yes, there's a. I understand the risk of the back button, but I don't see how this increases it or if it does it's because we presented the region wrong somehow, because, like there's, actually no need to tell the user, which region that you're you're you're cropping to.

C

I believe, if I understand the proposal correctly, there's actually no additional security benefits from cropping. It's merely um because you're consenting you're always consenting to capturing the whole tab, always.

G

Right so I'm claiming security neutral, like my perception of it as being is, is that it's security neutral, which is why I don't quite understand what the objection is, but I.

C

I mean security neutral, but I I feel that it's the wrong foundation, we're lulling users into the wrong mental model further. So uh I would.

A

C

That's also true of tab capture.

A

With get display media right.

C

A

C

Was I was, I was talking.

A

C

Emilia with tap capture yeah and get viewport media, I think we're good because and get input media. You are actually only capturing the document.

H

C

Has its own set of concerns? If you, you can't follow a link necessarily and have it captured so so I think you.

A

C

Media this makes perfect sense, get display media. I'm I'm also hoping that someday. We can introduce uh site isolated capture to get display media, which I presented a little over summer.

C

So I think, there's room for user agents to try to mitigate this over sharing risk in both models perhaps, and that someday we can have secure capture on pages where you would either get warned or captured, would terminate if you navigate away right.

E

uh I would like to re-ask uh tim's question because uh we're not talking about uh well at least we're. The proposal does not address get report media right now and does not address, get display media for any type of capture, but rather only for self capture, in which case the back button would just stop the capture anyway. So it seems like any concerns of lollying. The user into a false sense of security might apply if we one day try to expand this proposal to crosstab capture, but it does not apply for self-capture.

C

So, are you saying that.

E

F

F

So it seems that uh the current proposal, as stated, is uh stated in terms of get display media simply because that's what we have and that's what we currently have and can specify extensions too well get viewport media seems to take some somewhat more time.

F

Well, the current property of the current proposal is that, since it's only capable of of for working in self-capture, it will uh work only in self-capture, so navigation is not as accurately as you.

F

I don't think. I agree with some of the other statements about letting the user into into a false model. It's it is what it is.

F

So I think we should adopt this and uh and uh and iterate we should we shouldn't. uh We shouldn't wait any longer.

F

Hey, let me see, then we have yaniva and you end on the queue.

C

Yeah, so I should point out that I did not actually object to this proposal. I also agree that uh we should move forward.

E

C

uh But my concerns, uh I believe there are unaddressed, concerns in get display media and I see the value and get people. I'm surprised to learn that um so you're saying this would only work for self-capture so, but so far self-capture would get display. Media uh still allows capture doesn't terminate if I then navigate right. So are you saying that if the user uses this cropping feature, then the capture will terminate.

E

No, I'm saying that we're we're looking at the subset of get display calls so the subset in which the user chose the current in that subset. Yes, capture terminates. If you have, because both the because both the capture and the because the capture is being unloaded, that's the important part.

A

E

F

As long as we as long as we can't move media stream tracks off the off the tab, then yes, the media stream track, will go away once you navigate.

C

Right, no, no! That's a good point.

A

Yeah, so perhaps we just note some of these secure security concerns that apparently uh let by people put it in the document and would that address your concerns.

C

It will it would for self-capture, but I guess uh we'll have this debate again when we introduce capture handles.

F

Right, correct and and transfer will be stream tracks.

C

Yeah, hopefully not to service workers, so I think we're good. There.

D

Okay, I'm in the queue, so um I I want it first um to state that, uh yes, the current only use is self-capture, which is something we we dislike and we prefer not people go there. So that's the first thing and uh if we, if we had to do something like that, my guess is that we would probably not design an api where we are trying to define an opaque object that would be allowed to be transferable and so on.

D

So a lot of the api design has foods of where we are going because just capture and all because maybe you will get report media and all of this is not available. It is not a thing, so we we are clearly trying to design something.

D

um Some other work that we plan to do, and I would really prefer that we uh do the work first and then this one. uh My objection also lies in the scope of a work, then, because the scope.

E

Of the work is.

D

Really not clear to me and that's something: we need to precise.

E

um You should be aware that this is already an origin trial for chromium m98 and it is perfectly functioning without get viewport media or capture handle, and you can.

C

E

You can write the demo right now and enjoy it without any other uh and without any other features.

F

Yeah, so we got seven minutes we're in left in this segment. Yes, so.

A

I think we'd I'd like to go on to media capture, transform yeah, that's okay, so uh the cfa for that also in the december 13th- and there were basically eight for adoption, no objections. uh One of the adoptions had a concern, so this concern also was from un. Do you want to talk to that? U.N.

D

uh Sure I was trying to provide a list of uh if we, if we're, how are we going to be successful with media capture transform if we are using the streams model and uh first we need to have a good foundation for stream support.

D

So there's the pr there, which is just a rough proposal, so we need, as a working group, to put the effort to actually make sure that the stream, spec and stream's implementation will be daily, which is uh so that's something we need to put in in the document and also more generally, uh this uh work. There is the first one which is trying to uh push for uh streams for image manipulation.

D

So far, all the previous examples of uh image manipulations were callback based in bit web codecs or shape decision api whatever.

D

So we are branching now and we are trying to say: okay, that's a better model and uh let's embrace this model, which means that if we go there, we would need to push web codex force and uh over api designers, like dictation api, to consider using streams as a foundation piece so that there's no mismatch in terms of apid.

A

Yeah, I just had one comment: you referenced the shape detection api uh um and I would note that this also includes face detection, which was what we discussed at the last meeting. uh But does it uh somewhat differently.

D

Yes, it's a it's a post-processing step, so it's really a transform. While the thing we discussed was hey, we already have the data, so let's just expose it.

F

So yeah just uh just comment that I think I think web codex made the wrong decision and it was easy to write the adapter. I've already done it. So I don't think that consistency with web codec is a big deal.

F

The shape detection api, oh other than switcher. They don't not. My issue.

D

You're trying to push for a model like promise, promises were done in first place. So now you have some some leadership and you need to accept it and push for promises and put forth basically.

F

And then push by push by demonstration show that it's useful.

F

When audio have raised your hand instead of typing q plus, yes,.

A

Right, um oh sorry, I I just wanted to point out that um you know I understand the uh push for consistency, but actually it doesn't feel that bad when you're writing code. So I actually kind of like the shape detection api, I'm not even sure how it would work as a transform stream, because basically you're you're kind of giving it the the individual video frame. Although it's a an image bitmap um and getting back a face detection like if this were in a stream, I don't I'm not sure how it would work.

A

Basically, you would still have to get the face detection on every frame, so it actually seems that api seems pretty natural, and I also, as harold said, I just kind of disagree with the way web codecs did it, but on the other hand, you know I've also written transform streams in web codecs and it's not too terrible um and that there are actually some things that are actually that work a little bit better in the current model like if you have to skip frames or things like that in the middle, uh because the encoder is too backed up.

A

It actually gives you a bit more control than streams would so I actually don't feel that I mean I understand the consistency. Stuff is maddening, especially when you have problems with things like memory allocation like to get everybody to use the same model, and I think we're kind of stuck there, um but I'm not sure that we have to have strict consistency.

A

Although I would probably learn it probably a good idea to figure out how the working gifts can coordinate, because it seems like everybody's doing their own thing, but.

F

Okay, so we should probably see if we have a decision here.

A

um Well, I I I kind of think we do, because uh we had no objections.

F

Yeah so let's just record record this session together, but yeah.

A

um But we should, uh you know, keep on top of the stream stuff. I guess yanivar was this your slide about.

C

A

C

A

C

Run over this one uh and just to comment on what I agree about consistency, I think that's going to take time. I think the best we can do is to push uh good apis, that use streams and uh for bible codex. There are I've, had it's easy to shim streams on top of webcodex and I'm happy to push for them to use promises as well. They had some good arguments against that. I want to mention, which is for audio there's, not always a one-to-one between encode and calls to encode and callbacks.

C

So there's some small reasons there to perhaps not prefer.

A

C

But this slide is: uh I want to give an update on progress since last month in the what wg they've been very responsive to our needs in this area and there's I want to call out there's one pr already for fixing the avoiding buffering and that's to make high water mark zero work and basically, by inventing a new method just still being bike shed with a writer book. So the readable side of a transform can call a function.

C

Currently, you know release back pressure or mark ready to basically tell the writable side, I'm ready for a packet now, so it would work without buffers, so there's a yay on that and another pr uh from un. Thank you for providing an explainer that suggests a new stream type tentatively called transfer to help clean up objects that are both transferable and closable, which are two concepts that hopefully eventually might end up in web idl and maybe in the stream spec for now.

C

But basically this would be the first use case, for this would be video frames. So you can now make a transform stream that accepts a video frame and a controller, and you can access the video frame uh until you and cuba to the controller, in which case the video frame is transferred, think think, move semantics if you're from c plus loss. So it's move semantics for trunk, basically and then um so you can write code that takes care of closing the frame.

C

But after but after it's been enqueued, you don't need to close it anymore because you don't own it anymore and you can't also access it, which means you avoid problems like a passing to b and then a mutating. What was passed uh so there's for transfer uh transform stream, has both a readable side and a writable site, so there's a type field for that, and I'm also showing zero high watermark. So that's the current state of things. It's just an explainer at the moment, so uh still gathering feedback from other participants on that.

C

But it's encouraging because there's some concepts here that are potentially beyond um that are useful beyond just our needs for ray buffer and things like that. Thanks.

A

Yeah, I just had one question about the code you're showing here yanivar the e here right. You just try the controller dot, dotting queue, that's really only an error in enqueue. Why would that in queue itself is very unlikely to blow up. So I don't think you're catching much of an error here. It's not like not an encoding error or anything that you're catching right.

C

All right, no, actually, I I struggled with whether that should be inside or outside to try, but it's the line ahead. The comment that says js can imagine, there's some code right above that is accessing the video frame. If any of that javascript code were to fail, the the proper pattern would be to remember to close the video frame in that case, but at the point where you enqueue it uh once it's been enqueued, uh then the the red comment below just cannot access the video frame here.

C

The remaining code doesn't need to close the video frame anymore, so so this is sort of uh uh to solve the lifetime issues of video frames by um having more explicit lifetime controls, which gets a little more complicated than using garbage collection, of course. But okay, if that's what we have to do here,.

A

Okay, so I think we're out of time on this segment um and so we're going to go to the webrtc encoder transform api, which is un, we'll go to 8 50.

A

Sorry, uh the 50 point on the hour, so you win.

D

Okay, um I think we already discussed uh this topic at uh meeting. So um basically, uh there are some needs for controlling video encoders, uh either on the receive side or on the same side, and the most important thing is to be able to generate a keyframe on the send side. It might be like when you're changing your entire encryption keys, like you're, using as frame and you're using a new key. So probably you you need to generate a new keyframe at that point, so it would be very handy if javascript could say.

D

Okay generate a key for me, generate a keyframe for me please. The second case is maybe on the receive side. You have like multiple clears uh and you might want to to switch from one tier to the other, and uh then you will start subscribing, and you want to ask uh the uh other guy on the other side, to actually uh trigger keyframes.

D

So usually um the user agent might be able to do it by sending a full intro request, but it might be handy for javascript to also trigger that outside of the user agent heuristics.

D

So I think that harold and bernard presented, like various proposals.

E

And this one is like.

D

Building on on top of their proposal, so the api is uh split into three parts: first, an api to generate keyframe at sender, side that would be exposed in script, transformer where you are actually manipulating frames like doing end-to-end encryption.

D

So it's promise-based to state when you're thinking that the task is done and also to send errors, and it's taking reads as input to be able to select and which encoders you might want to request keyframes.

D

So the example below there is uh in the case where you using a script, transform for doing encryption whenever you're changing keys, then you might want to say: oh, let's go with generator keyframe and you continue doing encryption getting new frames.

D

The second api next slide is also exposed in script transformer and is only meaningful on the relative side. So let's say, but at some point you want to send a keyframe request. So you you stand off here, so you want the user agent to send a full request for you. So you call transformer dot, send keyframe request there, there's no parameters, because it's up to the other side to know exactly which encoder to actually use and it's promise based as an error mechanism as well.

D

I was not sure whether it should be promise based or not, but for now that's the current proposal and the third slide.

D

They were some requests that, on the at the center side, so main thread api that you, you would be able to generate a keyframe and some people are apparently doing that by using replace track or muted or muting tracks and so on, and it.

F

D

Better to have an api that deprecates all these heuristics and we can ensure that it will actually generate a keyframe.

D

It's the same prototype as the transformer case, and basically it's the same algorithm. So it's uh it's just a convenience mechanism to generate a keyframe without having to create a transformer just for it right.

A

So I guess the main difference from harold's original proposals is you return undefined, as opposed to a a time stamp right.

D

uh Yeah, I think so I was not sure exactly what was the purpose of a time stamp in the transformer case, because in the transformer case, you're grabbing frames, so you know exactly which one will be a keyframe and its time stamps and at the center side I was not sure what would be the use of the timestamp as well. So that's your.

F

D

F

Yeah, so the reason why I added the timestamp originally was that when you generate the keyframe, when you're asked to generate the keyframe and again get three frames when you.

F

Have to choose to choose which key to encrypt each frame with, and so you would normally think that you would would have to gener to use the old key for the for the ones previous to the keyframe and then the new key for the keyframe. You asked, for.

F

I got a little bit confused in my head about whether whether there was a case where you could get the keyframe and you could get a free keyframe ahead of the one you asked for, so that you would uh not uh not start encrypting the right key on the right keyframe and that's where why I added a timestamp just to have a you, have a unique identifier for the keyframe. That is a result of your request.

F

D

Yeah that that makes sense to me uh in the next slide. There are like some uh areas where I'm not sure like. If you resolve a promise, uh does it relate? Which frame does it relate to like? When uh will you actually resolve the promise right.

G

D

Need to define that and it's not really defined the pr, and uh my rough proposal would be that, uh yes, you can have cases where um you're requesting a key frame and the usa agent a millisecond before decided that yeah. Oh, it's five minutes. So now I need to generate a keyframe and then the keyframe order is arriving and you generate the second keyframe like three uh three frames after uh the first keyframe and I'm not sure it matters, uh but maybe it matters. So we need to get into that.

D

uh So my rough proposal there was to resolve the promise when the first key frame gets enqueued in transformer.treatable.

D

So in that case you would resolve on the first keyframe, even though it's not really you that actually generated it. Maybe you can do something else. It's it's really.

F

Before or after.

D

There is no one, so you enqueue you, you post a task to enqueue and in this case in this task, where you enqueue to the transformer., you would resolve the promise.

F

Okay, so you solve the promise, after after entering the frame.

D

um Yeah or I'll be just before. I don't know exactly because, because.

F

The resolution of the promise is likely to to to contain code that tries to read the frame. So it's important to know whether it's there or not.

D

Yeah, so my guess is that you would resolve the promise first then synchronously and cue the frame and then in terms of promise, if you, if you did then and so on, it's the uh general keyframe promise callback that would be called first and then the uh read chunk that would be called. Second, maybe in the same, investing task.

F

I'm always mixing up promises and events and how they resolve. I was.

E

F

I'm not sure that so that that's there's a an inquiry task there. This yeah we can there, but this is uh this- is solvable in uh writing careful pros after we accept that also.

D

Yes, so there are additional issues like or small details like when the api rejects uh like for audio senders and receivers. That does not make this sound, real sense and to me generate keyframe, for instance, on sender side. You should not drop frames, it should not. The next frame should not be like a keyframe. uh I think we, maybe we with that, I'm not quite sure, but that's something we can discuss so there.

E

D

All sorts of details that we need to uh iron.

E

D

Get like a fully specified behavior, but I I think that it would be good if uh we can discuss like the rough proposal uh first and then.

F

So I think I have bernard and tim in the queue right.

A

So uh I would say I generally support this uh work and uh I do I do understand now. Harold's concern uh and my personal view is, I think it's it. The promise should resolve uh relative to the new keyframe, not not a previous one, because that's a little uh it's a little bit confusing and there there might be use cases, as you once said, they're a little bit different from the encrypted transform case.

A

um So uh you know you you would want to know when, when the keyframe you asked for gets generated, not not a previous one.

A

G

Yeah, I'm I'm a little bit nervous about the time stamp. Maybe we can cover this in when we get down to the detail later, but I just wanted to flag up that. Some of the sfus will, as opposed to asking the encoder to generate a new keyframe, will send you one that they've cached recently, which would have.

A

G

Old time stamp on it, so whether the timestamp is a good marker is I'm not clear in my head yet.

D

Yeah, I think we really need to dig into those cases where there might like. Is it important that if there are two keyframes generated you resolve on the first arm per second? So that's something we need to understand precisely.

A

Okay, so in terms of next steps, is it fair to say the next step is maybe to uh revise uh a little bit you win and then to go to a call for consensus is that is that the next step.

D

D

Yeah I mean what what what should we revise? Is it the time stamp that we should revise, or I I.

A

I think generally, the stuff we've been just talking about is uh clarifying.

F

Exactly yeah, so we should, we should get. The I think we have more has accepted uh said that yes, this this looks good and when we should make it into a call request, and then we should uh do a call call for consensus on on the either either merge and merge to extensions.

D

Changes the call for consensus, or things like that or not.

A

I don't think it changes the process much okay, so I mean I guess the question is, I think we can. We leave this up to the editors harold. They can merge it, and then we do the cfc. It might be easier to do the cfc if you have the text, because someone can read rather than a pr okay. So that's next step is next. uh Next step is merge to the encrypted transform draft and then run a cfc.

C

A

I yeah you win uh sorry on ebay.

C

So I'm not sure we should merge it before we have consensus, though, is there, can we use pr preview and do it that way.

A

You can always well, you can't measure consensus without a cfc, you mean discuss it among the editors before merging.

C

If that was the only concern I mean we could solve it. That way.

F

Yeah yeah that's a possible way forward. Okay, both are possible.

A

Okay, uh so we can put that down run as cfc on the preview and then see what we get all right I'll. Let you have a little bit a little bit extra time, so we're now going to get into the warbridge cpc and we're going to see extensions prs um and first uh jani, where we'll talk about peck, timer and then we'll get into a few extensions issues and pr's.

A

A

um Sorry sorry.

C

Yeah, okay, uh yeah, so there's an issue filed uh here where, in um uh this came up when we're doing a content, security policy, but there's actually a general problem here, where the spec there's an rfc rfc8863 that talks about a pack timer, which is a way to update the ice agent to wait a minimum amount of time before declaring ice failure. Even if there's no candidate pairs um and all checking has failed, and this delay provides enough time for for the discovery of peer reflexive candidates.

C

This is when you've generated a local candidate and the other side was able to to successfully complete a stun request that that gets to you and in that case, um so so the current spec was going to fail too soon and not waiting the appropriate time to allow for pay reflexive candidates.

C

And so so that's the first thing that the pr does is to add language. That says, um the condition for failed is all these other things um we've finished gathering we've received an indication that are no more remote candidates, we've finished, checking all pairs and all pairs have either failed or lost consent and either zero local candidates were gathered or the pack timer has expired, and um with that uh change, we're now mentioning the pack timer and the reason for, but there's an uh exception there, because the pack timer is by default.

C

I think 39.5 seconds. So it's a 40 second wait, but um in the case I think uh justin bernie pointed out this. If you have generated local zero local candidates, you know for a fact that you know you're not going to get a peer reflexive candidate because there's nothing for the stunt server to hit. So in that case we can skip the weight and go to failed immediately and that that has some advantages in that we get an instant failure path in the common situation, where both it's not common.

C

But in the case, where both peers generate zero candidates, you can go to failed immediately and that is useful for csp, because if you block webrtc through csp, you now have a failure path that we can reuse uh for content security policy, because there is an interest from the content security folks uh to to not throw in the constructor, but but instead use the natural network failure path in our spec and we didn't have one until then, because um it should also mention the browsers here today.

C

They don't all go the failed here. So we need to add some platform test as well. So that's the first part and there's the second part.

C

We also added a new arrow to the transition diagram to update the state diagram to cover failure from zero candidates, because you're in state new, until you receive one candidate and then you go to state checking.

C

So if you never get any candidates, the state diagram made it look like we shouldn't go to failed, even though the all the uh pros, the normative language, I believe says we should and that's it.

F

Yeah so so the last uh transition would be when you have when gathering is completed, and you have still have stereo candidates.

H

B

A

Objections to this.

F

Makes more sense.

A

Okay, the minute should show that pr 2704 has consensus.

A

Okay, so issue 47. This relates to rtb header extension, encryption with cryptex, so cryptex has completed working group, less call and itf abt core working group. It's currently in revised id needed.

A

We had talked about the api proposal in september of 2020, and the basic idea was, um I think, hbos wrote this was to encrypt rtp headers on all the m sections within a bundle or none of them. uh You always attempt to negotiate cryptex.

A

uh If you support it and then you have rtp header encryption policy and configuration which can be negotiate uh which says, uh send unencrypted if the other side doesn't support it or require, and if the other side doesn't support it, you fail um and then we have a attribute encrypted encryption negotiated. That tells you whether you've negotiated or not on that transceiver.

A

So here's the rub. um The itf cryptex spec marks this as bundle transport, um and that means that if cryptex attribute is present, it must be in all m lines of the bundle group, but uh all m lines don't need to be uh identical when you're not bundling so harold brought up. The following issue is that this creates an interop problem, potentially with non-browsers, because it's it's transport, not identical and without identical we can't reject the following offer, which would be cryptics on audio but not video.

A

I would note that I actually brought up this same issue when I reviewed the cryptex document um and it it. I didn't understand this particular use case, because um what you're saying here is that you can't receive cryptx on video, but why would you not be able to do that? If you can do it on audio? It didn't make sense to me because you, the code, has the ability to do it. Why would you decide not to do it on video?

A

So it was a little confusing to me and I asked why it shouldn't be identical rather than transport, but I I guess the authors didn't uh didn't address that.

A

um So uh I guess my question is: what should we do about this? I mean, I guess harold. Do you think this is gonna cause enough of a problem just to prevent implementation in browsers.

F

I have not analyzed it that far okay.

A

Well, my other question for you, harold is: do you think anybody really needs to do this like on video, but not audio or audio? Not video.

F

I have to twist my head hard for for for to to write up a use kit to get the use case for it it's uh it's kind of the it it would have been uh if you have a middle box that insists on reading your head, but only for a video.

A

Yeah, I didn't understand that use case uh harold because, like if your middle box does cryptex for audio, why couldn't it do it for video? uh It's a different story, whether the thing behind the gateway can do it or not, but why would why would the middle box care it doesn't have to send cryptics? You know to the video conference or whatever it just has to do it on its own side.

A

So I I don't understand the use case either.

F

I think it's, I think it's very unlikely that we will encounter this and we could just reject it. Okay, if, if the.

A

Yeah, so um the question is what we should do. I mean one thing we could do is uh since this document is still in revised id needed. Someone could post to the working group. You know as themselves and to say hey, I don't I don't get this. um Why is it? Why is it not identical instead of transport?

A

um Another thing is the working group. If we have consensus that we want it to be identical, we could send a liaison or something say hey. This is giving us headaches any thoughts on what we ought to do.

F

Posting at the individuals is more idea.

G

uh Yeah, I was just gonna say I. It's feels like something um from the um 3gpp people who tend to split video off from audio right quite early on, but I can't see why it would matter to us.

A

Okay, so uh what what is the next step for the minutes?

A

Harold? Do you have a suggestion.

F

F

I can take on sending a note to the avt core list saying uh I have this problem case, but do you really want us to support this?

F

A

Okay, that that sounds like a good resolution, uh then we'll wait for the response and figure out what to do in the pr.

A

Okay: next one is issue 69 um by the way in between errol had a question.

E

um Yes, can you hear me, I've got spotty spotty internet connection here.

A

Yeah we can hear you.

E

uh Yes, so I didn't fully understand how the call for adoption for region capture concluded.

A

Well, there was one objection uh and the rest were approved, so I know dom, can you say something about what it means to have an objection and what the working group needs to do.

B

Well, the chairs are empowered to decide. My sense from the discussion is that we probably need to iterate some more in issues and email discussion to figure a pass out of the objection.

B

I don't know that would be my suggestion to the chairs.

A

Well, my my personal view is that uh some of the object- some of the objections, though possibly not all, uh could be addressed just by clarifications in the document like some of the stuff, you were talking about a lot about the security and how things would turn off if you navigated to another another page or something like that, um and also the relationship to capture handle that it actually doesn't have the dependency.

E

I agree completely, and I also think that if we adopt but don't you know, there is no call for consensus. Yet that's going to make it easier to iterate on both this as well as uh right. Capture handle like it's kind,.

A

E

To keep both of them on ice.

A

Yeah, well, it wasn't a call for consensus, it was just a call for adoption, so the bar is a little bit lower.

A

H

Answer your question um not fully, uh so I can't sleep. Yes, sorry.

A

I think, basically, uh you should do the revisions and then I guess the chairs will discuss what the next step is. Is that what you're saying dom.

B

um Yes, I mean, ultimately, the chairs have to assess whether the threshold of consensus is enough to move forward with adoption.

F

Okay, so so you're saying that in a case where the working group is not not anonymous but uh strongly take it, then the work groups just get to make the call.

B

Yes, you have to assess the rough in the rough consensus. Yes,.

F

Okay: okay, it's on our lap.

A

All right, thank you so back to issue 69. This was uh about p time and originally in the adapted p time description, which was in section nine. It mentioned setting b time uh but p time itself wasn't defined the attribute, uh and so we did in our in pr 89 is we removed the p time reference to not have it referred to something it didn't exist, um and this issue said hey: should we add this back and actually add p time to the document instead of having a dangling reference?

A

And so the question really is: are the working of participants supportive of adding p time, and if we add it we'll actually is anybody interested in implementing it and just for reference? This is the pr it's not particularly complicated. It basically adds a p time attribute to rtc rtp encoding parameters. Instead, you know duration of media represented by a packet of milliseconds and just adds back the reference in adaptive p time to p time and basically says you can't do both you do adapt to p time.

A

You can't set p times so want to open the floor to people commenting. Do you want b time? Will anybody implement it, etc?.

G

Tim yeah, so so I want it.

G

um There are situations where, uh where you know something about the network or you know something about the one end of the system where it will be really useful to wind the p time up to like 60 milliseconds to you drastically reduce the packet load um and that's there's a load of networks where that's a really valuable thing to be able to do, and at the moment the only way to do it is to manage the stp um and so adding p time back, I think, would remove my last reason for munching stp.

F

That's the winner himself.

A

We'll find you another reason to match tim.

G

Well, not at the moment right, I I genuinely have this is the last one that's hanging on so uh hopefully we we, I get away with it after that.

F

So would this: will this be an extension or would it being the main dock patch.

A

Well, at the moment, this is a pr to webrtc extensions. I guess in the theory that it would stay there until somebody implements it, because it you wouldn't want to patch something uh and have it not be implemented.

F

I would I would be happy to have it in the in extensions: let's do it.

A

Okay, are there any objections to merging this pr.

A

I think it probably ought to if it is merged uh without implementation. It probably should have a note saying it hasn't. You know it's, uh it hasn't been implemented, but now we can see what happens.

A

Okay sounds like we have consensus to merge it with a note.

A

Okay, cool all right so now we're into the last portion of the meeting, uh which is where to see nb use cases, and I think we're going to have a good good discussion here.

A

Okay, so let's talk about the results of the cfc, it was one of the more complicated cfcs, hopefully that we'll ever have it ended yesterday, and here are the result on the use cases. We had three use cases: uh low, latency, peer-to-peer, broadcast decentralized, internet and reduced complexity signaling.

A

uh There were three approvals and uh one objection for each one um and we'll go more into the use cases and then also into the requirements.

A

So the first one was low, latency peer-to-peer broadcast.

A

um I had a question whether it's well first, I guess first, what we mean by low latency, but also whether it might have value for non-low latency, like we've, seen peer-to-peer caching with the data channel being done to extend hls kind of like an enterprise cache.

A

My other question was what drm today in in the web is transport independent? So uh you know, was the requirement already met or is there something else that that we need to meet it? And I guess harold uh who also expressed support, said he interpreted broadcast as semi-simultaneous unidirectional delivery of the same audio video content to a thousand plus users, um and then yarivar said he thought it was too broad and confusing broadcast meant.

A

I think tim also responded that it was the multi uh multiple unit, uni-directional, real-time streams, with multiple viewers watching a concert or sports event or church service, and we have seen that implemented with the data channel in particular, and some of these do use drm. uh That already exists, and so then yanir said this is required. Drm support in the webrtc media stack or in the data channel like something beyond like what we already have do.

A

You need to send real-time media over data channels, and I added you know in one direction in both directions and does it require support for higher latency non-real-time media like peer-to-peer caching.

A

So is there anyone who wants to comment on this.

F

So tim here with me I'll just cue myself,.

G

So um yeah I I think this was badly phrased and- and I didn't actually mentally- include data channel use cases here, but but maybe that's uh on a mission that I shouldn't have made. I don't know, I'm not sure yet. um I think the only objection I have to some of these is. I, like, I think, beyond a thousand I'm not like. There are smaller churches who might still want to do this.

E

Like you know,.

G

Let's not put a number on on that. I mean you know more than your average. uh I try to want to try and distinguish it from video conferencing, um but but I think it's it's you know a thousand is a difficult number. I wouldn't wouldn't want to go that far. I think the drm thing is.

G

Is I genuinely don't understand what the requirements are here and that's probably why it was as as weakly written as it was, but I feel there is something here that we need to understand and support, and I and I I don't know how we, um how we approach that um I think getting experts who who can explain why they're not using webrtc.

G

Basically it's like the thesis of this, I think so. Yeah, that's not super helpful, but um that's kind of the way I saw it.

F

Yeah I I came up with a so now. It's how I ended I'm in the cube, and I came up with a 1000 number just because when you have 500 people you can just run an ordinary conference. So right, not quite ordinary, but but it works.

F

It's present technology there's nothing new here, so I put that up there beyond 1000, that's as to get to think that there might be new technologies that needed to be involved and see mr simultaneous universal, because we don't uh we're not talking about uh support supporting a uh mode where we talk back, but I think we should leave the rm out of it and whether whether it's data channel or not that's part of the solution or part of the problem, so I I think we should revise this quite dramatically, but uh we should adopt the use case.

A

Bernard yeah, I also support adopting the use case, and I agree with what a bunch of what harold has said. um I will say what I think the use case is, which I think is close to what what's been suggested here, which is I've seen this. uh You know you mentioned tim, the concert, the sporting event. That kind of thing, I think I think that's actually the core of it.

A

The big question, in my mind, is the latency and you use the term low latency. I think that's the right term, because I think you you're not talking about an ultra low latency case here. Like a gaming scenario, I think you're talking about something which doesn't have quite the latency requirement. Even of conferencing, like I'm thinking of also a very large company meeting like a hundred thousand people in a company and what I've seen happen here is basically uh it is.

A

It can be done a bunch of ways, uh but basically one way is to do the data channel. Think of it as a data channel to a gateway and then then branch out with peer-to-peer caching uh in the data channel, you can get to that kind of hundred thousand scale by uh more easily than you could with whoever you see. I've also seen drm supported for this, but it doesn't require anything new. That is the way it's done. Is you send containerized media get the keys with eme? It looks exactly like the drm and hls.

A

um I have heard some complaints about that, not with mse specifically, but when you so by the way the rendering is done, typically with mse or would be done, maybe with msev2 and rtc data channel like in workers.

A

The thing here is: the complexity comes in when, if you want to use web codecs- and there is discussion in the media working group about how that would work because then it wouldn't be containerized, but that's not in. We don't have to worry about that in whatever dc. I think we should mostly focus on the transport um and with respect to some of uh yanivar's questions.

A

This is done with the latency lowered by changing the congestion control on the server, so there's nothing in the rtc data channel that has to change um and since it's unidirectional it wouldn't be both directions um anyway. So I I at least I think I understand what what I my interpretation of the use case and maybe it's close to what jim and harold had in mind. Hopefully, yeah.

C

Yeah, so I I'm glad I'm hearing a lot of things that this could be improved. uh The use case could be clarified a lot. I think the difference is that I think we should object to the use case until those improvements have been made. So it's clear what we're committing to um and uh also webrtc is being used for a lot of things, uh but it still has a scaling problem, so I think we should be careful to uh actually commit.

C

I don't know that we should commit to an actual number and say that you know you're.

A

C

Right, it should support a thousand or anything like that um as far as sending media over data channels, but yeah, so to clarify. What's on the slide, what what I said about drm was that I just want to make it clear that um I worry that the use case is so broad that it might lead people to believe that we're asking for a lot of these things. So I want to clarify that I do not think we should support drm in webrtc meet a stack or data channel.

A

Well, it is, it isn't, there's a difference between adding something it is supported over data channels supported over every transport, with the current occupation, so you're saying don't donate.

C

We're not we're not.

A

Committing to anything new here, I guess.

C

Right we're not adding drm specific features. You can send me over data channels. Today um you can, as you pointed out, if you're server to client, you can even send low latency media. You just can't uh upload from client to server low latency media, because that would require well you're you're. Still, you can do that, but you're still down by the congestion controller.

C

There's a lot of things we could commit to, and I worry that uh we should have uh since the spec is that uh recommendation now we should have very narrow use cases for things that we actually anticipate adding features for.

A

C

E

A

The next steps on this use case- I think, what we've heard is it needs like a tim. Would you be willing to do a pr to revise it to address some of these concerns.

G

Yeah, I'm going to need going to need input because, as I said, I they're particularly the drm stuff- I I simply don't understand um how these things work, so I will need help with that.

A

Yeah um so uh okay, so I guess the first step is for you to do a pr and then we can comment on it and move forward uh with that. Yeah.

F

Rambo candles, in the queue.

A

I

And that's the unmute yep yeah there we go um so uh uh you know also on the johnny bar stuff uh helmet on the data channels. uh This is mentioned peer-to-peer, but bernard was talking about. Well, you can do real time if you have a cert if you modify the server's congestion control, but that wouldn't be peer-to-peer just not.

A

I

A

Ice, you know so it looks like peer-to-peer but.

I

A

Wouldn't be done in the browser.

I

But this says peer-to-peer so right.

A

I

Right, so that's that's different than what you were talking about for the very low for low latency.

I

So if you know, if you're not you know, if you want low latency and peer-to-peer, then there's some issues to deal with yeah.

A

But I guess tim, that's you don't think that that's a requirement, at least for the broadcast case right. You don't have to modify the the browser implementation of the data channel.

G

um So I think that pita peerness is orthogonal from whether one end is a browser or not like. There are a bunch of devices out there that aren't servers, but there also aren't browsers. That might be the origin of this, like you might put a super duper webcam in your church and have your 700 parishioners watch it um there's no servers involved, it's peer-to-peer, but you know, uh but yes, you can mess with the congestion control algorithm in that in that super duper. Webcam.

I

Yeah, I would call that a server, but that's just a definitional thing.

G

Yeah well now, so my distinction is that it's probably behind that and it won't have. It won't- have doesn't need to have a public ip address.

G

So, like that's my line for whether it's a server or not, that's probably a bad um line of distinction but yeah. I I don't know.

F

So my my big reason for saying uh 1000 was that if we we have a solution for peer-to-peer broker, then it doesn't scale to a thousand. It's not worth it. It's not right worth doing right, so anything that scales to a thousand will also work for 20, but we should aim higher.

A

Yeah, I mean typically the the limits for a lot of these conferencing. Solutions is around a thousand or you know so it has to be, has to be bigger.

A

Okay, so next use case was decentralized internet uh and uh the discussion there was around service workers.

A

uh Harold, supported it and said that if a service worker can create a pure connection, then you can do it and then janivar questioned uh the whether this was just about data channel and were brokers or was about rtc peer connection service workers and whether that was a little bit much to ask for and whether there were alternatives.

A

G

So um the use case well yeah. I I I'm again I'm slightly struggling with the with um dragging out the use case, and I think it would be good to get some expert input on this. But but the feedback I've had from people who are in the kind of decentralized messaging space is that they want to be able to effectively receive messages. In the background when, when the user currently doesn't have a tab open um and and and that is why we're in the service worker.

A

Is it just a data channel or is it the peer connection as well.

G

Well, I mean they only need a data channel and it could potentially have been created in in a tab. But the problem is that we've defined the lifetime as being the lifetime of the tab that it came from, and so.

B

G

It's gone then.

I

So um I think I was in the queue next, um the yeah I mean I. I am also concerned about the work to to put all of peer connection into service workers.

I

That's not trivial and.

I

And then, if we do put it in there, that's going to open up some interesting additional security, privacy, etc stuff. That neat will need to be thought about, as well as resource usage in the browser. um Ironically, I'm now on the workers and storage team at mozilla and been working on service workers, so.

F

I

So but uh I think before we were to do that, there would have to be some discussion around what are the implications of of putting the full stack in there for for browser, then for users and the resource usage.

A

Tim, you mentioned having some of the decentralized people come to the working group. I know we've had them had a lot of questions around some of the requirements for ice like in some of the other use cases. um Do you know those people well.

G

Enough I mean I could. I could certainly ask uh ask one or two and see if they they'll come along. um I um yeah I mean I'm, I can ask around and see see who can who can uh who? Who would accept an invite if we made one? um I can certainly do that.

G

uh I I think it's an I mean I want to emphasize. I think it's an interesting space and there are. There are people who are like doing ugly things in iframes at the moment, um and it would be nice to avoid that.

I

Yeah one yeah, one thing I I do there are some as I'm thinking about it. There are some some real concerns here once you have this stuff running entirely headless uh without any uh user, visible control, effectively service workers are totally hidden from the user, um and you know I mean in theory. Yes, you can get to them. If you know exactly what to look at and so forth in a browser but effectively the user never knows that they're there, which means once it gets installed. It can be doing anything forever.

I

For example, you put this in there, then people who want to run peer-to-peer caches can leverage everyone's. All they have to do is have you browse to some site, they control once and then forevermore. They can use your bandwidth and storage to do. Caching.

I

But without any but but the thing is you know, so I on my low-end laptop with my metered internet connection, I'm providing this to everyone without ever having been told. I'm doing it. That's the thing. There's no consent here.

G

I I I mean I I do totally agree that there are a set of risks here. We have to mitigate and manage and and like there's no question about that, but I think there's enough of a prize there that it's worth thinking about.

I

Thinking about, but I wouldn't uh I wouldn't agree to accepting it as a as a as a as a use case at this point, without some real deeper thought about what the implications are.

G

Well, can we decouple the use case from the way that we're going to solve it, because I think it would it be good to at least indicate some acceptance from the group that, like this is a use case that we want to at least somehow address and- and I agree that we haven't come up with a way of addressing it- that's in any way satisfactory.

G

But I could. I think it would be nice to kind of signal to the decentralized folks that yeah, okay, we're at least looking at this.

I

Wow perhaps I have my entire: have issues the entire decentralized folk in general, but that's separate.

G

Yeah well, yes, there's there's a but there's an there's, a kernel of something interesting there as well.

I

I I understand, then: I understand that what the wish to move away from everything controlled by a few people, but that's a said, that's a separate conversation.

I

um So you know, I think I think if we were to signal interest or acceptance of the id general idea, we would have to make make sure there's some very clear caveats attached to that.

A

So, in terms of next steps, could we actually try to get the decentralized people at the working group to kind of make the case and maybe discuss this because I I personally feel like I don't understand this space well enough to even understand the motivation entirely and certainly with ice. I think it's gone over my head. Okay, I don't quite understand.

G

A

Change is needed.

G

I I noticed the antivirus in the queue as well.

A

G

C

Was just gonna maybe another way to approach it was to compare it to fetch. I mean I understand you can use fetch in service workers today and so you know I'd say as a devil's advocate. Then you know what are the differences between asking for peer-to-peer on one end and on the other end going back to the decentralized people uh can't you can you somehow solve your use case using fetch?

C

I guess you know in a sort of semi-centralized way. I guess that's the problem.

G

Yeah, it's the centralization and and in fact, in some cases, there's there's a desire to take a fetch from the active tab and translate it into a peer-to-peer request that goes out over over some sort of decentralized fabric.

I

Seems like that, it seems like that wow yeah, um yeah.

G

So to penance point yes, I will try and dig up um one or two people who would would agree to an invite and and ask them um get get them and get them to give some background as to what their problems are with using the existing uh infrastructure and how what they would want and what limitations they would accept.

A

uh Harold do you have any other comments.

F

No, I think this is uh adequate coverage and and that that we.

F

We know one solution to this problem, just to clear the connection uh instantial within a in the service worker. We know that this solution comes with lots of forms, and so we should add the use case and then and then we should work on solutions.

F

Saying yes describing the solution in the use. Cases is not not the right way forward. Despite me doing it.

A

Okay uh and then we have reduced complexity, signaling, um which I guess harold mentioned, is the existing requirement is too simplistic uh due to the abuse uh possibilities outlined in rfc 8827 uh violence, section six three and then jan avar asked. How is this different from wish and then tim said it's wishes for ingest. This would be for egress, and then yanivar asked whether it was the itf, the new uri formats for the itf and.

A

Not for the w3c.

F

So this is, the requirement in uh in uh 6.3 was very specific about revealing uh uh letting certain keys be under under control of javascript and which they would be if we can inject them, and so I so adopting this case requires that we actually go understand this.

F

What these are supposed to guard against and why it's not a problem. In this case I mean in a which case, I think the answer is and hey. What's what's announcing the what's announcing the url is the server and servers are big boys. They can look out for themselves, which might not be the case for a for a peer-to-peer connection.

F

Now I have I lost track of where we were not. I think tim.

G

Yeah so so I think.

G

uh I don't know how we um do this, but I do think it there's a there's a set of requirements where it would be like it would be really nice, for example, to be able to plug in a a uni-directional live feed into a a video tag with just setting the source attribute right in the same way that you can do that with an m3u um url.

G

Now I I how that, without having to drag in a bunch of infrastructure, uh a bunch of javascript and and and I think it feels to me- like that's- achievable now- how you do it um and how it could be done. I I don't yet know, um but it I mean wishes and just the distinction with the other thing with wishes. That wish is a negotiation.

G

Although it's a less of a negotiation, it still does a full offer answer negotiation. um I I think the aim here would be more of a kind of declarative.

G

This is what we're doing a one-way statement, um so I I'm and it feels like it's achievable and desirable, but I I do take the the issue about kind of revealing things that you shouldn't be revealing and understanding. Why why that may or may not be a problem.

F

F

We will have a negotiation anyway or an offer ounce around in packets. It would be nice to not have to do enough rounds around there. Singly.

F

I mean you fire up dtns.

E

F

Have offer answer.

G

uh It isn't necessarily a negotiation, though,.

F

No, it's negotiates cryptoswitch and so on, nothing to do with stp right.

F

So you have a packet calling this packet going that way, but we shouldn't need to have a packet going this way around the corner, so some other media.

A

Yeah I mean the the problem has been like. Even in oh, it's something like otc. You still had to have an offer and an answer just to exchange the ice creds and the dtls credits right kind of at a minimum.

A

You couldn't uh just do it one way and have all the have all the security properties you wanted.

G

But I think I mean to harold's point about the server being a big boy. I mean the assumption is the assumption. Maybe then is that one end of this is a server. Maybe that's what that? Maybe that's the restriction that make allows us to write this, that that this that one end of this is a server and therefore there are attributes you already know, perhaps from you know, from having talked to it before or something so, it's a more stable place and- and it can look after itself in in some respects, um I I'm yeah.

G

um I think we again, I think we need we need to find some way of kind of picking apart the things that we care about here and and limiting the scope of this to it, to a point where it's at least well. I hope that it becomes acceptable.

A

Yeah so perhaps more analysis I mean I understand that if the dtls certificate was already known from a previous interaction, you could probably eliminate that offer answer. I don't think you could get rid of ice. uh The I saw for answer, but anyway, uh so is the next step here, more more uh analysis.

A

What do you think harold.

F

So I would say that uh the the use case should just be adopted within with a caveat saying that uh that secure security guarantees for the for each one must be must be taken into considerations and but, but so so the the way it looked currently was that it it said uh the answer is that you're right? What was the question, and I think the the question needs to be it needs to be.

F

We want to set up a a connection between a between two entities without having to go through a signaling server and they are, and the answer shouldn't be any question.

G

Right so so you're saying redraw this as a as a higher level requirement and then discuss it from there.

F

Yep, okay, so I have a very I've, been thinking thinking about just randomized uh thinking about way ways we could do this based on dns.

F

And then put it into mdns for the for the peer-to-peer use case inside the local network. I thought.

D

It was kind of cool, but.

F

It uh it's not uh it's not also, it's not a solution to all problems.

A

Yeah, I actually did a bunch of work on that years ago uh and it is actually tricky because you can start there's issues, potential issues with uh cash poisoning and- and you know, record signing and stuff like that, avoiding security issues. This is not simple.

F

A

Three properties.

F

Are interesting, yeah.

G

I mean I I don't want to dive into the detail of this, but uh but I think the strong point is, as you said, bernard was that if we already have some sort of exchange of um certificates that we both that the both sides know then there's at least somewhere to stand um and and and maybe validate things from or I don't know, um use that that pivot point to to to build the rest of it. I I you know, um I.

A

G

Take the point that this is complicated stuff we would have to get right.

A

Okay, so I think the next step on this one is uh revision uh and and clarification, I think um so. Why don't we get into the uh requirements and if you thought it was complicated up till now, we've got another level for you.

A

uh So we um trying to summarize here the comments on the individual requirements and a bunch of them uh were questions about whether we actually could do this already or whether we needed new stuff to do it so for n30 it said ability to re-establish media after an interruption, and my question was: do we need new apis for this? uh As an example, you know if you, if your media gets.

A

Interrupted you could do more signaling to try to set it up again. You could do a nice restart.

A

I know some folks at one point implemented, turn mobility, so you could bring it up pretty quickly without actually having to allocate new turn candidates. um You know, there's a nicer proposal from google in the itf, uh which I think harold didn't require any api changes right. It just.

F

We haven't so far, possibly possibly would the current discussion says that possibly we would consider asking for a switch to turn it on and off.

A

Right, okay, so minimal api changes, yeah.

F

um Adopt weber's cis totally.

A

uh Yeah well uh something like that.

F

A

Difficult fish so yeah, so that was the question about n30 is: did it have an epi requirement or was there some underlying protocol thing here uh without an api and then n31 was uh so place media during an interruption? And I guess the question was: couldn't you just download the whole music before the interruption and cache it and then play it? um uh It wouldn't be real time. Obviously, but you'd have stored it. You.

I

Don't even have you don't even need to download it, you could just pull it and play.

A

It right well, if you're interrupted, you wouldn't have connectivity, I guess.

I

But which is you're not sending it to anyone to anyone anyways.

A

Well, I guess uh I guess the browser could play it, even if it's disconnect from the internet right, if it already had it in the cache. I guess yes.

I

Yes, it could yeah yeah.

A

I

A

So n32 was about parking connections and my distant memory of sip is there is like you: do, have parking there. So could you just do that with the you know, the existing sip signaling? Do you need anything new in the api and then the long-term connection re-established without access to external services? I think that gets into what we were just discussing, um and I was my question: was you know? Is there some kind of protocol thing you need there um like you? Basically, your sip signaling server is no longer accessible like.

A

How do you know who to trust on the land? Do you need some because mdns isn't I mean? How do you? How do you figure that out you're, I guess signaling to someone else on the on the lan and if it's not a server like uh you're, expecting a browser to run a http server exactly? How would that work.

A

I don't know if people want to comment on these on these requirements.

G

I'll clarify the the hold music one, because I think it's probably the the one that is the least understood, and the easiest to explain. um But the issue here is: is that we don't that the browsers? Don't um don't tell you when they when you've been interrupted in a way that okay allows you to do anything sensible, um like you know, if you get a gsm interruption or or the the user put something foreground, and you don't ne, you don't know, and what's even worse, the other party you're talking to has absolutely no idea.

G

What's happened, it's indistinguishable from um losing connectivity for the first 40 seconds, like you can't it's it's really hard to to for the far end to know what has just happened.

B

G

And I think it would be really nice to be able to like just you know, hold music or whatever foots for the far end to receive to say so it's basically a mute state that carries the the idea that it might be retrievable and and somehow that is sent to the far end and the firing can like kind of play, comfort, noise or whatever. It is that he needs to do so.

I

What is he somehow? It gets into the far end, because that.

A

I

Like sounds like the hardest part here,.

G

um Well, so I think there are two parts. The first part is that the near end needs to needs to know what's happening like if the near end knew what was happening, then it could probably send something over the data channel and we could work around it that way, but what it does at the moment is it just as far as I can tell it just.

G

I should probably defer to you and if or something but but what I can as far as I can tell what it does at the moment, is it just mutes the stream, it mutes the audio stream right right and possibly the video stream depending on the implementation, and what I'm asking for is if that mute is sent. Can we not like do something else as well, but okay.

B

A

Weren't talking about a connectivity interruption, you were talking about like the phone call coming in on an iphone.

I

Yeah, what is an interruption uh here right? Because that's the part I don't understand, I assume it's connectivity.

G

uh So in this particular one, I'm not thinking about connectivity all right, okay and what.

A

Are you thinking about.

G

I'm thinking about the the gsm interrupt or um or people uh or the for one reason or another, the os deciding that this- um that this stream needs to be muted.

A

Yeah, so you went well.

G

A

About this right, you win, you end, you want to talk.

A

uh Anyway, you u.n.

C

Was continually dropped off.

A

Okay, so uwen has a pr about uh the iphone a phone call coming in and then you get muted. As a result of that, I think that is that what you're talking about tim.

G

Yeah, I I think he's he's addressing part of it, but my concern is the foreign finding out as well right.

I

Okay, well, if I mean, if you can, if there's a way, for I mean first thing, is the this: the side that this is happening to has to have some way to find out that this happened?

I

Okay, so, let's assume there's some way you can find out from the us or whatever okay, second of all, it has to be able to. If we find out that out, then we would need to define some sort of event. Once we define some sort of event that an application can get, then the application can do whatever it wants. It can switch to whole sending hold music. It can just send a data channel message to the other side. It's entirely within the existing apis.

I

It can be handled. The only thing I think that is needed is some sort of notification that that some sort of interruption of of media by the operating system has occurred, and then you have to define to figure out if, like, if you, you have to worry about things like the user, just hits the mute button on their mic. Does that constitute an interruption?

I

Probably not okay, you have to be something: that's not under the control of the user, uh but we could define an event for that and then let everything else be handled by existing apis.

C

Yeah, I agree that sounds like a request on media capture. It has nothing to do with peer connection per se. uh I'd like to comment that uh currently, if you mute a track locally, uh it does not get muted remotely it might in chrome, but that is there's a bug on that.

C

So these are this sounds like a media capture only issue that could be solved with uh you know an autoband data channel message.

A

uh Didn't un just submit a pr on this exact issue january?

A

E

A

Was a mute event, I think that he caused to have happened when uh the phone call comes in and you get muted as a result on the iphone.

C

Yes uh and it's a it's, a not a, not a peer connection thing, but a media capture thing yeah,.

A

Right right um so anyway, I think I think this one. The uh thing to do tim is be to revise it, um in light of, uh I think I think this may be, but just to clarify what we mean by interruption. Certainly, I think there was a misunderstanding about that, um and also for you to review un's pr to see if that's a foundation for it or whether there's an additional requirement.

A

Okay, do you have additional comments on the uh before we go to the other.

G

Requirements, so I think this was written before nicer. um I think there is some overlap with nicer and- and we need to understand what, where that, uh where that goes, um and whether whether nicer meets that requirement and then they're thinking about the 33.

A

G

I think and 30.

A

Is yeah I think, he's talking about.

G

Yeah and and then on on 33.

G

uh I think, though we need to it's. We probably need to come up with some limitations on on, like that, the two have already like met that this is this is 33, is only achievable if well, no, actually it's kind of reviving it. So they already know each other. So there's some some things that you could. You can pre-assume potentially.

I

So with 33, why? uh Under what circumstances that need to be re-established, you've been isolated from the wider net, but if the call is already up, how does how you know? Why does it you need to access to the wider net.

G

uh You don't want so so this crops, up with um with user, has, for example, a baby monitor under and a smartphone, and at the moment um they all write native apps because they can't re-establish communication if the uh if their isp is down, so they do tricksy things with mdns and local stuff. Well,.

I

This isn't really re-establishing a call. This is establishing a new call to us to a to something you've already talked to in the past.

G

uh Yeah, the assumption, I think was that there's also like two iot devices that maybe want to talk to each other or, and I you want to talk to an iot device a day later. um So you may not keep that connection up. Maybe.

I

G

With like well, it's establishing.

I

A new connection to something you talked to before.

G

um It depends on how you define a new connection, because I think in a lot of cases, this is going to be an extension of an existing connection like there are some properties of the existing connection that you can assume are still valid, and hopefully that makes it simpler to to deliver.

I

Okay, I think there's some terminology issue definitions that need to be nailed down here, to make sure it's clear what we're what we're actually talking about, because it's definitely not clear from the from the current text right and uh yeah.

I

I

Yeah, I'm just trying to think of what's.

I

A

Yeah, okay, why don't we uh look at the remaining requirements, and uh so we also had comments on n34, 35 and 36 34 was, I guess, back to what universe said about the per connection service workers n35 um was the question was: can we handle this with mesh?

A

um So you don't always need a media server to do a conference. You could you can do that today without seeing a mesh and then there was a whole bunch of comments on autoplay um being messy, and I certainly sympathize with that uh and there were questions about the autoplay attribute and actually I wanted to point out. Yaniverse said the autoplay is outside of the scope of webrtc.

A

It's it's actually in the media working group, but in fact they are trying to do some fixes to it and this autoplay issue. One was one example of fixes, so I think so that was a comment on n36 and then for 37, 38 and 39 um and then 37. The question was: is this: do we need new drm stuff, or can we use the existing drm stuff? We have and there's something new is required. What is it and then janibra had his questions about new drm things in order to see your data channels?

A

N38 was the subtitle assets and I guess we had the question of can't. We already do this like by just downloading the subtitle assets over data channel. Is there some? What is it uh and then n39 was the same thing? We talked about the uri formats uh with the uh issues in ada 27 and the idf handling of uri formats.

A

So do we have comments on these.

G

So I'll just talk about the mesh thing. The idea here was, I think, we're actually quite close to be able to do this um already um as as, but the idea is is that you don't necessarily need a mesh you you might want to. You might want to be a you might want to start um like there's no need to do a full mesh. If all you want to do is essentially send out the teacher to students and the students.

G

Don't need to talk to each other necessarily or don't need to see each other, but the teacher may need to see everybody and be seen by everybody, so you might want to build a star here and the media that you're sending to the students is the same for all of them. So can you make some optimizations about um only encoding it once because it turns out if you like, the huge overhead on on sending out like 40 streams is encoding.

G

It 40 times which you didn't need to do um so that that's where that comes from, but I think actually we're, surprisingly close with with the insertable stream stuff, we're surprisingly close to being able to do that as it is um I, but if we had a requirement that it was possible then uh like, if there's a slip on the we might, we might ensure that that becomes possible. If so, what I mean.

A

Yeah as an example like, if you used web codecs uh and then encrypted the payload you, uh you could certainly send that over data channel I mean you'd have to send it, as you know, to each of the students separately, but you wouldn't have to change. You, don't have to encode it a zillion times or encrypt it a zillion times.

A

So is that what you're talking about it is? But I didn't want to do it over the data channel. Oh okay! So not over the data channel right.

F

Requirements shouldn't be talking about whether it's on the data channel, udp transport, web transport or by blackmagic requirements talk about requirements.

I

So one thing about uh sending stuff to multiple people- and particularly the case that tim was talking about, uh is um that's all well and good to say: oh, this encoder wants to send it to everyone until you have bandwidth issues and latency issues and retransmit issues- and you know I l, I missed, I missed a keyframe, I need a, I need a refresh issue, and so uh yes, you can do this, but it is not anywhere near as straightforward as it sounds like whether it's over data channels or otherwise at minimum.

I

If you're going to support this in any sort of general form, you need to encode at multiple different bandwidths or be ready to encode it.

I

Multiple different bandwidths is as needed as we're told by the by the by this by the receivers, um and you need to handle recovery uh from all those in, like you know, if one misses an iframe you may have to send it to all of them are all that are sharing a particular sub stream, so it's it's messy and complicated, and- and so I think, if you're going to talk about it, you need to talk about. You know in more detail what is actually going to be required in, in this case,.

G

You and harold have just given completely diametric advice. um Harold has said he shouldn't be talking about how this works, and you just said you should.

E

G

How this works I mean I I totally get that it has to be done at some point, like both things have to be done at some point, but but I'm not sure what the takeaway activity is from this now, I'm not saying.

I

You have to define those things, I'm saying it's complex and you can't figure out a solution to it without having a more detailed explanation of what you're trying to get.

A

Well, so let me try to bridge the two I'm actually trying to write code as an example of what randall just said. It is extremely complex. um However, I will say that in the web api model we're getting more and more of the things you need to do like in web codecs. You can do svc. You know you can do all this stuff. What I'm just trying to understand is because this is a requirement what what stuff?

A

What exactly I need to do to make this possible that isn't possible now that that's all I'm trying to get, and maybe that's what harold is asking for- I'm just trying to understand you know you said that we're nearly there and I think I agree with that, but I'm not sure what's missing to get us there, yeah.

I

And I think I think to do that, you need to define with some real detail what there is. What is the actual case that you want to cover and what are this? What are the limits of that case, because you can't define a solution until you know what your the limits of this you're in the cover are.

G

So I think yeah um I I'm struggling slightly with the idea that we that we have to work through a in order to state a user requirement.

G

We have to work through exactly how it would work and say which bits I mean the goal in stating this user requirement for me was to ensure that the other work that we do in the other places which might very nearly make this work, will do that extra centimeter that extra api one extra api point that makes this requirement work and- and so, like I said, we've I suspect, we're very very nearly there already like we just added keyframes.

G

Like you know, a lot of the things that you're talking about are are things that we're very close to to already having, and I think that putting in a a a use case here, which says this is something we'd like to be able to achieve is it is provides a guideline for the other things that we're doing to make sure that those api points do meet this.

G

This need, and- and I I totally take your point- that all of these things will need to be done in order to deliver that, but I don't think they all have to be defined at this point in this document and I'm not disagreeing. I agree with. I agree with you.

I

Seven minutes left, I I largely agree with you, but I think in order not saying that we have to define the solution, I'm saying we have to define the problem we're solving. Okay and that's. The thing is, I think it's just a little too vague as to what the problem we're solving is here.

A

As harold just said, we're six minutes away uh and what we'd like to try to do. I think, in the six minutes remaining is figure out exactly what our next steps are um and and what we do to kind of move this along. um So I think we've had a really good discussion, uh but we need to kind of come to come to agreement on what to do next for these requirements.

A

um Harold, do you have any thoughts.

F

So I think we I think we should uh remove stuff. That is obviously not our problem like uh auto play.

A

Autoplay, okay,.

F

Yeah, I think we should uh uh clearly refine the use cases uh from so that they're more clear about what they. Oh, I mean. They should be clear enough that we know whether we have achieved them a lot and the requirements. Here I mean mostly.

F

I'm unhappy with the 34 2 because it seems to be mostly out either trivial around the scope, and so I would. I would uh go another round of uh editing the ones that ones that are left and say and try to make them more precise, precise enough that we can can tell whether they're already satisfied or whether they will be satisfied. Once.

G

F

G

About that precision is that precision in terms of what the user will be experiencing, or is it precision in terms of what we will be providing in terms of apis? Or is it precision in terms of what do we have to change in the browser right? Because there are? There are three levels of precision here and I'm I think I mean I'm in I'm in newbie at this and I think I'm getting getting it wrong. So I need guidance on what what you mean by precision and in this in this case, since this.

F

Is use cases I would say, and I will say that it's about what the user experience, what we're able to build so that the user has a circle experience when we come, we can't do everything.

F

We can't build a polished application as part of the standards work. That's not our business, but we got to convince ourselves that once it's once, we've satisfied the use case, it's possible to give the user the experience that we want to give him or her for it.

A

Yeah, so that's for the use case for a requirement. What I want is, I want to know if I've done it or not, yeah so like with n35.

A

I think, if you showed this to the web codex folks, they they might think that web code exploits data channel satisfies it or some, maybe with some wasm or something they might be able to do all the things that randall referred to, but I want to be able to determine whether I've done it or not, um and what, if, if not what's missing and then that's what I'm confused about for some of these, I don't know whether I have it or not, or what exactly I need to do to get it.

G

So I'm inclined to say that we that I can take on the thing of rewriting the user, the user use case, the user experience, stuff and and and and taking on board the comments that we've had about what it is we're trying to achieve here and and and in some cases why existing solutions don't work.

G

um I think I struggle much more with with getting the the detailed requirements um right and I'm kind of inclined, maybe to do an iteration without even addressing those for the moment and just make sure we agree what the use cases are.

F

That's going to make me happy.

A

Yeah, I think that's the right priority. Certainly.

C

Yeah, I would agree I'm on the cure, so I'm just going to say that for use cases, uh it's not like we're starting from scratch. We have a mature respect here. So I think what I took away the most from was when you phrase things as we try to do: here's what we try, because people are using think webrtc for things that we hadn't predicted. So there would be a use case would be.

C

We tried to do this with webrtc and here are the obstacles we encountered and uh I think that's helpful like when you said you know we had to encode multiple times, for example. Oh that sounds like you can do it, but it's just not fast enough. So that's an optimization and so forth.

B

C

Little more about the obstacles that you found with webrtc and then that should help drive the requirements too and narrow it down to you know overcoming specific obstacles, perhaps.

A

Okay, we are actually at the one o'clock hour uh eastern, um so I think we're done. Hopefully uh we have a uh a way forward and I'd like to thank everybody for coming and.

G

A

A happy happy new year and great holidays.

G

I'd like to thank thank ben for putting up with all that.

F

Thank you very much folks and see you in january, good, seeing.

A

You bye the next meeting is january 18th. Thank you.

C

C