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

Can we get some more comments from people on this please. In particular, 
I would like to hear if people are against "ccap" being able to convey 
an IP-address or not (if not, we can then debate the details of the 
restrictions around that separately) ?

Thanks

-- Flemming

On 3/20/13 5:56 AM, Simo.Veikkolainen@nokia.com wrote:
> 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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>