Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 06 November 2015 07:31 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 317061B363E for <mmusic@ietfa.amsl.com>; Thu, 5 Nov 2015 23:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 gOZvvZwq68Wo for <mmusic@ietfa.amsl.com>; Thu, 5 Nov 2015 23:31:15 -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 DCF471B363D for <mmusic@ietf.org>; Thu, 5 Nov 2015 23:31:14 -0800 (PST)
X-AuditID: c1b4fb2d-f79626d000004282-70-563c57404d9f
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.D4.17026.0475C365; Fri, 6 Nov 2015 08:31:12 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.202]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Fri, 6 Nov 2015 08:31:12 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt
Thread-Index: AQHRF46VcOK5EGyVV0CmTps0O2QosJ6M7xgwgACPF4CAAMOFgIAACxOAgAAN9wCAAEBdbQ==
Date: Fri, 06 Nov 2015 07:31:12 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37BDF3D0@ESESSMB209.ericsson.se>
References: <20151105055530.18448.860.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B37BDA7FA@ESESSMB209.ericsson.se> <563B764D.5020709@alum.mit.edu> <CY1PR0501MB157965D91C4852B5DE070273EB280@CY1PR0501MB1579.namprd05.prod.outlook.com> <563C239B.8020600@alum.mit.edu>, <CAD5OKxu7qgaF3Ti_OYq7xvzz_w8BzVGrLKnDt3f4jmt70pAufw@mail.gmail.com>
In-Reply-To: <CAD5OKxu7qgaF3Ti_OYq7xvzz_w8BzVGrLKnDt3f4jmt70pAufw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37BDF3D0ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM+Jvra5DuE2YQd9MM4upyx+zWKzYcIDV YsaFqcwOzB5/339g8liy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZ297OYyzYaVBx6scq1gbG xZpdjJwcEgImEsfOnGKHsMUkLtxbz9bFyMUhJHCEUWLZ8T5GkISQwGJGiSe9YV2MHBxsAhYS 3f+0QcIiAt4SfX0d7CBhZgF1iauLg0BMYYEkiUl/aiAqkiWmNvSzQ9hhEr9nb2IDsVkEVCR2 TFoGNpxXwFdi7uk3rBBbHzNJvN36lQUkwSkQKNFyeBJYMyPQad9PrWECsZkFxCWavqxkhThZ QGLJnvPMELaoxMvH/1ghavIlOiecZ4VYIChxcuYTlgmMIrOQtM9CUjYLSRlE3EDiy/vbULa2 xLKFr5khbH2J7venmZDFFzCyr2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjLKDW37r7mBc /drxEKMAB6MSD6/BcuswIdbEsuLK3EOMEhzMSiK8csw2YUK8KYmVValF+fFFpTmpxYcYpTlY lMR5W5gehAoJpCeWpGanphakFsFkmTg4pRoYS0zFlcS28R/QkVRoYrl1j7m9RYbtPc/Nuuwv T5nvtyafysqUjJcUXjDtrn+L1dqu7uq7M3Y/Svn/USssbIvFefvLLzP3Xuj6//6z8oqFvcb9 KxsKGpvy1LpjTWzUwgqElv08d7IkX2f2xLdrndq3pK9asf3iTSW9r9LtsWuF7LIYM6827/ZV YinOSDTUYi4qTgQAeHH8wa4CAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/ANelbI4LMCT7SzRd588pnfnMBj8>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt
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: Fri, 06 Nov 2015 07:31:17 -0000

Hi.

One option could perhaps be to use ICE if supported, but the rtcp attribute, with it's shortcomings, would be a fallback mechanism.

Because, the more mandatory dependencies we add, the more difficult it will be to deploy (mandating ICE for mux would also indirectly mandate ICE for BUNDLE) and I am pretty sure non-mux is something that also non-WebRTC folks want.

Regards,

Christer


Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:roman@telurix.com>
Sent: ‎06/‎11/‎2015 12:40
To: Paul Kyzivat<mailto:pkyzivat@alum.mit.edu>; Christer Holmberg<mailto:christer.holmberg@ericsson.com>
Cc: mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

Another solution is to require ICE. It is already requirement for WebRTC.  Unless ICE check completes for an address/port, nothing will be sent there.

Furthermore, end point can put IP4 0.0.0.0 in c= line and and not specify the candidates for RTCP components. If not RTCP components are specified and rtcp-mux is not used, there is not going to be a destination to send RTCP. Alternatively offerer can specify the same IP and port in candidates for both RTP and RTCP components. Offerer should already select safe payload types for rtcp-mux and answerer will send both RTP and RTCP packets to the same port.

SDP rtcp attribute is broken since there is no way to determine if it was understood by the remote party. It would be better if it was retired instead of finding new ways to use it.

Finally any deployments on open networks which do not require consent to send data are dangerous and should be discouraged. So, I strongly suggest that anything new should be built around ICE. This is why ICE is required for WebRTC. Anything else is already built assuming some sort of pre-negotiation is already in place and it is typically already known if remote party supports rtcp-mux or rtcp attribute.

Regards,
_____________
Roman Shpount