W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 23 Jun 2015 11:05:44 +0200
Message-ID: <55892168.2070500@alvestrand.no>
To: public-webrtc@w3.org
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?)
Received on Tuesday, 23 June 2015 09:06:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC