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

["Stach, Thomas" <[e-mail]>]

I don't object against having an IP adress in the ccap attribute and a PSTN number in the c-line, 
if that indicates a preference for the PSTN number.
But I don't like to have an IPv4 and/or IPv6 adress in both ccap and c-line
as this would introduce a second method for IPv4/v6 negotiation in addition to ICE.

My objection on this is based on what I remember from the IETF-68 discussion 
on usage of ICE vs. ANAT vs. SDP Capability-Negotiation for IPv4/IPv6 negotiation.
Cap-Neg did not address negotiations of IP address families at that time, 
but could have been extended accordingly.

Although the consensus at that meeting was very rough, ICE was finally selected as the 
method of choice since it also allows to test which address family would work based on connectivity checks. 
This also led to the deprecation of ANAT, as people didn't want to have two methods for the 
IPv4/IPv6 negotiation (and due to ANAT's other drawbacks).
A Cap-Neg extension via ccap would also miss a function for connectivity checking (common with ANAT).
I think this ability was seen as the major advantage of ICE and an Cap-Neg extension 
was no longer persued until the need for negotiation of a PSTN vs. IP adress came up.
We should stick to the decision from IETF-68 to only use ICE for IPv4/v6 negotiation.


Regards
Thomas  

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]] 
> Im Auftrag von Flemming Andreasen
> Gesendet: Donnerstag, 21. März 2013 14:41
> An: Jonathan Lennox; [e-mail]; Hadriel 
> Kaplan; Atle Monrad; [e-mail]; Stach Thomas; Andrew Allen
> Cc: [e-mail]
> Betreff: 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, [e-mail] 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: [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
>