RE: [ortc] RTCDtlsTransportState due to common Close Alert.

Yes, it does make sense to me that receipt of a Close Alert should cause a transition to "closed" rather than "failed". 

-----Original Message-----
From: Iñaki Baz Castillo via GitHub [mailto:sysbot+gh@w3.org] 
Sent: Tuesday, January 5, 2016 12:32 PM
To: public-ortc@w3.org
Subject: [ortc] RTCDtlsTransportState due to common Close Alert.

ibc has just created a new issue for https://github.com/openpeer/ortc:


== RTCDtlsTransportState due to common Close Alert. == Let's have an already established/connected DTLS connection (state = `connected`). The remote peer closes its side so sends a signaling "BYE" and also a DTLS Close Alert. Usually the DTLS Close Alert arrives before to us.

In this scenario (a common Close Alert rather than an "error"), what would be our `RTCDtlsTransportState` upon receipt of such a Close Alert? According to the spec it would become `failed`:


>closed
>The DTLS connection has been closed intentionally via a call to
stop(). Calling transport.stop() will also result in a transition to the "closed" state.

>failed
>The DTLS connection has been closed as the result of an error (such
as a DTLS alert or a failure to validate the remote fingerprint).

But that would trigger a `RTCDtlsTransportStateChangedEvent` and the app would be notified about a DTLS "failure" and would act according (for example by displaying a warning message to the user or whatever),  but after a few milliseconds the signaling "BYE" will arrive, invalidating such a warning.

So, would not make sense that, in this scenario in which we receive a DTLS Close Alert within a correctly connected DTLS transport, our `RTCDtlsTransportState` becomes `closed` instead of `failed`?

Please view or discuss this issue at
https://github.com/openpeer/ortc/issues/327 using your GitHub account

Received on Tuesday, 5 January 2016 22:21:43 UTC