TCP a:setup attribute for transport #190

Closed
robin-raymond opened this Issue Apr 17, 2015 · 4 comments

Projects

None yet

3 participants

@robin-raymond
Contributor

We do have a way to advertise "so", "active" and "passive" TCP candidates but we have no way to tell a transport to behave in "active", "passive" or "actpass" modes of operation.

@robin-raymond robin-raymond added the 1.1 label Apr 17, 2015
@pthatcherg

I think this would make sense:

Browsers gather active TCP candidates and only active TCP candidates. Servers and other endpoints can gather active or passive candidates.

@aboba
Contributor
aboba commented Apr 17, 2015

RFC 6544 Section 4.5 says:

If the default candidate is TCP-based, the agent MUST include the
a=setup and a=connection attributes from RFC 4145 [RFC4145],
following the procedures defined there as if ICE were not in use. In
particular, if an agent is the answerer, the a=setup attribute MUST
meet the constraints in RFC 4145 based on the value in the offer....

In the case of DTLS-SRTP [RFC5764], the
directionality attributes (a=setup) are utilized strictly to
determine the direction of the DTLS handshake. Directionality of the
TCP connection establishment is determined by the ICE attributes and
procedures defined here.

[BA] I believe that the implication is that in WebRTC (where ICE is always used) a:=setup is only for DTLS-SRTP.

@aboba
Contributor
aboba commented Apr 19, 2015

Add the following to Section 3.11.3:
Browsers MUST gather active TCP candidates and only active TCP candidates. Servers and other endpoints MAY gather active, passive or so candidates.

@aboba aboba closed this Apr 26, 2015
@robin-raymond robin-raymond pushed a commit that referenced this issue May 7, 2015
Robin Raymond - sender.setTrack() updated to return a Promise, as noted in:
#148

- Clarified handling of incoming connectivity checks prior to calling iceTransport.start(), as noted in:
#170

- Clarified handling of incoming DTLS packets, as noted in:
#173

- Added RTCIceGatherer as an optional argument to the RTCIceTransport constructor, as noted in:
#174

- Clarified handling of contradictory RTP/RTCP multiplexing settings, as noted in:
#185

- Clarified error handling relating to RTCIceTransport, RTCDtlsTransport and RTCIceGatherer objects in the "closed" state, as noted in:
#186

- Added component method and createAssociatedGatherer() method to the RTCIceGatherer object, as noted in:
#188

- Added close() method to the RTCIceGatherer object as noted in:
#189

- Clarified behavior of TCP candidate types, as noted in:
#190

- Clarified behavior of iceGatherer.onlocalcandidate, as noted in:
#191

- Updated terminology in Section 1.1 as noted in:
#193

- Updated RTCDtlsTransportState definitions, as noted in:
#194

- Updated RTCIceTransportState definitions, as noted in:
#197
c006197
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment