(EXT) live555 RTSP Server RTP over TCP BUG

recently encountered a very difficult problem, the NVR through the ONVIF protocol to the IPC for video recording, in the video, it will be found that the individual IPC will appear intermittent video. This situation is difficult to reproduce, but once this happens, the entire process lasts for a long time, typically until the RTSP Server is restarted.

Through a large-scale test of bitter type found:
1, between the IPC and the NVR is through the RTP over TCP transmission data (this test result is very simple to know);
2. Open 1 clients (transmit data via RTP over TCP), after opening the RTSP stream, use Task Manager to force the end. Immediately thereafter open 1 client, open the RTSP stream, wait a while (1 minutes or so), behind the opening of this stream unexpectedly automatically disconnected. This is a must-have bug. (The client can use VLC when testing here, but VLC transmits the data by default using RTP over UDP.) To receive data using over TCP, you need to use the following settings: Tools, preferences, open the Preferences dialog box, click the All radio button in the display settings, expand on the left tree menu: "Input/Codec", "Go to Multiplexer", "RTP /RTSP ", select" Use RTP over RTSP (TCP) ");

Debug Discovery:  
1, Rtspserver::createnew () has a reclamationtestseconds parameter with the default value of 65; 
2, Rtspserver: : Createnewclientsession When you create an rtspclientsession instance, the Rtspclientsession constructor invokes Noteliveness,noteliveness to set a delay task. The task's delay time is 1 reclamationtestseconds (its value is seconds, it needs to be converted to microseconds, and the callback is Livenesstimeouttask). Noteliveness, in addition to being called at construction time, is also called after the RTSP server receives a RR packet (RR is actually used as a heartbeat packet);
3, Rtspserver::incomingconnectionhandler () function After the exception ends on a client, and then open a client open the RTSP stream, the value of the socket returned in the function is the same as the socket handle value of the previous client (the probability is above 50% if the socket handle returned here is different, This bug will not be reproduced);

Through the above 3, if you read the live555 code, you should know what is going on. The callback function of the delay task set in the above 2 Livenesstimeouttask, only one event is deleted, that is, delete the instance created by Rtspserver::createnewclientsession. Look at the destructor of Rtspclientsession, and find out that it actually deleted the corresponding node in the Rtpinterface::ftcpstreams list. The RTP and RTCP packets are sent to each client via Rtspserver::sendpacket, which is sent directly to the Rtpinterface::ftcpstreams saved address (that is, the socket handle). If the socket in the Rtpinterface::ftcpstreams is cleared, the client will no longer receive data, and the disconnection is inevitable. At this point, the reason for the disconnection is finally clear: that is, the abnormal end of a client, in 65 seconds (the default is 65), and then open a client opened the stream, the second open stream will be in 65 seconds must be disconnected, if the client has the function of automatic disconnection, then, intermittent situation appears.

Through the test also found that the way to receive data through RTP over UDP, the abnormal end of the client, the RTSP server will actually receive a teardown message, and in the process of teardown messages, will clean up the client session and the RTSP link, Even if the data is transferred with RTP over UDP, the exception ends the client, and the above bug does not occur, which confuses me a lot, if any one knows, please tell me why.

In fact, to solve this problem, only need to comment out the DELETE statement in Livenesstimeouttask, but this is not the final solution, because it will cause a memory leak, the best way is to use the session ID and the target address to correlate, When calling Streamstate::endplaying to delete the destination address, if the session ID does not correspond, do not remove the corresponding node from the linked list is OK.

Transferred from: http://m.blog.csdn.net/blog/zxwangyun/40541023

(EXT) live555 RTSP Server RTP over TCP BUG