Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 09 March 2016 13:43 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 B589712DE33 for <mmusic@ietfa.amsl.com>; Wed, 9 Mar 2016 05:43:24 -0800 (PST)
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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94eNxmgmpaos for <mmusic@ietfa.amsl.com>; Wed, 9 Mar 2016 05:43:22 -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 2A85912DE21 for <mmusic@ietf.org>; Wed, 9 Mar 2016 05:43:20 -0800 (PST)
X-AuditID: c1b4fb25-f794e6d000003d15-53-56e02875dce6
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.2E.15637.67820E65; Wed, 9 Mar 2016 14:43:19 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Wed, 9 Mar 2016 14:43:17 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: 'Paul Kyzivat' <pkyzivat@alum.mit.edu>, Peter Thatcher <pthatcher@google.com>
Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE
Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4IAC75iggAA8gYCAADDekIACZK0AgACy7bCAAMFzgIAAUWfNgAYA1QCAADZUAIACTzoAgAs9uQCAAOpNEIAEXzeAgABtuICAAD8/oP//8y4AgAFEVNA=
Date: Wed, 9 Mar 2016 13:43:17 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37EA3F10@ESESSMB209.ericsson.se>
References: <CAJrXDUHutBgaPOV73-CyD_Knz+G5RFE0VX4s3+GqGV8K=B1LNA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> <CAJrXDUGU8SuBHJNQ+Y5DBYcj5pukfXQc742dEFAPCiUKDxN2Cw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se> <CAD5OKxvj25TE-RCvGOU4LQV=a+3aCzZLEB6U=SbTTUmoKVbXeA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E24284@ESESSMB209.ericsson.se> <CAJrXDUG-9CE=vx31gpJZ+Yeb_4LEqUfWWqDsyQNFk1MWfbcTng@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E40FC1@ESESSMB209.ericsson.se> <CAJrXDUFAFymTO+wZnv-8c4pbEbEPSmPprevX_BZY9GS6PNeOXA@mail.gmail.com> <CAJrXDUEGOyASOErt_DHFpaAS-TScxQ=5NHexpjeKS9LPCJ+Qvg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E7032B@ESESSMB209.ericsson.se> <D3044F95.55CF%christer.holmberg@ericsson.com> <56DEFBCB.70203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E9EAC2@ESESSMB209.ericsson.se> <56DF2618.2080204@alum.mit.edu>
In-Reply-To: <56DF2618.2080204@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdVLdc40GYQccdVoupyx+zWKzYcIDV 4try16wOzB5/339g8liwqdRjyZKfTAHMUVw2Kak5mWWpRfp2CVwZXydvZSno0K/4ffozewPj G90uRk4OCQETiTOrulkhbDGJC/fWs3UxcnEICRxmlGg8c4oZwlnMKLFj/hGgKg4ONgELie5/ 2iANIgLBEm1//oGFmQXUJa4uDgIJCws4SOx5spUdosRRYs6Kc2AzRQRuMUpM2nCGBSTBIqAi 8al/GTtIL6+Ar8Scg1YQqxZxSGz9uhDsIE4BHYn2P9PABjECHff91BomEJtZQFzi1pP5TBBH C0gs2XOeGcIWlXj5+B/UM4oSH1/tY4S4TVNi/S59iFZFiSndD8FG8goISpyc+YRlAqPYLCRT ZyF0zELSMQtJxwJGllWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgdF0cMtv1R2Ml984HmIU 4GBU4uEtiLwfJsSaWFZcmXuIUYKDWUmE9776gzAh3pTEyqrUovz4otKc1OJDjNIcLErivKyf LocJCaQnlqRmp6YWpBbBZJk4OKUaGBtmsJt4PcqbWV0ksyzihui/nJAMA+eAe/H3urNCL1/o zOA3KxcUOLTUvEtn08Wjl2/u+anPdffMyTP3E6ZdjE2MMztr/DBxwon3P92tt75j2h7Qv+mS x9wZDcecO9ckXH1iH/B1esCZ8vrC1Mmv/Tt4vlWueins/er/+ouK18OET0R/L1ds3qjEUpyR aKjFXFScCAASvoJYogIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/cq-13kKy9J6-VT0EFZoYPoxbEYQ>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
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 13:43:24 -0000

Hi,

...

>> We already specified this for ICE-related attributes, and the question is whether we should do it also for other attributes that must share the same value.
>
> OK. At the moment I can't think of any reason not to generalize this.

One reason would be if nobody gives a **** :)

Regards,

Christer



>> On 05/03/16 16:04, "mmusic on behalf of Christer Holmberg"
>> <mmusic-bounces@ietf.org on behalf of christer.holmberg@ericsson.com>
>> wrote:
>>
>>> Hi,
>>>
>>>> I took a look, and it seems fine to me.
>>>>
>>>> One question that was brought up to me about this is, though is:
>>>> would it make sense to expand this de-duplication rule to all 
>>>> transport-level attributes (like a=fingerprint) and not just ICE 
>>>> attributes?  We talked about this before, and my response was 
>>>> basically "the ICE candidates are my biggest pain point", but now I 
>>>> think I'm more in favor of saying all transport-level attributes 
>>>> should be de-duplicated.  What does everyone else think?
>>>
>>> I guess it would apply to transport-level attributes AND other 
>>> attributes that must have identical values within a bundle group, 
>>> i.e. attributes within the TRANSPORT and IDENTICAL categories [draft-mux-attributes].
>>>
>>> I don't have any strong opinions. If you think it make life easier 
>>> for implementers we should definitely consider it :)
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>> On Fri, Feb 26, 2016 at 1:23 PM, Peter Thatcher 
>>> <pthatcher@google.com>
>>> wrote:
>>> Sure.
>>>
>>> On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg 
>>> <christer.holmberg@ericsson.com> wrote:
>>> Hi Peter,
>>>
>>> I submitted a new version (-27) of BUNDLE a few days ago. Could you 
>>> take a look at the ICE Considerations section, and say whether you 
>>> are ok with the text?
>>>
>>> Thanks!
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> From: Peter Thatcher [mailto:pthatcher@google.com]
>>> Sent: 25 February 2016 08:53
>>> To: Christer Holmberg <christer.holmberg@ericsson.com>
>>> Cc: Roman Shpount <roman@telurix.com>om>; mmusic@ietf.org; Paul Kyzivat 
>>> <pkyzivat@alum.mit.edu>
>>>
>>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>>>
>>> That makes sense to me.
>>>
>>> On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg 
>>> <christer.holmberg@ericsson.com> wrote:
>>> Hi Roman,
>>>
>>> I didn't check whether some of the ICE attributes were 
>>> session-level, but I agree with what you say: the same rule should 
>>> apply to all media-level ICE attributes.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> Sent from my Windows Phone
>>> ________________________________________
>>> From: Roman Shpount
>>> Sent: ‎21/‎02/‎2016 08:21
>>> To: Christer Holmberg
>>> Cc: Peter Thatcher; mmusic@ietf.org; Paul Kyzivat
>>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE On 
>>> Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg 
>>> <christer.holmberg@ericsson.com> wrote:
>>>>> Correct, and that's one reason I suggest that we limit the scope 
>>>>> to ICE, eventhough we probably could do the same thing for any 
>>>>> IDENTICAL and TRANSPORT category attribute.
>>>>
>>> ​> While it would be nice to remove any duplication, the duplication 
>>> is particularly painful for ICE candidates, because
>>>> there can be a lot of them, and because they change without any 
>>>> offer/answer action (thanks to trickle ICE). ​ So if we just 
>>>> covered that candidates, we'd be getting most of the value.
>>>
>>> Assuming the scope is ICE, shouldn't the same still apply also to 
>>> other ICE related attributes? I assume the values for the 
>>> "remote-candidates", "ice-lite", "ice-mismatch", "ice-ufrag", 
>>> "ice-pwd", "ice-pacing" and "ice-options" attributes will be identical within a BUNDLE group, so...
>>>
>>> "ice-lite" and "ice-options" are session level only candidates, so 
>>> they should not be in the m= line BUNDLE or any other type. The same 
>>> logic that applies to ICe candidates should apply to other media 
>>> level ICE SDP attributes or things will break
>>>
>>> Regards,
>>> _____________
>>> Roman Shpount
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>