Stop SAVP Forcing In Gortsplib TLS Tunnels: AVP Control

Hey there, RTSP and streaming enthusiasts! Let's dive deep into a really interesting, and frankly, a bit tricky situation that some of you might have encountered when working with the awesome gortsplib library, especially when it comes to TLS tunneling scenarios. You see, when you're setting up a robust RTSP server, ensuring that your session description is spot-on is absolutely crucial for smooth media playback. We're talking about the Session Description Protocol (SDP), which essentially tells the client all the nitty-gritty details about the media streams—what codecs are used, the transport protocols, and so much more. Typically, for standard RTSP streaming, we use the Audio/Video Profile (AVP), which is the default and pretty much universally understood profile for non-secure media transport. However, things get a tad complicated when you introduce security into the mix, specifically using TLS to encrypt your communication. The gortsplib library, a fantastic piece of engineering for RTSP servers and clients written in Go, has a particular behavior around TLS configuration that can lead to some head-scratching moments, especially for those leveraging TLS for tunneling rather than direct SRTP encryption. The core issue we're tackling today revolves around the library's tendency to automatically modify the session description to use Secure Audio/Video Profile (SAVP) whenever a Server.TLSConfig is enabled, even if the actual media transport underneath is still TCP and not Secure Real-time Transport Protocol (SRTP). This automatic change, while well-intentioned for direct SRTP usage, can create a serious disconnect when clients are expecting a plain AVP profile in an encrypted tunnel, causing compatibility headaches and frustrating debugging sessions. We're going to break down why this happens, why it's problematic in specific TLS tunneling contexts, and what solutions we can explore to give developers more control over their SDP profiles.

The Core Problem: TLSConfig and Forced SAVP in gortsplib

Alright, guys, let's get right into the heart of the matter. When you're building an RTSP server with gortsplib and you want to add a layer of security using TLS, you'll naturally set up the Server.TLSConfig property. This is awesome because it encrypts your RTSP control plane, making sure that commands like DESCRIBE, SETUP, PLAY, and PAUSE are all transmitted securely. But here's the kicker: as soon as that Server.TLSConfig is enabled, the library, specifically within its prepareForDescribe function, takes it upon itself to automatically modify the session description (the SDP data) that it sends back to the client. Instead of sticking with the standard Audio/Video Profile (AVP), which is typically used when media streams are transported over plain UDP or TCP, gortsplib switches the profile to Secure Audio/Video Profile (SAVP). Now, on the surface, this might seem like a perfectly reasonable thing to do. If you're using TLS, shouldn't everything be secure? And SAVP is indeed the profile designed for secure media transport, primarily in conjunction with SRTP (Secure Real-time Transport Protocol), which encrypts and authenticates the actual media packets. The SAVP profile, specified in RFC 4568, indicates that the media stream itself is protected using SRTP, often negotiated via DTLS-SRTP for key exchange. So, if you were building a system where your media was going to be transported via SRTP, this automatic modification would be exactly what you want. The server would correctly advertise that the media is secure, and the client would know to expect SRTP packets. However, the world of RTSP and TLS isn't always so straightforward, and there are specific architectural patterns where this automatic SAVP forcing becomes a real wrench in the works. It's like buying a car with automatic high beams that turn on even when you're driving in bright daylight—helpful sometimes, but annoying and unneeded in other situations. We need to understand that TLS at the transport layer for the RTSP control channel does not inherently mean that the media payload itself is going to be SRTP. This distinction is critical for understanding why this behavior, while seemingly logical, can lead to significant interoperability challenges in certain network setups, particularly in the realm of TLS tunneling, which we'll explore next.

Understanding TLS Tunneling Scenarios

Let's clear something up, folks: TLS is a super versatile protocol, and not all TLS deployments are created equal, especially in the context of RTSP streaming. When we talk about TLS tunneling scenarios, we're referring to a very specific setup where TLS is used to create an encrypted tunnel over the network, primarily for the entire communication channel, but the content inside that tunnel might not necessarily be SRTP. Imagine this: you have an RTSP client and an RTSP server that need to communicate securely across an insecure network, perhaps through a firewall or a proxy. Instead of directly exposing the RTSP and media ports, you might wrap the entire RTSP communication—both the control messages and the media data—within a TLS tunnel. This means the transport layer connection itself is encrypted with TLS. The RTSP SETUP request, for instance, might specify TCP as the transport for the media, not RTP/SAVP/TLS or RTP/AVP/UDP. In such a scenario, the data flowing through this TLS-encrypted pipe is still, from an RTSP perspective, plain old RTP over TCP. The encryption is happening at a lower layer, courtesy of the TLS tunnel, effectively obscuring the entire RTSP stream from eavesdroppers. The RTSP messages themselves might still specify RTP/AVP/TCP, because the media inside the tunnel is not using SRTP for its own encryption; it's relying on the tunnel's encryption. Think of it like putting a regular, unencrypted letter inside a securely locked briefcase. The letter itself isn't encrypted, but the briefcase makes sure no one can read it during transit. The problem arises when gortsplib's server, upon seeing Server.TLSConfig, forces the session description to SAVP. The client, on the other hand, is blissfully unaware of SRTP at the application layer. It's configured to expect AVP because it knows the TLS tunnel handles the transport-level security. The client is preparing to receive standard RTP over TCP (which is then protected by the TLS tunnel), not SRTP. This fundamental mismatch in expectations regarding the session description profile (AVP vs. SAVP) leads directly to communication failures. The client receives an SDP indicating SAVP and likely aborts the connection because it's not set up to decode SRTP, or it simply doesn't understand why an SAVP profile is advertised when it requested AVP in its SETUP request via TCP transport. This is a classic case of a well-intentioned security feature causing unintended interoperability issues due to different interpretations of