Re: [dccp] FW: New Version Notification for draft-phelan-dccp-natencap-03

[Colin Perkins]

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 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:idsubmiss...@ietf.org]
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/