Hi Christian, Good input -- let me think about it a bit. Tom P. > -----Original Message----- > From: Christian Hoene [mailto:hoene@xxxxxxxxxxxxxxxx] > Sent: Monday, July 05, 2010 3:30 AM > To: Phelan, Tom; 'Colin Perkins'; 'DCCP working group' > Subject: RE: I-D Action:draft-ietf-dccp-udpencap-01.txt > > Hello Tom, > > Some more examples on how to negotiated DCCP-in-UDP in the presence of > NATs would be surely helpful. For at least pointer to drafts and RFCs > which describe how to use them. Just for the bunch of implementers out > here, who might have to use this protocol. > > > Having two protocols (or even more) to select during connection > establishment would surely help to increase the reliability. For example, > try first DCCP, then DCCP-UDP, then TCP - or any other order as negotiated > with SDP. > > With best regards, > > Christian > > > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of Tübingen > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Phelan, Tom > Sent: Wednesday, June 30, 2010 4:37 PM > To: Colin Perkins; DCCP working group > Subject: Re: I-D Action:draft-ietf-dccp-udpencap-01.txt > > Hi Colin, > > Hmm, the SDP is the way it is because I was trying to follow one of your > earlier comments -- I thought not having a way to signal willingness to > do both -STD and -UDP encap was a little problematic, but as I recall > your comments you deliberately wanted it that way. My initial take on > SDP allowed signaling either or both encaps, but you wanted to simplify > things. > > If you'd like to rethink the SDP, by all means do. > > Tom P. > > > -----Original Message----- > > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf > Of > > Colin Perkins > > Sent: Wednesday, June 30, 2010 5:13 AM > > To: DCCP working group > > Subject: Re: I-D Action:draft-ietf-dccp-udpencap-01.txt > > > > On 24 Jun 2010, at 20:15, Internet-Drafts@xxxxxxxx wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the Datagram Congestion Control > > > Protocol Working Group of the IETF. > > > > > > > > > Title : Datagram Congestion Control Protocol (DCCP) > > > Encapsulation in UDP for NAT Traversal (DCCP-UDP) > > > Author(s) : T. Phelan > > > Filename : draft-ietf-dccp-udpencap-01.txt > > > Pages : 11 > > > Date : 2010-06-24 > > > > > > This document specifies an alternative encapsulation of the Datagram > > > Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This > > > encapsulation will allow DCCP to be carried through the current > > > generation of Network Address Translation (NAT) middleboxes without > > > modification of those middleboxes. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-dccp-udpencap-01.txt > > > > > > The encapsulation looks fine to me, but I have some concerns about the > > SDP signalling: > > > > In an SDP offer, how can I signal that I support both native DCCP and > > DCCP-in-UDP? This doesn't seem to be possible using the "a=dccp-in- > > udp" attribute, which "conveys no information about whether or not the > > offerer is listening for DCCP-STD connections". > > > > How do I signal DCCP-in-UDP encapsulation in an ICE exchange? The ICE > > "a=candidate:" lines in SDP use a transport protocol, not an > attribute. > > > > I wonder if it would it make more sense to register transports such as > > DCCP/UDP/RTP/AVP, rather than using an attribute, to try to solve > > these issues? This is possibly something that should be raised in > > MMUSIC. > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > >
