Thank you, Ross. The problem is gone now.
On May 2, 2015, at 8:43 PM, Ross Finlayson
mailto:finlay...@live555.com>> wrote:
I have just installed a new version (2015.05.03) of the “LIVE555 Streaming
Media” software that should fix this problem. Now, whenever a
“RTSPClientConnection” object (i.
I have just installed a new version (2015.05.03) of the “LIVE555 Streaming
Media” software that should fix this problem. Now, whenever a
“RTSPClientConnection” object (i.e., the RTSP TCP connection) is closed, the
server will - at the same time - close any RTP/RTCP-over-TCP streaming that was
As I noted in my earlier response, we usually have to continue to allow a
“RTSPClientSession” to outlive a “RTSPClientConnection” - but that doesn’t make
sense if the session is using RTP/RTCP-over-TCP streaming. In that case, when
the “RTSPClientConnection” dies, we need to also close any “R
Oops, I misread part of your earlier message. Now I think I understand what is
going wrong.
Yes, I think you are correct: There is potentially a problem if a
“RTSPClientSession” outlives a “RTSPClientConnection”, because the
“RTSPClientSession” can hold references to socket numbers that get re
> Explanation.
> - When RTSPServer::RTSPClientSession is created livenessTimeoutTask() is
> scheduled and it gets rescheduled while connection is on.
> - 60 seconds after connection is closed livenessTimeoutTask() is executed. It
> will delete clientSession, which will call reclaimStreamStates(),
Hi.
Noted this when using RTSP relay.
Use case (probably can be simplified):
- RTSP relay based on RTSPServer with RTP over TCP.
- Open connection (#1) and let it run. At this point relay connects to the
source stream and starts forwarding packets.
- Open another connection (#2) to the same stre
