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 789646 - live555 clients get timed out after a while
live555 clients get timed out after a while
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
unspecified
Other Linux
: Normal blocker
: 1.12.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-10-30 09:52 UTC by Sebastian Dröge (slomo)
Modified: 2018-04-18 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2017-10-30 09:52:41 UTC
E.g. try with http://www.live555.com/openRTSP/ and the -t (for TCP) commandline option. Using "-K" prevents this, with UDP the data also seems to be continued to be sent.

About "-K":
> "-K " - Periodically send a RTSP "OPTIONS" command, to keep the connection alive. (This is useful with buggy servers that don't listen to our periodic RTCP "RR" packets instead.)

This only happens if the session cleanup timeout is used, e.g. https://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/examples/test-multicast.c#n25
Comment 1 Sebastian Dröge (slomo) 2017-10-30 09:53:16 UTC
With 1.8 this works fine, if someone wants to bisect
Comment 2 Mikhaylo 2017-12-11 15:14:10 UTC
This bug is listed in release notes of 1.12.4 release https://gstreamer.freedesktop.org/releases/gst-rtsp-server/1.12.4.html 

Is it fixed ?
Comment 3 Sebastian Dröge (slomo) 2017-12-11 16:06:21 UTC
No, it only appears there because it was set with target milestone 1.12.4 but the script is not checking if those bugs are actually closed. Which this one isn't.

Nobody had time to look closer into this bug yet. If it is fixed, then it will be written here and nowhere else.
Comment 4 Tim-Philipp Müller 2018-01-22 18:39:35 UTC
I can't reproduce this with

 gst-rtsp-server/examples/test-uri foo.mp4

Plays for 2.5 minutes over TCP, all the way to the end.
Comment 5 Sebastian Dröge (slomo) 2018-01-23 08:24:37 UTC
I can also reproduce it with test-uri here still. The files stops being written after about 1 minute.
Comment 6 Edward Hervey 2018-02-21 16:50:32 UTC
I would just like to confirm that the issue is the following:
* "When a RTSP client connects and negotiates a TCP lower-layer connection, the rtsp-server ends up timing out and disconnecting the client _even if_ the lower layer TCP connection is still up"
* If other mechanisms are used (such as periodically sending commands or RR RTCP packets) then the connection will _not_ be timed out.

correct ?
Comment 7 Sebastian Dröge (slomo) 2018-02-26 11:14:34 UTC
> * "When a RTSP client connects and negotiates a TCP lower-layer connection, the rtsp-server ends up timing out and disconnecting the client _even if_ the lower layer TCP connection is still up"

Even if the RTSP client is sending RTCP packets over the TCP connection.

> * If other mechanisms are used (such as periodically sending commands or RR RTCP packets) then the connection will _not_ be timed out.

Commands works fine, RTCP not (see above). Using media transport over UDP will close the TCP connection too, but media continues to be sent (but this seems fine).
Comment 8 Sebastian Dröge (slomo) 2018-02-28 19:18:36 UTC
This can't have never worked before. I assume it only worked in 1.8 because we failed to time-out clients due to a bug that was fixed since then.


commit 0dc617058203acae4db137621ee7ac388dd9eb30 (HEAD -> master)
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Wed Feb 28 21:12:43 2018 +0200

    rtsp-client: Place netaddress meta on packets received via TCP
    
    This allows us to later map signals from rtpbin/rtpsource back to the
    corresponding stream transport, and allows to do keep-alive based on
    RTCP packets in case of TCP media transport.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=789646
Comment 9 Mikhaylo 2018-04-18 11:25:11 UTC
The problem is still actual in 1.14.0 release for RTSP-over-HTTP tunneling. I created a new defect: https://bugzilla.gnome.org/show_bug.cgi?id=795354