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

[Stanley Biggs]

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/RTSPClient.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/be78994b/attachment.html>