On Wed, Jul 20, 2011 at 11:15 AM, Jeremy Noring <span dir="ltr"><<a href="mailto:kidjan@gmail.com">kidjan@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>

<br>I narrowed down the problem to  RTPInterface.cpp, line 379:<br><br>    case AWAITING_STREAM_CHANNEL_ID: {<br>      // The byte that we read is the stream channel id.<br>      fStreamChannelId = c;<br>      fTCPReadingState = AWAITING_SIZE1;<br>

      break;<br>    }<br><br>....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:<br><br>    case AWAITING_PACKET_DATA: {<br>

      // Call the appropriate read handler to get the packet data from the TCP stream:<br>      RTPInterface* rtpInterface = lookupRTPInterface(fStreamChannelId);<br>      if (rtpInterface != NULL) {<br><br>...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).<br>

<br>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.<br>

<br>Any ideas why this may be happening?<br></blockquote><div><br>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:<br>
<br>    case AWAITING_STREAM_CHANNEL_ID: {<br>      // The byte that we read is the stream channel id.<br>      RTPInterface* rtpInterface = lookupRTPInterface(c);<br>      if (rtpInterface != NULL)<br>      {<br>         fStreamChannelId = c;<br>
         fTCPReadingState = AWAITING_SIZE1;<br>      }<br>      else<br>      {  // we're not interested in this channel<br>        fTCPReadingState = AWAITING_DOLLAR;<br>      }<br><br>...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.<br>
<br> <br></div></div>