<head></head><body style="line-height: 1.5; font-size: 14px;font-family: Source Han Sans;">
<div style="font-family:Source Han Sans;font-size:14px;line-height:1.5;
" data-mce-style="font-family:Source Han Sans;font-size:14px;line-height:1.5;
"><div>Dear Ross,</div><div> </div><div>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.</div><div> </div><div>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.</div><div> </div><div>Tested target:</div><div><span class="mce-nbsp-wrap" contenteditable="false"> </span>LIVE555 Streaming Media version: 2026.07.08<br> Commit: 5470e10ecc3e97374d1d73cbaec7a9de727dc77f<br> Program: testOnDemandRTSPServer<br> URL: rtsp://127.0.0.1:8554/wavAudioTest</div><div>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.</div><div> </div><div>1. Empty Transport or missing transport-id still creates a session</div><div> Requests:</div><div> <span class="mce-nbsp-wrap" contenteditable="false"> </span></div><div><span class="mce-nbsp-wrap" contenteditable="false"> </span>Transport:</div><div><span class="mce-nbsp-wrap" contenteditable="false"> </span>Transport: ;unicast;client_port=1234-1235</div><div> </div><div>LIVE555 responds with default RTP/UDP parameters:</div><div> Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=0-1;server_port=0-0</div><div> </div><div>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.</div><div> </div><div>2. Out-of-range interleaved channel values are accepted and truncated</div><div> Requests:</div><div> Transport: RTP/AVP/TCP;unicast;interleaved=256-257<br> Transport: RTP/AVP/TCP;unicast;interleaved=999-1000</div><div> </div><div>LIVE555 responds with:</div><div> interleaved=0-1<br> interleaved=231-232</div><div> </div><div>This appears to be caused by casting the parsed values to unsigned char without checking the range.</div><div> </div><div>3. unicast and multicast are accepted in the same transport-spec</div><div> Requests:</div><div> Transport: RTP/AVP;unicast;multicast;client_port=1234-1235<br> Transport: RTP/AVP/TCP;unicast;multicast;interleaved=0-1</div><div> LIVE555 accepts both and responds using unicast. RFC 2326 describes unicast and multicast as mutually exclusive.</div><div> </div><div>4. Multiple comma-separated transport-specs appear to be parsed across spec boundaries</div><div><span class="mce-nbsp-wrap" contenteditable="false"> </span>Request:</div><div><span class="mce-nbsp-wrap" contenteditable="false"> </span>Transport: RTP/AVP;unicast;client_port=1234-1235, FROB/1.0;unicast;client_port=1111-1112</div><div><br data-mce-bogus="1"></div><div>LIVE555 responds with RTP/AVP, but uses the client_port from the later FROB/1.0 spec:</div><div> Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=1111-1112;server_port=6970-6971</div><div><br data-mce-bogus="1"></div><div>Similarly:</div><div> Transport: RTP/AVP;unicast;client_port=1234-1235, RTP/AVP;unicast;client_port=2234-2235</div><div> returns:</div><div> client_port=2234-2235</div><div> </div><div>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.</div><div><br data-mce-bogus="1"></div><div>5. Out-of-range client_port values are accepted and truncated</div><div> Requests:</div><div> Transport: RTP/AVP;unicast;client_port=65535-65536<br> Transport: RTP/AVP;unicast;client_port=99999-100000</div><div> </div><div>LIVE555 responds with:</div><div> client_port=65535-0;server_port=6970-0<br> client_port=34463-34464;server_port=6970-6971</div><div> </div><div>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.</div><div> </div><div>Could you please confirm whether these are intentional compatibility behaviors, or whether they should be treated as Transport parser bugs?</div><div> </div><div>I can provide the exact request/response logs if useful.</div><div> </div><div>Best regards,</div><div>Bocheng Cao</div><span data-mce-type="bookmark" id="mce_1_start" data-mce-style="overflow:hidden;line-height:0px" style="overflow: hidden; line-height: 0px;"></span><br></div><div style="font-family:Source Han Sans;font-size:14px;line-height:1.5;
" data-mce-style="font-family:Source Han Sans;font-size:14px;line-height:1.5;
"><br></div><div style="font-family:Source Han Sans;font-size:14px;line-height:1.5;
" data-mce-style="font-family:Source Han Sans;font-size:14px;line-height:1.5;
"><br></div><div style="font-family:Source Han Sans;font-size:14px;line-height:1.5;
" data-mce-style="font-family:Source Han Sans;font-size:14px;line-height:1.5;
"><br></div><div class="mail-signature"> <div class="lingxi-signature-container" style="font-family: PingFang,Source Han Sans,sans-serif;"> <!-- 样式一，完整版 --> <table style="border-collapse: collapse;width: 100%;text-size-adjust:none !important;table-layout: fixed;" class="mce-item-table"> <tbody style="text-size-adjust:none !important;word-wrap:break-word; word-break:break-all;"> </tbody> </table> <!-- 样式二，无头像 --> <div id="lingxi-signature-v2-block" style="width: 100%;text-decoration: none;text-underline: none;"> <div id="lingxi-signature-v2-content" itemid="id" style="max-width: 95%;font-size: 14px;line-height: 16px;color: #7A8599;padding: 16px 16px 4px 0px;margin-left: 0px;" itemprop="12249884"> <div style="color: #232D47;border: none;margin-bottom:4px;font-size: 16px;line-height: 20px;text-underline: none;font-weight: bolder;white-space:pre;" itemid="name">曹博程</div> <div style="border: none;margin-bottom:8px;text-underline: none;white-space:pre;">213220597@seu.edu.cn</div> </div> </div> <!--办公品牌--> </div></div>
<br><img width="1" height="1" style="display:flex" src="https://tr.qiye.163.com/datacapture/mailreport/v2/0a9f455fcf0709bakunm3bfdf33aa876?zone=hz&to=live-devel@lists.live555.com&tm=1783575589299&sign=04387f1738da6867739bcf3ccc9a6a5e&from=213220597%40seu.edu.cn&mid=AAkAbgCOKpNqqLBvhny0ZapQ&ack=0&toname=live-devel"></body>