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

>-----Original Message-----
>From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]
>Sent: 11 May, 2010 13:44
>To: Jonathan Lennox; Veikkolainen Simo (Nokia-D/Helsinki);
>mmusic@ietf.org
>Subject: RE: 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.

My main concern with the common solution is that it would tie the circuit-switched use case together with another use case where there is no WG consensus whether there is any problem to be solved at all.

Building a common syntax for an environment where you know you don't need ICE, but might require alternative v4/v6, *and* require also a capability for alternative circuit-switched connections doesn't sound like a strong use case.

Simo

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