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

Flemming Andreasen <fandreas@cisco.com> Tue, 19 March 2013 06:24 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 38AF721F8A52 for <mmusic@ietfa.amsl.com>; Mon, 18 Mar 2013 23:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.219
X-Spam-Level:
X-Spam-Status: No, score=0.219 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_42=0.6]
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 OfGhmkAg6THC for <mmusic@ietfa.amsl.com>; Mon, 18 Mar 2013 23:24:26 -0700 (PDT)
Received: from p2322.superclick.com (50-200-68-226-static.hfc.comcastbusiness.net [50.200.68.226]) by ietfa.amsl.com (Postfix) with ESMTP id B495C21F8A18 for <mmusic@ietf.org>; Mon, 18 Mar 2013 23:24:26 -0700 (PDT)
Received: from Flemmings-MacBook-Pro.local ([172.20.6.116]) by p2322.superclick.com (8.13.1/8.13.1) with ESMTP id r2J6OQLs006995 for <mmusic@ietf.org>; Mon, 18 Mar 2013 23:24:26 -0700
Message-ID: <5148049B.6090205@cisco.com>
Date: Tue, 19 Mar 2013 02:24:27 -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: mmusic <mmusic@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [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: Tue, 19 Mar 2013 06:24:27 -0000

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