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/
