Re: [MMUSIC] Please Read and Comment: Re: ICE SDP/JSEP peace accords

[Roman Shpount <[e-mail]>]

On Tue, Jan 22, 2019 at 4:36 PM Adam Roach <[e-mail]> wrote:

> On 1/22/19 3:33 PM, Roman Shpount wrote:
>
> On Tue, Jan 22, 2019 at 4:25 PM Adam Roach <[e-mail]> wrote:
>
>> On 1/22/19 3:15 PM, Roman Shpount wrote:
>> > The issue is the offer generated when ICE restart is not initiated and
>> > TCP candidate is currently nominated. TCP candidate is the only
>> > candidate which is present in both offer and answer. It is also the
>> > default candidate. No UDP candidate will be added it any point during
>> > the offer/answer exchange.
>>
>>
>> This is what I tried to indicate with the use of an italicized "always"
>> in my previous reply.
>>
>> EVEN IF it is generating an offer when ICE restart is initiated and the
>> TCP candidate is nominated, Chrome will still always (always, always)
>> generate an SDP that includes a UDP candidate and use that candidate's
>> value in the m=/o= lines.
>>
>
> Unless I am mistaken, if ICE restart is not initiated, only the nominated
> candidate must be included. No other candidates must be present. If Chrome
> does not follow this, then it is most likely not complaint with either ICE
> or JSEP specifications.
>
>
> Based on the conversation I had with their engineers, that seems to be the
> case.
>

Based on RFC 5245 section 9.1.2.2 (
https://tools.ietf.org/html/rfc5245#section-9.1.2.2) this is wrong:

The agent MUST include candidate attributes for candidates matching the
default destination for each component of the media stream, and MUST NOT
include any other candidates.


Regards,
_____________
Roman Shpount