Re: PR for adding RtpSender.transport, RtpReceiver.transport, RTCDtlsTransport, RTCIceTransport, etc

On 06/23/2015 12:14 AM, Peter Thatcher wrote:
>
>
>
>         2.  What states should we have in DtlsTransport.state?  I have
>         new/connecting/connected/closed/failed, which closely matches
>         both the ICE state and the ORTC DtlsTransportState.  However,
>         the ORTC state does not have "failed", whereas the ICE state
>         does. So, I included "failed" even though it's missing in ORTC
>         (or rather, closed the purpose of failed as well).
>
>
>     Well, it certainly can fall, so it should have a state.
>
>
> ​ Yes, but the question is not "​should failure have state", but 
> rather "should failure have the closed state, or a separate 'failed'" 
> state.  ICE has a separate "failed" state, so having one would be more 
> consistent with ICE.
>
ICE actually has 3 relevant states:

- "failed" - we never got there, expectation is that it will not heal
- "disconnected" - something broke, may or may not heal itself
- "closed" - JS deliberately went out and closed it

(The state diagram shows arrows both ways between "failed" to 
"disconnected"; I'm not sure whether that arrow is real or not - can't 
quite imagine why that should be allowed to happen).

If reflecting that in DtlsTransport, it would be

- "failed" - something's wrong, we won't retry
- "disconnected" - something's wrong, we're retrying
- "closed" - (since we don't have a close() function, what does it mean?)