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

<mohamed.boucadair@orange.com> Wed, 17 April 2013 11:08 UTC

Return-Path: <mohamed.boucadair@orange.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 6959C21F8D2E for <mmusic@ietfa.amsl.com>; Wed, 17 Apr 2013 04:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.614
X-Spam-Level:
X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, UNPARSEABLE_RELAY=0.001]
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 gtJpNgbSwz8m for <mmusic@ietfa.amsl.com>; Wed, 17 Apr 2013 04:08:31 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA0B21F8D29 for <mmusic@ietf.org>; Wed, 17 Apr 2013 04:08:30 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 07DAF2DC389; Wed, 17 Apr 2013 13:08:29 +0200 (CEST)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B08AB23805C; Wed, 17 Apr 2013 13:08:25 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 17 Apr 2013 13:08:25 +0200
From: <mohamed.boucadair@orange.com>
To: Flemming Andreasen <fandreas@cisco.com>
Date: Wed, 17 Apr 2013 13:08:24 +0200
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: Ac4332TSMK37vz3wTEi9XIobpQdqaQDcJMYA
Message-ID: <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr>
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>
In-Reply-To: <5168A94B.20608@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421
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 11:08:32 -0000

Hi Felmming,

Because it does not allow to indicate an alternate port number. This makes it a no working solution for various scenarios.

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.

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
>> .
>>