Re: [Wish] Proposal: Triggering ICE Restart

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

El sáb., 31 jul. 2021 1:17, Adam Roach <[e-mail]> escribió:

> 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).
>

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