Re: [Wish] Initial comments on draft-murillo-whip-02

[Christer Holmberg <[e-mail]>]

Hi,

General:
=======

Q_GEN_1:

>>>> The motivation behind WHIP seems to be broadcasting.
>>>>
>>>> But, unless I’ve missed something, what the draft does is defining how to do SDP O/A using HTTPS. So, it could be used for any SDP O/A use-case. It doesn’t even have to be WebRTC, as long as the client and server support the required extensions etc.
>>>
>>> The SDP O/A is restricted to one audio and/or video track in sendonly, indeed anyone could do an SDP O/A in an HTTP POST with whatever semantics they want, but the WISH wg is chartered to specifically cover the ingestion use case only.
>>
>> Maybe it would be good to say that the mechanism can be enhanced for other usages too, but those are outside the scope of the document.
>
> The protocol is only targeting ingest, I think it is a bad idea to open the possibility of enhancing it for other usages
> without explicting mentioning them too. Implementing an SDP O/A over HTTP for the viewing side will have not much similarities
> with current whip proposal to consider it an enhancement, even if they share HTTP as a transport layer.
>>
>> Also, if you are not planning on using the WebRTC data channel I think it would be good to explicitly indicate that.
>
> Nothing prevents an extension to include datachannel support in the future, although it may be worth adding this as note.

I think that would be good, because I am sure the question would come up.

---

Q_SEC-1_2:

>>>> The text says:
>>>>
>>>>   “RTSP, which is based on RTP and maybe the closest in terms of features to webrtc, is not compatible with WebRTC
>>>>   SDP offer/answer model.”
>>>>
>>>> What is “the WebRTC offer/answer model”?
>>>
>>> This seems editorial to me, do you have an alternative wording for this?
>>>
>> I assume what you want to say is that the features used by WebRTC have not been defined for RTSP.
>> But, it is not only about offer/answer, it is also about e.g., ICE etc.
>>
>> I guess it would also be good to say "which is ALSO based on RTP".
>
> Seems fine to me.

---

Q_SEC-1_3:

>>>> The text says:
>>>>
>>>>   “This document proposes a simple protocol for supporting WebRTC as
>>>>   ingest method which is:
>>>>
>>>>   …
>>>>
>>>>   o  Fully compliant with Webrtc and RTCWEB specs.”
>>>>
>>>> Based on some of the suggested restrictions, related to e.g., SDP O/A transactions (only allowing the initial O/A), ICE (related to trickle and restart), and the SDP setup attribute
>>>> misalignment (allowing setup:active in the initial offer) etc, I don’t think that is “fully compliant”. Or, if I have misunderstood, what exactly are you referring to?
>>>
>>> That any webrtc compliant endpoint can implement WHIP.
>>
>> I think it would be better to say that WHIP is designed in order to be compliant with WebRTC, but that a set of restrictions apply.
>
> Fine for me too

---

Section 4:
========

Q_SEC-4_1:

>>>> The text talks about usage of the Location header field in the 201 response. But, I assume usage is optional,
>>>> and that a server can choose to use the WISH endpoint for the whole session?
>>>
>>> No, it is not optional, the url of the created resource is returned in the 201 response and it must be used
>>> for doing the ice trickle and termination request. Nothing prevents the server from using the same url as
>>> the whip endpoint one.
>>
>> Isn´t that the implicit meaning if the Location header is not present?
>
> I would prefer to add as few optionalities to the protocol as possible. It would be trivial for the server
> to just return the current URL and not to have to test each interoperability with each client for both
> when the location header is present or not.

I just think it is not a good idea to make changes to core HTTP, so in my opinion it is more about HTTP interoperability than WHIP interoperability.

And, what if you are using an HTTP library that will remove the header if the endpoint isn't changed?

---

Section 4.1:
==========

Q_SEC-4-1_1:

>>>> The text says:
>>>>
>>>>   “In order to simplify the protocol, there is no support for exchanging
>>>>   gathered trickle candidates from media server ICE candidates once the
>>>>   SDP answer is sent.  So in order to support the WHIP client behind
>>>>   NAT, the WHIP media server SHOULD be publicly accessible.”
>>>>
>>>> Just because the server doesn’t support trickle, it doesn’t mean it has to be publicly accessible. Not supporting trickle just
>>>> means that the server needs to collect all candidates before sending the answer.
>>>
>>> We can remove the  last sentence as it is superfluous, adding a new github issue
>>> https://protect2.fireeye.com/v1/url?k=26929152-7909a816-2692d1c9-861d41abace8-717a11d6e023f0d4&q=1&e=d10bad7b-9658-47e5-8a4e-
>>> 85689e02a197&u=https%3A%2F%2Fgithub.com%2Fmurillo128%2Fwebrtc-http-ingest-protocol%2Fissues%2F13
>>
>> Also perhaps saying something like "no support for exchanging further candidates (ICE trickle)"
>
> Looks good to me

---

Q_GEN_2:

>> As a frequent user of a broadcasting/ingestion application myself, once the connection has been
>> established, I am able to send at least START, STOP, PAUS and RESUME commands. In case of sport
>> events, you are also able to send commands regarding scores etc.
>>
>> There doesn't seem to be any of that in WHIP. Instead, at least as far as the server is concerned,
>> the media ingestion starts once the connection has been established, ends once the connection is
>> terminated, and there is no way to exchange any kind of non-media data during the session. Perhaps
>> that is good enough when teenagers want to ingest something with their mobile, but I doubt it will
>> be useful for more professional usages.

If that is true, I think it would be good to point out in the draft.

> In terms of features, the WHIP protocol matches the ones offered by RTMP which is still widely used
> and offered on most profesional hardware encoders and main open source broadcasting software
> (i.e. ffmpeg/OBS/vmixer/...). Not sure how that is not suited for "professional usages".

RTMP supports PAUSE, RESUME etc commands, doesn't it? :)

Let me explain how the sport event ingestion software I am using works:

First you establish the session, choose what sports event you are going to stream etc.

After that, the media ingestion starts. But, the server does not start the broadcasting of the media yet. It only broadcasts the stream to the one doing the ingestion, so that he/she can check that everything works.

After that, the user sends a command to the server to start the actual broadcasting.

Etc.

So, the user has explicit control of when the actual broadcasting begins, even if the media ingestion has began earlier.

As I am not the implementer of the software I don't know all the protocol level details, other than it uses RTMP.

> Regarding the metadata exchanged during the session, which could be done either by datachannel
> or by a new whip protocol extension with another http url,

I had a datachannel in mind, and that's why I asked about it earlier :)

But, if commands are outside the scope of WHIP, I think it would be good to explcitly say it.

---

Q_GEN_3:

>> There is almost no text regarding WHY someone should use this mechanism, instead of existing ones.
>> There is a sentence saying "and content providers still rely heavily on protocols like RTMP". Ok,
>> so why is that a bad thing? Why should one use WHIP instead? Now it seems like the only reason is
>> because it is an IETF standard, but I hope there is more than that.
>
> We could add more info about the benefits of using webrtc end to end.

I think that would be useful.

Regards,

Christer