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 during RTSP session establishment (verified with sniffer) . Sometimes it turned to be that receiver does not recieve a reply (while other receiver get it with wrong CSeq). Camera from it's side waits for next command and client waits for a reply. Thanks again. On Sunday, January 26, 2020 12:41:36 PM IST Ross Finlayson wrote: > > So it can be very helpfull to have a deadline timeout for getting > > command's > > response (of course with callback being called). > > You can cancel a pending RTSP command by calling the function > RTSPClient::changeResponseHandler(unsigned cseq, responseHandler* > newResponseHandler) (see “liveMedia/include/RTSPClient.h”, line 165) > > You would pass this function a “cseq” value that was returned from a > previous RTSP “send*Command()” operation (on the same “RTSPClient” object, > of course). The “newResponseHandler” can be NULL; this will cancel the > pending command. (If a response ends up coming back over the network > later, then it will just get ignored.) > > The best way to set up a ’timeout’ like this is to call > “scheduleDelayedTask()”, as you have been doing. Then your handler can > call "changeResponseHandler()”, as noted above. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
