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

[<[e-mail]>]

Hi Simo,

I'm in favor of restricting the alternative address to PSTN. 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