IETF Logo Mail Archive

Re: [MMUSIC] Why do we need rtcp-mux-exclusive?

Bernard Aboba <bernard.aboba@gmail.com> Tue, 08 March 2016 06:03 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: mmusic@ietfc.amsl.com
Delivered-To: mmusic@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E0481CD968 for <mmusic@ietfc.amsl.com>; Mon, 7 Mar 2016 22:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhKr5nvXimjP for <mmusic@ietfc.amsl.com>; Mon, 7 Mar 2016 22:03:55 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 9A8341CD969 for <mmusic@ietf.org>; Mon, 7 Mar 2016 22:03:55 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id g3so4280770ywa.3 for <mmusic@ietf.org>; Mon, 07 Mar 2016 22:03:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hOqJi6eccuys0LiRRugC66Fj1tv9yIDZ1qjnqqPMgk0=; b=uqwxCNXdGM3NZF1nGTuyMFS9g9TGw3/VX/C4lQB5U4Saxz45SprUTAt+4107Fgyks6 obDI5VTy7QIXMl8iAC19QD3kZv1UITSxzPfW4SvXTh20HcM5N8if9aUJpGFxHV+Syc4X 2emiAhJYXHqT6NDS0I+y/nUoHtvETkdFDhiHROv2Kj2CTMOzC2hrLlSh5mBq19AeNE4a 7OEBXRToNjrnL1vaq4UK+tzNBvQlb1uRY5ziY4wMaJo8axpza2byTX2o2pcWeTorT5/8 BruPwkKQyJoTDYOLjfVwN4EHoC15Hp5cwjz/4NH1spyqIUTda39PdyragE09NZkU8o0r pJOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hOqJi6eccuys0LiRRugC66Fj1tv9yIDZ1qjnqqPMgk0=; b=Vda47sKcC9DGleC/HnySbULHGH6n1QwNbUm49swacRQyvrvo/19yzcwiRIg0EJjBvq tqGf4P/z6NTSufn8SC0OAFGpoo5akRsgFgpfC55Q2tyU+wGSLm8Iaw7yW2mGvCDm6+R5 oYKoXV84vJvEFikM9u/t0139T4aCbID6/ZdNCVSldO4BN76NaWsvWWtLIMTlDIVDFCet XdtmwI/gx8Qk2mKCtaJKJ5yKQrKOpH4RO7m7RkxxMsflk+Ys7IoW2vyzT/EeSEQZ04rt YJ2LkRzZlbROe5UmOsFbldVd4cQiuIwIxk97wH8AXjuMUh3yoKVuzz8Zku5/44/K+GaJ Voag==
X-Gm-Message-State: AD7BkJIopISF7ARqoJZ/6FOzUEJg7Ho3mtoP+qOl1XTk3qp8yL54JGTBywVFh+1XPMMA0PvOCYoQWAdyLlWD5Q==
X-Received: by 10.129.54.15 with SMTP id d15mr13609995ywa.17.1457417034845; Mon, 07 Mar 2016 22:03:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.215.140 with HTTP; Mon, 7 Mar 2016 22:03:35 -0800 (PST)
In-Reply-To: <CABkgnnWPJSGmYHbds09iL+NOibm2_x-gE=5YcsS0Wf4tZtyE7g@mail.gmail.com>
References: <CABcZeBNsJkqGcU3Z=eekP4ntj7r3WMz6YOSiFt=u+HdDH2Zk3Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E5A4E2@ESESSMB209.ericsson.se> <CABcZeBOGpguqkEeUoH35R2S_fOU=eGWgG7r5gmH3T_UHXqRRjg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E5BBC1@ESESSMB209.ericsson.se> <CABcZeBOQKX+LKu1vafq227wv4sy+AApmixGB4fb7wTeuByYTMQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E5C345@ESESSMB209.ericsson.se> <CABcZeBPNOCTT1ahJsH0OSaOwFnLicFSjHWUbAXxQ3sFu5tUdjA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E7236F@ESESSMB209.ericsson.se> <CABcZeBNtmfjrETCerCu=A5BXt5HRCG+nO4KZ4ze3sBEeRNnX_A@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E7444F@ESESSMB209.ericsson.se> <CABcZeBNvsUNxrX5mx3E19St9CGf7s2vUmoyKAUmWbOw9s7jXfw@mail.gmail.com> <56DE4F09.3030902@cisco.com> <CABkgnnWPJSGmYHbds09iL+NOibm2_x-gE=5YcsS0Wf4tZtyE7g@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 07 Mar 2016 22:03:35 -0800
Message-ID: <CAOW+2ds7bCmLCxmaGyOgNd2P-b3FdBNxhqVC7ucWcQhmcZ+R2g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a114272e4a6d5ce052d8358f0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/EFC-YojC6rT7zsKZOnT_Ifhp_yo>
Cc: Flemming Andreasen <fandreas@cisco.com>, mmusic WG <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Why do we need rtcp-mux-exclusive?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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, 08 Mar 2016 06:03:57 -0000

Martin said:

"Or, you could say that this is just an update to RFC 5761 and you want
to allow for an offerer to offer without RTCP on separate
candidates/port."

[BA] Since this relates to ICE, addressing it in RFC 5761bis does not make
much sense.

"Or, you could simply conclude that we're going to require mux in some
implementations and live with having no RFC that "defines" that
behaviour.  The draft dies."

[BA] If this were solely about browsers, I might agree with you - but it is
not.  Mobile/tablet applications are now incorporating WebRTC source code,
as well as design patterns such as mux and BUNDLE.  Eventually it is
inevitable that those mobile applications will interact with life critical
applications such as health and public safety - and without a
specification, BOOM.

So having a specification that can be cited as a normative reference is
actually quite important.

On Mon, Mar 7, 2016 at 8:36 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 8 March 2016 at 15:03, Flemming Andreasen <fandreas@cisco.com> wrote:
> > Sure. In the mean-time, we would like to hear from more people on this.
> As
> > Christer noted, there were several people in favor of adopting this work
> > when we asked in mid-December 2015, so we would like to understand if
> > anything has changed since then.
>
> I think that Eric is really just taking my earlier email to its
> logical conclusion.  The attribute isn't properly justified.  I see
> three options:
>
> You might be able to justify it on the basis that it allows
> intermediaries visibility into what is going on so that they can avoid
> allocating a second component, or maybe some other variant of what
> Christer and I discussed.  The draft grows.
>
> Or, you could say that this is just an update to RFC 5761 and you want
> to allow for an offerer to offer without RTCP on separate
> candidates/port.  That could be a very small RFC.  The draft becomes
> tiny.
>
> Or, you could simply conclude that we're going to require mux in some
> implementations and live with having no RFC that "defines" that
> behaviour.  The draft dies.
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email