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

[Flemming Andreasen <[e-mail]>]

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