[gst-devel] Is RTSPU implemented in gstreamer? Can I use RTSP over UDP?

[Mauro Brenna]

Hi,

As regards the possibility to transmit RTSP packets over UDP you can
also read in the RFC (2326):

" There is no notion of an RTSP connection; instead, a server maintains
   a session labeled by an identifier. An RTSP session is in no way tied
   to a transport-level connection such as a TCP connection. During an
   RTSP session, an RTSP client may open and close many reliable
   transport connections to the server to issue RTSP requests.
   Alternatively, it may use a connectionless transport protocol such as
   UDP."

So, I am practically convinced you could send also the RTSP commands,
not only the RTP data, via UDP.
Anywat, I don't want to start a post-reply war. I would like only to
understand what it is correct and what it is not. My application is
very specific and I will implement a very very simple RTSP over UDP
protocol.

Now, to answer your question:

- So how do you think it would work? you send the RTSP request over UDP?
Yes, I would do like that. Note the difference between sessionless
commands and commands that refers to a session. You need to mantain a
state for each session, if you would like to stream in unicast to more
than one client, otherwise you can use a single 'instance' of RTSP
server state and refuse to SETUP if a second client asks you so.

- How would you get the reply?
Via UDP, you send the SESSION id in the reply.

- How does the server know where to send the reply to?
I do not understand the question. The server should know specific
parameters via SETUP method. Or simply replies to the IP of the
sender. Which is the difference between UDP and TCP in this case in
your opinion?

- How is this going to work over NAT?
I don't use NAT. In any case when you use SETUP method you explicity
declare the client and server port to enable the firewall to learn
about them. That is what I understood by the RFC:

"A firewall may need to  understand the SETUP method to open a "hole"
for the UDP media stream."

"For the benefit of any
   intervening firewalls, a client must indicate the transport
   parameters even if it has no influence over these parameters, for
   example, where the server advertises a fixed multicast address.

     Since SETUP includes all transport initialization information,
     firewalls and other intermediate network devices (which need this
     information) are spared the more arduous task of parsing the
     DESCRIBE response, which has been reserved for media
     initialization."

This could be a point in favour of TCP:
" Unlike HTTP, RTSP allows the media server to send requests to the
   media client. However, this is only supported for persistent
   connections, as the media server otherwise has no reliable way of
   reaching the client. Also, this is the only way that requests from
   media server to client are likely to traverse firewalls."


- What will happen when the UDP packets get lost, duplicated or reordered?
It is not clearly explained. In any case there is a section dedicated
to reliability:

"9.2 Reliability and Acknowledgements

   Requests are acknowledged by the receiver unless they are sent to a
   multicast group. If there is no acknowledgement, the sender may
   resend the same message after a timeout of one round-trip time (RTT).
   The round-trip time is estimated as in TCP (RFC 1123) [18], with an
   initial round-trip value of 500 ms. An implementation MAY cache the
   last RTT measurement as the initial value for future connections.

   If a reliable transport protocol is used to carry RTSP, requests MUST
   NOT be retransmitted; the RTSP application MUST instead rely on the
   underlying transport to provide reliability."


- What would you do if the RTSP request is too big to fit in the MTU?
It does not happen in my case. If possible, you simply constraint the
client/server to use at maximum an MTU and send more than one request.
How is it implemented in TCP? Since the ordering is correct, you
simply send the RTSP packet fragmented and the server/client would
recompose it? How can the client/server understand the end of the RTSP
packet?


- What would you do if the reply is too big for the MTU?
Same as above.

- If you manage to get RTSP over UDP working, how and when are you
going to open the TCP connection when
you decide to do RTP over TCP?

I would open a TCP socket for RTP when the client issues a SETUP,
before sending the OK reply.
I would close the TCP connection associated to the UDP RTSP session
number X and ip Y, then the client with session X and ip Y issues the
command TEARDOWN.



I think I had formulated satisfactory answers but the one regarding
the fragmentation.


I'm looking forward to hearing from you your comments,

Mauro