Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

From: Flemming Andreasen <[email-masked]>
Date: Tue, 19 Mar 2013 02:24:27 -0400

Greetings

As you may have seen, there has recently been some list discussion on 
the "connection data capability" defined in 
draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in 
http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)

To recap, the connection data capability ("ccap") provides capability 
negotiation capabilities for what amounts to the "c=" line in regular 
SDP, and as such enables negotiation of network type (such as "IN") and 
IP-address information (v4 and v6 addresses). The Standards Track 
mechanism for negotiating and determining alternative IP-address 
information today is ICE, and hence the draft currently includes the 
following wording:
<quote>
The 'ccap' capability attribute is intended to
    be used only when there is no other mechanism available for
    negotiating alternative connection address information, such as when
    the <nettype> is different among the alternative addresses (e.g.
    "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
    situations where an existing mechanism (such as Interactive
    Connectivity Establishment (ICE) [RFC5245]) can be used to select
    between different connection addresses (e.g.  "IP4" and "IP6" or
    different IP addresses within the same IP address family).
</quoted>

The above text has led to some confusion as to exactly when and what 
"ccap" can be used for. More specifically, is it/should it ever be 
allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under 
what circumstances ?

If you have an opinion, please let us know.

A couple of points to keep in mind:
- The current document has been WGLC'ed without comment ~6 months ago.
- 3GPP has a dependency on the document (however I'm not sure if that 
dependency includes the above "IN" feature)
- The connection data capability is defined in a general manner to be 
generally useful in line with the overall capability negotiation 
framework (as opposed to targeted at one specific use case with one 
specific value)
- There are scenarios where ICE cannot be used, even if implemented 
(e.g. ice-mismatch).
- RFC 6849 (media loopback) provides for NAT traversal in the absence of 
ICE support

Thanks

-- Flemming

---

From: Andrew Allen <[email-masked]>
Date: Tue, 19 Mar 2013 12:27:27 +0000

Flemming

CCAP is the essential feature required by 3GPP. It is used by 3GPP to negotiate the use of CS SDP to set up a CS call as an alternative to a packet switched audio stream.

Andrew

----- Original Message -----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Tuesday, March 19, 2013 01:24 AM Central Standard Time
To: mmusic <[email-masked]>
Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)

Greetings

Thanks

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]
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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 19 Mar 2013 14:22:25 +0000

> CCAP is the essential feature required by 3GPP. It is used by 3GPP to negotiate the use of CS SDP to set up a CS call as an alternative to a packet switched audio stream.

Does it also need to be able to go from CS to IP sometime during a call, or once it's chosen to be CS it stays CS?

-hadriel

---

From: <[email-masked]>
Date: Wed, 20 Mar 2013 09:56:57 +0000

I went through the discussion, and my reading is that there is agreement on not allowing ccap to be used for alternative IP address negotiation.

That could be made clear in the text e.g. by modifying the second sentence Flemming quoted to read:

<quote>
    The 'ccap' attribute MUST NOT be used to select
    between different IP connection addresses (e.g. between 
    "IP4" and "IP6" address families or different IP addresses 
     within the same IP address family).
</quote>

The ccap attribute should be able to carry either an IP or PSTN address; that way either a PSTN or an IP bearer could be offered as the highest priority configuration (in the "m=" line).  However, if we want to clarify the intended use of ccap, we could modify the first sentence to read:

<quote>
   The 'ccap' capability attribute is intended for offering
   alternative connection addresses where the <nettype>
   is "IN" or "PSTN", i.e. selecting between an IP based
   bearer or a circuit-switched bearer.
</quote>

Simo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Flemming Andreasen
Sent: 19. maaliskuuta 2013 8:24
To: mmusic
Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

Greetings

As you may have seen, there has recently been some list discussion on the "connection data capability" defined in
draft-ietf-mmusic-sdp-miscellaneous-caps-04 (see e.g. thread in
http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.html)

To recap, the connection data capability ("ccap") provides capability negotiation capabilities for what amounts to the "c=" line in regular SDP, and as such enables negotiation of network type (such as "IN") and IP-address information (v4 and v6 addresses). The Standards Track mechanism for negotiating and determining alternative IP-address information today is ICE, and hence the draft currently includes the following wording:
<quote>

The above text has led to some confusion as to exactly when and what "ccap" can be used for. More specifically, is it/should it ever be allowed to use "ccap" to convey an IP4 or IP6 address, and if so, under what circumstances ?

A couple of points to keep in mind:
- The current document has been WGLC'ed without comment ~6 months ago.
- 3GPP has a dependency on the document (however I'm not sure if that dependency includes the above "IN" feature)
- The connection data capability is defined in a general manner to be generally useful in line with the overall capability negotiation framework (as opposed to targeted at one specific use case with one specific value)
- There are scenarios where ICE cannot be used, even if implemented (e.g. ice-mismatch).
- RFC 6849 (media loopback) provides for NAT traversal in the absence of ICE support

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 21 Mar 2013 09:40:52 -0400

Can we get some more comments from people on this please. In particular, 
I would like to hear if people are against "ccap" being able to convey 
an IP-address or not (if not, we can then debate the details of the 
restrictions around that separately) ?

Thanks

-- Flemming

On 3/20/13 5:56 AM, [email-masked] wrote:
> .

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 21 Mar 2013 16:28:39 +0000

I don't object against having an IP adress in the ccap attribute and a PSTN number in the c-line, 
if that indicates a preference for the PSTN number.
But I don't like to have an IPv4 and/or IPv6 adress in both ccap and c-line
as this would introduce a second method for IPv4/v6 negotiation in addition to ICE.

My objection on this is based on what I remember from the IETF-68 discussion 
on usage of ICE vs. ANAT vs. SDP Capability-Negotiation for IPv4/IPv6 negotiation.
Cap-Neg did not address negotiations of IP address families at that time, 
but could have been extended accordingly.

Although the consensus at that meeting was very rough, ICE was finally selected as the 
method of choice since it also allows to test which address family would work based on connectivity checks. 
This also led to the deprecation of ANAT, as people didn't want to have two methods for the 
IPv4/IPv6 negotiation (and due to ANAT's other drawbacks).
A Cap-Neg extension via ccap would also miss a function for connectivity checking (common with ANAT).
I think this ability was seen as the major advantage of ICE and an Cap-Neg extension 
was no longer persued until the need for negotiation of a PSTN vs. IP adress came up.
We should stick to the decision from IETF-68 to only use ICE for IPv4/v6 negotiation.

Regards
Thomas  

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Flemming Andreasen
> Gesendet: Donnerstag, 21. März 2013 14:41
> An: Jonathan Lennox; [email-masked]; Hadriel 
> Kaplan; Atle Monrad; [email-masked]; Stach Thomas; Andrew Allen
> Cc: [email-masked]
> Betreff: Re: [MMUSIC] Connection Data Capability (ccap) and 
> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
> 
> > I went through the discussion, and my reading is that there 
> is agreement on not allowing ccap to be used for alternative 
> IP address negotiation.
> >
> > The ccap attribute should be able to carry either an IP or 
> PSTN address; that way either a PSTN or an IP bearer could be 
> offered as the highest priority configuration (in the "m=" 
> line).  However, if we want to clarify the intended use of 
> ccap, we could modify the first sentence to read:
> >
> > <quote>
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Flemming Andreasen
> > Subject: [MMUSIC] Connection Data Capability (ccap) and 
> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
> >
> > Greetings
> >
> > As you may have seen, there has recently been some list 
> discussion on the "connection data capability" defined in
> > To recap, the connection data capability ("ccap") provides 
> capability negotiation capabilities for what amounts to the 
> "c=" line in regular SDP, and as such enables negotiation of 
> network type (such as "IN") and IP-address information (v4 
> and v6 addresses). The Standards Track mechanism for 
> negotiating and determining alternative IP-address 
> information today is ICE, and hence the draft currently 
> includes the following wording:
> > <quote>
> > The above text has led to some confusion as to exactly when 
> and what "ccap" can be used for. More specifically, is 
> it/should it ever be allowed to use "ccap" to convey an IP4 
> or IP6 address, and if so, under what circumstances ?
> >
> > - 3GPP has a dependency on the document (however I'm not 
> sure if that dependency includes the above "IN" feature)
> > - The connection data capability is defined in a general 
> manner to be generally useful in line with the overall 
> capability negotiation framework (as opposed to targeted at 
> one specific use case with one specific value)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Mar 2013 04:06:15 +0800

+1

---

From: Andrew Allen <[email-masked]>
Date: Fri, 22 Mar 2013 05:35:35 +0000

The offline discussion in Quebec agreed that CCAP should not be used to negotiate between different IP addresses or between IPv4 and IPV6.  

CCAP was only to be used to negotiate between IN address type and PSTN address type.

This is all 3GPP needs for CCAP as 3GPP specifications support use of ICE

I am in favor of improving the wording if it is not clear.

Andrew

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]] 
Sent: Thursday, March 21, 2013 9:41 AM
To: Jonathan Lennox; [email-masked]; Hadriel Kaplan; Atle Monrad; [email-masked]; Stach Thomas; Andrew Allen
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

Can we get some more comments from people on this please. In particular, I would like to hear if people are against "ccap" being able to convey an IP-address or not (if not, we can then debate the details of the restrictions around that separately) ?

Thanks

-- Flemming

On 3/20/13 5:56 AM, [email-masked] wrote:
> Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses 
> (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
> Greetings
>

---

From: Andrew Allen <[email-masked]>
Date: Fri, 22 Mar 2013 05:35:56 +0000

I am OK with either of these proposals

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 20, 2013 5:57 AM
To: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

<quote>

<quote>

Simo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Flemming Andreasen
Sent: 19. maaliskuuta 2013 8:24
To: mmusic
Subject: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

Greetings

Thanks

-- Flemming

---

From: Andrew Allen <[email-masked]>
Date: Fri, 22 Mar 2013 05:35:58 +0000

CCAP is currently only used by 3GPP to allow the UA to choose between PS and CS for a terminating call at call setup when the UA has the possibility to use either PS or CS for the call.

Mid call Handover PS to CS and CS to PS uses other techniques and does not involve use of CCAP.

Andrew

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, March 19, 2013 10:22 AM
To: Andrew Allen
Cc: [email-masked] (E-mail)
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 22 Mar 2013 14:37:21 -0400

Still waiting for more comments on this, especially from the people that 
were very vocal in their complaints previously: Now is the time to speak up.

Regardless, a few comments on the below:
1) It allows the use of "ccap" to be used to indicate one or more "IP4" 
addresses in a given SDP.
2) It allows the use of "ccap" to be used to indicate one or more "IP6" 
addresses in a given SDP.

Nit-picking a bit on the actual text, which I think is important:
The "ccap" attribute is not what is being to select between different 
IP-addresses; the use of a "ccap" attribute in a potential configuration 
("pcfg") is what is being used for this. Is the restriction that we want 
here:
a) A potential configuration MUST NOT reference more than one "ccap" 
attribute with a network type of "IN" ?
b) All potential configurations for a particular media description MUST 
NOT reference more than one "ccap" attribute with a network type of "IN" ?
c) Something else ?

Thanks

-- Flemming

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 22 Mar 2013 16:00:22 -0400

Currently, the deployed SIP world has three mechanisms to allow some flavor of negotiation among multiple IP addresses: ICE, altc (despite the general disapproval of the working group), and ANAT (despite its deprecation).

I think that adding ccap as a fourth member of this set would be a terrible idea; and as far as I can tell, no one wants to do that.  So we need to make it clear that that it MUST NOT be used for that purpose.

In the formulation below, I think I'd say that a given media description MUST NOT indicate more than one address with an IN network type, across all its configurations (actual and potential).

Obviously, different media descriptions (m= line blocks) can have different addresses.

In practice, given the port number issue that started this thread, I suspect this means that the SDP offer will need to put the IN address in the actual configuration (in the c= line), and the PSTN address(es) will be in the potential configurations.

--
Jonathan Lennox
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 23 Mar 2013 09:24:14 +0000

Hi,

In general I agree that having multiple ways of doing the same thing is not a good thing, and I don't have any strong feelings regarding the ccap usage.

But, no matter what we say, what would actually prevent people from using ccap, in the same way they are using ANAT and altc? :)

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jonathan Lennox [[email-masked]]
Sent: Friday, 22 March 2013 10:00 PM
To: Flemming Andreasen
Cc: [email-masked]
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and     IP-addresses    (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

--
Jonathan Lennox
[email-masked]

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 24 Mar 2013 11:39:21 -0400

> But, no matter what we say, what would actually prevent people from using ccap, in the same way they are using ANAT and altc? :)
There's no port signaling capability with ccap, but other than that, the 
only thing that prevents people from using this to signal alternative 
IP-addresses is the existence of a "MUST NOT" in the spec.

-- Flemming

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 24 Mar 2013 17:00:39 +0000

>   bearer or a circuit-switched bearer.

That is not technically possible, in practice.  If a ccap were to contain an IN for an IP Address family, there is no port number indicated anywhere for that IP address.  Therefore it can't be used to indicate an IP Address alternate in practice, since one couldn't use the address alone.

So... either we re-introduce the port number so that a ccap can actually be used to indicate an IP Address, or we make ccap only usable for PSTN and not IN.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 24 Mar 2013 17:03:29 +0000

> Mid call Handover PS to CS and CS to PS uses other techniques and does not involve use of CCAP.

Then it sounds to me like 3GPP only needs ccap to indicate PSTN; it does not need to indicate an IP Address, as the c= line can do that.
Yes?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 24 Mar 2013 17:07:38 +0000

> In practice, given the port number issue that started this thread, I suspect this means that the SDP offer will need to put the IN address in the actual configuration (in the c= line), and the PSTN…

Yes exactly.  Remove the ability for ccap to use an IP Address by changing its ABNF.  That will remove any confusion. (though the wording of the usage still needs to be cleaned up of course)

-hadriel

---

From: Andrew Allen <[email-masked]>
Date: Sun, 24 Mar 2013 17:33:48 +0000

There is also nothing that prevents people from defining their own proprietary attributes to do such a thing but that is not part of an IETF standard and is not approved usage.

If we really feel the need to discourage further such usage I suppose we could add some text stating that if CCAP s received containing an IN net  type and an IN net type is present in the corresponding Connection Attribute then the CCAP attribute MUST be ignored.

That way compliant implementations would not perfom the discouraged behavior.

Andrew

----- Original Message -----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time
To: Christer Holmberg <[email-masked]>
Cc: Jonathan Lennox <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)

-- Flemming

---

From: Andrew Allen <[email-masked]>
Date: Sun, 24 Mar 2013 17:35:08 +0000

Hadriel

Correct

Andrew

----- Original Message -----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Sunday, March 24, 2013 12:03 PM Central Standard Time
To: Andrew Allen
Cc: [email-masked] (E-mail) <[email-masked]>
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and	IP-addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)

-hadriel

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 24 Mar 2013 21:21:37 -0400

On 3/24/13 1:07 PM, Hadriel Kaplan wrote:
> Yes exactly.  Remove the ability for ccap to use an IP Address by changing its ABNF.
That's my problem with this whole discussion. We have defined a general 
connection data capability, and now we don't want it to be able to 
express anything beyond "PSTN" - exactly why did we do this again and 
what was it the WG agreed to when taking this on as a WG item ?

Also, if you explicitly prevent the ABNF from supporting IP-addresses, 
then you must be listing the values that actually are supported and 
hence we've further lost generality in how we define this and general 
alignment with the SDP structure where we register supported values 
separately. I'm really not in favor of any of that.

-- Flemming

>   That will remove any confusion. (though the wording of the usage still needs to be cleaned up of course)
>
> -hadriel
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 24 Mar 2013 21:26:43 -0400

> So... either we re-introduce the port number so that a ccap can actually be used to indicate an IP Address, or we make ccap only usable for PSTN and not IN.
These are not the only choices. We strive for defining general 
solutions, and there is no reason why lack of port numbers should lead 
us to define a general connection data capability that cannot contain 
any IP-addresses. The connection data capability by itself will of 
course not be sufficient to allow for negotiation of transport address 
alternatives (intentionally), but that is really a separate (albeit 
related) issue.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 24 Mar 2013 21:31:35 -0400

> There is also nothing that prevents people from defining their own proprietary attributes to do such a thing but that is not part of an IETF standard and is not approved usage.
Agreed.

> If we really feel the need to discourage further such usage I suppose we could add some text stating that if CCAP s received containing an IN net  type and an IN net type is present in the correspo…
I think that gets complicated quickly for a questionable gain. I'd 
prefer the "MUST NOT" described below with an explanation as to why it's 
there; as you note, ultimately people either decide to be spec compliant 
or not.

-- Flemming

---

From: <[email-masked]>
Date: Mon, 25 Mar 2013 09:44:45 +0100

Dear all,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] 
>De la part de Jonathan Lennox
>Envoyé : vendredi 22 mars 2013 21:00
>À : Flemming Andreasen
>Cc : [email-masked]
>Objet : Re: [MMUSIC] Connection Data Capability (ccap) and 

>In practice, given the port number issue that started this 
>thread, I suspect this means that the SDP offer will need to 
>put the IN address in the actual configuration (in the c= 
>line), and the PSTN address(es) will be in the potential 
>configurations.

Med: This makes sense. This is a good way to proceed.