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

[Eric Rescorla <[e-mail]>]

On Wed, Oct 24, 2018 at 1:12 PM Roman Shpount <[e-mail]> wrote:

> 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.
>

I don't believe any WebRTC stack does this, and to the best of my
knowledge, JSEP does not require it.

Moreover, that's not how I read the ICE-SDP draft, at least as far as
ICE-bis goes.
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-21#section-3.3.4

"

 However, If the support for 'ice2' ice-option is in use, the
   nominated candidate is noted and sent in the subsequent offer/answer
   exchange as the default candidate and no updated offer is needed to
   fix the default candidate.
"




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.
>

For DTLS-SRTP, JSEP requires that you generate UDP/TLS/RTP/SAVPF regardless
of the ICE candidates. Similarly, for datachannels, you must generate
UDP.DTLS/SCTP.

>
> Regards,
> _____________
> Roman Shpount
>
>