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.

Sign up for GitHub

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

Jump to bottom

TCP a:setup attribute for transport #190

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

TCP a:setup attribute for transport #190

robin-raymond opened this issue Apr 17, 2015 · 4 comments
Labels
1.1 PR exists

Comments

@robin-raymond
Copy link
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
Copy link
Contributor Author

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

@pthatcherg
Copy link

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
Copy link
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
Copy link
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 as completed Apr 26, 2015
robin-raymond pushed a commit that referenced this issue May 7, 2015
- sender.setTrack() updated to return a Promise, as noted in:
c006197 
#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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
1.1 PR exists
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@aboba @robin-raymond @pthatcherg