Hi,
You are receiving an additional response to Describe command that was
previously received completely ( CSeq: 4).
Your setup sent with CSeq: 5 but response came to CSeq: 4 - Handler for
this was already completed.
Try to implement a timeout handler - I had an issue with different vendor
of cam
Thank you for clarification,
Alexander
On Wednesday, July 29, 2020 2:33:14 PM IDT Ross Finlayson wrote:
> > On Jul 29, 2020, at 11:12 PM, Alexander Tumarov
> > wrote:
> >
> > Hi Ross,
> >
> > In the case of TCP should it suspend sending up to the point there
Hi Ross,
In the case of TCP should it suspend sending up to the point there is a space
available
instead of dropping RTP packets? or close connection in such a case? or at
least should it
be up to implementation/user code?
RTSP can be user for streaming stored data - not only real time strea
Thank you a lot - the idea with timer+changeResponseHandler did the job. Just
timer should be scheduled in very early steps and not after Play was issued.
The problem were like that - I have numerous different RTSP sources - some
them were buggy ( IP Cameras ) - they send a reply to WRONG socket
Thank you for replying,
This is RTSP client implemented based on testRTSPClient code supplied with
library sources.
What is happening is that upon errors in streaming from RTSP capable camera,
sometimes no callback is called.
If RTSP source reports problems (reply is sent) - code handles it w
I meet some problem with detecting that stream is broken.
The path it takes is like this:
It may be the case that connection is pending or while in connected state the
command is send (write in sendRequest succeed) but reply is never arrived
(RTSP source is overloaded for example).
Is there any
