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

[Christer Holmberg <[e-mail]>]

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.


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.


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


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?


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?


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.


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.


Regards,

Christer