Thanks for your comments, I can reply - but I will need others in the WG
to chime-in on these topics.
On 28/02/2011 10:58, RÃmi Denis-Courmont wrote:
Hello,
One of the DCCP charis asked me to review draft-ietf-dccp-udpencap-06.
So here comes a bunch of comments:
* The SDP support really ought to use a different protocol in the m=field.
This "stuff" is not "DCCP".
I need help from SDP people on this comment - the idea was that this
looked like DCCP to the app.
* An example SDP probably wouldn't hurt.
It would be really good, can someone offer such an example please?
* This specification is relevant not only to NAT(/firewall) traversal, but
also to implementating DCCP within an "application" with support from the
TCP/IP stack. This seems entirely absent.
It has been mentioned in the past, and we could add some text to the
motivation to explain this. Any thoughts from others?
* A proposed integration with the socket API would not hurt either. Then
again, it is true that there is no proposed socket API for DCCP at all in
IETF :-(
Indeed, and I'd assume any DCCP API could describe this. I hope you're
expecting me to say that this should be in another draft.
* I find the two pairs of port numbers objectionable. Inner port numbers
make sense for network-layer tunneling (e.g. Teredo, IPsec over UDP...).
But it is counter-intuitive and needless complicated for transport-layer
encapsulation.
Existing RTP/SDP applications (the main use case for DCCP) have no
provisions for two pairs of port numbers, and two layers of demultiplexing.
This topic was discussed at length on the list, and resulted in the two
approaches outlined. I'm not sure what to add.
(For example, VLC media player parses the SDP m= and c= lines into a
sockaddr, this is impossible with two level of port numbers).
* I don't see much value for a standardized IANA port allocation here. In
fact, it might do more harm than good with some braindead "port-preserving"
NATs: random source port are more likely to work there.
The assigned ports may be important for apps that don't use SDP and need
to communicate with a listening server. I'm guessing that SDP-based apps
may not need this.
Best regards,
Gorry
