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

Does DtlsTransport really have a "disconnected"/retrying state?  I guess we
could make it "disconnected" any time the underlying IceTransport is
disconnected, but that adds complexity.  What value do we gain to make it
worthwhile?

On Tue, Jun 23, 2015 at 2:05 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>  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?)
>
>
>
>