Re: Suggested resolution of Issue 849: Specify an AllowUnverifiedMedia RTCConfiguration property

Should I start doodle regarding the call time?

Regards,

_____________
Roman Shpount

On Wed, May 3, 2017 at 7:30 PM, Cullen Jennings (fluffy) <fluffy@cisco.com>
wrote:

>
> By happy to join a call on this. Let me be clear that I think is a very
> bad idea postpone DTLS handshake. I think the tls-id should be in the offer
> and both sides should use it.
>
>
> >
>
>
> > On May 3, 2017, at 2:00 PM, Roman Shpount <roman@telurix.com> wrote:
> >
> > On Wed, May 3, 2017 at 4:09 AM, T H Panton <thp@westhawk.co.uk> wrote:
> > For what it is worth I've come up with a scenario where this can happen,
> but I think it is unlikely.
> >
> > If you have
> > 1) an un-ordered or lossy signalling transport (SIP over UDP or JSON
> over an SCTP _unordered_ channel)
> > 2) are using trickle-ice which
> > 3) are sending a=candidates containing ufrag and password set
> >
> > Then you could (theoretically) have the situation where the candidate
> (with ufrag/pass) arrives before the answer with the fingerprint.
> >
> > If the ICE consent and DTLS handshakes complete (2 x rtt) before that
> delayed answer arrives, you could legitimately get
> > media sent and received (2.5 rtt) before the fingerprint can be used to
> verify the channel.
> >
> > This case seems to be legitimate but extremely unlikely.
> >
> > As Roman says, "prohibit to start DTLS handshake until the answer is
> received" will cover that unlikely case nicely.
> >
> >
> > Do you agree with me that it is a good idea to postpone DTLS handshake
> until answer is received?
> >
> > I see no benefit in allowing DTLS handshake to proceed before the answer
> is received by the end point, but I do see a lot of potential problems. As
> I have mentioned before the main motivation for doing this was to convert
> unusual call scenarios to the most common behavior and to avoid unverified
> media and handshake in the process. I think this would make the whole
> negotiation process easier to test and will prevent unexpected negotiation
> flows.
> >
> > Regards,
> > _____________
> > Roman Shpount
> >
>
>