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

[Ross Finlayson <[e-mail]>]

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.