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

I have provided my comments on pull request. I think this is a reasonable
way forward but the language requires clarification.

We will also need to update ice-sip-sdp to deal with some of the
ambiguities:

1. We need to specify that protocol in the answer must match protocol in
the offer, even if none of the ICE candidates in the answer match. For
instance, if an offer is received with TCP/DTLS/RTP/SAVPF , but the answer
contains only UDP candidates, answer MUST sill use  TCP/DTLS/RTP/SAVPF

2. We need to specify what address and port must be used if protocol in the
m= line does not match any of the candidates. I think using IN IP4 0.0.0.0
and port 9 is a safe option which avoids ICE mismatch.

Regards,
_____________
Roman Shpount

On Fri, Jan 25, 2019 at 1:58 PM Suhas Nandakumar <suhasietf@gmail.com>
wrote:

> I think Adam’s Pr on this topic is reasonable way forward.
>
> Thanks
> Suhas
>
> On Fri, Jan 25, 2019 at 10:50 AM Roman Shpount <roman@telurix.com> wrote:
>
>> On Fri, Jan 25, 2019 at 9:05 AM Flemming Andreasen <fandreas@cisco.com>
>> wrote:
>>
>>>
>>>
>>> On 1/22/19 4:42 PM, Adam Roach wrote:
>>>
>>> On 1/22/19 3:40 PM, Roman Shpount wrote:
>>>
>>> On Tue, Jan 22, 2019 at 4:36 PM Adam Roach <adam@nostrum.com> wrote:
>>>
>>>> On 1/22/19 3:33 PM, Roman Shpount wrote:
>>>>
>>>> On Tue, Jan 22, 2019 at 4:25 PM Adam Roach <adam@nostrum.com> 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.
>>>
>>>
>>> I'm not disagreeing.
>>>
>>>
>>> So where does this leave us ?
>>>
>>>
>> I think JSEP sections 5.1.2 (
>> https://tools.ietf..org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2
>> <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2>)
>> and potentially 5.2.2 (
>> https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2)
>> would need to be updated to be consistent with each other and mmusic drafts.
>>
>> There is currently a discussion on RTCWEB of pull request
>> https://github.com/rtcweb-wg/jsep/pull/862/files which attempts to fix
>> this.
>>
>> Regards,
>> _____________
>>
>> Roman Shpount
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>