I should also mention several other points about this: 1. Chrome doesn't do SO candidates even though it has ICE-TCP. TCP NAT traversal works so badly that the major argument for ICE-TCP is to allow for clients to talk to public servers even if they are behind TCP-only firewalls, and that doesn't require SO.
2. We just added ICE-TCP and we may also remove SO if experience shows it doesn't help. 3. WebRTC has its own COMSEC so we would want to disable TCPCINC for these settings in any case. So I think this is really an argument in favor of "don't worry too much about SO" -Ekr On Fri, Aug 28, 2015 at 10:18 AM, Eric Rescorla <[email protected]> wrote: > On Thu, Aug 27, 2015 at 11:56 PM, David Mazieres < > [email protected]> wrote: > >> Eric Rescorla <[email protected]> writes: >> >> >> 1. Does TCP-SO really exist in the wild, and if so under what >> >> circumstances (NAT, no NAT, etc.)? >> > >> > TCP-SO definitely exists in the wild. We do it in Firefox's ICE stack. >> >> So I'm not familiar with ICE over TCP, though I see there's now an >> RFC6544 on this. Is that what firefox does? That's great information. >> >> With RFC6544, could the controlling/controlled roles be used to break >> ties? E.g., with TCP-ENO, could the controlling peer just always set >> b=1? > > > The problem is that there are situations where each side thinks it is > controlling > ("role conflicts"). RFC 5245 has the tiebreaker field to resolve this. > > -Ekr > > >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
