Skip to main content

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
State Active
Other versions markdown
Last updated 2022-12-15


Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox
Bernard Aboba

Virtual Interim Agenda
Date: Thursday, December 15, 2022
Time: 08:00 - 10:00 Pacific Time


Meeting link:

Remote instructions:


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
  • Bernard has experimented with Javascript for concurrency (multiple
    RTP streams on a single QUIC stream) - await() is blocking, so don't
    do that
  • 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.

  • Topologies:

  • Roman Shpount suggests to stay away from multicast which complicated
    RTP. Demux of multiple RTP streams over a single "channel" needs to
    be specified.
  • Jonathan Lennox does not see a need to mention all topologies, but
    just mention those that will be in scope for RTP over QUIC.

  • QUIC Extensions:

  • 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.

  • AVT Profiles:

  • 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
    real-time media.
  • 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
    list discussion
  • 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
    encrypted end-to-end
  • Moving the packetizer from the encoder to the media encryptor
  • If we use WebCodecs API, and focus on video for now, we can make
    some progress.
  • 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"

Zulip Logs

Roni Even10:04
I am on my phone

Stephan Wenger10:09
I'm juggling two calls. If you have anything specific for me and I don't
respond, please put it in the chat.

Jonathan Lennox10:10
Stephan, can you update the EVC draft?

Stephan Wenger10:11
I have no audio right now.

Lauri Ilola10:11
Seems you cant hear me


Stephan Wenger10:11
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?

Nils Ohlmeier10:14
I'm getting 10-20 kbps audio

Stephan Wenger10:16
Had to reboot my Mac. And I thought rebooting helps only with Windows

Youenn Fablet10:17
@Stephan, if you are using Safari, feel free to file a bug in and send me a sysdiagnose (

Stephan Wenger10:18
Green Metadata is Leonardo's sin, but it's known now

Rui Paulo10:32
max_streams is not about open streams

Joerg Ott10:33

Rui Paulo10:33
rfc9000 "A count of the cumulative number of streams of the
corresponding type that can be opened over the lifetime of the
connection. "

Jan-Ivar Bruaroey10:35
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
better concurrency

Vidhi Goel10:37
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

Joerg Ott10:39


Mo Zanaty10:39
@Vidhi, any spec ref to justify such implementation? It sounds wrong
from a brief scan of RFC 9000.

Joerg Ott10:40
@Mo: It is treated as a sliding window according to some discussions on
the moq list, IIRC

Stephan Wenger10:46
can we PLEASE use zoom for future calls

Shuai Zhao10:49
I don’t think Stephan has audios

Stephan Wenger10:50
I'm going to shoot this computer!

Dale Worley10:50
Stephan: Nobody can hear you.

Stephan Wenger10:50
+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

Joerg Ott11:00
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

Rui Paulo11:00
would quic timestamps interact with rtp's timestamps ?

Joerg Ott11:01
within the QWUIC WG

there was limited response at this point

Rui Paulo11:01
@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.

Joerg Ott11:05
lucky you, at least then I was intelligible

Harald Alvestrand11:14
Is QUIC over TCP even defined?

Rui Paulo11:14
I hope not :-)

Harald Alvestrand11:17
So QUIC over TCP is QUIC over UDP over MASQUE? Stack ALL the layers!

Sam Hurst11:19
HTTP/3 doesn't specify the congestion control, the QUIC transport layer

Rui Paulo11:21
@Sam, that is correct.

Vidhi Goel11:24
The examples of NADA and Scream shouldn’t be taken as the only options

Sam Hurst11:30
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
QUIC connection?

Jan-Ivar Bruaroey11:38
but allowPooling defaults to false?

So if I create two new WebTransport(url); in the same document, they
fail? Not sure that is correct

also iframes

A WebTransport session is a session of WebTransport over HTTP/3. There
may be multiple WebTransport sessions on one connection, when pooling is

Vidhi Goel11:45
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

Jonathan Lennox11:47
Bernard, I think you've lost audio

Mo Zanaty11:49
Are we ending in 10 min at 10am PST?

Spencer Dawkins11:59
Mo, I heard a chair say maybe we can run over a bit ...

Mo Zanaty12:00
Spencer, I have a conflicting meeting starting now, so thanks for taking
over the minutes.

Harald Alvestrand12:11
need to go!