diff --git a/docs/2-usage/02-publish.md b/docs/2-usage/02-publish.md
index da318f28..cc9a2a7a 100644
--- a/docs/2-usage/02-publish.md
+++ b/docs/2-usage/02-publish.md
@@ -524,6 +524,8 @@ d.video_0 ! rtspclientsink location=rtsp://localhost:8554/mystream
 
 The resulting stream is available in path `/mystream`.
 
+For advanced options, see [RTSP-specific features](rtsp-specific-features).
+
 #### GStreamer and RTMP
 
 ```sh
@@ -540,6 +542,8 @@ videotestsrc ! video/x-raw,width=1280,height=720,format=I420 ! x264enc speed-pre
 audiotestsrc ! audioconvert ! avenc_aac ! mux.
 ```
 
+For advanced options, see [RTSP-specific features](rtsp-specific-features).
+
 #### GStreamer and WebRTC
 
 Make sure that GStreamer version is at least 1.22, and that if the codec is H264, the profile is baseline. Use the `whipclientsink` element:
diff --git a/docs/2-usage/03-read.md b/docs/2-usage/03-read.md
index 61be0d54..f7a91a29 100644
--- a/docs/2-usage/03-read.md
+++ b/docs/2-usage/03-read.md
@@ -207,6 +207,8 @@ GStreamer can read a stream from the server in several way. The recommended one
 gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/mystream latency=0 ! decodebin ! autovideosink
 ```
 
+For advanced options, see [RTSP-specific features](rtsp-specific-features).
+
 #### GStreamer and WebRTC
 
 GStreamer also supports reading streams with WebRTC/WHEP, although track codecs must be specified in advance through the `video-caps` and `audio-caps` parameters. Furthermore, if audio is not present, `audio-caps` must be set anyway and must point to a PCMU codec. For instance, the command for reading a video-only H264 stream is:
diff --git a/docs/2-usage/24-rtsp-specific-features.md b/docs/2-usage/24-rtsp-specific-features.md
index 03f0767b..e453b852 100644
--- a/docs/2-usage/24-rtsp-specific-features.md
+++ b/docs/2-usage/24-rtsp-specific-features.md
@@ -12,12 +12,18 @@ The RTSP protocol supports several underlying transport protocols, that are chos
 
 To change the transport protocol, you have to tune the configuration of the client you are using to publish or read streams. In most clients, the default transport protocol is UDP.
 
-For instance, FFmpeg allows to change the transport protocol with the `-rtsp_transport` flag:
+FFmpeg allows to change the transport protocol with the `-rtsp_transport` flag:
 
 ```sh
 ffmpeg -rtsp_transport tcp -i rtsp://localhost:8554/mystream -c copy output.mp4
 ```
 
+Available options are:
+
+- `-rtsp_transport tcp` to pick the TCP transport protocol
+- `-rtsp_transport udp` to pick the UDP transport protocol
+- `-rtsp_transport udp_multicast` to pick the UDP-multicast transport protocol
+
 GStreamer allows to change the transport protocol with the `protocols` property of `rtspsrc` and `rtspclientsink`:
 
 ```sh
@@ -25,6 +31,12 @@ gst-launch-1.0 filesrc location=file.mp4 ! qtdemux name=d \
 d.video_0 ! rtspclientsink location=rtsp://localhost:8554/mystream protocols=tcp
 ```
 
+Available options are:
+
+- `protocols=tcp` to pick the TCP transport protocol
+- `protocols=udp` to pick the UDP transport protocol
+- `protocols=udp-mcast` to pick the UDP-multicast transport protocol
+
 VLC allows to use the TCP transport protocol through the `--rtsp_tcp` flag:
 
 ```sh
diff --git a/docs/4-other/3-security.md b/docs/4-other/3-security.md
index 443565a8..dd335a6b 100644
--- a/docs/4-other/3-security.md
+++ b/docs/4-other/3-security.md
@@ -2,15 +2,13 @@
 
 ## Security of released binaries
 
-Binaries published in the [Releases](https://github.com/bluenviron/mediamtx/releases) section of GitHub are the output of a process which has been designed with a security-first approach. Every step from source code to the intended final destination of binaries is fully visible, immune from external interference and can be independently verified.
-
-This is the process:
+Binaries published in the [Releases](https://github.com/bluenviron/mediamtx/releases) section of GitHub are the output of a process which has been designed with a security-first approach. Every step from source code to the intended final destination of binaries is fully visible, immune from external interferences and independently verifiable. This is the process:
 
 1. During every release, the [Release workflow](https://github.com/bluenviron/mediamtx/actions/workflows/release.yml) is triggered on GitHub.
 
 2. The release workflow pulls the source code and builds binaries.
 
-3. The release workflow computes SHA256 checksums of binaries and publishes them on the Sigstore Public Good Instance through [GitHub Attestations](https://docs.github.com/en/actions/concepts/security/artifact-attestations).
+3. The release workflow computes SHA256 checksums of binaries and publishes them to the Sigstore Public Good Instance through [GitHub Attestations](https://docs.github.com/en/actions/concepts/security/artifact-attestations).
 
 4. Checksums and binaries are published on the Release page.