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

[Roman Shpount <[e-mail]>]

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
>