Re: [MMUSIC] What to do with the ccap attribute?

I tend to agree that a common solution makes sense. Of course, in defining an ICE candidate for circuit-switched we would encounter the fact that a pair of such candidates would not be testable using STUN. This would seem to add weight to the argument for having the ability to use ICE candidates without connectivity checking, as proposed in the microlite draft.

John

> -----Original Message-----
> From: mmusic-bounces@ietf.org 
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lennox
> Sent: 10 May 2010 16:25
> To: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
> Subject: Re: [MMUSIC] What to do with the ccap attribute?
> 
> I think it'd be best to unify the requirements of this use case 
> (separate IP and PSTN addresses) with the requirements of the 
> IPv4/IPv6 transition use cases, and come up with a common solution.
> 
> Having two mechanisms (ANAT and ICE) to specify multiple connection 
> addresses is a standard but annoying consequence of a technology 
> transition. Having three (ANAT, ICE, and ALTC) gets unmanageable. 
> Having four (ANAT, ICE, ALTC, and CCAP) is just silly.
> 
> -- 
> Jonathan Lennox
> Vidyo, Inc
> jonathan@vidyo.com
> 
> > -----Original Message-----
> > From: Simo.Veikkolainen@nokia.com 
> [mailto:Simo.Veikkolainen@nokia.com]
> > Sent: Monday, May 10, 2010 5:45 AM
> > To: mmusic@ietf.org
> > Subject: [MMUSIC] What to do with the ccap attribute?
> > 
> > Now that the discussion on ICE and v6 transition has quieted down, I
> > would like to ask for the list's opinion on how to proceed with the
> > ccap attribute defined in 
> http://tools.ietf.org/html/draft-ietf-mmusic-
> > sdp-misc-cap
> > 
> > Note that this draft will be re-submitted as an individual document
> > according to the WG decision in IETF#77. Nevertheless it 
> contains the
> > most up-to-date text, hence the reference.
> > 
> > As a short reminder, the misc-cap document defines capability
> > attributes for "i=", "b"= and "c=" lines (icap, bcap and ccap,
> > respectively). The ccap capability attribute is used to indicate
> > alternative connection addresses. Our use case for this has been the
> > ability to indicate alternative IP and PSTN addresses; a 
> feature which
> > is needed in some 3GPP scenarios.
> > 
> > As ccap is currently specified, it includes also the port number in
> > addition to the contents of a "c=" line (<nettype>, 
> <addrtype> and the
> > <connection-address>). The port number is needed in order 
> to indicate a
> > port number for internet addresses, the PSTN addresses don't have a
> > similar concept.
> > 
> > Now, as a side effect, the ccap attribute could also be used to
> > circumvent ICE, if one used IP4 and IP6 addrtypes as alternatives.
> > 
> > In order to move forward with the misc-cap document I'm now 
> asking how
> > do folks feel we should handle this issue. Possible 
> alternatives are at
> > least:
> > 
> > 1. Leave the current text as is (see [1]).
> > 
> > 2. Make a more strict statement that ccap SHOULD NOT be 
> used for v4/v6
> > address pairs.
> > 
> > 3. Come up with altogether different way of indicating alternative
> > connection addresses that fulfill our use case (PSTN/IP addresses).
> > 
> > Regards,
> > Simo
> > 
> > [1] The text from Section 3.1.2 from  
> http://tools.ietf.org/html/draft-
> > ietf-mmusic-sdp-misc-cap currently says
> > "
> >    The connection information capability can be used to 
> negotiate the
> >    use of IPv4 or IPv6 addresses without resort to Interactive
> >    Connectivity Establishment(ICE) [I-D.ietf-mmusic-ice].  Note,
> >    however, that ICE provides for real-time reachability testing of
> >    multiple addresses, whereas use of the connection 
> capability forces
> >    an early choice of connection address.
> > 
> >    [I-D.boucadair-mmusic-altc] describes a simple method of 
> specifying
> >    alternative network addresses when the transport 
> protocol (<proto>)
> >    is the same.
> > "
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 