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

Christer Holmberg <> Thu, 16 May 2019 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 761B4120177 for <>; Thu, 16 May 2019 00:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LUIFaDJSdoJQ for <>; Thu, 16 May 2019 00:25:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55D2F1200E6 for <>; Thu, 16 May 2019 00:25:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q06rNhjMrFeC/2xjXTZI5xpeqNdsMKdXxplIqYpS1Qg=; b=lGvYPEykschl+F5PKzzKHSBWB1w9QFnVxF2xLsS5jcxES9uixbJv9dA5BWGuKD7NO1QEHFSMKnvZZjN0q0TIF/eBEfpup5Vu5EGscgH6vo74qXEXboN+4kuOSeUIyz7/k+5M2szsP5386zidAybdfg3p5/Vz+u9ZLrzr281CrOA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.7; Thu, 16 May 2019 07:25:51 +0000
Received: from ([fe80::c999:f848:9abc:d321]) by ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1900.010; Thu, 16 May 2019 07:25:51 +0000
From: Christer Holmberg <>
To: Flemming Andreasen <>, Suhas Nandakumar <>
CC: mmusic WG <>
Thread-Topic: [MMUSIC] Is ice-mismatch media or session level?
Date: Thu, 16 May 2019 07:25:50 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9208726e-e964-4438-5f66-08d6d9cfb955
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3452;
x-ms-traffictypediagnostic: HE1PR07MB3452:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0039C6E5C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(346002)(39860400002)(136003)(189003)(199004)(14454004)(81156014)(81166006)(36756003)(8936002)(6512007)(6306002)(186003)(54896002)(26005)(446003)(82746002)(508600001)(256004)(66446008)(64756008)(316002)(76116006)(66476007)(73956011)(66556008)(66946007)(7736002)(8676002)(86362001)(5660300002)(58126008)(110136005)(68736007)(966005)(76176011)(33656002)(6486002)(53936002)(83716004)(25786009)(6116002)(102836004)(2906002)(66066001)(229853002)(3846002)(6506007)(6246003)(53546011)(4326008)(44832011)(6436002)(11346002)(2616005)(476003)(99286004)(486006)(71200400001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3452;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sl2LUFd0gIQAvk8rPxPpCC2HA7H0mbHq6gbu4BBVaYyMFcGrtcDzE3ZB2CwcFb8oEmd73mUS6COo3y+A4GAYDAC5tm/OiZdxh8mppttAEMikCW4X/8qo1XUWzAbrx9+rEuLxXMGVSYhAGMeih2VbGp7fhrTZn4NGqt0UtxzUo14TUmEowkoa7TfEtxSCgOs/u8wNXmkapFNJUzl90Rvq8z04Hl90Q5awGQt097OpmGU9Wj67594OIn3HkXkWVzSlHHLCbf9rNU613ZhQcTqaY5i9hUa3mO8LI6kHD/XJfFYu76Qb+nYEdQ99xeBd0pKi8VEr3d4Mjn8qZIwpeiiUKhvmImEMX8wF3UbIS481Za9gpCd+fEa/srKmsMWmjnP5wQhrL1E6TB6/6OpPq+OSjf6oRlVsaJ+INpEPQ1ajHTs=
Content-Type: multipart/alternative; boundary="_000_26BDCCFBA65F417C8291B490386ED869ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9208726e-e964-4438-5f66-08d6d9cfb955
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2019 07:25:50.8622 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3452
Archived-At: <>
Subject: Re: [MMUSIC] Is ice-mismatch media or session level?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 May 2019 07:25:58 -0000


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



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


-- 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 <> 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 ( At the same time, according to RFC 5245 Section 15..3 (, ice-mismatch is media level attribute only. This being said, according to RFC 5245 Section 6.1 (, ice-mismatch applies to the whole session, but it is specified per m= line. According to errata 3149 (, 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


mmusic mailing list


mmusic mailing list