[Live-devel] RTP over TCP

[Rex Wolf]

Ross,
Thanks for the quick reply.  Here is the diff of the changes I propose to the AWAITING_DOLLAR case in SocketDescriptor::tcpReadHandler1().
Rex


    case AWAITING_DOLLAR: {
      if (c == '$') {
#ifdef DEBUG_RECEIVE
        fprintf(stderr, "SocketDescriptor(socket %d)::tcpReadHandler(): Saw '$'\n", fOurSocketNum);
#endif
        fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
      } else {
        // This character is part of a RTSP request or command, which is handled separately:
        if (fServerRequestAlternativeByteHandler != NULL) {
          (*fServerRequestAlternativeByteHandler)(fServerRequestAlternativeByteHandlerClientData, c);
        }
      }
      break;
    }

-------------------------------------------------------------------------------------------------------

    case AWAITING_DOLLAR: {
      if (c == '$') {
#ifdef DEBUG_RECEIVE
        fprintf(stderr, "SocketDescriptor(socket %d)::tcpReadHandler(): Saw '$'\n", fOurSocketNum);
#endif
        fTCPReadingState = AWAITING_STREAM_CHANNEL_ID;
      } else {
        // This character is part of a RTSP request or command, which is handled separately:
        if ((fServerRequestAlternativeByteHandler != NULL) && (c != 0xFF) && (c != 0xFE)) {  // FF and FE are treated as special chars, so don't send them
          (*fServerRequestAlternativeByteHandler)(fServerRequestAlternativeByteHandlerClientData, c);
        }
      }
      break;
    }


From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Monday, October 01, 2012 12:24 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] RTP over TCP

To prevent this situation, I tried adding a check to SocketDescriptor::tcpReadHandler1() in the AWAITING_DOLLAR case to prevent it from calling fServerRequestAlternativeByteHandler if the byte read was 0xFF or 0xFE.  This is, of course, a hack on top of a hack.

Yes, but since the original 'hack' (i.e., using 0xFE and 0xFF as special 'signaling' bytes) relies upon the fact that we don't expect these characters to appear within RTSP requests or responses, it seems reasonable to modify the code - as you did - to check for this.

Just to make sure we're on the same page here, please send a "diff" containing your modification, and I'll include it in the next release of the software.


I've contacted the camera vendor to find out why they put this mystery data in between the RTP packets sometimes.  But here I wanted to ask if that was even allowed per the RTSP spec

No, definitely not.  There shouldn't be any extra data like this appearing in the TCP stream.  It's apparently a bug in the network camera.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121001/8b1c1677/attachment-0001.html>