[Bug 702652] New: rtspconnection: tunneled connections do not work

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=702652
  GStreamer | gst-plugins-base | git

           Summary: rtspconnection: tunneled connections do not work
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: branko.subasic at axis.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


When tunneling RTSP over HTTP a socket is transfered from the web server to the
RTSP server. The RTSP server will create a GstRTSPConnection using this socket,
put in a GstRTSPWatch, which it will attach to a suitable context. However,
since polling child sources were introduced tunneling has been broken. A client
that wants to connect over HTTP will not get an RTSP reply and will time out.

When the socket is transferred by the web server it will have read the data
(i.e. the RTSP request), and it will be saved in the GstRTSPConnection's 
'initial_buffer' member when the GstRTSPConnection is created. Before these
changes were made the same GSource was used to poll if the source was writable
as well as if it was readable. The same dispatcher function, 
gst_rtsp_source_dispatch, was called in both cases. That function checked if
'initial_buffer' was non-NULL and, if so, called 'watch->funcs.tunnel_start()'
to initiate the tunneling and replied to the client. Since that function was
called when the source was writable as well as when it was readable, the tunnel
was always started. 

But now we use separate child sources for reading and writing, with separate
dispatch functions, and the checking of whether the 'initial_buffer' variable
is non-NULL, and thus the starting of the tunnel, is only done in he read
dispatcher, gst_rtsp_source_dispatch_read(). But the client waits for our
response, and there will be nothing to read until it gets it and makes another
request. Thus we will never reply.

I have tried to find a solution, but have not managed to come up with a nice
one. One obvious thing to test was to check for 'watch->conn->initial_buffer !=
NULL' in the write dispatcher, gst_rtsp_source_dispatch_write(), and, if so,
call gst_rtsp_source_dispatch_read(). That solves the problem, but it seems a
bit ugly to me. Ideally the read and write dispatcher functions should not
depend on each other. It also adds one more statement to the write dispatcher,
which is called a lot.

I think that ideally the reply should be constructed (and sent?) before the 
watch is attached to the context, if that's possible. At a stage where we know
that it's a tunnel, that there's request data remaining to be parsed, and
replied to. So, any ideas?

-- 
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.