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

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

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 24 Jun 2015 11:41:17 -0700
Message-ID: <CAJrXDUEFVhukS2e+nJR7K8VJJm7Hd0e98gT6SwHa5dSS7iu3kQ@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Jun 24, 2015 at 12:27 AM, Harald Alvestrand <harald@alvestrand.no>

>  On 06/23/2015 10:38 PM, Peter Thatcher wrote:
>  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?
> I don't know DTLS well enough to say..... I'm sure there are states where
> the ICE connection is working fine, but traffic isn't getting through
> because something's wrong at the DTLS layer - it would be important to
> clearly identify that we're in that state.

​The question is whether that's a temporary state or permanent state.  If
permanent, just use the "failed" state.

I don't know of any such temporary situations with DTLS.​

> Otherwise, the fewer states the better.

​Yes, the only downside is that the JS then needs to check both
DtlsTransport.state and DtlsTransport.transport.state to know the full
state.  I think I'm OK with that, but it's worth recognizing the tradeoff.​
Received on Wednesday, 24 June 2015 18:42:25 UTC

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