Re: tcpType parameter

Does it need to be |RTCTcpCandidateType? tcpType|?


On Fri, Apr 18, 2014 at 12:35 PM, Bernard Aboba <Bernard.Aboba@microsoft.com
> wrote:

> This should do it:
>
> dictionary RTCIceCandidate {
>     DOMString           foundation;
>     unsigned long       priority;
>     DOMString           ip;
>     RTCIceProtocol      protocol;
>     unsigned short      port;
>     RTCIceCandidateType type;
>     RTCTcpCandidateType tcpType = null;
>     DOMString?          relatedAddress = "";
>     unsigned short?     relatedPort = null;
> };
>
>
> enum RTCTcpCandidateType {
>     "active",
>     "passive",
>     "so"
> };
>
>
>
>
>
>
> ________________________________________
> From: Justin Uberti [juberti@google.com]
> Sent: Thursday, April 17, 2014 9:43 AM
> To: Robin Raymond
> Cc: public-ortc@w3.org
> Subject: 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
> <mailto: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
>
>
>
>