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: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/
--
Colin Perkins
http://csperkins.org/
