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

<mohamed.boucadair@orange.com> Thu, 18 April 2013 09:27 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 83A2F21F8E9E for <mmusic@ietfa.amsl.com>; Thu, 18 Apr 2013 02:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.636
X-Spam-Level:
X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=0.012, 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 GLA-zVbB5SWs for <mmusic@ietfa.amsl.com>; Thu, 18 Apr 2013 02:27:56 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B8B8421F8E8E for <mmusic@ietf.org>; Thu, 18 Apr 2013 02:27:55 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 26EE522C3A5; Thu, 18 Apr 2013 11:27:55 +0200 (CEST)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 02D8A35C065; Thu, 18 Apr 2013 11:27:55 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 18 Apr 2013 11:27:54 +0200
From: <mohamed.boucadair@orange.com>
To: Flemming Andreasen <fandreas@cisco.com>
Date: Thu, 18 Apr 2013 11:27:53 +0200
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: Ac47eHShPmuTxsmGRnCY1BJU1UASmwAhXKmg
Message-ID: <94C682931C08B048B7A8645303FDC9F36EC73F1950@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> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> <516EB28A.1050003@cisco.com>
In-Reply-To: <516EB28A.1050003@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.4.18.90020
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: Thu, 18 Apr 2013 09:27:57 -0000

Hi Fleming,

Please see inline.

Cheers,
Med


>-----Message d'origine-----
>De : Flemming Andreasen [mailto:fandreas@cisco.com]
>Envoyé : mercredi 17 avril 2013 16:33
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Simo.Veikkolainen@nokia.com; aallen@blackberry.com;
>HKaplan@acmepacket.comcom; 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/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).

[Med] Yes, I understood the wg does not want to change and extend the capability to cover more than the PSTN case.

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

[Med] Ok, thanks.

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