Re: [MMUSIC] The way forward wih mux-exclusive

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 15 April 2016 07:57 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 368D012E80B for <mmusic@ietfa.amsl.com>; Fri, 15 Apr 2016 00:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa6VRcbFbmFZ for <mmusic@ietfa.amsl.com>; Fri, 15 Apr 2016 00:57:35 -0700 (PDT)
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 5B8EF12E810 for <mmusic@ietf.org>; Fri, 15 Apr 2016 00:57:04 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-c4-57109ece3578
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.58.12926.ECE90175; Fri, 15 Apr 2016 09:57:02 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Fri, 15 Apr 2016 09:56:41 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] The way forward wih mux-exclusive
Thread-Index: AQHRkaSKAzvOrS1NEUKZX+GpUspZkJ+Ag4GAgAkRLQCAAB/+AIAAMFCg///jlYCAAANKgIAAApKAgAACpgCAAPVFgA==
Date: Fri, 15 Apr 2016 07:56:40 +0000
Message-ID: <D33678AF.7031%christer.holmberg@ericsson.com>
References: <5707C2A6.2060001@cisco.com> <CAD5OKxshqQA5YMn6RuALcWhYjLTQB4d-H-7+JatMwO7AnT+pCw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37F37087@ESESSMB209.ericsson.se> <CAD5OKxtj-58ZN5VqKouu3Pf6c3Hjd+eQz9aD_a6+cLgaf-98tw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37F3715D@ESESSMB209.ericsson.se> <CAD5OKxuq+djAMceiweSpzNtfVWHzBtm=n8-=-uuhybVHAtvNHQ@mail.gmail.com> <570FF6EF.7020308@alum.mit.edu> <CAD5OKxv=SdH2_LQVh3gqDqTnpWk-_GhwsrnJdajcvnYw3P+VFQ@mail.gmail.com> <570FFB50.6000904@alum.mit.edu>
In-Reply-To: <570FFB50.6000904@alum.mit.edu>
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.147]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9A8AD005AA83A24CBA64AD83A40A8D88@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7uu65eQLhBq8b1CymLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlLJ6/jbFgj1DF+86LjA2M y/i6GDk5JARMJNo63jFB2GISF+6tZ+ti5OIQEjjCKLFt43oWCGcxo8TP23+Zuxg5ONgELCS6 /2mDNIgIeEtMmL+aDSTMLKAucXVxEEhYWMBc4t/EF8wQJRYSs5dcZIGwsyR6l75kA7FZBFQl nnU2M4G08gpYSax4JQGxaQKLxLSJ58BqOAV0JI43TQKzGYFu+35qDdidzALiEreezIe6WUBi yZ7zzBC2qMTLx/9YQWxRAT2JHedAbA6guJLEtK1pEK16EjemTmGDsK0lzp+HsbUlli18DTaG V0BQ4uTMJywTGCVmIdk2C0n7LCTts5C0z0LSvoCRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5q ySZGYFQe3PJbdQfj5TeOhxgFOBiVeHgTmgXChVgTy4orcw8xSnAwK4nwys8FCvGmJFZWpRbl xxeV5qQWH2KU5mBREufNjvwXJiSQnliSmp2aWpBaBJNl4uCUamAs4V+/MGTT54euLJfljT6e CVEI9juX+lfjiCrXg0XpcpKJbP6q/AkeioXvz20J3f6ycXdSwFc3Jv5pzzzeavxYnrXx95bv VvLfNH7w1e37MkdGLfJFwR+xuboHmjZNY5lkZPzhhsLqRFEznddsLarWS0IvGu5KaF8ecLpz Kl/Sp78XO/YKFTQqsRRnJBpqMRcVJwIAXR4UtMYCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Y-RIyvOLvPYYYddffCHjytYNzFQ>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] The way forward wih 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: Fri, 15 Apr 2016 07:57:38 -0000

Hi,

First, I am ok to rename the attribute, in order to make it shorter. Roman
has suggested the name change a few times already, and nobody has
objected, so I¹ll change it in the next version of the draft.

Second, if we also allow ³a=rtcp-mux², I guess we would need to update
5761 by saying something like:

³By default, the sender of the attribute must be used with RTCP fallback,
unless another mechanism is used to indicate that such fallback is not
supported.²

Regards,

Christer



On 14/04/16 23:19, "mmusic on behalf of Paul Kyzivat"
<mmusic-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:

>On 4/14/16 4:09 PM, Roman Shpount wrote:
>> On Thu, Apr 14, 2016 at 4:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>>     On 4/14/16 3:49 PM, Roman Shpount wrote:
>>
>>         This can currently produce interop problems. With current
>>usage, if
>>         rtcp-mux is supported by the remote end point, it will correctly
>>         negotiate with rtcp-mux-exclusive. If you remove rtcp-mux
>>         attribute from
>>         the offer, connection will not be established. This will be
>>         especially
>>         important during the migration from rtcp-mux to
>>         rtcp-mux-exclusive for
>>         current implementations. Only inserting rtcp-mux-exclusive, of
>>         cause, is
>>         better long term, since it is removing redundant information
>>         from SDP.
>>
>>
>>     So, why not remove use of rtcp-mux as a *requirement* and leave it
>>     as an implementation tactic for migration?
>>
>>
>> I would be happy to remove this as a "requirement". Specify that it can
>> be optionally used during the migration. But if we do this we will need
>> to update RFC5761, since rtcp-mux will be used without RTCP fallback
>> address being provided (which is required by RFC5761).
>
>I guess that "depends". If there is a normative statement about it (even
>MAY) then I guess you are right. OTOH, maybe not if there is just a note
>about it, explaining that it it technically a non-conforming usage, and
>discussing the pros/cons of doing so.
>
>	Thanks,
>	Paul
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic