Internet Engineering Task Force Interim Meetings, 15 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-AVTCORE-20221215-1600

Description

AVTCORE meeting session at IETF
2022/12/15 1600

https://datatracker.ietf.org/meeting//proceedings/

A

Good morning,.

B

Or whatever time it is for all ya,.

C

Should we get started.

B

Thank you, yeah I, think so yeah I think so do we have did we have anybody volunteer to take notes? Yet?

B

Oh that's winter.

C

And nobody volunteered on the list, so I guess we'll have to force somebody to do it.

D

D

Okay, well done. Thank you, okay! Thank you.

C

Volunteering for a note, taker.

C

Ronnie can he interest you.

C

We do need a note taker to proceed so.

B

You don't need all the blood level just you know.

D

C

Doesn't happen.

B

Well Ronnie said he's on his phone, so.

C

uh Harold, are you willing to take notes, foreign.

B

E

I'm sorry I have a hard time uh on some of my receive audio I. Couldn't tell whether Harold said yes or no, but I would take notes, but just a warning, my receive audio is a little choppy, so you may just have to repeat a few things.

C

Oh we'll take your offer mom sure. Thank you.

F

F

I can help uh when I'm not presenting and I'm actually planning on talking a lot during the uh um slot after mine as well so uh and I can help the wife.

C

Thank you yeah. You, please use the notes, the notes app and it can multitask so great.

C

We will be managing a queue. Probably everyone knows how to use it by now, and you do need to enable your audio to be heard.

C

You don't have to enable the video you can, if you like, please keep both of them off unless you're chairing or presenting and use of a handset or an echo canceling speakerphone is strongly recommended.

C

Jonathan, do you wanna over the nut? Well.

B

um Yeah, so basically, just as usual, you know, if you have any IPR, you have to, um um you, have to disclose it and we are under uh or you have to disclose it subject to the policies. It's you know the player for the details and we were under various um code of conduct. So please um behave appropriately. I think that's more cover on the next slide.

B

Indeed, yes, so we are under the code of conduct, so please behave professionally and uh you know we, you know, debate ideas, not people. um If you feel like um there, you don't have any problems. Please do the part of your chairs or the uh ombuds Team.

B

Okay, I've mentioned our note. Takers are uh yeah Center and no yes, indeed, okay. Thank you. Spencer, no.

C

um So here's the agenda for today uh we have more to go on the chair, slides covering the state of CFA stuff like that, um and then uh we have a presentation on green metadata, um some things relating to RTP over quick and then un is going to talk about codec, agnostic, payload format and then we'll have uh wrap-ups and next steps.

C

Is there any agenda? Bashes.

D

C

I want to do the draft status Jonathan.

B

Yep, okay, yeah we've had some things published. We have two things in auth 48, so that's very cool. Those have, um let's have a drive, they're are a few numbers are assigned, so those should be Republicans should be popping out quite soon.

B

um Skip is an ietf last call so we'll see what the comments on that are marketing mode. We do need a revised ID for that. So.

B

Please, um let's see I see up here to the slides at the very last minute. um Yes, 1783 best has Pub wrecked about an hour ago.

B

um So I'm sorry, if that taking so long, but that's finally done did you update the slides at the last minute.

C

B

Okay, cool, thank you, I thought I was gonna have to say this is uh um and uh then um let's see yeah so then hard to be a provocative adopted. Evc um is adopted, but we need to revise. We need an updated draft. Stefan says he juggling two calls so.

B

B

I'll ask him in the chat.

B

uh I, don't know if that actually needs any changes.

D

C

Now that DVC has done I think maybe they'll start from from the BBC draft and yeah.

B

I think the idea there was to basically do the same thing as VVC, so yeah. So that's um and then we need to have v3c. We publish as a working group document um I, don't know if any of the authors of that are here today.

C

Lori uh you're here, oh.

B

Larry's here, hello.

C

C

You have anything you'd like to say.

B

Foreign I see you unmuted, but I don't hear you so maybe I was having issues with your audio.

G

Yeah, maybe Larry has problem with audio Yeah.

D

We can hear you.

G

Now yeah this location, so we submitted the document with the proper name and the status is pending. The approval from chairs.

C

Oh okay, maybe we.

B

B

Okay and stone says that they'll rub EVC as soon as BBC is published, I guess they want to make sure they base it on the final RFC analysis, yes, yeah yeah, we'll.

C

Go fish the uh please receive email out of our inboxes yeah.

B

All right, I think I think.

B

I think uh um uh Laurie published the link to the things you need to click on. So let me put that.

A

B

Says, pending approved by the picture yourself, all right, I will I'll take off the fish that I'll post your style of game box.

C

Okay, yeah. Please note in the in a minute, there's an action item for the chairs to approve this. Thank you.

D

B

um So green metadata, um you got a call for adoption.

B

um There were some comments, people being in favor of it and one thing I can't so I think we have that on the agenda. So we can talk to that one we get to that.

F

uh Could the uh Bernard you you said that the chairs had a uh action to approve something but uh neither or nor I caught exactly what yeah so.

C

D

C

Yeah, it was on the uh the new draft for b3c approve it as a working group draft.

C

So it was adopted and.

H

F

C

Submitted it, but somehow the approval we didn't approve it so cool.

F

uh Will do thank you.

B

On the next slide,.

C

Okay, Magnus um isn't here yeah.

C

I guess young you're going to talk to these comments as well right.

I

I

Hello, can you hear me yes,.

B

We are yes, we hear you.

I

Yeah I have sliced to respond to all those comments. Later. Okay,.

B

C

Greetings so we should we can we skip some of this and then I guess cover it uh during your portion.

I

B

Yeah we'll get to that.

B

C

All right uh so I guess the uh I guess the question will be: uh have the comments been addressed and are we ready for adoption I? Guess that's what we're trying to answer in in Young's presentation: okay, go.

I

Ahead, Young all right, thank you. So this is a presentation for the rtcp messages for green metadata. Next slides, please. So this just quick summary. The message we proposed so the first is the request. Message include the frame rate picture with picture height and then the second message is the notification uh to response the framing rate, picture, width and height in the notification message uh next slides. Please.

I

Yeah, we received a number of comments during the CFA and the first comment is from Laurel from Nokia. He comments that it is needed to clarify how adapting the best stream of rtcp mechanism is used in collaborate with sdp updates. uh We think is this a good comment and we plan to add sdp definition subclass a similar, the one as in the RFC 510, to define the rtcp feedback attribute and the relevant parameters for the proposed message.

I

So the second command that we receive from Magnus is about the title. uh He feels the current title may not be clear, because the green metadata is about energy saving, but the the message propose. The message does not provide any energy uh information, so he suggested to to change it. So we we think about like two uh titles for the group to consider uh the first. We may change it to like rtcp messages for spatial and temporal resolutions.

I

The second candidate title could be codec resolution control message in RTP, audio visual profile with feedback so yeah. We think the the proposed message can be used beyond the green metadata, so we are open to to change the title but we'd like to to hear from the group which title may be more appropriate.

I

So I may stop here and see any um comments.

B

um I feel like it's probably best not to do too much of this um bashing on the on the on. You know in real time, go ahead. Stephanie.

B

Stefan I did not hear you possibly you're still having audio issues in the other direction.

D

B

Anyway, um obviously, I'm not sure doing the you know, you know the details of you know: fashion.

I

Oh yeah Stefan has the on the chat. You go something on the chat with the green method. They it's known now so.

J

B

Yeah I guess I mean I guess the question is, are you know I think? That's that's probably well known in the um from the um the uh itu session ISO Community, which, where that work is being done, I'm not sure how well it's known in the ITF Community, um so yeah I mean I. Think um I mean I feel like trying to do the details of bashing. The I think this would be better for the mailing list than the then live in the conference.

B

To figure out the details about the title should be so I'd say start a separate thread on that on the mailing list and we can discuss it.

I

hmm So should we change the title to or not.

B

uh I think the answer is, we should figure. We should discuss that on the mailing list. What the title should be, rather than trying to figure it out, live in the meeting yeah but yeah okay, especially because Magnus isn't here but yeah.

C

I mean yeah: please uh indicate that in the notes, uh Spencer and Mel yeah.

I

All right, so, let's, let's move on to next comment. So uh next comment is that uh currently the notification message just repeats the picture with height and frame rate and the comments that may be wasteful or maybe only send the ssrc and the secret number is enough. So in that case we can save 132 bits per FCI entry, but that's that's the only only one can disable because we still have to keep sending the ssrc and the sequence number um I checked the the current or the existing notification.

I

They just send all the the complete field so that the benefit to keep all three uh or other fields is to be consistent with the current design. But we are open if people think 32-bit saving is quite significant in this case.

B

Yeah I feel like it's my as an individual. My inclination would be to say better to be descriptive if it's not that expensive, and this also introduces the possibility of like you know, you could send unsoluted unsolicited tsdn if you're just doing something unilaterally, which I think happens for some of the other messages, but uh I'm not sure. If that's a good idea but open.

I

J

B

Say leave my mind should be seated. Leave that alone.

I

Okay thanks. uh The last question is just the the the question that in case the media center will change the resolution or frame rate or the spatial resolution due to the congestion Zen. It probably not. We need to send any notification.

I

Yeah, so that's Magnum case and I I just confirmed yes, that's true. If Center just changed the resolution by itself, it does not have to send any notification.

B

Yeah, this is analogous to how Timber works. Like you know, Timber is a Max bit rate, but this is that's. um There could be Clips, this is setting a maximum and it can go underneath it for be clear that you know that this is setting a cap and not necessarily you know, things can go underneath it. For other reasons, right.

D

I

All right uh next slice piece yeah, so so we asked for the the picture adoption. So that concludes my presentation. uh Thanks.

B

um Yeah I mean as I would say: yes, I think you know the the issues that were raised are all things can be done. You know addressed successfully during you know the uh I. You know the working group development of the draft and I think that this is probably fine to be adopted up with the possible. We should, you know, get um possibly get consensus on the title. Just because um uh that probably the uh that the documents.

B

Before we uh so before, we got to decide what the draft iatf ABT core documents going to be named. So let's have a little discussion of that on the list and then.

C

Options so the conclusion for the minutes is uh to debate the title on the list and then once the title is settled, to submit a working group draft with that with that title reflected in the name.

C

And overall the the draft is adopted, but.

K

C

To figure out the title and the name of the draft.

C

Okay, thank you. Thank you.

C

Okay, uh this is the next uh topic and uh to be clear, this is related to rtb over quick uh and it's uh a subject that came up both in some experiments, I've been doing and also came up on the muck list.

C

So on the mock list there was a posting from Christian. Wiedema who's also been implementing media over quick, and he discovered something which I think I've also seen, which is uh that it's possible, in some circumstances, for uh quick to run out of them to hit What's called the max streams limit, um and it depends depends on the use case and also if the application is doing, perhaps not cleaning up after itself correctly leaving streams open.

C

um So a little bit more about it.

C

So the question is: is this a potential issue with a quick or a web transport implementation? There do seem to be some use cases where a default, Max streams limit could be exceeded. We'll talk about that in a moment like conferencing, I have filed an issue on the web transport API because at least currently there's no way for a client to set a Max streams limit that might be higher than the default.

C

So there's a potential API issue there and but I've done a few experiments and if you're just sending a single RTP stream uh and you're cleaning up after yourself closing streams after they're they're used, then you probably won't hit this limit unless, for some reason your implementation has a very small um but uh I've encountered situations where, if, if you don't clean up after yourself, you can leak resources, leave streams open for some reason, um then you will hit it and there's all kinds of bad things that happen like the classical Legos uh goes very, very high.

C

So one question is whether there's any text needed in the RTP over quick specification, just warning about this I filed issue 49.

C

um So we'll we'll talk about a little bit more, whether it's something we actually need to address in a document or just um be aware of for implementers. So a little bit about the frame per stream model. You know I think we know how it works, which is in the send pipeline to Sender, opens the unit directional stream.

C

Perhaps if they want partial relatability they'll set a timer um and if the timer fires they reset the Stream, um otherwise they'll send uh they'll, write the RTP header in the payload to the unidirectional stream and then close the Stream um and then receive side.

C

Receiver is notified of an incoming uni-directional stream and they read from it until the stream is closed or it's reset, and sometimes the lane field is, is useful to know if it was completely received now, um so I did a little experiment um and uh with frame for stream transport, it turns out how this performs and whether you hit the limit depends a lot on what what I would call concurrency.

C

As you know, iframes are a lot larger than your average P frame, sometimes as much as 10 times the size, and what concurrency means is that on the quick stream you're sending the iframe at the same time as potentially multiple keyframes, um it's at least in JavaScript. You have to be aware of blocking if you're doing that, and in particular JavaScript awaits will block. So uh you have to get rid of that stuff. uh If you want to make sure that you can do concurrent sending of iframes and B frames. So it's a good sign.

C

If you see multiple P frames arrive on the receiver prior to the complete receipt of the iframe, because the iframe is so much bigger. That's kind of what you'd expect if you were doing concurrent.

J

C

So uh I've been going through um my example: implementation just trying to eliminate all the awaits, and after doing that, uh you do see a lot of real. You do see reordering about three to six events per experiment, mostly in the initial iframe and B frame um and a few other nice effects, because the iframe is closer to transmission line um still made.

C

You do a little bit of work on the read pipeline, but the point is: if you're, if you're, basically doing a good job on this, you will have concurrency, and that means you'll have a number of open streams open on a single RTP stream. Hopefully, uh so, uh let's talk about that a little bit more.

C

So here's an example of what you see after you've optimized it a bit. um This is a run with av1 at full HD resolution about 418 kilobits average bit rate 30 frames, a second uh gap size about 3 000 frames between keyframes. So almost all P frames, with maybe one p frame in an experiment uh with three temporal layers. So you can see the largest iframe here is about 12 590 octets. The P frame is much smaller, a little bit bigger than the average packet at 15 23.

C

um and with concurrency. The iframe is much closer to the transmission line. So essentially you have an FC win to send the iframe um uh in a single sea wit.

D

C

um So, uh overall, the question is this: is this a problem um and for a single rtb stream? The answer is almost certainly no um I haven't what in when I was doing. This I only saw a maximum of five concurrent open Quick streams um for a single ssrc. Assuming you don't have a lot of loss, I guess if you have loss, uh you might end up with more, but um I would note that I did see.

C

I did hit the max stream limit once, and that was because uh there were issues, closing streams and releasing all resources. So if you have leaks, then you could conceivably hit the limit, but uh if you're doing a good job, probably not um now, as I mentioned, if you have lost it, the limit could be higher um if you're doing priority.

C

Typically, what people will do is they'll say, send the iframe and don't do concurrency with the p frames and so you'll you'll end up with lower concurrent streams, uh but on the other hand, your glass delay will be higher, so that might not be the best idea.

C

um The one situation in which it seems like you could hit the max streams limit is in conferencing, for example, people commonly do seven by seven grits or 49 simultaneous video streams and there's continual demand for more I've heard of people asking for 11 by 11..

C

So in that kind of a circumstance you know, if you had say five uh quick, simultaneous quick streams and then 50. You know video streams, you could end up with 250 or 500 or something Max streams. uh Well,.

E

Yeah just a clarification question, maybe maybe my confusion.

E

um I thought the max streams limit was just the numeric number of stream IDs, the maximum stream ID numeric value that it can be not the number of actual concurrent uh open streams right now, so I didn't think there was any accounting that that closed streams would would somehow uh alter the max streams limit. I thought just the fixed limit that that number, a stream ID can't go above that number. This suggests that the the max streams is the number of active, open. Concurrent streams. Is that.

C

Right is that that's my understanding? Yes, so.

E

We have different understandings. Does anybody that knows quick, really well, authoritatively know what the right answer is: I'll double check if no one knows but I thought it was not anything to do with open streams. It was just the max stream number that could be.

C

Yeah you wouldn't want to just hit yeah 100 would be really really low for the maximum number of streams. You could ever open yeah that wouldn't that would make no sense I'll.

E

Take an action to check out the quick Authority on this because yeah a big turning point for our super frame start streaming.

C

What I didn't quite catch? You Jonathan, our stream number, is reusable.

C

You have to reopen the connection yeah.

E

They're not reusable yeah they're, not, but.

D

I, don't think there's.

E

An accounting of the number of closed streams to modify anything to modify Max streams or anything else. That's what I'll take an action to clarify.

C

But what I've seen MO is I've seen situations where I I didn't close a stream or didn't release resources and then I I hit I I ran into a wall where the delay went crazy.

E

I I I fully believe there's some internal implementation, accounting of magistration. You want some internal State and you have to search trees of active things, but not Source trees of closed things, but right I didn't think that affects the max streams limit.

C

Okay, um so anyway, uh there's also an interaction with priority in that uh priority can be used to limit the number of concurrent streams, um and, but you know, people talk about waiting for the iPhone to be finished before sending any P frames.

C

That's actually a little bit problematic because it reintroduces head of line blocking it's a little bit better is to allow kind of a finite number of P frames to be sent along with your iframe, uh but she probably shouldn't be infinite, um and uh you know in terms of what implementations do, at least in chromium and portions bandwidth equally between the open streams by default. That's another good reason not to leave streams open to close them, because otherwise, you'll kind of slow everybody down um and the issue of partial reliability is independent, a priority.

C

So if stuff is taking too long, you can always you can always uh send a reset stream. You can always call a board or something and get rid of it uh anyway. I think I think uh we have a good action item. Just is to look at this a little bit further. It strikes me it's not. uh It is probably something maybe worth a note in the RTP over quick spec um I. Don't know that it deserves any more than that, but um just something to be aware of.

C

F

Okay, uh I think this is I, think this I think this is me uh methods. Do you think this is me yeah.

K

F

I wanted to say too, okay, cool um uh and I'm just finishing up one sentence in the notes: real quick.

F

And now I'm not taking notes anymore, so I'll, let somebody else uh keep up uh click. The next slide. Please.

F

Or or um okay never mind um so uh we talked a little bit and very rapidly and at the end of the session, about um whether we actually had a an agreed scope for RTP over quick uh during our session in London and uh and uh York and I uh agreed that it was a good thing for us to work on that and we spent some time uh having a session working session.

F

uh While we were still in London- and we wanted to talk about where we think we are on scoping uh just level setting with the working group and uh making sure that the RTP over quick and the corresponding sdp specification uh are going to do what the working group thinks they is expecting them to do um so. Early discussions on RTP over quick started out small. This is going to be a drop-in replacement for RTP over UDP. uh That's an unrealistic idea for a variety of reasons that we talked about in previous sessions.

F

uh We want to do the right thing with RTP over quick, and uh the proposed goal is to do enough for it this to be useful, and the proposed non-goal is don't do everything that we can imagine uh so now. So for now, let's focus on uh what we know. We will need now and go don't do more than what we need know that we need now, but try not to break anything that we might need later I'm going to be asking.

F

Does that sound about right so far on each slide, and this is a slide, so uh I wanted to give people a chance to talk about that. If any. If anyone has something to say.

B

Yeah I think that's about right, I! Think it's of course. You know more specifically, I think that you know the um this is designed to be something comparatively simple, as opposed to mock, which is sort of doing the re-architect the world to uh you know for exactly what we want. So I think this is I'm.

F

Sorry, yeah, sorry and it looks like it looks like Sam- uh is going to correct at least me. Okay,.

H

F

Can you hear me okay,.

H

Yeah, fantastic uh yeah, some lspp r d, uh not sure if this is going to be a correction, more understanding um I might be uh preempting what you're about to say on a later slide. But what exactly? Do you mean by enough for RTP over quick to be useful.

F

um There is, there is actually a uh hive mind, group, think uh uh statement. uh So, basically, if uh people in the working group jump up and down and say you didn't do too much or did you didn't do enough or you did or you did too much uh we'd like to know that before you know going in rather than coming out, uh so the the basically this presentation is intended to be uh a significant chunk of that discussion, uh although uh not all of it and we'll talk about that uh during during the presentation.

F

Does that make sense.

H

uh Yeah yeah it does uh my only input on on that would be I. Think the enough for it to be useful is to Define some way of carrying RTP frames over quick, uh and then you can scope that on multicast is problematic. uh Maybe don't do that just yet.

F

Yeah yeah yeah uh dude, you're re you're, reading the issues and GitHub good job.

F

um If we, if we flip to the next slide uh that this may also be helpful,.

F

I'm waiting for the next slide to pop up. uh So uh in the 1980s there was a discussion on the history and history of programming. Languages about some languages were like I order, a pizza with the toppings that I want uh things like APL and Pascal that were designed by one person for one person's use and then adopted uh that sometimes we say we we will order a pizza with the toppings we want. This was the COBOL committee and people like that.

F

uh Where you get everybody in a room and say it's got to do at least this, and so some people order a pizza with all the toppings that anybody could ever want, and that was what the uh share committee on pl1 did on. Npl and po1 did so fast forwarding to the 2020s discussion on RTP over quick. uh My goal is that we order a quick, RTP pizza with only the toppings that we need next slide.

F

Please and I apologize for anybody, who's suddenly hungry in the middle of uh lunch, um so the planned usage was uh Bernard. Are you? Are you in queue.

C

I'll be in q, but just finish your slide look.

F

You want me to finish: you're finished, okay, so I'm finishing this slide, yeah go ahead, Okay cool, so the planned usages that we know about, and we probably started out uh with the uh sip VoIP environments that are currently using RTP and that kind of led us into the land of uh a drop in replacement for RTP over UDP um we've been talking about um webrtc environments that are currently using RTP and but we've also been talking about web transport environments carrying real-time media.

F

There's medicine has more about details about this on in the next section. So let's defer discussion about whether that's a bad idea or a good idea for now to um to measure this uh deck slot and uh yeah, but uh I think I want to I wanted to make sure that I. We were not missing, planned usages that somebody knew about now.

F

So like I say it's not it's not to say that these are the right usages, I'm, just trying to make sure that we've got all the ones that we that people are thinking of. uh Bernard I would.

C

Start with yeah um I'd be interested if if there are folks who've dealt with pbxs or handsets, but I haven't really seen any interest in this from that Community like if you're thinking that um rtb ever quick would be used in a SIP trunk to a carrier. I I haven't really seen interest in that or in a handset or in a PBX. So I I do think that's curious um with revitc.

C

You know there is some history appear to peer quick that went through An Origin trial, but um there's no official w3c activity so that one also seems kind of curious. So the first two I'm not sure where people got the idea that there was interest there but I'm not seeing it at least.

F

Excellent, so, are you pointing us uh towards web transport as the planned usage.

C

Well, I will say that web transport is a plan usage I'll. Let others comment on whether it's default.

F

Yeah yeah you're right right, right, right, I, would say. I was saying on this slide so far, um and this this is definitely something that would be whoever is taking notes.

F

It would be awesome to uh capture this as an action for the mailing list discussion, uh but just basically, especially especially the webrtc one, uh but just we're just asking that I'm seeing people in like 3gppsa4 uh who are wanting to do uh webrtc for media and uh in the you know in the same uh the same technical specification committee they are, uh they are uh doing other things with quick. So uh there's not that much of a leap for them. You know for me to imagine them being interested.

C

Yeah I guess there. There is a little bit of a difference. uh Spencer you have to be clear, there's webrtc and then there's the web right right and those could be different, like they could be doing webrtc stuff with a webrtc API, and then they could be doing something else with the web which, like web transport or something so.

D

C

To be clear um anyway, Peter Peter probably has more comments on that hi Peter.

F

I'm not quite hearing you yet are you hearing.

D

B

I am not hearing Peter.

C

Peter come back.

D

B

A lot of people hear me.

C

Yeah yeah, okay,.

B

Oh yeah I was going to comment um I feel, like you know, the one thing about support environments. There was and forget all the details, but several ideas back now we hear you Peter, but.

L

B

Okay, uh that there was I know there was a thing that um uh Jonathan Rosenberg uh brought to dispatch several idfs back. Talking about. You know the idea of having a sip architecture that integrated better into the web.

F

um Right right.

B

Model which I think that was you know there was some interest in having and that would I think presumably use something like r2p over quick as it's media plane, uh potentially so I think that might be I mean I, don't think! That's not anybody who's actively working on it, but there's some interest in it eventually too right, wow.

C

Yeah, you have to be clear though, but wasn't he proposing RTP over http.

F

D

I thought that.

F

It was I thought it was something really close to that.

B

Yeah I mean I think, but that sort of pre-dated web transfer being good. So it's possible.

F

Right I mean yes, that's the other thing it was. It was really early and we spent a lot of time talking about uh how much of the web infrastructure was HTTP. 1.1.

F

So so I think that that's that's something to look back on uh if somebody wanted to uh add a um if somebody wanted to add an action item for me to chase that, that would be. That would be lovely.

F

So got uh Jonathan have I, have I done you yeah, yes,.

B

F

Cool Peter, so uh Peter.

L

All right, you hear me now: yeah.

F

L

Okay, so uh first I think Bernard's right that you should probably just speak in terms of web environments um right now, someone might use webrtc, but then maybe one or integrate rtpa for quick and that, as far as I know, could not be done with webrtc unless uh extensions to it were made. But the only extensions I know of are kind of a bring your own transport, and in that case it would be a web transport.

L

So you might have a situation where webrtc is emitting, something that looks like packets and then whoever web transport actually carries them. But, inter in terms of this slide in planned usage is I think you should just speak in terms of web clients, but web transport would have to be a part of that. I think the other comment I have is that um I think you're missing um use case here, which is just say, mobile applications that do uh real-time communication using RTP and they might want to use quick instead.

L

Is that what the first bullet point is, when you say, VoIP environments.

C

um I wouldn't characterize environment, Peter.

L

Yeah there are tons of mobile apps that do RTC that would probably enjoy using RTP real quick. So that seems.

F

L

Weren't, its own bullet points.

F

Excellent and uh can can uh we and we've we've added that as in the minutes of something for us to chase right, it looks yes, it looks like someone is hopefully typing still in the minutes cool.

F

Thank you. Peter uh Stefan.

F

I am not quite hearing Stefan.

C

Stefan, can you say something or are you saying something.

F

You may have just cut on uh well I'm, not sure you just popped up and anyway uh Stefan. We are not hearing you yet.

F

F

um Stefan is is uh planning uh violence on his computer uh in in uh in zulup and uh Stefan um I am going to be looking at the uh at the uh at the chat for this. If, if it's helpful for you to uh put a comment in there, uh I will I will definitely see that as well.

B

So Stefan did say something in the chat said plus one to Peter's point. Also, the slide is overly standard. Centric defined applications, not the call control, Etc standards.

F

Cool excellent uh and thank you and thank you for your help with that. um Thank you so far. Anybody else.

F

B

I still want to drop into a place for RTP over you if you got standardized 12 controls, as this is a large segment to the industry you're using so.

F

B

uh Stefan said further, I still want a drop in replacement for RTP every Unity without standardized call controls, as this is what large segments of the industry are using.

F

Okay, excellent cool.

F

uh Yeah um Zoom, um so for topologies, uh we know that we can't support all the 7667 topologies, because um section 3.3 of that specification does uh point to point point to multi-point using multicast uh and quick doesn't have multicast yet um so we know we want to support some uh of those apologies, but we haven't discussed at which the polities in detail, yet uh the dash zero one version of the uh RTP over quick specification describes uh supported RTP Technologies in general terms, and the proposal was to uh analyze the rest of the unicast, the rest of the unicast apologies and I added issue.

F

47 for this in uh in GitHub. Is this about right?.

F

And Stefan you may still be in you may still be in in queue from the last one or us last letter for the or for this one.

D

F

Okay, so Stephen is out of here: is anybody getting in queue.

F

F

D

F

Morning, slash afternoon slash evening.

J

Okay, so good morning, oh good afternoon, oh good morning, the rest of the morning, uh we should be very careful with the apologies, because there are a lot of apologies there, which would unnecessarily limit stuff like, for instance, like we, because we're going to end up with SFU of a link or TP and all the other wonderful things which, if we yeah and seriously limit the functionality and implementation options which we have right.

F

J

For that fake, let's stay away from multicast, because this was.

F

Okay uh fold, this full disclosure, uh I added uh issue, 52 about multicast and I'm, not presenting it now, and uh we will ignore that that possible. We will ignore that possibility for the foreseeable future. Yes,.

J

Because uh it uh seriously messed up RTP and can seriously limit what we can do with uh like our RTC over quick um one thing which um kept coming up in topology with RTP as an issue is that and even if it's a peer-to-peer topology because of the different negotiation glare, you have multiple uh streams going or basically multiple RTP streams going over the same pre-negotiated channel.

F

J

There was in traditional uh RTP, it's not always easy to uh the max them like, especially like, for instance, if you have a dtls uh srtp right.

D

J

End up, for instance, with two with two dtls sessions going over the same five Tuple and that.

G

J

A problem and some of the quick parameters characteristics make it easier because you can just start new stream and the multiplex by that, but we might have some uh like it's. It's probably gonna go into the uh sdp negotiation like we need to make sure that uh if we negotiated this over sdp that we take uh have a way of the marketing multiple streams in the in the process of uh renegotiation and I, don't think it's actually covered in the topology section right now. So that might be something to be.

F

J

So that's all my comments.

F

Cool um any anybody else and queue on topologies.

B

um Sorry that didn't give us a few, but I think um you know mention them all I suspect some of them will be mentioned. For you know, we don't think this is important for this use case, but you know at least being able to make that decision explicitly is probably a good idea.

F

Yeah and um so.

F

Obviously, you know obviously and I I. uh Well, okay, it's obvious to me. It may not be obvious to everybody, because I could be wrong, uh but it's obvious to me that um we may end up with a certain amount of text on this and that certain amount of text on this may be longer than what's in the uh in the current draft, and uh that could be that could appear that that text could appear in the draft. It could appear in its own draft.

F

It could appear in uh which one or which might uh update uh 67th uh sorry 76 67, or it could uh end up in its own draft. That stands alone. uh If it turns out to be different enough from the things that have been done with uh with uh with uh RTP in the past, so uh I think the I think the right answer now is to uh write down the text and then figure out what to do with it.

F

If that, if that sounds, if that sounds fair, and uh is that, does that sound, fair, Jonathan.

B

Yeah I think that that's interestable, you know, got about something written down that we can argue about. Then laughs.

F

Excellent, um so I think that may take us through the next slide. uh Relevant, quick extensions. uh So datagrams is a quick extension that has been part of the RTP over quick plan, basically forever and dash zero. One of the RTP over quick specification assumes that the use of datagrams um and uh please we have had conversations but not a lot of conversations about the possibility of using quick timestamps, which is currently a individual draft, uh targeting the quick working group to allow better loss, detection and congestion control in some in some situations.

F

So those those are the two extensions that I think that I think the uh avt core Community has spent the most time talking about at least at least where I could hear them. uh Bernard I see you in queue.

C

Yeah, so in the web trans working group we had a conversation about quick timestamps, specifically the w3c uh came and said: hey.

C

um Can we make this mandatory for web transport for for the reasons that were discussed in ABT core? The general response? Was you know that many quick implementations don't support time stamps so um that that wasn't recommended as an approach? I don't know if this working group will feel differently that quick timestamps is so important that there has to be there, uh but in general at least at the moment, it's not widely implemented by any means.

F

Yeah well I mean uh I, know, I, know that uh people Implement individual drafts, but I mean this hasn't been adopted by the working group. Yet so uh people who have no, who have not implemented it yet have a pretty uh plausible uh excuse for not having done so, but yeah I I, like I, say- and this is uh I'm asking these questions now before we do a whole lot of work with quick, timestamps and then say: oh never, mind yeah.

C

I guess I guess the question would be. Do people feel it's that important that they you know that it should have a normative language or not.

F

But yeah and and uh I agree and uh I'm, not I'm, not trying to be the ABC Corporal Whisperer, but I I suspect that uh VZ core would feel better about pursuing this. uh If it is moving forward and the quick working group Peter um hi hi.

L

I'm interested uh to see quick, quick timestamps uh happen so that congestion control algorithms that need them can use them. um Is there any summary of a status of how well this particular draft is going.

F

uh Spencer's recollection, without clicking on the data tracker, is it's been through something like uh nine revisions? If I'm, if I'm remembering the right draft uh but uh I, don't you know, I I have not seen a call for adoption.

F

um Does anyone does anyone? Is anyone smarter about this than me and I? See I, see uh York uh popped up in the queue as I was asking a question. I don't know if uh York was asking was had a thought about that or not.

F

Oh okay, I am seeing uh in uh I am seeing a zulup, uh York saying limited response at this point uh and that's like I, say I think I think it's just too early in the uh in the discussions about uh quick time spans uh in detail for uh for a lot of people to have really focused on that.

F

So this this, this could be a at a, we will add a issue and that the pro the appropriate time we would uh see if we can move it forward.

F

Does that sound about right.

A

F

We just accidentally heard you please.

A

A

And but there's also an echo, somebody needs to mute.

A

I'm, okay, still echo.

F

I will mute until you quit talking. Okay,.

A

Doesn't help anyway, um so yeah Christian was wondering whether he should be putting more Cycles into this um specification.

A

And it this is really weird with the echo. Let me just move, not muted me, but oh, that doesn't work. Okay,.

A

So Christian was wondering what how much support or how much interest there would be into solving this timestamp problem. There was limited response inside the quick working group, and so no it is no enthusiasm that would make it um that he would put effort into taking this further right away.

A

um Can probably be convinced otherwise, but what we heard so far here also pointed in the direction that not many people would be implementing this.

F

A

F

And, like I said that all makes perfect sense uh could I ask the chairs if it's okay, if we have an action for working group participants who are interested in uh the possibility of using quick timestamps for RTP over quick to focus on that and provide some feedback.

C

No, that that sounds good uh um yeah uh you mean provide feedback to the quick working group or on the list.

F

Or uh you you guys tell you guys, tell me I mean it. It could be that it could be that it's helpful for us to discuss it uh like whether whether it would be useful and uh if, if we can't convince ourselves that it would be useful having some people spend Christian up before we decide not we don't care, it doesn't seem hope, doesn't seem friendly.

B

I mean I feel like it depends somewhat on what exactly the uh congestion control coupling model is. Where you know, if we're expecting to get. You know tight contest control coupling with the quick stack, then. Yes, if it's loose coupling- and you know you have to do your own- you know higher level congestion for low low latency at user level, which is not entirely clear to me yet either so.

C

Well, well, even if you do, though, Jonathan it's still sometimes useful to know the one-way delay as opposed to rtt, which you can measure in your app. So true.

D

Even if you're doing your.

C

Own it, you know it's something that I've you know in doing my own experiments I would love to be able to get particularly in very asymmetric links like cable. You know, cable, internet right, it's it's very asymmetric, so.

F

Yeah yeah, you and, and so I think the if I'm, if I'm, quoting the draft correctly, you know the issues are either it is uh asymmetric or at that uh the uh congestion on the ACT path is uh significantly higher. uh But but, like I said, don't quote me on that. That's what I'm remembering, but you know like I, say for us for us to just get more experience with what we're doing without time, stamps and then figure out how badly we need. It would be one strategy going forward.

F

um Mo did you uh did, were you in topic, go on topic for this.

E

Yes, I just wanted to agree with uh Peter that I'm also interested in this, uh for congestion, control improvements and, and also for the same reasons that Bernard is interested in one way, delay that often feeds back into both congestion control and some other decisions at the application. Level. So I would.

A

E

See this uh progress for for the notes, uh I wasn't clear what the action was. Is it an action for the chairs to ask something on the ABT core list soliciting feedback, or is it an action for for the authors for for Spencer to uh to solicit something uh on the list.

F

Foreign chairs, could you could you uh Express a thought.

C

Well, I had the same question as Mo.

F

C

Mean whatever you think would be useful or willing to do, but.

F

Yeah, so uh my definition of useful is to talk about this. You know for people who care who think they will care about this to talk about it on the ABT core list, first and so I think I think my only question was: do I send that email or do you guys well how.

C

About, if you send it Spencer uh action for.

F

F

Perfect, um and uh and thank you and thank you for thank you for asking for that clarification, hi Harold. How was your day.

M

It's a beautiful day and uh or night at the moment, but they all said. We wanted to add a thought about quick timestamps that uh timestamps aren't strictly needed for congestion control, but they're awfully useful for figuring out what what to send next.

M

Yes, so if it, if we get around to detangling this question of of protect the internet against those evil bits, and what do we send next now that we know what we can send right, I think yeah, we're going to find that timestamps are extremely useful and defining the timestamps is sometimes a hard job. First packet last packet, assemble packets,.

F

Yeah right yeah.

M

F

Right I think I think that I think that uh I think it makes perfect sense to me that people who have been doing H3 may not care because you know because they're they know what they're going to send next roughly, uh since this is reliable.

F

But uh it's maybe more of an interesting question for us than it is uh people who've been doing age three actually.

M

People who people who, who are still the people who invented the six parallel uh HTTP gets for uh for uh the first browsers, are probably still interested in what they can do and do in parallel and yeah next sure.

F

Yeah cool um that gets us to Jonathan.

B

Yeah so I mean I. Think part of the question here also is: what do we expect? How much information do we expect the RTP player is getting from the quick stack and if we will talk about useful, quick timestamps are I. Think presume that the you know, whatever the application that's sending RTP actually gets to know them, which.

D

B

Think has implications for what information is getting passed and forward what what you know affect API. Do we assume there so I think that's also something that we're going to need to think about to some extent, and that's also probably has implications also for the web transport discussions, because that's actually a explicit API being defined.

F

Yeah, exactly okay, cool um I, think that cleared the queue uh MBT profiles uh and I apologize for my rant about this in London, but I don't rent very often, we've had a we've had proposals that have ranged for uh from avt PDF to whether you're, adding uh where you're, whether you're going to be doing secure, RTP, uh whether you're going to be using the uh the.

F

Extended rtpc rtcp feedback uh and things like that, and so we've had some proposals for uh full protocol definition and actually I just I'm leaving no, um but basically basically.

F

Filling out the uh definitions for, uh for you know as full Pro uh definitions that we would put in a specification and um that that included uh the point Roman made a bit back a while back about.

F

If you are doing ice and you get all your ice candidates come back as TCP candidates, um whether you want to proceed with that or uh try and do something else, because if you can't do ice for you for UDP for quick to use, you probably can't do eyes for UDP for RTP to use um and then steam streams, datagrams or both as attributes to limit the combinatorialness of the of the registration and like I, said this is I I'm not typing this now, but uh but that's I, think that's what I'm.

I

F

Think that's where I'm headed towards uh the next time I do a revision of the uh STP specification. uh Jonathan.

B

um Yeah, so my only comment on the SCP at spdf on you know, you say it's for ease of relaying and forwarding to udprtp, but the problem is that once you talk about asset that layer, you talk about what that layer is keying looks like and I, don't think we're going to be able to Gateway btls srtp to Quick, unless you want a tunnel dtls over quick, which sounds terrible um and so and I.

B

Don't think you want to use security descriptions because that's generally terrible, so I feel like I would um say the the problem with the asses. Is you need to find what the keying looks like, which might mean exporting from quick but I'm, not sure how useful that is, if you're, relaying and forwarding so I would say. Maybe don't.

F

So so let me let me try another thing uh like I said, these are things that we have talked about um in in the in the in discussions in the past, but not in a huge amount of detail. One thing we said for relay and forwarding is: uh it would be easier for us to write a BCP saying if you're doing uh RTP over quick and on one side and RTP over UDP.

F

On the other side, uh you need to do uh secure RTP over UDP on the on the other side, and rather than rather than saying, uh oh we're going to do double encryption so that what the middle box gets is something that it can forward um using srtp on the other side.

F

So, like I, said.

B

King, so I'm letting.

F

B

Find that you don't yeah.

F

Yeah, so so I'm not I'm, not telling you that we know how to do this. I like to say I'm,.

B

Asking I mean I'd, say: I mean my suggestion would be how.

B

To help us figure out how to do Kia.

F

uh And that would be. That would also be a fine uh uh way to get off the way to get get through this. Yes, uh Rob. uh Thank you for that Roman. uh What's up.

J

So the I'm just again was thinking about sap I'm, not sure this is again like in the grand scheme of things uh relating dtls over quick. Is that horrible?

J

It's not ideal, but it's we're talking about like three or four extra packets during the session setup so and uh people who make it very easier to build essentially gateways which will run in front of the existing details, srtp infrastructure and Gateway to a 30p or essentially 30p. Over quick with bypass of again, it's going to be double encrypted, we're going to end up with uh more overhead, and we want a slightly more overhead, but it will work and it will work very quickly for any sort of like prototyping or um buildups.

F

Yeah right right, I, I, think. Another thing that we're talking about here is uh conversations that will be good for us to have after we've looked more closely at topologies.

F

um Yeah so so yeah.

B

Yeah I mean sorry um just to say to respond to Roman I feel like yes, there probably are use cases for what you're essentially doing is tunneling a dtls srtp over quick but I. Think that's mask and I. Think for the right answer. There is, you know, use a mask. You know UDP forwarding session they're talking. People are already talking about using masks.

B

um And I don't feel like that's a use case. We need to just discuss here.

F

Certainly without certainly, we don't need to discuss it without talking to the nice people in mask yeah.

D

F

Makes makes perfect.

D

F

Okay, cool anything else on this slide.

J

F

Excellent uh quick adjust your control, uh so so we we've had again a range of thoughts about uh what to do, how much to say about quick congestion control and uh what I'm talking about here is I think the least visible uh approach to Quick adjustment control, which is to Define an alpn. That's not H3, uh currently in zero one, it's RTP, Muk, quick, uh that that would avoid the most awkward aspects of nested, RTP and uh H3 controls.

F

uh So basically, if you're not talking to an H3 endpoint, if you are not an H3 endpoint talking to another HD H3 endpoint, uh there are a lot of things that become um clearer quickly.

F

um So again, with this proposal, that's relying on the endpoints that are doing say: RTP looks quick uh to do something appropriate, whatever that is, and the zero one version of the draft references scream and data as examples um Bernard I, perhaps.

C

D

C

uh um The aopm issue really is distinct from congestion control, um so I don't know that I would mix those two things, but I think the alpn proposal you have is fine, uh but it's it's really not doesn't relate to congestion control. That's a separate, separate thing.

F

um I think so I'm allow me to misquote Lucas, um but I believe that I believe the discussions about this. Probably in the quick working group, because it's been a while um he was, he was saying that that was the easiest way to make sure that the person you were talking to knew you were not doing uh http 3..

F

C

Well, yeah, it distinguishes the use, the use, that's fine, but that doesn't necessarily but the congestion control algorithm is an orthogonal thing. So.

F

You know it's an example: I I would agree with that. I would agree with that very much.

C

Yeah so I'm, going to take an example in web transfer. They've been talking about adding to the Constructor uh some hint about the congestion control you want, but uh that doesn't affect the alpn at all. It just affects what what congestion control is implemented anyway, just.

D

To say, they're, orthogonal.

C

F

C

F

And and I I think that uh I think that you're thinking that they're, more orthogonal than I was uh so uh and the reason we're having these discussions is to give me something to think about, um but um the the the other thing was um we we've.

F

You know these proposals have extended all the way into saying: I want to tell you what the uh congestion control is going to be, and um you know to Define certain aspects of the congestion control and, uh and uh that was what we were trying to talk ourselves out of. If there's a Constructor that says, do something for that's reasonable for for real-time media, uh that that would be fine with me too.

F

You know rather than saying oh well, you know it's got to be you.

J

F

To be this kind of bandwidth, probing and stuff, like that, does that make sense.

F

F

Okay, uh Peter.

L

I agree with Bernard that um it would be sad if there were implementations. That said, if aopn is RTP, mux quick use, real-time congestion control, algorithm else views not real time. I think it'd be much better. If we just had to fit something, I would like congestion controlling to them, and then we didn't have some case statement in implementations based on aopm.

F

Cool. Thank you for that. uh Vinnie.

D

I I just want to say that.

A

uh I agree with you.

J

K

It doesn't mean that is.

F

uh Really I am I'm getting a uh certain amount of breakup on your audio.

F

You want to try again or put it in put it in the zulup.

F

Yeah, that sounds better foreign.

F

Let me I I can mute me.

J

G

Was just uh say that yeah.

B

And these examples.

F

Fit for the chairs and from oh, are you, are you getting that.

B

um It was sort of hard to hear, but I think she was agreeing that we shouldn't have the congestion control tied to the um alpn. But.

F

You know cool, okay, excellent, yeah, and- and thank you thank you for that. uh Is there anything else we may move on to the next slide?

F

If we finish all of those uh then uh doing them, then I've got uh I've, got issues as of last night for doing the mapping between quick feedback and what we might want to get out of extended RTC rtcp feedback and working out the details of quick connection interconnection. uh You know, sorry, quick connection, interaction with ice, um and so so those are uh new uh new.

D

F

In the get in the GitHub and uh I saw, Bernard has put in a couple, and uh so people were also visibly typing so, uh but that that's the way it looked to me and um I wanted to thank people a lot for this session. uh I know it was very helpful for me and uh I hope it was for uh York and Mattis as well.

F

And with that um I well, I think I have one more slide saying. Thank you for sharing your thoughts and see you in Yokohama. um Next.

B

uh Just uh that looks like committee said something in the chat, so the examples of data stream shouldn't be taking any options.

B

Congestion control, algorithms for I think those are just the ones that we actually have published documents on. So we can cite us.

F

Yeah exactly exactly yeah.

B

Yeah yeah, it could also like I, think there's like the expired draft and on GCC, also which we could potentially cite because I think that's the one that right you know, subject to Evolution, that's the one that the browsers are actually using for webrtc but yeah. To cite all of those is probably.

F

Thank you over to you, Mavis.

K

Yeah thanks um I only have one topic to talk about today. uh Next slide, please.

K

uh Multiplexing we wanted to talk about this in London already, but we didn't have enough time to discuss it really, and we already talked about this in the last injury meeting two I think, but in that meeting I didn't include web transport, so I thought it may be useful to discuss this again today.

J

um In the past discussions.

K

We have um talked about multiplexing uh kind of related to aopn um because when we Define an ilpn, we probably or maybe also have to define the multiplexing or also the other way around. If we Define some multiplexing, we may also already have a decision on my LPN um and we also discussed about how much needs to be defined in this document um and yeah. That kind of um extends the scoping discussion from earlier.

K

um The main question we try to answer is how to Multiplex RDP over quick with non-rtp streams and datagrams, where non-rtp streams and datagrams means like rtps streams and datagrams that carry another protocol that is not RTP or rtcp.

K

uh The current graph defines a flow ID or session identifier to do this, but we are not sure how compatible this will be with other formats um and then, depending on what multiplexing we use. This might have implications on RDP over quick, because we also want to try lightweight and independent as much as possible, but of course, we also want to build something. That's usable by most of us for all of us next slide.

K

K

So to discuss multiplexing um to get everyone on the same page first, um the easiest thing we could do is to say we just put RDP packets for one RTP session and one quick connection, and if you want to do multiple r2p sessions open another quick connection that is kind of easy and it's similar to what we could do over UDP, where we could put different RTP sessions using different UDP ports and do the multiplexing on those parts. And then we would similar to that use.

K

Quick connection IDs instead, but that's also, um maybe not the best thing we can do, because maybe we can use one quick connection for multiple sessions and maybe also even further things. So the next point is to um how can we do multiplexing with multiple RTP.

D

Sessions in one.

K

Quick connections, accurate connection and these RTP packets can be encapsulated in streams or datagrams or both, and because we are using the stream per frame model that Bernard talked about earlier. We can't use the quick stream IDE to do multiplexing, because one RTP session was streamed with a lot of different streams and also the datagrams don't have any stream ID um is there.

K

So for that we would use some sort of a session identifier and, as I said earlier, this is the one we currently have in the graft.

K

That would also help us to do our gcp packets in the same quick connection, um and these rtcp packets could then be multiplexed with part of the versions of different RTP sessions and then the last point. If we want to do multiplexing with other protocols, what we would do over UDP is, for example, using RC 7983 this to Multiplex these different protocols.

K

That would probably be possible inside quick 2, but not necessarily the best thing to do, because maybe we don't even want all these protocols and Jonathan is in the queue.

B

um Yeah so I think um one of the use cases that a lot of people I think when we're looking at doing you know various media over quick type Solutions are interested in is the use case where your uh call control and your media are sharing the same quick connection, and the use case here is for like when you're going to a load balancer, you know and you've got something that spreads out to a lot of back-end systems, and it makes the problem of making sure that your secure um call, control and your media go to the same box on the back end much easier.

B

If it actually goes, it's a quick connection, so um I feel like looking at Multiplex, make finding something where we can Multiplex. Actually, our call control, whether that's something proprietary or ship, or you know, whatever with the media. It's probably something we should look at as an important use case, because I think that's been something. A lot of people have been interested in looking at.

B

So maybe it's if it's too hard, maybe we should say no but I- think that's certainly a use case people but interested in. We should think about how we want to if that's possible,.

K

Yeah I think I would consider this part of the last point where we Multiplex RDP sessions rtcp with other protocols and we're not sure which protocol that is, and it's not necessarily one of those that are listed below here.

K

And that is also what we want to talk about on the next slides yeah.

B

Oh I, just I just have her set a comments. Chat is that so, when you want to set up the mic, I think it's an interesting point.

H

Yeah I certainly can do uh it so H3 for uni-directional streams uh has a stream type. I was wondering if there was maybe more of a a general applicability to multiplexing. So so you could start a stream as just RTP over quick in the alpn, but then there's a transport extension that says I support some other frame type that allows you to negotiate uh adding a stream type in the from when you open a new stream, so you can identify which protocol this is actually for. I, don't know if that would be potentially more helpful.

K

uh Maybe I think it may become helpful if we go to the next slide. um We have a couple of options which we will would like to talk about. um One of them is web transport. The second is some part of web transport, and the last one is something I talked about in the last interview meeting and I think when I go through these different options, we will also talk about how to bring in other protocols like that, and um maybe that would already be helpful uh is that okay, other.

L

L

Say that if we want to make a generic uh multiplexing system, I mean that is what web transport is, so it'd be kind of Reinventing it so I'm glad to see. That's the first bullet point on your slide here.

K

Okay, so the three options options we have is web transport, which was brought up in the last meeting or actually was brought up as some um more generic multiplexing layer which we could introduce between the quick connection and RTP and um web transport could be one instance of this.

K

um The second option is to use partial web transport, which would be kind of more generic, using our own abstraction layer in between to do multiplexing, but maybe reuse, parts of web transport. For that and the last option, I will talk about it later on a dedicated slide for only doing RTP and rtcp first, but try to be um extensible in the future for other protocols.

K

So, let's start with uh web transport on the next slide down, so web transport defines a couple of Transport features, properties and requirements.

K

um These trans features and properties and requirements can be implemented by different instances of Transport protocols below and that are currently defined for HTTP 2 and https 3.. The features would be very much what we would like to use for RTP over quick. We would have different sessions which could be mapped to RTP sessions or multiple RTP sessions.

K

In one quick connection or even multiple web transport sessions to have one for RTP and one for something else, um membrok transport defines datagrams and uni and bidirectional streams, which is exactly what we're using in quick for RDP over quick and the transport properties um include some nodes about different transport protocols. Implementing these features uh because um for HTTP 2 we don't have, for example, unreliable datagrams, so the transport properties are, or some of them are optional.

K

For example, unreliable data delivery, aborting screens may result in re-transmissions, which would be the case for HTTP 2, which runs over TCP and datagrams may also be retransmitted in that case, um but for the web transport mapping to http 3, we would pretty much get exactly the features we have in quick.

K

um Then there are a couple of requirements. The two first of them are um I think they are clear. We don't need to talk about them. Much I also already mentioned the multiple sessions which we could use for multiplexing, so that would solve our multiplexing problem, but then there are also two things which I don't really know how to um work around them, how to or what to do with them.

K

um First of them is that a client needs to be able to indicate An Origin to the server, and the second is to be able to describe a server endpoint location using our URI and I have some questions about these points on the next slide. So, but not if you can write one more slide, that would be nice or is it specific to the slide.

C

um Some uh yeah, just one thing, is um the way web transport sessions are used. Is they're typically used to delimit browser tag tabs.

C

So um you can't really use a web transport session to have multiple uh different RTP sessions within a single tab, and you could use a separate, quick connection for that. But I, don't think that's what you want so yeah I think I think you're misinterpreting any what a web transport session is.

K

Okay, I see that's helpful.

C

Yeah I mean if it's a non-browser context that could work, but within a browser it wouldn't work.

K

So we would need another multiplexing inside that one web transport session for.

C

We're doing it within a browser, yes, but.

K

Would it be possible to have different sessions or different things? So do we need to have our own multiplexing entrepreneur of web transport, then again.

C

Well, you, you could either just use bundle, in which case it wouldn't matter, I just throw everything there, but if you wanted to actually be able to do different uh RTP sessions within a web transport session, you'd need to have some kind of multiplexing. For that.

K

C

Problem, you could just say fine, we all you have you're, basically bundling everything within a web transport session. Don't worry about it.

B

So you can't open more than one web transport session inside a single tab just for using their demons. You.

C

Can open a set, a different connection and potentially uh have it be pooled right and then end up with different sessions? But it's it's unpredictable. You don't know whether you you can't really. You can't really control it. Pooling is not it's not easily controlled. It's something! The browser decides, not your application.

K

C

Yeah, it's like HTTP pooling on a browser right, you, you might use the same HTTP connection, but you can't it's up to the browser to decide whether you get that or not.

K

Mm-Hmm, okay, then, maybe to continue what questions we also had about rock transport. um So that's an important point. I think that we still would need to Define our multiplexing. On top of that, um then, additional things we noted is the two points I noted before we don't really know what to do within with a client origin in RTP, real, quick and server endpoint URI, because we don't really have these Concepts.

K

um Maybe we just ignore them. I, don't really know if it would be a problem for us. We just wanted to notice here.

C

um You don't have to deal with either these things in your respect, basically a way to think about the URI. It's like web sockets. You need a URI destination to establish the connection.

C

um So you know you don't need to you, don't need to worry about it, just assume it gets established somehow and then just run rgp over click over.

B

Well, presumably, the you know, whatever the if we Define you know, the sdp spec would need to say how you put the web, the URI in the STP, for it.

C

Right, yeah potentially right there, it would go there, but not in RTP yeah yeah. No.

D

Okay, so we just wanted to note.

K

Them down here for RTP, then for sdp. We might need to do something else, um and then the last point is probably the one which is most important about uh when we think about using web transport for multiplexing for rgp over quick is that it would be defined for HTTP, 2 and 3, and we were wondering whether it really makes sense to depend on rep transport and HTTP, 2 and 3 to get RTP over quick done um and I.

K

Think that's the you know the most important question we would like to answer here um either now or after they show the other two options. Maybe um the next slide.

K

So one idea that came up recently in a discussion with Spencer and York is that we could also reuse parts of web transport and avoid this dependency on http because basically ignore what is not really relevant for us.

K

um But we are also not really sure if we can simply reference things from web transport without saying um or depending on http, and we're also wondering how much different is this from the current approach using flow IDs, because we would probably rebuild something similar to The Sessions in web transport using our own abstraction layer, and that would probably look similar to what we are using with flow IDs already and.

D

J

K

um On the next slide,.

K

What I, already presented in October I think is that we limit ourselves to RTP and rtcp for now um keep using the flow identifier. So we can have multiple RTP sessions and rtcp. All in the same quick connection then register the aopn for RTP click, because it's not multiplexing with anything else anymore and then allow other documents that could be described or could be written in the future to specify new, LP and tokens, which will also then have to specify the multiplexing between RDP over quit and other protocols.

K

um How the atmos flexing looks like it's hard to describe in our document now, because we don't know which other protocols we would need and new documents could knowing which protocols to Multiplex with RDP over quick, for example, we use our flow identifier to assign different fluid interfires or different protocols, or build some other kind of multiplexing between those um yeah. That's other three options we currently see and would be I'm happy to hear your opinions on these foreign.

C

Yeah uh I don't understand what partial web transport is uh like when you say a void. A dependency on HTTP kind of web transport is negotiated with nhdp3, so I mean in your implementation. You don't need all of the HTTP 3 headers. So in that respect, you don't need a full hap3 implementation to do web transport, so your implementation can largely avoid it, but um but the protocol spec has kind of been meshed with http 3.

C

um and you also don't want to create your own version of web transport, so it can't communicate with the ones and browsers. It's largely a browser specific thing. So you want to you want to maintain browser, compatibility, I, think or it doesn't make a lot less. Yeah.

K

I think maybe maybe partial web transport is a bad naming here. um What we were thinking was since web transport is doing sessions and multiplexing between different sessions. We can look at how it's been done in web transport and I. Think it's using session IDs um and reference these parts from the spec, so we don't have to invent our own multiplexing, which we currently do with multi-abits with our flow identifiers.

K

C

Yeah that that makes some sense, but.

K

Then it's it's not that.

C

Different than just full web transport right, it's just.

K

C

Yeah and if you don't want to do HTTP 2, you don't really have to I mean uh the API allows you to say: I, don't wanna I, don't want to drop down to hdb2. It has no, you know, there's no point or.

N

You could decide.

C

For some reason that you want to do it um and then obviously you will get these weird effects for the datagrams, but uh presumably you're ready for it. Yeah.

K

I agree that HTTP 2 is probably an optional for us anyway, because I mean there's also actually RTP over TCP, and if you really want to do HTTP- and you know what you're doing that's fine, but probably most of us would use HTTP 3 and the question here is: rather, um how can we or do we want to avoid this dependency on HTTP 3? Does it have implications that we do want to avoid or not.

D

B

B

My inclination would be to say, do um Define sort of a raw single RTP session over quick and Define. Our you know. Web transport and the web transport can have should be able to handle all the dmux cases and all the browser cases and the other one can handle the well I. Don't want that complexity, but don't sort of that you know don't do anything else unless we feel like we understand, there's a use case for it, but maybe there is a use case for it. I'm not seeing it.

K

uh So I I think that would kind of be the second option that we look at web transports see what it is doing and reuse what we are interested in like the most flexing and try to make it such that we can use RDP over Rockaway connection, but that we can also use it over web transport session.

B

Yeah I think my point beyond that is don't Define multiplexing other than web transport, because I feel like defining our own multiplexing.

B

um It's probably not useful in that case, so it.

J

B

You want multiplexing menus web transport and, if you don't want web multiplexing use raw RDP over quick.

K

But uh since Bernard mentioned this earlier, would that be not given that we can't have multiple or can't decide which reference, what sessions go into? One click connection.

B

um I mean I guess the question is: how much do people actually care are.

C

You speaking Mathis.

D

C

Can't hear you.

K

um I think Jonathan heard.

B

What I said yeah I heard I heard about that said, yeah I think the question is how much do I mean I. Think, like I said you can't control what the two web transports go in the same, quick and I guess the question is.

C

Do Jonathan, are you speaking I.

B

Think I think Bernard Bernard I think for Bernard is.

B

um Yeah so um yeah so yeah I think, like I, said I think you know if I guess, the question is: do you actually need the two, um the two uh RTP sessions or whatever, to go over the same put connection as opposed to share a quick connection, as opposed to parallel quick connections? Does that how much does that matter to you and I guess: they're! Quite the you know the this thing would be.

B

um You know the load balancer thing, but given that web transport is designed for load balancer cases, it isn't guaranteeing that generally people will have solutions. They understand for how to do that.

D

K

Yeah good to know how um what what people think about this, but I think it might be useful to have multiple RDP sessions in one pre-connection, uh even if it's just to make congestion control between them easier. Foreign.

B

Yeah but I mean I, yeah, I, guess I don't know uh Bernard. Can you hear us now yeah.

C

I was going to say one other thing, which is that keep in mind that web transport is client server versus I. Think of RTP over quick as being a peer-to-peer thing where you do peer-to-peer.

J

Quick over ice.

C

B

C

Little bit different um and requiring web transport and all that Machinery might not uh there's a lot of Machinery in web transfer, which isn't necessary for peer-to-peer quick like the the client, IDs and stuff, like that. That's.

D

C

B

Possibly doesn't even make sense if you.

C

Right right, yeah.

C

I think what we need to do is to give you in a little time, we probably need to move to his slides yeah.

B

I'm, just thinking that.

C

But uh the question is: what are: uh how do we move forward on some of these questions? There's something we should note for the minutes.

B

um I would say we don't yet have consensus and it probably makes sense to for the authors to move forward on defining the various things and maybe like, as you get more into the details, you decide hey. This is really hard or hey. This is really easy and you know that might give us more information.

C

um Just just a question from the chairs uh would you would it make sense to schedule another interim where we could uh get into this more.

K

I think it would be helpful for me to have more input on this. What is wanted by the working group? I'm, not sure if we need a interim for that or if we should just automating this thread for.

B

That well, let's, let's start a mailing list thread and see how it goes and then okay, yeah good.

C

Okay, please note that in the minutes, what's the next.

K

C

Right thanks: okay, you win. Finally, okay! Yes, maybe we can go a little bit over time, but uh anyway go ahead. You went. Can.

N

You hear me yeah, we have yes, yeah I'll, try to I'll try to do it, quick, maybe over quick. We will we'll see uh next slide, um so this uh presentation is actually stemming from uh a side meeting that uh that was organized during the last ietf meeting and the goal was to look at as frame and RTP packetization and, generally speaking, the the goal in that right is to enable end-to-end encryption of media over RTP and I.

N

Think in that meaning Bernard, you you mentioned skip, which is uh solving basically that so skip is defining a payload format, also media subtypes, to allow uncrypted content over RTP. It's it's very in the focus of a skip session. uh So it's not really applicable here, but uh yeah.

N

The idea is um to to do the same as what what was done for skip, but in with a different scope and the scope is uh webrtc and they have the the slide is slightly misleading because we're not trying to solve end-to-end encryption of media variety we're just trying to to solve it in the context of webrtc, where there are some webrtc clients and sfus in the middle, and so during that meeting uh it was food good to Define, an architecture of webrtc clients, sfus and so on how they would interact with and try to solve the end-to-end encryption thing so that we can identify requirements uh and also maybe provide hints at how we could do it.

N

So that's um what we started doing in in the draft the encrypted media rtb architecture document. uh So you can click on the link uh uh it's on GitHub, so you can provide commands PRS or file issues as well. If that's, uh if you have some time so next slide so webrtc, uh so we have like three main nodes. Usually we have senders, which will be a webrtc clients, usually browsers. Then we have sfus that will do the package for forwarding thing and then receivers, which might also be a web browsers.

N

uh The typical architecture uh uh and it's no different than generic RTP is a the packetizer, is generating packets from uh from metadata and uh and and the encoded frame content, and basically whenever intermediaries need to uh get information of uh what the encoded frame is and so on. It can just report the encoded frame content, uh because it's in the packet payloads and then do processing based on that. In our case where uh content is encrypted end-to-end, the packetizer cannot really extract information from the Android frame content because it's encrypted.

N

So this content is really opaque and the same issues happens for intermediate intermediaries. We cannot extract information uh from uh from the content, so it has to be replaced somehow by providing more encodified metadata to these instruments. So in the architecture uh the encryptor is between the encoder and the packetizer next slide to uh yeah. Traditionally, the packetizer is tied with the encoder, but now we have the encryptor that is uh in between and we think that now it kind of makes sense for bucketizer to become tied to a media.

N

Encrypter is trying to define the relationship between the two and try to Define some kind of interfaces that we between the encrypter and the packetizer. Ideally uh because we are in webrtc territory, uh changes. Small changes to Media encrypter should uh not require a new packetizer. We want to Define enough requirements on the media encrypter on the packetizer, so that, whether you use as frame format, V1 or preet stream format, or even s packet, basically, the architecture Remains, the Same and the packetizer- could be a roughly the same.

N

So since we are in webrtc territory um we can, and since we want to Define some kind of interfaces, uh we have web contacts and web codex is a web API. That is defining interfaces for media decoders and encoders, and it's uh it's a really nice abstraction that we can use to uh model encrypt the packetizer relationship, um so next slide will focus on on video, because uh yeah video is a bit more difficult as well. Since we are like it uh more.

A

Packetization being.

N

Done so on the median creature side, it must provide to to the packetizer content metadata that is useful to enter mirrorize and these content media data is coming from either the media source of the media encoder.

N

So, for instance, video frame members, so video frame is, uh is representing a video frame in webcodex, and it has some members like color space orientation, and all of these is metadata that the media encrypter would pass through to to the packetizer there's also some metadata related to the entire video check, like the codec type, the frame type, the timestamp, the decoder, config vs, similar data and so on. So it's a another bunch of metadata.

N

That is uh uh that encrypto could share with uh the media applicatizer and finally, the mega and crypto is generated generating encrypted content. It will not provide the encoded content to the packetizer. It will instead provide the encrypted content and from that, the media application must do its job of generating packets, and the idea here is that, since it has a lot of content metadata, it can generate HP headers like CPU from video frame orientation and so on, and it can also generate RTD pillows.

N

But this time it cannot analyze the the content because it's encrypted, so it needs to do some splitting it can be based on MTU or it can be based on some other information provided by the media encrypter.

N

uh We are thinking also that the media packetizer must transmit and generate the underlying product type, so that is given as part of encoded video chunk, uh which represents the codec being used before before encryption next slide.

N

So that's working pretty well in the context of uh a video Codec that is not doing SVC now with SVC. It's a it's a bit different, because now you really you're not only caring about a video frame, but you you will care about uh even individually decodable units that together will form.

N

uh We will allow you to decode a video frame and um since we are in Weber security, where the SFU might want to uh send some decodable units to some clients and some some over the colorable units to some of the clients, it's up to the media encrypter to get the decodable units and to encrypt them separately, and then it can provide to the to the packetizer the encrypted decodable unit content and plus the midday data. That is identifying what the decodable unit is.

N

So it's not only the media data related to the video frame, but also limited data that is uh identified identified in the decodable unit and again there. The packetizer will need to transmit this uh additional metadata. The good thing is that there we have an interface as well uh that is available in the slides, so you can see the frame number and, and so on and webcodex is providing that.

N

So we already have an interface and uh abstraction that we can use to clearly Define the boundary between and the the contract between the encryptor and the packetizer.

N

um Next slide uh going now to uh packet forwarding unit, um so the packet forwarding unit is receiving packets sent by the sender and we'll send some of them to other clients and uh when it receives a uh a packet in, it needs to be able to compute, to which decodable unit the packet is belonging to, and for that we are thinking that the underlying connect type is very useful, as well as the marker bit and timestamp, and to actually decide whether this RTP packet needs to be forwarded or not.

N

That's where the decodable unit metadata is really important, and one possibility here is to uh put that metadata in in the dependency descriptor, and um one additional potential requirement is that uh some sfus might want to record a call and they might want to record the encrypted content. So it should be visible for an SFU to uh get back from the packets, the actual encrypted content and store it somewhere and then send it later on, if need be, uh going very quickly to the reserver side architecture now next slide.

N

um So now we we are at the level of the unrecipient, uh the robotic client it has a key. So it can decrypt, but still before that it's receiving packets and it has very similar requirements as the packet forwarding unit, because it needs to reconstruct the encrypted content. But it also needs to uh do early processing uh on the packets like if it seems that it it needs a a keyframe, then send a fear and and so on and uh yeah. It also needs to be able to use existing rtp-based redundancy mechanisms.

N

Yep next slide will slightly over time. I. Guess it's fine. um So so, basically, the document is defining the architecture uh and some uh API contracts that they that we could set.

J

N

The different breaks of the pipeline- and we we are thinking that there is a proof of feasibility uh of the overall implementation in the reality world. uh Basically, you you, you apply as frame on each encoded. Video chunk uh as frame would be a password to all the related metadata that is received from web codecs and the RTP packetizer would uh generate the dependency descriptor rtph extension from the metadata, and it will encrypt the content. It will split.

N

The uncomplete content based on MTU and the payload type itself could be a prepended in the payload, for instance, we could think of uh which is very similar to what skip has done. uh Adding some subtypes like audio and Cryptid or video encrypted, for instance, and and use that for negotiation.

N

uh Next slide and I will be close to to the end. um So uh Peter mentioned that sfus might want to repacketize, and that's something that is interesting. It's not really in the draft now and that's something that uh I think we would welcome feedback there, uh uh since there may be different mtus or there might be different protocols.

N

Maybe uh some packets need to be split or merged and I wonder whether it should be in scope of this work uh uh and whoever uh there are some cases that are more important, like large to small functions might be more important than small to large or so so uh I'm, not sure. We will have a lot of time to discuss this, but yeah feedback is welcome either here or in the mailing list or on GitHub, and the last slide.

N

So my my temporary conclusion is that uh in the context of webrtc, we we can its desired to support end-to-end encrypted content, and we can actually do that uh and it can be done even though the practically and encrypted uh format uh changes like it can be as frame as packet. It can be something else. We can still Define the same architecture and hopefully uh reuse very, very similar packetas, uh so the current architecture provides a basis for what and how we want to support packetization uh foreign content.

N

uh It's still a draft, so I'm wondering whether at some point we want to uh submit it to the working group or whether we should uh think of starting Solutions instead, so votes from the working group, I only have like a few minutes left, because I need to jump in in some of the meetings. But if you have feedback, it's most welcome.

C

Hello, it's Jonathan first and then Harold.

B

Did I I'm not sure my door is my hand? I'm sorry go ahead.

M

Just say that um I'm also working on this area in this area, for other reasons, um the handling of encoded media without having to decode it. In order to understand what to do with, it is quite important in a couple of scenarios we have where we have looked at I mean enter any crypto. Content is one important point, but I think we need an architecture for for doing a little more than that, but this is also being discussed in webrtc working group in wgse. So the initial corporate.

L

If it wasn't already obvious uh I'm in support of doing this, and starting.

N

So what would be the next steps when uh Bernard Jonathan should I try to finalize the document and try to submit it, or should we focus more on Solutions.

B

I think having the architecture just sort of as the background for things is useful. um I'd say you know, maybe um submit that as a I mean submitted. You know it doesn't have to be complete it just you know as a zero zero digital draft. It doesn't have to be perfect, obviously, but I'd say, but probably also start working on Solutions in parallel just so, we can sort of see okay. What do you have in mind and um how are you thinking of doing it? Just you know again, sort of you know broad outlines.

B

You know with some straw bands, if need be uh just so, we can start having something up a place to start working on it, but I think there's. Clearly there is a lot of interest in this I think it would certainly be something that the working group is interested in doing sort of has a problem to solve.

C

Yeah and I want to thank you, you, and also for.

D

C

Progressing this I know, there's there's a bunch of things that that you've done that are new and I think represent progress from where we were so um I just want to encourage you to keep keep at it.

N

Okay, I'll try to submit it before uh the next ITF meeting and I guess, maybe with Peter and maybe Sergio as well. uh We we might want to advance uh Solutions, then in in the scope of uh this, this architecture graft and webrtc.

B

Seems good and you know like I, said a Herald said if, if the.

J

B

Know, w3c groups are working on it make sure to coordinate with.

N

Them yeah good point: I will so maybe around I will uh put you in the room as well.

C

Okay, uh I, don't know Peter. If you want to go over any of the remaining slides, you got I think two slides.

L

Yeah just skip to the next one and I'll: do it in like two minutes.

L

um Basically, if we're going to have a solution, um I think basically we're trying to decide what to go into that and as far as I know, there's the things that could go in um the biggest one is the payload type, uh but because it including that helps avoid Associated payload exclusion um and then within that we can decide if it's optional or required, because it might be cases where you only have one audio codecs.

L

What's the point of burning a byte, um but then there are other things like frame number or offset or index that are really just helpful for repacketization by an SFU for out of order packets, and uh this is something that you and talked about briefly I. Don't think we have time to go into uh why those are useful. But I just wanted to point out that a major design decision is really just what is included in the format that we come up with and you know things can be optional.

D

B

And this this might be something we're just having like a quick and dirty. You know, like uh you, know, proof of concept, implementation just to play with it and see how hard is this implementation? How much do I actually use this information in my implementation would be useful, so just like toss something together in JavaScript or something.

L

Yeah point maybe I could make a like big to smaller repack station example.

D

Exactly yeah yeah.

C

Okay, I think we've reached the end of the meeting. I wanted to thank everybody for coming um and I guess. uh We will, as mentioned, discuss a bunch of things on the mailing list and also we will of course have our normal meeting at itf116..

A

C

Thanks everybody.

B

See you Robert.