On 1 Sep 2010, at 09:17, Gorry Fairhurst wrote:
...
- I see the value of the IANA-specified destination port for a
client server app using a NAPT, where the NAPT changes only the
src port as it leaves the client, and does this differently for
each sender address behind the NAPT. What is the expected port
usage at the receiver? Does it listen on the IANA port bound to
any source port? Can you say more here?
[TomP] So section 3.1 says:
Source and Dest(ination) Ports: 16 bits each
These fields identify the UDP ports on which the source and
destination (respectively) of the packet are listening for
incoming DCCP-UDP packets (normally both are the default port
to
be assigned by IANA). Note that they do not identify the DCCP
source and destination ports.
I don't know that I see any necessary changes here, except it
should probably mention that the port values can be changed along
the way by NAPT boxes. You say, "Does it listen on the IANA port
bound to any source port?" I assume by this you mean will it
accept an incoming packet with any source port? Do we need to open
this UDP can of worms?
GF: We don't need to open the can of worms, but it may be wise to
realise that if the intention is to travserse middleboxes that the
ports (in particular the src port from a "client") may be updated by
a middlebox, e.g. NAPT, and therefore a receiver should expect that
one (or both) ports may be different to the IANA assigned value.
Right - the statement that "(normally both are the default port to be
assigned by IANA)" seems unlikely to be true, since the point of this
draft is to traverse middleboxes, which will almost certainly rewrite
the ports to a different value.
On a related topic, Section 5.1 could do with some wording to explain
the (limited) applicability of this new SDP attribute. Specifically,
it's likely only useful if the offering party is on the public
Internet, and not behind a NAT, because otherwise the port it
advertises won't be reachable. The draft should note this, and explain
that bi-directional NAT traversal is for future study.
Also, is the title of Section 5.1 accurate? It's not clear that
anything in the new SDP attribute depends on the RTP-over-DCCP
encapsulation.
Cheers,
Colin
--
Colin Perkins
http://csperkins.org/
