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

[Wim Taymans]

It sounds like you have it plan that could work.

Wim

On Wed, Jan 19, 2011 at 9:59 AM, Mauro Brenna <malloblenne at gmail.com> wrote:
> 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
>
> ------------------------------------------------------------------------------
> 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.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>