After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 702652 - rtspconnection: tunneled connections do not work
rtspconnection: tunneled connections do not work
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.1.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-06-19 12:47 UTC by Branko Subasic
Modified: 2013-06-24 07:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

One possible solution (1.16 KB, patch)
2013-06-20 09:51 UTC, Branko Subasic
none Details | Review

Description Branko Subasic 2013-06-19 12:47:04 UTC
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?
Comment 1 Branko Subasic 2013-06-20 09:51:53 UTC
Created attachment 247304 [details] [review]
One possible solution

This patch mimics the behavior from before the child sources were introduced.
In the write dispatcher a check is made whether there is any initial request data present in the connection, and if so it simply calls the read dispatcher.

This is probably not the best solution, but it works.
Comment 2 Wim Taymans 2013-06-21 09:53:39 UTC
I did something similar in the main dispatch function because the write dispatch is now only called when something to write is pending. Does this work for you too?

commit bcc5ac52986fa2f8af9741cf56b6e450e62e6243
Author: Wim Taymans <>
Date:   Fri Jun 21 11:50:33 2013 +0200

    rtsp: dispatch when initial buffer has data
    When we have data in the inital buffer, dispath the read function to read it
    even if the socket has no data to read.
Comment 3 Branko Subasic 2013-06-24 07:48:47 UTC
(In reply to comment #2)
> I did something similar in the main dispatch function because the write
> dispatch is now only called when something to write is pending. Does this work
> for you too?

Yes, it works just fine.