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

Andrew Allen <> Tue, 19 March 2013 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 363E821F8951 for <>; Tue, 19 Mar 2013 05:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.285
X-Spam-Status: No, score=-4.285 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9H0lWvmMssoC for <>; Tue, 19 Mar 2013 05:27:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1F7EA21F89D8 for <>; Tue, 19 Mar 2013 05:27:44 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-06-514859b05d03
Received: from ( []) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by (SBG) with SMTP id CC.49.13213.0B958415; Tue, 19 Mar 2013 07:27:29 -0500 (CDT)
Received: from ([fe80::2494:a63d:e3:723b]) by ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Tue, 19 Mar 2013 07:27:28 -0500
From: Andrew Allen <>
To: "" <>, "" <>
Thread-Topic: [MMUSIC] Connection Data Capability (ccap) and IP-addresses (draft-ietf-mmusic-sdp-miscellaneous-caps-04)
Thread-Index: AQHOJGputCjuJ1Z4YUGk72Cnji+Gkpis8WYH
Date: Tue, 19 Mar 2013 12:27:27 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsXC5Zyvq7sx0iPQ4OYSdov3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEU1MNokJZaUBWem5+nb2STm5eWXJJakKqSkFifbKvmkpifmKAQUZZYl JlcquGQWJ+ckZuamFikpZKbYKpkoKRTkJCan5qbmldgqJRYUpOalKNlxKWAAG6CyzDyF1Lzk /JTMvHRbJc9gf10LC1NLXUMlO92ETp6M7V8usRU0ileseTSbtYHxi1AXIyeHhICJxL83jUwQ tpjEhXvr2boYuTiEBNqYJGb3TmGEcDYzSiy68I4ZpIpNQEti/+HpYB0iAiESVzYuYwWxhQUq JF51rGeBiFdKvOj8CBTnALKNJH7dtwEJswioSsw70MQGYvMKeEgs+nMDzOYU0JToOd4E1soI dMT3U2vAxjMLiEvcejIf6jgBiSV7zjND2KISLx//Y4WwFSX+7v3OClGvJ3Fj6hQ2CFtbYtnC 18wQuwQlTs58wjKBUWQWkrGzkLTMQtIyC0nLAkaWVYyCuRnFBmaGyXnJekWZuXp5qSWbGEFR 76hhsIPx/XuLQ4wCHIxKPLyrvT0ChVgTy4orcw8xSnAwK4nwxrkChXhTEiurUovy44tKc1KL DzG6AkNiIrMUd3I+MCHllcQbGxjg5iiJ85ZpOgUKCaQDk0x2ampBahHMHCYOTpA9XFIixcBU kVqUWFqSEQ9KaPHFwJQm1cDopZcrpz/5cvSJtUcaxfXsfv17/N7lyOVPruXmF26fyvJg+z2j WqWt+tHCN653c+e93BD95qWPRfeBw7eaj1bpXNwa9ueO41XGOXFhkfHc3683Ked1pyleujJv r5/rtL6i5GpbJz7reBPlOzt9U7a0H9PbfOyvLmug0NVYnnPJT6c1xN/jDtVSYinOSDTUYi4q TgQA55ES9DsDAAA=
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: Tue, 19 Mar 2013 12:27:45 -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.


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


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:
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).

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


-- Flemming

mmusic mailing list

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.