Ross Finlayson wrote:
Glen Gray wrote:
On 26/11/09 00:28, Ross Finlayson wrote:
Yes, by modifying the code in "RTSPServer.cpp" :-)

Until we fix the problem (at least at the server end), that's the only way I can see to overcome this issue - unless VLC is fixed to not use "GET_PARAMETER" as a client liveness indicator. It doesn't really need to do this, because RTCP already acts as a (much better) client liveness indicator. But perhaps the VLC developers did this in order to support some other (broken) server implementation that didn't recognize RTCP "RR" packets from the clients??

Yes, the K word would follow here. However, if I recall correctly, it only ever sends the GET_PARAMETER messages as a keep alive if the server reports back a timeout value as part of the setup.

That's good news. Eventually, how could one choose not to send the timeout value? RTSPServer.cpp modify or there's a better solution?

Glen was talking about a 'Kasenna' server, I think. Our RTSP server implementation *does not* specify a "timeout =" parameter at all.

Anyway, I've now installed a new version (2009.11.27) of the code that hacks the RTSP server's "OPTIONS" response to *not* include "GET_PARAMETER" in the list of available commands. This will stop VLC from using "GET_PARAMETER" as a client 'liveness' indicator, which we don't need, because we already use the client's RTCP "RR" packets as a 'liveness' indicator.

(This hack will be removed when we fix the problem with RTP-over-TCP (RSN, I hope).)
Great! Thank you!

Regards,
Cristiano.

--
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
bell...@imavis.com <mailto://bell...@imavis.com>
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to