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

[Alexandre GOUAILLARD <[e-mail]>]

hi sean,

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

As mentioned to Ross, WHIP is aimed at being a 'companion' signalling
protocol to RTCWEB, not a replacement. The goal is for people to get most
if not all the rtcweb features when using WHIP for the signalling.


> # WHIPs narrow usage will mean not many implementations
>

WHIP does not aim to be a companion for all webrtc use cases. While the
number of implementations of WHIP will be at least one order of magnitude
less than those of RTCWEB, the IETF decided the use case was important
enough to justify this work and to create a working group.

Here is the official main use case, with some words emphasized by myself:

""*At the same time, the use of WebRTC as a mechanism for large-scale media
broadcast is gaining popularity, with companies such as Millicast,
Caffeine, Janus/Meetecho, Evercast, Wowza, Liveswitch, Antmedia, and
Strivecast deploying WebRTC-based media distribution networks. Unlike more
vertically integrated uses of WebRTC, these networks would benefit
immensely from being able to re-use the several broadcasting tools that
have been developed over time (such as Wirecast, OBS, Stretchcast, NewBlue
Stream, XSplit, FFSplit, Lightstream, vMix, and a host of other
applications). *

*To date, these media distribution networks have employed their own
proprietary signaling protocols to establish the connection between
broadcasting tools and the network, generally requiring either bespoke
software or customized modifications to existing broadcasting tools.*

*With the large number of available tools and the growing number of
real-time media distribution networks, this ad-hoc approach to creating
custom protocols for establishing sessions clearly does not scale. The
real-time broadcasting ecosystem would benefit immensely from a single,
shared protocol to meet this goal.*"

It is likely that any one-way output from video conferencing feature to
connect to delivery networks (zoom RTMP out, SKype RTMP out, Jitsi RTMP
out, ...) would also benefit from this without a lot of modifications.

The role of the IETF is to provide specifications, and not implementations,
or unified test suites like e.g. W3C which has a specific mandate for at
least two browsers implementations, and a reasonable level of testing.

I hope this clarifies.

   -