Make Raspberry Pi camera video streaming work over Internet

[Junichi Yamazaki]

This is my first post to the forum. I’m quite new for WebRTC and Janus.

Exactly following the instruction at the page, I have successfully made up Raspberry camera stream a video to FireFox on my home PC. Then I wanted to see the video out of my home. I have tried some solutions below.

Solution 1

1. Install Janus and Nginx with the streaming demo contents to a virtual machine at Amazon EC2 and accept any traffic
   
2. Install STUN/TURN servers to another virtual machine at EC2 and accept any traffic
   
3. Make Gstreamer running on Pi to send the video stream to Janus on EC2
   
4. Modify janus.cfg to use STUN/TURN servers on EC2
   

I could successfully see the video out of my home, but I do not like this solution, because the video traffic is going through Janus gateway, which may be a bottle neck for wide deployment. Then I have made up the second solution:

Solution 2

1. Switch Gstreamer back to send video to Janus ruining locally on Pi
   
2. Modify the demo contents at EC2 to use Janus on Pi. To make it work, I need to do the following two steps
   
3. Register an alias of Pi at my dynamic DNS provider
   
4. Set up my home router to forward TCP port 8088 traffic from Internet to the private IP address of Pi
   

I could successfully see the video out of my home, but I do not like this solution, because I need to configure the port forwarding of my home router. The solution does not make use of a value of WebRTC, zero configuration. Then I’m wondering the third solution, which is something like below:

Solution 3

1. Setup some signaling server on EC2
   
2. Modify the demo contents to establish WebSocket to the signaling server send any API calls to the signaling server
   
3. Make Janus establish WebSocket to the signaling server to accept any API calls forwarded by the signaling server
   

I wish if I had this solution, because of zero configuration and no bottle neck at EC2. My problem is that I’m not capable to write a program for the solution

I would like to ask the experts in this forum if there is any better solution.

Regards,

Jun

[Junichi Yamazaki]

Searching the web more deeply, there are people developing the video streaming application by using OpenWebRTC. I should keep watching the thread:

https://github.com/EricssonResearch/openwebrtc/issues/172

Jun

[Lorenzo Miniero]

Not sure about the OpenWebRTC approach as I'm not familiar with it.

About the approaches you listed, it really depends on what you want to achieve.

Approach 1. works fine if you have limited bandwidth and you want more people to access your feed. This way you only "publish" once on the cloud, and then all viewers are handled there. Of course this means having a server available with a certain bandwidth availability, which has costs. Besides, sending a plain RTP/RTCP stream to an external component on the Internet has both privacy (it can be eavesdropped) and robustness (if a packet is lost gstreamer wouldn't retransmit it, and WebRTC viewers would miss it forever) issues.

Approach 2. works fine if you want to have a private service you want to use for yourself. Not sure what you mean by an issue in needing to configure the router: that's of course needed in order to access web servers in a private network from outside, and it's standard practice. The WebRTC negotiation can then take care of the NATs automatically on its own.

Approach 3. probably overcomes the concern in having to configure the virtual NAT on your router, but it also means you have to implement some code to handle the "bridging". Modifying the demo to send a call outside only works if the page is already up and running, which wouldn't be the case if you're trying to access from outside. It would need to be some "local" application that connects to the signaling server and then in turn makes sure the Janus behind the NAT and the signaling server in the cloud can communicate.

For simplicity, I'd go for 2. which is practically just the matter of configuring a couple of things without touching anything else.

L.

[Junichi Yamazaki]

Lorenzo,

Thank you for your comments. I agree that the solution 1 is a good for video broadcast application. It may be also good for conference bridge (audio mixing) application. It is not good for multiple but independent point-to-point application. One of my motivation to use WebRTC is NAT traversal without touching the router. The solution 2 decreases my motivation.  The port forwarding is not an easy task for general consumers.

Regards,

Jun 

[Lorenzo Miniero]

Yes, but as I said you need port forwarding only for the web server, so a single port. The WebRTC negotiation handles NATs by itself just fine.

L.

[Lorenzo Miniero]

If the web server is smart enough to use UPNP or similar protocols and the router supports it, you don't even have to open anything yourself.

L.