Re: [MMUSIC] actpass redux

Iñaki Baz Castillo <ibc@aliax.net> Tue, 13 June 2017 17:08 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 B8E12129410 for <mmusic@ietfa.amsl.com>; Tue, 13 Jun 2017 10:08:54 -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 iZ4fAGJ_llye for <mmusic@ietfa.amsl.com>; Tue, 13 Jun 2017 10:08:52 -0700 (PDT)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 10AFE131901 for <mmusic@ietf.org>; Tue, 13 Jun 2017 10:08:52 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id v104so143870342wrb.0 for <mmusic@ietf.org>; Tue, 13 Jun 2017 10:08:51 -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=b925fa/ljfOxY2sy7nXCfpniUF6dFhsnizoy3rjdX9s=; b=HoPUwP/qinRaabexW1PenHhHniZZ45x1NBHoHsfyC0RLGmCULTQ58kAmXLmSQqSasQ O6c8VPXCzF86tfsSw9J6lDkPotJTxu+Np42y8ZDtzEsrLHoDnetwBac7jxaJyw7Htt46 bLNuNXSA3fqM1yT/9lJigeEC9hexRpx0C/FX1C1wccduRXginDZ4tKOy0uyKQEqGWuw2 KmJwYsEQ2telK3ato+6vf8l2lYQdDv1Ur9gnfYIaV424ipngZE1i4PbCsw4rC9imPVd0 uDeuojY1GNeCOehoq19mhKSGzts0Q9x2tXjHVqkOkmZ05Spwv5SQKF1lIKXKryqz/cxS FuqQ==
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=b925fa/ljfOxY2sy7nXCfpniUF6dFhsnizoy3rjdX9s=; b=CtUWRAbp3O9gLE6WQXyFXJfUL1yeOsQn+RA3z1gOlqvxu8/m4hLW/zUUAldW9r2O+e DlPEQCIUIe4XrAZ4c3eR0kA3OQFdwey/YE2yyX3ndO6XCRjFkZc51o8qORI6R2ExSrt/ zjY1owPcpr5lctyUFqYHE1Cq7ckBqZk7nGG26PQ8GjB5I6qonj174De9DvwGMiJNDAhr MMiAQaUg9dxgRRSnivJoWnoKSIYfNOjmriyNEP+9+R+0GUwgMEsFOsP3fqRa8NnwU912 FaPYZ5MhHyYg745Ds2RNqu4hXnfHE3O+totCJP9vI4aXy8UG93lKIRz3GaEK6tdHUhd4 atUQ==
X-Gm-Message-State: AKS2vOybQXUlbFXjC3G+0H1HYY1VoBa7cY+BOJXZbcRVU76giiu1dYSw RqOcW43Nfxc8+ubP+h4ACw19t60obBR5PvHE6Q==
X-Received: by 10.80.214.25 with SMTP id x25mr702450edi.13.1497373728812; Tue, 13 Jun 2017 10:08:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.135.87 with HTTP; Tue, 13 Jun 2017 10:08:28 -0700 (PDT)
In-Reply-To: <CAD5OKxvwgvm3Q4HsCYsewZjRS9ty_g34n9+x87vfLW4Omcm8mw@mail.gmail.com>
References: <CABcZeBMd2BZgyeFnqafTVyGga4FMoK0xJkPCv0y_wvmBWsg+xg@mail.gmail.com> <CAD5OKxvwgvm3Q4HsCYsewZjRS9ty_g34n9+x87vfLW4Omcm8mw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Tue, 13 Jun 2017 19:08:28 +0200
Message-ID: <CALiegfk_Oz5Vj5xxbO9v1XgGHyBYyzCqg1jp1Mv_aW0noWMchA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: Eric Rescorla <ekr@rtfm.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/WGLAwRwfivkJXAOawEpNRNGj1rE>
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 17:08:55 -0000

2017-06-02 20:02 GMT+02:00 Roman Shpount <roman@telurix.com>;:
> There was a discussion regarding the setup attribute value in subsequent
> offers when establishing new DTLS association is not desired

Hi, I've silently read all this thread. In fact I already participated
in this exact subject in some threads in the past (so long ago). But
it seems that problems in SDP persist forever.

I think it's time to expel SDP from our lives, specially in WebRTC
where we, the developers, can do media signaling much better than the
SDP-way.

All this kinds of problems are because a full SDP blob must be
generated and consumed by the remote party for *every* minor change in
the multimedia session. So, if I want to add a video stream on top of
the same ICE+DTLS transport, or if I want to pause it, or remove it,
or whatever, I must send a full SDP and the remote peer must figure
out whether such a SDP involves a ICE change, DTLS change, streams
change, codecs change, etc etc. This means a "full re-inspection" of
all the parameters (ICE, DTLS, RTP, RTCP, etc) for every SDP O/A
renegotiation.

When SDP was about simple bidirectional audio it was just fine. But
nowadays SDP is unsustainable.

Now we have a draft that defines a new a=tls-id attribute to avoid
DTLS re-handshake on a SDP O/A renegotiation. That's a hack IMHO. We
may also invent a new a=ice-id to avoid inspecting remote ICE
ufrag/passwd/candidates every time a multimedia session change is
desired. And also a=m-id attribute (per media section) so the receiver
figures out whether something has changed in such a media section or
not, etc. Ah, and we have BUNDLE so the "transport" is just defined in
the first media section (or the first *active* one, who knows?).

1) Transport => UDP or TCP or ICE
2) Security => DTLS or SRTP
3) Media => Parameters for independent send/recv media streams

That's all we need, nothing else: a clear layers separation so we can
signal each layer parameters independently. Yes, that's similar to
what ORTC provides, which is far from perfect, but it becomes much
more comfortable to work with.

IMHO it's really sad that WebRTC 1.0 has been polluted with this
legacy "media signaling" mechanism. WebRTC was born so many years ago
and, in 2017 with spec 1.0.0 about to be released, we still have spec
and implementation problems when it comes to "renegotiate" something
in the session because the remote may attempt a new DTLS handshake...
just LoL.

I do know that my complain is slightly off-topic given that this is
MMUSIC, which is supposed to be 100% SDP related. But I wonder why the
MMUSIC WG is still 100% tiled to SDP rather than just defining
multimedia related parameters as it should (IMHO). The longer this WG
defines multimedia stuff for just SDP, the longer the developers will
suffer the SDP re-negotiation and its inherited "full re-inspection".

I'm sorry for this email, but I just can not bear to see so many
bright minds wasting so much time due to a single SDP line whose value
may have to be different on each re-O/A (depending on who the
re-offerer is) to just keep the underlying transport untouched
("actpass ==> active", "passive <== actpass"). Having to change things
to change nothing seems surrealist.

Regards.


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

Replies:

References: