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

[Roman Shpount <[e-mail]>]

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