TCP active/passive/actpass/holdconn

[robin-raymond]

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?

[juberti]

You want RFC 6544 - the only thing needed is a single .tcpType property that is set to either active or passive.

[aboba]

Here is the proposal:

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"
};

[juberti]

lgtm