W3C home > Mailing lists > Public > public-ortc@w3.org > January 2016

[ortc] RTCDtlsTransportState due to common Close Alert.

From: Iñaki Baz Castillo via GitHub <sysbot+gh@w3.org>
Date: Tue, 05 Jan 2016 20:32:10 +0000
To: public-ortc@w3.org
Message-ID: <issues.opened-125045155-1452025929-sysbot+gh@w3.org>
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 20:32:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 5 January 2016 20:32:12 UTC