How Milestone keep RTSP Stream alive?

Hi,

I’ve attached a Wireshark data below .We can use Milestone to add camera smoothly, also can see the preview , but the TEARDOWN request comes through and stops the stream. As you can see with the screenshot and packages row data below, the streaming is interrupted every 130 seconds.

When I use VLC for RTSP connection, I can clearly see that VLC uses GET_PARAMETER to ensure that the connection is still alive, and that the stream I see is stable.

So I would like to ask how does Milestone ensure that the connection survives?

The attachment is a package of my camera with Milestone

Camera ip location: 192.168.100.156

Use products :

Milestone XProtect Essential 2020 R1

Version : 20.1a

Thanks

May I ask what you are trying to do? What do you want to achieve with SDK? Can you please add some context and elaborate on your question?

We are the IP camera manufacturer, and will integrate the major VMS like Contera, Milestone, Genetec.

For now , we trying to do is play Stream smoothly on Milestone XProtect Essential 2020 R1, but the Video Stream on your VMS always ​interrupted every 130 seconds.

We use VLC player to check our Live555 Streaming, we see VLC use GET_PARAMETER request to ensure the live stream is alive, so on VLC, we won’t see the TEARDOWN request.

So my question is

  1. How to keep stream alive on your VMS?
  2. Is there any key request that we didn’t respond to caused your VMS send a TEARDOWN request?

​​

The Keep-Alive of the RTSP connection is driver dependent. In your case, I see you are using the Arecont driver for this device. This driver will use RTCP to keep-alive the connection when Streaming mode is set to UDP. When it is TCP (as is the case in the Wireshark capture) there is no keep-alive. In the Wireshark capture it can be seen that 163 seconds after starting the stream, the device stops sending packets (probably because of no keep-alive from the driver), then after a 5 second timeout of no data, the Milestone Driver sends TEARDOWN and closes the connection to try again.

Some drivers allow the keep-alive method to be selected by the user. This is the case for the Universal Driver. This can used to experiment which Keep-Alive method is suitable for the specific device.

Note: I see you are using an older version of the Milestone Device Pack - 9.7. I suggest updating to the latest one.

Hi~

Thanks for answer.

But now we have another issue.

After resolve TEARDOWN issue, we start to run Long time test.

When we connect 15 camera on Milestone XProtect Essential 2020 R1 (by Arecont Driver), after run 1 hour, we saw a tiny Record breakpoint ( interval 1~2 sec ) like picture below with Live view flicker.

At same time we pull the log of this camera in VMS, only see the “communication error” , also using wireshark to capture packets , but still don’t see any communicate abnormality.

We used test network environment settings for VMS and camera is like picture below ,which is a small LAN includes a computer and 15 cameras.

​So my question is

  1. Is there any reason for this situation?
  2. Is there any possible steps to improve this situation?

​Camera ip location: 192.168.20.225

wireshark file and Milestone System log

https://drive.google.com/drive/folders/1Pv1Pdg14eZtEbxXL2xYSo1uiL7FmhB6N?usp=sharing

​Thanks

From the capture I see that the device is dropping the connection periodically. Let me explain.

All times below are in UTC, except for the TCP conversations dialog in which they are in UTC+3.

There are 6 TCP conversations related to the 20.225 device in the capture. They are from 2 RTSP streams as shown in the screenshot (one is for the “res=full” stream and the other is for the “res=half” stream).

As can be seen from the “start” and “end” bars in the dialog, the stream stops and then another stream starts. Let’s take a closer look at the TCP streams on ports 3454 and 3663. They are related to the same RTSP stream “res=full”.

In the below screenshot we can see that the stream (port 3454) is OK until 10:59:12.570 when the last RTP packet is received.

There is no data for 100 milliseconds and then the device (20.225) sends a FIN packet at 10:59:12.678. The Milestone Driver then sends a TEARDOWN and closes the connection.

Then at 10:59:12.799 the Milestone Driver opens new connection (port 3663) and does the DESCRIBE, SETUP, PLAY sequence.

The device sends the first RTP packet at 10:59:13.844 which is 1 second after the RTSP OK response to the PLAY command.

So from this capture can be seen that the device stops the streaming periodically and it takes more than 1 second to resume it again. This, in some cases, can lead to a gap in the timeline displayed in the Smart Client.