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

Hi Peter,
Thanks for the updates.




+


+          <dd>The transport has failed as the result of an error (such


+          as a failure to validate the remote fingerprint).</dd>


+        </dl>


+      </section>


Having a read-only attribute, to keep the failure code, from a list of predefined failure codes, associated to ‘failed’ state would help debugging and resolution of the failure.

In addition to that, I am wondering having another read-only attribute ‘infoString’, with even more details, which will help user/application understand the reason for DTLS failure.
The same attribute may be updated even during other states as the implementation see it fits.

BR
Raju


From: Peter Thatcher [mailto:pthatcher@google.com]
Sent: Friday, July 24, 2015 7:05 AM
To: Makaraju, Maridi Raju (Raju)
Cc: Eric Rescorla; Harald Alvestrand; public-webrtc@w3.org
Subject: Re: PR for adding RtpSender.transport, RtpReceiver.transport, RTCDtlsTransport, RTCIceTransport, etc

Is everyone OK with the current state of the PR now?  I made all the edits to address feedback that had consensus.  Is there anything else?

On Wed, Jun 24, 2015 at 3:01 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com<mailto:Raju.Makaraju@alcatel-lucent.com>> wrote:



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