IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 02 February 2016 09:32 UTC

Return-Path: <christer.holmberg@ericsson.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 5AA901ACD61 for <mmusic@ietfa.amsl.com>; Tue, 2 Feb 2016 01:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 0feB_0Pw9_GA for <mmusic@ietfa.amsl.com>; Tue, 2 Feb 2016 01:32:19 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D229E1ACD60 for <mmusic@ietf.org>; Tue, 2 Feb 2016 01:32:18 -0800 (PST)
X-AuditID: c1b4fb2d-f78fe6d00000163a-74-56b077a0e0f6
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 27.7A.05690.0A770B65; Tue, 2 Feb 2016 10:32:16 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Tue, 2 Feb 2016 10:32:16 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive
Thread-Index: AQHRVH5u5HwUiLpiFk2f5BpmhdG86J8GeIug///94ICAAL0LkIAAOGowgABaTACAAV0qoIAAIcaAgAEX24CAAJvKgIAACmeAgAAMtICAAM4ZgIAAhUyAgAAi3NCAAA/qgIAAAkUAgAACrYCAABTqAIAL3+xQ
Date: Tue, 02 Feb 2016 09:32:15 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37D664F2@ESESSMB209.ericsson.se>
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> <CAD5OKxsQqFPZn+BJGEtV8wNwkD3+BYuCQx3D-n_R9GY-r7xnHw@mail.gmail.com>
In-Reply-To: <CAD5OKxsQqFPZn+BJGEtV8wNwkD3+BYuCQx3D-n_R9GY-r7xnHw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D664F2ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7pe6C8g1hBkee6VhMXf6YxWLFhgOs FjMuTGW22Dm3g9mBxePv+w9MHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBm3Z5YV dIRUdLz8zNTA+CCwi5GTQ0LAROLk0uuMELaYxIV769m6GLk4hAQOM0q0/VkC5SxmlHjwbh5r FyMHB5uAhUT3P22QBhEBb4m+vg52EJtZIFDi2YU+FhBbWMBOovn0emaIGnuJU2s/MILMERFY xSixafErsCIWARWJlacfgzXzCvhKHNt4hh1i2X4OiXWznjCBJDiBps5c+xzsPEag876fWsME sU1c4taT+UwQZwtILNlznhnCFpV4+fgf2KESAooSy/vlIMrzJR5MvskIsUtQ4uTMJywTGEVn IZk0C0nZLCRls4AmMQtoSqzfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcXFuelGxnqp RZnJxcX5eXp5qSWbGIExeXDLb90djKtfOx5iFOBgVOLhLXi8PkyINbGsuDL3EKMEB7OSCO/+ 9A1hQrwpiZVVqUX58UWlOanFhxilOViUxHnXOANVC6QnlqRmp6YWpBbBZJk4OKUaGIObZP3e 7Io7schoL5dndeq9i7PeXvqT2nN7ReGfVOsJ7VeXX/f90DZjRYFP78ZOjw/Mmm3lzx1Zl7Qu 6uDcFOW2dNXKsyf+Mk9k1jxlOvtB/8p25mWKD1bv4nAs1Xyxv+xab0SN0+06wY5Fp3SKel2K 01ytYo6nskqr+tU+WqYd6Hgkb9kDDSWW4oxEQy3mouJEAJwLKnfFAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/FITFz3zGy4s726MZAY2uy-_-ghA>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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: Tue, 02 Feb 2016 09:32:21 -0000

Hi,

So, assuming we would define a new attribute to indicate/negotiate mux-exclusive, I still think we need to say something about a=rtcp, don’t we?

We could simply say that the a=rtcp attribute value must be identical to the port and address for RTP. That would work also for trickle ICE.

Regards,

Christer

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 25. tammikuuta 2016 23:11
To: Paul Kyzivat
Cc: Christer Holmberg; Suhas Nandakumar; mmusic@ietf.org
Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

On Mon, Jan 25, 2016 at 2:55 PM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto: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