Subject: [Ice] clarification on when it's acceptable to close underlying transport sockets

From: Nicholas Desaulniers <[email-masked]>
Date: Wed, 6 Jan 2016 10:57:31 -0800

Hi there,
I'm implementing ICE as part of my RTCPeerConnection 
library](https://github.com/nickdesaulniers/node-rtc-peer-connection). I 
will soon pull the ICE parts out into their own lib.  This is also my 
first time posting to any IETF related discussion, so let me know if 
this is the wrong forum.

I was curious, in [section 
7.3.1](https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-00#section-7.3.1), 
it's not clear when it's ok to close the underlying transport socket 
when ICE processing has finished.

For example, in my implementation (Full, Full-Trickle), I can see the 
valid list being built up.  When initiating an offer to Firefox in the 
controlling role, I see Firefox start responding with application level 
data once the first candidate I send the nomination for (aggressive 
nomination), though it will sometimes switch if I send a binding request 
for a higher priority candidate.

It's not clear to me when it's safe to close the rest of the sockets for 
candidates I'm not using.  Should I leave them open for the rest of the 
connection (surely not)?  Should I timeout once ICE has stabilized?  
What's a safe duration to use?  Or is there some other event that occurs 
during ICE processing that I should wait for, rather than a specific 
duration?

-- 
Thanks,
~Nick Desaulniers
Open Source Zealot
Mozilla Corporation

---

From: Ari Keränen <[email-masked]>
Date: Fri, 8 Jan 2016 15:09:13 +0000

Hi Nick,

> On 06 Jan 2016, at 20:57, Nicholas Desaulniers <[email-masked]> wrote:
> 
> Hi there,
> I'm implementing ICE as part of my RTCPeerConnection library](https://github.com/nickdesaulniers/node-rtc-peer-connection). I will soon pull the ICE parts out into their own lib.  This is also my first time posting to any IETF related discussion, so let me know if this is the wrong forum.

For things that are unclear in the ICE specifications, this is indeed the right forum. Welcome!

> I was curious, in [section 7.3.1](https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-00#section-7.3.1), it's not clear when it's ok to close the underlying transport socket when ICE processing has finished.

That section is a bit terse now when the SIP text has been moved away. The original text in RFC5245 gives guideline of 3 seconds after ICE processing moving to Completed state to accommodate for aggressive nomination: https://tools.ietf.org/html/rfc5245#section-8.3.1

That sounds like a good guideline to me.

I'd propose that we return the second paragraph from 5245 without the first (SIP forking specific) sentence to ICEbis 7.3.1. That is, add the following:

   Once ICE processing
   has reached the Completed state for all peers for media streams using
   those candidates, the agent SHOULD wait an additional three seconds,
   and then it MAY cease responding to checks or generating triggered
   checks on that candidate.  It MAY free the candidate at that time.
   Freeing of server reflexive candidates is never explicit; it happens
   by lack of a keepalive.  The three-second delay handles cases when
   aggressive nomination is used, and the selected pairs can quickly
   change after ICE has completed.

> For example, in my implementation (Full, Full-Trickle), I can see the valid list being built up.  When initiating an offer to Firefox in the controlling role, I see Firefox start responding with application level data once the first candidate I send the nomination for (aggressive nomination), though it will sometimes switch if I send a binding request for a higher priority candidate.

Switching to validated higher priority candidate is standard aggressive nomination behavior.

> It's not clear to me when it's safe to close the rest of the sockets for candidates I'm not using.  Should I leave them open for the rest of the connection (surely not)?  Should I timeout once ICE has stabilized?  What's a safe duration to use?  Or is there some other event that occurs during ICE processing that I should wait for, rather than a specific duration?

Completed state + 3 seconds is what seems the right thing to do. Any other opinions?

Cheers,
Ari

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 8 Jan 2016 08:51:38 -0800

> Completed state + 3 seconds is what seems the right thing to do. Any other opinions?

Aren't all candidates supposed to be using the same socket (same source UDP port number), to best aid firewall and NAT traversal?

-d

---

From: Nicholas Desaulniers <[email-masked]>
Date: Fri, 8 Jan 2016 08:58:27 -0800

I have a socket allocated per ip address per network interface.

Thanks,
~Nick Desaulniers
Open Source Zealot
Mozilla Corporation

---

From: Nicholas Desaulniers <[email-masked]>
Date: Fri, 8 Jan 2016 08:59:20 -0800

Ari,
Thanks for that concise response!  I think that addition would be a nice 
re-addition and would clarify my question.

Thanks,
~Nick Desaulniers
Open Source Zealot
Mozilla Corporation

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 8 Jan 2016 09:04:58 -0800

> I have a socket allocated per ip address per network interface.

Gotcha.  Can't do better than that!

-d