[MMUSIC] resurecting the CCAP attribute

[Andrew Allen <[e-mail]>]

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



> -----Original Message-----

> From: Simo.Veikkolainen at nokia.com [mailto:Simo.Veikkolainen at nokia.com]

> Sent: Monday, May 10, 2010 5:45 AM

> To: mmusic at 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

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