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

Roman Shpount <roman@telurix.com> Fri, 24 May 2019 21:37 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD612030A for <mmusic@ietfa.amsl.com>; Fri, 24 May 2019 14:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVTQkWYJz1Ai for <mmusic@ietfa.amsl.com>; Fri, 24 May 2019 14:37:10 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C6B120158 for <mmusic@ietf.org>; Fri, 24 May 2019 14:37:09 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id gn7so4631818plb.10 for <mmusic@ietf.org>; Fri, 24 May 2019 14:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CedmR3wOvT0F7leDtXUgqrwsq5pkZjK15Ll7/7FEVT0=; b=Bo0P0rkx041TQrJsAtP1GxrG/Y3NBQ69Y7Pdgk22QJJCNkvCPDby208dK1Ve/evhMX 9P2YRn/3He2YCEoTPIY2vDQ4aw5QnKGu4HFtdKDulFDgPGIJHzd8dEiWDfULqM6zT3un BaM2hz2X6jktIRrba8eUGBmjbXZULw3UENa6wTSA0im1wfAmuny2hx+ut3neO1/DLGb9 3blPMXYs2CK8nH/yEhpPHQqJkP0iY3y41Gk4o/6bRhTMObM0au3LcNj95H0ss2KPIYFr mxJHv404PEE/ESU5DZALI28fPYCEBmwMeZhhSnLtQ9jQn5mTLnZBXBvYqBFN5OlL/SDY qoIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CedmR3wOvT0F7leDtXUgqrwsq5pkZjK15Ll7/7FEVT0=; b=IAtbcY7V08/UHkzmDKDhm5chRwax7rzrH9l7T11V5XQW+B9je2zFFXxUb9qKtcRHOD GaKZnmj4D6OejcFz0jesm4SuEKwiaaZViZ3XmQuxmOQxBtNVZr/u6wSS2/OxK9pnATB4 4CI57oAKk2pBHBqu426QyZxq1Asb0K2p6P9PODJIxW3eGoZDjR0Y0+mzI5RQBL+72WC6 K/RLDlVIGqTOGUf+O0QXFyaPn13TeO2eUZhw5K+/L/oN19WyDpm/X96U563C9zza8Fpt Y/AU48Oar0u9g8ckEILEz7TO7A1OQpWgv1XAsRxV7SSU1UUiF4OSbbwwHTmYBCGtzwdc u7mQ==
X-Gm-Message-State: APjAAAXgDJrq3IVnKNF7ydRaXH4NihhiIyU1O6pHHtbCT7yK9uBdmKF9 mFqLQL3XWiWdeghKOOtQ7crFKkIyyLQ=
X-Google-Smtp-Source: APXvYqz9/sOC4LeChb42apk+qgFDnI6+WddbIeQOpYAJOOn7O4OHhMzhICd/nJJifoSIuijGfoLbRg==
X-Received: by 2002:a17:902:b204:: with SMTP id t4mr57505898plr.285.1558733829210; Fri, 24 May 2019 14:37:09 -0700 (PDT)
Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com. [209.85.215.178]) by smtp.gmail.com with ESMTPSA id 8sm3628170pfj.93.2019.05.24.14.37.07 for <mmusic@ietf.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 14:37:08 -0700 (PDT)
Received: by mail-pg1-f178.google.com with SMTP id f25so5703133pgv.10 for <mmusic@ietf.org>; Fri, 24 May 2019 14:37:07 -0700 (PDT)
X-Received: by 2002:a17:90a:d14c:: with SMTP id t12mr12316258pjw.120.1558733827628; Fri, 24 May 2019 14:37:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5OKxvGcC0inLRxwTHKdWW3z6xM2PWjV=1J8+3_zwQsF3tCaA@mail.gmail.com> <HE1PR07MB3161E1BDB1E2439E1A9CE785933F0@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxtqKi1ucRXd5xrZrsM6hiqu=FUULx3mQv+=bZx3YHMbLg@mail.gmail.com> <310293b1-0fbf-9b74-03ca-63ad8d4b80bd@cisco.com> <CAMRcRGSyWB3O04CDOUx1oXtyL=AyB--dM-e+ABfm2dN16RK7sw@mail.gmail.com> <222e6d5f-dcca-56c8-095d-e8ca96b1948b@cisco.com> <CAMRcRGQYuv0M5pcrjAfFLUk5J4VcGMAMm_hSTWB+k=ackcxbZQ@mail.gmail.com> <e3523821-b7bf-0d1b-7b10-d38b64e4110c@cisco.com> <26BDCCFB-A65F-417C-8291-B490386ED869@ericsson.com> <CAMRcRGQtyttNhJrPkUEVS9wkVHVQ=XeZ2HDUEBwq-g5995mgvg@mail.gmail.com> <CAD5OKxvts_xviXW4R3rj1CYYxdzSQCLGTWwa+ZUExF_dHFT+gg@mail.gmail.com>
In-Reply-To: <CAD5OKxvts_xviXW4R3rj1CYYxdzSQCLGTWwa+ZUExF_dHFT+gg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 24 May 2019 17:36:59 -0400
X-Gmail-Original-Message-ID: <CAD5OKxtYhKgAf_cqRBJYgZZ5z-R1Qaj=UjjsxRvrbFcno3YV+Q@mail.gmail.com>
Message-ID: <CAD5OKxtYhKgAf_cqRBJYgZZ5z-R1Qaj=UjjsxRvrbFcno3YV+Q@mail.gmail.com>
To: Suhas Nandakumar <suhasietf@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Flemming Andreasen <fandreas@cisco.com>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001868ee0589a90091"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/P8RA06ngUg8vKfRnUMWJfVGF20w>
Subject: Re: [MMUSIC] Is ice-mismatch media or session level?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2019 21:37:13 -0000

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 <roman@telurix.com>; 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 <suhasietf@gmail.com>;
> wrote:
>
>>
>>
>> On Thu, May 16, 2019 at 12:25 AM Christer Holmberg <
>> christer.holmberg@ericsson.com>; 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:
>>> fandreas@cisco.com>; 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:
>>> christer.holmberg@ericsson.com>; 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:mmusic@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> mmusic mailing list
>>>
>>> mailto:mmusic@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> mmusic mailing list
>>>
>>> mailto:mmusic@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>