What are some ways to debug incorrect RTSP DESCRIBE responses from RTSP servers

Question

I am writing some software that allows users to view previously recorded videos that are saved on an NVR. The videos can be played by calling on the RTSP server to play a specific file, and information is sent back through a web socket.

However, while the majority of files work, some of the files (about 20% of them), will not play. It seems that the sdpInfo returned from the DESCRIBE response indicates that there is only one track, a G.711A track, not an H264 track.

What are some reasons an RTSP server would return inconsistently incorrect responses for video files, and what can I do to debug this? I can't seem to gain access to the RTSP server itself, so I am stuck debugging this client-side. I have checked the cluster count, the filename, and can even play said footage on a different application. So I highly doubt the files are bad, but that the RTSP is not sending me correct DESCRIBE responses.

I have tried to trick the server by appending video track information to the DESCRIBE response and pipelining it to my video player and to the SETUP request, and as a result I do get packets back in the form of messages to my web worker, but it is a stream of H264-undecodable 534 byte data that seems to be messages for the Audio Worker only, and my Video Worker never gets notified.

Here is a sample DESCRIBE response:

Good (Audio/Video):

RTSP/1.0 200 OK
CSeq: 3
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://192.168.1.199:80//mnt/dvr/2020-07-07/000/dav/07/0/1/320149/07.00.00-07.09.00[R][0@0][0].dav/
Cache-Control: must-revalidate
Content-Length: 527
Content-Type: application/sdp

v=0
o=- 2269126519 2269126519 IN IP4 0.0.0.0
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=0-540.000000
m=video 0 RTP/AVP 98
a=control:trackID=0
a=framerate:25.000000
a=rtpmap:98 H264/90000
a=fmtp:98 profile-id=1;sprop-sps=QgEBAQAAAwAAgAAAAwAAAwC0oAFQIAXxY2lksrZrlxAIAAADAAgAAAMAyfxYlA==;sprop-pps=RAHA4eLwMFFJ;sprop-vps=QAEMAf//AQAAAwAAgAAAAwAAAwC0pQJA
a=recvonly
m=audio 0 RTP/AVP 8
a=control:trackID=1
a=rtpmap:8 PCMA/8000
a=recvonly

Bad (Audio only track):

RTSP/1.0 200 OK
CSeq: 3
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://192.168.1.199:80//mnt/dvr/2020-07-07/000/dav/04/0/1/311166/04.00.00-05.00.00[R][0@0][0].dav/
Cache-Control: must-revalidate
Content-Length: 261
Content-Type: application/sdp

v=0
o=- 2269129531 2269129531 IN IP4 0.0.0.0
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=0-3600.000000
m=audio 0 RTP/AVP 8
a=control:trackID=1
a=rtpmap:8 PCMA/8000
a=recvonly

This is an example of a bad RTSP packet (with line breaks):

$DHAV�-;��Q6�F��X��������������UU�������������������U�����UUUU��U�U
�U��U�U����UU�U��UUU��UUUUU�UUUUU���UUUU�UUUUUU�UUUUU�UU�U����UUU�UU�UUU��
UUUUU������������U����U�U���UUU������U���UU�U����U�����������U�U�U�UUU��UU
UUU�U�UU��UU�UUUU�UUUUUUU�U�UUU�U�UU�UUUU�U��U�U�U��U�U����U�UU��UUU����U�
�U���UUUU�����UU�UUUU�UUUUU�����UU���U�UUU��UUUU�UUUUU����UUUUUUUU�U��UUUU
U��UUU��UUUUUUU�UUUUUUUUU��UUUUU��U�UUU�UUUUUU�UU�����U�������������U�����
��U�����U�U�U�UU�����UU���U�U����UUUU��UUUUUUUUUUU��UUUUUU�UUUUdhav

And a visual example:

Answer 1

In case anyone stumbles across a problem like this, the solution for me was to poll the server and rewind by 1 second until a suitable stream was found. Because this could be a variable amount of time, it could be anything from 1 second to 300 seconds, every second had to be tried.