Subject: [Wish] Are there effectively two kinds of WHIP resources? trickle-supporting/non-trickle-supporting

From: Cameron Elliott <[email-masked]>
Date: Thu, 4 Nov 2021 21:47:27 -0700

Got a question from Lorenzo, that caused me to carefully re-read the draft.

It seems the spec effectively says there can be two kinds of WHIP resources
(server-side)(see bolded draft text below):

   - trickle-supporting
   - non-trickle-supporting

Is that a correct understanding of the language/intent from the current
draft?

I think client developers who want to support both models, might consider
an option at the client side: "all-candidates-in-sdp" vs
"trickle-candidates". Does this make sense for client-side developers who
want to address both kinds of WHIP resources?

Thanks, Cam

My bolding of the Oct 20 draft:

The initial offer by the WHIP client MAY be sent after the full ICE
> gathering is complete with the full list of ICE candidates, or only
> contain local candidates or even an empty list of candidates.
> 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. The WHIP Endpoint SHALL gather all the ICE candidates for
> the media server before responding to the client request and the SDP answer
> SHALL contain the full list of ICE candidates of the media server. The
> media server MAY use ICE lite, while the WHIP client MUST implement full
> ICE.
> The WHIP client MAY perform trickle ICE or an ICE restart {{!RFC8863}} by
> sending a HTTP PATCH request to the WHIP resource URL with a body
> containing a SDP fragment with MIME type "application/trickle-ice-sdpfrag"
> as specified in {{!RFC8840}} with the new ICE candidate or ICE ufrag/pwd
> for ICE restarts. A WHIP resource MAY not support trickle ICE (i.e. ICE
> lite media servers) or ICE restart, in that case, it MUST return a 405
> Method Not Allowed response for any HTTP PATCH request.
>