Re: [Moq] [EXTERNAL] Fwd: New Version Notification for draft-dawkins-sdp-rtp-quic-questions-01.txt

[Maxim Sharabayko <[e-mail]>]

Hi Spencer and James,

I’d like to say without exaggeration that this is an outstanding work and an excellent summary!
I took the liberty of submitting a number of additions for consideration. Please see my PR [1].

One such suggestion is the "Distribution withing a platform" use case.
My description might be a bit clumsy though. So please let me know if that makes sense.

“
Distribution withing a platform

While a media is being contributed in real time via an ingest point to a streaming platform,
there may be a need to distribute the media between several servers and/or perform
a load balancing of the incoming traffic.
The platform may peform transcoding at one or several points, or distribute (route) the media as is
to one or many egress points. Such a distribution and load balancing may happen with or without
the access to the encrypted payload.”

- [1]: https://github.com/fiestajetsam/draft-gruessing-moq-requirements/pull/17

--
Regards,
Maxim Sharabayko
Senior Software Developer | Haivision

From: Moq <[e-mail]> on behalf of Spencer Dawkins at IETF <[e-mail]>
Date: Tuesday, 26. October 2021 at 23:37
To: MOQ Mailing List <[e-mail]>
Subject: [EXTERNAL] [Moq] Fwd: New Version Notification for draft-dawkins-sdp-rtp-quic-questions-01.txt
Dear MOQ subscribers,

Just to follow on James' excellent lead, I've also revised this draft, which is an attempt to identify the requirements that RTP over QUIC will place on SDP signaling for this type of media traffic.

As James said about our mutual draft, my understanding is that we're expected to have conversations about "Media Over QUIC" on this mailing list. If anyone has a different understanding, please let the mailing list know, so that we can Do The Right Thing.

Otherwise, let's be thinking how to move this work forward in the IETF 112 timeframe.

Best,

Spencer
---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Mon, Oct 25, 2021 at 12:38 PM
Subject: New Version Notification for draft-dawkins-sdp-rtp-quic-questions-01.txt
To: Spencer Dawkins <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-dawkins-sdp-rtp-quic-questions-01.txt
has been successfully submitted by Spencer Dawkins and posted to the
IETF repository.

Name:           draft-dawkins-sdp-rtp-quic-questions
Revision:       01
Title:          SDP Offer/Answer for RTP using QUIC as Transport - Design Questions
Document date:  2021-10-25
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/archive/id/draft-dawkins-sdp-rtp-quic-questions-01.txt
Status:         https://datatracker.ietf.org/doc/draft-dawkins-sdp-rtp-quic-questions/
Html:           https://www.ietf.org/archive/id/draft-dawkins-sdp-rtp-quic-questions-01.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic-questions
Diff:           https://www.ietf.org/rfcdiff?url2=draft-dawkins-sdp-rtp-quic-questions-01

Abstract:
   This document is a companion document to "SDP Offer/Answer for RTP
   using QUIC as Transport".  That document focuses on the description
   and registration of SDP "proto" attribute parameters with IANA, to
   allow applications that rely on SDP Offer/Answer to negotiate the
   QUIC protocol as an encapsulation for RTP.

   In writing that document, it became obvious that decisions about an
   appropriate SDP description would depend on decisions about the way
   RTP would be encapsulated in QUIC, and different proposals for those
   encapsulations had made different assumptions.  Given that none of
   these proposals have been adopted by an IETF working group yet, it's
   not appropriate to try to base a general-purpose set of "QUIC/RTP"
   IANA registrations on any one of them, so this document includes the
   questions that have come up, and (as discussions progress) suggested
   answers for those questions.




The IETF Secretariat





***[EXTERNAL] This message comes from an external organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.***