IETF Logo Mail Archive

Re: [Wish] WHIP should also allow *media* to be sent over the HTTPS connection

T H Panton <tim@pi.pe> Sun, 14 March 2021 18:36 UTC

Return-Path: <tim@pi.pe>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655F73A0E9B for <wish@ietfa.amsl.com>; Sun, 14 Mar 2021 11:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VtRodXrEjleh for <wish@ietfa.amsl.com>; Sun, 14 Mar 2021 11:36:44 -0700 (PDT)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 D8CDD3A0E98 for <wish@ietf.org>; Sun, 14 Mar 2021 11:36:43 -0700 (PDT)
Received: (qmail 93077 invoked from network); 14 Mar 2021 18:36:41 -0000
X-APM-Out-ID: 16157470019307
X-APM-Authkey: 255286/0(253943/0) 56
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 14 Mar 2021 18:36:41 -0000
Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 6E590809E0; Sun, 14 Mar 2021 18:36:41 +0000 (GMT)
Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 599GWqn8GsTJ; Sun, 14 Mar 2021 18:36:41 +0000 (GMT)
Received: from [192.67.4.88] (unknown [192.67.4.88]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 49E1480536; Sun, 14 Mar 2021 18:36:41 +0000 (GMT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: T H Panton <tim@pi.pe>
In-Reply-To: <8FFE3ECA-D56D-42B3-9D66-66E72A014433@live555.com>
Date: Sun, 14 Mar 2021 18:36:40 +0000
Cc: wish@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8723BEA-1324-4EE6-896F-F592DCD2560D@pi.pe>
References: <2EB890DF-0BA1-442D-9E6E-0F58CA4CB5DF@live555.com> <35AF83F2-C219-42E7-8A53-5292B8E748B8@pi.pe> <8FFE3ECA-D56D-42B3-9D66-66E72A014433@live555.com>
To: Ross Finlayson <finlayson@live555.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/qNl8ZLVCeSQ51Pbyg7MxO5OLmXI>
Subject: Re: [Wish] WHIP should also allow *media* to be sent over the HTTPS connection
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wish>, <mailto:wish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish/>
List-Post: <mailto:wish@ietf.org>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wish>, <mailto:wish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Mar 2021 18:36:46 -0000


> On 14 Mar 2021, at 15:32, Ross Finlayson <finlayson@live555.com> wrote:
> 
> 
> 
>> On Mar 14, 2021, at 6:57 AM, Tim Panton <tim@pi.pe> wrote:
>> 
>> 
>>> On 13 Mar 2021, at 03:59, Ross Finlayson <finlayson@live555.com> wrote:
>>> 
>>> I think you may be missing my point.  A WebRTC stream that happens to negotiate COMEDIA transport (with RFC 4571 framing of RTP/RTCP) is still, in my mind, a WebRTC stream.  It would be negotiated the same way as any other WebRTC stream (using JSEP, SDP, O/A).  But the stream itself wouldn’t use datagrams, and thus wouldn’t use ICE (because it wouldn’t need it).  That’s why I described this as being ‘WHIP-light’ - a subset of the WHIP protocol just for this simple class of streams.
>>> 
>>> Perhaps I have a more expansive view of WebRTC than everyone else, but I consider what I’m describing as being a WebRTC stream; albeit a special case.
>> 
>> 
>> Would it run DTLS over comedia ?
> 
> No
> 
>> If not how would the SRTP keys be generated ?
> 
> If the streaming is over a HTTPS connection, then you wouldn’t need SRTP.  I.e., you’d need to negotiate "TCP/RTP/AVP” rather than “RTP/SAVP”.  Again, this is perhaps a more expansive view of WebRTC than everyone else :-)
> 
>> how would bandwidth estimation /congestion control work ?
> 
> You’d use the HTTPS connection’s congestion control.
> 
>> Without ice how does continuing consent work?
> 
> The HTTPS connection staying up implies consent.
> 
>> Unless I am mistaken it will take quite a lot of work to engineer this into the webRTC stack on a browser.
> 
> Yes - but who says that the media source has to be a browser :-)

Right, you have just eliminated all connection with webRTC.  
(I.e. it isn’t the rtcweb wire protocol and it isn’t from a browser).

Which makes your proposal something out of scope for this group as currently chartered. 
I’m not a process guru, but I think that means you have to go back to dispatch and charter a new group, 
or ask the AGs to re-charter this one. 

If you can find a way to do what you want an preserve webRTC/rtcweb compatibility with something like TURN over COMEDIA
then you might be able to slip the proposal in scope, but you’d need to show why that was better than TURN TLS.

Tim.

> 
> 	Ross.
> 
> 
> 
> -- 
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish

v2.23.0 | Report a Bug | By Email