Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 08 March 2016 19:09 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 3CC0712D9FD for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 11:09:03 -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 DdGLE2fRGQj6 for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 11:08:59 -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 7B04312DA09 for <mmusic@ietf.org>; Tue, 8 Mar 2016 11:08:51 -0800 (PST)
X-AuditID: c1b4fb25-f794e6d000003d15-8a-56df2341cdbc
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AB.7D.15637.1432FD65; Tue, 8 Mar 2016 20:08:49 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Tue, 8 Mar 2016 20:08:49 +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/oA==
Date: Tue, 08 Mar 2016 19:08:48 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37E9EAC2@ESESSMB209.ericsson.se>
References: <CAJrXDUHutBgaPOV73-CyD_Knz+G5RFE0VX4s3+GqGV8K=B1LNA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37DF9E40@ESESSMB209.ericsson.se> <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>
In-Reply-To: <56DEFBCB.70203@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.148]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdXddR+X6YwYQDFhZTlz9msVix4QCr xbXlr1kdmD3+vv/A5LFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgyVr20KrhlUvHx1WS2BsY1 xl2MnBwSAiYSjz/8Y4SwxSQu3FvP1sXIxSEkcJhRYtOMfmYIZzGjxNYfW4EcDg42AQuJ7n/a IKaIQKDEw9VCICazgLrE1cVBIGOEBRwk9jzZyg5iiwg4SsxZcQ5spIjAOUaJRRsOsoIkWARU JK5vXQw2kVfAV+LyySKQsJBAA4fEk20KIDangJbE/zWzwcoZgU77fmoNE4jNLCAucevJfCaI kwUkluw5zwxhi0q8fPyPFcJWkmhc8oQV4jRNifW79CFaFSWmdD8EO41XQFDi5MwnLBMYxWYh mToLoWMWko5ZSDoWMLKsYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMo4NbfqvuYLz8xvEQ owAHoxIP7wf2e2FCrIllxZW5hxglOJiVRHjXKt4PE+JNSaysSi3Kjy8qzUktPsQozcGiJM7L +ulymJBAemJJanZqakFqEUyWiYNTqoGx6erd21VPyxlDpGUqT8bd5uIK4146b33m8q96i6a4 HJBd5n54w1Svyg3Pp/onHPWzkd4/P4ZtKy+Hs82MiJJ2xpJ1s+7E3e94FnjxgVaMwszuyS3L XW1//nTs3b2w0/nHpNebJb1vnywpvTihYceyvuXhewMCI29oXur6d3o1+6rs97r57194KLEU ZyQaajEXFScCACEiRHWfAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/ylYciWO191I40j3MoFawgXxshZ0>
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: Tue, 08 Mar 2016 19:09:03 -0000

Hi,

>> Does anyone else have opinions on this? One would assume that the 
>> folks (Bernard, Martin, Ekr…) representing the other browser vendors 
>> would have an opinion.
>>
>> Whatever your opinion is (even if you don’t care), please indicate so NOW.
>> I want to avoid implementing this change, and then have someone saying 
>> he/she doesn’t like it...
>
> I have lost track - is the intent to limit this de-duplication to bundle-only? If it is to apply to m-lines that might be removed from the bundle then it gets more complicated.
>
> I guess it couldn't *only* apply to bundle-only - at least one of the lines in the group can't have that.

It applies to bundled m- lines that contain a previously negotiated *shared* address (not only bundle-only).

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.

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>; 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
>