Re: [MMUSIC] Is ice-mismatch media or session level?

[Roman Shpount <[e-mail]>]

Done.
_____________
Roman Shpount


On Fri, May 24, 2019 at 5:43 PM Suhas Nandakumar <[e-mail]>
wrote:

> Hi Roman
>
> Please go ahead with PR on that branch
>
> Thanks
> Suhas
>
> On Sat, May 25, 2019 at 3:07 AM Roman Shpount <[e-mail]> wrote:
>
>> Hi Suhas,
>>
>> I have looked at ice-mismatch branch and I think there is a slight
>> confusion there between presence of a=ice-mismatch in the answer and ICE
>> mismatch condition (ICE validation procedures failing for the answer).
>>
>> There are three distinct conditions when m= line in the answer is
>> processed:
>>
>> In case a=ice-mismatch is included in only some m= lines out of several,
>> ICE should not be used only for these specific m= lines and RFC 3264
>> procedures should be followed instead for these m= lines only.
>>
>> In case if offerer did not include any ICE attributes (offerer does not
>> support ICE) or if offerer included a=mismatch into all m= lines, ICE
>> should be terminated for the entire sessions and RFC 3264 procedures should
>> be followed instead for the whole session.
>>
>> In case if ICE validation procedures failed for one or more m= line in
>> the answer (answerer detected ICE mismatch), the behavior is unspecified
>> (answerer will likely terminate the session or emit a groan of unearthly
>> pain and die) .
>>
>> Let me know if you want a pull request on this branch.
>> _____________
>>
>> Roman Shpount
>>
>>
>> On Mon, May 20, 2019 at 5:03 PM Roman Shpount <[e-mail]> wrote:
>>
>>> Hi All,
>>>
>>> Few comments about this:
>>>
>>> 1. Section 3.2.5 needs to be rewritten to specify that Verifying ICE
>>> Support procedures is per m= line:
>>>
>>> First change old text:
>>>
>>> If this condition is not met, the agents MUST process the SDP based on
>>> normal [RFC3264] procedures, without using any of the ICE mechanisms
>>> described in the remainder of this specification with the few exceptions
>>> noted below:
>>>
>>> First change new text:
>>>
>>> If this condition is not met, the agents MUST process the SDP *for the
>>> media stream* based on normal [RFC3264] procedures, without using any
>>> of the ICE mechanisms described in the remainder of this specification with
>>> the few exceptions noted below:
>>>
>>> Second change old text:
>>>
>>> In some cases, controlling/initiator agent may receive the SDP answer
>>> that may omit "a=candidate" attributes for the media streams, and instead
>>> include a session level "a=ice-mismatch" attribute.  This signals to the
>>> offerer that the answerer supports ICE, but that ICE processing was not
>>> used for this session.  This specification provides no guidance on how an
>>> agent should proceed in such a failure case.
>>>
>>> Second change new text:
>>>
>>> In some cases, controlling/initiator agent may receive the SDP
>>> answer that may omit "a=candidate" attributes for the media *stream*,
>>> and instead include a *media *level "a=ice-mismatch" attribute.
>>> This signals to the offerer that the answerer supports ICE, but that
>>> ICE processing was not used for this *media stream*.  In this case,
>>> ICE processing MUST be terminated for this media stream and SDP for this
>>> media stream MUST be processed based on normal [RFC3264] procedures.
>>>
>>> 2. Section 3.3.3 says "If the answer does not indicate that the answerer
>>> supports ICE, or if the offerer detects an ICE mismatch in the answer, the
>>> offerer MUST terminate the usage of ICE". This needs to be clarified that
>>> if "a=ice-mismatch" attribute is included in the m= line, ICE processing
>>> MUST be terminated for this m= line only and this m= line MUST be processed
>>> based on procedures described in RFC 3264. If "a=ice-mismatch" is included
>>> in all m= lines in the answer, then ICE processing MUST be terminated for
>>> the entire session.
>>>
>>> 3. We need to specify somewhere that a=ice-mismatch is only allowed in
>>> the answer and MUST not be present in the offer.
>>>
>>> P.S. This would be much easier as a pull request but the repo is out of
>>> date.
>>> _____________
>>> Roman Shpount
>>>
>>>
>>> On Thu, May 16, 2019 at 4:28 PM Suhas Nandakumar <[e-mail]>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, May 16, 2019 at 12:25 AM Christer Holmberg <
>>>> [e-mail]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> >>>> I am inclined to leave it as media-level attribute. I am not sure
>>>>> what more clarification is needed in the text today ?
>>>>>
>>>>> >>
>>>>>
>>>>> >>> Are the clarifications Roman suggested below already included ?
>>>>>
>>>>> >
>>>>>
>>>>> >> I am finding it hard to parse suggested clarification. I am sure I
>>>>> am missing something.
>>>>>
>>>>> >
>>>>>
>>>>> > Roman suggested ice-mismatch should be defined for both media- and
>>>>> session-level.
>>>>>
>>>>> >
>>>>>
>>>>> > Looking further at the current text, I'm not sure I agree since
>>>>> there really isn't any normative behavior associated with receiving
>>>>> ice-mismatch.
>>>>>
>>>>> > Thus, I'd suggest simply keeping it as-is and media-level only.
>>>>>
>>>>>
>>>>>
>>>>> No matter whether it's session and/or media level, I still think there
>>>>> needs to be normative behavior associated with receiving ice-mismatch.
>>>>>
>>>>>
>>>>>
>>>>> Section 5.4 of RFC 8445 says:
>>>>>
>>>>>
>>>>>
>>>>>    "Each using protocol needs to define whether the using protocol is
>>>>>
>>>>>    vulnerable to ICE mismatch, how ICE mismatch is detected, and
>>>>> *whether*
>>>>>
>>>>> *   specific actions need to be taken when ICE mismatch is detected*."
>>>>>
>>>>
>>>> [Suhas] RFC5245 never defined a normative behavior on how a
>>>> ice-mismtach needs to be
>>>> handled and I do agree with the intent there.
>>>>
>>>> ice-sip-sdp says this today
>>>>
>>>> Also to note, this specification provides no guidance on how an
>>>>    controlling/initiator agent should proceed in scenarios where the the
>>>>    SDP answer includes "a=ice-mismatch" from the peer.
>>>>
>>>>
>>>> I am inclined to leave it as it is. RFC8445 doesn't mandate it either
>>>> (referring to  *whether*
>>>>
>>>> *   specific actions need to be taken"*
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, May 12, 2019 at 8:41 PM Flemming Andreasen <mailto:
>>>>> [e-mail]> wrote:
>>>>>
>>>>> Based on the errata, it seems like the intent was for to be
>>>>> media-level. I'd suggest we keep it that way and add the clarifications you
>>>>> outline below.
>>>>>
>>>>>
>>>>>
>>>>> If people feel otherwise, please speak up no later than May 19.
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>> -- Flemming (with chair hat on)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/29/19 4:44 PM, Roman Shpount wrote:
>>>>>
>>>>> Hi Christer,
>>>>>
>>>>>
>>>>>
>>>>> Thank you for reviewing and responding.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Apr 27, 2019 at 1:48 PM Christer Holmberg <mailto:
>>>>> [e-mail]> wrote:
>>>>>
>>>>> Before we just change something back we need to think what the reason
>>>>> for the change to media-level was. Could it be related to RTCWEB?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This is definitely not RTCWEB related, since RTCWEB should never
>>>>> generate ice-mismatch or use it for any reason.
>>>>>
>>>>>
>>>>>
>>>>> The ice-mismatch attribute was session only according to RFC 5245
>>>>> Section 21..1.4 (https://tools.ietf.org/html/rfc5245#section-21.1.4).
>>>>> At the same time, according to RFC 5245 Section 15..3 (
>>>>> https://tools.ietf.org/html/rfc5245#section-15.3), ice-mismatch is
>>>>> media level attribute only. This being said, according to RFC 5245 Section
>>>>> 6.1 (https://tools.ietf.org/html/rfc5245#section-6.1), ice-mismatch
>>>>> applies to the whole session, but it is specified per m= line. According to
>>>>> errata 3149 (https://www.rfc-editor.org/errata/eid3149), ice-mismatch
>>>>> should be media level. So, it is a bit of a mess.
>>>>>
>>>>>
>>>>>
>>>>> I can change ice-mismatch back to media level, but what we need to
>>>>> clarify then is the following: If ice-mismatch is present in the m= line,
>>>>> does it stop ICE processing for the whole session or for this m= line only?
>>>>>
>>>>>
>>>>>
>>>>> If it stops ICE processing for the whole session then it makes little
>>>>> or no sense being specified per m= line. If it only stops processing for
>>>>> specific m= line, then ice-mismatch probably also makes sense at the
>>>>> session level to stop ICE processing for the whole session.
>>>>>
>>>>>
>>>>>
>>>>> I am definitely open to input here.
>>>>>
>>>>> _____________
>>>>>
>>>>> Roman Shpount
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> mmusic mailing list
>>>>>
>>>>> mailto:[e-mail]
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> mmusic mailing list
>>>>>
>>>>> mailto:[e-mail]
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> mmusic mailing list
>>>>>
>>>>> mailto:[e-mail]
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>