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

Paul Kyzivat <> Thu, 21 March 2013 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6143521F8CB4 for <>; Thu, 21 Mar 2013 13:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.013
X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xpm85Qu0mcba for <>; Thu, 21 Mar 2013 13:06:17 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:96]) by (Postfix) with ESMTP id 768F021F8CCF for <>; Thu, 21 Mar 2013 13:06:17 -0700 (PDT)
Received: from ([]) by with comcast id EEHT1l00516LCl059L6Gjl; Thu, 21 Mar 2013 20:06:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id EL6G1l00Q3ZTu2S3SL6GeR; Thu, 21 Mar 2013 20:06:16 +0000
Message-ID: <>
Date: Fri, 22 Mar 2013 04:06:15 +0800
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1363896376; bh=sHvsHdAiXoiQ3fjHy/iYTJ1PC+hgbIF0OH+Di+ipgdk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZnIgggeeWwL77fMWO2FUrHN9bHX6oztjJXEO1cFj/COxiU2KdjKZsq3Tfb3aQW0kx geuhG+TGIzUfSGE3PCCdo4vjNrc0NLVe2PU9docMCSWRgRRbVEmM4DliUpF6QICikh 8V3WCbuGUi5Gp1ydCyfXgM7NNV3Xkgmiv3kDRlg6fwRviLLyH2O4ZAYQXbY3XpmXqq uY1+L8wVlvfzWM80AhQMzo4TFBvhwmj3AZdz/OLV1tVASV1iLgPMnr9SjFmg3/ybmI OosMpr00CDplk/1KVGqIkCUVstOe2x+wJfxBOUmIdGHkFxyRFusHvCAnkcOy3Nms+l DzCFn/ATGMVbg==
Subject: Re: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Mar 2013 20:06:18 -0000


On 3/22/13 12:28 AM, Stach, Thomas wrote:
> 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: []
>> Im Auftrag von Flemming Andreasen
>> Gesendet: Donnerstag, 21. März 2013 14:41
>> An: Jonathan Lennox;; Hadriel
>> Kaplan; Atle Monrad;; Stach Thomas; Andrew Allen
>> Cc:
>> Betreff: 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, wrote:
>>> 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:
>> [] 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
>>> 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 mailing list
> _______________________________________________
> mmusic mailing list