IETF
avtcore@jabber.ietf.org
Friday, November 12, 2021< ^ >
Jonathan Lennox has set the subject to: IETF AVTCore Working Group
Room Configuration
Room Occupants

GMT+0
[11:30:01] Meetecho joins the room
[11:35:02] alexamirante joins the room
[11:45:07] MikeFaller_web_280 joins the room
[11:45:07] Mathis Engelbart_web_451 joins the room
[11:45:07] Paolo Saviano_web_832 joins the room
[11:49:24] Waqar Zia_web_781 joins the room
[11:51:12] Jonathan Lennox_web_744 joins the room
[11:51:13] Bernard Aboba_web_406 joins the room
[11:52:29] Ted Hardie_web_656 joins the room
[11:53:02] Jan-Ivar Bruaroey_web_678 joins the room
[11:53:10] Bernard Aboba_web_406 leaves the room
[11:53:14] Bernard Aboba_web_791 joins the room
[11:53:51] Shuai Zhao_web_644 joins the room
[11:54:13] Nick Banks_web_529 joins the room
[11:55:07] Kazuaki Ueda_web_608 joins the room
[11:55:17] Daniel Hanson_web_814 joins the room
[11:55:34] Youngkwon Lim_web_859 joins the room
[11:57:11] Youenn Fablet_web_208 joins the room
[11:57:21] Daniel Hanson_web_814 leaves the room
[11:57:39] Joerg Ott_web_551 joins the room
[11:58:07] Daniel Hanson_web_282 joins the room
[11:58:32] Spencer Dawkins_web_337 joins the room
[11:59:03] Timothy Panton_web_375 joins the room
[11:59:33] Murray Kucherawy_web_448 joins the room
[11:59:36] Tim Bruylants_web_306 joins the room
[11:59:57] Daniel Hanson_web_282 leaves the room
[12:00:01] Renan Krishna_web_491 joins the room
[12:00:02] James Gruessing_web_549 joins the room
[12:00:13] Stephan Wenger_web_821 joins the room
[12:00:38] Ludovic Roux_web_994 joins the room
[12:00:39] Sergio Garcia Murillo_web_954 joins the room
[12:00:46] Hiroyuki Goto_web_288 joins the room
[12:00:53] Yago Sanchez_web_824 joins the room
[12:01:07] Harald Alvestrand_web_176 joins the room
[12:01:08] Colin Perkins_web_516 joins the room
[12:01:08] Daniel Hanson_web_198 joins the room
[12:01:10] Rohit Abhishek_web_327 joins the room
[12:01:14] Atsushi Tagami_web_510 joins the room
[12:01:15] Mike English_web_856 joins the room
[12:01:16] Mihail Zverev_web_547 joins the room
[12:01:48] Stephan Wenger_web_821 leaves the room
[12:01:49] Daniel Hanson_web_198 leaves the room
[12:01:52] Stephan Wenger_web_121 joins the room
[12:02:14] Youngkwon Lim_web_859 leaves the room
[12:02:21] Roni Even_web_535 joins the room
[12:02:36] Youngkwon Lim_web_993 joins the room
[12:02:49] Mo Zanaty_web_532 joins the room
[12:02:56] David Baldassin_web_613 joins the room
[12:03:04] Daniel Hanson_web_503 joins the room
[12:03:27] Martin Langer_web_201 joins the room
[12:03:48] Youngkwon Lim_web_993 leaves the room
[12:03:50] Ali Begen_web_701 joins the room
[12:04:08] Youngkwon Lim_web_278 joins the room
[12:04:26] Suhas Nandakumar_web_251 joins the room
[12:04:35] Martin Langer_web_201 leaves the room
[12:05:09] Mike English_web_856 leaves the room
[12:05:13] Mike English_web_627 joins the room
[12:05:22] Justin Uberti_web_616 joins the room
[12:06:27] Roland Jesske_web_923 joins the room
[12:07:17] Hiroyuki Goto_web_288 leaves the room
[12:09:58] Ali Begen_web_701 leaves the room
[12:10:02] Ali Begen_web_669 joins the room
[12:11:03] Justin Uberti_web_616 leaves the room
[12:11:07] Justin Uberti_web_656 joins the room
[12:11:13] Giles Heron_web_816 joins the room
[12:11:18] Justin Uberti_web_656 leaves the room
[12:11:22] Justin Uberti_web_908 joins the room
[12:11:43] Giles Heron_web_816 leaves the room
[12:11:47] Giles Heron_web_834 joins the room
[12:11:51] Giles Heron_web_834 leaves the room
[12:11:55] Giles Heron_web_750 joins the room
[12:13:15] Mike English_web_627 leaves the room
[12:13:19] Mike English_web_813 joins the room
[12:13:51] Ching-Heng Ku_web_862 joins the room
[12:16:16] Roland Jesske_web_923 leaves the room
[12:16:20] Roland Jesske_web_912 joins the room
[12:19:12] <Joerg Ott_web_551> This is probably a more general conversation.
[12:19:24] <Joerg Ott_web_551> (re W3C liaison statement)
[12:19:35] <Joerg Ott_web_551> and one that may not have quick answers
[12:22:02] <Joerg Ott_web_551> @Harald: we can certainly add a few words. It's not mandatory, but it could be dome
[12:22:11] <Colin Perkins_web_516> +1 to Harald: I also don't understand that design choice
[12:22:59] <Joerg Ott_web_551> We do RTP muxing on a single UDP pot
[12:23:00] <Sergio Garcia Murillo_web_954> +1 not sure what "rtp session" means in this context either
[12:23:07] <Joerg Ott_web_551> why should we now be worse off?
[12:23:53] <Joerg Ott_web_551> Which I believe we use consistently; if not then this is a mistake
[12:24:04] <Joerg Ott_web_551> (@Colin)
[12:24:09] <Stephan Wenger_web_121> "sessions" again.  Didn't we have that before? :-)
[12:25:26] <Spencer Dawkins_web_337> That's definitely a clarification that needs to happen - making sure we're clear on what a bundle looks like when it's mapped into QUIC datagrams, for example.
[12:25:29] <Colin Perkins_web_516> @Jörg realise you know the definition, just confused how it's being used here and why this is the right split.
[12:26:16] <Suhas Nandakumar_web_251> BUNDLE in RTP uses mid RTP header extension, not sure if that's waht was meant
[12:26:35] <Joerg Ott_web_551> @Colin Let me revisit the tet to make sure this is actually correct
[12:26:45] <Justin Uberti_web_908> overhead of QUIC packetization is definitely something we'll want to look closely at here and try to minimize vis-a-vis RTP.
[12:27:29] <Justin Uberti_web_908> that said, it might be possible to save bytes with a different packetization of MIDs.
[12:28:02] <Sergio Garcia Murillo_web_954> so the idea is to send mids in the flowids instead of in the header extensions?
[12:28:28] <Joerg Ott_web_551> yes; then your demuxing isn't limited to RTP packets
[12:29:01] <Justin Uberti_web_908> possibly? we'd need to look at the savings there to see if this makes sense
[12:29:02] <Joerg Ott_web_551> QUIC DATAGRAMS could also be used for non-RTP protocols after all
[12:29:07] <Suhas Nandakumar_web_251> it also depends on what is the flowId/Mid is used to map to ?
[12:29:16] <Sergio Garcia Murillo_web_954> but on an rtp session you can only send rtp packets.. :)
[12:29:29] <Spencer Dawkins_web_337> Joerg - people using RTP with other data is something that keeps coming up on the MOQ mailing list.
[12:30:03] Yago Sanchez_web_824 leaves the room
[12:30:07] Yago Sanchez_web_255 joins the room
[12:30:08] <Spencer Dawkins_web_337> And you can also send streams and datagrams on the same QUIC connection, no?
[12:30:10] Waqar Zia_web_781 leaves the room
[12:30:16] <Joerg Ott_web_551> sure
[12:30:25] <Justin Uberti_web_908> receive timestamps in QUIC: https://datatracker.ietf.org/doc/draft-smith-quic-receive-ts/
[12:30:32] <Colin Perkins_web_516> @sergio an RTP session, by definition is only sending RTP packets. We often mux other types of traffic on the same ports though
[12:30:33] <Sergio Garcia Murillo_web_954> yes, but that would be to differentiate rtp data from other no-rtp data
[12:30:40] <Joerg Ott_web_551> Yep, we are aware of the rx ts
[12:31:08] <Joerg Ott_web_551> a previous draft didn't quite exactly do what rtcp did, though, if my memory serves me wel
[12:31:10] <Sergio Garcia Murillo_web_954> but you don't need the flow id for demultiplexing rtp sessions on bundling (except if we reuse the flow id as mid to potentially save a couple of bites)
[12:31:35] <Colin Perkins_web_516> bundle is all one RTP session, no?
[12:31:45] <Jonathan Lennox_web_744> Yes
[12:32:05] <Sergio Garcia Murillo_web_954> yes. my bad, wrong wording
[12:32:27] <Justin Uberti_web_908> yep, this is the core problem here
[12:33:33] <Justin Uberti_web_908> strange that lower delay results in a worse rampup behavior
[12:33:48] <Spencer Dawkins_web_337> @Justin - agree. Making sure we all have the same understanding of a bundle, was a real issue in CLUE, I think.
[12:34:00] <Joerg Ott_web_551> @Justin & Spencer: one terminology issue may be that we reused the BUNDLE syntax for signaling
[12:34:31] <Suhas Nandakumar_web_251> https://datatracker.ietf.org/doc/html/rfc7656#section-2.2.2 might come handy ?
[12:34:36] <Spencer Dawkins_web_337> Joerg - thanks for the background.
[12:34:38] <Joerg Ott_web_551> Didn't want to reinvent new SDP for that; but the actual demuxing doesn't happen at the RTP layer. Agree that this may be confusing
[12:34:59] <Joerg Ott_web_551> (hey, this is just -01 :-)
[12:35:07] Magnus Westerlund_web_623 joins the room
[12:36:00] <Justin Uberti_web_908> it would be nice to not have all the same data as RTP here - the receive-ts doc might be just what we need though
[12:36:43] <Joerg Ott_web_551> This is what I hope for. We experimented with a number of different interpolation schemes and what is presented worked best so far
[12:37:13] <Justin Uberti_web_908> I meant to say, "it would be nice to have the same data as RTP here"
[12:37:13] <Spencer Dawkins_web_337> @Justin, I think that's one of the design choices - how much QUIC can provide the same/better feedback as RTCP.
[12:37:48] <Joerg Ott_web_551> Yes, trying not replicate RTCP feedback and giving off QUI. So, if QUIC can deliver rx ts then great
[12:39:48] <Spencer Dawkins_web_337> I was talking about feedback mechanisms in https://www.ietf.org/archive/id/draft-dawkins-sdp-rtp-quic-questions-01.html#name-feedback-mechanisms
[12:40:40] <Joerg Ott_web_551> we are measuring overhead but the detailed analysis is still outstanding
[12:40:54] <Joerg Ott_web_551> (@Justin)
[12:41:05] <Justin Uberti_web_908> :thumbsup:
[12:41:24] <Sergio Garcia Murillo_web_954> i will type my quesitons
[12:41:28] <Colin Perkins_web_516> seems clear that a lot of RTCP and the RTP headers is redundant over QUIC
[12:41:30] <Sergio Garcia Murillo_web_954> as audio seems not to be working
[12:41:56] <Sergio Garcia Murillo_web_954> first, awesome work, is there any way to replicate the results and contribute?
[12:43:40] <Joerg Ott_web_551> @Colin: we can do mostly without RRs and also SRs; but this depends of course on the detailed configuration
[12:44:01] <Joerg Ott_web_551> of the experiment; in the process of assessing their respective overheads
[12:44:31] <Joerg Ott_web_551> RTP headers: well, media timestamps won't be redundant, seq# surely are unless you need them for media specific repair
[12:44:55] <Colin Perkins_web_516> But also SDES and BYE are not needed, given the parallel QUIC signalling.
[12:45:12] <Joerg Ott_web_551> @Sergio: this is exploratory work towards understanding possible interplays between RTP and QUIC, so there is a long way to go stil
[12:45:34] <Jonathan Lennox_web_744> Well insofar as you have more than one stream you can't use QUIC sequence numbers for stream sequencing?
[12:45:35] <Justin Uberti_web_908> it's not clear to me that seqnums are necessarily redundant since you may want separate global seqnum for CC and individual CC for each SSRC
[12:45:45] <Sergio Garcia Murillo_web_954> @joerg for sure, i think the work you have done is great!
[12:45:47] <Justin Uberti_web_908> (individual seqnum)
[12:46:20] <Colin Perkins_web_516> SSRC and seqnu can be redundant, and PT, etc., depending on how the mapping onto QUIC is done.
[12:46:48] <Joerg Ott_web_551> please join for moving this forward; there are many things to sort out. Open source to come
[12:47:16] <Justin Uberti_web_908> happy to help here
[12:47:23] <Colin Perkins_web_516> +!
[12:47:23] <Jan-Ivar Bruaroey_web_678> Thanks Bernard
[12:47:27] <Colin Perkins_web_516> +1, even
[12:47:31] <Sergio Garcia Murillo_web_954> always happy to work on bwe/cc :)
[12:47:45] <Joerg Ott_web_551> Re redundancy: there is probably a short term and a mid term design approach here; the mid-term is more the future of media over a revised/extended QuIC (as Christian pointed out in MOQ)
[12:47:52] francesca joins the room
[12:48:02] <Colin Perkins_web_516> @Jörg definitely
[12:48:33] <Joerg Ott_web_551> We are trying out the short-term thing first to understand where we are and how far that carries
[12:48:46] <Justin Uberti_web_908> the short term is just stuffing RTP packets into datagrams, ideally in the long term we would feel like we can get close to parity regarding overhead and packet rate
[12:48:49] <Joerg Ott_web_551> Hope this can evolve into the mid-term (conceptually)
[12:49:14] <Joerg Ott_web_551> @Justin: then we try to be a bit better than very short term
[12:50:17] <Joerg Ott_web_551> @Colin: +1
[12:52:50] francesca leaves the room
[12:54:22] <Spencer Dawkins_web_337> +1 to short term/medium term
[12:54:35] Atsushi Tagami_web_510 leaves the room
[12:56:28] <Spencer Dawkins_web_337> My extreme apologies -I was trying to get out of the queue because the chairs were moving on
[12:56:37] <Jonathan Lennox_web_744> Ok, no worries.
[12:58:43] <Spencer Dawkins_web_337> @Jonathan and @bernard - my impression is that what we're talking about here is fundamentally different from much of the MOQ discussion, especially for the short-term topic. Would it make sense for you to suggest that the short term RTP over QUIC discussion move onto the AVT list?
[12:59:51] <Roni Even_web_535> I think the chairs can ask for early security and transport reviews
[13:00:06] <Roni Even_web_535> If important
[13:00:29] <Jonathan Lennox_web_744> Spencer: That sounds good to me.
[13:00:45] <Jonathan Lennox_web_744> I'll mention it in AOB at the end of the session.
[13:02:26] <Spencer Dawkins_web_337> @Jonathan, thank you.
[13:04:11] <Justin Uberti_web_908> @spencer, I see what you suggest as the best path to get actual traction on this effort. It would also be good to see if anyone feels that this sort of QRTP-ish approach doesn't solve their problems, as that might suggest alternative directions.
[13:04:51] <Spencer Dawkins_web_337> @Justin, that seems exactly right to me.
[13:04:59] <Ali Begen_web_669> roq vs. moq Spencer. I'd also prefer keeping roq discussions in avt.
[13:05:26] <Roni Even_web_535> In the past the video conferencing industry were using interop events for testing offer answer
[13:06:59] <Roni Even_web_535> There will always be interposed problems . Hopefully they will find where to discuss. Major points were about receiver or sender parameters
[13:10:52] <Roni Even_web_535> I think the VVC section 7.2.2 is good enough
[13:13:50] <Magnus Westerlund_web_623> I thought the whole Security review comments had died down after RFC 7202 was published, and that it is mostly to reference that document to tell SecDir reviewers that their comments are not relevant for this document.
[13:19:38] <Roni Even_web_535> Agree with Magnus
[13:22:06] james welch_web_682 joins the room
[13:24:45] <James Gruessing_web_549> It sounds like they want an RFC to refer on RFPs and procurement documents.
[13:31:43] <Spencer Dawkins_web_337> I think that's "opaque", more than "clear" ...
[13:32:33] <Ted Hardie_web_656> I just requested the listed document via email (from my gmail account).  If that works, then I don't see the same issue being present.
[13:34:32] <Magnus Westerlund_web_623> +1 to Colin's point. This has been done, and should continue to be done.
[13:34:48] <Roni Even_web_535> +1 to Colin
[13:36:53] <Roni Even_web_535> To add to Colin, during wglc there should be some input from people in the scip approving
[13:39:34] Magnus Westerlund_web_623 leaves the room
[13:39:38] Magnus Westerlund_web_788 joins the room
[13:40:33] Daniel Hanson_web_503 leaves the room
[13:40:59] james welch_web_682 leaves the room
[13:45:25] <Murray Kucherawy_web_448> On the previous document, if access to the referenced document can be secured, I agree that this should seek PS.
[13:46:35] Mike English_web_813 leaves the room
[13:46:39] Mike English_web_597 joins the room
[13:53:13] <Colin Perkins_web_516> The negotiation of the PT does, I think, tell you something about whether the payload is encrypted.
[13:53:26] Rohit Abhishek_web_327 leaves the room
[13:53:34] <Magnus Westerlund_web_788> The payload type needs to represent what is actually the payload format on RTP payload level.
[13:53:49] <Colin Perkins_web_516> The payload format definitions specify non-encrypted content
[13:54:01] <Justin Uberti_web_908> sure, but there is precedent for this sort of thing with "red", etc
[13:54:36] <Colin Perkins_web_516> sure, but that's a wrapper payload format
[13:55:09] <Justin Uberti_web_908> one could argue this is a wrapper of sorts as well
[13:55:13] <Jonathan Lennox_web_744> Well, is SRTP a wrapper?
[13:55:26] <Colin Perkins_web_516> @justin: yes
[13:55:36] <Jonathan Lennox_web_744> This seems like the same kind of thing as SRTP, which we treated as a profile.
[13:55:57] Fatima Zarinni_web_992 joins the room
[13:56:09] <Magnus Westerlund_web_788> SRTP is not a wrapper payload format as it affects not only the RTP payload, but also other things
[13:56:38] <Magnus Westerlund_web_788> Like RTCP, and replay protection that affects if RTP packets should be counted at all
[13:56:46] Shuai Zhao_web_644 leaves the room
[13:56:47] <Justin Uberti_web_908> it basically tells you to take these X additional steps
[13:57:04] <Justin Uberti_web_908> which is not that dissimilar from what is being discussed here
[13:57:55] <Magnus Westerlund_web_788> Justin, but it doesn't stay in one place in the process, it shows up in several places. a wrapper payload format I think need to exist one specific place in the send and receive chain.
[13:58:07] Nicholas Gajcowski_web_811 joins the room
[13:59:07] <Stephan Wenger_web_121> +1 to Mo&Colin
[13:59:20] Jinyou Dai_web_710 joins the room
[13:59:56] Jinyou Dai_web_710 leaves the room
[14:00:20] <Justin Uberti_web_908> the key difference here is just whether there is a specific wrapper PT that carries the wrapped PT?
[14:00:28] <Magnus Westerlund_web_788> I think encapsualting the original RTP paylaod format is the easiest, and thus have the PT indicate either SFRAME or SFRAME with Internal format X.
[14:01:03] <Colin Perkins_web_516> There's a wrapper payload format that's signalled, and assigned a PT.
[14:01:22] <Jonathan Lennox_web_744> The model would be like the model for rtx, where you say that PT 111 is VP8-over-SFrame.
[14:01:45] <Spencer Dawkins_web_337> ISTM that this discussion is relevant to RTP being encapsulated in QUIC, which is going to be encrypted.
[14:01:56] <Colin Perkins_web_516> PT 111 is sframe, with the wrapped content being VP8
[14:02:12] Roland Jesske_web_912 leaves the room
[14:02:47] <Magnus Westerlund_web_788> Spencer, it doesn't matter that QUIC is encrypted, SFRAME is object security for the media and needs to support multiple hopes, and it doesn't matter if the transport encryption is QUIC or SRTP..
[14:02:48] <Jonathan Lennox_web_744> There are signaling issues to handle to handle PT exhaustion issues, and also the ability to say "I'm willing to receive sframe-wrapped VP8, but not straight VP8".  But those should be tractable.
[14:02:52] <Justin Uberti_web_908> the problem is that we want to apply SFRAME packetization rather than VP8 packetization
[14:02:59] Ted Hardie_web_656 leaves the room
[14:03:40] Giles Heron_web_750 leaves the room
[14:03:44] Giles Heron_web_994 joins the room
[14:03:47] <Justin Uberti_web_908> (ie so that we can encrypt before packetization)
[14:03:53] <Spencer Dawkins_web_337> @Magnus, thank you. That's helpful. I was planning to reuse profiles in my SDP draft for this.
[14:04:02] Youenn Fablet_web_208 leaves the room
[14:04:06] Youenn Fablet_web_472 joins the room
[14:04:59] Yago Sanchez_web_255 leaves the room
[14:05:10] Timothy Panton_web_375 leaves the room
[14:05:38] <Justin Uberti_web_908> +1
[14:05:42] <Colin Perkins_web_516> sure
[14:05:48] <Suhas Nandakumar_web_251> +1
[14:06:36] <Spencer Dawkins_web_337> Thank you!
[14:06:38] alexamirante leaves the room
[14:06:40] <Tim Bruylants_web_306> thanks all
[14:06:48] <Roni Even_web_535> Thx
[14:06:48] Nick Banks_web_529 leaves the room
[14:06:56] Ching-Heng Ku_web_862 leaves the room
[14:06:58] David Baldassin_web_613 leaves the room
[14:06:59] Murray Kucherawy_web_448 leaves the room
[14:07:02] Mihail Zverev_web_547 leaves the room
[14:07:03] Renan Krishna_web_491 leaves the room
[14:07:05] Tim Bruylants_web_306 leaves the room
[14:07:06] Mike English_web_597 leaves the room
[14:07:10] Justin Uberti_web_908 leaves the room
[14:07:11] Colin Perkins_web_516 leaves the room
[14:07:13] Magnus Westerlund_web_788 leaves the room
[14:07:14] Jonathan Lennox_web_744 leaves the room
[14:07:17] Ludovic Roux_web_994 leaves the room
[14:07:25] Stephan Wenger_web_121 leaves the room
[14:07:27] Giles Heron_web_994 leaves the room
[14:07:27] Youenn Fablet_web_472 leaves the room
[14:07:28] Fatima Zarinni_web_992 leaves the room
[14:07:31] Harald Alvestrand_web_176 leaves the room
[14:07:33] James Gruessing_web_549 leaves the room
[14:07:34] Sergio Garcia Murillo_web_954 leaves the room
[14:07:35] Joerg Ott_web_551 leaves the room
[14:07:38] Bernard Aboba_web_791 leaves the room
[14:07:39] Suhas Nandakumar_web_251 leaves the room
[14:07:39] Joerg Ott_web_105 joins the room
[14:07:44] Jan-Ivar Bruaroey_web_678 leaves the room
[14:07:44] Ali Begen_web_669 leaves the room
[14:07:47] Mathis Engelbart_web_451 leaves the room
[14:07:47] Roni Even_web_535 leaves the room
[14:07:54] Nicholas Gajcowski_web_811 leaves the room
[14:08:10] Kazuaki Ueda_web_608 leaves the room
[14:08:12] MikeFaller_web_280 leaves the room
[14:08:12] Paolo Saviano_web_832 leaves the room
[14:08:12] Mo Zanaty_web_532 leaves the room
[14:08:12] Spencer Dawkins_web_337 leaves the room
[14:08:12] Youngkwon Lim_web_278 leaves the room
[14:08:12] Joerg Ott_web_105 leaves the room
[14:16:26] Meetecho leaves the room