Hi,
There has been a lot of talk in this thread about DNS. I want a solution
that works without DNS. If one uses SIP or RTSP to establish a media pat
using DCCP. In most cases one do include the explicit IP address rather
than the FQDN. Thus no DNS queries etc. I think something that makes
Hi,
one question we really need to answer is whether we want to go through
the pains of specifying UDP encapsulations for all our transport
protocols. We have on the table:
* draft-phelan-dccp-natencap for DCCP
* draft-tuexen-sctp-udp-encaps for SCTP
* JDR's recent
I've uploaded a draft agenda at:
https://datatracker.ietf.org/meeting/71/materials.html
If you are listed as a presenter and have not yet contacted the Chairs -
please email us as soon as possible:-)
If you have slides ready, then please do send them. (Please send by noon
Monday 10th at the
I have submitted a revised version of
draft-ietf-dccp-rfc3448bis-05.txt.
The changes from -04 are as follows:
* Added a mechanism for decaying the value in X_recv_set
following a loss event in a data-limited interval, and
restricting recv_limit to max (X_recv_set) for the next
Gorry, comments on service-codes-04.
The original draft of the DCCP specification did not use traditional
ports; instead the client allocated a 32-bit identifier to uniquely
identify the connection. ... This design
suffered from the downside of being sufficiently different from
Hi Lars,
I sympathize with your concern for each transport inventing its own UDP
encap solution. However, I don't think that that
IP/UDP/IP/DCCP[SCTP][whatever] works well. What is in the inner IP
addresses? They're not useful at all. They could start out the same as
the outer addresses, but
