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 749596 - rtsp-over-http authentication failure
rtsp-over-http authentication failure
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal normal
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-05-19 19:08 UTC by Jake Foytik
Modified: 2015-12-14 15:44 UTC
See Also:
GNOME target: ---
GNOME version: ---

gst-plugins-base support tunneling auth (21.07 KB, patch)
2015-10-22 15:42 UTC, Evan Callaway
none Details | Review
gst-plugins-good retry tunneling with auth (7.49 KB, patch)
2015-10-22 15:43 UTC, Evan Callaway
none Details | Review
gst-plugins-base support tunneling with auth (8.42 KB, patch)
2015-12-14 14:22 UTC, Evan Callaway
committed Details | Review
gst-plugins-good retry tunneling with auth (6.59 KB, patch)
2015-12-14 14:23 UTC, Evan Callaway
none Details | Review
gst-plugins-good retry tunneling with auth (6.57 KB, patch)
2015-12-14 15:25 UTC, Evan Callaway
committed Details | Review

Description Jake Foytik 2015-05-19 19:08:20 UTC
I am attempting to stream rtsp-over-http from an Axis camera with the following pipeline:

gst-launch-1.0 --gst-debug=*:3 rtspsrc location="rtsph://" user-id=testuser user-pw=pword ! fakesink

This results in the following errors:
ERROR default gstrtspconnection.c:773:setup_tunneling: got failure response 401 Unauthorized
ERROR default gstrtspconnection.c:892:gst_rtsp_connection_connect: failed to setup tunneling
ERROR rtspsrc gstrtspsrc.c:4198:gst_rtsp_conninfo_connect:<rtspsrc0> Could not connect to server. (Generic error)

Further tests:

I am able to properly stream rtsp-over-http with the camera under one of the following conditions:
 - Connect to port 554 instead of 80. (rtsph:// user-id=testuser user-pw=pword)
 - Disable authentication on the camera and stream from port 80. (rtsph://

Does rtspsrc support authentication when setting up the HTTP tunnel?
Comment 1 Evan Callaway 2015-10-19 13:06:47 UTC
I've reproduced this issue and delved into it a bit and it seems that we do not handle authentication during tunneling setup appropriately.  When I add the appropriate Authorization header to the request all goes well, but this may require some slight reworking of things to get the response back from setup_tunneling to know what kinds of authentication are supported.

Currently, rtspsrc calls gst_connection_connect on rtspconnection which in turn calls setup_tunneling if required.  The response to the request in setup tunneling is currently only local in scope, but all of our framework for setting up authentication is in rtspsrc and relies on being able to parse the response.

Here are two viable approaches:

1) Create variations of gst_connection_connect and setup_tunneling that are passed a response pointer in addition to the existing arguments so that a caller can leverage the response to setup authentication and retry the connection.  For compatibility with other code using gst_connection_connect, we can make gst_connection_connect into a wrapper method which maintains the existing function prototype and simply passes the arguments through with an added response pointer to the new method.

2) From rtspsrc, send a dummy request prior to attempting a connection to see if setup_tunneling will require authentication and add it based upon the response to the dummy request as necessary.  From there proceed with connecting as normal.  This does have the benefit of keeping all changes local to rtspsrc.

I am unsure what approach would be preferred.  Please advise as to what strategy you would like to see implemented to resolve this and I would be happy to supply a patch.
Comment 2 Sebastian Dröge (slomo) 2015-10-20 07:27:47 UTC
IMHO 1) sounds better as it will cause one request less in the good cases.
Comment 3 Evan Callaway 2015-10-22 15:42:15 UTC
Created attachment 313869 [details] [review]
gst-plugins-base support tunneling auth

Agreed, #1 is a better solution.

It seems that I can only attach one file at a time(?), so here is the gst-plugins-base patch, which adds allows the caller to retrieve a response that can be inspected to determine if authentication is required and retry with auth as required.  The patch that applies to gst-plugins-good will follow in the next comment.

Note that whitespace on some lines are changed as a result of running the code through GNU Indent with the flags presented on the FAQ (  If you would prefer to have me resubmit these patches without these whitespace changes, please just let me know.

As always, let me know if there is anything in the patch that you would like to see changed.
Comment 4 Evan Callaway 2015-10-22 15:43:09 UTC
Created attachment 313870 [details] [review]
gst-plugins-good retry tunneling with auth

Continued from above.
Comment 5 Sebastian Dröge (slomo) 2015-12-09 09:31:25 UTC
Review of attachment 313869 [details] [review]:

::: gst-libs/gst/rtsp/gstrtspconnection.c
@@ +52,2 @@
+#include <config.h>

Please don't do any whitespace changes :)

@@ +235,3 @@
+        peer_identity,
+        g_tls_connection_get_interaction (conn),

No code-style fixes, unless in a separate patch. But "gst-indent" should actually revert this part here already. Please run gst-indent on .c files :)

@@ +867,3 @@
  * forever. If @timeout contains a valid timeout, this function will return
+ * #GST_RTSP_ETIMEOUT after the timeout expired.  If @conn is set to tunneled,
+ * @response will contain a response to the tunneling request messages.

How would the caller know if it indeed does contain that, or if no tunnelling has happened?

@@ +871,3 @@
  * This function can be cancelled with gst_rtsp_connection_flush().
  * Returns: #GST_RTSP_OK when a connection could be made.

Add a "Since: 1.8" marker here

@@ +1101,3 @@
+ * #GST_RTSP_ETIMEOUT after the timeout expired.
+ *
+ * This function can be cancelled with gst_rtsp_connection_flush().

Maybe add a note to the docs that this function is going to cause problems with tunneling and authentication

@@ +1110,3 @@
+  GstRTSPResult result;
+  GstRTSPMessage *response;
+  response = g_new0 (GstRTSPMessage, 1);

You can allocate this one on the stack like the old function did

@@ +1142,3 @@
   g_snprintf (date_string, len, "%s, %02d %s %04d %02d:%02d:%02d GMT",
+      wkdays[tm.tm_wday], tm.tm_mday, months[tm.tm_mon],
+      tm.tm_year + 1900, tm.tm_hour, tm.tm_min, tm.tm_sec);

This and everything following here is also just code-style / whitespace changes. Please remove them from the patch
Comment 6 Sebastian Dröge (slomo) 2015-12-09 09:36:57 UTC
Review of attachment 313870 [details] [review]:

::: gst/rtsp/gstrtspsrc.c
@@ +4519,3 @@
   GstRTSPResult res;
+  GstRTSPMessage *response = NULL;
+  guint8 retry = 0;

Should this be a gboolean and be initialized to FALSE? You only seem to retry at most once

@@ +4523,1 @@
+  response = g_new0 (GstRTSPMessage, 1);

Why not allocate it on the stack?
Comment 7 Sebastian Dröge (slomo) 2015-12-09 09:39:48 UTC
Instead of all this message dance, could we add a NOT_AUTHORIZED to GstRTSPResult and return that from _connect() instead?
Comment 8 Evan Callaway 2015-12-09 14:19:17 UTC
As I see it, if we return NOT_AUTHORIZED instead of passing around the response, how will rtspsrc know how to do auth?  We need to know whether basic or digest is supported by the server.  If digest is supported we need the nonce and realm provided by the server to continue.
Comment 9 Sebastian Dröge (slomo) 2015-12-09 14:45:40 UTC
Good point, makes sense :)
Comment 10 Evan Callaway 2015-12-14 14:22:19 UTC
Created attachment 317373 [details] [review]
gst-plugins-base support tunneling with auth

Re-uploading this with whitespace changes removed and response declared on stack.
Comment 11 Evan Callaway 2015-12-14 14:23:41 UTC
Created attachment 317374 [details] [review]
gst-plugins-good retry tunneling with auth

Remove whitespace changes.  Declare response on the stack.  Add function prototype instead of moving gst_rtsp_conninfo_close.
Comment 12 Sebastian Dröge (slomo) 2015-12-14 15:02:01 UTC
Comment on attachment 317373 [details] [review]
gst-plugins-base support tunneling with auth

commit 65c7bd7a2ced2c3c82f6bb4663217c9afdb9faad
Author: Evan Callaway <>
Date:   Mon Dec 14 09:10:16 2015 -0500

    rtspconnection: Support authentication during tunneling setup
    gst_rtsp_connection_connect_with_response accepts a response pointer
    which it fills with the response from setup_tunneling if the
    connection is configured to be tunneled.  The motivation for this is to
    allow the caller to inspect the response header to determine if
    additional authentication is required so that the connection can be
    retried with the appropriate authentication headers.
    The function prototype of gst_rtsp_connection_connect has been
    preserved for compatability with existing code and wraps
Comment 13 Sebastian Dröge (slomo) 2015-12-14 15:04:12 UTC
Comment on attachment 317374 [details] [review]
gst-plugins-good retry tunneling with auth

This one does not apply cleanly to GIT master. Can you rebase it? Otherwise looks good to go
Comment 14 Evan Callaway 2015-12-14 15:07:38 UTC
Whoops!  Yes, will do.
Comment 15 Evan Callaway 2015-12-14 15:25:54 UTC
Created attachment 317378 [details] [review]
gst-plugins-good retry tunneling with auth

Alright, this should apply cleanly to master.  Apologies about the mix-up there.
Comment 16 Sebastian Dröge (slomo) 2015-12-14 15:43:33 UTC
commit 4718870959b1bd31633f64934d0f679a3c99d18b
Author: Evan Callaway <>
Date:   Mon Dec 14 09:05:06 2015 -0500

    rtspsrc: Retry connection if tunneling needs authentication
    Leverage response from gst_rtsp_connection_connect_with_response to
    determine if the connection should be retried using authentication.  If
    so, add the appropriate authentication headers based upon the response
    and retry the connection.