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

Roman Shpount <roman@telurix.com> Mon, 20 May 2019 21:03 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 DB052120026 for <mmusic@ietfa.amsl.com>; Mon, 20 May 2019 14:03:51 -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 ceU-3d5d0SKj for <mmusic@ietfa.amsl.com>; Mon, 20 May 2019 14:03:48 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 078DA120072 for <mmusic@ietf.org>; Mon, 20 May 2019 14:03:48 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id q17so7814769pfq.8 for <mmusic@ietf.org>; Mon, 20 May 2019 14:03:48 -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=91sbV2nyDJB1LOXUK4YTZChS1dq6eO0m56crkXesJjA=; b=qPA6KmGREVbhcCpI/6QQEXZ/81im9oxEsrloNmS4njh9ZkaMnW+Ow53F/tyqKxJJ2v OXonx5N3fWtUH4+BdlmEe09qIm2iuZF52KueBlV0gmn8mR/Df6124q1ac5y/vPxjWRNR 6mADqIN1WPXBSrTJrOfx/2ZZNqharN7HwcS1xQfv/UKhz6jnpKh7IdYmYszHmSlt1CwF L0tpcpNAsF9YnR/s6ITqJe6ZZyyY8r4QudbbNSC4aXDWxRzQhNQByQOHHsudd3AE6nNM wcuJqMn7XxynMd5RdM6CgxKF1h26z07sokqhlsdQt9ANp6JRjVVKkGh39LV/NJdW5xmu 7yDg==
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=91sbV2nyDJB1LOXUK4YTZChS1dq6eO0m56crkXesJjA=; b=a29D0xfQqNhUFHjrToYlC+OFTizgB7fOTQNL1O1qetbS1u9tASvuFInh6iFSqjCOJQ XzTuk6Sl8ntlBwYXQa5hJVcFdZY4DSprct85Huhg7wawwBOa2Mgyx00mHRGty4amJVnY z0JD3pxKabnmvxaLDXZnr8MmHZv1XRY5gVvmrCFDuYR2zqN+zIk0dUPHWY5J3IdLeDlQ 4Sjd2+mD9atvW9mx06BB8NDbXdqFcy/mVaOuFj83CXEQz435uUKCn7JwXg4AijZUKhUJ UfibvxhZquKt+UXPmL1+B6rt8uY44OR6QM8WjqLjYeBMUWHI0HNhg9NEFTqx9NC7S0al R8Lg==
X-Gm-Message-State: APjAAAXisazTt7J7U1tYIFtPdgSUA5qSjH/9wszdeXe5UTPqz/H/ZfiF KXS4w2VJbqdtl317Zf3UEo2roAg53Rs=
X-Google-Smtp-Source: APXvYqw0R8j3oAvXM04AL4hR82QyIElELOI7PuZj5tdLK67OvrpOtc65mD+vMSh2uG5sfNDelUwm9Q==
X-Received: by 2002:a63:8449:: with SMTP id k70mr76508459pgd.53.1558386227205; Mon, 20 May 2019 14:03:47 -0700 (PDT)
Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com. [209.85.214.171]) by smtp.gmail.com with ESMTPSA id d88sm10769459pfm.42.2019.05.20.14.03.46 for <mmusic@ietf.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 14:03:46 -0700 (PDT)
Received: by mail-pl1-f171.google.com with SMTP id c5so7254973pll.11 for <mmusic@ietf.org>; Mon, 20 May 2019 14:03:46 -0700 (PDT)
X-Received: by 2002:a17:902:bd94:: with SMTP id q20mr55640113pls.146.1558386225925; Mon, 20 May 2019 14:03:45 -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>
In-Reply-To: <CAMRcRGQtyttNhJrPkUEVS9wkVHVQ=XeZ2HDUEBwq-g5995mgvg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 20 May 2019 17:03:35 -0400
X-Gmail-Original-Message-ID: <CAD5OKxvts_xviXW4R3rj1CYYxdzSQCLGTWwa+ZUExF_dHFT+gg@mail.gmail.com>
Message-ID: <CAD5OKxvts_xviXW4R3rj1CYYxdzSQCLGTWwa+ZUExF_dHFT+gg@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="0000000000006b5603058958119f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/nOgfSQBApqExylfFTDbHwWMmT0s>
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: Mon, 20 May 2019 21:03:53 -0000

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
>