[Live-devel] Question about RTSP SETUP without Transport header creating a session in LIVE555

[曹博程]

Hi,
I am testing LIVE555’s RTSP server behavior against RTSP specifications and found a behavior that I would like to confirm with you.


Tested version:
   - Project: LIVE555 Streaming Media
   - Component: testOnDemandRTSPServer
   - Commit: fd17896e0ea37d3bb65ed6c50cc72afcd7d8e8c7
   - Version macros: 2026.06.24
   - Test date: June 29, 2026


I sent a SETUP request without a Transport header:
   SETUP rtsp://127.0.0.1:8554/wavAudioTest RTSP/1.0
   CSeq: 1


LIVE555 returned 200 OK, created a session, and selected transport parameters with zero ports:
   RTSP/1.0 200 OK
   CSeq: 1
   Transport:    RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=0-1;server_port=0-0
   Session: <id>; timeout=65


Using the returned Session, I then sent PLAY, and the server also returned 200 OK:
   PLAY rtsp://127.0.0.1:8554/wavAudioTest RTSP/1.0
   CSeq: 2
   Session: Range: npt=0-


Response:
   RTSP/1.0 200 OK
   CSeq: 2
   Range: npt=0.000-
   Session: <id>
   RTP-Info: url=rtsp://127.0.0.1:8554/wavAudioTest/track1;seq=0;rtptime=0
I repeated this test 5 times, and the behavior was stable.


My understanding is that SETUP requires transport negotiation. In RFC 7826, the Transport header is mandatory for SETUP, and Section 18.54 says that if no transport specification is supported, the server should use 461 Unsupported Transport.
So I wanted to ask:
Is accepting a SETUP request without a Transport header and creating a playable session intended LIVE555 behavior, or should this be considered a protocol conformance bug?
I can provide the full reproduction script and logs if helpful.


Best regards,
Bocheng Cao






 曹博程
213220597 at seu.edu.cn




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