[Live-devel] RTP over TCP

[Rex Wolf]

I'm streaming RTP data over TCP from a network camera.  Most of the time this works fine.  But about once every 30 minutes (varies a lot) this particular camera sends some unexpected data between two RTP packets and that causes live555 to go into a state where it thinks it's receiving RTSP data and it never recovers from this.  Below is a portion of the data captured from wireshark that causes the problem.  The first chunk of data is the end of one RTP frame.  After this is received, SocketDescriptor::tcpReadHandler1() goes into the AWAITING_DOLLAR state.  As the next 112 bytes of data come in, it calls fServerRequestAlternativeByteHandler() to handle these bytes until it encounters the next $.  The function fServerRequestAlternativeByteHandler() points to RTSPClient::handleAlternativeRequestByte() which simply calls RTSPClient::handleAlternativeRequestByte1().

Now RTSPClient::handleAlternativeRequestByte1() normally just calls RTSPClient::handleResponseBytes() to handle this data, thinking that it should be an RTSP response.  But this is unknown binary data and the 28th bytes of it happens to be a 0xfe, which RTSPClient::handleAlternativeRequestByte1() treats as a special character that means the current data handler no longer needs any data so install RTSPClient::incomingDataHandler as the new data handler.  All incoming data now goes to RTSPClient::incomingDataHandler(), but since the data coming in is still RTP data, RTSPClient::fResponseBuffer just keeps overflowing forever with RTP data.

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.  But it does keep SocketDescriptor::tcpReadHandler1() as the incoming data handler and allows it to pick back up at the start of the next RTP packet.

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 and if my proposed change was acceptable or if there's a better way to handle this situation.


0310   50 8b 8f 84 2a a3 62 1e d3 6a 40 91 8b f4 31 51  P...*.b..j at ...1Q
0320   29 bd ce a1 05 02 3d 49 fe 1e 87 fd 2a 27 cc 78  ).....=I....*'.x
0330   1d 40 f0 c5 19 60 c5 37 b9 69 30 73 fd a6 d3 fa  . at ...`.7.i0s....  <== end of previous frame

0340   82 04 3a dd cd 10 35 e7 67 1a b4 95 83 08 e6 a7  ..:...5.g.......  <== start of 112 bytes of mystery data
0350   02 6a 81 f9 87 72 3c 3e 7f ee bf fe cc 73 dd 54  .j...r<>.....s.T  <== 0xfe appears in the stream
0360   9d 1b 67 10 5a 21 b6 8a 06 9b 84 b1 08 98 15 cc  ..g.Z!..........
0370   89 42 f8 90 80 72 5e 67 8e a0 86 43 cd f6 a6 cf  .B...r^g...C....
0380   b5 41 55 d1 a1 9e 75 e8 c2 18 77 06 d8 d1 be 9a  .AU...u...w.....
0390   79 a7 3a 97 24 7a 2f fd b3 fb c5 6e d8 ee 86 8d  y.:.$z/....n....
03a0   bb 56 cc f7 1f 4c 8d 52 5f f9 2d 02 19 af 05 31  .V...L.R_.-....1

03b0   24 00 20 0c 80 60 0f 0e db 0f ee cc 9b 05 ae d1  $. ..`..........  <== start of next frame ('$', channel 0, 0x200c bytes)
03c0   7c 05 1c 09 de 8e 50 88 af 46 15 1b 10 74 7b 97  |.....P..F...t{.
03d0   6c 4b b0 00 05 5a 4c 1a 81 86 a9 e5 ed fe cc 12  lK...ZL.........


Thanks for your help,
Rex Wolf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121001/14a069bc/attachment.html>