Relay server for an IP camera viewing app

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.

## Deliverables

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.

Compétences : Programmation C, Ingénierie, Linux, MySQL, Gestion de Projet, Architecture Logicielle, Tests de Logiciels, UNIX

en voir plus : relay camera video stream iphone web site, p2p camera linux server, camera relay server, work remotely from home, work for at&t from home, where to hire coders, where to get the best coders for hire, what is the best way to work from home, what is the best android phone, what do you need to get a manufacturer, web thin client, web site programming at home, web projects for coders, ways to work at home, video chat on android, video chat for android, video chat between iphone and android, video chat android to iphone, t sql programming, t mobile work from home

Concernant l'employeur :
( 6 commentaires ) United States

Nº du projet : #3787570

6 freelance font une offre moyenne de $1225 pour ce travail


See private message.

%bids___i_sum_sub_35% %project_currencyDetails_sign_sub_36% USD en 10 jours
(111 Commentaires)

See private message.

%bids___i_sum_sub_35% %project_currencyDetails_sign_sub_36% USD en 10 jours
(23 Commentaires)

See private message.

%bids___i_sum_sub_35% %project_currencyDetails_sign_sub_36% USD en 10 jours
(124 Commentaires)

See private message.

%bids___i_sum_sub_35% %project_currencyDetails_sign_sub_36% USD en 10 jours
(9 Commentaires)

See private message.

%bids___i_sum_sub_35% %project_currencyDetails_sign_sub_36% USD en 10 jours
(6 Commentaires)

See private message.

%bids___i_sum_sub_35% %project_currencyDetails_sign_sub_36% USD en 10 jours
(0 Commentaires)