Session Date/Time: 23 Jul 2026 07:00
[00:00:12] Jonathan Lennox: K. Seems good. Give it another minute because we're the first people in the morning. So Alright. I guess we can probably get started. People might trickle in, but that's fine. So welcome to AVTCore at IETF 126. I am Jonathan Lennox. My co-chair is remote, Bernard. Always, note the note well. Everybody is expected to behave in a professional manner and extend like, respect and courtesy to everybody else involved. If you have any concerns, contact the chairs or the ADs or the ombuds team. Also, there are requirements on IPR disclosure. If you know any IPR that you control on a document, you must disclose it. See this for details. And all this is being recorded, so you will show up on camera if you speak at the microphone. Meeting tips. Please, everybody here, make sure to sign in to the meeting either via the link in the data tracker or there's a QR code on the microphone there. You use the meet you use this to join the queue if you wish to speak or if we have a poll. We don't usually have polls in this group, but we might. You never know. And if you are remote, if you're hearing me, you've probably already joined this, but please keep your audio and video off unless you're chatting, you're presenting, or speaking at the mic. And use of a headset is strongly recommended because echo cancellation isn't perfect. Also, everybody, please state your state your name when we begin speaking in the queue, you know, even especially I mean, it's good for everybody, but it's especially good now that we're using the AI notetaker tool, so maybe it'll actually get your name right when it you when we get it to show up in the notes. I don't wanna attribute it to somebody who's not here. Here are some resources and the agenda. Start off with this business, then we will have Eric doing frame acknowledgement, doing V-DMC, Sun doing OPUS MultiStream, and then Magnus doing GCM-SST. Anybody have any comments or questions or requests on the
[00:04:03] Magnus Westland: on the agenda?
[00:04:06] Jonathan Lennox: Alright. So draft status is a little bit small, but, hopefully, everybody can read enough to be tell. We have published haptics, nine nine nine three, so that's exciting. V-3C of the RFC editor. JPEG access third edition and green metadata are with the IESG. HEVC-WebRTC completed working the last call. There were some editorial comments, basically, because it was still written as though we're proposing a new idea, whereas it's now standardizing a defined idea, but there were no technical comments. And RTP over Quick had working group last call a while ago, and we did not get anything like enough comments on it. So I will encourage please, please, everybody review that and send comments. I'm I'm staring at Magnus specifically. Oh, thank you. We have a number of adopted drafts, many of which we're talking about today, and then several of which were adopted but expired, which is not the best status. So I will try to nag the the authors. But if you're the authors of any of those drafts, please try to let us know if there's stuff if there's stuff you need from us or otherwise update with any things you know. I any Mario, do you have anything to add?
[00:05:42] Erik Myhre: No. I don't have any further comments.
[00:05:44] Jonathan Lennox: Yeah. Oh oh, one other note to our I AD on the AVTcore. We are keeping Bernard as a coauthor on that, so we'll need to override it off 48 because he did most of the work, and we don't we wanna credit him for that.
[00:05:59] Alan Ford: Yeah. Yeah. I think that's appropriate.
[00:06:01] Jonathan Lennox: Okay. Thank you. Alright. So I guess, Erik, you're up first. There we are. K. And I can give you clicker control.
[00:06:20] Magnus Westland: Yep. Okay.
[00:06:22] Jonathan Lennox: That should work. And, yes, you're probably you're you're tall, so we probably need that to be higher either higher up or hold the budget down.
[00:06:30] Erik Myhre: Yeah. Maybe I just told him this in. Yeah. Can you
[00:06:31] Magnus Westland: hear me?
[00:06:32] Jonathan Lennox: No. I can. Can there are people here?
[00:06:35] Erik Myhre: Perfect. Yes. That's fine.
[00:06:38] Magnus Westland: Great. Thank you. Alright.
[00:06:41] Erik Myhre: So I'm Erik. Together with and we have written this proposal on RTP frame acknowledgement. Here to do some updates on that. So I guess the big news since last time was that it was adopted by the working group. So it's changed name accordingly and also moved from Megatab repo into the IETF WG. And we continue to make kind of slow but steady progress. I think we have only a handful of issues left that we can hopefully close soon. There's a few of them listed down here that we're gonna look a few of them are closed, and others, we want input from the group if possible. Okay. Just to recap what frame acknowledgment is. So this is first header extension. You can add to frame to market with a frame ID and also to request that when the receiver has received and decoded this or a list of frame IDs, it should send feedback using an RTCP message to say which of these frames it has successfully received and decoded. And two of the issues we identified here was that since you essentially keep a state of a list of frames at the receiver, if you just keep marking frames with IDs but never request feedback form, you sort of expect the receiver to keep a very long list potentially of of state that's not useful. Also, you could unintentionally or maliciously try to request feedback from the start of time up to now for every frame you send in order to try and just generate a bunch of excessive feedback. So we've addressed this a few ways. One of them is to introduce a status window. So we define a window in the FIFO queue at the receiver where you keep the state for these frames. They can actually negotiate the size of this by STP if you want to. Otherwise, it's defaulted to two fifty five. I just added language that senders should request feedback regularly. I'm not sure why any reasonable application wouldn't, but, yeah, let's put it there anyway. We also explicitly stated that you must follow the RTC feedback timing rules. So this puts limits on how much of the bandwidth you can actually use for feedback. So that means if you actually keep requesting too much feedback, it's gonna be deferred. And so these well, okay. So with that also, we had to add some language to say what happens if you request feedback for a certain set of frames and then the window shifts. So we want to make clear what the receiver is actually expected to do in that case. And with those things, the cities, when do we address the stakes extortion problem? And with the timing rules, the feedback amplification should also be a non issue. So this is a topic that we're currently discussing. So we have a hypothetical scenario here where you've received and decoded a couple of frames. We have one of them where you have dropped back as you have not been able to decode it. But then you actually have frames after that you have been able to recede. And the question is, should we introduce something to signal that these frames are actually complete, but we couldn't decode it for some reason? And with that data, it might make it easier for a sender to determine if it should try to recover with an LTR reference or if it just should try to do retransmission. But that also makes we need to add an extra bit for for every frame that we wanna send feedback for, which adds a little bit of bandwidth, but more, I think, implementation complexity because it might not be clear why a frame isn't decodable. Like, if you take every frame, you might be able to infer the chain to see which frame you're actually missing things for. But if not, is this receiver expected to infer all the frames from the last acknowledged or unacknowledged to this one? Just comes a bit tricky.
[00:11:22] Jonathan Lennox: Jonathan is giving a personal opinion. I feel like we have other mechanisms to tell you which packets have been received. I feel like this is should this is doing decoding. This is the purpose of this is decoding and, you know, you there's no reason you can't run this and max simultaneously. Yeah. So things have been if things haven't been received, you knock that if things have been decoded, you don't frame acknowledge them. So I think that's you know, keep the keep each mechanism doing one thing and use more than one mechanism if you want Yep. To do multiple things. I think it's probably a better approach. But that's Exactly. Perfect opinion.
[00:11:56] Erik Myhre: That's along my thinking as well. Like, this is about decodability and not about the packet transport. But we just wanted to reach out to the group to see if anyone has any use case. If if this would be useful to anyone, then we might include it. Otherwise, probably we'll drop it. The next thing was around okay. You tag a packet with a frame ID. What bitstream data does it actually refer to? So in the draft, we define a frame as any independently decodable unit of bitstream data that results in an update to the codec state that can be used as reference for any subsequent decodable unit of bitstream data. So, typically, this will be a full frame, but it could be potentially a subset of frame. If you're talking about SVC, of course, it can be the full full frame for a temporary unit, or it could be frames for a for a given layer. We've also stated the header extension appears on the last packet of a frame. We can, of course, only have one frame ID per packet, and it also refers to the last decodable unit in that packet.
[00:13:09] Moe Zanaty: Moe Zanaty, Cisco. I I think the frame definition probably needs to be adjusted because as it reads, it would also apply to, like, a slice. I don't think you ever meant to apply it to a slice. Right?
[00:13:19] Erik Myhre: That is that is sort of the point. Well, it's maybe not a slice, but it's supposed to be able well, we can get to it, I guess. I'll I'll get to your point. Let's go through it and cycle back. But yeah. So there are other header extensions with similar issues. Like, the dependency descriptor says it's an RTP frame is just what they say. The frame marking, it's sort of old package related to a frame that has a given as a temporary spatial ID or, yeah, layer ID. It could be a quality layer as well. I don't know if I need to go through this in detail. I'm just thinking of edge cases here. Technically, we could support having two frames in one packet, in which case, the frame ID will then set refer to the last. So in this case, you have a SVC frame. It would refer to the top one just both if both of them are in the same packet. If you're using simulcast, it would also refer to the same packet to to the to the top frame. In this case, you cannot refer to the bottom frame. I don't think it's a problem because I don't know why you would send both frames together in one packet if you're using RTP in this way. Let's skip that one. Okay. So the point is we wanna be able to also support the concept of tile streaming. So the h two six six specifically has this. They which they call sub pictures. A v two seems to have implemented two competing ways of doing basically the same thing. But the point is to doing things like VR XR streaming where you only wanna stream part of the picture, the real direction that you're looking in. And so the point is to exactly in the same way that we do layering, we would be able to sort of split each tile then into packets. And you could put them potentially also tag frame IDs for each of these tiles so you can infer about the decodable state there. So TLDR, if, like, your whole frame is like, if you can if even if you have multiple slices or whatever, if according to the spec you're using, you have to decode all of this in order to have a decodable frame, it doesn't matter if you refer to the last slice. Like, if that slice if you have decoded the slice means you have decoded the full picture, it's implicitly referring to the full picture. But if you have a codec where you can, according to the RTP profile for that codec, decode a part of a frame, then you can indeed if you packetize them separately, you can mark them separately and signal those because it was state separately. Okay. Did I address your comments or your question now?
[00:16:51] Moe Zanaty: It it mean it seems like you didn't don't really mean frame. You just mean unit in general because I I don't I don't recall any RTP specs that have ever used the word frame to mean, you know, a slice. There is always ambiguity between a full a full frame as a full temporal unit versus a frame as a layer, a spatial layer. There's always confusion about that, and different specs see different things. Yep. So frame is used interchangeably there, but I've never seen frame used to mean a slice No. Or a tile. So maybe you want a different word than frame there if if that's if you really intend to allow that.
[00:17:29] Erik Myhre: The yeah. Except problem is every codec, even within the sort of same standards group, seems to call it a new thing for the next generation. So just don't not sure which word to use. But, yeah, certainly, we could call it something else.
[00:17:51] Magnus Westland: Magnus
[00:17:51] Magnus Westland: Westland, Ericsson. I I do think it might this one actually may be more useful if you go with the definition towards, say, okay. Be able to indicate the independent decodable unit, wherever it is. I mean, because we have as you say, we have tiles for HEVC of two six five, two six six, and AV1, then it's like yeah. And and this I don't think
[00:18:19] Erik Myhre: it will go away, this
[00:18:21] Magnus Westerlund: type of enabling parallel decoding thing if you especially if you go towards higher bandwidth. You probably want to be able to indicate out which parts of the independently codable have I been able to decode if you only get some subset of the picture decoded and not the other. Yeah. Okay.
[00:18:42] Erik Myhre: I guess the yeah. I thought about h two six five, but it seems like even the, like, motion constraint tilesets there, according to the RTP spec, it doesn't seem like you're able to decode one of those and skip the rest of them. So
[00:18:56] Magnus Westland: I it's been too long since I I looked into deeply, so I don't remember how what's and what's not possible within the byte stream there. Yep. I think a lot is hidden within the HRD and the specified pipe stream pin.
[00:19:13] Jonathan Lennox: Yep.
[00:19:17] Erik Myhre: I will I have a PR in in review. I'm gonna make some more edits to that. I might ping the mailing list to to ask for input there if other people.
[00:19:27] Jonathan Lennox: Yeah. Jonathan Lennox again as an individual. I mean, I feel like from I mean, I'm I mostly my experience is mostly a little bit older now in a in H.264 or whatnot, but we did, you know, have independently decodable slices, but that's mostly only useful so you can do things like multithreaded decoding. It's not actually useful for decoding only part of a picture and moving on because you still need to eventually get the whole picture to use it as a reference. So in which case, yes, they're infinitely decodable, but I think I'd I'd still want to know when the whole actual frame is decoded. So, I mean, I'm wondering if rather than if we would actually just rather specify this, I mean, it would send more header extensions, but have, like, something like, you know, flag saying start of unit I care about, end of unit I care about, so the encoder can decide what granularity it cares about in terms of getting feedback. You know, if it wants to know slices, it can say, this is, you know, this is, you know, frame you know, you give each slice a different number. If it only cares about frames, it could say, this is sort of frame. This is end of frame. I'm just sort of speculating off off the cuff here, but I feel like it might, you know, it might vary by encoder what it thinks is useful.
[00:20:50] Magnus Westland: Magnus Westerlund. Yeah. I just remember where where when I looked into tiles, I worked with with the tiles. We were actually looking at at three sixty video usage cases. And and there, you might not be looking or showing at all that direction, which so you you I think they even with AV1, you actually have truly decodable independent decodable parts, which you can ignore if you're not interested because they're auto
[00:21:19] Jonathan Lennox: Yeah. I feel like tiles and slices are different use cases.
[00:21:22] Magnus Westland: Yes. And Tiles, I think it's it's it makes more sense. Yeah. No.
[00:21:25] Erik Myhre: I agree.
[00:21:25] Jonathan Lennox: So that's why I'm thinking it might make more sense to leave this under the encoder control and try to specify something which is a poor fit for some cases either in either direction. Yeah. Yep.
[00:21:42] Erik Myhre: Alright. Thank you, those comments. Yeah. So we're like, this is one of one of the GitHub issues we're trying to close out. But I think after that, we're in a pretty good state, and we wanna have review from the working group, if possible, to have to have more eyes on it. And at the same time, create a prototype implementation so we can actually benchmark it and show that it is in practice useful. Yeah, that's all I had. Thank you.
[00:22:15] Jonathan Lennox: Alright. Any other comments or anything? I encourage everybody to read the draft, and we have a GitHub. So make comments in the GitHub. If there's any if there's major design issues, also mention them on the list. And thank you. Alright. This is always a little bit involved, so I think I have to do this, then this, then this, then wait. Where this is hold on. What are we doing? Or if this is v d m c. Right? Yeah. Okay. Yes. And then do you wanna use the clicker, or do want me to drive the slides? Alright. Alright. Let's one second. Let me alright. You should have slide control now.
[00:23:03] VDMC Presenter: Hello. I'm from IntoZero. Today, I do like just present update information to the V-DMC draft. So this is our history history of our draft. So we published the first individual draft in October 2020. And then we published working group first working draft about one years later. Then after that, we wait for a while until our MPEG reference draft reached FTIS status. Then finally, it it has become a FTIS now. And for the reference other draft, we also have a one draft in the a b tcore, which is a V-3C, and this is not under Now it's a review. So, yeah, this is all of the related to document status. So we just did a bit update draft based from the working group version. Now it's your two version. First of all, we revised a prehistory component for VDMC table based on the MPEG reference document because they did a bit changed when they when they revised a little bit at the final stage. So we also revised some part to clarify how it should be used. So in particular, we update fragmentation unit part. And we also update based on the comments that we received, during the radius r f s review. So in particular, we we updated, STP parameter section and the security concerns sections based on that comment. And we also have some minor update, such as, typo, and we are sitting with some unnecessary parameter because, parameter doesn't use anymore because the that part the contents of that part little bit changed in from the MPEG reference document. So we also remove that part too. So I think, as I mentioned before, I think, most of our reference document is ready. So I believe that is ready for, working Rascal. So I'd like to request walking Rascal this time. But I really wanna a feedback from our groups, and especially if for the V-3C draft authors. Yeah. Thank you. So any comment? Or
[00:26:19] Jonathan Lennox: So you're saying that the comments that are being made on V-3C in IESG review, you're feeding into this document as well?
[00:26:28] VDMC Presenter: Yeah. We I tried yeah.
[00:26:30] Jonathan Lennox: So probably what I would suggest is we wait till that's finished. I used to review, see if there's more any more things to feed in, then do one last rep of this and do work in the best call. Does that make sense?
[00:26:41] VDMC Presenter: Yeah. By the way, they are that draft is under RFC editors.
[00:26:47] Erik Myhre: Oh, it's already it's already
[00:26:48] Jonathan Lennox: RFC editor. Right?
[00:26:48] VDMC Presenter: Think it's already done. Yeah. Okay.
[00:26:50] Jonathan Lennox: Alright. In that case, yeah. Okay. Yeah. Right. I got you right. I confused which we do have two in them. I used to review, and I lost track of which one was which ones are. Yeah. Alright. Yeah. So that sounds like yeah. This is yeah. I mean, I'm sure we'll get typo fixes in our RFC editor queue and we could get merged in, but that's trivial. Yeah. So yeah. Yeah. So it sounds like, yeah, we should start working group last call, and so we'll start that in the next little bit. Alright.
[00:27:14] VDMC Presenter: Thank you.
[00:27:15] Jonathan Lennox: Sure. Thanks. So next up, we have, I think, Opus Multistream. You have to click this too many times. Alright. And, Son, do you want slide control, or do want me to drive the slides?
[00:27:38] Shuaiyang Sun: Oh, yeah. If I can, I can
[00:27:41] Erik Myhre: Alright?
[00:27:42] Jonathan Lennox: You should have side control now. I why did why did it disappear? I don't understand what happened here. Okay. Just like
[00:27:56] Magnus Westland: Oh. No. No. Hold hold on.
[00:27:57] Jonathan Lennox: Let me share the slides, and then I'll pass you control.
[00:28:00] Shuaiyang Sun: Okay. Yeah. Yes.
[00:28:01] Alan Ford: Alright.
[00:28:02] Shuaiyang Sun: Sorry about that.
[00:28:03] Jonathan Lennox: No worries. Alright. Alright. So now you should have control.
[00:28:08] Shuaiyang Sun: Yes. I can. Good. Thanks. Thank you for attending this presentation. I'm going to present about RTP, STP for the OPUS multi stream. The purpose of this presentation is about sharing what we have done, what we have discussed through AVTCore working group, and also want to share the the feedback we have and then ask for the direction. So let me start from the recap because we started this this question from last IETF 118. So that's maybe last year. So first thing, what we need to why why do we need to multi opus on this WebRTC streaming is in case of cloud gaming, unlike video conferencing, the surround sound audio streaming is quite credential because most of the high end gaming, they already has surround sound audio. So the goal of the cloud gaming is to replicate all the features of the game has to be supported by the network. So that's the motivation of surround sound support through WebRTC. And the current situation is when we try to get the Opus Multistream multichannel audio from the server, in case of cloud gaming server, we request the client, the user agent, to support multi opus, multichannel audio, and different video option and the other backup audio options. And when we send the request, the user agent usually reject the in case of audio channel is larger than stereo. This case, the SDP information got rejected or deleted. And then the other information usually kind of mapped to the user agent capability, so we got the information updated without loss. So what the most of the application can support surround sound at this time, we just detect whether the user agent remove or reject any surround sound option, and then we just manually recover the multi audio information after the rejection, which is called STP merging so that we can have the multichannel support through the browser client. That's the current situation, also the limitation. That's why we want to resolve this issue by having this support from the browser without any kind of additional modification of the STP. That is the goal of this idea. So we proposed it. And last, IETF 118, Timothy and Moe shared some feedbacks about the revision original revision. And we already applied those feedback into the revision three. Most of the feedback we got and we updated was first thing, we met the family syntax of the coded channel, and and we are not modifying any RTP payroll format. We just make sure that this is for, like, signaling purpose, not the not we are not trying to modify or changing any RTP or streaming layout or format part. So we just make sure that also, we make sure that the current WebRTC WG work is being used as a extension for the future extension, but not this. We make sure that this idea is just limited to the channel family 1 Opus channel. So those were updated on the revision three. And since then, we started asking the adoption call. And from the adoption call from last May to June. We got several feedback from Erik and others, and they were they supported this idea. Also, Philipp made a objection of this idea because of the following idea. He suggested that this idea is just based on the existing change list of the Chrome browser. So he suggested that without relying on the existing implementation, why don't we use the more syntax syntax more proper syntax of multichannel OPUS without making any additional MIME type addition, like Opus Multistream? So we can just use opus/48000/channel-number. Those are those idea was suggested as a different implementation, different idea. So I just make a comparison for both ideas. So I just put these two different options. One is current proposal, and the second one is proposed by the Philipp. And we just see there are some advantage without making any new MIME type addition. But, also, when we use the Opus namespace with channel number, we need to update the existing infrastructures, not only for the server, but also let me finish, Philipp, and then I will get your question. So we will get we will have a, like, existing system if we use the current multiopus namespace. That is kind of advantage, but I I agree what Philipp suggested so we can have a more clear OPUS syntax. Also, we don't need to rely on any IANA mime type expansion. Yes. Philip?
[00:36:12] Philipp Hancke: Philipp Hancke, so when you say existing deployment experience, please note that this requires STP managing, which is not allowed by the w three c specification. So you will need changes no matter what.
[00:36:31] Shuaiyang Sun: Yeah. That's good point. But, actually, let me go back. So what I mean the extra the current existing implementation is, like, after we make a merging, when we use the local description to the browser client, the browser already has this multichannel OPUS information implemented. The existing WebRTC implementation has multiopus information. Also, not only for this browser implementation, the server side already has the multi purpose namespace, which I think is existing infrastructure.
[00:37:20] Philipp Hancke: That's correct. But you will need to update the browser implementations to actually support and announce the codec, which they currently don't do for reasons only Google can explain.
[00:37:40] Shuaiyang Sun: I think that's correct. But WebRTC implementation is not used only by the Google.
[00:37:55] Philipp Hancke: True. But in this case, this was something Google wrote for a specific use case, and we don't even know how widely multiopus is used. We will get public numbers next month in the next Chrome version so we know how often this is used or being abused.
[00:38:18] Shuaiyang Sun: I I didn't understand clearly. Can you repeat once again?
[00:38:27] Magnus Westland: So
[00:38:27] Philipp Hancke: I added measurements for determining how often this STP monitoring is used because STP monitoring is on the list of things that should go away because it's a spec violation, and we will get numbers how often multiopus is enabled relative to the other STP module.
[00:38:48] Shuaiyang Sun: Oh, yeah. Yeah. Sure. Yeah. We we the the motivation of this idea is also we already noticed that the WebRTC is trying to block the SAP merging. So, eventually, we think the SAP merging should be removed all the server side or service side implementation. I agree.
[00:39:14] Moe Zanaty: Eric?
[00:39:18] Erik Myhre: So, Erik Myhre, are you aware of any other browser apart from Chromium that actually supports this behavior?
[00:39:27] Shuaiyang Sun: Which mean do you mean surround sound support?
[00:39:32] Erik Myhre: Well, yeah, the the the multi opus that that that you're actually using in production now, does it work with, say, Firefox so far?
[00:39:42] Shuaiyang Sun: We we actually evaluate on Chrome, and we haven't actually used the other browser yet. We are currently depends on the Chrome implementation.
[00:40:01] Erik Myhre: Okay. Thank you.
[00:40:12] VDMC Presenter: Okay. And yeah. Oh, yeah.
[00:40:15] Erik Myhre: Moe?
[00:40:17] Moe Zanaty: Yeah. Moe Zanaty, Cisco. I'm just curious. Is this a problem just unique to STP? Because Opus is used in five dot one surround environments in in in many other contexts. Like, for example, there's the iAMF immersive audio media format. So YouTube streams that. I think it's also called Eclipse audio. So it's it's popular in a lot of other contexts. Those are not STP contexts, but Mhmm. They don't they don't they didn't have to extend anything. They just still use the word opus. Right? There's no multi opus. And if you open the container, there's no multi opus in there. It's just opus, and it's used with five dot one or even higher order Ambisonics. So I'm wondering what is broken about STP that requires a multi opus here?
[00:41:07] Shuaiyang Sun: Okay. Yeah. Moe, I think let me go back to the slide. So this is the STP we are relying on while making the STP hand shaking between server and client. And then when we have this hand shaking, we just need to have all the information, like, matched in between server and client. And right now, the, like, WebRTC client side implementation, when the server request multi opus in the I video ID zero, it got removed.
[00:41:47] Moe Zanaty: But but but what's the rationale for the server doing multi opus instead of opus? If mid zero was opus, would it be rejected or it'd be accepted?
[00:41:55] Shuaiyang Sun: Is it it is rejected as of today.
[00:42:00] Jonathan Lennox: Yeah. I think
[00:42:01] Moe Zanaty: If mid 0 was Opus48 Mhmm. Six, not multi Opus486, do you see that being rejected or accepted today?
[00:42:10] Shuaiyang Sun: Oh, like, general Opus?
[00:42:13] Moe Zanaty: Yes. It
[00:42:14] Shuaiyang Sun: is accept yeah. It it is accepted.
[00:42:16] Jonathan Lennox: No. So I think the existing Opus the existing Opus codec only specifies slash two. And so it would the existing things would not accept a slash six.
[00:42:27] Shuaiyang Sun: But Ah, slash six. Yeah. That's correct.
[00:42:30] Moe Zanaty: So it's still be rejected.
[00:42:31] Jonathan Lennox: It's still be rejected. But yeah. So Philipp's proposal is to defy extend the Opus Right.
[00:42:36] Moe Zanaty: The subtype the subtype for the one type.
[00:42:38] Jonathan Lennox: Yeah. Exactly.
[00:42:38] Moe Zanaty: New one type.
[00:42:39] Jonathan Lennox: Yeah. Exactly.
[00:42:40] Moe Zanaty: I think that's Yeah.
[00:42:40] Jonathan Lennox: I I believe as I understand the history, the then this was basically because this was not a standard thing, the Chrome the implementation wired it in this way so that it could be a separate path for a nonstandard thing. And I think as I under not to speak for Philip necessarily, but as his argument is that if we're gonna make it a standard thing, it should look more like a standard thing rather than a separate path.
[00:43:11] Moe Zanaty: I would agree with that because, like I said, it's also used in other contexts, in non SDP, non WebRTC contexts with op with the Opus, you know, canonical word and, you know, with multi multichannel audio and even even beyond, you know, standards around even more complex channel family mappings than than than standard surrounds. So I I think that makes more sense in lines with other standards.
[00:43:38] Shuaiyang Sun: Thanks.
[00:43:40] Magnus Westland: Alan?
[00:43:43] Alan Ford: Alan Ford, Cisco. I was wondering how you'd see this working if multiopus wasn't supported and Opus was, say, for example, is that a scenario you'd want to support in this, and would it be easier in one way or the other? Because whatever happens, as Jonathan said, slash two is the only thing specified for Opus today. So we'd have to specify in a document to support for other things, and then we'd have to support, well, what if the answer comes back with only slash two? Is that the way you would negotiate this down? Mhmm.
[00:44:15] Jonathan Lennox: Or would
[00:44:15] Alan Ford: it be easier to have a separate mime type for this? I don't have a strong opinion on this. I I think I prefer Philipp's solution anyway. It's neater, but we definitely need to specify what would happen if one end supports it not. You just zero it out, or do you try and negotiate a slash two or or what?
[00:44:37] Shuaiyang Sun: So what we want is to have multi purpose support from the browser client. We don't, like, we don't have a strong, like, preference.
[00:44:49] Jonathan Lennox: Yeah. So I think if you're asking what what's happens in the spec, if you if you offered an m line with only the slash six as the payload format, it would reject it. If you offered a m line with both a slash six and a set slash two as separate payload formats Mhmm. Something they didn't understand it would, assuming it's pro implemented, respond with only the slash two and accept it.
[00:45:12] VDMC Presenter: Yeah. I think
[00:45:13] Alan Ford: it it it that that seems neat.
[00:45:15] Jonathan Lennox: Yeah. That that's that's what's supposed to happen to us. Now my concern is if there's implementations that say, oh, it's opus. I know what this means, and don't bother to check the two. But then they're broken, and, hopefully, there's not not too many of those.
[00:45:26] Alan Ford: Okay. As long as as long as everyone Yeah. Agrees, that's what would happen. Yeah. Sounds great
[00:45:29] Jonathan Lennox: to me. Okay. Harald?
[00:45:38] Harald Alvestrand: Yeah. Hello. I was. I was next door to to the bad bad decision to implement multiopus in the first place. And the reason for doing multiopus was exactly because we didn't trust that will do that the opus slash six wouldn't interfere with wouldn't make interesting bugs with the multi with with the old Opus. I'm in favor of doing it clearly now, but then I'm not implementing it anymore. So I would I would be happy to see to see us see us go forward to with the just open slash six and define whether open slash two is a valid answer to a proposal of open slash six. That's for but that has to be decided.
[00:46:54] Jonathan Lennox: Okay. Does anybody want to stand up and say that they actively prefer multiopus versus Opus slash six? Because it sounds like we're roughly getting towards. And I guess, also, would the people who actually implement this offer an opinion on whether they'd wanna implement one or the other?
[00:47:14] Erik Myhre: Yes. I mean, I said I supported MultiOpus, but, actually, seeing Philipp's proposal and thinking more about it, I think it's actually right there. And if you write a good spec, I don't think any human really has to write code for it either.
[00:47:36] Jonathan Lennox: Anybody else have any comments toward this point? If not, I mean, I we we should probably confirm this on the list, but it's sounding like we have a consensus towards doing the you know, extending the existing OPUS payload format rather than defining a new one. So I would suggest that the authors of the current drafts, you know, update it up offer an updated version that does that instead of defining the multi OPUS payload format, and then we can do a call for adoption on that. Does anybody disagree with that? Alright. Bernard, if you're taking notes taking note that we should confirm that on the list, but that is the approach we'll take. And, obviously, authors, as long as it's individual draft, you can update it whenever you like. You don't have to wait for us to do that column list. Actually, mean, I guess, technically, we just we we we don't have to necessarily even do a column list. Authors can just do a Moe, did you have a comment?
[00:48:43] Moe Zanaty: Yeah. Moe Zanaty, I wonder if do you want do you still wanna mention the historical multiopus in that draft to, you know, to avoid developer confusion, or do you want this to be a stand alone speaker that has no historical
[00:48:56] Jonathan Lennox: I mean, I that's hack. That's kind of an editorial decision. But, I mean, I think it's not unreasonable to have an informative section saying there was this hack, but this is something different. Alright. So yeah. So my my my suggestion is actually I don't know if we even need to do a call on the list because it's still an individual draft. But my suggestion is, authors, let's do a why don't you update this with open the open slash fixing, and then we can do another call for adoption.
[00:49:23] Shuaiyang Sun: Yeah. That sounds very clear to me. Thanks for the, yeah, information.
[00:49:28] Jonathan Lennox: Okay. Great. Wonderful. I'm glad we could get that resolved. Okay. Alright. Thank you.
[00:49:35] Erik Myhre: Yeah. Is that your last slide?
[00:49:36] Jonathan Lennox: I think you have one more slide here. I don't know if you
[00:49:39] Shuaiyang Sun: Oh, it's it's Okay. Yeah. Alright. Yeah.
[00:49:41] Magnus Westland: It's okay.
[00:49:42] Shuaiyang Sun: Yeah. Yeah.
[00:49:42] Jonathan Lennox: And I'll you know, and please also, you know, review and anybody who has any other comments on this, please review the draft. I mean, I assume it's basically going to be the same thing except change that one token and add an updates to the OPUS payload format in the header. Thanks. Okay. Thank you. Alright. Okay. And finally, Magnus, after I do this ridiculous dance. And do you want the clicker?
[00:50:15] Magnus Westland: Yes, please. Alright. There you are. Oh, yeah. So my name is Westland from Ericsson. Me and John here has co authored a draft on the proposal for new cipher suite for SRTP. This is let's see. Yes. This is based on the GCM-SST. So this is Galois counter mode, and SST standing for strong secure tags. It's an AEAD algorithm. It's currently the it's an individual draft in CFRG, and we're to push this towards getting adopted there. It's currently standard for both Etsy and 3GPP. We have two independent security proofs for this. It basically uses it's based on ASGCM. The main change here is that you arrive a set of different keys for the authentication. So you get each AEAD invocation, which in case of SRTP is for each packet. You will get a new authentication key, which changes the behavior. Current ASGCM use the same key for the same master key, independent of the nonces, which creates a weakness is that if you ever manage to forge one authentication tag and can determine that it's been forged, you reveal a lot of the bits. And that's yes, I forgot to update this slide. Down here in the same column for how many forgeries for the second, it's basically it goes towards one that you will get 100% probability of successful forgery. You don't need to do many attempts. So and this GCM-SST construct is then defined for three different underlying algorithms and key lengths. It's a s 128, so 128 bit keys with 128 bit blocks. A s two fifty six, so then two fifty six keys, but 128 bit blocks and Rijndael, which has two fifty six bit keys and two fifty six bit blocks. So when it comes to using this in SRTP, the big advantage here is that you can actually truncate these tags with and have a four d probability of becoming very near ideal with if you're inducing in unicast usage and have replay window, you get the four d probability down to one divided by two up to the power of t, where t is tag length in bits. So it gets low. We're going to discuss how low with the truncated tag in a future slide. When it comes to multicast broadcast use, it also has improved properties compared to ASGCM, but it's not ideal. And the property you get here for this is that you have the SSDs. The successful 40 on one receiver, and you can get an indication that you succeed it, you can reuse it in towards other receivers for the same nonce. Therefore, you can spread the forwarder attempts among the r set of receivers with giving them unique different forwarders to try. And if you have any feedback mechanism that you would trigger, you would be able to detect it and then potentially send it out. So basically, assuming that you have re replay protection, we basically get the property that the expected number of distinct fordiers are number of attempts of forgery times per receiver times the number of receivers divided by two to the power of t. We see these algorithms as a potential replacement for AS728 counter mode with HMAC SHA-one and 32 bit tags. Currently, there are no other algorithms with this short level of tags. The advantage here would be to have AEAD algorithm. And so you can get single pass kind of behaviors and a modern efficient implementations on most platforms. We are proposing to adjust the tag length for modern threat levels. We're currently proposing 48 bits, but we will discuss this on the next slide. And also, if you're using 48 bits for RTP, we're still using 96 bit tags for RTCP. You also get with Rijndael and the bigger blocks, you get the number of decryption invocation before you consider this being too many, is basically moved from two to the power of 54, 48 bit blocks to to the power 118, which so But, yes, let's discuss a bit on what is the appropriate authentication tag if we're going to have kind of short tags for RTP and in use cases where you can accept slightly higher risk for successful forgery, but where you considered it an individual forgery not resulting in a significant issue for for the communication, like in audio where if you would get for, like, twenty milliseconds of audio, it remind me, I will remind you that it's still encrypted. So authentication forgery means that you can flip bits because the encryption is stream ciphers. So it's primarily affecting fields where you know what it is. Flipping the bits blindly on an audio payload and get something useful out of it is not particularly easy. It's more like you probably can be distracted to make it fail or or basically get it into some error containment mode, the codec, because it's considered frame broken or strange. So it can generate some, maybe some noise, etcetera, but, it's still limited. But to read this table, what I've done here is that the packets p 50 line, that's the probability of having 50% probability of successful forgery. This is how many attempts of forgery you need to do for a single nonce with GCM-SST. But I then took this value. I considered a 48 byte packet, so basic IPv4, UDP, RTP, small payload and the indicated authentication taglines. It's so so and yeah, Moe.
[00:57:52] Moe Zanaty: Moe Zanaty, I didn't understand that part. So So I that that encapsulation is already over 48 bytes. What do you what do you mean you can't No. No. No. Payloads?
[00:58:00] Magnus Westland: No. No. So it's 48 plus the authentication tag length.
[00:58:03] Moe Zanaty: Oh, so the payload is 48 bytes.
[00:58:05] Magnus Westland: No. No. The payload is eight bytes. So it's IPV four UDP. RTP is 48. Eight bytes of payloads. Yes. So very the minimal kind of minimal minimal payload, I think, we basically have. Okay. Yeah. So this is very low bit rate codec.
[00:58:22] Jonathan Lennox: But that that proteo bytes does not include the auth tag.
[00:58:24] Magnus Westland: And then you have the authentication tag of the lengths indicated on the column.
[00:58:28] Moe Zanaty: And I have a very, very different question. It's probably not even related to the slots. Maybe I'll just wait for the end.
[00:58:33] Magnus Westland: Yeah. Yeah. So, and then you have the numb the different line is is the amount of dedicated attack traffic. So one gigabit, 100 gigabit of 40 terabit or attack traffic being evaluated by the receiver. So this is the other aspect of this is that so if you actually have a 32 bit tag with SSDs, using one gigabit of attack traffic, it would take you one hundred and twelve seconds for a single nonce to get to 50% probability of successful forwarder. And that is basically then it's 2,000,000,000 packets. So and this is then recounted and it's like, okay, how much time on that is speed is this indicated? So like here over in the 96 column, we're talking about the lot times of length of existent of the universe and a bit longer. So it's it's not a feasible attack to do anything over here, really, on the dark green side. And even with 40 terabits, yes, you're down to two point eight milliseconds. There, actually have something which would be feasible. I think this is, in practice, not feasible unless you have a lot of receivers you can share the load over. But it's there to indicate like this would represent if you have 40,000 different targets at one gigabit, you would actually be able to get something that is feasible. So 32 bits, I think, is too short in some sense. The question is practically because you need to hit the replay window, the roll-over counters are currently being used for that particular SSRC and nonce. You for single nonce, you have a fairly small window in an actual application. I start thinking that 48 looks fairly good here, and that's why we have it.
[01:00:35] Erik Myhre: But
[01:00:35] Magnus Westland: yes, if people want to adjust this to 40 or 56, I'm happy to hear input on that. So but this does assume that you have replay protection. Otherwise, the it will be not as strong. So and also, I mean, if you would actually try attacking with this odd wallets of traffic, what you can do is to monitor the failed decryptions. And if that counter rapidly increases, at least you can warn that the session is under attack. So and I mean, rapidly, I mean, large numbers. A few failed decryption shouldn't trigger any warning because that's very low probability when it's successful. If you start to get, oh, we have a million failed decryptions within a few seconds, yeah, then maybe you should consider warning the user in applications. So yeah. Any feedback on tag lengths or forward you, etcetera, for a shorter tag? 48 bits, does it sound well good?
[01:01:52] Jonathan Lennox: Is this something you think just for audio or I mean, I guess the rates you're having with our video. So
[01:01:57] Magnus Westland: Yeah. It's I mean, it's it's I think it's up to what your if you have a well as long as you have an implementation that's fine and robust against kind of bit flipping and things like that, which basically if you have tested with fuzzing attacks of random bit flipping and things like that, I I wouldn't see it as a problem, because you are attacking a single nonce, and you have fairly low probability. So yeah. But it's it's maybe it's other you need to analyze this from your perspective what happens if I get to forwarder. It's just that with this algorithm, each forwarder takes a certain amount of individual, which is still fairly good on this. It's like it takes quite a lot of effort to attack the 48 bit attack.
[01:02:48] Jonathan Lennox: So
[01:02:49] Moe Zanaty: Moe? Yeah. Moe Zanaty. The thing that makes me wonder whether or not you should have the 32 is that the people that chose thirty two for audio were not overly concerned with security. That's how they arrived at 32. They were they're overly concerned about about overhead. Right?
[01:03:05] Magnus Westland: Yep.
[01:03:05] Moe Zanaty: And so try to convince those people to go to 48. Maybe it wins. But if you have something stronger at 32, it's a clear win. Right? There's it's a slam dunk. There's no reason why they would ever resist that.
[01:03:17] Magnus Westland: I don't think this is really stronger compared to HMAC when truncated 32. John, you No.
[01:03:24] John Preuß Mattsson: Yeah. It's Compared to HMAC is equally strong. It's yes. GCM has quite a lot of different weaknesses. HMAC is actually quite strong. You it behaves like an ideal MAC, and so does GCM SST. So
[01:03:42] Moe Zanaty: if It
[01:03:45] John Mattsson: would be it would be twice the performance. This is as fast as a AES-GCM, which is typically twice as fast as counter
[01:03:56] Moe Zanaty: Real quick question on that point. From what I understood, you you're you're revving the key with each nonce? Yes. But you are you still able to use the hardware crypto for the for that?
[01:04:06] John Mattsson: You not if you have GCM hardware, then you need new you can use the the AES hardware, you can if you have dedicated hardware, the ASIC for GCM, you probably have to redo it. If you have a processor like Intel or ARM, this is as fast as GCM. You can do the instructions in that CPU to to accelerate this as similar to GCM.
[01:04:33] Erik Myhre: Is it well,
[01:04:33] Jonathan Lennox: it's one additional ECB operation per packet. Is that right?
[01:04:37] John Mattsson: It's two additional. You derive GCM has one authentication key. Mhmm. The GCM SSD derives two authentication key, and it derives them for each package. So there's two extra. So if you have if you have, like, thousand byte, it doesn't matter. If you have very, very small packages or yeah. Then you get your overhead.
[01:05:04] Erik Myhre: Yeah. Okay.
[01:05:08] Magnus Westland: Yeah. Okay. Yeah. Yeah. Okay. You work. So, yeah, I we're here to basically see what interest is because our step now is to push this in CFRG for being adopted there. And there, it's good to show that there exists interests. And then we can come back and do the work here for actually defining the Cypher Suite for SRTP. So that's kind of the what we see as the way forward. But we have considering where GSM SST is now being standardized in ETSI and 3GPP with the security proofs, etcetera, we this is the time for us to kind of go for completing the set and enable it for use. I think this is one use where where it makes a lot of sense. So
[01:06:09] John Mattsson: Yeah. And, yeah, and in addition to input on on tag lengths, we would be open to any CFRD suggestion to make changes to the I would say, 3GPP has already standardized their variant with all the 3GPP telecom inputs. Like, this is the CFRG draft is a byte oriented with some changes that we got from CFRG already, and we would we have no problems changing anything more. It's not like we want to push the the three d p p output standard.
[01:06:51] Moe Zanaty: Yeah.
[01:06:54] Magnus Westland: Hi. I think we'd be supportive of this work. One of the things that have stopped us from using authenticated, like, the AEAD mechanisms is the truncation of the tags is not possible. So this opens up opens up that, so we're happy with that. I would kind of second most point that if we can also put the 32 bit tag as one of the cipher suite opt options, saying that it's, like, no less secure than HMAC SHA one thirty two Mhmm. Then the adoption story becomes, like, simpler. Yeah.
[01:07:32] Magnus Westland: Yeah. Okay. Yep. So that's I mean, it's easy for us to update our draft here to enable because, basically, what the only resource you're burning here because it's truncation is the different okay. How much are you truncating? And that uses up CypherSuite identifiers basically for the DTLS-SRTP and and things like that. And they are unlimited from one sense, and it's it's up to your implementation. Just support the ones you want to you see need. So I think it's it's having some different options is not a problem. Okay?
[01:08:11] Moe Zanaty: To follow-up on our discussion after the quick presentation, I'm still not 100% sure why you don't have the full length tags also. The six the full 16 Mhmm. Tags as as another possibility because then it would kind of be a full replacement for all of
[01:08:27] Jonathan Lennox: the current side disputes that are insecure against 40%.
[01:08:30] John Mattsson: Yeah. So the reason is that, like, if you look at the the numbers here on on GCM and and Poly, you you can see that you don't get the full tag length. And GCM SST is a little bit similar. So if you have the full tag length, you actually it's it gives a full sense of security. You only get 96 or a 112. So but we are based on what NIST is doing right now with Rijndael and Byde, I'm actually in the next version, I'm planning to make Rijndael with a hash that can support 128 with full security. But that comes with a performance overhead, Rijndael, and that would probably have twice to you can use the same, but you get maybe you get 100%. It's 50% of the performance of AES with the hash, but then then you get that. So I think that will be coming in the next version in a
[01:09:37] Magnus Westland: month or so.
[01:09:38] Jonathan Lennox: Actually want Yes.
[01:09:38] Magnus Westland: Just to clarify what Moe and I discussed was that if you're looking at this lowest row, I will update the slides to fix this formatting error. But down here, you see it's two to the power 117. So this is with 128 bit tag. You actually just get 117 bits authentication performance for that 128 bits. And if you compare this with the 14 bits where we get actually 14 byte, we get the 112 byte actual performance out of it when it's truncated. So those extra two bytes gives very, very little.
[01:10:13] Moe Zanaty: So I think the short answer to my question was that that there's no practical benefit for the for the extra for the full length off tags.
[01:10:22] Magnus Westland: No. Not in this not for SSD. I think if if if yeah. For this ASGCM, it might be slightly different. But
[01:10:32] Moe Zanaty: But my question is really for more crypto unaware developers.
[01:10:37] John Mattsson: Yeah.
[01:10:37] Moe Zanaty: Just picking a cipher suite. Yeah. You if they saw something that's an identical match to what they were using and says it's stronger, they would easily use it. But now it's, oh, wait. I have a shorter, you know, tag. Am I truncating? I weaker? You know, that's what I worry about, that people resist making this transition because they don't see an identical, you know, target to go to.
[01:10:57] Jonathan Lennox: Yeah.
[01:10:58] John Mattsson: Yeah. So how they work mathematically is that in GCM, irrespective you get the tag length minus the length of the message and authenticated data in blocks.
[01:11:10] Magnus Westland: Yeah.
[01:11:10] John Mattsson: With GCM-SST, as long as you follow some mathematical boundaries, you get the instead, you get the full tagline, but it it collapses if you have two long taglines. So but but, yeah, I I agree. People will people think they are getting 128 bit secure taglines and 120, and they will will be skeptical. But I think we will we will have so much such a option, but I I don't think we want to have any tag lengths that doesn't actually give that security. I think that's a wrong thinking in in the past that depending on the algorithm. So I think we will avoid that.
[01:11:51] Moe Zanaty: Mhmm. So the educated authors
[01:11:53] Magnus Westland: Yeah. Yeah.
[01:11:56] Alan Ford: My goodness. My brain's not had enough coffee.
[01:11:59] VDMC Presenter: Okay.
[01:11:59] Alan Ford: What does the last line actually say in your table?
[01:12:04] Magnus Westland: It's GCM. Yeah. I've got half of it. And then Which has 16. 16 bytes of tag. Yep. Yep. It says, this is two to the power of 117.
[01:12:17] John Mattsson: Two to 16.
[01:12:18] Magnus Westland: It's under 16. Yeah. Okay. Right. Yes. And this is one. Yeah. And then it's v squared divided by two to the power of 17. So That's okay. Yeah. Right.
[01:12:31] Alan Ford: And I guess my other question is, did you get what you needed to try and tell CFRJ that there is interest here? Or do you need something more from
[01:12:40] Magnus Westland: this group? No. John, I think we've I think we're we have something. We got something from Quick. We got some indication of in in in interest, and I think also from here to show that we can have and Yeah. So
[01:12:53] John Mattsson: Yeah. I I think we can go to both of these groups and say that to see if I can say there is interest in these groups and also very clear that you want to do it. So we I will address them in the next.
[01:13:07] Magnus Westland: Okay. Sounds good. Yeah. Thank you.
[01:13:11] Jonathan Lennox: Yeah. So yeah. So I think we still need to work out exactly which taglines people want. We don't wanna have too many because you don't wanna but because that hurts in a drop, but we wanna have everything people actually need. So yeah. Then definitely, I'd say, tell CFRtp there's interest. Right. In which case, I believe that was our last presentation. Just make sure we got through all the slides there. Yeah. Okay. Yeah. So the answer is yes, and we'll figure that out. And here's the Ericsson logo because everybody likes slashes.
[01:13:44] Magnus Westland: Alright. Or sausages.
[01:13:46] Jonathan Lennox: Or sausages. Okay. Yeah. Well, we're in Vienna. We have to have sausages. Right? Alright. So I think that was everything on our agenda. So I guess I can just put the chair slides back up so I make sure I remember so we can go over back over what we did and figure out. Okay. So frame acknowledgement, Eric is still working on that. He has known issues continuing to go through open issues. VDMC, we think, is ready for working to blast calls, so we'll start that soon. Opus MultiStream, the authors are going to resubmit it as Opus slash six, etcetera, versus multi Opus, and then we'll do a call for adoption and GCM-SST. The authors are going to go to CFRG and say, yes. There's interest from this work group. Is there any other business anybody wants to talk about? Do any authors of expired drafts wanna stand up and say, I'm gonna submit a new version soon. Otherwise, thank you all, and see you around the IATF. And see you in San Francisco virtually or physically.
[01:15:01] Erik Myhre: Thank you all. Have a nice day. Mhmm.
[01:15:06] Jonathan Lennox: Oh, I guess one other thing. The last interim we did was not terribly successful. We only had one presentation. So I think we'll probably do a call to ask if people are interested in the interim, but we won't assume there will be because we don't know. Because, like I said, the last one, we didn't have we had one presentation and, like, five people there, so that was not very successful. But we'll do a call to see if people are interested in interim before San Francisco, or rather we'll just do a do do the next session in San Francisco. Alright. Thank you all.
[01:15:51] Magnus Westland: I have to look for both.
[01:15:53] Jonathan Lennox: Slow at the finances. Oh, good. Thank you.