[Live-devel] GET_PARAMETERS used as a ping request and VLC

Cristiano Belloni belloni at imavis.com
Wed Nov 25 08:55:43 PST 2009


Hi to all,

I've got a liveMedia RTSP server and VLC as a client. I need the server 
to stream on TCP (and so, use the RTSP connection to stream video).

What happens is that VLC sends GET_PARAMETERS rtsp commands with empty 
body to the server during streaming.
The server does not respond to this command, because liveMedia is unable 
to process rtsp commands after a play, as stated here: 
http://www.mail-archive.com/live-devel@lists.live555.com/msg00651.html 
by Ross:

> Note, though, that if you requested RTP-over-TCP streaming, then 
> (because of software limitations) the server will not see any RTSP 
> requests after "PLAY".  However, incoming RTCP "RR" packets will 
> always be handled (and used to indicate client liveness).
>   

Maybe vlc is sending GET_PARAMETERS to "ping" the server, as stated in 
RFC 2326 par. 10.8. The problem is that, since the server simply does 
not respond, VLC seems to conclude that the server is dead and discards 
packets with the infamous "Discarding interleaved RTP or RTCP packet".

Now, server OPTIONS' response is: Public: OPTIONS, DESCRIBE, SETUP, 
TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER.
I think it's not quite correct not answering the client GET_PARAMETER 
requests, since this option is publicized in the OPTIONS response, but I 
understand it's a major limit in liveMedia RTSP/TCP design, and nothing 
can be done.

My questions are:

1) Is there a way to change the OPTIONS response? Maybe if we don't 
publicize the GET_PARAMETER option, vlc client won't try to use it, only 
to find the server unable to handle it after a PLAY.

2) Is there some other work-around for this situation? Please note I 
can't change VLC code, as we don't distribute VLC, but let every client 
download it (its browser-plugin, in fact) straight from the site. 
Conversely, I cant' just switch to UDP, as TCP streaming is the only 
things that just works in case of blocking firewalls, routers, and all 
the sweet things you can encounter on the modern Internet.

Thanks,
Best Regards,
Cristiano Belloni.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni@imavis.com>


More information about the live-devel mailing list