[MMUSIC] What to do with the ccap attribute?

<Simo.Veikkolainen@nokia.com> Mon, 10 May 2010 09:46 UTC

Return-Path: <Simo.Veikkolainen@nokia.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BA63A67A2 for <mmusic@core3.amsl.com>; Mon, 10 May 2010 02:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level:
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlpfrzviNIC8 for <mmusic@core3.amsl.com>; Mon, 10 May 2010 02:46:05 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 65BEA3A62C1 for <mmusic@ietf.org>; Mon, 10 May 2010 02:46:05 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4A9iNDu019178 for <mmusic@ietf.org>; Mon, 10 May 2010 04:45:53 -0500
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 12:45:10 +0300
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 12:45:06 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 12:44:59 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 10 May 2010 11:44:45 +0200
From: Simo.Veikkolainen@nokia.com
To: mmusic@ietf.org
Date: Mon, 10 May 2010 11:44:42 +0200
Thread-Topic: What to do with the ccap attribute?
Thread-Index: AcrwJWqZpvLJ586JTjK5XQiTSB6kSA==
Message-ID: <B23B311878A0B4438F5F09F47E01AAE050870CAD88@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {76285732-B3F4-4158-83D2-703C16CC175C}
x-cr-hashedpuzzle: BIyB B7sh CHOn Cvmm C0Wn Diag DsJh D771 Edy/ FNnL Hfbf HlXM IE9g JPbY JV5U J6qM; 1; bQBtAHUAcwBpAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {76285732-B3F4-4158-83D2-703C16CC175C}; cwBpAG0AbwAuAHYAZQBpAGsAawBvAGwAYQBpAG4AZQBuAEAAbgBvAGsAaQBhAC4AYwBvAG0A; Mon, 10 May 2010 09:44:42 GMT; VwBoAGEAdAAgAHQAbwAgAGQAbwAgAHcAaQB0AGgAIAB0AGgAZQAgAGMAYwBhAHAAIABhAHQAdAByAGkAYgB1AHQAZQA/AA==
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 10 May 2010 09:44:59.0842 (UTC) FILETIME=[74DA9A20:01CAF025]
X-Nokia-AV: Clean
Subject: [MMUSIC] What to do with the ccap attribute?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 10 May 2010 09:46:06 -0000

Now that the discussion on ICE and v6 transition has quieted down, I would like to ask for the list's opinion on how to proceed with the ccap attribute defined in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-misc-cap

Note that this draft will be re-submitted as an individual document according to the WG decision in IETF#77. Nevertheless it contains the most up-to-date text, hence the reference.

As a short reminder, the misc-cap document defines capability attributes for "i=", "b"= and "c=" lines (icap, bcap and ccap, respectively). The ccap capability attribute is used to indicate alternative connection addresses. Our use case for this has been the ability to indicate alternative IP and PSTN addresses; a feature which is needed in some 3GPP scenarios.

As ccap is currently specified, it includes also the port number in addition to the contents of a "c=" line (<nettype>, <addrtype> and the <connection-address>). The port number is needed in order to indicate a port number for internet addresses, the PSTN addresses don't have a similar concept.

Now, as a side effect, the ccap attribute could also be used to circumvent ICE, if one used IP4 and IP6 addrtypes as alternatives.

In order to move forward with the misc-cap document I'm now asking how do folks feel we should handle this issue. Possible alternatives are at least:

1. Leave the current text as is (see [1]).

2. Make a more strict statement that ccap SHOULD NOT be used for v4/v6 address pairs.

3. Come up with altogether different way of indicating alternative connection addresses that fulfill our use case (PSTN/IP addresses). 

Regards,
Simo

[1] The text from Section 3.1.2 from  http://tools.ietf.org/html/draft-ietf-mmusic-sdp-misc-cap currently says 
"
   The connection information capability can be used to negotiate the
   use of IPv4 or IPv6 addresses without resort to Interactive
   Connectivity Establishment(ICE) [I-D.ietf-mmusic-ice].  Note,
   however, that ICE provides for real-time reachability testing of
   multiple addresses, whereas use of the connection capability forces
   an early choice of connection address.

   [I-D.boucadair-mmusic-altc] describes a simple method of specifying
   alternative network addresses when the transport protocol (<proto>)
   is the same.
"