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

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

Hi Christer, just got back from vacation, comments inline

El mar, 3 ago 2021 a las 21:16, Christer Holmberg (<christer.holmberg=
[e-mail]>) escribió:

> Hi,
>
>
>
> I read the draft, and I have some comments.
>
>
>
> As the draft is still in an early stage I will skip pure editorial
> comments, unless the text is unclear.
>
>
>
>
>
> 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.


>
> 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://github.com/murillo128/webrtc-http-ingest-protocol/issues/12


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


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


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


>
>
>
>
> 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://github.com/murillo128/webrtc-http-ingest-protocol/issues/13


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

Best regards
Sergio