The app, called a Camera Management Server, is a daemon that runs on our Linux server, listens for incoming connections from cameras and keeps that socket alive, listens for incoming requests to view the cameras, and, handles sending the camera an ip/port to push the video stream to, and forwards it to the client.
The CMS doesn't do any transcoding or video processing. It's really just about being very good with sockets. Also, we will provide the code for all the logging and authentication.
We have a 'remote camera viewing' application for which we need to hire a really good code immediately. Our product is launching later this month because two months ago we signed a contract with a camera manufacturer who was supposed to provide both the hardware and the software. But now that we are close to launch, we learned that the software does not work anything like their demo, and we need to write our own server. We have a couple C/C++ coders, but they are swamped with other projects, and do not have experience in this area anyway. In a nutshell here's what happens:
1. The customer plugs in his camera, it gets an IP address, and opens a port to our central camera management server (CMS) and sends it's internal IP and mac address. The camera keeps connection alive so the CMS can send back commands over the same port. The CMS logs this information.
2. The camera, all on its own, attempts to do a port forward using UPnP. The CMS tests if the port forward has worked, and whether any client viewers will be able to view the video directly from the camera, using only the routable IP, or if the CMS has to act as a relay.
3. Optionally users may have an Adobe Flash client running on a thin client within their home. This flash client also makes a connection to the same CMS, using a different port, and the CMS keeps track of all the clients the same way it does the cameras. The socket connection allows the flash client to send very basic messages to the server, and vice versa. The protocol is really simple; there will be about 4 plain text messages. The amount of traffic will be minimal.
This system can be used two ways: as a video chat (video only, no sound) between two Adobe flash clients, or, the user can remotely view the cameras and is home with his mobile phone (android/iPhone) or with the web browser.
1. For video chat, both users will have a camera and a flash client that are associated together; our existing code provides this information. User a enters the serial number of user B's camera, which causes a CHAT_REQUEST to be sent to the CMS server, which forwards it to user B's flash client. User B's flash client pops up a message, and if the user accepts, sends an ACCEPT to the CMS, and the CMS sends a VIEW_VIDEO http://[whatever] to both flash clients, where the URL points the flash client to the streaming video from the other user.
2. For remote camera viewing, the user logs into a web site which we created with his browser or mobile phone, and our web services get the URL from the CMS, and embed it an iframe.
The only part we need is the CMS server. The Flash client, web site, etc., are done in house already. We can modify the protocol we use easily to suit whenever is the best and most efficient way the CMS will implement this.
This CMS server does not do any transcoding or video processing. The video from the camera is obtained by a URL on the camera, like [url removed, login to view] or, you send the camera a message to have it pushed the stream to a given IP/port.
We do NOT want to have the video relay to cross our server unless absolutely necessary. So if there are techniques for hole punching/NAT transversal, etc., to allow p2p, we would like to implement them. However, that can be done as a phase two. Right now, at launch, the volume of users will be minimal, so we can provide the server bandwidth initially.
The logging and authentication occur in a my SQL table. If you do not know mysql, that is not a problem. We can provide that code. You would just call a function stub like AuthUser(char *Username,char *Password) and we can provide the implementation.
Unfortunately, we're under very tight deadline so we're looking for a Coder who can start right away, as someone who can do it evenings and weekends. Also, if it is easier to use existing GPL code, that is no problem, we can release our app under GPL as well.