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

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 09 March 2016 16:37 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 992CA12D7AA for <mmusic@ietfa.amsl.com>; Wed, 9 Mar 2016 08:37:15 -0800 (PST)
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=ham autolearn_force=no
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkbq_rdlN6X9 for <mmusic@ietfa.amsl.com>; Wed, 9 Mar 2016 08:37:14 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88A412D7A4 for <mmusic@ietf.org>; Wed, 9 Mar 2016 08:37:13 -0800 (PST)
X-AuditID: c1b4fb25-f794e6d000003d15-9b-56e05137e01d
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AC.4B.15637.73150E65; Wed, 9 Mar 2016 17:37:12 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Wed, 9 Mar 2016 17:37:11 +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///1Q4CAACIS8IAAC0KAgAPbM4CAAAkjgIAAGHWAgAAE5ICAADHDgIABfqxAgACGpoCAACjoAA==
Date: Wed, 09 Mar 2016 16:37:11 +0000
Message-ID: <D30619E9.5867%christer.holmberg@ericsson.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> <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>
In-Reply-To: <CAD5OKxuC8kS=qAFkJrgZJndEvzXCrEAh=U2b4Na57MYY93o-+A@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.1.160122
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_D30619E95867christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUyM2K7k65F4IMwg2ct3BYb9v1ntnh/Qdfi 2pl/jBZTlz9msZhxYSqzA6vHlN8bWT12zrrL7rFkyU8mj1tTCgJYorhsUlJzMstSi/TtErgy mvdpF5w0qlgy7T9rA+NTzS5GTg4JAROJ+8t/MkPYYhIX7q1n62Lk4hASOMwoMe3xAXYIZzGj xJTTSxi7GDk42AQsJLr/aYM0iAioSvz9PpkJpIZZYAGjxMKmyawgCWGgmmlLTjJCFFlKrD57 ixGkSERgGaPE97VPmEASLAIqEhvOrGQDsXkFrCTuNm0Es4UEtnNKdE8RB7E5BQIltu1bBzaU Eei876fWgPUyC4hL3HoynwnibAGJJXvOQ70gKvHy8T+welEBPYnbHWvZIeJKEo1LnrBC9MZL nDq0jQVir6DEyZlPWCYwis1CMnYWkrJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylnEWMIyY Bawlrr9yRVaygJFjFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgNB/c8lt1B+PlN46HGAU4 GJV4eAsi74cJsSaWFVfmHmKU4GBWEuEt9n4QJsSbklhZlVqUH19UmpNafIhRmoNFSZyX9dPl MCGB9MSS1OzU1ILUIpgsEwenVAMj80WP6Nun+7o3SSvETfrJniP6Jjvu3BVz73+d0Q9XmFyR CDxbz1h937Z1s7OL/ULHb7KVP00OmmlNXvrv9PT7BzK9brLNfJIe+5sto21dw9moh/yfLa9M iT2rqCSpWaIU4bjpjZlPlVVsTub1mAoJZg6XCyZSC33TnDTTJtffZHu1VlaVZZcSS3FGoqEW c1FxIgCEiuhp4gIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/raiU-qxRMF7-7IcYsLgF_xA8nlY>
Cc: Flemming Andreasen <fandreas@cisco.com>, mmusic WG <mmusic@ietf.org>
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: Wed, 09 Mar 2016 16:37:15 -0000

Hi,

>I was against a=rtcp for two reasons:
>
>1. There is a conflict with RFC 5245 and things derived from it such as JSEP which caused confusion. I have proposed the language to draft-ietf-mmusic-ice-sip-sdp to make a=rtpc optional. I am not sure if this was accepted or is still being discussed. If this language is accepted then this reason goes away.
>
>2. I want to limit a=rtcp for non-ICE end points only or only when interop with non-ICE end points is desired. For anything modern which will not work without ICE, such as webrtc, there
>is no reason to specify RTP address in c= and m= lines, or RTCP address in a=rtcp. I do not want to create new usages for a=rtcp to keep it alive after it have outlived its usefulness. For webrtc, including
>a=rtcp-mux, setting c= address to IN IP4 0.0.0.0, m= to port 9, and not generating any RTCP ICE candidates should be enough to indicate what we want to achieve with a=rtcp-mux-only.
>
>As far as a=rtcp-mux-exclusive is concerned, I see it as a optimization attribute which helps in the following two cases:
>
>1. Tells the remote end point not to allocate RTCP ICE candidates if trickle ICE is used. This can be an ice-option. I would actually prefer the ice-option to say the opposite, i.e. that RTCP candidates will be allocated, since not allocating RTCP candidates will be a much more common flow.
>
>2. Tells any RTP forwarding intermediaries such as SBC, not to allocate any resources to forward RTCP. I think this is really marginal

I don’t think we should argue about whether we think the associated resource allocation is marginal or not – it is very product/deployment specific.

3. Tells whether a gateway needs to perform "mux transcoding", in case the gateway is connected to a network where usage of mux is not supported (for whatever reason).

I have no problem using ice-options, if that works. But, what happens if an endpoint does not support the received ICE option-tag? Will it simply discard it? If so, how would that be more backward compatible than a new attribute?

And, what about a=rtcp-mux plus RTP candidate, as suggested by Martin? That would probably work, assuming we don’t allow RTCP candidates to be trickled later (I would assume RTP and RTCP candidates are always sent together).

Regards,

Christer