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

Hi Ross,

RTP/RTCP over HTTP totally works. These are some of the issues I anticipate or
things that I really like about WebRTC...

# Needs to get into the browser
WebCodecs + WebTransport might solve this, but it hasn't been proven to
be feasible yet.

# WHIP needs to define more
WebRTC has some complicated features that I think WHIP will benefit from

* Simulcast
* Negotiation (Codec support, Multiplexing tracks)
* Congestion Control/Error Correction (When using QUIC Datagrams)

Simulcast is a big one. It is expensive to run transcoders, I would much
rather have publishers upload multiple quality levels.

# WHIPs narrow usage will mean not many implementations
I can capture my webcam/distribute a file today on these platforms or
using these languages. These aren't just bindings. I don't see WHIP ever
matching this because of its narrow use case.

* C++/Mobile (Android/iOS) [0]
* C/RTOS [1]
* Go [2]
* Rust [3]
* Typescript [4]
* Python [5]
* C# [6]

# ICE is good for the client
Network switching (Wifi -> 4G) is nice to have. You have 'IRL Streamers'
who will be using WHIP. I am not familiar with the latest in
TCP/HTTP, but this is a 'solved problem' with WebRTC at least.

[0] https://webrtc.googlesource.com/src/
[1] https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c
[2] https://github.com/pion/webrtc
[3] https://github.com/webrtc-rs/webrtc (Rust, Full implementation)
[4] https://github.com/shinyoshiaki/werift-webrtc
[5] https://github.com/aiortc/aiortc
[6] https://github.com/sipsorcery-org/sipsorcery

On Fri, Mar 12, 2021 at 05:40:44PM -0800, Ross Finlayson wrote:
> One of the promises of WISH is that it might provide a way for relatively simple media sources (e.g. things like network cameras and real-time text (e.g., telemetry) feeds) to be more easily used within WebRTC applications.
>
> During the WISH meeting earlier this week, a few speakers expressed concern about complexities of the proposed ‘injestion’ protocol (WHIP), in particular, the need to implement ICE.  While Cullen (for example) correctly pointed out that if the web server has a public IP address (as it usually will), then then relatively little ICE is required, this seemed to only partially alleviate the concerns.
>
> Fortunately, for very simple media source endpoints, there is an easy solution already available to us: Have the media source negotiate COMEDIA transport (RFC 4145) with RTP/RTCP packets framed as defined in RFC 4571.  The media source (i.e., offerer) can ask for a "TCP/RTP/AVP”[*] stream, with "a=connection:existing”.  If the media server accepts this, then the media source can proceed to send its media over the existing HTTPS connection (that was used for negotiation), without requiring any ICE or STUN or TURN or DTLS, or any wrestling with NAT.  Nothing new needs to be standardized for this to work.
>
> Needless to say, streaming RTP/RTCP over a reliable stream isn’t ideal, but it’s an easy solution, and perhaps appropriate for some simple, relatively low-bitrate media streams.
>
> The WHIP document should, IMHO, explicitly note this possibility, by describing a 'WHIP-light’ subset of the protocol that very simple media sources might want to use (with caveats).
>
> Of course, a media server should not be required to support WHIP-light (just as it should not be required to support any particular codec(s)), but having this possibility will likely cause WHIP to get more adoption.
>
> 	Ross.
>
> [*] Yes, having “TCP” in the transport description might be a bit of an anachronism if the HTTPS stream ends up being sent over QUIC, but the meaning remains clear.
>
> --
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish