> On Nov 26, 2020, at 11:30 PM, Лисовой Андрей Витальевич
> <a.liso...@transtelematica.ru> wrote:
>
> Hi!
>
> I found bug (using live.2018.02.18, but in 2020.06.25 RTPInterface.cpp is the
> same).
First, you should always try to use the latest version of the code (currently,
2020.11.26)
> It occures when proxyServer used with -t flag (RTP-over-TCP with backend
> server).
> In some cases, like client disconnects or reconnects, backend socket
> deregistering RTP channels, and only RTCP channels have staying alive. But,
> before proxied server got PAUSE command, it continue send RTP packets. Proxy
> interpret packets channel ID as wrong: ("Saw nonexistent stream channel id")
> and continues search dollar from next byte. And, when found dollar (in RTP
> payload of not actual channel), it wrongly interpret next byte as channel Id.
> And when that wrong ID equals one of alive RTCP channels, next two bytes
> interprets as packet size. So, trying to get that wrongly detected amount of
> bytes leds to infinitely calling of RTCPInstance::incomingReportHandler1()
> with same fNumBytesAlreadyRead, that exceeding maxRTCPPacketSize.
Unfortunately it’s going to be difficult to debug this unless I can get a lot
more details about the specific sequence of events (and function calls) that
causes it. (The RTP-over-TCP implementation has, historically, been the most
complex and error-prone part of the code.)
However, from your description, I suspect that there may be a bug in the
(back-end) server, that is causing it to send bad RTP-over-TCP data that our
code is not handling well. (Yes, we might be able to improve the way that we
handle this bad data, but if the server really is sending bad RTP-over-TCP
data, then there’s also a bug in your server that would need to be fixed.)
It might also help if you can reproduce this problem using a single RTSP client
(e.g., “openRTSP”, using the “-t” flag), rather than the "LIVE555 Proxy Server”
(which is a much more complex piece of software, as it combines a RTSP server
with a RTSP client).
I’m sorry I can’t be more helpful right now.
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
