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

Flemming Andreasen <fandreas@cisco.com> Sat, 13 April 2013 00:39 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 AD3C821F8DD4 for <mmusic@ietfa.amsl.com>; Fri, 12 Apr 2013 17:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level:
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 3OcqFNAgJLsO for <mmusic@ietfa.amsl.com>; Fri, 12 Apr 2013 17:39:42 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0354621F8DD1 for <mmusic@ietf.org>; Fri, 12 Apr 2013 17:39:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14158; q=dns/txt; s=iport; t=1365813582; x=1367023182; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7wH8H1ZXm2hzBQr1D5MhDtryE7WneH1ie/Ld0MCvn00=; b=JVyRBZfJJuSc7F/zxA+GADfliugLz+VQiK+7bAe4m7v4WYegY9u+PKMy hf/LZR48mxNFpHrdg1eyGD7+7urDa0ETE5cH4YZZyfjfqZjnkm4AqzDmo KlqUswdcEVMP+DnvFtGyJj6ouH04uc+NWyBk2lp0zF/2MrKFNGZAQdRyH 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAMGoaFGtJV2b/2dsb2JhbABQgwY2wWSBDRZ0gh8BAQEDAQEBAS8BBTQCCAMFBwQLEQQBAQEJGgQHDwIWHwkIEwEFAgEBBRKHcwYMvEmNXwaBJwsHBoM7A5cCkRGBVYFSIIEuCRc
X-IronPort-AV: E=Sophos;i="4.87,466,1363132800"; d="scan'208";a="198368217"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 13 Apr 2013 00:39:41 +0000
Received: from rtp-fandreas-8718.cisco.com (rtp-fandreas-8718.cisco.com [10.117.7.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3D0ddCs005761; Sat, 13 Apr 2013 00:39:40 GMT
Message-ID: <5168A94B.20608@cisco.com>
Date: Fri, 12 Apr 2013 20:39:39 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <BBF5DDFE515C3946BC18D733B20DAD2338D31D67@XMB104ADS.rim.net> <514FA8F7.7060203@cisco.com> <D09DAE6B636851459F7575D146EFB54B210ADF26@008-AM1MPN1-025.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "jonathan@vidyo.com" <jonathan@vidyo.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "christer.holmberg@ericsson.com" <christer.holmberg@ericsson.com>
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: Sat, 13 Apr 2013 00:39:44 -0000

On 4/12/13 11:39 AM, mohamed.boucadair@orange.com wrote:
> Hi Simo,
>
> I'm in favor of restricting the alternative address to PSTN.
Can you elaborate on why ?

We have defined a generic connection data capability as part of a 
general capability negotiation framework. What's the point of that if 
the only value it can convey is PSTN ?

Thanks

-- Flemming


> This is coherent whit your first bullet below.
>
> If you share the text changes you are proposing, this would be more easier to review.
>
> Thanks for taking care of this issue.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part de
>> Simo.Veikkolainen@nokia.com
>> Envoyé : lundi 8 avril 2013 08:35
>> À : fandreas@cisco.com; aallen@blackberry.com; HKaplan@acmepacket.com
>> Cc : jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com
>> Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses
>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>
>> Recapping the discussion so far:
>>
>>
>> - ICE is the way to negotiate between different IP addresses. There seems
>> to be no disagreement here.
>>
>> - since no alternative port number can be expressed, in practice the IN
>> address needs to go to the actual configuration (address in the c= line and
>> port number in the m= line), and the alternative PSTN address in the
>> potential configurations. Also here, there seems to be no disagreement.
>>
>> - then, whether the "ccap" attribute should be limited to carry only PSTN
>> addresses, or also other types. I'm with Flemming on this one; SDP capneg
>> framework is already fragmented enough, and limiting the connection address
>> capability to PSTN addresses only would again be targeted for a single use
>> case only, whereas we should strive for general solutions.
>>
>> Simo
>>
>>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
>> ext Flemming Andreasen
>> Sent: 25. maaliskuuta 2013 3:32
>> To: Andrew Allen
>> Cc: jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com
>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses
>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>
>>
>> On 3/24/13 1:33 PM, Andrew Allen wrote:
>>> There is also nothing that prevents people from defining their own
>> proprietary attributes to do such a thing but that is not part of an IETF
>> standard and is not approved usage.
>> Agreed.
>>
>>> If we really feel the need to discourage further such usage I suppose we
>> could add some text stating that if CCAP s received containing an IN net
>> type and an IN net type is present in the corresponding Connection
>> Attribute then the CCAP attribute MUST be ignored.
>> I think that gets complicated quickly for a questionable gain. I'd
>> prefer the "MUST NOT" described below with an explanation as to why it's
>> there; as you note, ultimately people either decide to be spec compliant
>> or not.
>>
>> -- Flemming
>>> That way compliant implementations would not perfom the discouraged
>> behavior.
>>> Andrew
>>>
>>> ----- Original Message -----
>>> From: Flemming Andreasen [mailto:fandreas@cisco.com]
>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time
>>> To: Christer Holmberg <christer.holmberg@ericsson.com>
>>> Cc: Jonathan Lennox <jonathan@vidyo.com>om>; mmusic@ietf.org
>> <mmusic@ietf.org>
>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-
>> addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>
>>> On 3/23/13 5:24 AM, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> In general I agree that having multiple ways of doing the same thing is
>> not a good thing, and I don't have any strong feelings regarding the ccap
>> usage.
>>>> But, no matter what we say, what would actually prevent people from
>> using ccap, in the same way they are using ANAT and altc? :)
>>> There's no port signaling capability with ccap, but other than that, the
>>> only thing that prevents people from using this to signal alternative
>>> IP-addresses is the existence of a "MUST NOT" in the spec.
>>>
>>> -- Flemming
>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>> ________________________________________
>>>> From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of
>> Jonathan Lennox [jonathan@vidyo.com]
>>>> Sent: Friday, 22 March 2013 10:00 PM
>>>> To: Flemming Andreasen
>>>> Cc: mmusic@ietf.org
>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and     IP-
>> addresses    (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>> Currently, the deployed SIP world has three mechanisms to allow some
>> flavor of negotiation among multiple IP addresses: ICE, altc (despite the
>> general disapproval of the working group), and ANAT (despite its
>> deprecation).
>>>> I think that adding ccap as a fourth member of this set would be a
>> terrible idea; and as far as I can tell, no one wants to do that.  So we
>> need to make it clear that that it MUST NOT be used for that purpose.
>>>> In the formulation below, I think I'd say that a given media description
>> MUST NOT indicate more than one address with an IN network type, across all
>> its configurations (actual and potential).
>>>> Obviously, different media descriptions (m= line blocks) can have
>> different addresses.
>>>> In practice, given the port number issue that started this thread, I
>> suspect this means that the SDP offer will need to put the IN address in
>> the actual configuration (in the c= line), and the PSTN address(es) will be
>> in the potential configurations.
>>>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote:
>>>>
>>>>> Still waiting for more comments on this, especially from the people
>> that
>>>>> were very vocal in their complaints previously: Now is the time to
>> speak up.
>>>>> Regardless, a few comments on the below:
>>>>> 1) It allows the use of "ccap" to be used to indicate one or more "IP4"
>>>>> addresses in a given SDP.
>>>>> 2) It allows the use of "ccap" to be used to indicate one or more "IP6"
>>>>> addresses in a given SDP.
>>>>>
>>>>> Nit-picking a bit on the actual text, which I think is important:
>>>>> The "ccap" attribute is not what is being to select between different
>>>>> IP-addresses; the use of a "ccap" attribute in a potential
>> configuration
>>>>> ("pcfg") is what is being used for this. Is the restriction that we
>> want
>>>>> here:
>>>>> a) A potential configuration MUST NOT reference more than one "ccap"
>>>>> attribute with a network type of "IN" ?
>>>>> b) All potential configurations for a particular media description MUST
>>>>> NOT reference more than one "ccap" attribute with a network type of
>> "IN" ?
>>>>> c) Something else ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Flemming
>>>>>
>>>>>
>>>>>
>>>>> On 3/22/13 1:35 AM, Andrew Allen wrote:
>>>>>> I am OK with either of these proposals
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> Behalf Of Simo.Veikkolainen@nokia.com
>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM
>>>>>> To: fandreas@cisco.com; mmusic@ietf.org
>>>>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-
>> addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>>>> 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
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>> .
>>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> mmusic@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>> --
>>>> Jonathan Lennox
>>>> jonathan@vidyo.com
>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> .
>>>>
>>> _______________________________________________
>>> 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.
>>> .
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> .
>