Create remote camera viewing system

We need improvements to our product which allows someone to watch IP cameras in their home on their mobile phone or web browser, without having to setup port forwarding in their home router. This project requires some knowledge of playing streaming video from IP cameras, like RTSP, MPEG-4, and MJPEG, and how best to encrypt it, such as using Secure RTP. There will be some coding in C++, some in Android, some for iPhone, and some Web. NOTE: It is NOT required that one coder have all these skills. We are fine awarding this project to multiple coders. You can bid on just the piece that you know, like the Android viewer and the C++, or just the iPhone. ## Deliverables **Background:** We make a home automation product, "Vera", which is essentially a wi-fi access point running Linux and our own C++ software (see Vera at [[login to view URL]][1]). One of the features is the ability to remotely view your IP cameras from outside the home on a web browser, or Android or iPhone, even though the camera is behind the homeowner's firewall, without having to setup a port forward on the router. The way we implement the remote viewing right now is that Vera keeps a constant connection to our server, and when the user wants to view a camera, our server sends a message to Vera to start a port relay using port X on the server with ssh's built-in port forwarding. Say the camera is on the homeowner's network with the IP [login to view URL], and our server is [login to view URL], and the server tells Vera to use the server's port #21000. Then Vera runs ssh like this: ssh -p 22 -T -y -i /someprivatekey -R 21000:[login to view URL] <someuser@[login to view URL]> That means that the publicly accessible URL on our server ([login to view URL]) is now the same thing as the port 80 on the homeowner's home network, so the web and phone viewers can access the camera's video. The problems with our current solution are: 1. the video stream isn't encrypted, so a man-in-the-middle could view the homeowner's cameras, and the only way we ensure that only the homeowner views the camera is by doing an iptable on the server limiting the IP that can access that port 2. The web browser is able to play streaming video using the QuickTime plugin (h.264), but we must have done something wrong because QuickTime crashes a lot 3. we haven't yet gotten the Android or iPhone apps to be able to play the streaming video, so for now they're just displaying a series of still frames (motion-JPEG) 4. most of the cameras support two-way audio, meaning they have speakers in them and you can use them as an intercom, but our Android/iPhone coders don't know how to capture the audio from the phone and forward it to the cameras so the cameras can play the audio with their speakers. **Scope of work:** If we find one person to do all these, that's great. Otherwise just bid on what you know. The project is divided into the following parts, and you can bid on all or some of them: **ARCHITECTURE**: We don't have much expertise in-house with video or low-level network technologies like hole-punching. So part of the project is simply coming up with the best plan of action. Considerations are that our product which is in the home, Vera, is a low-power device (16MB RAM, 200Mhz processor), with no DSP. So Vera will not be able to do video transcoding, like taking the MPEG-4 and re-encoding it as secure flash. Vera probably could encapsulate packets. So, assuming that secure RTP is just RTP/RTSP with some light encryption, Vera probably could handle encrypting the stream. But whatever encryption is done it must be something standard enough that the Android/iPhone/Web viewers will be able to view it. We want to support 3 manufacturer's cameras (Sercomm, Foscam, and Panasonic), so an analysis of those cameras features and supported codecs is needed to determine what's possible on each camera. Also, to reduce our server costs, we would prefer that the homeowner's viewing client (web, android, iphone) be able to fetch the video directly from Vera, without going through our server, whenever possible. We envision several ways this could happen, such as the viewing client requests video from the server, the server relays this to Vera and sets up some hole-punching, giving both the client and Vera the other devices IP and reporting what port is being used for NAT. Or, if the homeowner's router supports UPNP, Vera could try to use UPNP to do a port forward, and the server could validate. If those fail, then the viewing client could revert to having the server act as a relay. So, part of the project is simply consulting work, and if different coders are doing the Android/iPhone part, working with them to be sure it all works. **VERA AND SERVER CODING:** (Probably C++ on Linux): Once the architecture is finalized we need the code that will run on the Vera which will handle the encryption and possibly the hole punching and port forwarding. This will probably be C++, unless it can be done in bash scripts with the standard utilities in busybox. On the server there will also be some code to setup the hole punching, confirm the port forwarding is working, and handle the relay. We could continue to do the relaying with ssh like we do now, or there could be new code involved. **ANDROID CODING:** We will provide the Android code we have already which is displaying a series of still frame images (Motion-JPEG). Whatever encryption method is chosen will need to be implemented, as well as working to get motion video (MPEG-4/H.264) working. The phone should attempt to use the motion video first, since it's smoother and uses less bandwidth, and revert to still frames if the phone can't handle the video or the codec. We also want the ability to capture the audio from the phone's microphone and send it back to the camera so it gets played through the camera's speakers. **IPHONE CODING:** Same thing as the Android coding, but for iPhone. **WEB CODING:** Figure out how to play the encrypted video stream in modern web browsers, perhaps using QuickTime or Flash. **Cameras**: The 3 cameras we want to support are on the web so you can see how they work. The manuals and specs are available online: **1. Panasonic BL-C210A** IP: [login to view URL] username:dceadmin password:dcepass Specs: <[login to view URL]> **2. Foscam FI8918W** IP:[login to view URL] username:admin password:(none) Specs: <[login to view URL]> **3. Sercomm RC8021** IP:[login to view URL]: username:dceadmin password:dcepass Specs: <[login to view URL]>