IETF Logo Mail Archive

Re: [MMUSIC] actpass redux

Iñaki Baz Castillo <ibc@aliax.net> Tue, 13 June 2017 21:18 UTC

Return-Path: <ibc@aliax.net>
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 3CFAF131101 for <mmusic@ietfa.amsl.com>; Tue, 13 Jun 2017 14:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 MUdqsiXi6fnw for <mmusic@ietfa.amsl.com>; Tue, 13 Jun 2017 14:18:05 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 8953712EB3F for <mmusic@ietf.org>; Tue, 13 Jun 2017 14:18:05 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id q97so161796509wrb.2 for <mmusic@ietf.org>; Tue, 13 Jun 2017 14:18:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=h9BKN6ui6QIVC5a42ub99wr/F/h9Dqq0582UAU4c2d4=; b=h1o3D9yXUenWE+6RiqROYdcA43Vo2Kle5gQ0fHnr0r1wA2lZSNY6V4LF05xMkEObd8 PfYuq3tBb+/OYX9gqmtAMBnlZh/YrTOUQ1VqNrHBarXOfAPtqTao8iwMS/zuUMab7X1I nUh/d/fdA9wohySs5uM3cpn1yXsR3pT5U8byvmj1yfgPJqY4g+iWf5G5ybdcuTT5JCXb pzLwSmQTQmQ9EpkyZleRWjBfEUN9VYXq4W69t/wfv3S/AmJNKHxr2nMWyg1pX7BaKaKg CeMWYz0MkHMVuk7S8eYgEcnsFy9ezZ/VrCUy6JWbyJFfhX3VKSHZo69IZOE+a6IJwD3y Mu+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=h9BKN6ui6QIVC5a42ub99wr/F/h9Dqq0582UAU4c2d4=; b=YGW+NbXNJ5mWBKMkpDiX/1ke61MAMW/UxZGeYtI31QP2PFhOKTIRNArPd/zWFkQitz V5tx7Rw674cM0OEkmG6ShaN2S41eYbsN9I5GHhZj365jk3dwbtwCtK2KBN0AJStewuV5 9oxft1MKMvs/BnbOzeRZEkzfc1TlTWkPpEECo2rFEOzPlZU36p+oZPSNUo7IQS1yvTJA yp3rSAQDjQmxY2mzb8mAS8wR9z8VwmrmBoLoSv3PRZlPaswAP0phxgPMhpssF4+wWEDf cPrgPXOEir+iZ4b6RlwYzc9EovLHACzd27J1e9fWTvEi4ccNmRfli2RQZJcYhua5KtQB BHGw==
X-Gm-Message-State: AKS2vOxJNFtSchE6z+qwmlPXrB/FclVyTWHVE+0QmFdEBve0Qlb90sg4 lz0qgL/kiDokjDUuu4GdwPZSYqTxViSS
X-Received: by 10.80.147.226 with SMTP id o89mr1397842eda.112.1497388684093; Tue, 13 Jun 2017 14:18:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.135.87 with HTTP; Tue, 13 Jun 2017 14:17:43 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBEAD3D@ESESSMB109.ericsson.se>
References: <CABcZeBMd2BZgyeFnqafTVyGga4FMoK0xJkPCv0y_wvmBWsg+xg@mail.gmail.com> <CAD5OKxvwgvm3Q4HsCYsewZjRS9ty_g34n9+x87vfLW4Omcm8mw@mail.gmail.com> <CALiegfk_Oz5Vj5xxbO9v1XgGHyBYyzCqg1jp1Mv_aW0noWMchA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4CBEAD3D@ESESSMB109.ericsson.se>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Tue, 13 Jun 2017 23:17:43 +0200
Message-ID: <CALiegfka7-YatS0YGQEA_VmJDDQegr3ocb8kPLH=kLWyL6EZjA@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Roman Shpount <roman@telurix.com>, mmusic WG <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/G2_AtYiMWHZJ2RvB_wVMcID-2dA>
Subject: Re: [MMUSIC] actpass redux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 13 Jun 2017 21:18:08 -0000

2017-06-13 20:23 GMT+02:00 Christer Holmberg <christer.holmberg@ericsson.com>:
> I don't necessarily disagree with you, and I don't know if your e-mail is off-topic for MMUSIC, but it for sure IS off-topic for THIS thread, and the draft/charter item discussed :)

Hi Christer,

Probably you are right, and sorry for that. Being honest, I started
writing a very different email exposing my experience with the issue
being discussed in the thread. It said something as follows:

I've seen the "SDP DTLS role conflict" in many implementations. AFAIR
older versions of Firefox and Asterisk wrote, in a re-offer, an
a=setup attribute with the effective value (active or passive) as
negotiated during the initial O/A, which breaks the RFC because it
MUST be "actpass", so Chrome complained. I've also seen (and reported)
that FreeSwitch changes its DTLS a=setup role during a re-negotiation,
but the funny thing here is that it was just a cosmetic change in the
SDP (internally FreeSwitch wants to keep the initially negotiated DTLS
connection regardless what it actually writes in the re-offer):

https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-10258/FS-10258.html

But after writing it, I've realized that if it's so complex for
existing implementations to deal with this specification rule (still
in 2017) changing the spec or creating a new one won't help much (at
least in the short term), so I got really frustrated and ended sending
my original text.

Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email