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

<Simo.Veikkolainen@nokia.com> Fri, 26 April 2013 09:22 UTC

Return-Path: <Simo.Veikkolainen@nokia.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E72621F988D for <mmusic@ietfa.amsl.com>; Fri, 26 Apr 2013 02:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qpc3NbS-tMtc for <mmusic@ietfa.amsl.com>; Fri, 26 Apr 2013 02:22:44 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E426021F988C for <mmusic@ietf.org>; Fri, 26 Apr 2013 02:22:43 -0700 (PDT)
Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r3Q9MRHq006175; Fri, 26 Apr 2013 12:22:28 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Apr 2013 12:22:27 +0300
Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.240]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0328.011; Fri, 26 Apr 2013 09:22:26 +0000
From: Simo.Veikkolainen@nokia.com
To: fandreas@cisco.com
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOO3h4GI1XUw+H1UKVjshlEllXf5jjVzIggAPSQ4CAAR5VMA==
Date: Fri, 26 Apr 2013 09:22:26 +0000
Message-ID: <D09DAE6B636851459F7575D146EFB54B210E74D2@008-AM1MPN1-024.mgdnok.nokia.com>
References: <BBF5DDFE515C3946BC18D733B20DAD2338D31D67@XMB104ADS.rim.net> <514FA8F7.7060203@cisco.com> <D09DAE6B636851459F7575D146EFB54B210ADF26@008-AM1MPN1-025.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36EC2D7C282@PUEXCB1B.nanterre.francetelecom.fr> <5168A94B.20608@cisco.com> <94C682931C08B048B7A8645303FDC9F36EC66217CC@PUEXCB1B.nanterre.francetelecom.fr> <516EB28A.1050003@cisco.com> <D09DAE6B636851459F7575D146EFB54B210E5F5D@008-AM1MPN1-024.mgdnok.nokia.com> <517956CB.2040701@cisco.com>
In-Reply-To: <517956CB.2040701@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-version: 3.5.9.3
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ivm4xbzrYVxIZLYcVE8MkpBpYSmhkAuQqQMGR/NKzjcJ6f+e0jPWCKW7SGpJea1HxF1+/yLcs1+3lx3oszWyEpFv854jwBDNm5uGBrLhHEq2uJVa1v3Zy3IaDHnDpP8YdeWJoIxth58+K+iDrSfX6VQ02aQvlegHvqg5/RXW70sT2gWMegB3w4ZokmZ6TonQusO76vvQMHR/vQU0QPUC11SVb40uqfcnkx/QGq/+rxh6PjGmIEYoBsFtbNHhKJpsDCi2sWHkj6c1vywSqwUPIuCiLtKIL2Gu8XWL0WJgw3GKD0xnlqe8LYUvX+UUenTVQQ==
x-originating-ip: [172.21.81.167]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Apr 2013 09:22:27.0189 (UTC) FILETIME=[9191A250:01CE425F]
X-Nokia-AV: Clean
Cc: jonathan@vidyo.com, mmusic@ietf.org, christer.holmberg@ericsson.com
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2013 09:22:46 -0000

See below [SV].

-----Original Message-----
From: ext Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: 25. huhtikuuta 2013 19:16
To: Veikkolainen Simo (Nokia-CTO/Espoo)
Cc: mohamed.boucadair@orange.com; aallen@blackberry.com; HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; christer.holmberg@ericsson.com
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)


On 4/23/13 4:37 AM, Simo.Veikkolainen@nokia.com 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
>
> 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' 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.
>
>     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---
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>

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

Simo

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

Thanks

-- Flemming

> Regards,
> Simo
>
>
> -----Original Message-----
> From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: 17. huhtikuuta 2013 17:33
> To: mohamed.boucadair@orange.com
> Cc: Veikkolainen Simo (Nokia-CTO/Espoo); aallen@blackberry.com; 
> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; 
> christer.holmberg@ericsson.com
> Subject: Re: [MMUSIC] Connection Data Capability (ccap) and 
> IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>
>
> On 4/17/13 7:08 AM, mohamed.boucadair@orange.com 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
>
>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Flemming Andreasen [mailto:fandreas@cisco.com] Envoyé : samedi
>>> 13 avril 2013 02:40 À : BOUCADAIR Mohamed OLNC/OLN Cc :
>>> Simo.Veikkolainen@nokia.com; aallen@blackberry.com; 
>>> HKaplan@acmepacket.com; jonathan@vidyo.com; mmusic@ietf.org; 
>>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection Data 
>>> Capability (ccap) and IP-addresses
>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>
>>>
>>> On 4/12/13 11:39 AM, mohamed.boucadair@orange.com 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.
>>>>
>>>> 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 : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De 
>>>>> la part
>>> de
>>>>> Simo.Veikkolainen@nokia.com
>>>>> Envoyé : lundi 8 avril 2013 08:35
>>>>> À : fandreas@cisco.com; aallen@blackberry.com; 
>>>>> HKaplan@acmepacket.com Cc : jonathan@vidyo.com; mmusic@ietf.org; 
>>>>> christer.holmberg@ericsson.com Objet : Re: [MMUSIC] Connection 
>>>>> Data Capability (ccap) and IP-addresses
>>>>> (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
>>>>>
>>>>> 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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On 
>>>>> Behalf
>>> Of
>>>>> ext Flemming Andreasen
>>>>> Sent: 25. maaliskuuta 2013 3:32
>>>>> To: Andrew Allen
>>>>> Cc: jonathan@vidyo.com; mmusic@ietf.org; 
>>>>> christer.holmberg@ericsson.com
>>>>> 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:fandreas@cisco.com]
>>>>>> Sent: Sunday, March 24, 2013 10:39 AM Central Standard Time
>>>>>> To: Christer Holmberg <christer.holmberg@ericsson.com>
>>>>>> Cc: Jonathan Lennox <jonathan@vidyo.com>; mmusic@ietf.org
>>>>> <mmusic@ietf.org>
>>>>>> 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: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on 
>>>>>>> behalf of
>>>>> Jonathan Lennox [jonathan@vidyo.com]
>>>>>>> Sent: Friday, 22 March 2013 10:00 PM
>>>>>>> To: Flemming Andreasen
>>>>>>> Cc: mmusic@ietf.org
>>>>>>> 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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 
>>>>>>>>> On
>>>>> Behalf Of Simo.Veikkolainen@nokia.com
>>>>>>>>> Sent: Wednesday, March 20, 2013 5:57 AM
>>>>>>>>> To: fandreas@cisco.com; mmusic@ietf.org
>>>>>>>>> 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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 
>>>>>>>>> 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.h
>>>>>>>>> t
>>>>>>>>> ml)
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> mmusic@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>> _______________________________________________
>>>>>>>>> mmusic mailing list
>>>>>>>>> mmusic@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.
>>>>>>>>> .
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> mmusic mailing list
>>>>>>>> mmusic@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>
>>>>>>> --
>>>>>>> Jonathan Lennox
>>>>>>> jonathan@vidyo.com
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing list
>>>>>>> mmusic@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>> .
>>>>>>>
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> mmusic@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.
>>>>>> .
>>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> mmusic@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> mmusic@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> .
>>>>
>> .
>>
> .
>