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

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 05 March 2016 15:39 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 504851A1A4B for <mmusic@ietfa.amsl.com>; Sat, 5 Mar 2016 07:39:36 -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 xNYNgNAppM2C for <mmusic@ietfa.amsl.com>; Sat, 5 Mar 2016 07:39:34 -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 724411A1A16 for <mmusic@ietf.org>; Sat, 5 Mar 2016 07:39:34 -0800 (PST)
X-AuditID: c1b4fb2d-f79836d000006396-17-56dafdb37873
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 64.E4.25494.3BDFAD65; Sat, 5 Mar 2016 16:39:32 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Sat, 5 Mar 2016 16:39:31 +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: AQHRdajWE2kKEUdcwUGjD2CZk1wvxJ9I7sEQgAAvLYCAABdykP//+CcAgABTMICAAAArgIABZCbQ///1Q4CAACIS8A==
Date: Sat, 05 Mar 2016 15:39:31 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37E7444F@ESESSMB209.ericsson.se>
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>
In-Reply-To: <CABcZeBNtmfjrETCerCu=A5BXt5HRCG+nO4KZ4ze3sBEeRNnX_A@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.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdV3fL31thBrPW8ViseH2O3WLq8scs DkweS5b8ZPKY/LiNOYApissmJTUnsyy1SN8ugStj+vnpzAWXBCvu78ppYJwh2MXIySEhYCJx 6to7ZghbTOLCvfVsXYxcHEIChxklfk+/zArhLGaUaH3xkKWLkYODTcBCovufNkiDiICCxK8/ J1hAbGYBeYkLS9YwgdjCQCX3bt5ih6ixlFh99hYjhJ0l0fNwLRuIzSKgInG+6wXYSF4BX4lF 250hVv1hkej6tx1sDqdAoMTlN9/BehmBjvt+CmI+s4C4xK0n85kgjhaQWLLnPNQDohIvH/9j hbCVJFZsv8QIMp9ZQFNi/S59iFZFiSndD8FO4xUQlDg58wnLBEaxWUimzkLomIWkYxaSjgWM LKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAiPn4JbfujsYV792PMQowMGoxMNbIHwrTIg1 say4MvcQowQHs5IIr/1roBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFetk+Xw4QE0hNLUrNTUwtS i2CyTBycUg2M0ZKe34P+v9nOpGuorMaatO4576v1GzKbVrK48j/3ZZ8VIMBwd0FwfdflI5UJ Tp+eZpxsa+Y+tfDR2qIZllFFxVzfVFgWC321rtwT5GzA9y+kT6vmj17Cjtv10b7dOQz12dfW vdQo+Nq34opBnltWv95e1sNqqhYaW8QqCzsPBEXOYmP9X6fEUpyRaKjFXFScCAC5EpZdmAIA AA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/TXkO4lYbzIDv3NIGnOu3WEhGEqA>
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: Sat, 05 Mar 2016 15:39:36 -0000

Hi,

>>> Yes, of course, but the question is how they will behave if they receive rtcp-mux-exclusive.
>>
>> IF (for whatever reason) non-mux is required on the "other side" of the gateway then the gateway will do "transcoding" between mux and non-mux.
>
> Given that essentially every Web browser is going to do only mux, it seems like the gateway
> can just infer this. In fact, since in most of these cases, the gateway and the Web app are
> related entities, that should be extremely straightforward.

WebRTC is more than browsers, and mux-exclusive is more than WebRTC. There is a general wish to move towards mux. However, that is not going to happen over night.

>>> Can we get those implementors to speak up on the list?
>>
>>I represent one of those implementers :)
>
>Yes, I had assumed so.
>
>Bottom line, this seems like just another piece of complexity for minimal value, so I
>propose dropping it.

I don't see the complexity - it's adding a static attribute without a value, in the same way you add a=rtcp-mux. If your browser is always only going to do mux there is no need for any additional logic or configuration.

Also, I don't agree with minimal value. Reserving RTCP resources that may never be needed, and/or doing mux/non-mux transcoding "just in case" is not minimal. Maybe for single-user device, but not for devices handling large number of users.

And, again, from a protocol perspective, a=rtcp-mux means you are able to fallback, and I don't think we shall break that semantics. There are enough problems related to offer/answer, we don't need to create more on purpose.

Regards,

Christer