Subject: Re: [Wish] Proposal: Triggering ICE Restart

From: Adam Roach <[email-masked]>
Date: Mon, 2 Aug 2021 15:14:01 -0500

On 7/31/21 02:35, Sergio Garcia Murillo wrote:
> 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.

This kind of syntactic manipulation seems really inelegant to me, but I 
can live with it if it gets us to consensus faster.

So, in this scheme, we address the issue that Jonathan raised by 
returning ICE candidates in a 200 response to the PATCH request, right? 
Jonathan: can you see any issues with that approach?

/a

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 2 Aug 2021 17:07:14 -0400

> On Aug 2, 2021, at 4:14 PM, Adam Roach <[email-masked]> wrote:
> 
>> 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.
> 
> This kind of syntactic manipulation seems really inelegant to me, but I can live with it if it gets us to consensus faster.
> 
> So, in this scheme, we address the issue that Jonathan raised by returning ICE candidates in a 200 response to the PATCH request, right? Jonathan: can you see any issues with that approach?

Yeah, that seems fine; you’d have ICE candidates, and the ufrag/password, in the 200 response to a PATCH request that does an ICE restar.  (Assuming that’s sensible according to the HTTP semantics people, that is; it seems potentially odd enough that we should probably confirm this.)

We also need to clarify that servers can’t trickle their own candidates (either for the initial connection or a restart), since we’re not supporting any sort of server push that could send them.  (I don’t think the complexity of allowing servers to respond to non-restart trickle candidate PATCH requests with candidates of their own would be particularly useful.)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 03 Aug 2021 00:49:34 +0200

> We also need to clarify that servers can’t trickle their own candidates
> (either for the initial connection or a restart),

In the case of the restart, I think that's okay.  The main point of ICE
restart is to deal with clients that have moved to a different AP and the
DS allocated them a new external IP.  (I know it shouldn't do that, but
I'm not the one designing the DS.)

As to the initial answer, I'll let more knowledgeable people express an
opinion.

-- Juliusz

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Aug 2021 09:07:21 +0000

Hi,

>We also need to clarify that servers can’t trickle their own candidates (either for the initial connection or a restart), 

Section 4.1 says:

"The WHIP endpoint SDP answer SHALL contain the full list of ICE candidates publicly accessible of the media server."

Having said that, it is a little unclear to me what "publicly accessible" really means. The reason you normally send multiple candidates is because you don't know which ones are publicly accessible.

I think it would be more clear to simply say "full list of ICE candidates".

Regards,

Christer