Ross,
Glad we could contribute something.
The tests I ran were all successful with the new release, thank you.
And thanks again for the great library,
Regards,
Ralf
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document F
Ralf,
Many thanks for the bug report. I have applied (a sllightly modified
version of) your patch, and released a new version (2008.11.04) of
the software.
Please check that it works OK for you, and eliminates your problem.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_
Hi Ross,
One of my colleagues Louis Joubert found that the socket descriptors never got
deleted.
I've included his mail below. He found the difference between Windows and Linux
socket implementations:
On Windows and it seems like the accept() call returns different socket
descriptors/handles
Hi Ross,
Managed to isolate the problem further, the RTSP Server session timeout
triggers the RTCPInstance destructor (since the client has already
disconnected).
As soon as a RTCPInstance destructor has executed, the next RTSP client request
is handled by the RTSP handler instead of the RTCP
Hi Ross,
>That's strange. When the RTSP server handles the RTSP "PLAY"
>command, its call to "OnDemandServerMediaSubsession::startStream()"
>causes "StreamState::startPlaying()" to be called, which should cause
>a "RTCPInstance" to be created. That should then cause incoming data
>(on the TC
I managed to track the cause of the disconnection down.
It seems that the later connection's RR packets are not handled by
RTPTransmissionStats::noteIncomingRR but by the
RTSPServer::RTSPClientSession::incomingRequestHandler1.
That's strange. When the RTSP server handles the RTSP "PLAY"
com
Hi Ross,
I managed to track the cause of the disconnection down.
It seems that the later connection's RR packets are not handled by
RTPTransmissionStats::noteIncomingRR but by the
RTSPServer::RTSPClientSession::incomingRequestHandler1.
Every RR fills the buffer up and when the buffer is finally
Update:
Replicated using liveMedia RTSP server and open RTSP to stream audio.
Disconnect also occurred at about 340 seconds.
This seems to indicate that the request buffer is never reset and hence the 170
and 340 second times make sense too;
double the requests (or RTCP RR packets) and the buff
Hi,
I've written a RTSP Server using the liveMedia library which streams live data
from a webcam unicast over TCP.
The server runs on a Linux box.
When receiving the stream the server randomly disconnects the openRtsp client
(sitting on another box).
I've traced it to line 324 in RTSPServer.cpp
