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

<Simo.Veikkolainen@nokia.com> Wed, 20 March 2013 09:57 UTC

Return-Path: <Simo.Veikkolainen@nokia.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 1056C21F8AD5 for <mmusic@ietfa.amsl.com>; Wed, 20 Mar 2013 02:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.924
X-Spam-Level:
X-Spam-Status: No, score=-4.924 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 1PgBanuwXGTT for <mmusic@ietfa.amsl.com>; Wed, 20 Mar 2013 02:57:02 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2C48221F8AD4 for <mmusic@ietf.org>; Wed, 20 Mar 2013 02:57:01 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2K9uwK1008812; Wed, 20 Mar 2013 11:57:00 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Mar 2013 11:56:58 +0200
Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.100]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.02.0328.011; Wed, 20 Mar 2013 09:56:58 +0000
From: <Simo.Veikkolainen@nokia.com>
To: <fandreas@cisco.com>, <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJGpsaYWyC2xxJUaG2b4cQbjFxZiuU3ug
Date: Wed, 20 Mar 2013 09:56:57 +0000
Message-ID: <D09DAE6B636851459F7575D146EFB54B2109D350@008-AM1MPN1-026.mgdnok.nokia.com>
References: <5148049B.6090205@cisco.com>
In-Reply-To: <5148049B.6090205@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-version: 3.5.9.3
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ivm4xbzrYVxIZLYcVE8MkpBpYSmhkAuQqQMGR/NKzjcJvrcT2VmD4iRqNDtz3NKc/LOn9Ls0KOL+40Vh61iFNHGfzpjcTACdIULNp3RnsSHdlPCE/lblMg9cG3A9PxJtPVAo/QrzI/wV/xYZvKGnpHkj9utSV2jnifPRoPWbfL5o5zQp9XCh/0lEeKL/oZHyHOAtRH+rahuoJKWQ7WayRAPYDuYdWnRvmXKYFJhrx2brlh3yPHveRVrRIJtsUik1yjU/ym0/gsPWw0IDYlR+Xlc8X4x8SSYaTfkCZ53TklZhR4NSUEgwXjYwetfjqEw7aw==
x-originating-ip: [62.78.254.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Mar 2013 09:56:58.0927 (UTC) FILETIME=[432303F0:01CE2551]
X-Nokia-AV: Clean
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: Wed, 20 Mar 2013 09:57:03 -0000

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