"ICE Agent" and "ICE engine" versus "ICE Transport" #132

Closed
aboba opened this Issue Jul 15, 2014 · 0 comments

Projects

None yet

1 participant

@aboba
Contributor
aboba commented Jul 15, 2014

In a number of places, the ORTC API uses terms such as "ICE Agent" and "ICE engine" that make sense in WebRTC 1.0, but do not make sense in ORTC API, where there are ICE Transport objects that can be configured individually (and can have separate states).

Proposed resolution:

In Section 3.9 change:

"all
The ICE engine gathers all types of candidates when this value is specified.

nohost
The ICE engine gathers all ICE candidate types except for host candidates.

relay
The ICE engine must only gather media relay candidates such as candidates passing through a TURN server. This can be used to reduce leakage of IP addresses in certain use cases."

To:

"
all
The ICE transport gathers all types of candidates when this value is specified.

nohost
The ICE transport gathers all ICE candidate types except for host candidates.

relay
The ICE transport must only gather media relay candidates such as candidates passing through a TURN server. This can be used to reduce leakage of IP addresses in certain use cases."

In Section 3.10, change:

"
new
The ICE Agent is gathering addresses and/or waiting for remote candidates to be supplied.

checking
The ICE Agent has received remote candidates on at least one component, and is checking candidate pairs but has not yet found a connection. In addition to checking, it may also still be gathering.

connected
The ICE Agent has found a usable connection for all components but is still checking other candidate pairs to see if there is a better connection. It may also still be gathering.

completed
The ICE Agent has finished gathering and checking and found a connection for all components. Open issue: it is not clear how the non controlling ICE side knows it is in the state.

disconnected
Liveness checks have failed for one or more components. This may trigger intermittently (and resolve itself without action).

closed
The ICE Agent has shut down and is no longer responding to STUN requests."

To:

"
new
The ICE Transport is gathering addresses and/or waiting for remote candidates to be supplied.

checking
The ICE Transport has received at least one remote candidate, and is checking candidate pairs but has not yet found a connection. In addition to checking, it may also still be gathering.

connected
The ICE Transport has found a usable connection, but is still checking other candidate pairs to see if there is a better connection. It may also still be gathering.

completed
The ICE Transport has finished gathering and checking and found a connection. There is no such state for the ICE non-controlling peer.

disconnected
Liveness checks have failed. This may trigger intermittently (and resolve itself without action).

closed
The ICE Transport has shut down and is no longer responding to STUN requests."

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Jul 16, 2014
Robin Raymond Added section on WebRTC 1.0 compatibility issues, responding to Issue #…
…66

Added Identity support, as described in Issue #78
Reworked getStats method, as described in Issue #85
Removed ICE restart method described in Issue #93
Addressed CNAME and synchronization context issues described in Issue #94
Fixed WebIDL issues noted in Issue #97
Addressed NITs described in Issue #99
DTLS transport issues fixed as described in Issue #100
ICE transport issues fixed as described in Issue #101
ICE transport controller fixes made as described in Issue #102
Sender and Receiver object fixes made as described in Issue #103
Fixed RTCRtpEncodingParameter default issues described in Issue #104
Fixed 'Big Picture' issues descibed in Issue #105
Fixed RTCRtpParameter default issues described in Issue #106
Added a multi-stream capability, as noted in Issue #108
Removed quality scalability capabilities and parameters, as described in Issue #109
Added scalability examples as requested in Issue #110
Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue #111
Removed header extensions from RTCRtpCodecParameters as described in Issue #113
Addressed RTP/RTCP non-mux issues with IdP as described in Issue #114
Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue #116
Added layering diagrams as requested in Issue #117
Added a typedef for payload type, as described in Issue #118
Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue #121
Added explanation of Voice Activity Detection (VAD), responding to Issue #129
Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue #130
Added RFC 6051 to the list of header extensions and removed RFC 5450, as noted in Issue #131
Addressed ICE terminology issues, as described in Issue #132
Separated references into Normative and Informative, as noted in Issue #133
6f8216a
@aboba aboba closed this Jul 17, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment