[Live-devel] Bug-fix: RR packets are being sent early before PLAY command has been issued when using RTP-over-TCP

[Stanley Biggs]

Just a correction: I reference livemedia/RTSPClient.cpp as the source file
where I made the fix. This is incorrect. The correct filename is
livemedia/RTCP.cpp. It is here where the method occurs to which I applied
the fix. I am also indicating it inline below...


On Wed, Sep 11, 2013 at 9:06 AM, Stanley Biggs <stanley at gofuseit.com> wrote:

> Hi Ross
>
> I have found what I believe to a bug in the latest live555 code and I also
> have a fix for the problem. We have tested this fix in our implementation
> and I would like to submit this fix for inclusion in your project.
>
> *PROBLEM DESCRIPTION:*
> We are streaming using RTP-over-TCP. We are streaming via 3G cell phone
> connections which means that latency is higher than on a cabled network. We
> are setting up different Audio and Video streams which means that the
> client will issue a DESCRIBE request, followed by two SETUP requests and
> will then issue a PLAY request to start playing the stream. We have found
> that, after sending the second SETUP request (and before getting the result
> of this from the server), the client sends out an RR packet to the server.
> Since this happens before the client has issued a "PLAY" to the server, the
> server gets confused and responds with a "405 Method Not Allowed". This
> doesn't happen when we stream on a local LAN since the latency isn't a
> problem. The problem is only observed once we stream over a "real" network
> where there is some latency.
>
> *SOLUTION:*
> I have now debugged the Live555 code and have found the cause of the
> problem. Basically, in the case of a Sink Node being assigned, the
> RTCPInstance::addReport function checks the setting we have for
> enableRTCPReports (whether we can start sending reports or not). However,
> in the case of a Source Node being assigned, this function neglects to
> check the corresponding value of the Source Node. I have applied the
> following fix that I'd like to propose to include in the code:
>
> In *livemedia/include/RTSPSource.hh*:
>
> ...
>   Boolean& enableRTCPReports() { return fEnableRTCPReports; }
>   *Boolean constAccessibleEnableRTCPReports() const { return
> fEnableRTCPReports; }* //****Function added by me (Stanley). The same as
> enableRTCPReports except that it is "const" and "safe" for const object
> references to call, which means we can call this from RTCPInstance using
> the fSource object there.
> ...
>
> In *livemedia/RTCP.cpp*:
>
> ...
> Boolean RTCPInstance::addReport(Boolean alwaysAdd) {
>   // Include a SR or a RR, depending on whether we have an associated sink
> or source:
>   if (fSink != NULL) {
>     if (!alwaysAdd) {
>       if (!fSink->enableRTCPReports()) return False;
>
>       // Hack: Don't send a SR during those (brief) times when the
> timestamp of the
>       // next outgoing RTP packet has been preset, to ensure that that
> timestamp gets
>       // used for that outgoing packet. (David Bertrand, 2006.07.18)
>       if (fSink->nextTimestampHasBeenPreset()) return False;
>     }
>
>     addSR();
>   } else if (fSource != NULL) {
>     //****The following IF-statement was added by me (Stanley). As in the
> case of the Sink Node above, we first check the value of EnableRTCPReports
> before we do addRR().
>     *if (!fSource->**constAccessibleEnableRTCPReports()) return false;*
>     addRR();
>   }
>
>   return True;
> }
> ...
>
> Kind Regards
>
> Stanley Biggs
>
> <stanley at gofuseit.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130911/82b4df52/attachment-0001.html>