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

Simo,

   See my thoughts inline.  Pending more wg feedback, we can confirm the scope of a new work item.

Jean-François

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Simo.Veikkolainen@nokia.com
> Sent: Monday, May 10, 2010 3: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.

There is consensus for the i= and b= line.
While Jonathan Lennox brought up discussions at the meeting about putting these params back into media capneg, we had decided to take b= out some time ago.  My preference is therefore to have misc-cap still continue with i= and b= as part of the cap neg framework.

For c=, based on the WG meeting discussions and list, it seems we do have two paths:
	- add ccap per misc-cap following the SDP capneg framework
	- extend ICE candidates to also indicate the nettype 

I'd like to hear from folks about extending ICE (pros&cons).

> 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]).
I would propose this:
	- issue your new individual ID draft with the i= and b=
	- WG chairs will get a wg formally approved for misc-cap

> 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).

Extending ICE is in that camp.

> 
> 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