dccp@ietf.org
[Top] [All Lists]

Re: [dccp] I-D Action:draft-ietf-dccp-udpencap-01.txt

Subject: Re: [dccp] I-D Action:draft-ietf-dccp-udpencap-01.txt
From: Colin Perkins
Date: Wed, 30 Jun 2010 10:12:31 +0100
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/



<Prev in Thread] Current Thread [Next in Thread>