Re: [Wish] Proposal: Triggering ICE Restart

I am not sure if I agree with the idea of mapping the operations with jsep.
Sure we will make life a bit easier for clients integrating libwebrtc but
we may make it much harder to get it implemented in others (like ffmpeg for
example).

What i dislike about the idea of generating a new SDP O/A  for ICE restart
is that we force the clients/servers to parse the whole sdp for changes
that are not just the ice parameters.

Best regards
Sergio

El sáb., 31 jul. 2021 0:05, Adam Roach <adam@nostrum.com> escribió:

> During today's meeting, Jonathan raised a question about whether the
> currently proposed PATCH mechanism is sufficient for triggering ICE
> restarts. The issue is that ICE restarts result in a new generation of
> ICE candidates, which necessitates new ufrags and passwords on both sides.
>
> Looking at RFC 5789, it's pretty clear that PATCH is intended as an
> optimization of PUT rather than its own independent operation (e.g. look
> closely at the final paragraph of section 2). So one semantically
> consistent approach to ice restart would be for WHIP clients to send a
> PUT with a new offer rather than simply PATCHing in new candidates.
>
> This approach has a lot of appeal for me because it lines up well with
> the model that Jonathan was describing (where we're basically mapping
> WISH operations pretty directly to JSEP operations): in JSEP, ICE
> restarts result in the generation of a whole new offer rather than
> simply a set of candidates.
>
> So how would we feel about using PUT with a full SDP offer on the WHIP
> resource URL for ICE restarts? (Alternatively, we could use POST on that
> URL for an offer/answer exchange, to keep it consistent with session
> initiation -- I see minor pros/cons each way, but nothing decisive)
>
> /a
>
> --
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish
>