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

Hi Roman,

Clarification question inline

On Fri, Jan 25, 2019 at 11:35 AM Roman Shpount <roman@telurix.com> wrote:

> 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
>
>
[Suhas] If none of the candidates match, shouldn't we report ice-mismatch.
So in the example, if one side has just UDP and other side just TCP , we
can't proceed with the connection, isn't it ?

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