Re: [AVTCORE] Mapping RTP onto QUIC

Spencer Dawkins at IETF <> Thu, 17 September 2020 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0817B3A0B2E for <>; Thu, 17 Sep 2020 06:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tGPvce0cHIcw for <>; Thu, 17 Sep 2020 06:30:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D90AE3A0B2D for <>; Thu, 17 Sep 2020 06:30:15 -0700 (PDT)
Received: by with SMTP id x20so1679105ybs.8 for <>; Thu, 17 Sep 2020 06:30:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1gLtcILkUUib7VKStcVcGQoBcLerYXwn2iYykyENYnI=; b=XYNS5fQip8qRyQ0TRMEonjj2D4a1s3CVNLTtMWcuH1sX41I8Dtylwc9qs/JuPoWbYz FRGM33ONYGwaLO3x8hi+1byrHz05yQapNECYMGudpQMaUgnMK4JKT8hcBrJ8UJfesmII aPtnmvA9TLBXBOP2sCTgB6zOzW7ExxX1xCMMJA4KdRTx8PRhqDgwChDqWBt2xl/qZO6q oby8CPe0r4o2qeQXDqevGjvxQT0aVxj+zZ1b9xfB1lfCxbEzEchXc+wlNXRGycuH1kV3 xKKDVZxcHhbZcpMzGw80kRZNe27xq9bCbL1WAjt2M86IaF7TLaCQPyzzFEzMl5aNboiy ZXlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1gLtcILkUUib7VKStcVcGQoBcLerYXwn2iYykyENYnI=; b=IToePNr133vwV59C33Hbbzt+S6f29o9LQz2Hpiki626YEUDnjwhxyk+Awt/NITLI9i HlTxibT8fG+uIvW/WtzjyLCbCvztJmYqxV2uqaH5NaerCdD9hUn4Nk1Cmh7T6YIJqUtX Ew0jeblMkwrBRUBr9mD3kcfT5fOhAHt6Q/5aGxUXduuKnL51R5KfdgbSLZVxKUHbPc8n Dv2dHyQmBItPN+7q0kxIV8k2P1F0Yfip9oIU758JTy7jYDWbH7GRAIET8GHA3RBYLid5 k+E7r6x2kVaRlmHLN1FjUUcrIyLcV+f4q4X0XxAn8svjWMC3zox+nHGbUUbxDKcyTdas BYCA==
X-Gm-Message-State: AOAM531N27imBM6IG/SYJWs1vip9fXxhvIa0vLx0TVS+W6hXt8wjdnmA Sr8Km9TenTZ0A8rwTQmcM8SZGBrgKsmGka0fEe0=
X-Google-Smtp-Source: ABdhPJxIJfdfycweQn3B98qzasJCd/RTfSn80epU8eyNdpXiKbKjqX6pIsoOszykOsEFDn/1P14e9Ps4bgG4+NlKhvc=
X-Received: by 2002:a25:9d92:: with SMTP id v18mr39556442ybp.297.1600349415043; Thu, 17 Sep 2020 06:30:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 17 Sep 2020 08:29:48 -0500
Message-ID: <>
To: Bernard Aboba <>
Cc: IETF AVTCore WG <>
Content-Type: multipart/alternative; boundary="00000000000066764c05af826299"
Archived-At: <>
Subject: Re: [AVTCORE] Mapping RTP onto QUIC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Sep 2020 13:30:18 -0000

Hi, Bernard,

On Tue, Sep 15, 2020 at 12:37 PM Bernard Aboba <>

> 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:
> but the charter seems to omit the media aspects that were discussed during
> the RIPT BOF.
> The HTTP/3 datagram draft (
> (which
> played a part in some of the scenarios described in the RIPT BOF) isn't
> currently a WG work item anywhere, although
> 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:
> ) 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.



* 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!

> <>
> On Tue, Sep 15, 2020 at 8:42 AM Spencer Dawkins at IETF <
>> 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}
>> [2]
>> [3]
>> [4]
>> _______________________________________________
>> Audio/Video Transport Core Maintenance