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

[Christer Holmberg <[e-mail]>]

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.

Also, if you are not planning on using the WebRTC data channel I think it would be good to explicitly indicate that.


Section 1:
=======
 
Q_SEC-1_1: 
 
>> The text says:
>> 
>>   “WebRTC intentionally does not specify a signaling transport protocol
>>   at application level, while RTCWEB standardized the signalling
>>   protocol itself (JSEP, SDP O/A) and everything that was going over
>>   the wire (media, codec, encryption, ...).”
>
>RTCWEB did not standardize the signaling protocol. 
> 
>You are right,  adding a github issue to track and solve it.
>https://protect2.fireeye.com/v1/url?k=772ed376-28b5ea32-772e93ed-861d41abace8-803b50005df852cb&q=1&e=d10bad7b-9658-47e5-8a4e-85689e02a197&u=https%3A%2F%2Fgithub.com%2Fmurillo128%2Fwebrtc-http-ingest-protocol%2Fissues%2F12

Thanks!


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


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. 
 

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?
 
 

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


Q_SEC-4-1_2: 
 
>> The text says:
>> 
>>   “A WHIP client receiving a 405 response for an HTTP PATCH request
>>   SHALL not send further request for ICE trickle or restart.  If the
>>   WHIP client gathers additional candidates (via STUN/TURN) after the
>>   SDP offer is sent, it MUST send STUN request to the ICE candidates
>>   received from the media server as per [RFC8838] regardless if the
>>   HTTP PATCH is supported by either the WHIP client or the WHIP
>>   resource.”
>>
>> This sounds really strange. 
>>
>> The text says that if the client receives 405, because the WHIP resource does not support trickle, the client can still trickle candidates per RFC 8838 (by sending STUN requests from the new candidates).
>> 
>> Creating peer-reflexive candidates by sending STUN requests from NEW candidates, even if trickle isn’t used, sounds like a hack to me.
>
> That was already agreed to be removed. ICE lite servers would just need to ignore the signaled candidates on the HTTP PATCH requests and reply only to the incoming stun requests from the new candidates.
 
Ok.

I have a couple of more generic comments.

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.


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.

Regards,

Christer