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

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

El mié, 25 ago 2021 a las 22:34, Christer Holmberg (<
[e-mail]>) escribió:

> Hi,
>
> See inline.
>
> 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.

>
>
>
> 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.


>
> 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".

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, the main problem is about standardizing the metadata that could be
used widely and implemented  in a service agnostic way.


> 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.

Best regards
Sergio