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

From: <[email-masked]>
Date: Mon, 10 May 2010 11:44:42 +0200

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

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 10 May 2010 04:25:12 -0600

Simo,

   See my thoughts inline.  Pending more wg feedback, we can confirm the scope of a new work item.

Jean-François

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, May 10, 2010 3:45 AM
> To: [email-masked]
> 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.

There is consensus for the i= and b= line.
While Jonathan Lennox brought up discussions at the meeting about putting these params back into media capneg, we had decided to take b= out some time ago.  My preference is therefore to have misc-cap still continue with i= and b= as part of the cap neg framework.

For c=, based on the WG meeting discussions and list, it seems we do have two paths:
	- add ccap per misc-cap following the SDP capneg framework
	- extend ICE candidates to also indicate the nettype 

I'd like to hear from folks about extending ICE (pros&cons).
 
> 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:
> 
I would propose this:
	- issue your new individual ID draft with the i= and b=
	- WG chairs will get a wg formally approved for misc-cap

> 3. Come up with altogether different way of indicating alternative
> connection addresses that fulfill our use case (PSTN/IP addresses).

Extending ICE is in that camp.

> 
> Regards,
> Simo
> 
> [1] The text from Section 3.1.2 from
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-misc-cap currently
> says
> "
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 10 May 2010 11:24:36 -0400

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
[email-masked]

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 5:45 AM
> To: [email-masked]
> 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
> 
> according to the WG decision in IETF#77. Nevertheless it contains the
> most up-to-date text, hence the reference.
> 
> 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.
> 
> 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.
> 
> 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:
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 May 2010 12:43:37 +0200

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.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: 10 May 2010 16:25
> To: [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] What to do with the ccap attribute?
> 
> > ccap attribute defined in 
> http://tools.ietf.org/html/draft-ietf-mmusic-
> > sdp-misc-cap
> > 
> > 2. Make a more strict statement that ccap SHOULD NOT be 
> used for v4/v6
> > address pairs.
> > 
> http://tools.ietf.org/html/draft-
> > ietf-mmusic-sdp-misc-cap currently says
> > "

---

From: <[email-masked]>
Date: Tue, 18 May 2010 20:13:33 +0200

>From: ext Elwell, John [mailto:[email-masked]]
>Sent: 11 May, 2010 13:44
>To: Jonathan Lennox; Veikkolainen Simo (Nokia-D/Helsinki);
>[email-masked]
>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