RE: tcpType parameter

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

Received on Friday, 18 April 2014 19:35:30 UTC