Subject: [Wish] Proposal: Triggering ICE Restart

From: Adam Roach <[email-masked]>
Date: Fri, 30 Jul 2021 17:04:32 -0500

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 31 Jul 2021 00:40:41 +0200

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 <[email-masked]> escribió:

> --
> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 30 Jul 2021 18:17:12 -0500

On 7/30/21 17:40, Sergio Garcia Murillo wrote:
> 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.

Can you expand on this concern? The clients will have code for parsing 
full SDP in order to handle session setup; and the actual parsing 
operation itself is computationally straightforward, so I can't imagine 
it's the parsing itself.

Is the concern that the SDP might change session parameters that the 
server would then need to make adjustments for? If so, we can 
normatively forbid doing so in WHIP (or possibly normatively forbid 
doing so in the absence of explicit indication of server support).

/a

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 31 Jul 2021 09:35:11 +0200

> doing so in the absence of explicit indication of server support).

The parsing of the initial SDP is done at the whip enpoint while the
parsing of the restart would be done at the whip resource, which may be
completely different components/servers.

My main concern is indeed any of both sides changing session parameters not
related to ICE. While it could be possible to forbid it at spec level, I
think it opens a potential source of bugs and may even make servers/client
to have to verify that those parameters have not actually changed.

On the other side mapping the sdp frag info to an actual sdp o/a is a
trivial string replacement for the sdp answer, you can get the local
username and frag from the ice transport object and add the server new
candidates via the addCandidate method.

Best regards
Sergio