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

From: Flemming Andreasen <[email-masked]>
Date: Sun, 12 May 2019 20:27:36 -0400

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 
> <[email-masked] 
> <mailto:[email-masked]>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 12 May 2019 22:22:59 -0700

I am inclined to leave it as media-level attribute. I am not sure what more
clarification is needed in the text today ?

On Sun, May 12, 2019 at 8:41 PM Flemming Andreasen <[email-masked]>
wrote:

> On Sat, Apr 27, 2019 at 1:48 PM Christer Holmberg <
> [email-masked]> 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
> 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.
>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 13 May 2019 12:26:22 -0400

On 5/13/19 1:22 AM, Suhas Nandakumar wrote:
> 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 ?

Thanks

-- Flemming
>
> On Sun, May 12, 2019 at 8:41 PM Flemming Andreasen <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>>         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?
>>
>>
>>
>>     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.
>>
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf..org/mailman/listinfo/mmusic  <https://www.ietf.org/mailman/listinfo/mmusic>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 15 May 2019 00:59:23 -0700

> Are the clarifications Roman suggested below already included ?

I am finding it hard to parse suggested clarification. I am sure I am
missing something.

>>> 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?
>>>
>>>
>> 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
>> 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?
>>
>> mmusic mailing [email-masked]://www.ietf..org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 15 May 2019 23:53:08 -0400

On 5/15/19 3:59 AM, Suhas Nandakumar wrote:
>
> On Mon, May 13, 2019 at 9:26 AM Flemming Andreasen <[email-masked] 
>>     I am inclined to leave it as media-level attribute. I am not sure
>>     what more clarification is needed in the text today ?
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.

-- Flemming

>
>
>     Thanks
>
>     -- Flemming
>>
>>     On Sun, May 12, 2019 at 8:41 PM Flemming Andreasen
>>     <[email-masked] <mailto:[email-masked]>> 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.
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 May 2019 07:25:50 +0000

Hi,

>>>> I am inclined to leave it as media-level attribute. I am not sure what more clarification is needed in the text today ?

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

Regards,

Christer

On Sun, May 12, 2019 at 8:41 PM Flemming Andreasen <mailto:[email-masked]> 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.

Thanks

Hi Christer,

On Sat, Apr 27, 2019 at 1:48 PM Christer Holmberg <mailto:[email-masked]> 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.

_____________

Roman Shpount

mmusic mailing list

mailto:[email-masked]

mmusic mailing list

mailto:[email-masked]

mmusic mailing list

mailto:[email-masked]

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 16 May 2019 13:28:10 -0700

On Thu, May 16, 2019 at 12:25 AM Christer Holmberg <
[email-masked]> wrote:

> really isn't any normative behavior associated with receiving ice-mismatch.
>
> No matter whether it's session and/or media level, I still think there
> needs to be normative behavior associated with receiving ice-mismatch.
>
>
>
>    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"*

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 May 2019 17:03:35 -0400

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 <[email-masked]>
wrote:

>> 21..1.4 (https://tools.ietf.org/html/rfc5245#section-21.1.4). At the
>> same time, according to RFC 5245 Section 15..3 (

---

From: Roman Shpount <[email-masked]>
Date: Fri, 24 May 2019 17:36:59 -0400

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 <[email-masked]> wrote:

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

---

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 25 May 2019 03:13:22 +0530

Hi Roman

Please go ahead with PR on that branch

Thanks
Suhas

On Sat, May 25, 2019 at 3:07 AM Roman Shpount <[email-masked]> wrote:

>> In some cases, controlling/initiator agent may receive the SDP answer
>> that may omit "a=candidate" attributes for the media streams, and instead
>> 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.
>>
>> 3. We need to specify somewhere that a=ice-mismatch is only allowed in
>> the answer and MUST not be present in the offer.
>>
>>>> media-level. I'd suggest we keep it that way and add the clarifications you
>>>> outline below.
>>>>
>>>>
>>>>
>>>> or no sense being specified per m= line. If it only stops processing for

---

From: Roman Shpount <[email-masked]>
Date: Fri, 24 May 2019 18:08:13 -0400

Done.
_____________
Roman Shpount

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

>> In case if ICE validation procedures failed for one or more m= line in
>> the answer (answerer detected ICE mismatch), the behavior is unspecified
>>> media stream* based on normal [RFC3264] procedures, without using any
>>> of the ICE mechanisms described in the remainder of this specification with
>>> 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.
>>>
>>>>> > 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.
>>>>>
>>>> [Suhas] RFC5245 never defined a normative behavior on how a
>>>> ice-mismtach needs to be