IETF Logo Mail Archive

Re: [Taps] QUIC API for WebRTC

youenn fablet <yfablet@apple.com> Tue, 16 October 2018 02:28 UTC

Return-Path: <yfablet@apple.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA04C127B92 for <taps@ietfa.amsl.com>; Mon, 15 Oct 2018 19:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.064
X-Spam-Level:
X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 wZqAHJsoqcaQ for <taps@ietfa.amsl.com>; Mon, 15 Oct 2018 19:27:59 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 1EB97127AC2 for <taps@ietf.org>; Mon, 15 Oct 2018 19:27:59 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9G2QxEI026132; Mon, 15 Oct 2018 19:27:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=QxImJwY7980xpE2PtthLt3ld41Yc+40+5xidpOp0ZIA=; b=WzjqtWoGfa2nlXQsd7RgEKvtJU12DG6xhL4E/t7fCa1cmV14y+/VClRHlaHYAOjby3/8 6MSS1NcLdg2aoeYTgMKLMHKgOQPf4w/94a+gMlkh3Pu6WtPTr3vH9L2qV3FFFu3TslwF jLyRIista7XPqr9DaXaf+GeYeT6prXuAKqvNfSxHhfWFwDcPOXZtjm1u8riRXbsMrtie +Fm4R7+uwD3XmPlPalKDUNWRY5tF2kx6QIBiGX0zaXnesoHvJ1JBAAnYMi0Nt6nYjYSb AZkQjMtSiBZ22jsI26DZ3p5TdKfQTfR/v3CTuU6rS/9jCUCKjfb5HatvTKYvpZz2zTaA 5Q==
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2n3d89f8tw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Oct 2018 19:27:51 -0700
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_GsoVpesf2iOlUJXrRzMmTQ)"
Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGO007536UFOR00@mr2-mtap-s02.rno.apple.com>; Mon, 15 Oct 2018 19:27:51 -0700 (PDT)
Received: from process_viserion-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGO00G0067BQ600@ma1-mmpp-sz10.apple.com>; Mon, 15 Oct 2018 19:27:51 -0700 (PDT)
X-Va-A:
X-Va-T-CD: b6bb457c0a685d707884d44453bef0d4
X-Va-E-CD: 60e05dbaa660b1a1d1872b99f54c2fe5
X-Va-R-CD: 2b427da21ffe06b137f8b53fe585f690
X-Va-CD: 0
X-Va-ID: 77c4aed4-fca5-4154-ad66-57ba30d89a3f
X-V-A:
X-V-T-CD: e0b4e3205114c910a61d426831c8e828
X-V-E-CD: 60e05dbaa660b1a1d1872b99f54c2fe5
X-V-R-CD: 2b427da21ffe06b137f8b53fe585f690
X-V-CD: 0
X-V-ID: 92fb9207-5e47-43bb-9653-3c3b6cef16f3
Received: from process_milters-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGO00C005WROO00@ma1-mmpp-sz10.apple.com>; Mon, 15 Oct 2018 19:27:50 -0700 (PDT)
Authentication-results: corp.apple.com; spf=softfail smtp.mailfrom=yfablet@apple.com; dmarc=none header.from=apple.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-15_14:,, signatures=0
X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp22.corp.apple.com-10000_instance1
Received: from [17.234.142.5] (unknown [17.234.142.5]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGO0039W6UBBV80@ma1-mmpp-sz10.apple.com>; Mon, 15 Oct 2018 19:27:50 -0700 (PDT)
Sender: youenn@apple.com
From: youenn fablet <yfablet@apple.com>
Message-id: <F2600D1F-51E7-4DC2-BF5B-5C698CC03ED2@apple.com>
Date: Mon, 15 Oct 2018 19:27:45 -0700
In-reply-to: <A8FB9ECB-A342-4A84-B250-FC86D28D789E@apple.com>
Cc: Aaron Falk <aaron.falk@gmail.com>, Michael Welzl <michawe@ifi.uio.no>, Colin Perkins <csp@csperkins.org>, taps@ietf.org
To: Tommy Pauly <tpauly@apple.com>
References: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> <FF152FCC-0EB3-4A20-8079-F17BFB3BE824@apple.com> <DFCA1DAF-C774-44E8-AE8E-ACBC58266705@gmail.com> <A8FB9ECB-A342-4A84-B250-FC86D28D789E@apple.com>
X-Mailer: Apple Mail (2.3445.100.42)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_01:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/xU2AWxuN2cQZyRHS9QkEdY4UjKk>
X-Mailman-Approved-At: Mon, 15 Oct 2018 21:00:10 -0700
Subject: Re: [Taps] QUIC API for WebRTC
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Oct 2018 02:28:01 -0000

FWIW, this topic might also be discussed during next TPAC within the WebRC WG (https://docs.google.com/document/d/1N8Px_UfBRkvVJbRT3pQMiYKVDmg9grPQIrsOkgFoDWM/edit <https://docs.google.com/document/d/1N8Px_UfBRkvVJbRT3pQMiYKVDmg9grPQIrsOkgFoDWM/edit>).

What Pauly suggests makes sense to me. Having some discussion during next IETF meeting seems beneficial.
I would hope we could define a data channel API/QUIC mapping based on TAPS.

Understanding the shortcomings of current data channels would be useful.
I can see some cases that might be interesting to study further:
- Use the same QUIC connection for both media exchange and data channel
- Use an existing QUIC/HTTP connection for data channel: Web Socket or SCTP data channel replacement

	Y

> On Oct 12, 2018, at 12:52 PM, Tommy Pauly <tpauly@apple.com> wrote:
> 
> I think it would be useful to have agenda time in TAPS to discuss both:
> 
> - Transport API mappings for QUIC
> - TAPS API mappings for WebRTC
> 
> Having input on the requirements and background for WebRTC + QUIC would be great.
> 
> Thanks,
> Tommy
> 
>> On Oct 12, 2018, at 12:48 PM, Aaron Falk <aaron.falk@gmail.com <mailto:aaron.falk@gmail.com>> wrote:
>> 
>> On 11 Oct 2018, at 17:14, Tommy Pauly wrote:
>> 
>> I think this also brings up a point that it may be good to have a discussion in Bangkok with the group about getting a bit more in detail to how TAPS can best serve WebRTC use cases, and make that aspect of the API really concrete.
>> 
>> Are you thinking an offline discussion or would you like to spend some agenda time on the topic? I could invite the authors to present.
>> 
>> --aaron
>> 
>

v2.23.0 | Report a Bug | By Email