backformation
commented
1 year ago I think I'm seeing something similar with the Android flavour of TAK: rtsp-simple-server 0.21.6 works and mediamtx 0.22.0 doesn't. (Neither does 0.22.1, 0.22.2, 0.23.8 or 1.0.0.) However, having examined my logs, I'd put the blame on the other foot.
I have two Android phones and a Linux PC all on one network. One phone is running TAK-ICU and broadcasts to the media server on the PC. The other phone is running ATAK and is trying to see the video. All versions tested with the default configuration file, except that I've set "logLevel: debug".) Obviously the re-branding isn't the cause, but it does allow me to have last-known-good and first-known-bad versions installed at the same time.
I don't think TAK ICU's available through the Play store, but I also don't think it is a factor. To judge from the logs, any video source would do because the problem lies at the other end of the chain. I noticed the problem while using ATAK 4.4.0.0. The Play store is offering 4.8.1.27 right now and that does not have the problem. It works fine with mediamtx. Since I happen to have access to a cart-load of old ATAK APKs, I can report that the problem still existed in 4.5.1.12 but disappeared with 4.6.0.1. I also note that a simple gstreamer client does not exhibit the problem:
gst-launch-1.0 playbin uri=rtsp://build4.khtest.local:8554/live/kenAll things considered, my guess would be that the problem is/was in the TAK client and it is fixed in more recent versions. I haven't used WinTAK and I've no idea which version you are using, but it would be worth a look. A brief search suggests that it is currently at "version 4.1.something" but I've no idea if WinTAK version numbers are comparable to ATAK ones. (They ought to bear some resemblance, since I'd hope there was a large shared code-base, but perhaps I'm being naive!)
Comparing the logs for 0.21.6 and 0.22.0 (which I'll post next) I think I can offer a clearer description of my symptoms. You might want to enable "logLevel: debug" yourself and see what your WinTAK is saying. I don't know enough about the RTSP protocol to know if one or other end is being "unforgiving", or enough to write a more helpful bug report for the WinTAK people if that turns out to be our conclusion. I'd appreciate it if someone who knows about RTSP can cast an eye over the logs and comment on that.
aler9
github-actions[bot]
Which version are you using?
v0.22.2
Which operating system are you using?
Describe the issue
WinTAk try to establish the connection, using several SETUP statements, but the server in version v0.22.2 fail to establish communication. @aler9 I can confirm that this is a bug that has been introduced in the last year. using version v0.18.0, I can connect successfully with the same sequence:
Transport: RTP/AVP/UDP;unicast;client_port=16076-16077 // trying to use UDP that is disabled
499 7.813985 192.168.1.150 198.199.70.185 RTSP 216 SETUP rtsp://198.199.70.185:8554/live/Corvo/ RTSP/1.0Transport: RTP/AVP/TCP;unicast;interleaved=0-1500 7.858533 198.199.70.185 192.168.1.150 RTSP 184 Reply: RTSP/1.0 200 OK// switch to TCPstream starts
Describe how to replicate the issue
Connect to a RTSP stream using WinTAK (any version)
Did you attach the server logs?
yes in the server logs �[90m2023/05/11 14:06:57 �[0m�[32mINF�[0m [RTSP] [conn 129.222.188.14:59163] opened �[90m2023/05/11 14:06:57 �[0m�[32mINF�[0m [RTSP] [session 2852d870] created by 129.222.188.14:59163 �[90m2023/05/11 14:06:57 �[0m�[32mINF�[0m [RTSP] [conn 129.222.188.14:59163] closed (path has changed, was '/live/Corvo', now is '/live/Corvo/trackID=0')
I was able to connect with a prev. version of mediamtx (Dec 2021)
Did you attach a network dump?
Wireshark request 62 4.126893 192.168.1.150 204.48.30.216 RTSP 220 PLAY rtsp://204.48.30.216:8554/live/Corvo/trackID=0 RTSP/1.0 response 70 4.457005 204.48.30.216 192.168.1.150 RTSP 110 Reply: RTSP/1.0 400 Bad Request
WinTAK2_RTSP_comms.zip
yes