GNOME Bugzilla – Bug 751164
rtspsrc does not respect the timeout value in the SETUP reply
Last modified: 2015-06-22 18:04:33 UTC
RFC 2326 12.37 Session This request and response header field identifies an RTSP session started by the media server in a SETUP response and concluded by TEARDOWN on the presentation URL. The session identifier is chosen by the media server (see Section 3.4). Once a client receives a Session identifier, it MUST return it for any request related to that session. A server does not have to set up a session identifier if it has other means of identifying a session, such as dynamically generated URLs. Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ] The timeout parameter is only allowed in a response header. The server uses it to indicate to the client how long the server is prepared to wait between RTSP commands before closing the session due to lack of activity (see Section A). The timeout is measured in seconds, with a default of 60 seconds (1 minute). So when the RTSP server returns: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;multicast;destination=239.1.158.234;port=44078-44079;mode="PLAY" Server: 0060e057bc25 Session: yzkpnxtlxwrtbgne;timeout=30 Date: Thu, 18 Jun 2015 16:55:01 +0200 it should send keep-alives every 30*0.9 seconds (90% of timeout to be sure). rtspsrc states: 0:00:00.037728263 24517 0x1f840f0 DEBUG rtspsrc gstrtspsrc.c:4942:gst_rtspsrc_loop_udp:<source> doing receive with timeout 54 seconds (still the default 60 seconds).
Related this commit: commit 18c610eddaff068e57bbe0f8dc7e268becb1bba6 Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Jun 22 19:51:32 2015 +0200 rtspconnection: Only drop everything after the ; of a session header in requests For responses it is actually allowed and used to signal the timeout to the client! https://bugzilla.gnome.org/show_bug.cgi?id=736267
For UDP this should already do the right thing now, for TCP (interleaved) it always uses whatever was configured on the tcp-timeout property. Which IIRC is correct, for TCP the keep-alive shouldn't be done because that's already handled at the TCP level and we use TCP for sending data back and forth anyway.