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:56 PM Roman Shpount <[e-mail]> wrote:

> Hi Eric,
>
> On Wed, Oct 24, 2018 at 4:45 PM Eric Rescorla <[e-mail]> wrote:
>
>> On Wed, Oct 24, 2018 at 1:12 PM Roman Shpount <[e-mail]> wrote:
>>
>>> 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.
>> "
>>
>> Updated offer is still present when ice2 is not used.
>
> When ice2 is used, nominated candidate still ends us as default candidate
> in the subsequent offer/answer exchanges, which means ICE-TCP candidate
> ends up in the m= line.
>

For the same reasons as JSEP is going to reference ICE-bis, you should do
so here, and just punt this problem.


> 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.
>>
>
> I think this only covers the initial offer, but not the subsequent
> exchanges.
>

Well, sort of: https://github.com/rtcweb-wg/jsep/issues/854

-Ekr



> Regards,
> _____________
> Roman Shpount
>