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

From: <[email-masked]>
Date: Mon, 8 Apr 2013 06:35:24 +0000

Recapping the discussion so far:

- ICE is the way to negotiate between different IP addresses. There seems to be no disagreement here.

- since no alternative port number can be expressed, in practice the IN address needs to go to the actual configuration (address in the c= line and port number in the m= line), and the alternative PSTN address in the potential configurations. Also here, there seems to be no disagreement.

- then, whether the "ccap" attribute should be limited to carry only PSTN addresses, or also other types. I'm with Flemming on this one; SDP capneg framework is already fragmented enough, and limiting the connection address capability to PSTN addresses only would again be targeted for a single use case only, whereas we should strive for general solutions. 

Simo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Flemming Andreasen
Sent: 25. maaliskuuta 2013 3:32
To: Andrew Allen
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

On 3/24/13 1:33 PM, Andrew Allen wrote:
> 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 corresponding Connection Attribute then the CCAP attribute MUST be ignored.
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
> 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)
>
>
> On 3/23/13 5:24 AM, Christer Holmberg wrote:
>> 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? :)
> 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
>
>> 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)
>>
>> 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.
>>
>> On Mar 22, 2013, at 2:37 PM, Flemming Andreasen wrote:
>>
>>> 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
>>>
>>>
>>>
>>> On 3/22/13 1:35 AM, Andrew Allen wrote:
>>>> 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)
>>>>
>>>> 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 '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
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> _______________________________________________
>>>> 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.
>>>> .
>>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>> --
>> Jonathan Lennox
>> [email-masked]
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>>
> _______________________________________________
> 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.
> .
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 10 Apr 2013 15:30:10 -0400

> - then, whether the "ccap" attribute should be limited to carry only PSTN addresses, or also other types. I'm with Flemming on this one; SDP capneg framework is already fragmented enough, and limit…
Agree with you.

Any other comments from anybody ?

If we do not hear otherwise from anybody by the end of this week, we 
will proceed according to the above.

Thanks

-- Flemming (MMUSIC co-chair)

---

From: <[email-masked]>
Date: Fri, 12 Apr 2013 17:39:04 +0200

Hi Simo,

I'm in favor of restricting the alternative address to PSTN. This is coherent whit your first bullet below.

If you share the text changes you are proposing, this would be more easier to review.

Thanks for taking care of this issue.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>[email-masked]
>Envoyé : lundi 8 avril 2013 08:35
>À : [email-masked]; [email-masked]; [email-masked]
>Cc : [email-masked]; [email-masked]; [email-masked]
>Objet : Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses
>(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
>- since no alternative port number can be expressed, in practice the IN
>address needs to go to the actual configuration (address in the c= line and
>port number in the m= line), and the alternative PSTN address in the
>potential configurations. Also here, there seems to be no disagreement.
>
>- then, whether the "ccap" attribute should be limited to carry only PSTN
>addresses, or also other types. I'm with Flemming on this one; SDP capneg
>framework is already fragmented enough, and limiting the connection address
>capability to PSTN addresses only would again be targeted for a single use
>case only, whereas we should strive for general solutions.
>
>Simo
>
>
>Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses
>(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
>
>> 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 corresponding Connection
>Attribute then the CCAP attribute MUST be ignored.
>> Subject: Re: [MMUSIC] Connection Data Capability (ccap)	and	IP-
>addresses	(draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>
>>
>>> 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? :)
>>> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and     IP-
>addresses    (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>
>>> 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).
>>>
>>> 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.
>>>
>>>>> Subject: 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>
>>>>> 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)
>>>>> 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.
>>>>> .
>>>>>
>> 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: Flemming Andreasen <[email-masked]>
Date: Fri, 12 Apr 2013 20:39:39 -0400

On 4/12/13 11:39 AM, [email-masked] wrote:
> Hi Simo,
>
> I'm in favor of restricting the alternative address to PSTN.
Can you elaborate on why ?

We have defined a generic connection data capability as part of a 
general capability negotiation framework. What's the point of that if 
the only value it can convey is PSTN ?

Thanks

-- Flemming

> This is coherent whit your first bullet below.
>

---

From: <[email-masked]>
Date: Wed, 17 Apr 2013 13:08:24 +0200

Hi Felmming,

Because it does not allow to indicate an alternate port number. This makes it a no working solution for various scenarios.

The text which triggered this discussion was confusing. I hope the updated version will be much more clear and reflect what have been discussion so far in this thread.

Cheers,
Med

>De : Flemming Andreasen [mailto:[email-masked]]
>Envoyé : samedi 13 avril 2013 02:40
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked];
>[email-masked]
>>> - ICE is the way to negotiate between different IP addresses. There
>seems
>>> to be no disagreement here.
>>>
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>Of
>>> ext Flemming Andreasen
>>>>>>>        negotiating alternative connection address information, such
>as
>>> when
>>>>>>> - RFC 6849 (media loopback) provides for NAT traversal in the
>absence
>>> of ICE support
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -- Flemming
>>>>>>>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 17 Apr 2013 10:32:42 -0400

On 4/17/13 7:08 AM, [email-masked] wrote:
> Hi Felmming,
>
> Because it does not allow to indicate an alternate port number.
Correct - a connection address does not provide a port number; a 
different capability would be needed for that.
> This makes it a no working solution for various scenarios.
No - it simply means that you would need to define another capability to 
convey port numbers if you wanted such a solution (however we have ICE 
as the complete solution for that and the WG has not indicated a desire 
to change that).

> The text which triggered this discussion was confusing. I hope the updated version will be much more clear and reflect what have been discussion so far in this thread.
I have asked Simo to update the draft.

Thanks

-- Flemming

---

From: <[email-masked]>
Date: Thu, 18 Apr 2013 11:27:53 +0200

Hi Fleming,

Please see inline.

Cheers,
Med

>Envoyé : mercredi 17 avril 2013 16:33

[Med] Yes, I understood the wg does not want to change and extend the capability to cover more than the PSTN case.

>
>> The text which triggered this discussion was confusing. I hope the
>updated version will be much more clear and reflect what have been
>discussion so far in this thread.

[Med] Ok, thanks.

>>>>> De : [email-masked] [mailto:[email-masked]] De la
>part
>>> de
>>>>> address needs to go to the actual configuration (address in the c=
>line
>>> and
>addresses
>>>>> MUST NOT indicate more than one address with an IN network type,
>across
>>> all
>>>>> the actual configuration (in the c= line), and the PSTN address(es)
>will
>>> be
>>>>> highest priority configuration (in the "m=" line).  However, if we
>want
>>> to
>>>>> for negotiating and determining alternative IP-address information
>today
>>> is
>>>>>>>>>         between different connection addresses (e.g.  "IP4" and
>"IP6"
>>> or
>>>>>>>>> - There are scenarios where ICE cannot be used, even if
>implemented
>>>>> (e.g. ice-mismatch).
>>>>>>>>> ------------------------------------------------------------------
>--
>>> -

---

From: <[email-masked]>
Date: Tue, 23 Apr 2013 08:37:12 +0000

Below the original and proposed text on the usage of ccap attribute in Section 3.1.2. of http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 

This is pretty much the same text I proposed earlier, including Jonathan's wording on IN address families. 

--- begin original text ---
   The 'ccap' capability attribute allows for expressing alternative
   connection address ('c=') lines in SDP as part of the SDP capability
   negotiation process.  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).
--- end original text ---

--- begin proposed text ---

   The 'ccap' attribute MUST NOT be used to indicate more 
   than one address with an IN network type in actual 
   or potential configurations for any given media description 
   (e.g. between  "IP4" and "IP6" address families or different 
   IP addresses within the same IP address family).
--- end proposed text---

Also, since no alternative port numbers can be offered, add this sentence at the end the of the last paragraph to clarify how alternative IP and PSTN media descriptions are offered:

   This document does not define any mechanism for negotiating or
   describing different port numbers and hence the port number from the
   "m=" line MUST be used by default. Exceptions to this default can be
   provided by extension mechanisms or network type specific rules.
   This draft defines an exception when the network type is "PSTN", in
   which case the port number is replaced with 9 (the "discard" port) as
   described in Session Decription  Protocol (SDP) Extension For Setting
   Up Audio and Video Media Streams over Circuit-Switched Bearers in the
   Public Switched Telephone Network (PSTN) [I-D.ietf-mmusic-sdp-cs].
 --- begin new text ---
   An endpoint offering alternative IP and PSTN bearers MUST include the 
   IP media description in the actual configuration (IP address in the "c=" line
   and port number in the "m=" line), and the PSTN media descriptions in the 
  potential configuration.
--- end new text ---

Regards,
Simo

-----Original Message-----
From: ext Flemming Andreasen [mailto:[email-masked]] 
Sent: 17. huhtikuuta 2013 17:33
To: [email-masked]
Cc: Veikkolainen Simo (Nokia-CTO/Espoo); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

> Because it does not allow to indicate an alternate port number.
Correct - a connection address does not provide a port number; a different capability would be needed for that.
> This makes it a no working solution for various scenarios.
No - it simply means that you would need to define another capability to convey port numbers if you wanted such a solution (however we have ICE as the complete solution for that and the WG has not indicated a desire to change that).

Thanks

-- Flemming

>> De : Flemming Andreasen [mailto:[email-masked]] Envoyé : samedi 
>> 13 avril 2013 02:40 À : BOUCADAIR Mohamed OLNC/OLN Cc : 
>> [email-masked]; [email-masked]; 
>> [email-masked] Objet : Re: [MMUSIC] Connection Data 
>> Capability (ccap) and IP-addresses
>>>> À : [email-masked]; [email-masked]; 
>>>> [email-masked] Cc : [email-masked]; [email-masked]; 
>>>> [email-masked] Objet : Re: [MMUSIC] Connection Data 
>>>> Capability (ccap) and IP-addresses
>>>> - since no alternative port number can be expressed, in practice 
>>>> the IN address needs to go to the actual configuration (address in 
>>>> the c= line
>> and
>>>> port number in the m= line), and the alternative PSTN address in 
>>>> the potential configurations. Also here, there seems to be no disagreement.
>>>>
>>>> - then, whether the "ccap" attribute should be limited to carry 
>>>> only
>> PSTN
>>>> capability to PSTN addresses only would again be targeted for a 
>>>> single
>> use
>>>> proprietary attributes to do such a thing but that is not part of 
>>>> an
>> IETF
>>>>> 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.
>>>> 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
>>>>> That way compliant implementations would not perfom the 
>>>>> discouraged
>>>> behavior.
>>>>> Andrew
>>>>>
>>>>>> 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.
>>>>> 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
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>>
>>>>>> From: [email-masked] [[email-masked]] on behalf 
>>>>>> of
>>>> Jonathan Lennox [[email-masked]]
>>>> flavor of negotiation among multiple IP addresses: ICE, altc 
>>>> (despite
>> the
>>>> 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.
>>>> 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
>>>>>>> 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.
>>>>>>> 1) It allows the use of "ccap" to be used to indicate one or 
>>>>>>> more
>> "IP4"
>>>>>>> 2) It allows the use of "ccap" to be used to indicate one or 
>>>>>>> more
>> "IP6"
>>>>>>> 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:
>>>>>>> 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: [email-masked] [mailto:[email-masked]] 
>>>>>>>> On
>>>> Behalf Of [email-masked]
>>>> 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>
>>>> 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
>>>>>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>>>>> On
>>>> Behalf Of ext Flemming Andreasen
>>>>>>>> As you may have seen, there has recently been some list 
>>>>>>>> discussion
>> on
>>>> 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
>>>>>>>>         the <nettype> is different among the alternative 
>>>>>>>> addresses
>> (e.g.
>>>>>>>>         Connectivity Establishment (ICE) [RFC5245]) can be used 
>>>>>>>> to
>>>> select
>>>> to use "ccap" to convey an IP4 or IP6 address, and if so, under 
>>>> what circumstances ?
>>>>>>>> - 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
>>>>>>>> - The connection data capability is defined in a general manner 
>>>>>>>> to
>> be
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -----
>> -
>>>> information, privileged material (including material protected by 
>>>> the solicitor-client or other applicable privileges), or constitute 
>>>> non-
>> public
>>>> 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.
>>>>>>>> .
>>>>>>>>
>>>>> --- 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
>>>> 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: Flemming Andreasen <[email-masked]>
Date: Thu, 25 Apr 2013 12:16:11 -0400

>     IP addresses within the same IP address family).
I'm ok with the overall restriction but I think the opening wording is 
overly constraining. With that in mind, a slightly modified proposal below:
<quote>

    The 'ccap' capability attribute allows for expressing alternative
    connection address ('c=') lines in SDP as part of the SDP capability
    negotiation process. One of the primary use cases for this is offering
    alternative connection addresses where the <nettype>
    is "IN" or "PSTN", i.e., selecting between an IP based
    bearer or a circuit-switched bearer.

By supporting the "IN" <nettype>, the 'ccap' attribute enables the signaling of multiple IPv4 and IPv6 addresses, however the Standards Track mechanism for negotiation of alternative IP addresses in SDP is Interactive Connectivity Establishment (ICE) [RFC5245]. The 'ccap' attribute does not change that and hence the combined set of actual and potential configurations (as defined in [RFC5939]) for any given media description MUST NOT use the 'ccap' attribute to negotiate more than one address with an IN network type (i.e., it is not permissible to select between "IP4" and "IP6" address families or different IP addresses within the same IP address family).

</quote>
>     and port number in the "m=" line), and the PSTN media descriptions in the
Looks good.

Thanks

-- Flemming

---

From: <[email-masked]>
Date: Fri, 26 Apr 2013 09:22:26 +0000

See below [SV].

-----Original Message-----
From: ext Flemming Andreasen [mailto:[email-masked]] 
Sent: 25. huhtikuuta 2013 19:16
To: Veikkolainen Simo (Nokia-CTO/Espoo)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)

On 4/23/13 4:37 AM, [email-masked] wrote:
> Below the original and proposed text on the usage of ccap attribute in 
> Section 3.1.2. of 
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04
>
I'm ok with the overall restriction but I think the opening wording is overly constraining. With that in mind, a slightly modified proposal below:
<quote>

</quote>

[SV] I think your proposal makes the intent clearer; I'll edit the text accordingly.

Simo

Looks good.

Thanks

-- Flemming

> Cc: Veikkolainen Simo (Nokia-CTO/Espoo); [email-masked]; 
> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and 
> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
>
>>> general capability negotiation framework. What's the point of that 
>>> if the only value it can convey is PSTN ?
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>>
>>>>> De : [email-masked] [mailto:[email-masked]] De 
>>>>> la part
>>> de
>>>>> [email-masked] Objet : Re: [MMUSIC] Connection 
>>>>> Data Capability (ccap) and IP-addresses
>>>>> framework is already fragmented enough, and limiting the 
>>>>> connection
>>> address
>>>>> 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] [[email-masked]] on 
>>>>>>> behalf of
>>>>>>> Obviously, different media descriptions (m= line blocks) can 
>>>>>>> have
>>>>> different addresses.
>>>>>>>> ("pcfg") is what is being used for this. Is the restriction 
>>>>>>>> that we
>>>>> want
>>>>>>>> here:
>>>>>>>> NOT reference more than one "ccap" attribute with a network 
>>>>>>>> type of
>>>>> "IN" ?
>>>>>>>> c) Something else ?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> -- Flemming
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> 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
>>>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg10472.h
>>>>>>>>> t
>>>>>>>>> ml)
>>>>>>>>>
>>>>>>>>>          Connectivity Establishment (ICE) [RFC5245]) can be 
>>>>>>>>> used to
>>>>> select
>>>>>>>>> - The connection data capability is defined in a general 
>>>>>>>>> manner to
>>> be
>>>>> from your system. Use, dissemination, distribution, or 
>>>>> reproduction of this transmission by unintended recipients is not 
>>>>> authorized and may be unlawful.
>>>>>>>>> .
>>>>>>>>>
>>>>> from your system. Use, dissemination, distribution, or 
>>>>> reproduction of this transmission by unintended recipients is not 
>>>>> authorized and may be unlawful.
>>>>>> .
>>>>>>