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> wrote:

>
>
>
>
>
>
> On Wed, Jun 24, 2015 at 12:27 AM, Harald Alvestrand <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
>