Re: [bfcpbis] Eric Rescorla's Discuss on draft-ietf-bfcpbis-rfc4583bis-26: (with DISCUSS and COMMENT)

[Roman Shpount <[e-mail]>]

On Wed, Oct 24, 2018 at 3:54 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Wed, Oct 24, 2018 at 12:50 PM Roman Shpount <[e-mail]> wrote:
>
>> On Wed, Oct 24, 2018 at 3:23 PM Eric Rescorla <[e-mail]> wrote:
>>
>>> S 9.
>>> >      transport is used for the default candidate, then the 'm' line
>>> proto
>>> >      value MUST be 'UDP/TLS/BFCP'.  If TCP transport is used for the
>>> >      default candidate, the 'm' line proto value MUST be
>>> 'TCP/DTLS/BFCP'.
>>> >
>>> >         Note: Usage of ICE with protocols other than UDP/TLS/BFCP and
>>> >         TCP/DTLS/BFCP is outside of scope for this specification.
>>>
>>> this is very different from any other use of ICE, and I'm not sure
>>> it's interoperable, unless you require that only TCP or only UDP
>>> candidates be offered (which you do not seem to). The reason is that
>>> with ICE you can flip between different candidates as part of the
>>> negotiation. So what happens if I initially get a UDP candidate and
>>> then via aggressive nomination settle on TCP (or vice versa). DTLS and
>>> TLS aren't really interoperable in that way. It would be far better to
>>> do what WebRTC does and when you do ICE, always do DTLS even if it's
>>> over TCP.
>>>
>>>
>> When ICE is used, DTLS is always used exactly for the reasons you
>> mention.  End points only allowed to use 'UDP/TLS/BFCP', which is DTLS over
>> UDP, or 'TCP/DTLS/BFCP', which is DTLS over TCP. DTLS over UDP is only
>> named  'UDP/TLS/BFCP' instead of  'UDP/DTLS/BFCP' for legacy interop
>> reasons, since some implementations apparently already added support for
>> this.  Please note that naming of BFCP over DTLS over UDP  as
>> 'UDP/TLS/BFCP'  is similar to naming RTP over DTLS over UDP as
>> "UDP/RTP/TLS/SAVP".
>>
>
> Ah, I missed this. But then I do wonder whether it's really useful to have
> two proto versions here, rather than just UDP/TLS/BFCP. We didn't find it
> helpful in JSEP....
>
>
ICE SDP draft still requires a re-INVITE after nomination process is
completed where c= and m= line are updated to reflect the nominated
candidate. If nominated candidate an ICE-TCP candidate, then proto in m=
line would be 'TCP/DTLS/BFCP' to reflect this. In cases when non ICE-TCP
candidate is used, the proto in m= line will be 'UDP/TLS/BFCP'. Also, all
subsequent offer/answer exchanges, which do not initiate ICE restart are
supposed to use the proto value of nominated candidate in the m= line. So,
the only reason for existence of 'TCP/DTLS/BFCP' proto is to differentiate
if UDP or TCP candidate is used after the nomination.

How did you solve this issue in JSEP? I was pretty sure
that 'TCP/RTP/DTLS/SAVP' and 'TCP/DTLS/SCTP' were used there for this
purpose, but I could have missed one of the updates.

Regards,
_____________
Roman Shpount