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

Flemming Andreasen <fandreas@cisco.com> Mon, 25 March 2013 01:26 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 6D5C121F8E51 for <mmusic@ietfa.amsl.com>; Sun, 24 Mar 2013 18:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.901
X-Spam-Level:
X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, 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 piLWENeK7JyV for <mmusic@ietfa.amsl.com>; Sun, 24 Mar 2013 18:26:45 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 30D5421F8E57 for <mmusic@ietf.org>; Sun, 24 Mar 2013 18:26:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1603; q=dns/txt; s=iport; t=1364174805; x=1365384405; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oJOTsYLPpO5EOE9T7vY38mhHViwxt2MR0HYBg+oMTQg=; b=HC3i2OHYtWWo7cbc11rkfFQcuVf9xLCDk+Qqc0q/MyFgOjASrw4dOydF 2ifCwjgaBIgQRo3M/epDxXjCzRmkRJMAGphIXUPUSzGhnZCBIZlQUsbmI N9ILiTu4yrcrVWZt86McFjptq1+yPb7dLbtlBycLm3O95fgqkuc37ePqE 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFANCmT1GrRDoJ/2dsb2JhbABDxXyBehZ0giQBAQEEOEABEAsOCgkWBAsJAwIBAgFFBg0BBQIBAReHeMFpjxgHg0ADlmeRBIFUgVIg
X-IronPort-AV: E=Sophos;i="4.84,902,1355097600"; d="scan'208";a="76617708"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 25 Mar 2013 01:26:44 +0000
Received: from Flemmings-MacBook-Pro.local ([10.86.253.124]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2P1QhNV006171; Mon, 25 Mar 2013 01:26:44 GMT
Message-ID: <514FA7D3.8040909@cisco.com>
Date: Sun, 24 Mar 2013 21:26:43 -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: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <5148049B.6090205@cisco.com> <D09DAE6B636851459F7575D146EFB54B2109D350@008-AM1MPN1-026.mgdnok.nokia.com> <EE8DA776-7DC3-4002-8366-7095F4DBD456@acmepacket.com>
In-Reply-To: <EE8DA776-7DC3-4002-8366-7095F4DBD456@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Mon, 25 Mar 2013 01:26:46 -0000

On 3/24/13 1:00 PM, Hadriel Kaplan wrote:
> On Mar 20, 2013, at 5:56 AM, Simo.Veikkolainen@nokia.com wrote:
>
>> 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>
> That is not technically possible, in practice.  If a ccap were to contain an IN for an IP Address family, there is no port number indicated anywhere for that IP address.  Therefore it can't be used to indicate an IP Address alternate in practice, since one couldn't use the address alone.
>
> So... either we re-introduce the port number so that a ccap can actually be used to indicate an IP Address, or we make ccap only usable for PSTN and not IN.
These are not the only choices. We strive for defining general 
solutions, and there is no reason why lack of port numbers should lead 
us to define a general connection data capability that cannot contain 
any IP-addresses. The connection data capability by itself will of 
course not be sufficient to allow for negotiation of transport address 
alternatives (intentionally), but that is really a separate (albeit 
related) issue.

-- Flemming

> -hadriel
>
>
> .
>