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

[<[e-mail]>]

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