[gst-devel] Is RTSPU implemented in gstreamer? Can I use RTSP over UDP?
wim.taymans at gmail.com
Wed Jan 19 12:34:28 CET 2011
It sounds like you have it plan that could work.
On Wed, Jan 19, 2011 at 9:59 AM, Mauro Brenna <malloblenne at gmail.com> wrote:
> 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
> 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
> 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
> 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) , 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
> - 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,
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel