[Live-devel] Possible RTSP version handling issue in LIVE555: RTSP/2.0 request receives RTSP/1.0 200 OK

[曹博程]

Hello LIVE555 developers,
I would like to ask whether the following RTSP version handling behavior in LIVE555 is intended.
My test setup uses the ProfuzzBench RTSP/Live555 subject as the benchmark harness, but the actual tested implementation was updated to the upstream LIVE555 latest version before verification.


Tested target:
   LIVE555 Streaming Media
   Program: testProgs/testOnDemandRTSPServer
   Version: 2026.06.24
   Commit: fd17896e0ea37d3bb65ed6c50cc72afcd7d8e8c7
   The server was started locally on 127.0.0.1:8554. I sent the following RTSP/2.0 requests.


Probe 1:
   OPTIONS * RTSP/2.0
   CSeq: 1
Observed result, 5/5 runs:
    RTSP/1.0 200 OK


Probe 2:
   SETUP rtsp://127.0.0.1:8554/wavAudioTest RTSP/2.0
   CSeq: 1
   Transport: RTP/AVP;unicast;client_port=1234-1235
Observed result, 5/5 runs:
   RTSP/1.0 200 OK


My understanding of RFC 7826 is that, for an RTSP/2.0 request, a server that supports RTSP/2.0 should return an RTSP/2.0 response, while a server that does not support or refuses that major version should reject it with:
   505 RTSP Version Not Supported
However, LIVE555 returns a successful RTSP/1.0 response to the RTSP/2.0 request. This appears to be a protocol version handling inconsistency, and may cause interoperability issues or client-side state confusion for RTSP/2.0 clients.


Could you please confirm whether this behavior is intended? If it is unintended, I can provide the minimized reproducer and full response logs.


Best regards,
Bocheng Cao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20260626/c24cd5a1/attachment.htm>