Re: TCP active/passive/actpass/holdconn

I think it can be a lot simpler. For ICE-TCP (RFC 6544), you just need a
.tcpType parameter indicating whether a TCP candidate is active or passive
(or s-o, but I think realistically active/passive are the only things we
will support)


On Wed, Apr 16, 2014 at 3:55 PM, Robin Raymond <robin@hookflash.com> wrote:

>
> http://tools.ietf.org/html/rfc4145
>
> To support this RFC, we have TCP candidates being offered. These
> candidates are effectively "passive" candidates in that they listen for
> incoming TCP connections.
>
> However, if we assume all ORTC clients support TCP as a must then we can
> assume that all clients are capable of initiating a connect (active) when
> they receive a passive candidate. To control the active/passive role, you
> need only feed the candidate or not to the remote party. Essentially, all
> ORTC clients would be "actpass", but a higher layer can chose to make one
> side or the other active/passive by virtual of filtering the TCP candidate.
>
> The only issue I see is "existing" vs "new" and "connhold". For
> "connhold", the ability to purge TCP candidates (i.e. setRemoteCandidates
> with filtered TCP on both sides) would address this feature since it would
> disconnect TCP upon filtering. For re-use, there's nothing to do since the
> candidates match. For forcing a new connection, it could be that the web
> app developer purges the TCP candidate momentarily then puts the candidate
> back thus effectively causing a disconnect and a reconnection.
>
> So in my mind, the only thing we need to do to support these modes is to:
> a) assume all ORTC clients must support TCP (is this true?)
> b) web apps can filter TCP candidates from remote client
> c) allow purging of TCP candidates by "setRemoteCandidates(...)" without
> TCP candidate
>
> That's it in my mind. Am I missing something?
>
>
> -Robin
>
>
>