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