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

Flemming Andreasen <fandreas@cisco.com> Wed, 17 April 2013 14:32 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 3355021F8615 for <mmusic@ietfa.amsl.com>; Wed, 17 Apr 2013 07:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[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 tRJMEKqOsNYj for <mmusic@ietfa.amsl.com>; Wed, 17 Apr 2013 07:32:53 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D96EB21F8614 for <mmusic@ietf.org>; Wed, 17 Apr 2013 07:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16280; q=dns/txt; s=iport; t=1366209173; x=1367418773; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lCMajeV5SiKN+2kXejD5Sq+AMmC5ouicoNYCEzapNEs=; b=XFJneh8kgBqH4rzwCK11btDLfgKrl+UPD1jkInD+AIt/EbgfhGtq4E6n n5N846gaEipbG5u4N1z2a/WU8Wcim36acExJDuGZfhu1DaUh2/9Cb/+a+ 7IieTRMjCPYZac7sLyv9IkdhA3zWgENOMH9TJNK8LeGz63hzMhZzPIY3R E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAFixblGrRDoG/2dsb2JhbABQgwY2wQyBAxZ0gh8BAQEDAQEBAS8BBTQCCAIBBQcECxEEAQEBCRYEBAcJAwIBAgEVHwkIEwEFAgEBBRKHcwUNvUuNYgaBJwsHBoNAA5cGkRSBVYFSIIEuCRc
X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208";a="75798384"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 17 Apr 2013 14:32:53 +0000
Received: from Flemmings-MacBook-Pro.local (che-vpn-cluster-2-15.cisco.com [10.86.242.15]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3HEWhcj018511; Wed, 17 Apr 2013 14:32:44 GMT
Message-ID: <516EB28A.1050003@cisco.com>
Date: Wed, 17 Apr 2013 10:32:42 -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> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EC66217CC@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: Wed, 17 Apr 2013 14:32:55 -0000

On 4/17/13 7:08 AM, mohamed.boucadair@orange.com wrote:
> Hi Felmming,
>
> Because it does not allow to indicate an alternate port number.
Correct - a connection address does not provide a port number; a 
different capability would be needed for that.
> This makes it a no working solution for various scenarios.
No - it simply means that you would need to define another capability to 
convey port numbers if you wanted such a solution (however we have ICE 
as the complete solution for that and the WG has not indicated a desire 
to change that).

> The text which triggered this discussion was confusing. I hope the updated version will be much more clear and reflect what have been discussion so far in this thread.
I have asked Simo to update the draft.

Thanks

-- Flemming


> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Flemming Andreasen [mailto:fandreas@cisco.com]
>> Envoyé : samedi 13 avril 2013 02:40
>> À : BOUCADAIR Mohamed OLNC/OLN
>> Cc : Simo.Veikkolainen@nokia.com; aallen@blackberry.com;
>> HKaplan@acmepacket.com; 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)
>>
>>
>> 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>; 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
>>> .
>>>
> .
>