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 <stan...@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
>
> <stan...@gofuseit.com>
>
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
