[Bug 736647] New: Tunneled RTSP sessions do not always timeout as expected

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sun Sep 14 12:21:48 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=736647
  GStreamer | gst-rtsp-server | unspecified

           Summary: Tunneled RTSP sessions do not always timeout as
                    expected
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-rtsp-server
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: branko.subasic at axis.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


gst-rtsp-server monitors a clients liveness by requiring it to periodically
send either an RTCP or an RTSP packet. If it does not receive a packet within a
certain period of time (by default 60 seconds) the server destroys the session
and releases resources allocated for that session.

However, currently this mechanics is disabled when RTP is tunneled over RTSP.
The server simply relies on the TCP connection. If it's up the client is
considered being alive. Unfortunately, this way a client with network problem
may drop of without the server noticing.

This problem is easily fixed by using the same liveness monitoring as when UDP
transport is used, i.e. requiring the client to periodically send RTCP or RTSP
packets. I think that would be in line with the RTSP RFC. It's discussed in RFC
2326, section A.2, and in more detail in the RTSP v2 draft, section 10.5.

I will attach a patch which allows the application to choose if RTCP/RTSP
monitoring should be used or not for tunneled sessions. The default behavior is
not to use it, i.e. same as currently. Would something like that be a accepted?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list