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: Iñaki 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>
- [MMUSIC] actpass redux Eric Rescorla
- Re: [MMUSIC] actpass redux Roman Shpount
- Re: [MMUSIC] actpass redux Roman Shpount
- Re: [MMUSIC] actpass redux Paul Kyzivat
- Re: [MMUSIC] actpass redux Roman Shpount
- Re: [MMUSIC] actpass redux Christer Holmberg
- Re: [MMUSIC] actpass redux Eric Rescorla
- Re: [MMUSIC] actpass redux Cullen Jennings
- Re: [MMUSIC] actpass redux Roman Shpount
- Re: [MMUSIC] actpass redux Cullen Jennings
- Re: [MMUSIC] actpass redux Paul Kyzivat
- Re: [MMUSIC] actpass redux Roman Shpount
- Re: [MMUSIC] actpass redux Paul Kyzivat
- Re: [MMUSIC] actpass redux Roman Shpount
- Re: [MMUSIC] actpass redux Paul Kyzivat
- Re: [MMUSIC] actpass redux Roman Shpount
- Re: [MMUSIC] actpass redux Eric Rescorla
- Re: [MMUSIC] actpass redux Christer Holmberg
- Re: [MMUSIC] actpass redux Eric Rescorla
- Re: [MMUSIC] actpass redux Christer Holmberg
- Re: [MMUSIC] actpass redux Eric Rescorla
- Re: [MMUSIC] actpass redux Christer Holmberg
- Re: [MMUSIC] actpass redux Martin Thomson
- Re: [MMUSIC] actpass redux Iñaki Baz Castillo
- Re: [MMUSIC] actpass redux Christer Holmberg
- Re: [MMUSIC] it's time to expel SDP from our lives Paul Kyzivat
- Re: [MMUSIC] actpass redux Iñaki Baz Castillo
- Re: [MMUSIC] it's time to expel SDP from our lives Iñaki Baz Castillo
- Re: [MMUSIC] it's time to expel SDP from our lives Bernard Aboba
- Re: [MMUSIC] it's time to expel SDP from our lives Dale R. Worley
- Re: [MMUSIC] it's time to expel SDP from our lives Iñaki Baz Castillo
- Re: [MMUSIC] it's time to expel SDP from our lives Iñaki Baz Castillo
- Re: [MMUSIC] it's time to expel SDP from our lives Christer Holmberg
- Re: [MMUSIC] it's time to expel SDP from our lives Christer Holmberg
- Re: [MMUSIC] it's time to expel SDP from our lives Iñaki Baz Castillo
- Re: [MMUSIC] it's time to expel SDP from our lives Christer Holmberg
- Re: [MMUSIC] it's time to expel SDP from our lives Iñaki Baz Castillo
- Re: [MMUSIC] it's time to expel SDP from our lives Paul Kyzivat
- Re: [MMUSIC] it's time to expel SDP from our lives Iñaki Baz Castillo