Re: [Wish] WHEP - WebRTC Http Egress Protocol

[Sergio Garcia Murillo <[e-mail]>]

Hi Cameron,

Thank you very much for your feedback!

I would also prefer to have a single method, but our current PoC uses the
SDP offer in the HTTP request, and the alternative option was suggested
later by Gustavo Garcia and I think it was a nice addition to the protocol.

Anyway, having both options in would be similar to SIP, which allows the
invite to have the sdp offer, or be empty and send the SDP answer in the
ACK. (I know, maybe SIP is not a good source of inspiration).

I agree that the audio only/video only is not a very compelling reason for
having the media server doing the SDP offer, and the clients not supporting
createOffer is also not a very strong case.

However, I think it would be very interesting to allow WHIP/WHEP
integrations:

                +------------+     +-----------+      +------------+
                |            |     | WHIP      |      | WHEP       |
                |    GW      |     | Endpoint  |      | Endpoint   |
                +-----+------+     +-----+-----+      +-----+------+
                      |                  |                  |
                      |        HTTP POST |                  |
                      +------------------+----------------->|
                      |        201 CREATED (SDP OFFER)      |
                      |<-----------------+------------------+
                      |   HTTP POST (SDP OFFER)             |
                      +----------------->|                  |
                      |   201 CREATED (SDP ANSWER           |
                      |<-----------------+                  |
                      |   HTTP PATCH (SDP|ANSWER)           |
                      +------------------+----------------->|
                      |   200 OK         |                  |
                      |<-----------------+------------------+
                      |                  |                  |


I am not very concerned about endpoints support, there will be pressure to
implement both methods, so I am always more worried about clients for
WHIP/WHEP than media server support.

Best regards
Sergio


On Tue, Aug 2, 2022 at 12:14 AM Cameron Elliott <[e-mail]>
wrote:

> 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
>>
> --
> Wish mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wish
>