Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TCP active/passive/actpass/holdconn #63

robin-raymond opened this issue Apr 16, 2014 · 3 comments

TCP active/passive/actpass/holdconn #63

robin-raymond opened this issue Apr 16, 2014 · 3 comments


Copy link

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?

Copy link

juberti commented Apr 17, 2014

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

Copy link

aboba commented Apr 22, 2014

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 {

Copy link

juberti commented Apr 23, 2014


robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Apr 29, 2014
- Support for contributing sources removed (re-classified as a 1.2 feature), as described in w3c#27
- Cleanup of DataChannel construction, as described in w3c#60
- Separate proposal on simulcast/layering, as described in w3c#61
- Separate proposal on quality, as described in w3c#62
- Fix for TCP candidate type, as described in w3c#63
- Fix to the fingerprint attribute, as described in w3c#64
- Fix to RTCRtpFeatures, as described in w3c#65
- Support for retrieval of remote certificates, as described in w3c#67
- Support for ICE error handling, described in w3c#68
- Support for Data Channel send rate control, as described in w3c#69
- Support for capabilities and settings, as described in w3c#70
- Removal of duplicate RTCRtpListener functionality, as described in w3c#71
- ICE gathering state added, as described in w3c#72
- Removed ICE role from the ICE transport constructor, as described in w3c#73
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants