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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 21 March 2016 09:53 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 3C21712D580 for <mmusic@ietfa.amsl.com>; Mon, 21 Mar 2016 02:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 ahVYT7odVMi8 for <mmusic@ietfa.amsl.com>; Mon, 21 Mar 2016 02:53:21 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E044C12D553 for <mmusic@ietf.org>; Mon, 21 Mar 2016 02:43:49 -0700 (PDT)
X-AuditID: c1b4fb30-f79246d00000788a-64-56efc25318f6
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.58.30858.352CFE65; Mon, 21 Mar 2016 10:43:47 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 10:43:42 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] Why do we need rtcp-mux-exclusive?
Thread-Index: AQHRdajWE2kKEUdcwUGjD2CZk1wvxJ9I7sEQgAAvLYCAABdykP//+CcAgABTMICAAAArgIABZCbQ///1Q4CAACIS8IAAC0KAgAPbM4CAAAkjgIAAGHWAgAAE5ICAADHDgIABfqxAgACGpoCAACjoAIAAAz2AgAxwHoD//+OkgAAEug6A///hZACAAATggIAAIYYA///TiyCAAJdAAIAA4s4AgARnBgCAAC87gA==
Date: Mon, 21 Mar 2016 09:43:42 +0000
Message-ID: <D3158E96.601C%christer.holmberg@ericsson.com>
References: <CABcZeBNsJkqGcU3Z=eekP4ntj7r3WMz6YOSiFt=u+HdDH2Zk3Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E7444F@ESESSMB209.ericsson.se> <CABcZeBNvsUNxrX5mx3E19St9CGf7s2vUmoyKAUmWbOw9s7jXfw@mail.gmail.com> <56DE4F09.3030902@cisco.com> <CABkgnnWPJSGmYHbds09iL+NOibm2_x-gE=5YcsS0Wf4tZtyE7g@mail.gmail.com> <CAOW+2ds7bCmLCxmaGyOgNd2P-b3FdBNxhqVC7ucWcQhmcZ+R2g@mail.gmail.com> <CABkgnnV_ChBkVh+yHLpCwvqc99odBLVVyf2L_dAJt-sWp66Nfw@mail.gmail.com> <D30448AA.55C1%christer.holmberg@ericsson.com> <7594FB04B1934943A5C02806D1A2204B37E9FE5B@ESESSMB209.ericsson.se> <CAD5OKxuC8kS=qAFkJrgZJndEvzXCrEAh=U2b4Na57MYY93o-+A@mail.gmail.com> <D30619E9.5867%christer.holmberg@ericsson.com> <CAD5OKxsOBRHwSGSsJ2+Wf1U3W_LPGWv5OuCmJR2BeXJgT8YHBQ@mail.gmail.com> <D3108E09.5D37%christer.holmberg@ericsson.com> <CAD5OKxvV1dwW=rxJ8hg3wK1_ih_w-PmF5EZ+tn0TdQSG+Rei5A@mail.gmail.com> <D3109581.5D66%christer.holmberg@ericsson.com> <CAD5OKxv+2T=j=DqYnX037H=ZCsE8=MAeCaKM95oYCJpW_Bs7YA@mail.gmail.com> <56EAD16D.6010607@alum.mit.edu> <CAD5OKxvK9SP6c8P7NH6gOFHCGDCYDXxi3Y=ieUsLiVO_KvC5Mg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37EBFA24@ESESSMB209.ericsson.se> <CAD5OKxsJzd7q5H-rr7rvgFj4tKE5iouNTBVfSRwafzWddLr0BA@mail.gmail.com> <D311B53D.5E4F%christer.holmberg@ericsson.com> <CAD5OKxt1C_Ljc6wuawypLdv8M4w-F-K662NdOmngvgwPa1UrTg@mail.gmail.com>
In-Reply-To: <CAD5OKxt1C_Ljc6wuawypLdv8M4w-F-K662NdOmngvgwPa1UrTg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_D3158E96601Cchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM2K7pW7wofdhBp+fqFlMXf6YxWLFhgOs FjMuTGV2YPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DKODjlNHPBTPGKEw2mDYyb hbsYOTkkBEwkLq2cwwphi0lcuLeeDcQWEjjMKLF5S0gXIxeQvZhRYv2Jr0xdjBwcbAIWEt3/ tEFqRARUJf5+n8wEYjML+Eq8XPCFGcQWBiqZtuQkI0SNpcTqs7cYQeaICHxjlGjev5kdJMEC 1Nz0awtYM6+AlcTjVWtZIJbd55K4t/gC2EWcAoESbfuOgk1lBLru+6k1UNvEJW49mc8EcbWA xJI955khbFGJl4//gfWKCuhJ7Dj3D+ozRYmr05dD9cZL7N0CEecVEJQ4OfMJywRGsVlIxs5C UjYLSRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hLLLuxBUbOAkWMVo2hxanFSbrqRkV5q UWZycXF+nl5easkmRmDEHtzy22AH48vnjocYBTgYlXh4DYTehQmxJpYVV+YeYpTgYFYS4U3d 9z5MiDclsbIqtSg/vqg0J7X4EKM0B4uSOC/rp8thQgLpiSWp2ampBalFMFkmDk6pBkatmc5X yrftfc99+u+rzbtufXm5yOUoY/QBy1daN77t59Ff1ft77X27gybB95mWN4q02y04+Pj0Y4XV 3taPX/7QzzxRVj9j1ZT2P63NiSwLzyu7dN8P2am1lktg37Q5f7nv7RHtfh8Y5NYndK9R5NS1 dfsTyzadf/XsSNz2DRPep35fuezMib1/G5VYijMSDbWYi4oTARQu3vPUAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/dSeXUi4PYb-DK5LzOv5mRD_sglw>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Mon, 21 Mar 2016 09:53:22 -0000

Hi,

>> In my opinion, a=rtcp-mux PLUS a=rtcp with RTP port would be an easy was to indicate mux-exclusive, and it would work both with ICE and non-ICE. I don’t think we should define multiple mechanisms for doing the same thing.
>
>I would argue that a=rtcp is completely redundant potentially ignored information. It does not indicate (at least not yet) that trickle will not generate RTCP candidates. If ICE is used, the absence of RTCP candidates is enough to indicate that RTCP should not be sent yet. If ICE is not used, there is no grantee that a=rtcp is not ignored, so >it does not help. So, we can just include rtcp-mux and do not include any RTCP candidates, and we will get the result we need without any new specifications.

How does the receiver know that RTCP candidates won’t be trickled later?

Regards,

Christer