When splicing RTSP addresses, the case where the attribute control is trackid = 0 in the returned information is not considered, as shown in the figure

[liumaopeng]

ErrorMessage：
022/04/19 12:02:14 RTSP/1.0 200 OK
CSeq: 2
Cache-Control: must-revalidate
Content-Base: rtsp://10.105.240.22:9100/dss/monitor/param/cameraid=1000193%241%26substream=1?token=69154&trackID=0
Content-Length: 481
Content-Type: application/sdp
Server: Dahua Rtsp Server/2.0
X-Accept-Dynamic-Rate: 1

v=0
o=- 2281187389 2281187389 IN IP4 0.0.0.0
s=RTSP Session/2.0
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=now-
m=video 0 RTP/AVP 96
a=control:trackID=0
a=framerate:25.000000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640032;sprop-parameter-sets=Z2QAMqwsaoCgAtabgoCCoAAAAwAgAAAGUIA=,aO4xshs=
a=recvonly
m=audio 0 RTP/AVP 8
a=control:trackID=1
a=rtpmap:8 PCMA/8000
a=recvonly

2022/04/19 12:02:14 Setup:rtsp://10.105.240.22:9100/dss/monitor/param/cameraid=1000193%25241%2526substream=1%3Ftoken=69154?token=69154/trackID=0 error:invalid transport header: encoding/hex: invalid byte: U+0020 ' '

[aler9]

Hello, i understand that there's a SETUP issue and we can work around that, but the control attribute is indeed considered by Track.URL. As you can see here:

rtsp://10.105.240.22:9100/dss/monitor/param/cameraid=1000193%25241%2526substream=1%3Ftoken=69154?token=69154/trackID=0

The control attribute (trackID=0) is appended to the URL - what is missing is the final part of the query:

&trackID=0

Please post a network dump, that can be generated in this way:

1. Download wireshark (https://www.wireshark.org/)
2. Start capturing on the interface used for exchanging RTSP (if the server and the target software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card)
3. Start the server and replicate the issue
4. Stop capturing, save the result in .pcap format
5. Attach

[liumaopeng]

Hello, the following is my packet capture data, which is the communication between 10.105.243.19 and 10.105.240.22

data.zip

[aler9]

Thanks for the dump, that problem wasn't related to the control attribute, but to the transport header:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=     D93FF

This transport header couldn't be parsed correctly. Now the bug is fixed. Feel free to open another issue if there are any more problems.

[github-actions]

This issue is being locked automatically because it has been closed for more than 6 months.
Please open a new issue in case you encounter a similar problem.