[Live-devel] Problem with RTP over TCP

[Jeremy Noring]

On Wed, Jul 20, 2011 at 11:15 AM, Jeremy Noring <kidjan at gmail.com> wrote:

> I updated my RTP client to the most recent version (2011.7.18) and I'm
> having trouble with RTP over TCP.  Occasionally Live555 will get in a state
> where it no longer receives any data from the server, even though the server
> is completely alive.
>
> I narrowed down the problem to  RTPInterface.cpp, line 379:
>
>     case AWAITING_STREAM_CHANNEL_ID: {
>       // The byte that we read is the stream channel id.
>       fStreamChannelId = c;
>       fTCPReadingState = AWAITING_SIZE1;
>       break;
>     }
>
> ....fStreamChannelId gets set to some crazy value (e.g. '37') that isn't
> valid (for my app, should be 0 or 2).  Once it's in that bad state, this
> fails repeatedly:
>
>     case AWAITING_PACKET_DATA: {
>       // Call the appropriate read handler to get the packet data from the
> TCP stream:
>       RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);
>       if (rtpInterface != NULL) {
>
> ...lookupRTPInterface(fStreamChannelId) returns NULL, which causes the
> library not to call fReadHandlerProc().  Live555 consumes all the CPU, and
> the only communication that still happens are the periodic SR reports (which
> do still work).
>
> I haven't managed to figure out why this is; using a debug build (i.e.
> DEBUG is defined, so there are periodic log messages) seems to reproduce the
> issue much more immediately--otherwise it can take a while to get in this
> bad state.
>
> Any ideas why this may be happening?
>

Update: I went through some older versions of the library (prior to the
async client rewrite) and I saw code that would ensure the stream channel ID
was present.  So I did a quick test with the following code:

    case AWAITING_STREAM_CHANNEL_ID: {
      // The byte that we read is the stream channel id.
      RTPInterface* rtpInterface = lookupRTPInterface(c);
      if (rtpInterface != NULL)
      {
         fStreamChannelId = c;
         fTCPReadingState = AWAITING_SIZE1;
      }
      else
      {  // we're not interested in this channel
        fTCPReadingState = AWAITING_DOLLAR;
      }

...and that seems to have mostly corrected the issue.  That said, I'd really
like to know how it's happening in the first place--seems to me like there
must be some other bug allowing it to get in this state?  Or maybe it's not
that simple.  Any insight is welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110720/cf216cc8/attachment.html>