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

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 24 Jun 2015 14:13:56 -0700
Message-ID: <CABcZeBM-ed0J6UNA=T1r2Xi0UiJCTD9wQnw1b9+D+GgFUYJW0Q@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Jun 24, 2015 at 11:41 AM, Peter Thatcher <pthatcher@google.com>
wrote:

>
>
> On Wed, Jun 24, 2015 at 12:27 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>>  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.​
>

That's correct.

-Ekr


>
>
>> 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 21:15:15 UTC

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