IETF Logo Mail Archive

Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

Roman Shpount <roman@telurix.com> Mon, 25 January 2016 21:10 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87051A026F for <mmusic@ietfa.amsl.com>; Mon, 25 Jan 2016 13:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no
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 BlB27awi_8oD for <mmusic@ietfa.amsl.com>; Mon, 25 Jan 2016 13:10:34 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 D4F701A0266 for <mmusic@ietf.org>; Mon, 25 Jan 2016 13:10:33 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id 77so165220647ioc.2 for <mmusic@ietf.org>; Mon, 25 Jan 2016 13:10:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1sN0wd85EOyS7EB2Q9ho+ImzRJz1um8XDvXV+t+rZ/M=; b=oWhGsVBBI600u5RWME5HLK7e5jRvQ2zQcsdlYOCxsI3M6A/F3i/gRxGovVLR8ImK4w GTEyEKQu76x2FpaT3+fI+Zuy8Q+D2JXF4oNNtNH/pqFhbGqB8WZGFmNervSOh2jER+zk SaDe3gWkDRdQMB3Gl9rD/581/6EPQHtPisaoV3BtI5HNPIEx0Ns6gnnO7PPopy/b15iT HmCAFExboEQDVPylMDhRkhPvTV3besWthtCeQojz7RL48UB91A7AnYHBQOw65w8rH8xq iAIpk9mLu74TmsQEH7HRlfIh/t+VYd7LQwHnMGqsa8AnFPF2sjjGLSq1H9nU3w8FVmhD G5sA==
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:date :message-id:subject:from:to:cc:content-type; bh=1sN0wd85EOyS7EB2Q9ho+ImzRJz1um8XDvXV+t+rZ/M=; b=PlmNgwna8dnhhR4uH8zIUbhgDPhaepDIlUvuOTbn472xiSh5P/6ibxPix9jWsE8s9f 94H00im72dB+2CCpKjznryxxw6Eqnq6C2iOCOvZY9f6bS0rgdnr3aSpF2a90CD66jXTv bGnaMAU7GjN28cJgZepReuwBjlHTU7yRJQxwPvUa33s3iZ1NqGfTF/CjiS16tDLyq3ax G0v3KFxPnVeyHnHAsS5wStf/zQ+jdNaxYiktXHy0bGObmxrEiWohnxKKH0jfqKyifEDq 8FqcJk6t5Ad1+uriN+1ry/XcqCfAJUpoovZtoWuNl760iddjoI24wmCCNz5wUfPCaYTp j7Uw==
X-Gm-Message-State: AG10YOTP2maDsh08SXbTXuAdMXZeAuZB3jvp8qpu2vIT16MvqDoVL8quTt9btNM1qJhq4A==
X-Received: by 10.107.46.228 with SMTP id u97mr18993917iou.136.1453756233059; Mon, 25 Jan 2016 13:10:33 -0800 (PST)
Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id nq10sm237107igb.2.2016.01.25.13.10.31 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 13:10:31 -0800 (PST)
Received: by mail-ig0-f182.google.com with SMTP id mw1so39586284igb.1 for <mmusic@ietf.org>; Mon, 25 Jan 2016 13:10:31 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.88.7 with SMTP id bc7mr19695382igb.24.1453756231011; Mon, 25 Jan 2016 13:10:31 -0800 (PST)
Received: by 10.36.105.77 with HTTP; Mon, 25 Jan 2016 13:10:30 -0800 (PST)
In-Reply-To: <56A67DBB.1000509@alum.mit.edu>
References: <CAD5OKxvMdsdkYaJWB5UdvCTNj3a+pheXV+_1viyLrH_UOWBTpA@mail.gmail.com> <CAD5OKxum=E84NVTtWtSwYowDmyJ=sQifx6Na9wt0pUhYH1j_PA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37D557C6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D55EAA@ESESSMB209.ericsson.se> <CAD5OKxvaUi25TbOa48mKwkEJMnJqde_TQNfe1Cagdgj+jTbJ3g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37D57EFC@ESESSMB209.ericsson.se> <CAD5OKxuRwgs0w0iUorivK6BV_8bZNNN1D9w9ot4CVJ7CV-6xpw@mail.gmail.com> <CAMRcRGTDpXMdk9SqQtRCc+LyQff26-5NiV6er6dkbdJzJLEwAQ@mail.gmail.com> <56A51EE7.8060406@alum.mit.edu> <CAMRcRGRD_XedYjVfBxfwXFdxAmm_wTZ5HhK5S+iSrJXwOZogMw@mail.gmail.com> <56A53249.5020709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D59613@ESESSMB209.ericsson.se> <56A64EFD.4000509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37D5B5E7@ESESSMB209.ericsson.se> <56A67995.4040309@alum.mit.edu> <CAD5OKxt_9DEH=NBsL1EunB3DviDsYhBCanQ2fpBZEA4pWyfadQ@mail.gmail.com> <56A67DBB.1000509@alum.mit.edu>
Date: Mon, 25 Jan 2016 16:10:30 -0500
X-Gmail-Original-Message-ID: <CAD5OKxsQqFPZn+BJGEtV8wNwkD3+BYuCQx3D-n_R9GY-r7xnHw@mail.gmail.com>
Message-ID: <CAD5OKxsQqFPZn+BJGEtV8wNwkD3+BYuCQx3D-n_R9GY-r7xnHw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="089e01184168bd5924052a2efff7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/uUIn9B98I1M5IQnd0laOo9GHgCI>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 25 Jan 2016 21:10:43 -0000

On Mon, Jan 25, 2016 at 2:55 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Do you have data supporting this assertion?
>


I believe a=rtcp was developed to work in conjunction with RFC 3489. In
practice such deployment scenarios are recipes for disaster since end
points will end up not getting connected often enough for large groups of
your customers to complain. Such architecture also has serious security
problems. This entire architecture was later completely redesigned (see
https://tools.ietf.org/html/rfc5389#section-2 for more details).

Anything commercially viable is using either something like ICE or host
based NAT traversal. I think we should strongly steer service implementers
towards ICE when NAT support is required and do not extend or promote
a=rtcp based solutions. ICE does mention a=rtcp but it is only used there
for legacy interop with exiting end points which were designed to work with
RFC 3489 derived addresses. I do not think a=rtcp has any use cases beyond
such legacy interop.
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email