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

[Ross Finlayson <[e-mail]>]

> On Mar 14, 2021, at 6:57 AM, Tim Panton <[e-mail]> wrote:
> 
> 
>> On 13 Mar 2021, at 03:59, Ross Finlayson <[e-mail]> 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 :-)

	Ross.