Hi Tom,
My feeling is that there are two ways the signalling could go:
1) Support simple declarative SDP only. This looked to be the approach
you were taking in draft-phelan-dccp-natencap-03, which didn't mention
SDP offer/answer, and was the focus of my earlier comments.
2) Support SDP offer/answer and ICE, in addition to declarative SDP,
to allow tunnelled versus native DCCP to be negotiated for interactive
RTP sessions that traverse NAT devices. The current draft seems to be
moving in this direction, since it talks about offer/answer, hence my
comments.
The first option works with the SDP attribute defined in the current
draft, and fits the spirit of doing the simplest possible thing that
could work. It also fits the likely first deployment scenario, which
is a server with a public IP address, talking to clients behind NAT,
where the client tries both tunnelled and native DCCP. It's not clear
that it works with ICE though.
Colin
On 30 Jun 2010, at 15:36, Phelan, Tom wrote:
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/
