Re: [Moq] How complicated is WebRTC?

On Mon, 4 Apr 2022 09:52:15 +0000
Maxim Sharabayko <maxsharabayko@haivision.com> wrote:

> Hi Lorenzo,
> 
> Thank you for your detailed follow up! It adds a lot of useful
> details. Just to clarify a bit further, in case of the FOSDEM demo
> both client and server were located nearby, presumably with an
> ultra-low RTT (<50 ms), right?
> 

Hi Maxim,

no, the demo I talked about at FOSDEM (which was done live during a
"Dangerous Demo" session at the virtual edition of ClueCon) had the
client part at my home, and the server part publicly available, on the
server I linked in my WHIP presentation. The client part was made of
two different components, since I used one laptop for OBS and NDI
output, and another laptop to do NDI input for the WHIP client (and
WebRTC ingestion); this was done on purpose to simulate a pseudo
production environment, and to properly test NDI in that setup.

I actually made a similar demo at CommCon, and that part was recorded,
so you can check the effect yourself:

https://2021.commcon.xyz/talks/whip-ndi-and-janus-genesis-of-a-broadcasting-demo

The Q&A starts at ~26:30, and it should give you a way to roughly
estimate the latency. In fact, the Q&Q starts with me doing audio and
video in a regular Janus-based conference, and then a separate
audio/video PeerConnection is created using WHIP and exactly the same
setup I described before: you still here me talking using the
conference channel, while the second video appears, and so the lip sync
should give you an idea of the latency between the two approaches
there.

Both the conference stream and the WHIP stream were handled by the same
server (since Dan's Broadcaster.vc is based on Janus, and he added an
integrated WHIP server to allow ingestion done that way too), which
IIRC was based in the UK. The WHIP based stream seems to be a bit behind
due to the NDI path between the two laptops, and because the WHIP
client is not tuned to zero out the latency completely (which we
discussed in a previous mail), but it's still pretty much there: I'd
expect latency to be smaller in case the production tool does WebRTC
ingestion via WHIP directly, as it happens with RTMP anyway.

Lorenzo

> 
> 
> From: Moq <moq-bounces@ietf.org> on behalf of Lorenzo Miniero
> <lorenzo@meetecho.com> Date: Tuesday, 29. March 2022 at 18:29
> To: Maxim Sharabayko <maxsharabayko@haivision.com>
> Cc: Simon Pietro Romano <spromano@unina.it>, Justin Uberti
> <juberti@alphaexplorationco.com>, Cullen Jennings <fluffy@iii.ca>,
> MOQ Mailing List <moq@ietf.org> Subject: Re: [Moq] How complicated is
> WebRTC? On Mon, 28 Mar 2022 16:31:49 +0000 Maxim Sharabayko
> <maxsharabayko@haivision.com> wrote:
> 
> > Hi Simon,
> >
> > Thank you for sharing those links! I’ve watched both sessions here.
> > They indeed go much more into details. However, certain items are
> > still missing for my perception:  
> 
> 
> Hi Maxim,
> 
> I'm glad you enjoyed the presentations! Answering your questions
> inline.
> 
> 
> >
> >   1.  Configure WebRTC for low latency live ingest (I only say a
> > command-line example for the whip-client app, it didn’t set much
> > webRTC-related parameters).  
> 
> 
> Actually there's nothing much that needs to be configured for low
> latency in there, as the WebRTC stack in gstreamer already tries to
> send stuff out as soon as it's captured/encoded. There are a couple of
> properties in the webrtcbin elements that could be tweaked, but we
> currently don't expose them via the command line arguments in the WHIP
> client, so they can't be modified unless you edit the code.
> 
> As such, all you configure in the WHIP client at the moment is mostly
> what you want to capture (e.g., a mic/webcam vs. a file vs. something
> else) and how you want to encode it, and the WebRTC stack takes care
> of the rest. You can configure STUN/TURN servers too, if required.
> 
> 
> > 2.  What was the resulting end-to-end
> > latency and network RTT in the experiment. Seems like low enough to
> > do live jamming session. But still no numbers unless I missed them.
> >  
> 
> 
> The jam session application is actually a different one (namely the
> one in this repo, https://github.com/lminiero/jamrtc). I didn't
> measure the latency and RTT, but you can expect them to be pretty
> much the same as in any WebRTC based conversation.
> 
> Of course, any hop can add a bit of latency, but in the case of the
> demo I talked about in the FOSDEM presentation, you had:
> 
>         1. my local devices (including a guitar) being captured by my
>         main laptop, and produced in OBS;
> 
>         2. OBS configured to do NDI out (so whatever latency NDI adds
>         here, which IIRC is a single frame);
> 
>         3. the WHIP client consuming NDI from a different laptop on
> the same LAN, using a cable (so latency should be minimal, since
>         NDI was configured to exchange uncompressed frames);
> 
>         4. the WHIP client encoding audio and video (so whatever
>         latency this process typically takes);
> 
>         5. the WHIP client sending the encoded streams via WebRTC to a
>         public Janus WebRTC server (network latency);
> 
>         6. Janus internally passing the stream to a colocated
>         distribution node, handled by the same Janus instance (the
> most basic SOLEIL setup);
> 
>         7. a subscriber receiving the stream via WebRTC.
> 
> Overall, the latency was very low. Again, I didn't measure it, but I
> expect all those hops to be probably in the 100-200ms range, possibly
> a bit higher. Capturing and encoding something directly, rather than
> doing the additional NDI hop I did as a proof-of-concept while we wait
> for broadcasting tools to natively support WebRTC, would probably cut
> that further down. I mentioned how webrtcbin does have a few knobs
> that could help bring that further down: in JamRTC, for instance, I
> manually set a property called "latency" to 0 (it's 200 by default).
> Anyway, I haven't played much with those yet, so there's definitely
> room for improvement.
> 
> That said, that's something you can also experiment with yourself if
> you want: the WHIP and Janus server I used for my tests is still up
> and running and publicly reachable, as it's the one I put up for the
> hackathon during IETF 112. You can find the relevant address and links
> (and a sample pipeline to use in the WHIP client) on my IETF 113 WHIP
> slides. The server is in Italy so you may experiment a higher latency,
> but that should give you an idea of what to expect. Should you need
> guidance on how to make a test, please feel free to reach to me
> privately.
> 
> 
> >
> > P.S. For those who might follow the discussion now or later on, the
> > link to the simple whip server has been changed to
> > https://github.com/meetecho/simple-whip-server.
> >  
> 
> 
> Yes, I moved both the client and server repos to the Meetecho
> organization a few days before the FOSDEM talk was published, and
> since the presentation had been recorded a couple of weeks in advance
> I couldn't update that in time. Both repos should automatically
> redirect to the right place, though. Apologies for the confusion!
> 
> Lorenzo
> 
> 
> >
> > From: Simon Pietro Romano <spromano@unina.it>
> > Date: Wednesday, 23. March 2022 at 14:03
> > To: Maxim Sharabayko <maxsharabayko@haivision.com>
> > Cc: Justin Uberti <juberti@alphaexplorationco.com>, Cullen Jennings
> > <fluffy@iii.ca>, MOQ Mailing List <moq@ietf.org> Subject: Re: [Moq]
> > How complicated is WebRTC? Hi,
> >
> >
> > I believe Lorenzo Miniero did a good talk on the WISH WG meeting
> > sharing his experience of running WebRTC using OBS and Gstreamer.
> > Still, the part on how to configure to get the best out of it felt
> > like missing.
> >
> > If it can be of any help, you can find here a recent talk Lorenzo
> > gave at FOSDEM, which covers both the ingestion part and the
> > distribution part.
> >
> > https://fosdem.org/2022/schedule/event/rtc_whip/
> >
> > Back in November 2020, we also presented related stuff at the MOPS
> > WG meeting:
> >
> > https://youtu.be/WeoKtWfmxnU?t=286
> > https://www.slideshare.net/LorenzoMiniero/virtual-ietf-meetings-with-webrtc-ietf-109-mops
> >
> > Cheers,
> >
> > Simon
> >
> >     _\\|//_
> >                               ( O-O )
> >      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> >                     Simon Pietro Romano
> >               Universita' di Napoli Federico II
> >                      Computer Engineering Department
> >                    Phone: +39 081 7683823
> >                                           e-mail:
> > spromano@unina.it<mailto:spromano@unina.it>
> >
> >     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
> >     idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> >                                     oooO
> >       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> >                  \ (            (   )
> >                                   \_)          ) /
> >                                                                       (_/
> >
> >
> > Il giorno 23 mar 2022, alle ore 13:34, Maxim Sharabayko
> > <maxsharabayko@haivision.com<mailto:maxsharabayko@haivision.com>> ha
> > scritto:
> >
> > In my humble opinion when someone says WebRTC is complicated, what
> > is actually meant here is that WebRTC is a beast powerfull as a
> > hell, I am scared and I don’t know how to instruct it to do what I
> > want. :) There are always two concerns for an end-user:
> >
> >   1.  Which implementation/tool to use?
> >   2.  How to properly configure it for exact my use case.
> > Please forgive my ignorance if something exists alerady, but I feel
> > like there should be a configuration profile for WebRTC to have it
> > up and runing as a media ingest transport, with as minimum settings
> > to configure as possible. Ideally only tell the buffering latency
> > the user is ok with.
> >
> > I believe Lorenzo Miniero did a good talk on the WISH WG meeting
> > sharing his experience of running WebRTC using OBS and Gstreamer.
> > Still, the part on how to configure to get the best out of it felt
> > like missing.
> >
> >
> >
> >
> >
> >
> > Maxim Sharabayko
> > Principal Research Engineer
> > <logo-h.png><https://www.haivision.com/>
> >
> >
> > From: Moq <moq-bounces@ietf.org<mailto:moq-bounces@ietf.org>> on
> > behalf of Justin Uberti
> > <juberti@alphaexplorationco.com<mailto:juberti@alphaexplorationco.com>>
> > Date: Wednesday, 23. March 2022 at 07:07 To: Cullen Jennings
> > <fluffy@iii.ca<mailto:fluffy@iii.ca>> Cc: MOQ Mailing List
> > <moq@ietf.org<mailto:moq@ietf.org>> Subject: [EXTERNAL] Re: [Moq]
> > How complicated is WebRTC? I think the truth is that there are two
> > different sets of things that people want to be able to do: a) get
> > HLS-style distribution with ~1s latency b) deploy WebRTC-based
> > interactive services (~100ms latency) with the benefit of modern
> > public cloud infrastructure
> >
> > Maybe there is a pony in there somewhere that can do both, but I
> > wonder if we'd be best off considering these efforts separately, and
> > seeing if the a) solution grows upwards to solve b) or vice versa.
> >
> > On Tue, Mar 22, 2022 at 3:27 PM Cullen Jennings
> > <fluffy@iii.ca<mailto:fluffy@iii.ca>> wrote:
> >
> > As background info on the pro/cons of WebRTC ….  You can see the
> > main specification that WebRTC depended on in
> >
> > https://datatracker.ietf.org/doc/html/draft-jennings-rtcweb-deps-27
> >
> > It is approximately about the following (with some mistakes):
> >
> >   [RFC2198]  Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
> >               Handley, M., Bolot, J.C., Vega-Garcia, A., and S.
> > Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC
> > 2198, DOI 10.17487/RFC2198, September 1997,
> >               <https://www.rfc-editor.org/info/rfc2198>.
> >
> >    [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
> > Model with Session Description Protocol (SDP)", RFC 3264,
> >               DOI 10.17487/RFC3264, June 2002,
> >               <https://www.rfc-editor.org/info/rfc3264>.
> >
> >    [RFC3388]  Camarillo, G., Eriksson, G., Holler, J., and H.
> >               Schulzrinne, "Grouping of Media Lines in the Session
> >               Description Protocol (SDP)", RFC 3388,
> >               DOI 10.17487/RFC3388, December 2002,
> >               <https://www.rfc-editor.org/info/rfc3388>.
> >
> >    [RFC3389]  Zopf, R., "Real-time Transport Protocol (RTP) Payload
> > for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,
> >               September 2002,
> > <https://www.rfc-editor.org/info/rfc3389>.
> >
> >    [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
> >               Jacobson, "RTP: A Transport Protocol for Real-Time
> >               Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
> >               July 2003, <https://www.rfc-editor.org/info/rfc3550>.
> >
> >    [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio
> > and Video Conferences with Minimal Control", STD 65, RFC 3551,
> >               DOI 10.17487/RFC3551, July 2003,
> >               <https://www.rfc-editor.org/info/rfc3551>.
> >
> >    [RFC3556]  Casner, S., "Session Description Protocol (SDP)
> > Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth",
> >               RFC 3556, DOI 10.17487/RFC3556, July 2003,
> >               <https://www.rfc-editor.org/info/rfc3556>.
> >
> >    [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark,
> > Ed., "RTP Control Protocol Extended Reports (RTCP XR)",
> >               RFC 3611, DOI 10.17487/RFC3611, November 2003,
> >               <https://www.rfc-editor.org/info/rfc3611>.
> >
> >    [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
> > K. Norrman, "The Secure Real-time Transport Protocol (SRTP)",
> >               RFC 3711, DOI 10.17487/RFC3711, March 2004,
> >               <https://www.rfc-editor.org/info/rfc3711>.
> >
> >    [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
> >               Conrad, "Stream Control Transmission Protocol (SCTP)
> >               Partial Reliability Extension", RFC 3758,
> >               DOI 10.17487/RFC3758, May 2004,
> >               <https://www.rfc-editor.org/info/rfc3758>.
> >
> >    [RFC3890]  Westerlund, M., "A Transport Independent Bandwidth
> >               Modifier for the Session Description Protocol (SDP)",
> >               RFC 3890, DOI 10.17487/RFC3890, September 2004,
> >               <https://www.rfc-editor.org/info/rfc3890>.
> >
> >    [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport
> > in the Session Description Protocol (SDP)", RFC 4145,
> >               DOI 10.17487/RFC4145, September 2005,
> >               <https://www.rfc-editor.org/info/rfc4145>.
> >
> >    [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP:
> > Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
> >               July 2006, <https://www.rfc-editor.org/info/rfc4566>.
> >
> >    [RFC4571]  Lazzaro, J., "Framing Real-time Transport Protocol
> > (RTP) and RTP Control Protocol (RTCP) Packets over Connection-
> >               Oriented Transport", RFC 4571, DOI 10.17487/RFC4571,
> > July 2006, <https://www.rfc-editor.org/info/rfc4571>.
> >
> >    [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over
> > the Transport Layer Security (TLS) Protocol in the Session
> >               Description Protocol (SDP)", RFC 4572,
> >               DOI 10.17487/RFC4572, July 2006,
> >               <https://www.rfc-editor.org/info/rfc4572>.
> >
> >    [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J.
> > Rey, "Extended RTP Profile for Real-time Transport Control
> >               Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
> >               DOI 10.17487/RFC4585, July 2006,
> >               <https://www.rfc-editor.org/info/rfc4585>.
> >
> >    [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
> >               Hakenberg, "RTP Retransmission Payload Format", RFC
> > 4588, DOI 10.17487/RFC4588, July 2006,
> >               <https://www.rfc-editor.org/info/rfc4588>.
> >
> >    [RFC4756]  Li, A., "Forward Error Correction Grouping Semantics
> > in Session Description Protocol", RFC 4756,
> >               DOI 10.17487/RFC4756, November 2006,
> >               <https://www.rfc-editor.org/info/rfc4756>.
> >
> >    [RFC4820]  Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk
> > and Parameter for the Stream Control Transmission Protocol
> >               (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
> >               <https://www.rfc-editor.org/info/rfc4820>.
> >
> >    [RFC4856]  Casner, S., "Media Type Registration of Payload
> > Formats in the RTP Profile for Audio and Video Conferences",
> >               RFC 4856, DOI 10.17487/RFC4856, February 2007,
> >               <https://www.rfc-editor.org/info/rfc4856>.
> >
> >    [RFC4895]  Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
> >               "Authenticated Chunks for the Stream Control
> > Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895,
> > August 2007, <https://www.rfc-editor.org/info/rfc4895>.
> >
> >    [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol
> > (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
> >               <https://www.rfc-editor.org/info/rfc4961>.
> >
> >    [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
> >               Correction (FEC) Building Block", RFC 5052,
> >               DOI 10.17487/RFC5052, August 2007,
> >               <https://www.rfc-editor.org/info/rfc5052>.
> >
> >    [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
> >               Kozuka, "Stream Control Transmission Protocol (SCTP)
> >               Dynamic Address Reconfiguration", RFC 5061,
> >               DOI 10.17487/RFC5061, September 2007,
> >               <https://www.rfc-editor.org/info/rfc5061>.
> >
> >    [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B.
> > Burman, "Codec Control Messages in the RTP Audio-Visual Profile
> >               with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
> >               February 2008,
> > <https://www.rfc-editor.org/info/rfc5104>.
> >
> >    [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile
> > for Real-time Transport Control Protocol (RTCP)-Based
> > Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
> >               2008, <https://www.rfc-editor.org/info/rfc5124>.
> >
> >    [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
> >               (ICE): A Protocol for Network Address Translator (NAT)
> >               Traversal for Offer/Answer Protocols", RFC 5245,
> >               DOI 10.17487/RFC5245, April 2010,
> >               <https://www.rfc-editor.org/info/rfc5245>.
> >
> >    [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for
> > RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
> >               2008, <https://www.rfc-editor.org/info/rfc5285>.
> >
> >    [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
> >               "Session Traversal Utilities for NAT (STUN)", RFC
> > 5389, DOI 10.17487/RFC5389, October 2008,
> >               <https://www.rfc-editor.org/info/rfc5389>.
> >
> >    [RFC5506]  Johansson, I. and M. Westerlund, "Support for
> > Reduced-Size Real-Time Transport Control Protocol (RTCP):
> > Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506,
> > April 2009, <https://www.rfc-editor.org/info/rfc5506>.
> >
> >    [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
> >               Media Attributes in the Session Description Protocol
> >               (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
> >               <https://www.rfc-editor.org/info/rfc5576>.
> >
> >    [RFC5583]  Schierl, T. and S. Wenger, "Signaling Media Decoding
> >               Dependency in the Session Description Protocol (SDP)",
> >               RFC 5583, DOI 10.17487/RFC5583, July 2009,
> >               <https://www.rfc-editor.org/info/rfc5583>.
> >
> >    [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
> >               Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
> >               March 2010, <https://www.rfc-editor.org/info/rfc5705>.
> >
> >    [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data
> > and Control Packets on a Single Port", RFC 5761,
> >               DOI 10.17487/RFC5761, April 2010,
> >               <https://www.rfc-editor.org/info/rfc5761>.
> >
> >    [RFC5763]  Fischl, J., Tschofenig, H., and E. Rescorla,
> > "Framework for Establishing a Secure Real-time Transport Protocol
> >               (SRTP) Security Context Using Datagram Transport Layer
> >               Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
> >               2010, <https://www.rfc-editor.org/info/rfc5763>.
> >
> >    [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
> >               Security (DTLS) Extension to Establish Keys for the
> > Secure Real-time Transport Protocol (SRTP)", RFC 5764,
> >               DOI 10.17487/RFC5764, May 2010,
> >               <https://www.rfc-editor.org/info/rfc5764>.
> >
> >    [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal
> > Using Relays around NAT (TURN): Relay Extensions to Session
> >               Traversal Utilities for NAT (STUN)", RFC 5766,
> >               DOI 10.17487/RFC5766, April 2010,
> >               <https://www.rfc-editor.org/info/rfc5766>.
> >
> >    [RFC5768]  Rosenberg, J., "Indicating Support for Interactive
> >               Connectivity Establishment (ICE) in the Session
> > Initiation Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April
> >               2010, <https://www.rfc-editor.org/info/rfc5768>.
> >
> >    [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session
> > Description Protocol (SDP) Grouping Framework", RFC 5888,
> >               DOI 10.17487/RFC5888, June 2010,
> >               <https://www.rfc-editor.org/info/rfc5888>.
> >
> >    [RFC5928]  Petit-Huguenin, M., "Traversal Using Relays around NAT
> >               (TURN) Resolution Mechanism", RFC 5928,
> >               DOI 10.17487/RFC5928, August 2010,
> >               <https://www.rfc-editor.org/info/rfc5928>.
> >
> >    [RFC5956]  Begen, A., "Forward Error Correction Grouping
> > Semantics in the Session Description Protocol", RFC 5956,
> >               DOI 10.17487/RFC5956, September 2010,
> >               <https://www.rfc-editor.org/info/rfc5956>.
> >
> >    [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of
> > RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
> >               <https://www.rfc-editor.org/info/rfc6051>.
> >
> >    [RFC6062]  Perreault, S., Ed. and J. Rosenberg, "Traversal Using
> >               Relays around NAT (TURN) Extensions for TCP
> > Allocations", RFC 6062, DOI 10.17487/RFC6062, November 2010,
> >               <https://www.rfc-editor.org/info/rfc6062>.
> >
> >    [RFC6096]  Tuexen, M. and R. Stewart, "Stream Control
> > Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096,
> >               DOI 10.17487/RFC6096, January 2011,
> >               <https://www.rfc-editor.org/info/rfc6096>.
> >
> >    [RFC6184]  Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup,
> > "RTP Payload Format for H.264 Video", RFC 6184,
> >               DOI 10.17487/RFC6184, May 2011,
> >               <https://www.rfc-editor.org/info/rfc6184>.
> >
> >    [RFC6188]  McGrew, D., "The Use of AES-192 and AES-256 in Secure
> >               RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011,
> >               <https://www.rfc-editor.org/info/rfc6188>.
> >
> >    [RFC6236]  Johansson, I. and K. Jung, "Negotiation of Generic
> > Image Attributes in the Session Description Protocol (SDP)",
> >               RFC 6236, DOI 10.17487/RFC6236, May 2011,
> >               <https://www.rfc-editor.org/info/rfc6236>.
> >
> >    [RFC6263]  Marjou, X. and A. Sollaud, "Application Mechanism for
> >               Keeping Alive the NAT Mappings Associated with RTP /
> > RTP Control Protocol (RTCP) Flows", RFC 6263,
> >               DOI 10.17487/RFC6263, June 2011,
> >               <https://www.rfc-editor.org/info/rfc6263>.
> >
> >    [RFC6336]  Westerlund, M. and C. Perkins, "IANA Registry for
> >               Interactive Connectivity Establishment (ICE) Options",
> >               RFC 6336, DOI 10.17487/RFC6336, July 2011,
> >               <https://www.rfc-editor.org/info/rfc6336>.
> >
> >    [RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
> >               Correction (FEC) Framework", RFC 6363,
> >               DOI 10.17487/RFC6363, October 2011,
> >               <https://www.rfc-editor.org/info/rfc6363>.
> >
> >    [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J.
> > Rajahalme, "IPv6 Flow Label Specification", RFC 6437,
> >               DOI 10.17487/RFC6437, November 2011,
> >               <https://www.rfc-editor.org/info/rfc6437>.
> >
> >    [RFC6464]  Lennox, J., Ed., Ivov, E., and E. Marocco, "A
> > Real-time Transport Protocol (RTP) Header Extension for Client-to-
> >               Mixer Audio Level Indication", RFC 6464,
> >               DOI 10.17487/RFC6464, December 2011,
> >               <https://www.rfc-editor.org/info/rfc6464>.
> >
> >    [RFC6465]  Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A
> > Real- time Transport Protocol (RTP) Header Extension for
> > Mixer- to-Client Audio Level Indication", RFC 6465,
> >               DOI 10.17487/RFC6465, December 2011,
> >               <https://www.rfc-editor.org/info/rfc6465>.
> >
> >    [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams,
> > "Transport Layer Security (TLS) and Datagram Transport Layer
> > Security (DTLS) Heartbeat Extension", RFC 6520,
> >               DOI 10.17487/RFC6520, February 2012,
> >               <https://www.rfc-editor.org/info/rfc6520>.
> >
> >    [RFC6525]  Stewart, R., Tuexen, M., and P. Lei, "Stream Control
> >               Transmission Protocol (SCTP) Stream Reconfiguration",
> >               RFC 6525, DOI 10.17487/RFC6525, February 2012,
> >               <https://www.rfc-editor.org/info/rfc6525>.
> >
> >    [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B.
> >               Roach, "TCP Candidates with Interactive Connectivity
> >               Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
> >               March 2012, <https://www.rfc-editor.org/info/rfc6544>.
> >
> >    [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success
> > with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
> >               2012, <https://www.rfc-editor.org/info/rfc6555>.
> >
> >    [RFC6562]  Perkins, C. and JM. Valin, "Guidelines for the Use of
> >               Variable Bit Rate Audio with Secure RTP", RFC 6562,
> >               DOI 10.17487/RFC6562, March 2012,
> >               <https://www.rfc-editor.org/info/rfc6562>.
> >
> >    [RFC6716]  Valin, JM., Vos, K., and T. Terriberry, "Definition of
> > the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
> >               September 2012,
> > <https://www.rfc-editor.org/info/rfc6716>.
> >
> >    [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization
> > Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012,
> >               <https://www.rfc-editor.org/info/rfc6749>.
> >
> >    [RFC6904]  Lennox, J., "Encryption of Header Extensions in the
> > Secure Real-time Transport Protocol (SRTP)", RFC 6904,
> >               DOI 10.17487/RFC6904, April 2013,
> >               <https://www.rfc-editor.org/info/rfc6904>.
> >
> >    [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of
> > Stream Control Transmission Protocol (SCTP) Packets for
> > End-Host to End-Host Communication", RFC 6951,
> >               DOI 10.17487/RFC6951, May 2013,
> >               <https://www.rfc-editor.org/info/rfc6951>.
> >
> >    [RFC7022]  Begen, A., Perkins, C., Wing, D., and E. Rescorla,
> >               "Guidelines for Choosing RTP Control Protocol (RTCP)
> >               Canonical Names (CNAMEs)", RFC 7022, DOI
> > 10.17487/RFC7022, September 2013,
> > <https://www.rfc-editor.org/info/rfc7022>.
> >
> >    [RFC7053]  Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-
> >               IMMEDIATELY Extension for the Stream Control
> > Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November
> > 2013, <https://www.rfc-editor.org/info/rfc7053>.
> >
> >    [RFC7064]  Nandakumar, S., Salgueiro, G., Jones, P., and M.
> > Petit- Huguenin, "URI Scheme for the Session Traversal
> > Utilities for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064,
> >               November 2013,
> > <https://www.rfc-editor.org/info/rfc7064>.
> >
> >    [RFC7065]  Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and
> > P. Jones, "Traversal Using Relays around NAT (TURN) Uniform
> >               Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065,
> >               November 2013,
> > <https://www.rfc-editor.org/info/rfc7065>.
> >
> >    [RFC7160]  Petit-Huguenin, M. and G. Zorn, Ed., "Support for
> > Multiple Clock Rates in an RTP Session", RFC 7160,
> >               DOI 10.17487/RFC7160, April 2014,
> >               <https://www.rfc-editor.org/info/rfc7160>.
> >
> >    [RFC7164]  Gross, K. and R. Brandenburg, "RTP and Leap Seconds",
> >               RFC 7164, DOI 10.17487/RFC7164, March 2014,
> >               <https://www.rfc-editor.org/info/rfc7164>.
> >
> >    [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
> >               "Transport Layer Security (TLS) Application-Layer
> > Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
> >               July 2014, <https://www.rfc-editor.org/info/rfc7301>.
> >
> >    [RFC7345]  Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP
> >               Transport Layer (UDPTL) over Datagram Transport Layer
> >               Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345,
> > August 2014, <https://www.rfc-editor.org/info/rfc7345>.
> >
> >    [RFC7496]  Tuexen, M., Seggelmann, R., Stewart, R., and S.
> > Loreto, "Additional Policies for the Partially Reliable Stream
> >               Control Transmission Protocol Extension", RFC 7496,
> >               DOI 10.17487/RFC7496, April 2015,
> >               <https://www.rfc-editor.org/info/rfc7496>.
> >
> >    [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
> >               Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
> >               2015, <https://www.rfc-editor.org/info/rfc7515>.
> >
> >    [RFC7587]  Spittka, J., Vos, K., and JM. Valin, "RTP Payload
> > Format for the Opus Speech and Audio Codec", RFC 7587,
> >               DOI 10.17487/RFC7587, June 2015,
> >               <https://www.rfc-editor.org/info/rfc7587>.
> >
> >    [RFC7635]  Reddy, T., Patil, P., Ravindranath, R., and J. Uberti,
> >               "Session Traversal Utilities for NAT (STUN) Extension
> > for Third-Party Authorization", RFC 7635,
> >               DOI 10.17487/RFC7635, August 2015,
> >               <https://www.rfc-editor.org/info/rfc7635>.
> >
> >    [RFC7639]  Hutton, A., Uberti, J., and M. Thomson, "The ALPN HTTP
> >               Header Field", RFC 7639, DOI 10.17487/RFC7639, August
> >               2015, <https://www.rfc-editor.org/info/rfc7639>.
> >
> >    [RFC7657]  Black, D., Ed. and P. Jones, "Differentiated Services
> >               (Diffserv) and Real-Time Communication", RFC 7657,
> >               DOI 10.17487/RFC7657, November 2015,
> >               <https://www.rfc-editor.org/info/rfc7657>.
> >
> >    [RFC7675]  Perumal, M., Wing, D., Ravindranath, R., Reddy, T.,
> > and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage
> >               for Consent Freshness", RFC 7675, DOI
> > 10.17487/RFC7675, October 2015,
> > <https://www.rfc-editor.org/info/rfc7675>.
> >
> >    [RFC7728]  Burman, B., Akram, A., Even, R., and M. Westerlund,
> > "RTP Stream Pause and Resume", RFC 7728, DOI
> > 10.17487/RFC7728, February 2016,
> > <https://www.rfc-editor.org/info/rfc7728>.
> >
> >    [RFC7741]  Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
> >               Galligan, "RTP Payload Format for VP8 Video", RFC
> > 7741, DOI 10.17487/RFC7741, March 2016,
> >               <https://www.rfc-editor.org/info/rfc7741>.
> >
> >    [RFC7742]  Roach, A.B., "WebRTC Video Processing and Codec
> >               Requirements", RFC 7742, DOI 10.17487/RFC7742, March
> > 2016, <https://www.rfc-editor.org/info/rfc7742>.
> >
> >    [RFC7850]  Nandakumar, S., "Registering Values of the SDP 'proto'
> >               Field for Transporting RTP Media over TCP under
> > Various RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April
> > 2016, <https://www.rfc-editor.org/info/rfc7850>.
> >
> >    [RFC7918]  Langley, A., Modadugu, N., and B. Moeller, "Transport
> >               Layer Security (TLS) False Start", RFC 7918,
> >               DOI 10.17487/RFC7918, August 2016,
> >               <https://www.rfc-editor.org/info/rfc7918>.
> >
> >    [RFC7941]  Westerlund, M., Burman, B., Even, R., and M. Zanaty,
> > "RTP Header Extension for the RTP Control Protocol (RTCP)
> >               Source Description Items", RFC 7941, DOI
> > 10.17487/RFC7941, August 2016,
> > <https://www.rfc-editor.org/info/rfc7941>.
> >
> >    [RFC7982]  Martinsen, P., Reddy, T., Wing, D., and V. Singh,
> >               "Measurement of Round-Trip Time and Fractional Loss
> > Using Session Traversal Utilities for NAT (STUN)", RFC 7982,
> >               DOI 10.17487/RFC7982, September 2016,
> >               <https://www.rfc-editor.org/info/rfc7982>.
> >
> >    [RFC7983]  Petit-Huguenin, M. and G. Salgueiro, "Multiplexing
> > Scheme Updates for Secure Real-time Transport Protocol (SRTP)
> >               Extension for Datagram Transport Layer Security
> > (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016,
> >               <https://www.rfc-editor.org/info/rfc7983>.
> >
> >    [RFC8035]  Holmberg, C., "Session Description Protocol (SDP)
> > Offer/ Answer Clarifications for RTP/RTCP Multiplexing",
> >               RFC 8035, DOI 10.17487/RFC8035, November 2016,
> >               <https://www.rfc-editor.org/info/rfc8035>.
> >
> >    [RFC8083]  Perkins, C. and V. Singh, "Multimedia Congestion
> > Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083,
> >               DOI 10.17487/RFC8083, March 2017,
> >               <https://www.rfc-editor.org/info/rfc8083>.
> >
> >    [RFC8108]  Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
> >               "Sending Multiple RTP Streams in a Single RTP
> > Session", RFC 8108, DOI 10.17487/RFC8108, March 2017,
> >               <https://www.rfc-editor.org/info/rfc8108>.
> >
> >    [RFC8122]  Lennox, J. and C. Holmberg, "Connection-Oriented Media
> >               Transport over the Transport Layer Security (TLS)
> > Protocol in the Session Description Protocol (SDP)", RFC 8122,
> >               DOI 10.17487/RFC8122, March 2017,
> >               <https://www.rfc-editor.org/info/rfc8122>.
> >
> >    [RFC8260]  Stewart, R., Tuexen, M., Loreto, S., and R.
> > Seggelmann, "Stream Schedulers and User Message Interleaving for the
> >               Stream Control Transmission Protocol", RFC 8260,
> >               DOI 10.17487/RFC8260, November 2017,
> >               <https://www.rfc-editor.org/info/rfc8260>.
> >
> >    [RFC8261]  Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
> >               "Datagram Transport Layer Security (DTLS)
> > Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261,
> > November 2017, <https://www.rfc-editor.org/info/rfc8261>.
> >
> >    [RFC8285]  Singer, D., Desineni, H., and R. Even, Ed., "A General
> >               Mechanism for RTP Header Extensions", RFC 8285,
> >               DOI 10.17487/RFC8285, October 2017,
> >               <https://www.rfc-editor.org/info/rfc8285>.
> >
> >    [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
> >               Better Connectivity Using Concurrency", RFC 8305,
> >               DOI 10.17487/RFC8305, December 2017,
> >               <https://www.rfc-editor.org/info/rfc8305>.
> >
> >    [RFC8421]  Martinsen, P., Reddy, T., and P. Patil, "Guidelines
> > for Multihomed and IPv4/IPv6 Dual-Stack Interactive
> >               Connectivity Establishment (ICE)", BCP 217, RFC 8421,
> >               DOI 10.17487/RFC8421, July 2018,
> >               <https://www.rfc-editor.org/info/rfc8421>.
> >
> >    [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg,
> > "Interactive Connectivity Establishment (ICE): A Protocol for
> > Network Address Translator (NAT) Traversal", RFC 8445,
> >               DOI 10.17487/RFC8445, July 2018,
> >               <https://www.rfc-editor.org/info/rfc8445>.
> >
> >    [RFC8489]  Petit-Huguenin, M., Salgueiro, G., Rosenberg, J.,
> > Wing, D., Mahy, R., and P. Matthews, "Session Traversal
> >               Utilities for NAT (STUN)", RFC 8489, DOI
> > 10.17487/RFC8489, February 2020,
> > <https://www.rfc-editor.org/info/rfc8489>.
> >
> >    [RFC8627]  Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP
> >               Payload Format for Flexible Forward Error Correction
> >               (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019,
> >               <https://www.rfc-editor.org/info/rfc8627>.
> >
> >    [RFC8656]  Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and
> > J. Rosenberg, "Traversal Using Relays around NAT (TURN):
> >               Relay Extensions to Session Traversal Utilities for
> > NAT (STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020,
> >               <https://www.rfc-editor.org/info/rfc8656>.
> >
> >    [RFC8825]  Alvestrand, H., "Overview: Real-Time Protocols for
> >               Browser-Based Applications", RFC 8825,
> >               DOI 10.17487/RFC8825, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8825>.
> >
> >    [RFC8826]  Rescorla, E., "Security Considerations for WebRTC",
> >               RFC 8826, DOI 10.17487/RFC8826, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8826>.
> >
> >    [RFC8827]  Rescorla, E., "WebRTC Security Architecture", RFC
> > 8827, DOI 10.17487/RFC8827, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8827>.
> >
> >    [RFC8829]  Uberti, J., Jennings, C., and E. Rescorla, Ed.,
> >               "JavaScript Session Establishment Protocol (JSEP)",
> >               RFC 8829, DOI 10.17487/RFC8829, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8829>.
> >
> >    [RFC8830]  Alvestrand, H., "WebRTC MediaStream Identification in
> > the Session Description Protocol", RFC 8830,
> >               DOI 10.17487/RFC8830, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8830>.
> >
> >    [RFC8831]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
> >               Channels", RFC 8831, DOI 10.17487/RFC8831, January
> > 2021, <https://www.rfc-editor.org/info/rfc8831>.
> >
> >    [RFC8832]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
> > Channel Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,
> >               January 2021,
> > <https://www.rfc-editor.org/info/rfc8832>.
> >
> >    [RFC8833]  Thomson, M., "Application-Layer Protocol Negotiation
> >               (ALPN) for WebRTC", RFC 8833, DOI 10.17487/RFC8833,
> >               January 2021,
> > <https://www.rfc-editor.org/info/rfc8833>.
> >
> >    [RFC8834]  Perkins, C., Westerlund, M., and J. Ott, "Media
> > Transport and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
> >               January 2021,
> > <https://www.rfc-editor.org/info/rfc8834>.
> >
> >    [RFC8835]  Alvestrand, H., "Transports for WebRTC", RFC 8835,
> >               DOI 10.17487/RFC8835, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8835>.
> >
> >    [RFC8836]  Jesup, R. and Z. Sarker, Ed., "Congestion Control
> >               Requirements for Interactive Real-Time Media", RFC
> > 8836, DOI 10.17487/RFC8836, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8836>.
> >
> >    [RFC8837]  Jones, P., Dhesikan, S., Jennings, C., and D. Druta,
> >               "Differentiated Services Code Point (DSCP) Packet
> > Markings for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January
> >               2021, <https://www.rfc-editor.org/info/rfc8837>.
> >
> >    [RFC8838]  Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle
> > ICE: Incremental Provisioning of Candidates for the
> > Interactive Connectivity Establishment (ICE) Protocol", RFC 8838,
> >               DOI 10.17487/RFC8838, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8838>.
> >
> >    [RFC8839]  Petit-Huguenin, M., Nandakumar, S., Holmberg, C.,
> > Keränen, A., and R. Shpount, "Session Description Protocol (SDP)
> >               Offer/Answer Procedures for Interactive Connectivity
> >               Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
> >               January 2021,
> > <https://www.rfc-editor.org/info/rfc8839>.
> >
> >    [RFC8840]  Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
> >               Session Initiation Protocol (SIP) Usage for
> > Incremental Provisioning of Candidates for the Interactive
> >               Connectivity Establishment (Trickle ICE)", RFC 8840,
> >               DOI 10.17487/RFC8840, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8840>.
> >
> >    [RFC8841]  Holmberg, C., Shpount, R., Loreto, S., and G.
> > Camarillo, "Session Description Protocol (SDP) Offer/Answer
> >               Procedures for Stream Control Transmission Protocol
> > (SCTP) over Datagram Transport Layer Security (DTLS) Transport",
> >               RFC 8841, DOI 10.17487/RFC8841, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8841>.
> >
> >    [RFC8842]  Holmberg, C. and R. Shpount, "Session Description
> > Protocol (SDP) Offer/Answer Considerations for Datagram Transport
> >               Layer Security (DTLS) and Transport Layer Security
> > (TLS)", RFC 8842, DOI 10.17487/RFC8842, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8842>.
> >
> >    [RFC8843]  Holmberg, C., Alvestrand, H., and C. Jennings,
> >               "Negotiating Media Multiplexing Using the Session
> >               Description Protocol (SDP)", RFC 8843,
> >               DOI 10.17487/RFC8843, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8843>.
> >
> >    [RFC8844]  Thomson, M. and E. Rescorla, "Unknown Key-Share
> > Attacks on Uses of TLS with the Session Description Protocol (SDP)",
> >               RFC 8844, DOI 10.17487/RFC8844, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8844>.
> >
> >    [RFC8851]  Roach, A.B., Ed., "RTP Payload Format Restrictions",
> >               RFC 8851, DOI 10.17487/RFC8851, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8851>.
> >
> >    [RFC8852]  Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP
> > Stream Identifier Source Description (SDES)", RFC 8852,
> >               DOI 10.17487/RFC8852, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8852>.
> >
> >    [RFC8853]  Burman, B., Westerlund, M., Nandakumar, S., and M.
> > Zanaty, "Using Simulcast in Session Description Protocol (SDP) and
> >               RTP Sessions", RFC 8853, DOI 10.17487/RFC8853, January
> >               2021, <https://www.rfc-editor.org/info/rfc8853>.
> >
> >    [RFC8854]  Uberti, J., "WebRTC Forward Error Correction
> >               Requirements", RFC 8854, DOI 10.17487/RFC8854, January
> >               2021, <https://www.rfc-editor.org/info/rfc8854>.
> >
> >    [RFC8858]  Holmberg, C., "Indicating Exclusive Support of RTP and
> > RTP Control Protocol (RTCP) Multiplexing Using the Session
> >               Description Protocol (SDP)", RFC 8858,
> >               DOI 10.17487/RFC8858, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8858>.
> >
> >    [RFC8859]  Nandakumar, S., "A Framework for Session Description
> >               Protocol (SDP) Attributes When Multiplexing", RFC
> > 8859, DOI 10.17487/RFC8859, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8859>.
> >
> >    [RFC8860]  Westerlund, M., Perkins, C., and J. Lennox, "Sending
> >               Multiple Types of Media in a Single RTP Session",
> >               RFC 8860, DOI 10.17487/RFC8860, January 2021,
> >               <https://www.rfc-editor.org/info/rfc8860>.
> >
> >    [RFC8861]  Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
> >               "Sending Multiple RTP Streams in a Single RTP Session:
> >               Grouping RTP Control Protocol (RTCP) Reception
> > Statistics and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
> >               January 2021,
> > <https://www.rfc-editor.org/info/rfc8861>.
> >
> >
> > Thank you for scrolling all the way to the bottom.
> >
> > You can view this one of two ways. There is a lots of stuff in
> > WebRTC that does useful things and one can leverage it. Or you can
> > view it as there must be a simpler way to accomplish what we need.
> >
> > WebRTC is a great for what it does - the number of different ways it
> > has been used in the last two years alone makes it one of the most
> > important protocols of the internet. But I don’t find it to be a
> > good match to the problem we want to solve here.
> >
> > I’m sure there is a pony in there somewhere :-)
> >
> >
> >
> >
> >
> > --
> > Moq mailing list
> > Moq@ietf.org<mailto:Moq@ietf.org>
> > https://www.ietf.org/mailman/listinfo/moq
> >
> >
> > ***[EXTERNAL] This message comes from an external organization.
> > Exercise caution when opening attachments or clicking links,
> > especially from unknown senders.***
> >
> >
> > --
> > Moq mailing list
> > Moq@ietf.org<mailto:Moq@ietf.org>
> > https://www.ietf.org/mailman/listinfo/moq
> >
> >
> >
> >
> > ***[EXTERNAL] This message comes from an external organization.
> > Exercise caution when opening attachments or clicking links,
> > especially from unknown senders.***
> >
> >  
> 
> 
> 
> --
> I'm getting older but, unlike whisky, I'm not getting any better
> https://twitter.com/elminiero
> 
> --
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
> 
> 
> 
> ***[EXTERNAL] This message comes from an external organization.
> Exercise caution when opening attachments or clicking links,
> especially from unknown senders.***
> 

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero