Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text
Christer Holmberg <christer.holmberg@ericsson.com> Mon, 22 February 2016 10:10 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 3F0201B2F80 for <mmusic@ietfa.amsl.com>; Mon, 22 Feb 2016 02:10:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 wLhG4RaJB9-E for <mmusic@ietfa.amsl.com>; Mon, 22 Feb 2016 02:10:05 -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 9BF471ACD8E for <mmusic@ietf.org>; Mon, 22 Feb 2016 02:10:04 -0800 (PST)
X-AuditID: c1b4fb25-f794e6d000003d15-d1-56cade7a781d
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.4C.15637.A7EDAC65; Mon, 22 Feb 2016 11:10:02 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 11:10:02 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text
Thread-Index: AdFtWOeeQ/zW0OtpRAOrN5PglHqZIw==
Date: Mon, 22 Feb 2016 10:10:01 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37E3054E@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E3054EESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7qG7VvVNhBn8aDC2mLn/MYrFiwwFW i2vLX7NazLgwldmBxePv+w9MHgs2lXosWfKTyePWlIIAligum5TUnMyy1CJ9uwSujMfHfjEX 3DnAVLF+wSTWBsY1O5i6GDk5JARMJBaves8OYYtJXLi3nq2LkYtDSOAwo8SH5fOYQRJCAosZ JY6tkOhi5OBgE7CQ6P6nDRIWEVCX+Lq3hxmknllgPaNEZ9smRpCEsECwxPXuzWwQRSESi6ef Zoaw9SQWTToFVsMioCqxee9jMJtXwFfi7ep5YEcwAh3x/dQasOOYBcQlbj2ZD3WogMSSPeeZ IWxRiZeP/7FC2EoSaw9vZ4Goz5c4fG0bK8RMQYmTM5+wTGAUnoVk1CwkZbOQlM0Ceo1ZQFNi /S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjLKD W36r7mC8/MbxEKMAB6MSD68B56kwIdbEsuLK3EOMEhzMSiK8W48ChXhTEiurUovy44tKc1KL DzFKc7AoifOucV4fJiSQnliSmp2aWpBaBJNl4uCUamBMNP9cNWvZtbrYXe3JMrvMzvHG39c6 8Lt31rQW7amNnw6H6j+UZZ/To/k7oWTbR/Ga9x421yZskXCJF9o/YWVJ/snbCl3Vpy9vOuDV brB/u9AXu4vv+QyZXdvVZEpmuYvIGqj72zLrcTglC14IPtVutd4lr8DHYfUTa9Y/HYuVP3WY ZxnsWK7EUpyRaKjFXFScCABVrrL9rgIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/CJJC69ZEIkAhk8oIQ7fu4lIh-IE>
Cc: Ari Keränen <ari.keranen@ericsson.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text
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: Mon, 22 Feb 2016 10:10:09 -0000
Hi, Assuming we will only associated ICE candidates to the “m=” line associated with the offerer/answerer BUNDLE-tag, below is a first suggested of modified ‘ICE Considerations’ text: ----------------------- 11. ICE Considerations 11.1. General This section describes how to use the BUNDLE grouping extension together with the Interactive Connectivity Establishment (ICE) mechanism [RFC5245]. The generic procedures for negotiating usage of ICE using SDP, defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE with BUNDLE, with the following exceptions: o When BUNDLE addresses for a BUNDLE group have been selected for both endpoints, ICE connectivity checks and keep-alives only need to be performed for the whole BUNDLE group, instead of per bundled "m=" line. o Among bundled "m=" lines with which the offerer has associated a shared address, the offerer only associates ICE-related media- level SDP attributes with the "m=" line associated with the offerer BUNDLE-tag. o Among bundled "m=" lines with which the answerer has associated a shared address, the answerer only associates ICE-related media- level SDP attributes with the "m=" line associated with the answerer BUNDLE-tag. Support and usage of ICE mechanism together with the BUNDLE extension is OPTIONAL. 11.2. SDP Offer/Answer Procedures 11.2.1. General When an offerer associates a unique address with a bundled "m=" line (excluding any bundle-only "m=" line), it MUST also associate unique ICE candidates to the "m=" line, according to the procedures in [I-D.ietf-mmusic-ice-sip-sdp]. An offerer MUST NOT associate ICE candidates with a bundle-only "m=" line with a zero port value. NOTE: The bundle-only "m=" line, if accepted by the answerer, will inherit the candidates associated with the selected offerer BUNDLE address. An answerer that does not support BUNDLE would not accept a bundle-only "m=" line. When an offerer or answerer associates a shared address (i.e. a previously selected BUNDLE address) with one or more bundled "m=" lines, the offerer (or answerer) MUST only associate SDP 'candidate' attributes with the "m=" line associated with the offerer BUNDLE-tag (or the answerer BUNDLE-tag) address). The offerer or answerer MUST NOT associate 'candidiate' attributes with any other bundled "m=" line to which the offerer (or answerer) associates a shared address. This also apply to any other ICE-related media-level SDP attribute. NOTE: The following ICE-related media-level SDP attributes are defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote- candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- pacing'. 11.2.2. Generating the Initial SDP Offer When an offerer generates an initial offer, it associates unique ICE candidates with the bundled "m=" lines, according to Section 11.2.1. 11.2.3. Generating the SDP Answer When an answerer generates an answer that contains a BUNDLE group, the answerer MUST only associate SDP 'candidate' attributes (and other ICE-related media-level SDP attributes) with the "m=" line associated with the answerer BUNDLE-tag. 11.2.4. Offerer Processing of the SDP Answer When an offerer receives an answer, if the answerer supports and uses the ICE mechanism and the BUNDLE extension, the offerer MUST associate the same ICE candidates, associated with the "m=" line representing the offerer BUNDLE address (selected by the answerer), with each bundled "m=" line. 11.2.5. Modifying the Session When an offerer generates a subsequent offer, it associates unique or shared ICE candidates with the bundled "m=" lines, according to (Section 11.2.1). ----------------------- Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 21 February 2016 12:12 To: Roman Shpount <roman@telurix.com> Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE 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<mailto:roman@telurix.com> Sent: 21/02/2016 08:21 To: Christer Holmberg<mailto:christer.holmberg@ericsson.com> Cc: Peter Thatcher<mailto:pthatcher@google.com>; mmusic@ietf.org<mailto:mmusic@ietf.org>; Paul Kyzivat<mailto:pkyzivat@alum.mit.edu> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto: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
- Re: [MMUSIC] Questions about ICE candidates with … Christer Holmberg
- Re: [MMUSIC] Questions about ICE candidates with … Roman Shpount
- Re: [MMUSIC] Questions about ICE candidates with … Christer Holmberg
- Re: [MMUSIC] Questions about ICE candidates with … Paul Kyzivat
- Re: [MMUSIC] Questions about ICE candidates with … Christer Holmberg
- Re: [MMUSIC] Questions about ICE candidates with … Paul Kyzivat