Open lars18th opened 5 years ago
Hi @catalinii ,
I discovered the cause of this problem: The satipc
module when the adapter is closed, then it closes the socket before the TEARDOWN command is acknowledged.
See this part of the log:
[12/11 18:02:08.701 main]: closing adapter 2 -> fe:14 dvr:15, sock:17, fe_sock:15
[12/11 18:02:08.701 main]: satip device 192.168.1.27:554 is closing
[12/11 18:02:08.701 main]: satipc_http_request (ad 2): sending to sock 15:
TEARDOWN rtsp://192.168.1.27:554/stream=2 RTSP/1.0
CSeq: 12
Session: 0272793942
[12/11 18:02:08.701 main]: satip_close called for adapter 2, socket_id 15, handle 14 timeout 30000
[12/11 18:02:08.701 main]: sockets_del: sock 15 -> handle 14, sid 2, overflow bytes 0, allocated 0, used 0, unsend packets 0
[12/11 18:02:08.701 main]: sockets_del: 15 Last open socket is at index 17 current_handle 14
[12/11 18:02:08.701 main]: Destroying mutex 0x7fbd49ea0268
[12/11 18:02:08.701 main]: satip_close called for adapter 2, socket_id 16, handle 16 timeout 0
[12/11 18:02:08.701 main]: sockets_del: sock 16 -> handle 16, sid 2, overflow bytes 0, allocated 0, used 0, unsend packets 0
[12/11 18:02:08.701 main]: sockets_del: 16 Last open socket is at index 17 current_handle 16
[12/11 18:02:08.701 main]: Destroying mutex 0x7fbd49ea03c8
[12/11 18:02:08.701 main]: adapter.c:1105: get_adapter returns NULL for adapter_id 2
[12/11 18:02:08.701 main]: adapter.c:875: get_adapter returns NULL for adapter_id 2
[12/11 18:02:08.701 main]: Destroying mutex 0x7fbd49e8fd78
[12/11 18:02:08.701 main]: done closing adapter 2
[12/11 18:02:08.701 main]: sockets_del: sock 17 -> handle 15, sid -1, overflow bytes 0, allocated 0, used 0, unsend packets 0
So, the TEARDOWN command is created, but the socket is closed before it's sended! Futhermore I can confirm that the SAT>IP server has not received the RTSP command.
The correct behaviour (in my opinion) is to wait until the RTSP command confirming the TEARDOWN is received to close the socket. OR almost flush the socket before close it. You agree?
Hi @catalinii ,
I'm triying to add a flush_socket()
call after this line as a workaround: https://github.com/catalinii/minisatip/blob/70ab20c8e8d0d4875b4f6ce3b2c1935e7378e278/src/satipc.c#L484
However, I don't know how to retrieve the socket pointer.
Please, can you help me?
Hi @catalinii ,
I'm tired! The TEARDOWN message never arrives to the socket. Please, can you provide a solution?
Thank you!
I can take a look into this.
I can take a look into this.
Hi @catalinii . Any news?
Hi @catalinii ,
I indentified the root cause of this problem. And I'm working on fixing it. Only FYI.
Regards.
Hi @catalinii ,
I found another trouble with the SAT>IP client mode: When some SAT>IP client request a
pids=none
for one stream, then thesatipc
module never closes the remote session when the client doesn't sends a TEARDOWN command. So the session with the target SAT>IP server continue open forever.Please, can you enforce to close (send a TEARDOWN message) if the client session is expired? And, as a tip, I suggest to close too the session if
pids=none
and the client socket (from the SAT>IP client to minisatip) is closed. In this specific case it will be desirable to not wait until the watchdog to close the session.I hope you want to consider it. Thank you!