Re: [AVTCORE] Mapping RTP onto QUIC

Hi, Bernard,

On Tue, Sep 15, 2020 at 12:37 PM Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> Spencer said:
>
> "As best I can decode from the discussion during the RIPT BOF [3], and
> subsequent non-chartering, the RIPT BOF participants didn't support moving
> forward,"
>

Thanks for the clue here. I'd forgotten about ASAP(^), but my focus really
is on the media.

> [BA] The Automatic SIP trunking and Peering (ASAP) WG was subsequently
> chartered:
> https://datatracker.ietf.org/wg/asap/about/
>
> but the charter seems to omit the media aspects that were discussed during
> the RIPT BOF.
>
> The HTTP/3 datagram draft (
> https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram) (which
> played a part in some of the scenarios described in the RIPT BOF) isn't
> currently a WG work item anywhere, although
> https://tools.ietf.org/html/draft-ietf-quic-datagram did get adopted by
> the QUIC WG.
>
> "but we didn't really converge in those discussions on whether we should
> be looking at HTTP/3 for media, or a more conservative mapping of RTP
> directly onto QUIC transport."
>
> [BA]  I would agree that those discussions (and subsequent ones) have not
> converged.  There are multiple dimensions to the non-convergence.  One axis
> is HTTP/3 transport versus direct QUIC transport.   Another dimension is
> how HTTP/3 would be used.  The RIPT BOF suggested a general goal of
> enabling media to leverage conventional Web infrastructure; one of the
> slides showed an HTTP/3 request (with a byte range!) soliciting a response
> of HTTP/3 datagrams.  That is quite different from the model used in
> WebTransport (either Http3Transport or QuicTransport).
>
> Yet another dimension is what kind of media would be transported over
> HTTP/3. This can include conventional streaming media (e.g. DASH or HLS
> over HTTP/3), low-latency streaming media (e.g. SRT over HTTP/3), or
> realtime media.
>

Yeah, we're definitely experimenting with both. I'd like to talk to anyone
else who is also experimenting (and can talk about it).

>  In the W3C WebTransport WG (recently formed, see:
> https://w3c.github.io/webtransport-charter/charter.html ) there is now a
> work item for use cases. So perhaps some greater understanding will come
> out of that.
>

Thanks for the pointer. I was waiting for the final formation in W3C. I'll
keep an eye on that.

Best,

Spencer

* It was easier for me to keep track of BOFs that changed names when they
were chartered when I was balloting on WG charters, but I'm not complaining
that's ended!

> <https://datatracker.ietf.org/wg/asap/about/>
> On Tue, Sep 15, 2020 at 8:42 AM Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
>> Dear AVTCORE,
>>
>> As part of the set of ideas included in the IETF 107 RIPT BOF [1] there
>> was a proposal [2] to use HTTP/3 for media {"when it is available, falling
>> back to media byways when it is not").
>>
>> As best I can decode from the discussion during the RIPT BOF [3], and
>> subsequent non-chartering, the RIPT BOF participants didn't support moving
>> forward, but we didn't really converge in those discussions on whether we
>> should be looking at HTTP/3 for media, or a more conservative mapping of
>> RTP directly onto QUIC transport.
>>
>> I know there have been proposals for an RTP mapping onto QUIC (most
>> notably [4]). Are some people in AVTCORE interested in pursuing that
>> alternative, now that QUICv1 is banging around in WGLC?
>>
>> Best,
>>
>> Spencer, sending this e-mail to AVTCORE at the suggestion of the ART and
>> TSV ADs
>>
>> [1} https://datatracker.ietf.org/group/ript/meetings/
>> [2]
>> https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ript-00#section-8.8
>> [3] https://www.ietf.org/proceedings/107/minutes/minutes-107-ript-00
>> [4] https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-01
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>>
>