On Wed, Jun 24, 2015 at 12:27 AM, Harald Alvestrand <harald@alvestrand.no<mailto: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. [Raju] Before a connected state is reached, a DTLS could go into disconnected state due to Fatal Alert Messages related to certificate issues (unknown CA, fingerprints don’t match etc.) or some other handshake issues. Once connected state is reached, SRTP decoding issues could result in DTLS alerts. An implementation may choose to go into disconnected state when this happens. Other implementations may choose to ignore such Alerts as going to disconnected state allows attacker to inject invalid pkts (with valid RTP hdr) into an otherwise healthy stream to trigger alerts and disrupting communication. https://tools.ietf.org/html/rfc5764#section-7.3.1 talks about these alerts, but does not suggest any action to take on such alerts. BR Raju
Received on Wednesday, 24 June 2015 22:01:37 UTC