Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

Andrew Allen <aallen@blackberry.com> Fri, 22 March 2013 05:35 UTC

Return-Path: <prvs=2793a08615=aallen@blackberry.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 EFBD321F9025 for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2013 22:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.316
X-Spam-Level:
X-Spam-Status: No, score=-4.316 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 YzNm1J42f1w7 for <mmusic@ietfa.amsl.com>; Thu, 21 Mar 2013 22:35:43 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4C21F8FE3 for <mmusic@ietf.org>; Thu, 21 Mar 2013 22:35:43 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-bb-514beda85292
Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id 51.BF.09265.8ADEB415; Fri, 22 Mar 2013 00:35:36 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0328.009; Fri, 22 Mar 2013 00:35:35 -0500
From: Andrew Allen <aallen@blackberry.com>
To: Flemming Andreasen <fandreas@cisco.com>, 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" <md3135@att.com>, Stach Thomas <thomas.stach@siemens.com>
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJjm5B4s42L3aokaFCl3Xnh0SyJixCFEQ
Date: Fri, 22 Mar 2013 05:35:35 +0000
Message-ID: <BBF5DDFE515C3946BC18D733B20DAD2338D30F38@XMB104ADS.rim.net>
References: <5148049B.6090205@cisco.com> <D09DAE6B636851459F7575D146EFB54B2109D350@008-AM1MPN1-026.mgdnok.nokia.com> <514B0DE4.3060501@cisco.com>
In-Reply-To: <514B0DE4.3060501@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.67.110.252]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA3VSbUgTYRznuTvP22xwLtMH+9C6iNKczTK5SCWt4MQgzU8GZed2bVfbbd1N afbFIMIMMrWlDk3L9WL0qtELZsNVkhbNskEujWJmSS1JiF6Jbl2BED2ffv+33+//f/gRqLYG TyZ4wcmJAmulcDWmXmdP15+NFBYb7g4vogPdrYCeHtbTbSNvYmlfZwCl/S9fx9LuM2GMvhOR 0aOZcYzed/E2slbFdDf24MxUXStgjn6/EsN8+xTEGa/3K8KMh54gzP7JQZy5PtiAMAcmx2KL VFuqQXY566ws4c3C8txsVhDsTtbJ6UycZMyhNnJm1qorEvlK1ujSreclo5XlbZxI6XhTDpVJ 6RxW1sjZOMGZQ7EOByeYqFy17p+XLbfxgo4TjHYTL5hzqIKSTXqaXrVan0Hl6rcfnGO5cS8U 4wgv2fOgtx+vBl8W1AIVAclMeC1wPEbBiXD4xSW8FqgJLdkFoK9nBFWCHgAHer1YtAsnU6Hv ThMSLSSQNxHY3PAciRZQcgccD7lBLSCIueQe2OeOi6YTSBe8XHsBV/AKODqq8GDkYrjv58Dv vIZkYOfAAFDE3AAe9rl/F1RkCvxwJoxGMZDX+zx0/o9WEgxNtCPK2iT03gqgCp4Hp8I//5yz EIb3H8KU/jTY0TuDK3gZPH3iHaoIx8PBlgnsCEj0zKL1zBrxzBrxzBrpANg5EG+zSIYsg1Ew pou8LV3gnN0gaq28pctvgMg07QckAag5mraJwmJtDFspuWx+AAmUStCUmuSUxsS6qjjRXiZW WDnJDzbI31KPJscZ7bJRBWfZSoPh/wGVpKl7VlCsJc2ymXZxnIMT//IghCqqo05OkGS/cCJb 4bSURS1YJskeTK4GrsT3b0d2tm0ubak317g78yKfkSWbTqlS753te3ASrcpI9Fvyy/PTgsda 2KHdfcMh7dWnwa2BsVcZF3LNP8rzho5Z+7elx21Pe/pxYq+uf1d8xNqR1F58zcPeD57wByWv 73DNevvHrNUp8z1zRUPzQ8Nk1+P8m02NkmpnOGuN4KcwycJmpKKixP4CkbS1x5sDAAA=
Cc: "mmusic@ietf.org" <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: Fri, 22 Mar 2013 05:35:48 -0000

The offline discussion in Quebec agreed that CCAP should not be used to negotiate between different IP addresses or between IPv4 and IPV6.  

CCAP was only to be used to negotiate between IN address type and PSTN address type.

This is all 3GPP needs for CCAP as 3GPP specifications support use of ICE

I am in favor of improving the wording if it is not clear.

Andrew

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: Thursday, March 21, 2013 9:41 AM
To: Jonathan Lennox; mohamed.boucadair@orange.com; Hadriel Kaplan; Atle Monrad; md3135@att.com; Stach Thomas; Andrew Allen
Cc: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Subject: 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
> .
>


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.