Re: [MMUSIC] resurecting the CCAP attribute

["Miguel A. Garcia" <[e-mail]>]

As an individual....

Hadriel,

As far as I understand, the requirement from 3GPP is to be able to offer 
an audio stream of circuit-switched or over regular IP. As such, the 
authors of the misc-cap draft do not have a strong requirement for 
letting a mixture of different network types (3GPP requirement) or the 
same (your requirement, the altc draft).

I would say that we need to clarify whether we can come up with a text 
that indicates what is the intended usage and the allowed usage.

/Miguel



On 27/07/2011 19:33, Hadriel Kaplan wrote:
> So what happens if a UAC puts both an IPv4 and IPv6 addresses as ccap -
> is the UAS mandated to ignore it, or reject the request, or may it use it?
>
> I ask because we've taken the altc draft outside of the IETF as an
> independent submission to the RFC editor, using the altc syntax. If it
> would be better, we could instead change our independent submission to
> say "implement the sdp-icap-bcap using CCAP but ignore the MUST NOT …". I
> don't know if that would be better or worse, so just asking.
>
> -hadriel
>
>
> On Jul 27, 2011, at 11:17 AM, Andrew Allen wrote:
>
>> Yesterday several MMUSIC participants including Jonathan Lennox and
>> Miguel Garcia got together to discuss what to do regarding the CCAP
>> attribute which is currently used in 3GPP specifications but was
>> removed from the misc-cap draft (which then became the sdp-icap-bcap
>> draft without the CCAP attribute). The CCAP attribute was removed after
>> earlier comments on the list from Jonathan regarding the possibility
>> that CCAP might be used as an alternative to ICE for negotiating IP
>> addresses for the C line (see email thread below). 3GPP currently
>> utilize the CCAP attribute with SDP-cap-neg for negotiation of use of a
>> circuit switched call for the audio media as an alternative to an audio
>> RTP stream over packet switched access. CCAP is used to offer the PSTN
>> net type and E.164 number used to set up that call.
>> After a thorough discussion the conclusion of those involved in the
>> discussion (including Jonathan) was that the best way forward given the
>> constraints of the 3GPP architecture is to resurrect the CCAP attribute
>> but with some wording that places constraints on its usage so that it
>> isn’t used to negotiate alternative addresses for a network type for
>> which ICE can be used to negotiate addresses. This means that CCAP
>> could be used to negotiate the possibility to use PSTN net type as an
>> alternative to the IN net type but that using alternative IP address
>> candidates within the IN net type would need to be negotiated using ICE
>> not using CCAP.
>> Are the any concerns from other MMUSIC participants if CCAP is
>> resurrected (probably in an again renamed version of the sdp-icap-bcap
>> draft that would again include CCAP) with appropriate text to address
>> the ICE issue along the lines of above?
>> Andrew
>>
>>   * /To/: "Simo.Veikkolainen at nokia.com
>>     <mailto:[e-mail]>" <Simo.Veikkolainen at
>>     nokia.com <mailto:[e-mail]>>, "mmusic at
>>     ietf.org <mailto:[e-mail]>" <mmusic at ietf.org
>>     <mailto:[e-mail]>>
>>   * /Subject/: Re: [MMUSIC] What to do with the ccap attribute?
>>   * /From/: Jonathan Lennox <jonathan at vidyo.com
>>     <mailto:[e-mail]>>
>>   * /Date/: Mon, 10 May 2010 11:24:36 -0400
>>   * /Accept-language/: en-US
>>   * /Acceptlanguage/: en-US
>>   * /Delivered-to/:mmusic at core3.amsl.com <mailto:[e-mail]>
>>   * /In-reply-to/: <B23B311878A0B4438F5F09F47E01AAE050870CAD88 at
>>     NOK-EUMSG-01.mgdnok.nokia.com
>>     <mailto:[e-mail]>>
>>   * /List-archive/: <http://www.ietf.org/mail-archive/web/mmusic>
>>   * /List-help/: <mailto:[e-mail]?subject=help>
>>   * /List-id/: Multiparty Multimedia Session Control Working Group
>>     <mmusic.ietf.org <http://mmusic.ietf.org>>
>>   * /List-post/: <mailto:[e-mail]>
>>   * /List-subscribe/: <https://www.ietf.org/mailman/listinfo/mmusic>,
>>     <mailto:[e-mail]?subject=subscribe>
>>   * /List-unsubscribe/: <https://www.ietf.org/mailman/listinfo/mmusic>,
>>     <mailto:[e-mail]?subject=unsubscribe>
>>   * /References/: <B23B311878A0B4438F5F09F47E01AAE050870CAD88 at
>>     NOK-EUMSG-01.mgdnok.nokia.com
>>     <mailto:[e-mail]>>
>>   * /Thread-index/: AcrwJWqZpvLJ586JTjK5XQiTSB6kSAALoU1w
>>   * /Thread-topic/: 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 atvidyo.com  <http://vidyo.com>
>>
>> >  -----Original Message-----
>> >  From: Simo.Veikkolainen atnokia.com  <http://nokia.com>  [mailto:Simo.Veikkolainen  atnokia.com  <http://nokia.com>]
>> >  Sent: Monday, May 10, 2010 5:45 AM
>> >  To: mmusic atietf.org  <http://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 inhttp://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 atietf.org  <http://ietf.org>
>> >  https://www.ietf.org/mailman/listinfo/mmusic
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other
>> than the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and
>> delete this information from your system. Use, dissemination,
>> distribution, or reproduction of this transmission by unintended
>> recipients is not authorized and may be unlawful.<ATT00001..c>
>

-- 
Miguel A. Garcia
[phone]
Ericsson Spain