Subject: [MMUSIC] TR: I-D Action:draft-boucadair-mmusic-ccap-00.txt

From: <[email-masked]>
Date: Mon, 6 Jul 2009 13:44:00 +0200

Dear all,

This draft has been submitted. 

Comments and suggestions are more than welcome.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 6 juillet 2009 11:45
À : [email-masked]
Objet : I-D Action:draft-boucadair-mmusic-ccap-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Session Description Protocol (SDP) Connectivity Capability (CCAP) Attribute
	Author(s)       : M. Boucadair, H. Kaplan
	Filename        : draft-boucadair-mmusic-ccap-00.txt
	Pages           : 14
	Date            : 2009-07-06

This memo proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer/answer.  The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boucadair-mmusic-ccap-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 7 Jul 2009 01:06:16 -0400

BTW, this draft was submitted in response to the discussion around the need for an ANAT-type model that was backwards-compatible, and for a v4/v6 stack option-tag indicator, which was a topic of discussion on SIPPING back in February and March.  That thread started with:
http://www.ietf.org/mail-archive/web/sipping/current/msg16718.html

-hadriel
p.s. sorry about the cross-posting, but SIPPING is effectively closed (right?) so it's hard to know where to post such notices which are tightly related to SIP.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Monday, July 06, 2009 7:44 AM
> 
> Dear all,
> 
> This memo proposes a mechanism which allows to carry multiple IP
> addresses, of different address families (e.g., IPv4, IPv6), in the same
> SDP offer/answer.  The proposed attribute solves the backward
> compatibility problem which plagued ANAT, due to its syntax.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: <[email-masked]>
Date: Tue, 7 Jul 2009 13:22:44 +0200

[Dropping dispatch and sipping.]

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Hadriel Kaplan
>Sent: 07 July, 2009 08:06
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: [Sipping] A replacement for ANAT
>
>
>BTW, this draft was submitted in response to the discussion 
>around the need for an ANAT-type model that was 
>backwards-compatible, and for a v4/v6 stack option-tag 
>indicator, which was a topic of discussion on SIPPING back in 
>February and March.  That thread started with:

Sorry for missing the discussion on SIPPING. Have you taken a look at http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00, which also defines a ccap attribute? The draft has exprired, but we are planning to submit an updated version soon (with minimal changes).

Regards,
Simo

>
>-hadriel
>p.s. sorry about the cross-posting, but SIPPING is effectively 
>closed (right?) so it's hard to know where to post such 
>notices which are tightly related to SIP.
>
>
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of [email-masked]
>> De : [email-masked] 
>> [mailto:[email-masked]]
>> De la part de [email-masked] Envoyé : lundi 6 juillet 2009 
>> 11:45 À : [email-masked] Objet : I-D 
>> Action:draft-boucadair-mmusic-ccap-00.txt
>> 
>> 	Title           : Session Description Protocol (SDP) 
>Connectivity
>> Capability (CCAP) Attribute
>> addresses, of different address families (e.g., IPv4, IPv6), in the 
>> same SDP offer/answer.  The proposed attribute solves the backward 
>_______________________________________________
>Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip 
>Use [email-masked] for new developments of core SIP
>

---

From: <[email-masked]>
Date: Tue, 7 Jul 2009 14:50:40 +0200

Dear Simo,

Thank you for this information. I'm not aware about this draft.

We need to check together if we have the same definition and usage of the ccap attribute.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 7 juillet 2009 13:23
À : [email-masked]; [email-masked]
Objet : Re: [MMUSIC] A replacement for ANAT

>BTW, this draft was submitted in response to the discussion around the 
>need for an ANAT-type model that was backwards-compatible, and for a 
>v4/v6 stack option-tag indicator, which was a topic of discussion on 
>SIPPING back in February and March.  That thread started with:

Regards,
Simo

>
>-hadriel
>p.s. sorry about the cross-posting, but SIPPING is effectively closed 
>(right?) so it's hard to know where to post such notices which are 
>tightly related to SIP.
>
>
>[email-masked] for questions on current sip Use 
>[email-masked] for new developments of core SIP
>
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 7 Jul 2009 23:00:57 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 07, 2009 7:23 AM
> 
> Sorry for missing the discussion on SIPPING. Have you taken a look at
> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00, which also
> defines a ccap attribute? The draft has exprired, but we are planning to
> submit an updated version soon (with minimal changes).

Heh, that's funny - nope hadn't seen that draft before.  

The concepts are obviously similar, though different in the following ways:
1) The boucadair draft does not to tie the ccap concept to sdp-cap-neg in any way.  Specifically, we did not want to make implementers have to support sdp-cap-neg just to offer alternate addresses for v4/v6.  Sdp-cap-neg is a fairly complex mechanism for people who don't need it.

2) We assumed in the boucadair draft that a host could not necessarily use the same UDP/TCP/etc. port numbers for the alternate address, since they're different number spaces, so we include the port number in the ccap attribute.

3) Since we include the port number in the ccap in the boucadair draft, and the port number is specific to the media line, we do not allow the ccap at the session level - only the media level.

4) The boucadair draft is for the alternate address/port connection concept only, and not for any other capabilities.  This was done on purpose, because the only goal was to have a workable replacement model for ANAT for v4/v6, so we wanted any claims of compliance to the draft to be for the specific support of ccap.

-hadriel

---

From: <[email-masked]>
Date: Wed, 8 Jul 2009 11:43:13 +0200

>From: ext Hadriel Kaplan [mailto:[email-masked]] 
>Sent: 08 July, 2009 06:01
>To: Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]
>Cc: [email-masked]
>Subject: RE: A replacement for ANAT
>
>
>
>http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00, which 
>> also defines a ccap attribute? The draft has exprired, but we are 
>> planning to submit an updated version soon (with minimal changes).
>
>1) The boucadair draft does not to tie the ccap concept to 
>sdp-cap-neg in any way.  Specifically, we did not want to make 
>implementers have to support sdp-cap-neg just to offer 
>alternate addresses for v4/v6.  Sdp-cap-neg is a fairly 
>complex mechanism for people who don't need it.
>
>2) We assumed in the boucadair draft that a host could not 
>necessarily use the same UDP/TCP/etc. port numbers for the 
>alternate address, since they're different number spaces, so 
>we include the port number in the ccap attribute.
>
>3) Since we include the port number in the ccap in the 
>boucadair draft, and the port number is specific to the media 
>line, we do not allow the ccap at the session level - only the 
>media level.
>
>4) The boucadair draft is for the alternate address/port 
>connection concept only, and not for any other capabilities.  
>This was done on purpose, because the only goal was to have a 
>workable replacement model for ANAT for v4/v6, so we wanted 
>any claims of compliance to the draft to be for the specific 
>support of ccap.

The ccap attribute as defined in the boucadair draft seems to borrow its syntax from sdp cap-neg, but is otherwise totally independent; but I guess this was your intention. Actually, you probably could remove any references to sdp-cap-neg without losing any of the functionality you have described. 

You could use the definitions in draft-garcia-mmusic-sdp-misc-cap for the address capability part, but you would still need the port number indicated as a capability. This is not defined currently in any of the related drafts (sdp-cap-neg, sdp-media-capabilities, sdp-misc-cap). 

Simo

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 9 Jul 2009 16:59:51 +0200

Hi Hadriel and Simo,

this proposal resembles almost exactly what was proposed as
ice-micro-lite in early 2007.
ice-micro-lite was proposed as further reduced ice-lite procedures, i.e.
ice-lite without the need to respond to STUN connectivity checks.
The main differences in this new draft is that the syntax mimics
SDP-cap-neg instead of ICE.

The discussion back in 2007 ended with a proposal by Jonathan R. which
seemed to satisfy all needs.
--> http://www.ietf.org/mail-archive/web/mmusic/current/msg05648.html

I wonder if such an approach, i.e. ice-lite on both sides, would work
for your scenarios as well.

Regards
Thomas

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, July 08, 2009 11:43 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] A replacement for ANAT
> 
> 
>  
> 
> The ccap attribute as defined in the boucadair draft seems to 
> borrow its syntax from sdp cap-neg, but is otherwise totally 
> independent; but I guess this was your intention. Actually, 
> you probably could remove any references to sdp-cap-neg 
> without losing any of the functionality you have described. 
> 
> You could use the definitions in 
> draft-garcia-mmusic-sdp-misc-cap for the address capability 
> part, but you would still need the port number indicated as a 
> capability. This is not defined currently in any of the 
> related drafts (sdp-cap-neg, sdp-media-capabilities, sdp-misc-cap). 
> 
> Simo
> 
> >-hadriel
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 9 Jul 2009 12:46:17 -0400

Hi Thomas, 
I don't remember a micro-lite, but we did consider an ICE-Lite model instead of a new attribute.  The problem is, and correct me if I'm wrong, but in the current ICE draft-19 an ICE-lite implementation MUST be able to respond to connectivity checks.  That was a basic requirement from that email you cited as well.  The basic rationale for that is to enable NAT traversal.

But we have no such need in the boucadair-draft, or for ANAT replacement in general.  All we need is for an alternate address to be signaled in a backwards-compatible fashion in the offer, and one of them to be picked/used in the answer.  In particular, I fully expect there to be ccap-offering devices which cannot respond to connectivity checks.  So re-using the ice-lite concept is inappropriate I think.  It isn't ICE really.

For example, suppose a device which could not respond to connectivity checks sent an ice-lite offer, and the answerer was capable of ICE-full.  The answerer would do connectivity checks, and they would fail.  

So instead, the proposal in the boucadair-draft is to signal this using a ccap attribute, which is an alternative to ICE.  The offerer can offer both ccap and ICE (or even Ice-Lite); an Ice-only answerer would ignore the ccap; a ccap-only device would ignore the ICE attributes and do ccap; and an answerer which can do both can choose whether to use ICE or ccap, but it can't use both.

There are some other differences as well, but not as big probably.

-hadriel

> From: Stach, Thomas [mailto:[email-masked]]
> Sent: Thursday, July 09, 2009 11:00 AM
> 
> Hi Hadriel and Simo,
>

---

From: Bob Gilman <[email-masked]>
Date: Wed, 29 Jul 2009 10:30:31 -0600

Hadriel-
My apologies for the delay, but I have a few comments on your reply to
Simo, embedded below.
-Bob

Hadriel Kaplan wrote:
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] Sent: Tuesday, July 07, 2009
>> 7:23 AM
>> 
>> Sorry for missing the discussion on SIPPING. Have you taken a look
>> at http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00,
>> which also defines a ccap attribute? The draft has exprired, but we
>> are planning to submit an updated version soon (with minimal
>> changes).
> 
> The concepts are obviously similar, though different in the following
> ways: 1) The boucadair draft does not to tie the ccap concept to
> implementers have to support sdp-cap-neg just to offer alternate
> addresses for v4/v6.  Sdp-cap-neg is a fairly complex mechanism for
> people who don't need it.
[rrg]: If you don't want make it part of capability negotiation, then
        perhaps you could rename the attribute to not end in "cap".
        It could be a little confusing to work it into the Cap Neg model
        with a line like:
           a=acap:1 ccap:2 IP6 2001:db8::1 45678
        and it just complicates the problem of formulating a more general
        Cap Neg attribute that includes IN addresses or CT addresses, (or
        even AC addresses - RFC 1149).
> necessarily use the same UDP/TCP/etc. port numbers for the alternate
> address, since they're different number spaces, so we include the
> port number in the ccap attribute.
[rrg]: This is a very good point, and it should apply to capabilities
        negotiation as well.  We need to add an optional parameter to
        our ccap attribute to carry a port number when the <nettype>
        is "IN".
> 
> 3) Since we include the port number in the ccap in the boucadair
> draft, and the port number is specific to the media line, we do not
> allow the ccap at the session level - only the media level.
[rrg]: Since draft-garcia-mmusic-sdp-misc-cap-01 specifies that its
        ccap attribute always be interpreted at the media level, I see
        no reason its presence should not be confined to the media level
        as well.
> 
> 4) The boucadair draft is for the alternate address/port connection
> concept only, and not for any other capabilities.  This was done on
> purpose, because the only goal was to have a workable replacement
> model for ANAT for v4/v6, so we wanted any claims of compliance to
> the draft to be for the specific support of ccap.
[rrg]: I worry that solving the specific case might complicate the
        solution for the more general case as mentioned above.
> mmusic
> mailing list [email-masked] 
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 30 Jul 2009 03:39:39 -0400

Thanks for your comments Bob - I'll raise the attr name during the presentation of the draft (which will be in the next hour or so).

Can you describe what the use-cases are for a more "general" approach for alternative connection IP addresses?

-hadriel

> From: Bob Gilman [mailto:[email-masked]]
> Sent: Wednesday, July 29, 2009 12:31 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; [email-masked]

---

From: "Roni Even" <[email-masked]>
Date: Thu, 30 Jul 2009 10:39:10 +0300

Hi,
This functionality is part of the capability negotiation framework.
It was in the media capability negotiation and was moved according to WG
request to draft-garcia-mmusic-sdp-misc-cap-01

Roni Even

> Sent: Monday, July 06, 2009 2:44 PM
> To: [email-masked]; [email-masked]
> Subject: [MMUSIC] TR: I-D Action:draft-boucadair-mmusic-ccap-00.txt
> 
> 
> 
> Dear all,
> 
> De : [email-masked] [mailto:i-d-announce-
> [email-masked]] De la part de [email-masked] Envoyé : lundi
> 6 juillet 2009 11:45 À : [email-masked] Objet : I-D

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 30 Jul 2009 03:43:24 -0400

Ah, yes we learned it was in that draft. (I thought you meant in the current WG cap-neg drafts)

I'll be mentioning that today in the presentation.
Thanks!

-hadriel

> Of Roni Even
> Sent: Thursday, July 30, 2009 3:39 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [MMUSIC] TR: I-D Action:draft-boucadair-mmusic-ccap-00.txt
> 
> Hi,

---

From: "Roni Even" <[email-masked]>
Date: Thu, 30 Jul 2009 10:42:47 +0300

Simo,
The reason for not offering different ports in cap negotiation work is to
not replace ICE
Roni Even

> Behalf Of [email-masked]
> Sent: Wednesday, July 08, 2009 12:43 PM
> The ccap attribute as defined in the boucadair draft seems to borrow
> its syntax from sdp cap-neg, but is otherwise totally independent; but
> I guess this was your intention. Actually, you probably could remove
> any references to sdp-cap-neg without losing any of the functionality
> you have described.
> 
> You could use the definitions in draft-garcia-mmusic-sdp-misc-cap for
> the address capability part, but you would still need the port number
> indicated as a capability. This is not defined currently in any of the

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 30 Jul 2009 05:15:12 -0400

I'm confused by this - how does offering different *addresses* in sdp-cap not "replace" ICE, but offering different ports does replace it?

-hadriel

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, July 30, 2009 3:43 AM
> To: [email-masked]; Hadriel Kaplan; [email-masked]
> Subject: RE: [MMUSIC] A replacement for ANAT
> 
> Simo,