9

Unfortunately I'm still stuck with a little implementation of a RTP / RTCP communication to access my IP camera properly.

What do I want to do

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.

What do I have so far

  1. A TCP connection which communicates via RTSP for the DESCRIBE / SETUP / PLAY Request ( RTSP ) to get the stream started. This connection must remain open while the Camera streams it's data.

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

  3. A UDP Socket which receives the RTCP Sender Reports / Source Descriptions. 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 Sender Report Goodbye comes, which means streaming has finished. Then I can close the TCP Socket (from RTSP communication).

What is going wrong

It is working for small buffer sizes like 2MB or 4MB. I receive some Source Descriptions and then a Goodbye. 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.

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:

Possible Reasons

This is the part where I need your advise.

Possibility: Lack of Receiver Reports

When streaming via VLC I noticed that there were some RTCP Receiver Reports sent from VLC to the camera ( cyclic like the Sender Reports ). So could it be that the camere expects at least one Receiver Report in a specific time ( or after a particular amount of bytes sent ) ? At the moment I can't think of any other reason.

Solution?

  • If we assume that the camera stops streaming because there are no Receiver Reports 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 RFC 3550 and I guess there is still a bunch of logic behind those Report messages. Now I actually don't need and so I also don't want to implement a complete RTCP protocol here. Would it be enough to send some Receiver Report Dummy frames so the camera just keeps on streaming? If so, how do they look?

  • If it is not related to the lack of Receiver Reports and I just don't need them, what could be the reason then for the camera to stop streaming? Any suggestions?

Edit:

Okay I just managed to create some kind of Dummy Receiver Report and it seems to work ( I just could receive 12MB then I got the desired Goodbye )

I just filled a 28Byte buffer and just used some values in the Header fields, meaning:

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 -> 28 Byte )

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.

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?

Toby
  • 3,815
  • 14
  • 51
  • 67
  • Have you considered using an existing RTP library that'd take care of this ? – nos Feb 23 '12 at 18:29
  • @nos Of course this would be an alternative but I actually wanted to avoid the use of any library because I just want the stream to be kept alive - There is not even a need to parse anything from the RTCP ( expect if it's an Goodbye Message of course ). Second the whole application needs to be completely async so I'd like to manage all sockets etc. by myself. Afaik most libs will control their own sockets and connections. But if I really need to fill the Receiver Reports properly ( with some "complex" data ) I maybe really consider a lib – Toby Feb 23 '12 at 23:40
  • Have you done a wireshark packet capture while the app is running? This will tell you exactly what is or isn't happening with your data. – Jonathan Henson Mar 08 '12 at 16:16
  • Yeah I did - the point I want to know is nothing what my wireshark log could answer me - like I said in my Update - I am sending dummy receiver reports to the camera and then it keeps streaming...my question at the moment is just if it's really OK to send this kind of "dummy" receiver reports to the camera – Toby Mar 08 '12 at 16:34
  • @nos Is there any library for this? mostly looking for java based android RTP and RTCP where i can read the receiver reports. – user14610638 Mar 16 '21 at 18:41

2 Answers2

1

Receiver report (RR) can be used by some cameras as "keep alive" message. You can try instead to send to you camera GET_PARAMETER every minute as keep alive message, if GET_PARAMETER is accepted by the camera. See what it tells you in response to DESCRIBE.

Some IP cameras can't parse RR properly. I'm actually trying to prevent the live555 library that I use in my client from sending RR messages because some models of Samsung cameras drop connection (according to their tech support).

MiltonGuy
  • 11
  • 1
1

You should read the data from the stream yourself. That way you can give real receiver reports instead of dummy ones.

If you need to forward it to another port for another application or library, you can simply do that.

Ben
  • 34,935
  • 6
  • 74
  • 113
  • I actually want to spare any resources I have ( embedded device ), so I want to avoid reading all this data. It would be quite unnecessary since I don't need it ( except for RTCP ) anyway. So I would really prefer doing it with some dummy values. – Toby Mar 21 '12 at 13:14
  • While you may not "need" it, the server does so it can adjust/throttle data to prevent flooding the network and packet loss. – Deanna Mar 17 '15 at 18:12