# Rtspsrc keep-alive behavior with TCP vs. UDP
**URL:** https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433
**Category:** General Discussion
**Created:** [April 6, 2025, 4:47pm UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433 "2025-04-06T16:47:50Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@rajneeshksoni](https://discourse.gstreamer.org/u/rajneeshksoni)
#### Post date: [April 6, 2025, 4:47pm UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/1 "2025-04-06T16:47:50Z")
I’m investigating the keep-alive functionality of the rtspsrc element in GStreamer. Specifically, I’m observing a discrepancy in behavior between UDP and TCP transport.
The rtspsrc element has a property `do-rtsp-keep-alive` that’s intended to periodically send RTSP GET\_PARAMETER requests to maintain the RTSP connection.
This functionality works correctly when receiving data over UDP. However, when receiving data over TCP, the keep-alive mechanism appears to fail.
**Root Cause (as understood):**
Upon examining the GStreamer code, I’ve noticed that gst\_rtspsrc\_send\_keep\_alive() is triggered only when rtspsrc hasn’t received any messages from the server within a specified timeout period.
UDP: This timeout condition is met because RTP data packets are transmitted over a separate connection, allowing the RTSP connection to remain idle.
TCP: In TCP mode, data is received continuously over the same connection, preventing the timeout condition from being met. Consequently, keep-alive requests are never sent.
Questions/Concerns:
- I’d like to understand the reason for different behavior between TCP and UDP in the rtspsrc plugin.
- Some RTSP servers (e.g., cameras) require keep-alive requests even when using TCP, or they will terminate the RTSP connection, so keep-alive is required for some cases.
- While the get-parameters action signal can be used as a workaround, it’s not a viable solution for gst-launch based pipelines.
Would modifying the rtspsrc plugin to send keep-alive requests for TCP streams be an acceptable solution for the GStreamer community?
I noted that GStreamer 1.16 exhibited different behavior, sending keep-alive requests even for TCP streams. Why was this changed?
---
### Author:  [@slomo](https://discourse.gstreamer.org/u/slomo)
#### Post date: [April 7, 2025, 6:07am UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/2 "2025-04-07T06:07:01Z")
> [@rajneeshksoni](#):
>
> I noted that GStreamer 1.16 exhibited different behavior, sending keep-alive requests even for TCP streams. Why was this changed?
That doesn’t sound like an intentional change. Can you maybe `git bisect` it, or at least check between which major release (1.16, 1.18, 1.20, …, 1.26) this changed?
Also this should really be tracked in a gitlab issue.
---
### Author:  [@rajneeshksoni](https://discourse.gstreamer.org/u/rajneeshksoni)
#### Post date: [April 7, 2025, 2:39pm UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/3 "2025-04-07T14:39:59Z")
This behaviour changed started with - 1.17.1
This `keep-alive` was removed with -
[https://bugzilla.gnome.org/show\_bug.cgi?id=744209](https://bugzilla.gnome.org/show_bug.cgi?id=744209)
---
### Author:  [@slomo](https://discourse.gstreamer.org/u/slomo)
#### Post date: [April 7, 2025, 4:30pm UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/4 "2025-04-07T16:30:08Z")
That bugzilla ticket is moved to [rtspsrc: May stop sending keep alive due to buggy timeout in rtspconnection (#159) · Issues · GStreamer / gst-plugins-good · GitLab](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/159) and no changes related to it were merged AFAICS.
---
### Author:  [@rajneeshksoni](https://discourse.gstreamer.org/u/rajneeshksoni)
#### Post date: [April 7, 2025, 5:11pm UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/5 "2025-04-07T17:11:48Z")
This commit removed the keep-alive -
>
>
> The rtsp connection code has been fixed now.
>
> https://bugzilla.gnome.org/show\_bu…g.cgi?id=744209
---
### Author:  [@rajneeshksoni](https://discourse.gstreamer.org/u/rajneeshksoni)
#### Post date: [April 8, 2025, 4:59am UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/6 "2025-04-08T04:59:57Z")
I believe the keep-alive was removed because of ONVIF specification about `keep-alive`
> **[ONVIF-Streaming-Spec.pdf](https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf)**
>
> 464.49 KB
```auto
5.2.2.2 Timeout and keep-alive handling
• A server shall interpret any RTSP request other than TEARDOWN as a keep-alive.
• A server shall interpret any RTCP receiver report for a unicast stream as keep-alive for the RTSP
session.
```
Still some camera may not follow specification.
---
### Author:  [@tasnimbin](https://discourse.gstreamer.org/u/tasnimbin)
#### Post date: [January 2, 2026, 10:25am UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/7 "2026-01-02T10:25:01Z")
Hi, I came across a similar problem for TCP in gstreamer 1.26. Setting do-rtsp-keep-alive does not prevent connection termination from the server side. Apart from patching the rtspsrc, is there any other way keep the connection alive? I previously used gstreamer 1.18 and the connection worked there.
Note: I am new at this and the gstrtspsrc.c code seems to be changed a lot since the PR @rajneeshksoni mentioned. So, did not try patching (would like pointers on how to do that if its the only way).
---
### Author:  [@rajneeshksoni](https://discourse.gstreamer.org/u/rajneeshksoni)
#### Post date: [January 2, 2026, 12:48pm UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/8 "2026-01-02T12:48:30Z")
> [@tasnimbin](#):
>
> Note: I am new at this and the gstrtspsrc.c code seems to be changed a lot since the PR @rajneeshksoni mentioned. So, did not try patching (would like pointers on how to do that if its the only way).
if you are not using gst-launch, you can use the [get-parameter](https://gstreamer.freedesktop.org/documentation/rtsp/rtspsrc.html?gi-language=c#rtspsrc::get-parameter) to periodically send OPTION from application.
---
### Author:  [@tasnimbin](https://discourse.gstreamer.org/u/tasnimbin)
#### Post date: [January 5, 2026, 4:41am UTC](https://discourse.gstreamer.org/t/rtspsrc-keep-alive-behavior-with-tcp-vs-udp/4433/9 "2026-01-05T04:41:37Z")
> [@rajneeshksoni](#):
>
> if you are not using gst-launch, you can use the [get-parameter](https://gstreamer.freedesktop.org/documentation/rtsp/rtspsrc.html?gi-language=c#rtspsrc::get-parameter) to periodically send OPTION from application.
Thanks for the reply. Problem is, the server I am working with does not support GET\_PARAMETER. So, Gstreamer does send the command saying:
Line 61585: 0:00:31.671108100 20412 0000021E466E68C0 DEBUG rtspsrc gstrtspsrc.c:6861:gst\_rtspsrc\_loop\_send\_cmd: sending cmd GET\_PARAMETER
Line 61595: 0:00:31.671262200 20412 0000021E3C1DEAD0 DEBUG GST\_BUS gstbus.c:839:gst\_bus\_source\_dispatch:\ source 0000021E3B62CAB0 calling dispatch with progress message: 0000021E469111F0, time 99:99:99.999999999, seq-num 170, element ‘rtspsrc0’, GstMessageProgress, type=(GstProgressType)start, code=(string)request, text=(string)“Sending\ GET\_PARAMETER\ request”, percent=(int)0, timeout=(int)-1;
Line 61612: 0:00:31.671681100 20412 0000021E466EDE50 DEBUG rtspsrc gstrtspsrc.c:6880:gst\_rtspsrc\_loop\_send\_cmd: ignore, we have a pending GET\_PARAMETER
Line 61616: 0:00:31.672544100 20412 0000021E466EDE50 DEBUG rtspsrc gstrtspsrc.c:10298:gst\_rtspsrc\_thread: got command GET\_PARAMETER
Line 61619: 0:00:31.672732100 20412 0000021E466EDE50 DEBUG rtspsrc gstrtspsrc.c:10691:gst\_rtspsrc\_get\_parameter: creating server get\_parameter
Line 61620: 0:00:31.672793400 20412 0000021E466EDE50 DEBUG rtspsrc gstrtspsrc.c:10765:gst\_rtspsrc\_get\_parameter: GET\_PARAMETER is not supported