Support for ICE TCP (RFC 6544) #41

Closed
aboba opened this Issue Apr 2, 2014 · 4 comments

Projects

None yet

3 participants

@aboba
Contributor
aboba commented Apr 2, 2014

At IETF 89, the minutes indicate that there was consensus to make ICE-TCP (RFC 6544) a MUST implement.

See:
http://www.ietf.org/proceedings/89/minutes/minutes-89-rtcweb (Transport discussion)
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11958.html

However, there is no protocol attribute in RTCIceCandidate to indicate if the candidate uses UDP or TCP.

Fix:

dictionary RTCIceCandidate {
DOMString foundation;
unsigned long priority;
DOMString ip;
unsigned short port;
RTCIceProtocol protocol;
RTCIceCandidateType type;
DOMString? relatedAddress;
unsigned short? relatedPort;
};

enum RTCIceProtocol {
"udp:,
"tcp"
}

@aboba
Contributor
aboba commented Apr 2, 2014

Also, how do we know if a browser supports ICE-TCP or not?

@aboba
Contributor
aboba commented Apr 4, 2014

Some ongoing discussion on the IETF RTCWEB list relating to all the implications of supporting ICE TCP:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11988.html

One related question is whether the TCP/UDP transport needs to be exposed anywhere else other than in the RTCIceCandidate object (e.g. RTCIceServer object, etc.).

@martinthomson
Member

One related question is whether the TCP/UDP transport needs to be exposed anywhere else other than in the RTCIceCandidate object (e.g. RTCIceServer object, etc.).

Even if it seemed like a good idea, I'd want to resist creating externalities in that way. If the browser can't handle the consequences of using TCP rather than UDP without pushing its problems on the using application, then I'd rather we didn't include this feature at all. My guess is that it's manageable without more API hooks.

@aboba
Contributor
aboba commented Apr 4, 2014

OK. Looks like the enum is sufficient for now.

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Apr 12, 2014
Robin Raymond Support for contributing source information added, as described in w3…
…c#27

Support for control of quality, resolution, framerate and layering added, as described inhttps://github.com/openpeer/ortc/issues/31
RTCRtpListener object added and figure in Section 1 updated, as described in w3c#32
More complete support for RTP and Codec Parameters added, as described in w3c#33
Data Channel transport problem fixed, as described in w3c#34
Various NITs fixed, as described in w3c#37
Section 2.2 and 2.3 issues fixed, as described in w3c#38
Default values of some dictionary attributes added, to partially address the issue described in w3c#39
Support for ICE TCP added, as described in w3c#41
Fixed issue with sequences as attributes, as described in w3c#43
Fix for issues with onlocalcandidate, as described in w3c#44
Initial stab at a Stats API, as requested in w3c#46
Added support for ICE gather policy, as described in w3c#47
b536737
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment