Minutes interim-2022-avtcore-04: Thu 16:00
|Meeting Minutes||Audio/Video Transport Core Maintenance (avtcore) WG|
|Date and time||2022-12-15 16:00|
|Title||Minutes interim-2022-avtcore-04: Thu 16:00|
Audio/Video Transport Core Maintenance (avtcore) Working Group
CHAIRS: Jonathan Lennox
Virtual Interim Agenda
Date: Thursday, December 15, 2022
Time: 08:00 - 10:00 Pacific Time
Notes by: Mo Zanaty, Spencer Dawkins
1. Preliminaries (Chairs, 15 min)
Note Well, Note Takers, Agenda Bashing, Draft status, CfAs
- Note-takers were dragooned, and the Note Wells were noted (Really
- The agenda escaped unbashed
- Jonathan provided draft status and pinged authors for updated draft
versions on the call
- Action Item for Chairs approve the adopted v3c draft (this got
fumbled a bit).
- Action done: V3C WG draft posted:
2. RTP Control Protocol (RTCP) Messages for Green Metadata (Yong He, 10 min)
Yong gave a brief overview of these messages and replied to comments
received during Call For Adoption.
Jonathan requested "no bikeshedding about names on this call"
- Stephan pointed out that the current name (Green Metadata) is
already known in the ISO community
- Can seek comments on renaming the draft on the list.
- Is saving 32 bits per FCI entry worth it? We think not
- Does the media sender need to do anything if it reduces resolution
or frame rate due to congestion? No, the sender has provided a
maximum, and as long as the sender stays under the maximum, no
action is required
- Action Item for Authors The authors have an action to submit a
working group version after closing on the title in mailing list
3. MAX_STREAMS and the Frame/Stream Model (B. Aboba, 10 min)
- Bernard has filed an issue for the WebTransport API (#446) to allow
the application to influence MAX_STREAMS, and added an issue for
RTP over QUIC about whether we need to provide a warning in our
RTP streams on a single QUIC stream) - await() is blocking, so don't
- Is MAX_STREAMS limit a problem? Most likely if you aren't closing
streams and cleaning up resources.
- Conferencing looks like the most obvious place where we could have a
problem, with more and more simultaneous video streams being
- Mo - is MAX_STREAMS about a limit on maximum stream ID, or about
maximum open streams?
- Stream ID numbers are not reusable unless you close and reopen a
- Action Item for Mo Zanaty Mo takes an action to follow up on
details here. (Answer: maximum number of streams, including closed
- Chromium apportions bandwidth based on the number of open streams,
so close streams you're not using them.
- There may be a reason to add a note in our spec about this.
4. Scoping for RTP over QUIC (J. Ott, M. Engelbart, S. Dawkins, 20 min)
- Planned Usages:
- Action Item for Authors : Authors to discuss planned usages on
the mailing list.
- Bernard Aboba questions whether SIP and WebRTC are planned usages.
SIP implementations are slow to change; took a long time to deploy
SIPS: in handsets, PBXes, SIP trunking. P2P QUIC had an origin trial
in Chromium based on the ORTC API, but no current implementations.
So may be better to think of Web applications, rather than just
- Jonathan Lennox notes that some people (notably Jonathan Rosenberg)
hoped to evolve SIP deployments to better use web infrastructure.
- Peter Thatcher notes that leveraging web (not WebRTC) infrastructure
is a good goal. Mobile apps doing voice and video should also be a
planned usage, separate from "SIP" or Web.
Stephan Wenger agrees with Peter's point. ALso, the slide is overly
standards-centric. Define use cases based on applications, not call
control etc. standards. Still want a drop-in replacement for RTP
over UDP without standardized call controls, as this is what large
segments of the industry are using.
- Roman Shpount suggests to stay away from multicast which complicated
RTP. Demux of multiple RTP streams over a single "channel" needs to
Jonathan Lennox does not see a need to mention all topologies, but
just mention those that will be in scope for RTP over QUIC.
- Action Item for Authors : Authors to ask on the AVTCORE
mailing list if anyone is interested in the timestamp extension.
- Bernard Aboba notes IETF WEBTRANS WG could not make the timestamp
extension mandatory or even recommended in WebTransport, since it is
not widely implemented. However, W3C WebTransport is interested in
it, since it can enable estimation of the one-way delay, which the
application couldn't otherwise get at. This can be helpful for
asymmetric networks (e.g. cable internet).
- Peter Thatcher is interested to see the timestamp extension progress
and deploy it to aid congestion control.
- Joerg Ott said the author of the timestamp extension (Christian)
wants to know if there is more interest to devote more effort on
- Mo Zanaty is interested in the timestamp extension for the same
reasons as Peter and Bernard.
Harald Alvestrand notes that timestamps may be useful for knowing
what to send next, independent of congestion control.
- Jonathan Lennox sees issues with the secure profiles where keying
needs to be defined, so would not recommend this.
- Roman Shpount brings up the case of tunneling DTLS-SRTP over QUIC.
Jonathan Lennox thinks Roman's use case belongs in the MASQUE WG.
ALPN and Congestion Control:
- Bernard Aboba agrees with proposed ALPN "rtp-mux-quic" not "h3", but
notes this is orthogonal to congestion control. In WebTransport API
(constructor), the application can provide a hint about the desired
kind of congestion control, but this doesn't affect the ALPN.
- Peter Thatcher hopes congestion control does NOT depend on ALPN, but
rather we get a good congestion control for all traffic including
- Vidhi Goel agrees with Peter.
5. RTP over QUIC (J. Ott, M. Engelbart, 20 min)
- Talking about multiplexing - we've talked about this previously, but
not in much detail, and not including WebTransport.
- We have a lot of levels where we can do RTP/RTCP multiplexing (and
they don't all fit on one slide!)
- Jonathan - one use case people are interested in, is call control
and media on the same connection (if your call control and media go
to the same box, that makes load balancing easier, for example)
- This may be related to rfc7983 bis, though RTP over QUIC won't need
to multiplex with STUN/TURN/ZRTP/DTLS, only perhaps RTCP and data.
- Sam - transport parameter that allows you to say what a stream
carries when you open a new stream - would that help?
- Three options - "WebTransport", "Partial WebTransport" with our own
multiplexing, or just support multiplexing RTP/RTCP and assume we
can add other protocols when we need to.
- WebTransport requirements - indicate client origin and describer
server endpoint location using a URI
- Bernard - When an application constructs a WebTransport while
allowing pooling, this can result in multiple sessions over a single
QUIC connection. However, pooling is an optimization; the
application might get a distinct connection instead if pooling isn't
supported in the browser or on the server. So multiplexing of RTP
sessions using the WebTransport SessionId is more viable for
non-browsers than for browsers.
- Does it make sense to rely on WebTransport (hence, h2 and h3) in
order to get RTP over QUIC done?
- Bernard: In the WebTransport API, an application can specify whether
it is willing to failover to H2 or not. So it is possible to define
RTP over WebTransport only for HTTP/3, if there are required
features that HTTP/2 cannot provide.
- RTP/RTCP-only for now, and figure out how to multiplex any other
protocols in other documents that describe multiplexing per-protocol
for a new protocol?
- Bernard - what's "partial WebTransport"? You don't need to implement
all of HTTP/3 to support WebTransport, just a few headers. So no
need for a separate profile.
- Jonathan - define a single raw RTP session over WebTransport, and
have WebTransport handle all of the multiplexing stuff? Defining our
own multiplexing is probably a bad idea.
- Mathis - would that be enough?
- Jonathan - how much do we care?
- Mathis - having multiple RTP sessions over one QUIC connection to
simplify congestion control.
- Bernard: Today in WebRTC, it is nearly universal to bundle audio &
video are bundled and mux RTP and RTCP. Why not design for the
common use case?
- Bernard - how do we move forward on these issues?
- Jonathan - probably need to move forward on alternatives, so we can
evaluate alternatives better
- Action Item for Authors - Mathis and Joerg to start a mailing
- The chairs noted that we do have time for another virtual interim
before IETF 116 in March, if we need one
6. Codec Agnostic Payload Format (Y. Fablet, 20 min)
- Youenn provided an overview of an architecture for media that is
- Moving the packetizer from the encoder to the media encryptor
- If we use WebCodecs API, and focus on video for now, we can make
- Need to know whether to forward a packet or not, and the indicator
that tells you this can't be encrypted
- SFUs probably need to repacketize (for example, clients with
different MTU sizes) - Youenn would like feedback on this.
- We have a need for multiple encrypted transforms (SFrame, SPacket,
etc.), and we have an architecture. Are we ready to start working on
- Harald - I'm working on a different use case, but there's overlap
between what we're doing, and handling encrypted packets without
decrypting them is important
- Peter - I agree that it's important
- Chairs - you've made a lot of progress and given us capabilities
that we didn't have before - please keep working on this.
- Youenn - I'll do that.
- Peter's slides - major decision is what metadata to include.
- Don't have time to go over specifics, but there's more information
on the slides
- Jonathan - a minimal implementation that we could look at would be
very useful. With WebCodecs and WebTransport, this could be done in
7. Wrapup and Next Steps (Chairs, 15 min)
- The chairs thanked everyone for coming, and noted that we have a lot
to talk about
- "See you at IETF 116"
I am on my phone
I'm juggling two calls. If you have anything specific for me and I don't
respond, please put it in the chat.
Stephan, can you update the EVC draft?
I have no audio right now.
Seems you cant hear me
EVC draft will be revved as soon as RFC 9324 is published; any day now.
Mid Jan the latest, probably earlier
I get audio: 0 kbps. Anyone else?
I'm getting 10-20 kbps audio
Had to reboot my Mac. And I thought rebooting helps only with Windows
Green Metadata is Leonardo's sin, but it's known now
max_streams is not about open streams
rfc9000 "A count of the cumulative number of streams of the
corresponding type that can be opened over the lifetime of the
To clarify: the await/then issue isn't about a technical difference, but
about whether the JS sender blocks writing more bytes on the successful
queuing of bytes it just wrote. pipeTo() backpressure uses await
writer.ready for this reason which resolves ahead of writer.write(), for
Though max_streams is cumulative, quic implementation increases that
limit anytime streams are closed. So, it tries to maintain some number
of streams always open
@Vidhi, any spec ref to justify such implementation? It sounds wrong
from a brief scan of RFC 9000.
@Mo: It is treated as a sliding window according to some discussions on
the moq list, IIRC
can we PLEASE use zoom for future calls
I don’t think Stephan has audios
I'm going to shoot this computer!
Stephan: Nobody can hear you.
+1 to Peter's pont. ALso, the slide is overly standards-centric. Define
applications not be call control etc. standards.
I still want a drop-in replacement for RTP over UDP without standardized
call controls, as this is what large segments of the industry are using
can we PLEASE PLEASE PLEASE use zoom henceforth
Trying to clear my queue
QUIC TS could be used as an improvement if available but certainly would
not be mandated
At the last IETF, Christian Huitema was trying to see how much interest
there was in QUIC TS
would quic timestamps interact with rtp's timestamps ?
within the QWUIC WG
there was limited response at this point
@joerg, that may have been because of an application, but it seems like
RTP could be a motivating factor
we don't hear any echo, btw.
lucky you, at least then I was intelligible
Is QUIC over TCP even defined?
I hope not :-)
So QUIC over TCP is QUIC over UDP over MASQUE? Stack ALL the layers!
HTTP/3 doesn't specify the congestion control, the QUIC transport layer
@Sam, that is correct.
The examples of NADA and Scream shouldn’t be taken as the only options
Is this multiplexing question more of a general topic, and possibly not
unique to running RTP over QUIC? Maybe it's more generally useful to
define some transport extension which specifies a generic stream type
like that defined by H3 for unidirectional stream types?
Sergio Garcia Murillo11:32
what's the use case of multiplexing multiple RTP sessions over the same
but allowPooling defaults to false?
So if I create two new WebTransport(url); in the same document, they
fail? Not sure that is correct
A WebTransport session is a session of WebTransport over HTTP/3. There
may be multiple WebTransport sessions on one connection, when pooling is
I would argue against over webtransport or http as there are
applications that don’t do either.
If you want to just take the multiplexing logic from webtransport, then
I think it needs to very clear
Bernard, I think you've lost audio
Are we ending in 10 min at 10am PST?
Mo, I heard a chair say maybe we can run over a bit ...
Spencer, I have a conflicting meeting starting now, so thanks for taking
over the minutes.
need to go!