Re: [Wish] 2nd WG Last Call for draft-ietf-wish-whip: PATCH and trickle ICE

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

On Tue, Jan 9, 2024 at 12:25 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> Section 4.1.1. of WHIP-11 says:
>
>
>
>         “When used for trickle ICE,
>
>            the body of this PATCH message will contain the new gathered
> set of
>
>            ICE candidates and when used for ICE restarts, it will also
> contain
>
>            the new ICE ufrag/pwd pair as defined in [RFC8838] Section 5.4.”
>
>
>
>
>
> Q1: My reading of the text above is that ICE ufrag/pwd is only included
> for ICE restarts. However, they are included in the trickle ICE example in
> Section 4.1.2.
>

This is not mandatory text, so just a description of the important fields.
Probably we should explicitly state in 4.1.2. Trickle ICE that the creation
of the HTTP PATCH BODY and processing by the WHIP session MUST follow
section 4.4. Delivering Candidates in INFO Requests of RFC 8840.


>
>
> Q2: My reading of the text above is that for trickle ICE the PATCH message
> body will not contain the previous candidates, only the new gathered set.
>
>
>
> However, Section 4.4. of RFC 8838, which defines the SDP
> trickle-ice-sdpfrag content type, and the usage with SIP INFO, says:
>
>
>
>           “Since the agent is not fully aware of the state of the ICE
> Negotiation Session at its peer, it MUST include all currently
>
>             known and used local candidates in every INFO request.”
>
>
>
> Since WHIP does not (AFAIU) apply to the MUST above, I think it would be
> useful with some justification in the draft. For example, is there
> something HTTP PATCH provides, but SIP INFO does not, that justifies not
> adopting the MUST?
>
>
>
> (Related to Q1, RFC 8838 also mandates sending of ICE pwd/ufrag for
> trickle ICE)
>

I was not aware of the in-order delivery requirement of RFC 8838. In order
to fulfill that requirement, I don't think that sending all the candidates
is required,  but only the ones that are "in-flight".

That is, two concurrent patch requests can be received out of order by the
media server. So the WHIP client needs to keep an ordered list of
candidates sent on the PATCH request, and remove them from the list when
the 204 response is received. If a new candidate is gathered, we just
append it to the list, and send a new request with the full list of pending
candidates.

WDYT?

Best regards
Sergio