W3C WebRTC Working Group, 1 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TPAC 2018 WebRTC meeting - @Tuesday part 3

Description

From 3:30 PM

A

Slide my Thunder just itches we're.

B

Now, recording yep.

A

So now, back back to work, it's end-to-end encryption for conference calls and web apathy. You spray.

C

A

And me so: okay.

C

They mad so yeah I'm gonna talk briefly about Anton encryption for conference call. This is one use case for report, see envy api's discussed yesterday briefly by Bernard.

A

We describe I'm.

C

A

A

We do have a willing victim, or should we just indict one.

A

Well, room, can you did okay, we have a scribe.

A

C

Yeah this was briefly mentioned yesterday, Bernard and earlier today, by Peter, so yeah. This should be quick. I know this was discussed like last June and face-to-face and over the meals right. So my goal, or is to revive this conversation back and focus on a simple use case, hopefully make some progress, so so I'm gonna focus on fully trust, able application. So I remember from the mailing threads.

C

That's it's three use cases like fully trusted to application partially trusted and not trust it so I think the aliased won't focus on is fully trusted application, but not trusted is if you'd. So, though, application will have access to the key is joseph. Has access to the kids? The effuse can see the metadata, but most of contents on this would be enter an encrypted. The encryption decryption itself would be done by the application by javascript and only focus on audio and video no text next five days.

C

So what we're going to use is basically frame encryption, so we're going to use two layers of encryption what's already happening today with at packet level, leaving itself to be this would be between the clients and they see fuse, which is outer encryption and the inner encryption would be at the frame. That's a packet lever, so basically encrypt sign per frame before packetization and then attach the extra Mack and IV and then backside of it and then send it over the network.

C

This is different from what we have today, for example in Burke, which double encrypt at the packet level. This improves the bandwidth. The codes extra mekin IV is per frame, not the packet very, very similar to implement, and it's also not to be specific. So we can use it for future. Put codes, ie, quark I'm, not going to discuss the encryption scheme or protocol details there. It will be discussed ability in IDF and Prague 104 next slide.

C

This is too old.

C

Yeah I have much much updated side, but anyway, hey if any way to open the updated one latest one. Let me see the domain link.

A

C

I think the main overhang goes to you.

C

Yeah, the cache is much happier in solve this. One I'm just kidding.

C

Yay much more complex.

D

A

Someone who is both on a hangout and the and the mirc do that I haven't logged into our see this day.

C

Okay and yet again so basically the idea is: there are two clients: the nbz one sent this awesome cut picture. Sir multiple Chiefs change here on the letter. Security exchange also banned between twenty and company, this for Internet encryption, but it still is a technical detail, a handshake between client and AC fields for the hop-by-hop encryption.

C

So what happened is taking Zion code for him once the metadata encrypt the frame, but not to miss River and then feed it into the regular robotc flow is oxidization due to smaller packets, incredible so the great the great back area. Squirrels. Are they in turn encrypted, then finish to the resort, abusing the black hope. I hope this play. This is Becca to go through SF use.

C

The clips out encryption is ought to be affirmed that it does not see the media. Do some settings magic. Then it's a lift forward to the next client, which is being clipped again using this. If you using resource to be, and in the final client, you will first, the crypts outer layer construct the encrypted frames and decrypt the framing center in encryption keys next slide, please. So what we need to change here so Pilipinas is a typical robot see flow.

C

What do we need to inject is the polled squirrels at the bottom, which is between the encoder and vectorization, so between the encoder back on the original insert in cutter and between the oxidization decoder inside decrypter next slide. Please! So really we need two interfaces: framing crept through simple function: encrypts that takes a media type either audio or video. The source is source e.

C

The frame- and some additional data in this case would be the metadata and similar for frame decrypter and we're going to send this interfaces as a penguin set set them like the implementation in RTP sender are to be receiver XY.

C

Another proposed meant you could actually make it more generic, no, not a specific friend to encryption, but just general interface that well a process that included media before sending it and process and coded frame before after receiving it. So, in this case, we'll have like process process out going frame, pros, sorry, algorithm process or an incoming frame processor and just to simply process function and can just set the meeting out to be central to be receiver.

C

Yes, two simple questions. Do you know saying this is a good idea like just focus in I, see someone reading isn't.

E

E

So I'd ask this morning about the attack. What's assume that, what's assumed that we're worried about vulnerability in media.

F

E

Right which have to actually break in and create a break the encryption ship before forwarding on, if you're, if you're encrypting the frames at the application layer. What a me, what what a media game way be prohibited from doing any any post-processing such as video compositing and such there's.

C

No missing you, so it's basically as a fee model, so it can modify the metadata if we want to, but not the content itself so to not evil. So there are also it lets you not. You have to see the media itself. You.

E

Live audio unaffected, though so immediate way would still be able.

E

C

Like choice, sources.

E

Okay, so this is basic okay, so this.

C

Is unusable but you can, if I'm select like the top three audio, you can prevent forwarding the lower volume because the way might be in the metadata. So it's if you can access to the metadata and see okay, this isn't listen, not speaker person, so we went forward them. So you can do such a thing but I'm defining the content itself. It.

A

Could probably also do frame way, knowing right so.

C

A

The temporal temporal scale.

C

Yes, yes, those capabilities.

E

Okay, so this goes, you asked my question in the morning. So, what exactly? At the transport layer, security, whether it be DT iOS or they are the various modes- is going quick that do you think you're getting it do, you think, are vulnerable. That makes it.

G

E

Yeah but the media server case, like I, said the media server is terminating the connection because it's doing something.

E

You say yeah, it is terminated, but I think it's like yeah yeah. Let's.

H

A

Microphone yeah.

E

A

That's some s about you, you yeah.

E

A

Are too far from the microphone to be heard,.

E

A

Loose, so you can just drag it towards.

G

The ID behind, if I, understand him at correctly the ID is. Let's say you have an application that use a third party platform at the service to provide NSF you to relay right. So the only thing that the SFU does is looking at the header, possibly copy clone the the packet to send to multiple people, but there is no real media processing. You can do the copying and everything if you use the frame, marking, RTP header extension or dropping framing, as we see and so on, without touching the media at all.

G

So in the case where there is no media processing, which is the scope of the discussion SFU with relay only possibly as we see support, if you do not trust that media server, that was provided by a third party, then the security provided by web RTC. Initially we DTLS SRTP, is not sufficient, hence the hand to an encryption. You have a secondary. While you have a third key pairs, that is only between Addison Bob. The media server doesn't have access to it.

G

So when he terminates the DTLS SRTP, both the DTLS and the RTP, he doesn't have access to a full RTP packet. He has access to an RTP packet whose payload has been encrypted. Is that correct? Emmett? Yes, correct.

E

Yeah so summarized this is a. This is a middle box that I can purely the relay. Yes, no, no need to do any kind of any kind of proper processing. There's no reason to access the media. No man.

I

E

A box that you don't trust, yes,.

C

Exactly that's good.

E

Okay, only only there.

C

Are two endpoints of the call or the group alternates? Is the media contents? Okay,.

E

But that's also the other. Thank you, the two endpoints which in this case is not necessarily the end user, but the applications are making a connection on behalf of the end user to a gateway into every way that they don't trust, correct.

G

Correct okay, so.

J

I have some questions about the API changes, I'm, not quite understanding. It's this Web IDL at least browser I'm using my own language, okay,.

C

Fine JavaScript yeah, it's.

J

The it's the goal to do encryption decryption in JavaScript, yes, okay, I think in that case we should probably not try to do that on the main thread.

J

So I would question that, and we talked about.

F

Others and not yes, because it would be, it will trigger GC, and then you know you know real-time pipeline. It might have difficulties as well. No js'.

J

Could mean wasum? Yes,.

F

What might work? One thing is so you're targeting a specific use case and that's that's: okay, it's always good to start there, but you also need to consider consider the over use cases so that the api virtual designing will work or there will be ways to handle the other case in the future.

F

One potential issue is: if you have the keys available or jinn generated by GS observable by GS, then it makes it really hard.

F

So the more we can isolate the API from that problem, the better like, if there's just one specific point where we are doing that right now, because that's the only way- maybe that's fine, but it should. It should be very.

F

It should be just one point so that we can actually try to have better solutions. Hopefully, this way we can reuse V over parts when we try to tackle the next big thing, which is probably bigger in terms of use cases. Sure.

C

Enough this means, or whatever grows more generally PI like something like this and someone can use the CPI is for encryption, some of it other people convert or some other stuff.

H

This might actually be a prime example for the stream set for what RJ streams, as presented by Peter for philosophy, yeah.

I

So in my time start next, one of my slides actually shows how you could use what WD streams on senders and receivers to do the same thing. And if you combine that, with the worklet version of transform streams, you could potentially do the encrypt and decrypt off the main thread and also have it available for other processing purposes.

E

So I, don't you know, I, don't know what the protocol is. Although I look for the IETF contribution, but are you assuming that the that any private key material associated with the with the protocol in the handshake for setting up the encryption keys will be in this will be implemented and fully contained within the browser or you or you or you planning to rely on some sort of platform mechanism?

E

C

Let me change the very first site. Just be encryption/decryption, be ads application not in the browser itself, so just provide the CPRS to the application, and can they inject their own implementation? No.

E

The application will have to take care of it. It will take care of any handshake negotiating symmetric-key. The application will control any private key material. I think you know, for instance, related to any kind of cert great.

F

E

E

Okay, so so that is so, I mean I. You know, I, there's, there's well known, attacks on key material one and then, when you contain them in the application, so that is so you're not alone.

F

E

You security to a point, in other words, okay,.

A

So it's entirely possible that you could write encryption yeah all scripts, that used crypto API is to get get rid of the key handling. But as far as I understand that the proposal here is that we don't require any such thing. Let's say that whether this doesn't grip encryption or with XOR rot13 or whatever that's entirely up to the application. Is that correct? Yes, correct.

D

Be possible to use it for other things as well: yeah.

C

One is case, for example, could, if wants to store the friends by Ken, something I can come up but I'm, not aware of. Like other use cases you can just see if what other people can do with their access to make college friend, yeah.

D

I was thinking, I, think it'd come up before about FEC and encrypted frames and I'm curious, if someone's actually thought about adding a PC on top of this engineering.

D

Like you get the encrypted friends, and then you know the the problem is when you have the media bridge in the middle and if you do forward error correction and if it's inside the encrypted part so.

C

If you would have been help, I hope so time to have an after the encryption, it'll.

D

Happen after yeah, okay, that's already been standardized or it.

C

D

C

It's not standard somewhere, no.

D

I think because flextec made the assumption there would be before encryption and I, don't know where we landed on that, even though I'm one of the co-authors of it. If.

A

You don't know that I'm sure I am I. Think.

D

That the pendulum went back and forth so much on that I think the working group probably knows, but so.

C

I believe all the FEC stuff happening. That's a packet level, so the encryption is happens before backside vision just as a frame so everything she happened.

J

At ocean continued.

C

Working as before,.

J

So it's gonna say that for for me considering the use case, I think it's fair, but as far as the API goes, it sounds like this is pretty much a transform stream and then we will probably already decided that if we're gonna do any thing like this, it should be be based on what WG streams. Yes,.

F

No because there might be a decision to be made, apparently there's some work in the ITF right. So me, if there's an ITF solution, there's a decision to be made which is should should be implemented in JavaScript or in the browser, and since it's related to security, usually you do not want people to write their own code to algorithm.

F

So do we want people to write their own work like work, implementation in JavaScript, and maybe it will say maybe which will be okay, I, don't know how complex it will be, or do we actually want to let the browser handle it, and if we let the browser handle it, the API is very different right.

J

Yeah so short-term I agree, that's a decision. I mean long term. If we are considering a transform stream, API Stan, you know we can't really prevent.

H

Something we could do is expose help a utility that exposes the transference cream. That does it securely by it as part of the specification right.

F

Spit return from stream, that is, a perk, transform stream right.

J

There goodbye so.

F

J

A

F

A

We're talking about this behaves like a transform stream and in the particular use case we have here, the transform scheme is going to going to execute Java scripts, which is probably executing wasn't so other cases could do other things, including a standardized encryptor. That could be an implemented entirely within the browser, but I think that's not part of the proposal. At this time.

F

Agree that we, if we did design something we should be able to tackle both short term and the long term, and if we have a correct path between the two time regulating, then it's it's nice, because they some early adopters, might rely on JavaScript and might succeed or might fail.

F

We will see, but at least we we might anticipate that we will have long term solution that you know, but we're sure we'll be working, even though it might be a lot of work, and maybe we will never get there if the short term solution is good enough.

J

So it's a good point about pork. Are we making a decision implicitly about pork here or no we're not making a decision about work.

A

C

To summarize, I think there are two things here like this is the generic bias looks like transforms chain, and the other thing is it's like: removing the encryption as the application or as the problem just depends basically on the IETF stuff right.

A

Well, I will say, and with regard encryption in the browser or in the application, we should think carefully about the security trade-offs there I don't think we can say anything more than that.

G

So in Stockholm we spoke already about opening a little bit the pipeline right to put arbitrary transform in there. This is just a variation of an arbitrary transform. It might be duplicating all the stuff. Some people send media over WebSocket like zoom right instead of using way about C and so on. This D there any reason to actually reject the proposal because we might, in the future, do the same thing inside the inside.

G

The browser I understand Security's little bit sensitive, but this is if this is what the application want to do any fit one of the design we have agreed to discuss previously, while rejecting it right we have I was saying you know: let's not do it because we might do work in the future hi or what that's the way I perceived it. So my prediction was wrong: I.

I

Agree with dr. Alex in the sense that we should add a mechanism for doing arbitrary, transforms and then, if applications want to use that for Indian encryption they can and then later. If we feel that it's worth making something that standardized in the ITF into the browser, because that will help people do it right or lower the barrier to entry or whatever. Then we can also do that. Yeah.

F

I think I believe that it's you start with something that is very focused. It's very cheap because there's already something, but we might be going to, and then there might be a longer term thing. I was not at all saying that we should refuse that proposal. I think we should consider it as a use case and as some somehow as a goal direction so that we we create a model that will comply with that at some point of it will resolve most of the issues of this use case.

J

Is it not covered in Bernards use case document.

C

It's covered at one line: I just used to describe it in more detail, yeah yeah, so.

A

What I'm hearing here as a conclusion of this this part is the working group who would like to see this proposal fleshed out and based as closely on transport stream as possible. Chance transform stream all.

C

The money transform, stimulate Bernard or someone else and.

A

Transform streams are owned by the by the without Mooji yeah.

I

F

I

To the encoded frames, in order yeah.

F

I

Transform them is not, it is covered by this work. That's not something we have yet, but it is something I cover in my next yeah I was.

F

I would like to make is that this creates a requirement on exposing and new new points in the pipeline and that's a debate we we need to have. Maybe we will agree. Maybe we want to agree whether this is a use case that we should consider during the discussion. Yes,.

A

That's it that use case require it. It's a driver requirement for that particular one, so should be a switch to Peter. Sorry.

C

Just one last question, because I'm not familiar with the teabag process, so what's next like I'm, going to like discover this in under meaningless, like how come move forward from here, we.

A

Will we will take this to the mailing lists, as in the first place, seeing us what we can flesh out in the use cases and and the second case, to see if we can get the concrete proposal together? But do we have consensus.

I

That we're going to conclude this use case that we're adopting this use case because at the end of the face-to-face in Stockholm that wasn't clear that we were I, think that would be progress if we were adopting that use case. What, whether or not it's a specific okay, it's from the ITF version or a generic mechanism for processing frame, all.

A

Right, transforming you could have dreams it so so I'd like this, so so let let's consider just that issue. So what I'm hearing is that people want to a number of people have said that they want to support this use case in WebRTC Envy.

A

So does anyone wish to speak against supporting this year, including this use case in our web RTC and be requirements? Would.

J

It be fair to say that the use case is to have end-to-end encryption.

A

The use case is to make it possible to have and an application do end-to-end encryption well.

J

That's the distinction right. Yes,.

A

That's a very important distinction and I.

J

Think we couldn't agree with the broader use case, at least, and.

A

One this brildor roto.

I

At the last face to face the Stockholm, there was confusion or whether we wanted a use case where we trusted the JavaScript application, but not the server and versus not trusting either. And so this is, we trust the application, but not the server. And if that's the use case we're adopting or not whether or not it involves an API that assumes ITF docks and built into the browser or not like you're still trust in the JavaScript and.

J

I think is UN mentioned. We've fully had the discussion yet of if that requires exposing rod, that raw network data, I, guess and so I think I'd like to agree on that. We should support end-to-end encryption on the application part. Maybe we could take it to the list too. So I I get some time to confer with my my folks.

J

A

Have a number of security.

I

Did we make any progress.

G

You know speak about it at Prague, in more real, and yet we don't know where in Asia so.

A

I, what I would like to say that we support really adapt, have adopted the enter and use case where we trust the application, but not really as part of the requirements? That's a step forward, okay, good and then anyone do you want to verify that on the lists? Yes,.

J

E

Whether the application should be able to transform raw frames.

E

But you know frame data, then really once that should be. That should be the primary question to be answered, because that that, if the application wants to implement their own protocol in the end in order to encrypt they have the capability to do that with the bread and what what's available in the bars of the day. That.

I

That's a separate question and I: don't think we have consensus on that, but if we can at least have consensus that we're, including one instance of a use case, at least at least we're making some progress.

I

Yeah I'm gonna talk more about the second question. When you're bringing up in my presentation, I have a specific proposal for I wish you do it.

A

The work group is still considering the generic access to a code, the data use case. So with that, can we jump to Peter yeah I'll, see if I can bring up the latest and greatest version of your head? Please not the one. From an hour ago, you sent me a link half an hour ago else right. That's.

C

A

I

You you skipped ahead: okay, the link to themself I'm, talking about media over quick, but it's more like bring your own transport, so it could be me over other things too. So next slide. First thing I want to bring up is the fact that people are already doing it. For example, there are already people sending live media over HTTP over quick and putting it into MSC and they're, asking us for a better server push basically, and they would like to use the quick transport to push chunks of media over that to push it into MSC.

I

There are also people doing live media over SCTP data channels already and putting it into MSC. There are two examples there that recently had some. You know details published and I reached out to one of them and their specific request was that they would like to switch from SCTP to quick because of the pain of having setp on their server.

I

The last is that people are already sending media over WebSockets, which something was brought up earlier today and they're not evenings went using WebRTC at all they're using web assembly to do the encode and decode for both audio and video and I haven't talked to them, but my proposal would be that quick transport would be better than WebSocket. Assuming we didn't have the requirement for ice and you could do a client server. At the very least, you could avoid the head-of-line blocking and congestion control problems that WebSocket has so next slide.

I

You can already do all these things, although somewhat poorly on the decode side, you can already use MSC, which is pretty good, and on the encode side you can already use webassembly and either web audio or canvas. This is what zoom is doing and on the web audio site, it's pretty good, because audio encode and decode in web assemblies, not too bad, but on the video side, video encode with web assembly is not so good.

I

So, basically, you can already do the things that I'm talking about today, I'm just talking about making it so that red box is not so red and actually all the boxes are more green. So next slide and people are already planning on doing video over quick I'm, a member of the copán, the second screen working group and we're, as I mentioned earlier today, considering doing media over quick for streaming purposes.

I

There's also a mailing list already in the ITF for talking about sort of next-gen, arty media and someone's already proposed the idea of doing video over quick, the implementation of WebRTC that is widely used. Lib WebRTC is adding support for media over quick. We have some slides and more detail about that later on. At the moment, it only supports mobile because there's no Web API for this and that the team working on that has already made an experimental mobile client to see how well this works, and the conclusion is that it works pretty well.

I

But web support is a problem because there's nothing in the weather that can do this so or would not do it well, referring to my boxes previously, so I have some proposals for how to fix that next slide. There are two proposals: one is to adopt. The quick transport which we already have expect for, but which is not adopted by the working group and, second, is to add what W stream support to Archie sender in our to be receiver for encoded media, something we were just talking about next slide.

I

So on the topic of adopting the quick transport I'd like to point out, there's a lot of interest from outside the working group. So we could continue work outside of the working group either, for example, in the ortc community group or in an incubation group.

I

There's already been people that have wanted to start an incubation group to make a version of WebSockets that runs over quick, basically covering the clients for use case, but not the period appear use case, a version of quick transport, essentially without the ice transport underneath and some people would even prefer to be outside of our working group. The tag for example, and the tag review mentioned that why is this in the RTC working group? This is mortar rather than RTC, so I feel that this is going to move forward one way or the other.

I

The question is whether this working group wants to be part of the work or not. So that's my first proposal. It can stop and talk about that before I move on to my second one.

B

J

So muscle precision is still that the quick spec is still busy doing TLS and HTML, and it's premature to to send media over quick in a web. Spec.

I

So to be clear, I'm not proposing any web spec about media over quick I'm, proposing a quick transport for doing data over quick and a mechanism for transforming audio and videos frames from RTP sender and receiver I'll get to that in a sec. Those two combined could do media over quick, but there's no spec here about media over quick.

J

Okay, but yeah I think that's the same thing, though right.

I

Well, that's like saying we're like saying we're standardizing media over SCTP because there's an sctp data channel, which is not the case right, but.

J

I think the information we've gotten from the quick working group is that using it right now, they're focusing on caelis HTTP and not any other uses other people. People are gonna use, quick.

D

For other things, sure.

J

D

I, don't think it's within the quicks working in the IDF's quick charter to think about media were quick, I think there are people independently in the idea in the IETF which have thought about Media overcook I'm, one of the co-authors of spec. It talks about RTP over quick, so there are people. Definitely thinking of it. It may be part of the quick working group or might be part of a boutique or or might be part of something else remains to be seen.

A

To put it another way, the.

A

The current specifications for quick allow transferring data.

A

It's possible that there might be changes later to quick that make it more useful for transferring data that that contains video frames, but that doesn't mean that doesn't prevent anyone from using the current version of quake for transporting video frames, whether whether or not the spec says anything about it. So the so.

A

Not not doing quick, because quick hasn't admitted that it's used useful for with the frames. Well now it's doesn't pass the smell test for me.

J

Well, I think you know to in order to adopt a quick transport would be you know using quick wholesale for this one purpose. My understanding was that that would rule out that might have some impact on other uses of quick potentially and it's.

J

We still consider it too early to know that what.

A

Do you mean what do you mean by impacts in this case I.

J

Think it was touched on in Stockholm I, don't know that our position has changed much I'm.

A

Asking you what what do you mean by impact impact on operations, impact impact on Network impact on and end systems into the impact on standards? Other.

J

Uses are quick basically like if you have a quick transport I, don't know that all the network concerns are covered, and that would be something that I I think we should rely on the quick working group to tell us how that should work.

A

I'm not convinced that.

D

The quick is a congestion control protocol over UDP, so I'm assuming and it has some security property so from a networking perspective, I think if and when the quick working group and the IETF clarifies it, and it's going to probably go into the II's iesg and when it does, it can be used for anything I guess. The question here is: do we want to use it beyond the scope of whatever the quick working group has delineated it for I I? Think it if it's a congestion control protocol, we can use it for anything.

D

Given that HTTP 2 was HTTP was used for doing video streaming, which it was not initially destined to do so, and HLS both use HTTP for a video which no one thought initially was a way to transport video. So not the same use case though, but it allows us to experiment beyond what's possible today, I.

B

B

Think I think quicker for transferring data sounds very interesting in and of itself I think being able to transform frame sounds very interesting. You know, love themselves, I think you know being able to do. Swept up. Encoder/Decoder sounds very interesting on their own and, like you take all of these together, it sounds very, very interesting and I don't know details but I mean I think this is interesting and it has potential so I have the second.

I

Proposal for the streams part of it coming up like I, would appreciate if we can come to some conclusion here. So I can move on to the second proposal. I.

J

Think what we said in Stockholm is: if we could proceed in a transport agnostic way, that would be probably away a middle ground for now. What.

I

Do you mean by transport agnostic and that.

J

We could consider all the other benefits that Henrik mentioned strategies down the road so that when, when quick is ready, that might.

I

Be one of the options? That's essentially the second half of the proposal is transporting now statement. So there's a transport Rosel here and a transport agnostic proposal, but I want to know if we're. If this working group is going to adopt the quick transport or not because if it doesn't, we should proceed somewhere else.

A

So let's try a simple one: who thinks that that this working group should adopt like the quick, the the quick, specific API document. Well,.

J

I was I was instructed if there any attempt for consensus should be on the list that.

A

Is noted- and this is it so- this is a straw polls for the information to see if there's any point in continuing who thinks that we should add up this documents, who thinks that we should not adopt this documents.

A

Thank you. We will take this to the list. Thanks.

I

A

E

A

Is a proposal for adopting the quick API document proposed by Peter? It does.

E

Not say anything about.

A

What this API could be useful all right, let's move on a proposal to.

I

Proposal to is about nothing, did with transport just media, so the gist of it is that the RTP sender and RTP receiver can include a mix in that. Has this on the sender side, two new methods and on the receiver side, two new methods. It allows you to read encoded frames from the sender and write encoded frames to the receiver and then write feedback from so I read feedback from the receiver, such as a keyframe request and write the feedback into the sender.

I

If you go the next slide, there's an example.

D

Yeah there's also local stats and local feed. That's.

I

In the feedback, that's.

D

On the feedback, yeah Oh.

D

I

The stats in the feedback now we could tweak that if we felt like it get stats on this was a better approach like this isn't the final say on.

D

I

D

To me it would seem like maybe what Dom's have made more sense like when you say read: can you go back? One slide sure.

D

Yeah, so you had read encoded frames, you would have read local stats or get stats or something similar there, because when you say, write feedback, I'm, assuming that's coming from the far side and not the local, oh yeah,.

I

You mean taking sender stats over to the receiver. Oh yeah.

D

I

That's true, you have, you need to get stats for that. I find.

A

The direction of the word and read to be totally confusing on this slide. Sorry.

I

Okay, well, you can look at the comment. We can't we can bike shed the names, but the gist of it is the encoder. The encoded frames comes out of the sender. It's basically acting like an encoder and you bring your own transport. You send it. However, you want and then or you process it.

I

However, you want, you can pull them out of the sender and stick them back in I have a different site for that a little bit later and then two on the receiver side, you can put the encoded frames in and treat it like. A decoder yeah.

D

I just wanted to make a point that there might be stats on both sides, which might be local and remote yeah you're, getting from.

I

Remote urine, you're right and the way that you can handle this is that you can have the encoded frames coming out of the sender, be either frames or status.

E

I

That's actually the way that I specified it in. If you look at what goes in the readable stream, there I was just hard to fit all that at once, like yeah.

D

I do remember that from like the slides before, but just not seeing it here, just yeah.

I

I was trying to simplify the slide. It's already complex enough right, yeah.

E

So what have you since your since you're managing the applications managing sone transport actually need something different, depending on the type of encoded stream like an iframe or a key frame? What would it whether.

I

It's a key frame or not is in the the frame that's given to you inside the readable stream. When you call reading code streams, okay,.

E

I

No it the the thing you get in it's on a future slide is an object that has metadata on it, including okay,.

D

I

It's a keyframe or not, there's no binary thing. You have to parse it's like so.

D

I think specifically, you could easily drop that frame if you did not want to send it for whatever reason: yeah yeah, just don't send it on your transport. So.

J

I'm also a little confused about the wording here, but I think. My main objection here is that this adds well, it's not it's less about adding what WG streams to sender and receiver, but adding a way to get data out and into sender and receivers right. It's a way to get encoded frames out of the senator and into the receiver. Yes right so I'm not sure we.

I

Should expose that on the main thread? That would be my so this. If you go to the next slide, and you look at the example, this entire thing can be off the main thread. Assuming that the transform stream function call. There is something that gives you a transform stream. That can happen off the thread using any of the mechanisms that we thought could be possible, so the pipe through in the middle there, where it goes to the either the steriliser, the or the parser, would happen off the main thread.

I

The only thing you do on the main thread is set it about right.

J

But in writing in the in designing the API that way, we make it possible for Java Script to do to easily do foolish things like that would end up doing it on the main thread. What.

I

Will happen on the main thread that I mean if we did it or if we did the transform stream with a work late you you can't run anything on the main thread.

J

Right, I'm missing, maybe, for instance, if other approaches would be that to say these methods are only exposed on when, in a worker, for example, that might have.

I

Oh, you want to prevent people from from accidentally.

J

I

Don't know if that's really worth it, because I've talked to several people about how important it is to them the people that are using SCTP to put things into MSC and they're, doing it on the main thread, and they said it's not a problem for them. So, even though we think it's a problem and I totally agree that we should come up with a good solution for it, which is why I presented so much about it. There are people that think running on.

I

The main thread is fine for them, and so like telling them they can't do it is kind of well. It might.

J

Be fine for them, but it might not be fine for browsers who might have all other tabs and people want customers wondering. Why are all my tabs slow? Because you have a tab and you forgot about, does all this so.

K

I guess the question is: is it food? Can that has any other purpose and shooting in your own foot or it's a real reasons why you wouldn't want to go up the main thread or doing processing of these frames.

I

And if somebody.

E

I

To use it after me and thread they can and if they don't I mean.

K

I

Just a food gun, then I, don't think it's just a foot gun. Okay, I think some applications will want to do it on the main thread and I. Think that's fine, but a lot of them will probably care about not having it on the main thread. So I think it's good to provide a way to do that. I mean.

K

I guess with general that if we can push people to have the right thing, make it easier to do the right thing rather than the wrong thing. That's better.

E

K

Don't know if that's up to forbidding it completely on the main thread, but there may be you know more. We could do to avoid it being a default thing. You know, because you don't want to look into workers or whatever yeah.

I

I think, if that, if it's easy to use a transform stream off the main thread and we're basing this off of what WG streams and all the examples people read are like here, get this transform stream and get this and plug it. You know they see this line of code is the example. Then the obvious path to take will end up being one where you are off the main thread, but having it like throw an exception, because you didn't do right, yeah,.

J

Maybe I'm missing a piece, but I mean the generic transport transfer stream with a uppercase. T is a pretty much just a JavaScript I mean it's a class, but it's a JavaScript construct that doesn't automatically make it exposes. It lets JavaScript right classes that act as transfer streams, but does not it's still not a browser object that the browser could then move that information off main thread. Not what I was saying is that, if, if we.

I

Have an implementation of transform streams off the main thread using a worklet or a worker, or whatever we've talked about before, then it should be like five extra lines of code in order to get one of those. Instead of that lines of codes and characters in the code, take it one of those instead of the classic on the three transform stream right.

J

So yeah I think this is interesting. I think it's one of the options I also believed it's one of the lower priority items that when we sorted all the priorities it sounded like this was on the lower of the list, at least from what UN mentioned so I think it may be a little early to say one way or the other, but like some time to look at it.

J

I

So then, is it worth making a an extension spec for this? Just like we did for quick where then we can debate whether we actually adopt the extension spec or not, but we have something specific to look at more specific, then, once one or two slides.

A

So one of the problems with evaluating slide, where has always been that there are lots of Devils in the lots of details like virulence mention of where do the stats go right? Well,.

I

So this the same happen with the quick transport and we learned a lot from both writing the spec and implementing it, and we ended up with a much better place than the original slide. So I think we could do the same here. Question is.

A

If we should do a short start that narrow it so I'm a I'm, a again I mean I, hear you about I, do you do it here or you do it elsewhere, but in.

E

Either case your.

A

It will you personally be free up any time to doing up we about to see 1.0 stuff, but by not talking to the WebRTC work group on this one I mean it's a question of thus starting this stuff now make anything else later or not.

I

Maybe the other way putting it is: are there other people interested in working on this spec so now so.

D

Personally, I think we are willing to contribute resources to this effort and especially documenting it, and especially for this particular use case of both media /, quick and a quick bi-directional and unidirectional flows.

D

J

That the tricky problem is getting things off main thread and we've heard a couple of proposals earlier. One of them was to you know, first bring data channel to workers and in ortc like way and then maybe other objects would follow. That would only be accessible in workers.

J

Maybe workers are fine with garbage with regard to garbage collection and video. Maybe it's not. Maybe they work late way is better I. Think there's a lot of experimentation needed, to wit, to to know which approach is going to work better and I, worried that focusing on the API first might be pre-selecting one or the other. So.

I

If we start an extension spec to allow access to encoded frames from the sender and receiver, would you be interested in contributing by figuring out how to properly make sure it's off the.

J

Main thread I think personally, I'm gonna be busy with one point. Oh.

I

Well, hopefully, he'll be done by that with that by the time we've got the extensions back going.

I

All right, so anyone interested anyone else interested in contributing. We have two.

G

Expressions of interest so far right, yeah I, have one Russo's working on that already experimenting, but I think this is the stage where we are experimenting. There will be a meeting of the quick working group at the end of January in Tokyo, today's working group and today's hackathon interoperability hackathon, and things like that. So maybe that would be a good place to hack on an ID and on the web at resistance. I understand that there is an existing implementation that is RTC, but that is in the code of chrome and remote DC standalone as well.

G

So we haven't started coding, but we were thinking about starting the experimentation in there right.

I

So I'd like to give some time to Anton, who has been working on code inside of Lib web RTC for adding support for quick and I think it'd be useful for people to know about the progress he's made so that these kinds of things can move forward. So can you skip forward a few slides one.

J

More comment would be that I think what might be useful. It is to get feedback from the what WG stream group to see because I know, for instance, audio work. Let's right now does not rely on readable streams at all to ask messages back and forth and I know so if they have thought about so this use of transfer streams to offload to main thread and exactly exactly how that will work. It's still a little of a new territory so be good to get feedback from them. If that's a reproach to a sanction, yeah.

I

L

L

Next top this one, yes, so I'm I've been working on integrating, we can leave a party see, and this is still highly experimental, although we think we'll be successful, we have very successful prototypes working and we are also actually already taken in leave a party she liked the interface I checked in already so I think I mean besides, like whywe implementation, quick at all.

L

If I think this viewer that we are doing it will make it actually easier for the web applications and for the browsers, because the way we are integrating it, it will make easier for browsers to implement proposed API is that Peter was talking about if we decide to go with this API s, and also we think that for applications today, it's a pretty higher cost of doing both native and web apps. So if we have similar building blocks in Libra party she and on the web, that will reduce the cost.

L

So why why we are so passionate about quick, familiar I? Think Peter may be told, talked about it many times in the past, but I want to reiterate it because it's we started it not because of the web started it because we want quick was a media. We think it's much simpler stack if you familiar with RTP I, don't think you will disagree. There are views interest inside benefits like view art, it is to set up encryption and we see many opportunities for quality improvements that we actually prototyped locally.

L

We see opportunities for low overhead, but retransmissions and very easy to add extensions and features like did you try to add extensions or RTP or implement an improvement story. Transmissions like anything, energy P world is very hard and also quick, rotate, the channel and quick Committee. Of course we want to use the same path so quickly how we are doing it today.

L

If you have a miller with the property seeds, the code is very RTP aware, even even the media parts of the code, so we actually refactoring it so that between the Transperth part and encoders, there is this media media interface layer, which is strikingly similar to Peters proposal, which is like here. Is you encoded frame or so send encoded friendly ship encoded frame and send me the key frame and so on so but in very Factory in the code? So it will be like transport agnostic?

L

Actually, so that you can, we will implement the legacy RTP on the same interface and then the future concept any transports and they have a link in the bottom. You don't see it. You can look at the interfaces. Currently, we are also doing the data transport implementation. For now the data channel. Sorry, for now we will use existing data channel the web RTC phone, the quick so that applications can migrate without in any coach angel. But in the long term.

L

Of course, we want to use something like quick transport that Peter was talking about and then have the media through the same quick transport interface. So what is this media transport? Actually? What is this middle layer? What is it so in our prototype implementation? It's this one, quick per frame we implement. We define wire format and implement serialization deserialization then send it to quick. We use protobufs currently, which is like super easy for serialization or extensions. We have some extra transmission control on top of quick because we need some different audio and video presentations here.

L

Adaptation and pendens allocation is an interesting topic because I think the long term you want to have this media transportation much tell encoders and what should be the bitrate or frame rate etc. Right now we keep. We keep like the adaptation inside. The stream receives 3-month sense sense, dream sorry inside the send stream, but will probably move it inside the transport later, and it is a pluggable component. So we think we're is no need to standardize it.

L

They could be default implementation, but I think it will really be if it, if you don't standardize the wire format for 4 frames.

L

So we have some of the challenges. The congestion control was like one of the biggest issues for us. We found that existent way. Congestion control is not rated for real-time, we did not give up, but we decided we should try to integrate congestion control from Lee property. She which works well today with real-time, and we will plug it into quick. But the question is what to do next to be standardized. It and quick, oh well, keep it as pluggable or should we fix PDR I? Think it will depend on on our success.

L

Hdpe is something that we kind of said. Ok, we'll do it later, but it's an it's an issue for us. So currently we assume that application would Whitney go. She ate quick transport, but we should decide what to do forward. So one option is just not to use peerconnection API for quick or I mean we can cheat, but chitinous, not nice. We can add, but we can also add quick media transport option for HDPE, but I think maybe we need to standardize the protocol itself.

L

If, if we make quick like a visual part of peer connection, if he/she is not currently supported by quick I, think eventually, it will be needed for a good quality media and just general question what is next for Libra party. She is, that is a clear connection model for native or or do you want to have building blocks and Kieran thinking exactly as I said in the beginning. It would be really nice to have some since in some similarities, between web and native and to give more control to to the apps.

L

So like media transport is one of these building blocks that we are proposing, they could be ice encoders and so on.

D

So I have a clarification.

L

Question leave.

D

It open for the application developer to choose if they want to send the media frame over a single, quick transport, multiple, quick transport or yes,.

L

D

C

D

L

Did you have, did you have more slides if there are no questions.

E

Yeah, we in fact was supported and quick at one time and it was ripped off it.

L

Was it was correct? You.

E

Learn from that, we have considering adapting flexpet I.

L

Think they did not, they did not. They did not consider real-time scenarios and when we think how a fish you should be implemented should be very well aware of the media like, for example, for audio and video, it would be very different and there is some feedback on RTC the jitter buffer size. You want to take it into account.

L

I'm do you? Do you know Peter? What was a issues why FEC was not used for they.

I

Removed it because they didn't see any benefit in measurable statistics, one that.

D

The reason for that was basically because you have only when you're sending packets in the inside a quick stream the only time it would help you is during the tail loss, because that's, but at that point you you have so little data in your buffer, that it was only at the tail end of that stream or connect I, forget channel there. You would see that benefit in our case I guess it depends a lot on what type of strategy you're going to use to send your frames.

D

Are you going to open open if you're going to send a group of pictures over over a stream or if you're gonna send a single frame or a single packet, because that's totally up to you as an application, developer or decide what you want to do and the use of faq is more with long-standing sessions. So, if you'd only go in to send like one frame or less than a frame over a stream, it's not probably going to be beneficial. You want to do it in the application there them yeah.

E

Because I'm trying to kind of marry this with what we're talking frame-by-frame, have you talking about letting the application be played by frying process? Inferences that it then become.

E

You know it becomes difficult for the application to buffer that many friends to make that exact, effective in that case and then we're back and so we're back to actually saying no, we don't want to get the application and give the application that capability. We want to push it down. Implementation, we're about the management is probably better handled, but.

D

So there's three solutions for the fact right: one, the encoded frames that come out from the encoder have like FEC already there and you don't worry about it or you push it push that responsibility down to to the transport which would then have FEC or you could have all three you could do bring your own FEC have something coming in from redundancy from the encoder figuring out and quick, also like I'm, not suggesting all three, but I am what I'm suggesting right now is that maybe we need to figure out, let's get the ball moving and figure out faq and congestion control in some of these things, as we go down that path, because if we want to give the application developers the flexibility, maybe all three choices are valid and might depend on like configuring, your encoder to like say, like hey, I, don't bode FCC.

D

You just figure out the FEC at your and give me FEC or I'm smart enough I'm, going to figure out the FEC myself or let the transport figure out the FEC and I think all three options may be valid. I want.

L

To add, even even if you leave it to the application like, if even if encoder gives you a fishy, you still may want quick to be aware of it, because you won't talk, maybe frames that were recovered or like. Oh, you don't want to merge. Fec frames with right.

D

And I think I think that there's a lot of when we talk about the the statistics, both from the receiver side and gathering statistics from the local side, it was those are the points of presence that I would be really interested in to be able to like get these statistics and maybe not have quick. The transport have to figure these things out. Maybe there can be input coming from the application to tell the receive side that I've already you know, do not send these knacks for these quick things, yeah completely so saying.

A

That we're now at the usual backlog compared to planned time, I think where it's time to wrap up this segment. Do it I note that the two pieces of decision?

A

One is what the on that on the web part. You see quick API. We have a decision to be taken to the lists on where to dr. doc document and I, hear the working group encouraging and the proponents to turn the streams page slide, we're into a proposal so that we can actually take a position on adopting a turnout. Apart from this, are there any decisions that need to be taken based on this segment and thank you for the very interesting information.

A

Hearing silence: let's go back to review so.

A

A

One thing we've heard heard, load loud and clear over the last few days is that people want web RTC 1.0 to be finished as in stop wiggling, and they want in implementations to be interoperable, which means testing enough to make sure that they are so that's a high level bit. We also heard a number of things that indicate that people are wanting to use and real-time media things in web browsers that are not within the current webrtc 1.0 specs and that they are going to do so, no matter what we say about it.

A

So if we want to have its standardized within the WebRTC workgroup and we'd better get on with it, third get the webrtc 1.0 done with hype right. So that's a hard combination to match up, but we'll have to do it. Somehow the chairs will go on of and contemplate so concrete things of decisions that we decided. We have a number of issues that were looked at and said.

A

Okay, we decided by combine our agents, gum, media functions, secure context, bang screen share, full screen is in front of non-normative. Respectful constraints will be merged. We will not allow URL, white and blacklist the screen share. We have a proposal for removing the surface type constraints and.

A

We have a removal of the must, not statement on changing sources and we have consensus aggressively to move, get display media to media devices, which is therefore secure context.

A

We have not made a decision on exclude on audio. There was the proposal that we might say that in this context echo cancellation or means exactly that. But this is not a decision. Please go on discussion be discussing Weber to CPC.

A

We had a consensus decision now verified and duly recorded to stop saying anything about, checked out ID mapping into as STP or out of STP for that matter, where consensus, rename transport of transport to transport of ice transport and that direction is set when SRB up the set remote description answer is, it is done clarifications to colic parents accepted said. Kotick preferences remains on transceiver and obvious has promised to write a tests, use order, an answer as preference don't make life complicated and make codec payload type read-only select.

A

The candidate pair needs further work, so these are non decisions. We didn't take a decision on, nobody can came with it and we need to discuss, discussed codec payload type in that transceiver, and they can Bernard promised specially to discuss that now. If you see anything in that this quick review that you think is the wrong recording recorded gyeongree. This.

B

Iv gap not entirely sure but making codec prototype read owner I, think that depends on other decisions that require further discussion. But maybe, if you Adam, maybe there.

A

It is not a decision.

M

A

Can either method may be reconsidered? It sounds.

J

Good, what was use order in answers? Preference again? It.

A

A

That, when you, when you get it, when you do as set remote description, will announcer and the answer has a list of hallo types, which is the recipients preference. Then, unless the the, unless the user explicitly assess use this codec, it will use the first one list, make it simple.

A

A

Testing we will have a regular web cut from test review, meeting chase editors um and I didn't catch the name Karthik I volunteered.

A

Now this was interesting that.

A

Prabhat and then back, then it should have changed. No II did so. We will create a perspect web web. A web platform tests directories so that we get everything linked up to the spec that it's specified at. We will aim for a simulcast work, a virtual interim sorting out CEMA castings in January, and we will aim, for that, doesn't mean hits, but it means that we will aim for a hackathon. That's the idea in March rocky.

A

Use cases are adopted as a working group document on web RTC eyes.

A

We have said that we can change as candidate pair to an interface.

A

Yeah that reflects back into PC, so that will cause a pull request it on PC, based on the position in the that came out of the special nice. That's not that's a nice thing about having an adopted the working group document that this is a working position.

A

It will consult with the CDN folks on whether is dealing or not or how should work when it when it's needed, and we will use networking information to represent network information instead of defining our own type. That may cause heartburn down the road. If we, if the web RTC I spec, gets to be considered. Considering for candidate recommendation before the the network, information spec gets on some kind of formal, formal status, we will think about that on SVC. We will adopt this document now, that's to be verified on the mailing lists.

A

We have a salt consultation with Web Audio what you needed. We have a consultation station needed with with the machine learning community group about what they need um on audio. We did not make a decision to adopt my draft for and non Web Audio API, it's from the feedback. It seems that it's very possible we'll just drop it on.

A

Streams new api's need to be stream is based, I.

A

Recorded a non-decision on either adopt stream messages or read more info. I can't tell exactly what I entered.

C

A

Waiver has we'll have to go back two minutes, but we definitely have a decision that we need advice from the stream folks Dominic at KU about how to get out of the main thread. Peter I believe that you volunteer to do that. You.

I

Don't remember volunteering but I suppose I could try anyone.

A

I

Would be better than me, he I.

A

Suspect not especially after you have made such a such a bad job of not of the king.

I

Alright I'll take it on.

A

Data channel, we will add an on closing event.

A

J

On the previous two slides on a data check, was there any decision on Webber QC data channel expansion spec? He said it was unclear and it I guess: that's either Dobbs three measured it or need more info. Yeah should I keep working on. That document. Keep.

A

Working on that darts I think it's I, it's one of those cases where yeah we have a grand vision of the bright shining and streams palace in the sky, and we have a number of thoughts that might lead there, but all of them seems thank you this step. So why not just take it, though, keep working on this, but we don't have a decision on it. Yet.

A

And stats stone service. That's the proposal is acceptable. Let's merge it. A dot made the senders and receivers. We don't either a chance severe object. At the moment we add stream identifiers to senders and we move the stream objects to be obsolete.

A

You never will write the PR tools say exactly which stats M when.

A

It and we do not remove track stats at this time, but note that it's not mandatory to implement and if the web RTC PC is back here says that this mandatory will fix that III.

J

Think respect right now says they're only on the sender, so we would need to add language if we wanted to be on the receiver. Yeah.

A

A

We expose IP addresses only if an ass seen in an ad candidate. That is, if they, if it's mdns, kam of large name address, then we show up them. We show the mdns camouflage and if it's IP address, we show the IP address and if we didn't get it through I candidate, we don't show it will copy the size, stats to outbound RTP and remove them from sender. We will not remove them from track.

A

We will discuss the details on the when the pull request is ready for discussion and we had no consensus on leaving Network type in the spec or taking it out. So that is for further discussion on.

A

Workers among the options that UN presented we'd like to pursue the hope option to that data journalism in work is based on the idea that WebRTC is the and it's available and can be used to establish the data channel that will get the number of API is exposed to workers, but not media.

A

When we offers to specify this when there's the red upper interest, so any developer, who has interest, will then pestered un? It is gone into hiding. It's.

I

It's probably worth noting here when you say workers that you mean driven by the desire to have them work in service workers, which is different than desire to have them work off the main thread.

A

Now this is about workers, which is the JavaScript complex that exists independently from the writer.

I

But they're there web workers and then their service workers and I believe this is in the context of wanting to work in service workers. So, for example, if somebody said hey we'll do it with worklets. Instead, it wouldn't cover this, because it's specifically about service workers, I.

A

Just specifically about workers, I did I didn't hear. People say that they would want it and web workers or in service work workers one or the other.

K

So one thing that makes service workers different from workers and makes it a particular motivation fortune 2, is that in service worker you need to manage Network changes and the life time, and so on, like reaching simple workers, you could just keep on the main thread: we're not in Turkey service worker, so I think that's the reason for the deactivation exactly so, even though it's not only for workers, service worker adds an additional constraint which makes that option more appealing than some of the other option that also appealing in other contexts. Exactly so.

A

Which so at least service work some man, then it's no lease, but is this method? It's a service workers, the proper.

I

Subset of workers, if you, if it works for service workers, it should work for other workers, but if it works for any worker, if it works for web workers, it doesn't necessarily work for service workers. So that's all by putting service workers here is making it a little more clear about what we're trying to achieve. Yeah.

A

So if so, that's I.

I

Just think it'd be changed workers on the second line they're into service workers, then that would be slightly better.

A

And we'll just remember from our learning that this is. This also means that the workers are covered, other workers are covered and this work has lower priority and Weber to see 1.0 and Weber Tracy ice, since it depends on Weber see, is that kind of a logical, end-to-end encryption.

A

The work group will adopt the end-to-end use case where with just the application, but not the relay with those some about the Stockholm on which of this will we would adopt, but we will verify this on the list because we're slightly I think the web worker you be still considering, like generic access to encoded data use case, whether that's adopted or not, and the working group recommends basing API zone transform streams.

A

We've we're starting to fall in love with streams.

A

Though the quick, on the basis of the quick big, bring your own transport presentation, the working group will ask the list if we should adopt the Weber to see quick API documents. I noted the clear majority in the room indicating that they wish wish to assess so adopt and a couple of strong voices saying we should not, and the working group encourages Peter to turn the stream spaced slide, we're into a proposal that can actually be evaluated. Production.

A

That was all the decisions. If I I noted that we made so far, does anyone remember this idea? Anything else.

A

A

A

This is the end of the slide where so we now have a little time to say: okay, how do we go from here in such a way that we actually make good.

A

Progress towards our next goal and what is that next goal? I see kind of two groups of goals which are somewhat orthogonal. One is pushing the specs of WebRTC one by doll to the serial Sarah bags and state and which includes getting the specs fixed. Getting that tests done getting the implementations up to speed, which kind of leaked like tree branches of that we have as a working group. We don't have any control over in from implementers, but we do have implementers presents that have strong input into what their companies do.

A

The other thing other thrust is that we would like to make sure that if and when we about a real-time functions on the web are considered for Standardization by other working groups or by this working group. The expertise in this community is considered.

A

That might be take take the form of us adopting proposals for processing within this working group, or it might take the proposal that the approach of just making sure we know about each other. As the second screen working group presentations, there was a clear example of so what advice do people have for the chairs? As what should we do next.

N

Carol, this is Bernard I think we clearly have some process problems relating to WPT, so that seemed to me to be the most seriously broken thing. It doesn't really have to do with the working group and it's an example of something not that the working group that we.

M

Haven't paid enough attention to.

N

So I think that's clearly something I think that, particularly if we eventually want to get to test before commit, we need to fix.

J

Yeah I agree with that and I think that's that was right and my input would be that the sooner we can finish with 1.0 the sooner we can focus fully on the next step.

N

And also I would say, with respect to finishing 1.0. One thing I've noticed is that one reason things don't get implemented is that there are problems in the spec and developers. Look at it and say: I, don't understand this, so I can't write so I would encourage developers to start filing bugs, even if they might not really be bugs or just we haven't explained things well enough. Just go and file them, don't just sit there twiddling thumbs or be confused, don't be embarrassed. Just go file issues. We.

A

Also have a member of its means. That's well nobody's complained about the missing, or very few people have complained about the missing, so that might be a sometimes be an indication of things that need to be taken out and shots I.

D

Guess the developers here mean the browser developers because the application developers, when they see some interface or API not implemented they just skip through. They don't read the specs at that point, so there been several situations where we've looked at it and we said none of the browser's actually do anything here so move on nothing to look at it right.

D

So so we don't know if there are bugs really in the text, because we haven't really looked at some parts of it, but one of the things that came up and one of the things that seems to be like a big thing that we need to take care of a simulcast and and the fact that it cannot be taken out of the spec into its own means that there is work to be done here.

D

Apart from the testing and fixing the bugs and I, don't know if you've really put in significant time to think about some of that. Well,.

N

I think we we have in the extent that it's already the code is already in browsers, I. Think the problem is that I think there are some, as we've seen from just a few of the questions that Henri grace. There are some serious problems with the spec and I think we need to get into them more, because this is a case where the code is already there. So we're just talking about some Java scripts and clearly something's wrong with what we've got in this back. If they can't think.

A

Currently deployed call this, of course, that and what's it.

A

The browsers have all been hacked to do this in non-standard manners, because it was quicker than implementing what's in the spec, among other things, because the spec needs fixing. So where.

A

We have a pattern of non-standard behavior, also.

N

We have I mean to be blunt about it. It's not at all clear to me that there's stuff the rich stuff in the spec makes censor that people are going to implement it, but.

A

That would be a serious if that that the one isn't right, then we have a serious problem on our hands: yeah I'll.

N

Just note that nobody's implemented rid so far so just putting it out there.

A

As a single link, which is, has its.

D

Own problems and I think when we're talking about one, oh we're talking about Webber, DC PC becoming CR, our PR and I. Think stats go with it. Fortunately and I think there's a fair amount of work to be done there as well, especially for we've, put the simulcast discussion for stats as well delayed it just because we haven't seen much implemented and whatever we seen is poorly implemented. So so.

J

About red Firefox has a very early implementation of set parameters that accepts red, but does not, as I learned signal it in the RTP header extension, so we'll open a bug on that yeah.

N

I mean as another example the mid: nobody emits the mid header extension either or uses it to route packets.

D

So I think those are I from the discussion. I think simulcast seems to be like the big redheaded sitting so.

M

Clarify and chrome, with unified plan, we do implement mid header extension, sending Andy boxing.

N

Are you planning to support rid header, extensions and.

M

N

Nobody's noticing we.

A

Will certainly speaking with macro, madam, we will certainly try to figure out whether we're planning out to the letter or not real soon. Now, firstly, I think we should.

K

So back to my implementation timeline question, so we have an issue with speaking simulcast, but given all that set of issues at the spike level, I can only imagine it's ten times versus implementation level. So I mean we really. We can.

N

Well, I will say this: having looked at it in detail, the problem is: when you have this many open questions in front of a developer. They often wonder whether it's appropriate to ship, something until there's enough consensus to tell them what to do. They don't want to be in a situation of a ship, a bunch of stuff that ends up not being in other browsers.

N

So that that kind of thing does delay implementations eventually.

D

Against the other question is: should we put more effort into thinking of about removing simulcast into its own spec, because we can't be in a situation where we can't get it implemented? Nor can we get it out of the spec into its own spec? Well,.

N

It won't help to put it in its own spec. If we basically don't know what should be in that own spec I mean I. Think that's that's. Basically the problem all right, we're gonna have enough implementations at some point where you know people are going to come in with positions about what should be in or out and and I. Don't think we're far from that time, but I think the main thing is getting all the problems on the table. So we know even what we're debating, which I'm not sure we know yet I mean.

D

Like if he can pull out, everything from that say, simulcast out is needed for simulcast into its own spec by creating partials on those interfaces. Ordinarily, I.

J

Think we tried that right. We.

N

Tried that it just became even more confusing and it would probably delay implementation even further. So.

F

We tried that and we, the result was less readable. It was less readable, but that does not mean that we could not do it right. It's just that. It feels less right and at the end of the day, what we would like it for whether it's you one of us would be the full spec, maybe offering consistently, maybe in the short term, it's still fine to say: let's split it, it will be not great for some for one or two years and then we will remote it in two years. From now.

K

Some of you may know, the advisory board has started looking into evergreen standards. Mother inspired by Vivek, and my understanding that probably inspired by what is being proposed in terms of a collaboration with wiki on HTML document, is that you could mark some subset of a specification.

K

Non-Normative! Ethically, so that you could escape.

K

Implementation of a specific part of the spec that.

K

Consideration concern I guess. My high-level question is whether that is something worse at all police or diffraction I.

D

Think, overall, we are all looking for a way to like get one or to a point where, even since 100 and if simulcast is going to take more time and if you think that it's part of the one or activity it's part of the one or activity, but if it's part of the PC spec, then we want to like drive all our efforts in that direction.

D

But if it's not the case, then- and there are other things that we want to do- the SVC stuff in the eyes so I would. If we know that simulcast is going to take time, then I it's either. We said that this is not the focus at the moment. We can focus somewhere else, but saying that focus and not doing not aligning our efforts to reach the target seems I mean.

K

I think what you say find one way of thinking: I was easy: the relative priorities of single cast and.

N

Yeah I mean there's a whole bunch of applications that either will settle our dietary functionality and just ignore this back. If it doesn't get done so again, it would be a case of the working group, either finishing simulcast are abandoning it I, don't think, there's really any point in letting it sit in a separates back and not get finished, because it'll, just the whole market will go proprietary at that point. Ignore the working group.

D

Isn't that what's already happened in some sense, the dinner yeah.

N

But we're moving to unified plans, so we have an opportunity. If the working group can finish the suspect actually get a standard implemented, but if it doesn't, then you might as well. Just that mean that'll mean that essentially, the future of Weber to c1 will be all proprietor. Everything advanced to just be done outside the w3c and I.

J

Think that's a good point.

D

So I guess then I guess the question is what is the next step? Is an we've just in 15 minutes only come back to the same position. We were at the beginning of this. This card I just.

N

Think that we needed to have a push to get all the issues out because I don't think we know what they are yet so Dom.

F

You were saying that with the current spec, if we go evergreen now we would be able to do some things or is it like post Weber, post PR that we would.

K

Be able to do things I don't want to promise, because this is pushing some of the existing boundaries, but we could look into pushing the existing boundaries for one that you're. If again, we think that value again I don't want us to spin our wheels into process considerations. The process would be odd, but if we believe that this helps us clear, some of your plates and habituate is investigated with directors.

F

Yeah we tend to not so we should consider. We have a list of issues. We should try to say hey for developers. This is the top priority, so let's try to fix it first.

F

If, if it means simulcast is at the end, then it's at the end if it means on the contrary, but it's the first thing to do, then we should shoot for it. I. Don't have it's difficult for me to actually Church on on that, but we, if we have some information there, that might be very helpful to prioritize simulcast, but also all the words issues.

J

So so what what just to clarify? What does simulcast under percent done? Look like is it? Are we worried about? That's like what would be as long as we have tests that we need to be able to track when we're done. Yeah.

N

I think it means having tests, but it also means being very clear about everything that affects the behavior of a simulcast implementation. Yeah.

F

And then you need to implement. You need to have some prototypes at least two prototypes by probably be similar, I guess so well, we.

N

Have we have the prototypes or the we have shipping implementations? So it's more than just prototypes I mean the question is kind of shipping implementation to actually move to the back yeah.

F

That's what I mean we, hopefully by January or March, we will have a stable spec and then do we have enough throughput to say that these prototypes will be able to go up to the spec and then show that the spec is in top level. So.

J

Just for my own clarification to interoperability between browsers, are we covering that in our tests? Are we most occurring now API API? Well,.

N

Api, but with things like simulcast playground, you could actually test in an interrupt right.

N

Yes, we don't have okay, we don't have the implementations. We also don't have the test to test those implementations when we get them.

G

Don't sell election cosmo, we do have some tests for simulcasts they're, not updated, so they're checking a little bit of the current state and not the the spec, but we have in place all the system to actually spawn on SFU part of the test and test against and SFU and so on and so forth. I'm ready to spend as many resources as needed. To make that happen.

G

We got a lot of people that came to us and say they need simulcast to happen to the point where we actually implemented: support for h.264 simulcast and provided the patch to the browser vendors. So it is important for a lot of people and they're not going to drop it even if we put it out of the spec, so we're ready to push you and shoulder some of the testing effort. If you tell us exactly what what should be tested, we're gonna write the test for you and make the system available. I.

N

Guess one question I have is you know, I know it's it's a little bit concerning for developers. They don't want to ship something that might not be right, but is there a way to have like an extended run in canary or in Firefox nightly, and so that at least we can begin the test? The test writing process a little bit earlier.

N

Even a month or two would help so.

G

I'm sorry, burnin I didn't understand the question: are you asking if we can test on canary and based on that.

N

We I'm just wondering if, at some point we were told hey, this is close enough, so you can start writing the test for canary or nightly doesn't have doesn't have to be finished. It's just did not just need enough of an implementation so that we can start figuring out what we don't know. We have.

G

Had an implementation for four or five months already that we're testing against canary to help Google in the airport of 14, unified plan and transceiver. And we unify.

N

Plan a canary doesn't support simulcast. Does it well.

G

We had different kind of version, two its failing too right, but at least you see when it's turning from red to green and that's that's the definition of dawn, right and I. Think that's what Jake was asking for. Oh do I know when, when it's okay, so we brought the test first and and then again, so it's it's running today against Firefox and everything. So if, if that's not what you want, tell us what you want now.

J

That sounds good, but just to clarify son, like you mentioned that some of the tests right now test the status quo. So if they show us, the status quo is considered green, maybe switch to test, so that is red or yellow or something. So the green means expect.

G

The most difficult part was to set up the infrastructure. Stills WPT cannot do that directly to be able to ask any question and we reach that, and so the question we ask would be outdated for the goal you have today. But now the only thing you have to do is to ask the next question the rest of the system. Tests system can be reused so and that's pretty fast.

A

Okay, so testing seems to be a solvable problem based on an input here. As long as we have know what we know that the API is are clearly define for what for what we need to test. So wrapping up a level, it sounds like the chess will have to stick their heads together and think about what.

A

What's at the top of priority list and get around to whipping it similar getting simulcasts under control, as when I assess get us move that mountain, it's pretty important and getting restless back cannot write, cannot be ignored, I mean we need to reach back zero.

A

So with that I think it's time to wrap up the meeting and.

A

We just say we have: we are planning a simulcasts focused to virtually enter in in January. Some of us mil will meet in Bangkok in a few weeks. Some are still not, and the list is open and the organizer is recognizing and the editors will meet as usual.

A

So let's go forward and let's get get this show on the road. Thank you all for coming Thanks to everyone who subscribed and thanks to them for making a sound system that actually worked and we'll see you all see you soon. Ian.

K

The credit father-son system should go to the system, seems I'm. I was just a messenger, so.

B

Okay, I'm stopping recording.