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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 04 March 2016 12:28 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 13FD31B37B0 for <mmusic@ietfa.amsl.com>; Fri, 4 Mar 2016 04:28:04 -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, 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 STAr-XK6ffun for <mmusic@ietfa.amsl.com>; Fri, 4 Mar 2016 04:28:02 -0800 (PST)
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 921FE1B37B1 for <mmusic@ietf.org>; Fri, 4 Mar 2016 04:28:02 -0800 (PST)
X-AuditID: c1b4fb30-f79d26d000006389-7b-56d97f50b02b
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DF.76.25481.05F79D65; Fri, 4 Mar 2016 13:28:00 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Fri, 4 Mar 2016 13:28:00 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [MMUSIC] Why do we need rtcp-mux-exclusive?
Thread-Index: AQHRdajWE2kKEUdcwUGjD2CZk1wvxJ9I7sEQgAAvLYCAABdykA==
Date: Fri, 04 Mar 2016 12:27:58 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37E5BBC1@ESESSMB209.ericsson.se>
References: <CABcZeBNsJkqGcU3Z=eekP4ntj7r3WMz6YOSiFt=u+HdDH2Zk3Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E5A4E2@ESESSMB209.ericsson.se> <CABcZeBOGpguqkEeUoH35R2S_fOU=eGWgG7r5gmH3T_UHXqRRjg@mail.gmail.com>
In-Reply-To: <CABcZeBOGpguqkEeUoH35R2S_fOU=eGWgG7r5gmH3T_UHXqRRjg@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.20]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdWjeg/maYwYJNihYrXp9jt5i6/DGL A5PHkiU/mTwmP25jDmCK4rJJSc3JLEst0rdL4MrYcP0Jc8ENroqL800bGLdwdTFyckgImEj8 mbeFHcIWk7hwbz1bFyMXh5DAYUaJHyfvMkM4ixglet7tYu1i5OBgE7CQ6P6nDdIgIqAg8evP CRYQm1lAXuLCkjVMILYwUMm9m7fYIWosJVafvcUIYTtJTFm+FyzOIqAi8W/mMrBeXgFfid+N 51ggdt1mlLgyoQ+siFMgUGLqnslgQxmBrvt+CmIBs4C4xK0n85kgrhaQWLLnPDOELSrx8vE/ VghbUeLq9OVMIDczC2hKrN+lD9GqKDGl+yE7xF5BiZMzn7BMYBSbhWTqLISOWUg6ZiHpWMDI sopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMHYObvltsIPx5XPHQ4wCHIxKPLwbVlwPE2JN LCuuzD3EKMHBrCTCu6DyZpgQb0piZVVqUX58UWlOavEhRmkOFiVxXtZPl8OEBNITS1KzU1ML UotgskwcnFINjL6h5/ruXKzX7fOaFHviaaZTT+UkLoOiu0t/Kizufh/9M9HyGHc/V5278r9P H5/fMllyfmqo+q0Y5z6lncX2XgdFVl9+pVy4ofPrlHmMbRXBYq8LVuT+f+nE1/rh3dWXlQvM FP8+P7n50LQo27cnD2/fofCM38Ffq08vw8XaZl/TIa3emg3lt5RYijMSDbWYi4oTASvZiz6Z AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/vE_zzJmFVWDOgLm3mQjAPX1chWk>
Cc: 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.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, 04 Mar 2016 12:28:04 -0000

Hi,

>>But, we agreed that we want to have an explicit indicator, 
>
>My point is that I think that that agreement was wrong and we should not do so.

I think such statements should be given when the chairs initially ask the community whether it is something we should work on in the first place - not during WGLC, after people have spent time and effort on defining the feature.

>>and then we can only hope people will implement it (by mandating support of it etc).
>
>But again, why would you?

Because then you will have a mechanism to explicitly indicate that you can do mux only, without having to test-and-fail. The current rtcp-mux attribute indicates that you are able to do fallback to non-mux, and entities (endpoints and intermediaries) will have to have resources if that happens.

Also, in non-ICE cases there will be no candidates, so entities will always have to assume that the rtcp-mux attribute indicates possibility to fallback to non-mux.

Regards,

Christer