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.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
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic