Re: [Wish] WHEP - WebRTC Http Egress Protocol

[Cameron Elliott <[e-mail]>]

TL;DR
Some will complain, but I predict the following if two models of where the
offer is created does get adopted:
1. Some (WHEP-like) endpoints will only accept an offer from the client.
(busy industry programmers)
2. Some (WHEP-like) endpoints will only handle generating an offer.  (busy
industry programmers)
3. Some (full-WHEP) endpoints will implement both client-offer and
endpoint-offer generation. (good life programmers)

I would encourage some assertiveness, and chop WHEP to either client-offers
or endpoint-offers.
(endpoint offers does have the advantage the endpoint can present
audio-only or video-only SDPs)


--- Full message ---


I want to provide some initial thoughts on the first WHEP draft.
I've been exploring HTTP POST for egress since early 2021.
I wrote a library called whip-whap-js
<https://github.com/x186k/whip-whap-js> which can be used for egress.
I am now using Sergio's Js WHIP library for egress (which it works fine
for).

The draft proposes both single-POST and double-POST models.
Said another way, supporting both client-offer and endpoint-offer egress.

One reason given in the draft is to support audio-only SDPs as controlled
by the endpoint.
One reason given in the slides is that some WebRTC stacks don't support
'createOffer()' calls.

In my explorations, I initially used double-POST for egress, (endpoint
offer).
Eventually, I switched to single-POST as it just seemed cleaner.


Thoughts:
- The concern about audio-only (or video-only?) service sounds really good.
But if this is true, can a client ever in practice generate an offer?
Does the end-user/controller/developer choosing/controlling a client need
to know a-priori that the WHEP endpoint
can offer audio-only or video-only, and thus *choose* or *configure* a WHEP
client to do an empty-payload first POST?
Needing end-users or dev-ops people to understand whether the endpoint
always does 2 tracks or just one track seems problematic.

- The double complexity of implementing both client-offers and
endpoint-offers is not huge or overwhelming, but
it seems to offer little concrete value vs choosing one or the other.
Testing, development, debugging interop will be harder.

- Some will grumble as I believe there are both client-offers and
endpoint-offers in use already, but the conceptual
simplicity and reduced testing would be fantastic if just one of the two
was chosen for the standard.

People in industry under time pressures are going to be very tempted, or
maybe forced to choose
one of client-offers vs. endpoint-offers, especially if they initially are
controlling the client also.
When this happens, there will three different kinds of WHEP (WHEP-like
anyway) servers:
1. Full spec, handling both client-offers and server-offers
2. Not to spec, handling just client-offers
3. Not to spec, handling just endpoint-offers

Thanks,
Cameron











On Mon, Aug 1, 2022 at 6:34 AM Sergio Garcia Murillo <
[e-mail]> wrote:

> Hi all,
>
> As we didn't have enough time to discuss it during the last IETF meeting,
> I would like to introduce the WHEP draft again and ask for feedback and
> next steps.
>
> The draft is here:
>
> https://www.ietf.org/id/draft-murillo-whep-00.html
>
> The github repo for filling issues is here:
> https://github.com/murillo128/webrtc-http-egress-protocol
>
> And these are the corrected slides that I intended to present during the
> meeting.
>
> https://docs.google.com/presentation/d/1vOTbc-SfvQEtr62CuFlb1dqwaz6ag_zY6L-8kEKXIsY/edit?usp=sharing
>
> As I said during the meeting, the current draft is almost the same as WHIP
> but changing the direction attribute and taking into account some
> peculiarities about playback.
>
> So my feeling is that this draft would be best discussed here and would be
> better not create a new WG for this, but this would require a recharter of
> the WG, so not sure if it is possible.
>
> Do you have any feedback on the draft itself or what do you think is the
> best way forward to move it inside IETF?
>
> Best regards
> Sergio
>
>
> --
> Wish mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wish
>