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