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

[<[e-mail]>]

Hi Fleming,

Please see inline.

Cheers,
Med


>-----Message d'origine-----
>De : Flemming Andreasen [mailto:[e-mail]]
>Envoyé : mercredi 17 avril 2013 16:33
>À : 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/17/13 7:08 AM, [e-mail] 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:[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
>>>> .
>>>>
>> .
>>