Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 21 March 2013 20:06 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 6143521F8CB4 for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2013 13:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Level:
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpm85Qu0mcba for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2013 13:06:17 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 768F021F8CCF for <mmusic@ietf.org>; Thu, 21 Mar 2013 13:06:17 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id EEHT1l00516LCl059L6Gjl; Thu, 21 Mar 2013 20:06:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id EL6G1l00Q3ZTu2S3SL6GeR; Thu, 21 Mar 2013 20:06:16 +0000
Message-ID: <514B6837.50505@alum.mit.edu>
Date: Fri, 22 Mar 2013 04:06:15 +0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: mmusic@ietf.org
References: <5148049B.6090205@cisco.com> <D09DAE6B636851459F7575D146EFB54B2109D350@008-AM1MPN1-026.mgdnok.nokia.com> <514B0DE4.3060501@cisco.com> <F81CEE99482EFE438DAE2A652361EE120679B5DD@MCHP04MSX.global-ad.net>
In-Reply-To: <F81CEE99482EFE438DAE2A652361EE120679B5DD@MCHP04MSX.global-ad.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363896376; bh=sHvsHdAiXoiQ3fjHy/iYTJ1PC+hgbIF0OH+Di+ipgdk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZnIgggeeWwL77fMWO2FUrHN9bHX6oztjJXEO1cFj/COxiU2KdjKZsq3Tfb3aQW0kx geuhG+TGIzUfSGE3PCCdo4vjNrc0NLVe2PU9docMCSWRgRRbVEmM4DliUpF6QICikh 8V3WCbuGUi5Gp1ydCyfXgM7NNV3Xkgmiv3kDRlg6fwRviLLyH2O4ZAYQXbY3XpmXqq uY1+L8wVlvfzWM80AhQMzo4TFBvhwmj3AZdz/OLV1tVASV1iLgPMnr9SjFmg3/ybmI OosMpr00CDplk/1KVGqIkCUVstOe2x+wJfxBOUmIdGHkFxyRFusHvCAnkcOy3Nms+l DzCFn/ATGMVbg==
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 21 Mar 2013 20:06:18 -0000
+1 On 3/22/13 12:28 AM, Stach, Thomas wrote: > I don't object against having an IP adress in the ccap attribute and a PSTN number in the c-line, > if that indicates a preference for the PSTN number. > But I don't like to have an IPv4 and/or IPv6 adress in both ccap and c-line > as this would introduce a second method for IPv4/v6 negotiation in addition to ICE. > > My objection on this is based on what I remember from the IETF-68 discussion > on usage of ICE vs. ANAT vs. SDP Capability-Negotiation for IPv4/IPv6 negotiation. > Cap-Neg did not address negotiations of IP address families at that time, > but could have been extended accordingly. > > Although the consensus at that meeting was very rough, ICE was finally selected as the > method of choice since it also allows to test which address family would work based on connectivity checks. > This also led to the deprecation of ANAT, as people didn't want to have two methods for the > IPv4/IPv6 negotiation (and due to ANAT's other drawbacks). > A Cap-Neg extension via ccap would also miss a function for connectivity checking (common with ANAT). > I think this ability was seen as the major advantage of ICE and an Cap-Neg extension > was no longer persued until the need for negotiation of a PSTN vs. IP adress came up. > We should stick to the decision from IETF-68 to only use ICE for IPv4/v6 negotiation. > > > Regards > Thomas > >> -----Ursprüngliche Nachricht----- >> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> Im Auftrag von Flemming Andreasen >> Gesendet: Donnerstag, 21. März 2013 14:41 >> An: Jonathan Lennox; mohamed.boucadair@orange.com; Hadriel >> Kaplan; Atle Monrad; md3135@att.com; Stach Thomas; Andrew Allen >> Cc: mmusic@ietf.org >> Betreff: Re: [MMUSIC] Connection Data Capability (ccap) and >> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >> >> Can we get some more comments from people on this please. In >> particular, >> I would like to hear if people are against "ccap" being able >> to convey >> an IP-address or not (if not, we can then debate the details of the >> restrictions around that separately) ? >> >> Thanks >> >> -- Flemming >> >> >> On 3/20/13 5:56 AM, Simo.Veikkolainen@nokia.com wrote: >>> I went through the discussion, and my reading is that there >> is agreement on not allowing ccap to be used for alternative >> IP address negotiation. >>> >>> That could be made clear in the text e.g. by modifying the >> second sentence Flemming quoted to read: >>> >>> <quote> >>> The 'ccap' attribute MUST NOT be used to select >>> between different IP connection addresses (e.g. between >>> "IP4" and "IP6" address families or different IP addresses >>> within the same IP address family). >>> </quote> >>> >>> The ccap attribute should be able to carry either an IP or >> PSTN address; that way either a PSTN or an IP bearer could be >> offered as the highest priority configuration (in the "m=" >> line). However, if we want to clarify the intended use of >> ccap, we could modify the first sentence to read: >>> >>> <quote> >>> The 'ccap' capability attribute is intended for offering >>> alternative connection addresses where the <nettype> >>> is "IN" or "PSTN", i.e. selecting between an IP based >>> bearer or a circuit-switched bearer. >>> </quote> >>> >>> Simo >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen >>> Sent: 19. maaliskuuta 2013 8:24 >>> To: mmusic >>> Subject: [MMUSIC] Connection Data Capability (ccap) and >> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04) >>> >>> Greetings >>> >>> As you may have seen, there has recently been some list >> discussion on the "connection data capability" defined in >>> draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html) >>> >>> To recap, the connection data capability ("ccap") provides >> capability negotiation capabilities for what amounts to the >> "c=" line in regular SDP, and as such enables negotiation of >> network type (such as "IN") and IP-address information (v4 >> and v6 addresses). The Standards Track mechanism for >> negotiating and determining alternative IP-address >> information today is ICE, and hence the draft currently >> includes the following wording: >>> <quote> >>> The 'ccap' capability attribute is intended to >>> be used only when there is no other mechanism available for >>> negotiating alternative connection address >> information, such as when >>> the <nettype> is different among the alternative >> addresses (e.g. >>> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >>> situations where an existing mechanism (such as Interactive >>> Connectivity Establishment (ICE) [RFC5245]) can be >> used to select >>> between different connection addresses (e.g. "IP4" >> and "IP6" or >>> different IP addresses within the same IP address family). >>> </quoted> >>> >>> The above text has led to some confusion as to exactly when >> and what "ccap" can be used for. More specifically, is >> it/should it ever be allowed to use "ccap" to convey an IP4 >> or IP6 address, and if so, under what circumstances ? >>> >>> If you have an opinion, please let us know. >>> >>> A couple of points to keep in mind: >>> - The current document has been WGLC'ed without comment ~6 >> months ago. >>> - 3GPP has a dependency on the document (however I'm not >> sure if that dependency includes the above "IN" feature) >>> - The connection data capability is defined in a general >> manner to be generally useful in line with the overall >> capability negotiation framework (as opposed to targeted at >> one specific use case with one specific value) >>> - There are scenarios where ICE cannot be used, even if >> implemented (e.g. ice-mismatch). >>> - RFC 6849 (media loopback) provides for NAT traversal in >> the absence of ICE support >>> >>> >>> Thanks >>> >>> -- Flemming >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> . >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- [MMUSIC] Connection Data Capability (ccap) and IP… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Andrew Allen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Hadriel Kaplan
- Re: [MMUSIC] Connection Data Capability (ccap) an… Simo.Veikkolainen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Stach, Thomas
- Re: [MMUSIC] Connection Data Capability (ccap) an… Paul Kyzivat
- Re: [MMUSIC] Connection Data Capability (ccap) an… Andrew Allen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Andrew Allen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Andrew Allen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Jonathan Lennox
- Re: [MMUSIC] Connection Data Capability (ccap) an… Christer Holmberg
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Hadriel Kaplan
- Re: [MMUSIC] Connection Data Capability (ccap) an… Hadriel Kaplan
- Re: [MMUSIC] Connection Data Capability (ccap) an… Hadriel Kaplan
- Re: [MMUSIC] Connection Data Capability (ccap) an… Andrew Allen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Andrew Allen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… mohamed.boucadair
- Re: [MMUSIC] Connection Data Capability (ccap) an… Simo.Veikkolainen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… mohamed.boucadair
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… mohamed.boucadair
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… mohamed.boucadair
- Re: [MMUSIC] Connection Data Capability (ccap) an… Simo.Veikkolainen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Flemming Andreasen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Simo.Veikkolainen
- Re: [MMUSIC] Connection Data Capability (ccap) an… Simo.Veikkolainen
- [MMUSIC] Last chance to comment: Re: Connection D… Flemming Andreasen