Re: [AVTCORE] QUIC RTP Tunnelling
Samuel Hurst <samuelh@rd.bbc.co.uk> Mon, 02 November 2020 16:39 UTC
Return-Path: <samuelh@rd.bbc.co.uk>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 926FE3A0CD8
for <avt@ietfa.amsl.com>; Mon, 2 Nov 2020 08:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level:
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id UaN_9hh1PDRq for <avt@ietfa.amsl.com>;
Mon, 2 Nov 2020 08:39:31 -0800 (PST)
Received: from tlsmtp.bbc.co.uk (tlsmtp1.telhc.bbc.co.uk [132.185.161.173])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 476683A0B3C
for <avt@ietf.org>; Mon, 2 Nov 2020 08:39:31 -0800 (PST)
Received: from gateh.lh.bbc.co.uk ([10.118.193.77])
by tlsmtp.bbc.co.uk (8.15.2/8.15.2) with ESMTPS id 0A2GdSv3004112
(version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Mon, 2 Nov 2020 16:39:29 GMT
Received: from mailhub0.rd.bbc.co.uk ([172.29.120.128])
by gateh.lh.bbc.co.uk (8.14.5+Sun/8.13.6) with ESMTP id 0A2GdStC004320;
Mon, 2 Nov 2020 16:39:28 GMT
Received: from [172.29.197.137] (port=57818)
by mailhub0.rd.bbc.co.uk with esmtp (Exim 4.92)
(envelope-from <samuelh@rd.bbc.co.uk>)
id 1kZcrf-0000dH-SQ; Mon, 02 Nov 2020 16:39:28 +0000
To: Bernard Aboba <bernard.aboba@gmail.com>, avt@ietf.org
References: <8dd07103-16a0-ca03-625b-e6c2b4c18008@rd.bbc.co.uk>
<91C47627-9EA3-4C01-9ADD-E7AAE103AD2B@gmail.com>
From: Samuel Hurst <samuelh@rd.bbc.co.uk>
Autocrypt: addr=samuelh@rd.bbc.co.uk; prefer-encrypt=mutual; keydata=
LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptRE1FWFZacHVSWUpLd1lC
QkFIYVJ3OEJBUWRBTC9KNCtaMUVGRGNLR3ByNzdvYzZKRWVOemZXQ0t4VXBCNXJ6CnVUN0tm
dHEwSTFOaGJYVmxiQ0JJZFhKemRDQThjMkZ0ZFdWc2FFQnlaQzVpWW1NdVkyOHVkV3MraUpZ
RUV4WUkKQUQ0V0lRUi9NaG1CLzJtREdicVJEUUZGM3RxdVp0UWdLd1VDWFZacHVRSWJBd1VK
Q1dZQmdBVUxDUWdIQWdZVgpDZ2tJQ3dJRUZnSURBUUllQVFJWGdBQUtDUkJGM3RxdVp0UWdL
L0p6QVFEZUxZZjNSQVgzOTk3THgzcDZnbTZQClRCYlJSV2JVeDJ0VHovOTFzQytUREFFQTVz
di9GdFdNN045VS83L0p2MDdQVkpGS0VTS3JQRENFdHBDSHdwbG0KblF5NE9BUmRWbW01RWdv
ckJnRUVBWmRWQVFVQkFRZEFnVWpnZ09jb25pV0RFWkxQazBQNHVvRGtGMmZubFR1egpmSVpl
dm9kTGhBNERBUWdIaUg0RUdCWUlBQ1lXSVFSL01obUIvMm1ER2JxUkRRRkYzdHF1WnRRZ0t3
VUNYVlpwCnVRSWJEQVVKQ1dZQmdBQUtDUkJGM3RxdVp0UWdLNys4QVFETFZlaW9rVlBIaUlG
TXpWRzltS2dib3A1am1CQkkKazFpUWw5d0NJMVFOUVFEK0x1LzhRZnJPcjBSOGNEemUxSjlW
Q0VmQmVjcjdROElHcVhCWHpZWkU4QTA9Cj1UNFJwCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZ
IEJMT0NLLS0tLS0K
Message-ID: <de22c2fb-0c50-6c31-82b7-cb100c348964@rd.bbc.co.uk>
Date: Mon, 2 Nov 2020 16:39:24 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <91C47627-9EA3-4C01-9ADD-E7AAE103AD2B@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="KmqLaRjBBohCFhbMGFfWcy7GZeqo06XUI"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/WpULiHZWdokMPyrO6A1LKVKzg28>
Subject: Re: [AVTCORE] QUIC RTP Tunnelling
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>,
<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>,
<mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 16:39:33 -0000
Hello Bernard, On 02/11/2020 15:29, Bernard Aboba wrote: > A comment on the allocation of QUIC datagram flow identifiers. In pooled > transports such as HTTP/3 over QUIC, the datagram flow identifier is > used to route datagrams to a particular application, and an additional > identifier is provided by the application to identify a particular flow. > Therefore in a pooled transport the application will not have the > ability to allocate its own application flow identifiers. In order to keep the initial draft more concise, I've written it as if the only thing that goes over the QRT session is just RTP, so I can avoid having to specify managing different applications contending for the same space. However, I fully realise that in the future the draft will absolutely have to support co-located application packet flows. I can forsee this causing issues with things like SDP which advertise the flow identifiers up front, but that's why I made it an optional component of the draft. I'm keeping an eye on the development of such ideas in the DATAGRAM and H3 DATAGRAM spaces to see what the consensus ends up being, and then I can adopt that. -Sam
- [AVTCORE] QUIC RTP Tunnelling Samuel Hurst
- Re: [AVTCORE] QUIC RTP Tunnelling Bernard Aboba
- Re: [AVTCORE] QUIC RTP Tunnelling Samuel Hurst