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 10:05 PM Eric Rescorla <[e-mail]> wrote:

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

We did punt the problem. We have defined proto values for all possible
protocol variations. How these proto values are going to be used with ICE
is up to ICE or ICE-bis RFCs. In the worst case  'TCP/DTLS/SCTP' ends up
being just a place holder which is never used. Since RTP and datachannel
both have proto value for the same purpose, this should not be that big of
an issue.


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

I will address this in the github. Thank you for providing the reference.

Regards,
_____________
Roman Shpount