Subject: Re: Re : RTSP

From: Adrien de Croy <[email-masked]>
Date: Fri, 18 Oct 1996 03:57:12 +1300

Hi all, hope you don't mind me butting in on this conversation.

At 11:39 17/10/96 +0100, you wrote:
>
>>i suggest RTSP has two mappings for control messages, one for TCP for
>>"media on demand" model usage, and one for UDP, for paricipation of a
>>storage/replay system in a multiway interactive scenario....
>
>I was starting to think along similar lines.  For most control
>functionality, you require application level acknowledgements anyway -
>you can't just assume that because you put a message into a TCP
>connection that it has been acted upon yet.
>
>Defining an RTSP so that it can work over UDP should be perfectly
>feasible.  It should allow better control responses and the ability to
>not care if some mesages get through or not (eg. UDP-resend if you
>really need that functionality).  But there are also pragmatic reasons
>why working over TCP is desirable (mostly to do with firewalls).

There is a very strong reason why you should seriously consider the
implications before rejecting a TCP-based control protocol.

The SOCKS5 protocol (RFC1928) which is in common use now for access through
firewalls, has UDP support, but only at a limited level.  You can only
initiate UDP communications from the client side.  There is no mechanism for
a client to access the socket information  of a UDP socket on the outside of
a SOCKS5 firewall - only the inside. (e.g no UDP "BIND" command). 

this means that a client cannot start listening on a UDP socket on the
outside of a SOCKS5 firewall for packets coming back to it from a server,
because it cannot learn the port number of the socket the firewall creates
for it on the outside (only the socket on the inside).  The UDP support only
lets you start sending UDP packets to specified host:port by a relay
mechanism (with a reduced payload size too I might add).  Returning packets
are relayed back and may also be fragmented by the firewall - this is
because the firewall must attach another header to the UDP packet, and if it
was already at the maximum size (i.e 512 bytes) then you get frags. Some
SOCKS5 firewalls do not support fragmentation, and will drop the packets.

However, SOCKS5 does give you the socket information of sockets it creates
for you for TCP connections.

I guess maybe I should be talking to NEC about their poked protocol.

This raises another issue.  Most streaming clients I have seen create a UDP
socket for data, and send the server the socket info over a TCP control
channel, so the server can start sending data back to the client on it.
This cannot happen through a SOCKS5 firewall, unless you allow a mechanism
like the following:

* client connects through SOCKS to server on TCP
* server sends address and port of UDP data socket, along with a unique ID
number
* client connects to SOCKS server and sends UDP ASSOCIATE command, then
sends this unique ID number to the server over the UDP relay
* server then knows that the client is the same one (normally can also match
IP addresses) that made the request, and has the socket info from the packet
headers to send data back to the client, which is relayed back to it.

this way the client does not need to know the socket information of the UDP
socket on the firewall.

maybe this will tip some scales?

>
>So it seems to me like we should design an RTS(control)P so that it
>works over UDP (ie, has appropriate application-level acknowledgements
>and each message is sufficiently idempotent), but is unambiguously
>framed so it can also work over TCP too.
>
>#include <wg-chair-hat>
>Right now we're arguing in circles, and this isn't helping solve the
>problem.  We've been in this situation before with SIP/SCIP and didn't
>reach concensus.  It's beginning to look like the solution there is to
>do the same thing.
>
>Mark
>
-------------------------------------------------------------------------------
Adrien de Croy - [email-masked].  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------