[Live-devel] RTP over RTSP: client sending RR "early"
Chris Richardson (WTI)
chris at gotowti.com
Thu Aug 30 14:09:34 PDT 2012
Hi All,
I also have run into this issue on more than one occasion, with customers
using relatively high latency DSL or cellular modems. I agree it is more
than an annoyance (RTP over RTSP in this case is too unreliable to even use
at all) and any kind of fix or workaround would be greatly appreciated.
Thanks,
Chris Richardson
WTI
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Matt Schuckmann
Sent: Thursday, August 30, 2012 10:50 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] RTP over RTSP: client sending RR "early"
I actually ran into this very same problem a while back. We had a customer
trying to stream live low frame rate/low bit rate video over a slow military
3G cellular network and things weren't working, I can't remember all the
details now but either the client or the server was hanging up because of an
unexpected response or something like that. It wasn't crashing but things
also weren't operational.
Eventually I figured out the same thing that Ralf discovered, i.e. that one
of the RTCP packets were coming in before the server expected and messing up
the server RTSP over TCP parsing code. I have to go back and reproduce the
problem to be sure, but I think it was more than a mere annoyance.
At the time the customer figured out a work around (I think it was a
different network or something like that ) and I didn't have time to figure
out a proper fix for the code and I put it on my to do list to report the
problem to you Ross. But as often happens with to do lists that item never
came up.
A fix for this would be appreciated.
Matt S.
On 8/30/2012 6:44 AM, Ross Finlayson wrote:
1) The server could of course be made more robust by detecting the '$' char
and ignoring such requests.
Would this work as a quick fix?
Perhaps. But is this really a problem worth worrying about? If this
happens only occasionally (in extreme situations), and merely causes the
server to send back a "method not allowed" RTSP response, then is this a
major problem? It seems to be merely an 'annoyance'.
2) The (more correct?) approach would be to only allow the client to send an
RR after it has received a PLAY response.
Maybe, but that would require a major change to the client code that might
break other things - and wouldn't help with existing clients anyway. So I'm
not going to go down that route just to deal with a rare issue that - as
noted above - appears to be just an annoyance.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120830/01273e07/attachment.html>
More information about the live-devel
mailing list