RTCDtlsTransportState due to common Close Alert. #327

ibc opened this Issue Jan 5, 2016 · 1 comment


None yet

2 participants

ibc commented Jan 5, 2016

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:

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.

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?

aboba commented Jan 6, 2016

I agree that RTCDtlsTransportState should transition to "closed" on receipt of a Close Alert, rather than "failed".

@aboba aboba added a commit that referenced this issue Jan 6, 2016
@aboba aboba DTLS alerts and RTCDtlsTransportState
Fix for #327
@ibc ibc added a commit to ibc/mediasoup that referenced this issue Jan 6, 2016
@ibc ibc Transport: Set dtlsState to 'closed' instead of 'failed' upon receipt…
… of a DTLS Close Alert (related to w3c/ortc#327)
@aboba aboba closed this Jan 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment