Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream?

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 May 2017 07:02:22 +0000

Hi,

> - Why can't a lite agent start an ICE restart or remove a media stream?  Seems like it would make sense for it to be able to, but the spec says it can't.

Technically, I guess a lite agent COULD start an ICE restart. But, what would be the trigger? A lite agent doesn’t send STUN requests etc.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 May 2017 21:35:47 -0400

On Mon, May 29, 2017 at 3:02 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> > - Why can't a lite agent start an ICE restart or remove a media stream?
> Seems like it would make sense for it to be able to, but the spec says it
> can't.
>
> Technically, I guess a lite agent COULD start an ICE restart. But, what
> would be the trigger? A lite agent doesn’t send STUN requests etc.
>
>
Lite agent must be able to initiate ICE restart or things will break.
Consider a 3pcc scenario where a re-INVITE moves the call from one ICE-lite
end point to another. In this case, 3pcc controller will send an empty
re-Invite to an ICE-lite end point, to which it must respond with a new
ufrag value. This will initiate an ICE restart on the full ICE end point
where 3pcc will forwards the SDP received from ICE-lite endpoint, which
should cause full ICE endpoint to start collecting new candidates and run
connectivity checks to the ICE-lite end point.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 May 2017 13:56:26 +0000

Hi,

The draft contains the following text in section 7.2.1:

   "The lite implementation will never itself determine that ICE
   processing has failed for a media stream; rather, the full peer will
   make that determination and then remove or restart the failed media
   stream as part of subsequent candidate exchange process."

But, the way I read it, it’s more about determining ICE failure. Is there any text actually preventing an lite implementation from doing a restart? I can’t find such text anywhere.

In any case, it would probably be a good idea to modify the text, and/or clarify that an lite agent is allowed to trigger a restart.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 30 May 2017 at 04:35
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent start an ICE restart or remove a media stream?

On Mon, May 29, 2017 at 3:02 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Lite agent must be able to initiate ICE restart or things will break. Consider a 3pcc scenario where a re-INVITE moves the call from one ICE-lite end point to another. In this case, 3pcc controller will send an empty re-Invite to an ICE-lite end point, to which it must respond with a new ufrag value. This will initiate an ICE restart on the full ICE end point where 3pcc will forwards the SDP received from ICE-lite endpoint, which should cause full ICE endpoint to start collecting new candidates and run connectivity checks to the ICE-lite end point.

Regards,
_____________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 01 Jun 2017 00:39:25 +0000

"The lite implementation will never itself determine that ICE
processing has failed for a media stream ... rather, the full peer will make
that determination and ... restart" sounds to me like "Full will restart;
lite will not restart".

However, if you're right and it realy means "Full may restart because of
failure; lite may restart for other reasons", then I agree we should
perhaps reword it to make it clear that the lite side can restart.

Why would a lite side restart? Well, if it's a client->server situation (a
common use case for ICE lite), the server may be failing over to another
server with a different IP address. Rather than wait for the client to
notice, it can signal it to the client.

Now you may say "then let the server signal to the client to signal the ICE
restart".  But not only is that silly, but it also highlights the fact that
this is really out of scope for ICEbis to define and that ICEbis should
leave it to the using/signaling protocol to define.

I think we should just say in ICEbis something like "the using protocol
defines how ICE restarts are triggered" and that's about it.

On Tue, May 30, 2017 at 6:56 AM Christer Holmberg <
[email-masked]> wrote:

> But, the way I read it, it’s more about determining ICE failure. Is there
> any text actually preventing an lite implementation from doing a restart? I
> can’t find such text anywhere.
>
> In any case, it would probably be a good idea to modify the text, and/or
> clarify that an lite agent is allowed to trigger a restart.
>
> Regards,
>
> Christer
>
> From: Roman Shpount <[email-masked]>
> To: Christer Holmberg <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Subject: Re: [Ice] Peter's review of ICEbis - Why can't a lite agent
> start an ICE restart or remove a media stream?
>
>
>> > - Why can't a lite agent start an ICE restart or remove a media
>> stream?  Seems like it would make sense for it to be able to, but the spec
>> says it can't.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Jun 2017 06:55:30 +0000

Hi,

>processing has failed for a media stream ... >rather, the full peer will >make that determination and ... restart" sounds >to me like "Full will restart; lite will not restart".
>
> However, if you're right and it realy means "Full may restart because of failure; lite may restart for other reasons", then I agree we should perhaps > reword it to make it clear that the lite side can restart.

I agree.

>Why would a lite side restart? Well, if it's a client->server situation (a common use case for ICE lite), the server may be failing over to another server with a different IP address. Rather than wait for >the client to notice, it can signal it to the client.
>
>Now you may say "then let the server signal to the client to signal the ICE restart".  But not only is that silly, but it also highlights the fact that this is really out of scope for ICEbis to define and that ICEbis should leave it to the using/signaling protocol to define.
>
>I think we should just say in ICEbis something like "the using protocol defines how ICE restarts are triggered" and that's about it.

I’ll think of some text.

Regards,

Christer

On Tue, May 30, 2017 at 6:56 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,
_____________
Roman Shpount