TCP a:setup attribute for transport

[robin-raymond]

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]

related:
https://tools.ietf.org/html/rfc6544
https://tools.ietf.org/html/rfc4145

[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]

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]

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.