[Live-devel] RTSP/1.0 Transport parsing conformance questions in LIVE555 2026.07.08

[曹博程]

Dear Ross,
 
Thank you for the clarification about RTSP/2.0 vs RTSP/1.0. I agree that the independent TCP interpretation of "RTP/AVP/TCP" without "interleaved" is RTSP/2.0-specific, so I will not treat that case as a LIVE555 RTSP/1.0 conformance issue.
 
I continued testing RTSP/1.0 Transport header parsing in LIVE555 and found several other cases that seem to be independent of the RTSP/2.0 issue.
 
Tested target:
   LIVE555 Streaming Media version: 2026.07.08
  Commit: 5470e10ecc3e97374d1d73cbaec7a9de727dc77f
  Program: testOnDemandRTSPServer
  URL: rtsp://127.0.0.1:8554/wavAudioTest
All tests were local. I repeated each case 20 times, and the behavior was stable: SETUP returned 200 OK, a Session was created, and a following PLAY also returned 200 OK.
 
1. Empty Transport or missing transport-id still creates a session
  Requests:
    
   Transport:
   Transport: ;unicast;client_port=1234-1235
 
LIVE555 responds with default RTP/UDP parameters:
  Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=0-1;server_port=0-0
 
My reading of RFC 2326 is that Transport must contain at least one transport-spec, and a transport-spec must begin with a transport/protocol/profile identifier.
 
2. Out-of-range interleaved channel values are accepted and truncated
  Requests:
  Transport: RTP/AVP/TCP;unicast;interleaved=256-257
  Transport: RTP/AVP/TCP;unicast;interleaved=999-1000
 
LIVE555 responds with:
  interleaved=0-1
  interleaved=231-232
 
This appears to be caused by casting the parsed values to unsigned char without checking the range.
 
3. unicast and multicast are accepted in the same transport-spec
  Requests:
  Transport: RTP/AVP;unicast;multicast;client_port=1234-1235
  Transport: RTP/AVP/TCP;unicast;multicast;interleaved=0-1
  LIVE555 accepts both and responds using unicast. RFC 2326 describes unicast and multicast as mutually exclusive.
 
4. Multiple comma-separated transport-specs appear to be parsed across spec boundaries
   Request:
   Transport: RTP/AVP;unicast;client_port=1234-1235, FROB/1.0;unicast;client_port=1111-1112


LIVE555 responds with RTP/AVP, but uses the client_port from the later FROB/1.0 spec:
  Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=1111-1112;server_port=6970-6971


Similarly:
  Transport: RTP/AVP;unicast;client_port=1234-1235, RTP/AVP;unicast;client_port=2234-2235
  returns:
  client_port=2234-2235
 
My reading of RFC 2326 is that comma-separated transports are separate options listed in preference order, and the server should return the single option that was actually chosen.


5. Out-of-range client_port values are accepted and truncated
  Requests:
  Transport: RTP/AVP;unicast;client_port=65535-65536
  Transport: RTP/AVP;unicast;client_port=99999-100000
 
LIVE555 responds with:
  client_port=65535-0;server_port=6970-0
  client_port=34463-34464;server_port=6970-6971
 
This seems to be another range-checking issue. I understand that RFC 2326 defines port syntactically as digits, but these values are ultimately UDP/TCP port numbers, so silently wrapping them seems surprising.
 
Could you please confirm whether these are intentional compatibility behaviors, or whether they should be treated as Transport parser bugs?
 
I can provide the exact request/response logs if useful.
 
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/20260709/47e5531d/attachment-0001.htm>