In our previous webcam blog post, we showed how Nabto can be used to access a video stream from a remote webcam using the Nabto P2P platform. That post is well worth a read as it covers access control and the setting up a simple webcam for streaming, two topics not covered in this blog post. However, the client used in the previous post does not support RTSP streaming which is the topic of this post so you can try high performance P2P video streaming with audio – the most typical commercial Nabto use case.
Connecting a video player directly to a remote RTSP server through a P2P connection using Nabto requires the uNabto tunnel application running between the RTSP server and the internet.
The Nabto Client establishes the P2P connection to the uNabto process on the target system, acting as a local RTSP proxy used by a video player application. Typically the Nabto Client and video player are embedded in a mobile app.
Essentially the uNabto tunnel on the remote network acts as a P2P enabled RTSP reverse proxy. Typically the uNabto tunnel runs on the same machine as the target RTSP server, e.g. directly on a camera or a DVR or NVR. But it can also run on a separate machine on the same network as the RTSP server, e.g. on a gateway-style device. This blog post assumes the latter type of setup as we then don’t have to worry about compiling for individual IP cameras or DVRs.
This example will assume an RTSP server is available to the uNabto tunnel application, and not make further elaborations on how such a server can be set up. Instead, we will show how to get the uNabto tunnel application running and how to connect to it using an app available at Apple App store and Google Play store.
Note that we still leave a gap in terms of blog posts and examples – we will fill this as soon as time permits: To recap, the webcam blog post shows production ready pairing (authentication/authorization), but misses a streaming capability useful for production (it uses MJPG and not RTSP). The blog post at hand shows how to use RTSP streaming useful for production quality feeds, but misses authentication/authorization.
So for a true production ready streaming solution, the two concepts must be combined – this is indeed what the Nabto video customers already do for production (as already experienced by more than 1.5 million users of Nabto-enabled cameras, DVRs and NVRs). We will add a complete example with RTSP support + production ready pairing to use in such scenarios later.
The uNabto software is designed to be lightweight and able to run on a wide variety of embedded devices running Linux, RTOSes such as FreeRTOS and even on bare metal. For this example, we will run the uNabto application on a first generation RaspberryPi with access to an RTSP server on the same LAN. The example RTSP server can be accessed using the following parameters:
- IP: 192.168.0.105
- Port: 554
- Path: axis-media/media.amp
This means that from a PC on the same LAN, the video feed can be accessed by the following url: rtsp://192.168.0.105:554/axis-media/media.amp e.g. from the VLC player.
Without Nabto, you would have to setup port forwarding in your firewall to reach the device on the LAN. With Nabto, you don’t need any such fiddling, it works with zero configuration.
To connect remotely to the stream we first build the uNabto application on the RaspberryPi, adapt as necessary to your target device (we have a cross compilation guide in TEN030 Nabto Tunnels).
Note that the RaspberryPi with Nabto acts as a gateway: The Nabto software is installed on the RaspberryPi (which in the example has IP 192.168.0.101) – it then connects to the LAN address of the IP cam, which has IP address 192.168.0.105.
First, login to the RaspberryPi either directly using a keyboard and monitor, or if SSH is enabled, connect from your PC using SSH:
$ ssh [email protected] [email protected]'s password: ... Last login: Sat Sep 9 09:14:12 2017 from mclappe2.home [email protected]:~ $
To build the uNabto software, git and cmake must be installed on the RaspberryPi:
$ sudo apt-get update ... $ sudo apt-get install git cmake ...
The Raspberry is now ready to build the uNabto software.
Building the software
First, retrieve the uNabto source code from the github repo https://github.com/nabto/unabto.git:
$ mkdir git $ cd git $ git clone https://github.com/nabto/unabto.git Cloning into 'unabto'... remote: Counting objects: 5745, done. remote: Total 5745 (delta 0), reused 0 (delta 0), pack-reused 5745 Receiving objects: 100% (5745/5745), 2.63 MiB | 1.55 MiB/s, done. Resolving deltas: 100% (3388/3388), done.
Next, run cmake to prepare the build of the uNabto tunnel application. The key step in line 4 below is quite long, so scroll a bit to see it all or look below where we have zoomed in on it:
$ cd unabto/apps/tunnel $ mkdir build $ cd build $ cmake -DCMAKE_BUILD_TYPE=Release \ -DUNABTO_CRYPTO_MODULE=openssl_armv4 \ -DUNABTO_RANDOM_MODULE=openssl_armv4 .. -- The C compiler identification is GNU 4.9.2 -- The ASM compiler identification is GNU -- Found assembler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc ... -- Generating done -- Build files have been written to: /home/pi/unabto/apps/tunnel/build
Now you can build the tunnel:
[email protected]:.../build $ make -j Linking C executable unabto_tunnel
Check you can execute the unabto_tunnel binary (./unabto_tunnel)
Obtain Nabto device id and license key
For test and development of Nabto P2P streaming, please use the Nabto Cloud Console to obtain device ids and license key. The first 10 are free with no ads if using the non-free business model, unlimited licenses are free if using the ad-based business model.
For this step, you need a Cloud Console account – go to www.console.cloud.nabto.com and sign up if you haven’t done so already. The Cloud Console is our developer portal which runs on the same underlying platform as Nabto.
Next, create a product – you don’t have to tick the “Free product” checkbox, you get a few regular licenses for free with your account (in this way you don’t have to see ads for the first devices you use).
Next, generate a license by clicking the “Generate license” button and enter 1 as quantity:
You now have everything you need to run the tunnel on the device – the device id and the key revealed when clicking “Show License Key” are used in the next step:
Running the uNabto tunnel application
Log on to the RPI or continue your session above and execute the unabto_tunnel binary using the following command:
[email protected]:~ $ ./unabto/apps/tunnel/unabto_tunnel \ -d vtquiht9.xmnqf.trial.nabto.net \ -k 7d1d1f5ef09adc4398648f1a9614acf \ --allow-port 554 --allow-host 192.168.0.105 \ --no-access-control
The unabto_tunnel takes several arguments explained below:
- -d: The device ID you retrieved from the Cloud Console.
- -k: The license key you retrieved from the Cloud Console.
- –allow-port and –allow-host: This is the access information for the RTSP server as stated in the beginning of this document – multiple arguments can be specified to allow clients to connect to multiple services. The client controls what to connect to and these parameters restrict where it is allowed to proceed to.
- –no-access-control: The uNabto tunnel can use RSA public key fingerprint based access control to control who can access the tunnel. This example uses the Nabto Video / Nabto RTSP app as the Nabto Client as explained above and in the next chapter. These apps do not yet support this access control mechanism but must as of writing be used for RTSP streaming as outlined above. Therefore, the RSA public key fingerprint based access control is turned off in this example. This should never be used for production. Please read TEN036 about security in Nabto carefully before designing your own Nabto applications.
The uNabto Tunnel should now run and you should see the log line:
11:01:39:697 unabto_attach.c(591) State change from WAIT_GSP to ATTACHED
It tells you that the uNabto tunnel has been successfully attached (registered) to the Nabto Basestation and is ready for incoming connections.
Please note that the uNabto tunnel is now running in your current SSH session with the RaspberryPi. This means if you terminate your connection, the uNabto tunnel will also terminate. To have the tunnel running while not logged in, see “step 6: Configure the tunnel” in the previous blog post:
Note that if you use the init.d script as described on that page, you must change the commandline a bit from that example to match what has been described above: The unabto_tunnel binary needs the –no-access-control parameter for reasons given above. If you don’t specify this, the demo apps will not be able to connect.
Now that the uNabto tunnel is running, the video stream can be accessed remotely from your smart phone.
Running the Nabto Client App
On Android, go to Google Play Store and install the Nabto Video app. On iOS, go to Apple App Store and install the Nabto RTSP app. These apps are the only Nabto examples supporting RTSP; do not use the AMP Video apps for RTSP streaming (the AMP Video app from the previous blog example was a simple demo of how to configure pairing and authentication/authorization using just a simple MJPG feed).
After opening the Nabto Video app on Android or the Nabto RTSP app on iOS, tap the + button to add a new device. Enter the following information, corresponding to how you started the uNabto tunnel application:
- Video Player Type: MPEG
- Title: Nabto Example Player
- Name: vtquiht9.xmnqf.trial.nabto.net
- TCP host: 192.168.0.105
- Port: 554
- Path part of RTSP URL: axis-media/media.amp
Video Player Type must be always set to MPEG for RTSP feeds.
Title can be anything, or you can leave it out and the Name will be used as Title. The Name is the device ID obtained from the Cloud Console.
TCP host, Port, and Path are the access information for the RTSP server.
If the uNabto tunnel device is running on the same host as the RTSP server, the TCP host field can be left at the default (localhost). Otherwise specify the hostname or IP address of the RTSP server as the uNabto tunnel must use to reach the RTSP server.
After pressing save, the device is now visible from the device list. Tapping the device on the list will connect you to the stream, and you can see the remote video feed.
Final Notes on Security
For reasons stated above, this example uses no access control which should never be used for other than testing and examples. The example is only good for evaluating the raw RTSP streaming performance.
The Nabto platform provides a few different ways to control access. For typical deployments where a user can be paired with a camera, we recommend the “Paired Public Key Authentication” approach outlined in section 8.2 of TEN036 “Security in Nabto Solutions”. Basically this ensures that only clients that possess the private key of an RSA keypair where the public key has been installed on the RPI is allowed to access the camera. In addition to the introduction above, you can read more about it in the Fingerprint ACL module documentation in the uNabto SDK.
For a more general introduction to security in the Nabto platform, the remaining sections of TEN036 “Security in Nabto Solutions” are a good read – and also, we have a short introduction in this blog post.
Update 2019-05-03: We just added two blog posts on access control that goes into great detail – start with Access Control Part 1: Intro and Device.