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

[<[e-mail]>]

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:[e-mail]]
>Envoyé : samedi 13 avril 2013 02:40
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [e-mail]; [e-mail];
>[e-mail]; [e-mail]; [e-mail];
>[e-mail]
>Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses
>(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
>
>On 4/12/13 11:39 AM, [e-mail] 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 : [e-mail] [mailto:[e-mail]] De la part
>de
>>> [e-mail]
>>> Envoyé : lundi 8 avril 2013 08:35
>>> À : [e-mail]; [e-mail]; [e-mail]
>>> Cc : [e-mail]; [e-mail]; [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On Behalf
>Of
>>> ext Flemming Andreasen
>>> Sent: 25. maaliskuuta 2013 3:32
>>> To: Andrew Allen
>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>> 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:[e-mail]]
>>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time
>>>> To: Christer Holmberg <[e-mail]>
>>>> Cc: Jonathan Lennox <[e-mail]>; [e-mail]
>>> <[e-mail]>
>>>> 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: [e-mail] [[e-mail]] on behalf of
>>> Jonathan Lennox [[e-mail]]
>>>>> Sent: Friday, 22 March 2013 10:00 PM
>>>>> To: Flemming Andreasen
>>>>> Cc: [e-mail]
>>>>> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of [e-mail]
>>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM
>>>>>>> To: [e-mail]; [e-mail]
>>>>>>> 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: [e-mail] [mailto:[e-mail]] 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing list
>>>>>>> [e-mail]
>>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>> --
>>>>> Jonathan Lennox
>>>>> [e-mail]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>> .
>>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>>