Re: [MMUSIC] resurecting the CCAP attribute

[Andrew Allen <[e-mail]>]

Gonzalo

Adding Simo and Miguel

The example and functionality you show for CCAP is what we need for 3GPP. I can't knowledgably comment on altc but your altc description is also my understanding.

Andrew

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Wednesday, August 03, 2011 3:08 AM
> To: Hadriel Kaplan
> Cc: Andrew Allen; [e-mail]
> Subject: Re: [MMUSIC] resurecting the CCAP attribute
> 
> Hi Hadriel,
> 
> a quick question on these two drafts. RFC 4566 defines the format of the
> c line as follows:
> 
> c=<nettype> <addrtype> <connection-address>
> 
> Per the emails below, the function of the ccap attribute would be to
> choose between different nettypes while the purpose of the altc
> attribute would be to choose between different addrtypes, right?
> 
> That is, you would use ccap to choose between the following
> configurations:
> 
> c=IN IP4 example.com
> c=PSTN E164 [phone]
> 
> While you will use altc to choose between:
> 
> c=IN IP4 example.com
> c=IN IP6 example.com
> 
> Is this the intention?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> On 27/07/2011 8:33 PM, 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 at vidyo.com <http://vidyo.com>
> >>
> >> > -----Original Message-----
> >> > From: Simo.Veikkolainen at nokia.com <http://nokia.com>
> [mailto:Simo.Veikkolainen at nokia.com <http://nokia.com>]
> >> > Sent: Monday, May 10, 2010 5:45 AM
> >> > To: mmusic at ietf.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 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 at ietf.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>
> >


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