title: RTCP / RTP communication issue
body: <p>Unfortunately I'm still stuck with a little implementation of a RTP / RTCP communication to access my IP camera properly.</p>
  
  <p><em><strong>What do I want to do</em></strong></p>
  
  <p>The camera has an internal buffer which I want to read. So I communicate with the camera via RTSP and tell it to stream the data. When the camera went through the whole buffer, streaming will stop.</p>
  
  <p><em><strong>What do I have so far</em></strong></p>
  
  <ol>
  <li><p>A TCP connection which communicates via RTSP for the <code>DESCRIBE</code> / <code>SETUP</code> / <code>PLAY</code> Request  ( RTSP ) to get the stream started. This connection <strong>must</strong> remain open while the Camera streams it's data. </p></li>
  <li><p>A Port on which I receive the data sent via RTP ( based on UDP ) - handling this is none of my concern, I even have absolutely no access to it, I just wanted to mention it for the sake of completeness.</p></li>
  <li><p>A UDP Socket which receives the RTCP <code>Sender Reports</code> / <code>Source Descriptions</code>.  This is important since I don't know when the stream stops ( as mentioned in point 2, I can't just look when the streaming stopped ). On this Socket I read until the RTCP <code>Sender Report Goodbye</code> comes, which means streaming has finished. Then I can close the TCP Socket (from RTSP
  communication).</p></li>
  </ol>
  
  <p><em><strong>What is going wrong</em></strong></p>
  
  <p>It is working for small buffer sizes like 2MB or 4MB. I receive some Source Descriptions and then a <code>Goodbye</code>. But in my particular test case I wanted to use 16MB ( which is still less than half of what the camera is capable of ).
  I receive the Sender Reports but at some point ( always at around 8MB +/-300KB ) the camera just stops sending. </p>
  
  <p>Noteworthy is the fact that I can access the buffer via VLC without problems. I even looked at the communication ( RTSP and RTCP ) which is almost completely the same as in my application...the one thing missing I'm gonna mention below:</p>
  
  <p><em><strong>Possible Reasons</em></strong></p>
  
  <p>This is the part where I need your advise. </p>
  
  <p><em>Possibility: Lack of Receiver Reports</em> </p>
  
  <p>When streaming via VLC I noticed that there were some RTCP  <code>Receiver Reports</code> sent from VLC to the camera ( cyclic like the <code>Sender Reports</code> ). So could it be that the camere expects at least one <code>Receiver Report</code> in a specific time ( or after a particular amount of bytes sent ) ?
  At the moment I can't think of any other reason.</p>
  
  <p><em><strong>Solution?</em></strong></p>
  
  <ul>
  <li><p>If we assume that the camera stops streaming because there are no <code>Receiver Reports</code> I'd like to know if there is a way to implement them without carrying to much information. I have already read some of the <a href="http://www.ietf.org/rfc/rfc3550.txt">RFC 3550</a> and I guess there is still a bunch of logic behind those Report messages. Now I actually don't <em>need</em> and so I also don't <em>want</em> to implement a complete RTCP protocol here. Would it be enough to send some <code>Receiver Report</code> Dummy frames so the camera just keeps on streaming? If so, how do they look?</p></li>
  <li><p>If it is not related to the lack of <code>Receiver Reports</code> and I just don't need them, what could be the reason then for the camera to stop streaming? Any suggestions? </p></li>
  </ul>
  
  <p><strong>Edit:</strong></p>
  
  <p>Okay I just managed to create some kind of Dummy <code>Receiver Report</code> and it seems to work ( I just could receive 12MB then I got the desired Goodbye )</p>
  
  <p>I just filled a 28Byte buffer and just used some values in the Header fields, meaning:</p>
  
  <pre><code>buffer[0] = 0x80;   // Version 2 , Padding = false, Reception Count = 0
  buffer[1] = 0xC9;   // Packet Type 201 Receiver Report
  buffer[2] = 0x00;   // Higher byte for total length
  buffer[3] = 0x06;   // Lower byte for total length ( in 32 Bit words -&gt; 28 Byte )
  </code></pre>
  
  <p>The rest of the buffer I just filled with zeros. Yeah I know it's just a hack and you should not tell your kids to program like this.</p>
  
  <p>Now my question changes a bit: Is this okay with this hack? It seems to work, but I'm still a bit concerned that my camera will use those dummy data and change configuration cause it interpets some weird stuff in it?</p>