Colin Perkins
Fri, 20 Nov 2009 11:58:30 -0800
Hi Tom, Both of those are features, rather than bugs though, right? Colin On 20 Nov 2009, at 17:00, Phelan, Tom wrote:
Hi Colin, I have two issues with this, probably neither of them showstoppers: 1) There's no way to support DCCP_NAT running on a non-standard port. 2) There's no way to say "Don't bother trying DCCP_RAW". Tom P.-----Original Message----- From: Colin Perkins [mailto:c...@csperkins.org] Sent: Friday, November 20, 2009 11:42 AM To: Phelan, Tom Cc: DCCP working group Subject: Re: [dccp] FW: New Version Notification fordraft-phelan-dccp-natencap-03 Tom, For the SDP, I think what's needed is a simple "a=dccp-in-udp" attribute which is declarative, takes no parameters, and indicates that the sender of the SDP supports the UDP encapsulation of DCCP. An SDP offer using it would look something like: v=0 o=alice 1129377363 1 IN IP4 192.0.2.47 s=- c=IN IP4 192.0.2.47 t=0 0 m=video 5004 DCCP/RTP/AVP 99 a=rtcp-mux a=rtpmap:99 h261/90000 a=dccp-service-code:SC=x52545056 a=dccp-in-udp a=setup:passive a=connection:new The idea is that the answering party will attempt to make a native DCCP connection where possible, but will fall back to using UDP- encapsulated DCCP if that doesn't work, or if it doesn't support native DCCP (trying both in parallel is also possible, of course). This removes a lot of complexity from the SDP, and moves the test for which transport actually works into the media path (where it has to be, to work through middleboxes). Colin On 19 Nov 2009, at 12:47, Phelan, Tom wrote:Hi Colin, Thanks for the support and comments. I did apply for a UDP port a while ago, and was told I had to wait for it to be a WG draft. I'll reapply when/if this gets WG status. Can you give me more detail for what you'd like to see in the SDP? Tom P.-----Original Message----- From: Colin Perkins [mailto:c...@csperkins.org] Sent: Thursday, November 19, 2009 6:17 AM To: Phelan, Tom Cc: DCCP working group Subject: Re: [dccp] FW: New Version Notification fordraft-phelan-dccp-natencap-03 Hi, As I said in the meeting, we have an implementation of this (the basic encapsulation, not the SDP signalling), and I support it's publication as an experimental RFC. I have two suggestions for modifications, though: 1) I'd recommend registering a UDP port for the DCCP-in-UDP encapsulation service. 2) I suggest the SDP extension be changed to be a declarative "I support DCCP-in-UDP NAT encapsulation" option, rather than listing preferences or ports. Both these are in the spirit of doing the simplest possible thing that could work. I'm happy to contribute text to the draft for these, if the group accepts the idea. Cheers, Colin On 18 Nov 2009, at 16:11, Phelan, Tom wrote:Hi All, I have submitted a new version of draft-phelan-dccp-natencap (-03)tothe I-D depository. This version just resurrects the draft afteraperiod of inactivity -- there are no technical changes. Tom P. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org] Sent: Wednesday, November 18, 2009 11:09 AM To: Phelan, Tom Subject: New Version Notification fordraft-phelan-dccp-natencap-03A new version of I-D, draft-phelan-dccp-natencap-03.txt has been successfuly submitted by Thomas Phelan and posted to the IETF repository. Filename: draft-phelan-dccp-natencap Revision: 03 Title: Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-NAT) Creation_date: 2009-11-18 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document specifies an alternative encapsulation of theDatagramCongestion Control Protocol (DCCP), referred to as DCCP-NAT. This encapsulation will allow DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxeswithoutmodification of those middleboxes. The IETF Secretariat.-- Colin Perkins http://csperkins.org/-- Colin Perkins http://csperkins.org/
-- Colin Perkins http://csperkins.org/