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:csp@xxxxxxxxxxxxx] > Sent: Friday, November 20, 2009 11:42 AM > To: Phelan, Tom > Cc: DCCP working group > Subject: Re: FW: New Version Notification for draft-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:csp@xxxxxxxxxxxxx] > >> Sent: Thursday, November 19, 2009 6:17 AM > >> To: Phelan, Tom > >> Cc: DCCP working group > >> Subject: Re: FW: New Version Notification for > > draft-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) > > to > >>> the I-D depository. This version just resurrects the draft after a > >>> period of inactivity -- there are no technical changes. > >>> > >>> Tom P. > >>> > >>> -----Original Message----- > >>> From: IETF I-D Submission Tool [mailto:idsubmission@xxxxxxxx] > >>> Sent: Wednesday, November 18, 2009 11:09 AM > >>> To: Phelan, Tom > >>> Subject: New Version Notification for draft-phelan-dccp-natencap-03 > >>> > >>> > >>> A 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 the Datagram > >>> Congestion 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) middleboxes without > >>> modification of those middleboxes. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat. > >> > >> > >> > >> -- > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > > > > > > -- > Colin Perkins > http://csperkins.org/ > >
