TCP active/passive/actpass/holdconn

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 Wednesday, 16 April 2014 13:56:24 UTC