Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Flemming Andreasen <fandreas@cisco.com> Thu, 21 March 2013 13:40 UTC
Return-Path: <fandreas@cisco.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 8C12E21F8EDE for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2013 06:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.203
X-Spam-Level:
X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8]
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 oYWiBqAnekXj for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2013 06:40:54 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D48AD21F8837 for <mmusic@ietf.org>; Thu, 21 Mar 2013 06:40:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4176; q=dns/txt; s=iport; t=1363873255; x=1365082855; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YzKlJZUCHa3yeItJSlOs1G+ZuiDwXolfdh+G+a8lvuA=; b=eLYov3QX9fBR57lMKrDoyS3qn5egLVnDJAcW+MWNZ7gD/jiM64mVsWPM QNiXjR0H3nCQ7hvJ5ZcYfkK+Sgl4oCqS1LoAN4qH1uXObDgO2JSn2pmFO Xtt56PamoZsTVGOi7TEPNSj10/9zwfScuV6KugOFZLi/1i68GHSsHmvpN w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAOMLS1GrRDoH/2dsb2JhbABDxTmBWxZ0giQBAQEEAQEBNTYKAQwECxEEAQEBCRYEBAcJAwIBAgEVHwkIBgEMAQUCAQEFiAoNwn+NYYElCwcGgzoDlmSRAoFUgVIggTc
X-IronPort-AV: E=Sophos;i="4.84,886,1355097600"; d="scan'208";a="76233938"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 21 Mar 2013 13:40:54 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.247.102]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2LDepeV031013; Thu, 21 Mar 2013 13:40:52 GMT
Message-ID: <514B0DE4.3060501@cisco.com>
Date: Thu, 21 Mar 2013 09:40:52 -0400
From: Flemming Andreasen <fandreas@cisco.com>
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: Jonathan Lennox <jonathan@vidyo.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Hadriel Kaplan <HKaplan@acmepacket.com>, Atle Monrad <atle.monrad@ericsson.com>, md3135@att.com, Stach Thomas <thomas.stach@siemens.com>, Andrew Allen <aallen@blackberry.com>
References: <5148049B.6090205@cisco.com> <D09DAE6B636851459F7575D146EFB54B2109D350@008-AM1MPN1-026.mgdnok.nokia.com>
In-Reply-To: <D09DAE6B636851459F7575D146EFB54B2109D350@008-AM1MPN1-026.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org
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 13:40:55 -0000
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] 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