{"id":543,"date":"2020-04-04T12:44:00","date_gmt":"2020-04-04T10:44:00","guid":{"rendered":"https:\/\/sebastian.fam-knopp.de\/?p=543"},"modified":"2020-07-22T12:53:09","modified_gmt":"2020-07-22T10:53:09","slug":"node-zoocam-ip-kameras-auf-sicherem-weg-oeffentlich-bereitstellen","status":"publish","type":"post","link":"https:\/\/sebastian.knopp.it\/?p=543","title":{"rendered":"node-zoocam – IP-Kameras auf sicherem Weg \u00f6ffentlich bereitstellen"},"content":{"rendered":"\n

Im Rahmen einer gr\u00f6\u00dferen Umgestaltung wurden in den Terrarien des Schulzoos des Collegium Josephinum einige IP-Kameras installiert. Diese sehr g\u00fcnstigen Kameras eines No-Name Herstellers mit Pan- und Tilt-Funktion (Rotation um zwei Achsen) stellten lediglich ein sehr rudiment\u00e4res Web-Interface zur Interaktion bereit, auf dem der Gro\u00dfteil der Einstellungsm\u00f6glichkeiten bereits garnicht funktionierte. Um den Kamera-Stream im Browser betrachten zu k\u00f6nnen, ist zudem ein Flash-Plugin notwendig, was moderne Browser \u00fcberhaupt nicht mehr unterst\u00fctzen. Ziel war es nun, die Bilder dieser Kameras irgendwie \u00f6ffentlich bereitzustellen. Hierzu ben\u00f6tigt man also eine M\u00f6glichkeit die Bilddaten automatisiert abzugreifen um sie geb\u00fcndelt darzustellen. Gleichzeitig w\u00e4re es f\u00fcr die sp\u00e4teren Nutzer sicherlich nett die Kameras auch selbst steuern zu k\u00f6nnen, um sich im Terrarium umzuschauen.<\/p>\n\n\n\n

OnVIF-Schnittstelle<\/h4>\n\n\n\n

Mit etwas Recherche stellte sich heraus, dass die Kameras bereits von sich aus den OnVIF-Standard unterst\u00fctzen. Der OnVIF-Standard dient der Spezifikation von Surveillance-Systemen. Neben IP-Kameras geh\u00f6ren dazu bspw. auch Sicherheitst\u00fcren, Sirenen oder Alarmleuchten. Durch Nutzung der OnVIF-Api-Schnittstellen lie\u00df sich die Adresse eines RTSP-Streams (Real-Time Streaming Protocol)<\/em> herausfinden, welchen die Kameras bereitstellen. Dieser Stream kann bspw. mit dem VLC-Player abgerufen werden. Leider gibt es aber bis heute keine M\u00f6glichkeit einen solchen Stream direkt im Browser darzustellen.<\/p>\n\n\n\n

Die Schnittstelle bietet noch weitere Features an. So lassen sich hier\u00fcber auch die Pan- und Tilt-Funktionen der Kamera ansteuern. Der Standard sieht hierbei eigentlich eine genaue Definition von Richtung, Geschwindigkeit und Dauer vor. Die Programmierer eines der verwendeten Kameramodelle haben sich aber f\u00fcr eine sehr rudiment\u00e4re Umsetzung dieser Schnittstelle entschieden und unterscheiden lediglich zwischen positiven und negativen Werten f\u00fcr die Richtungsangabe und drehen dabei immer mit fester Dauer und Geschwindigkeit. Bestimmte Wertekombinationen f\u00fcr Geschwindigkeit und Dauer lassen die Kamera sogar einfach neustarten.<\/p>\n\n\n\n

RTSP zu WebRTC<\/h4>\n\n\n\n

Mittels Einbindung des \u00f6ffentlichen Projekts webrtc-streamer<\/a> gelang es RTSP-Streams zu WebRTC-Streams zu wandeln. Die WebRTC-Schnittstelle dient normalerweise der Umsetzung von direkter Videotelefonie zwischen zwei Browsern, kann also direkt verwendet werden um Livebilder im Browser anzuzeigen.<\/p>\n\n\n\n

Den RTSP-Stream wollte ich jedoch aufgrund der kleinen verbauten Chips nicht direkt von den Kameras beziehen, sondern schaltete einen Live555-RTSP-ProxyServer<\/a> dazwischen. Diesen kann man auch \u00f6ffentlich erreichbar schalten und so dem Benutzer weiterhin ein eigenst\u00e4ndiges Abrufen des Kamerastreams im VLC-Player mit ausreichend Server-Ressourcen erm\u00f6glichen. F\u00fcr beide Projekte erstellte ich angepasste Docker-Container und programmierte anhand des webrtc-streamer Projekts mein Frontend, sodass es die Streams direkt von dort einbinden konnte.<\/p>\n\n\n\n

Da WebRTC auch teils komplexe Netzwerkarchitekturen unterst\u00fctzen k\u00f6nnen muss, ben\u00f6tigt es zwei weitere Dienste, einen STUN- und einen TURN-Server, um einwandfrei zu funktionieren. <\/p>\n\n\n\n

Ein STUN-Server<\/strong> wird ben\u00f6tigt, damit ein Browser mittels eines externen Dienstes seine tats\u00e4chliche \u00f6ffentliche IP-Adresse und Portnummer herausfinden kann, was gerade im Fall von NATing notwendig sein kann. Er macht Client und Server untereinander bekannt. Anschlie\u00dfend kann mittels Hole Punching<\/a> versucht werden, die bereits bestehende TCP-Verbindung weiter zu verwenden um so bspw. restriktive interne Firewalls zu umgehen und zwei eigentlich hinter Firewalls versteckte Dienste direkt miteinander zu verbinden. <\/p>\n\n\n\n

Klappt das nicht, gibt es als Fallback-M\u00f6glichkeit noch die Nutzung von Relay-Servern (sog. TURN-Server<\/strong>). Diese m\u00fcssen von Client und Server direkt erreichbar sein, empfangen den Datenverkehr beider Seiten und leiten ihn an die Gegenstelle als dritte Instanz weiter. Dadurch, dass s\u00e4mtlicher Datenverkehr dar\u00fcber laufen muss, m\u00fcssen sie eine entsprechende Bandbreite vorhalten und selbst betrieben werden.<\/p>\n\n\n\n

Fallback auf JPEG-Stream<\/h4>\n\n\n\n

Sollten alle Stricke rei\u00dfen und eine WebRTC-Verbindung nicht m\u00f6glich sein. Dies kann bspw. auch bei \u00e4lteren Mobilbrowsern der Fall sein, welche schlicht kein WebRTC unterst\u00fctzen, so kann mittels der OnVIF-Screenshot Schnittstelle regelm\u00e4\u00dfig ein aktuelles JPG des Kamerabildes abgerufen und weitergegeben werden. Der Server implementiert dies mit einer entsprechenden Proxyschnittstelle, um die Kameras im Falle vieler Anfragen nicht zu \u00fcberlasten.<\/p>\n\n\n\n

Webserver mit node.js<\/h4>\n\n\n\n

Der Webserver an sich basiert auf ExpressJS<\/a> und implementiert eine REST-API, welche die wichtigen Funktionen und \u00f6ffentlichen Adressen der Kameras bereitstellt. Er stellt au\u00dferdem ein Angular-Frontend bereit, welches die REST-API ansteuert und die Kamerastreams entsprechend visualisiert.<\/p>\n\n\n\n

Docker Container-Orchestration und Deployment<\/h4>\n\n\n\n

W\u00e4hrend der Entwicklung und auch im Produktivbetrieb kommt vor Allem docker-compose<\/a> zum Einsatz. Hiermit l\u00e4sst sich zur Entwicklungszeit schnell das gesamte Projekt bauen und unter Produktivbedingungen testen. Im Produktiveinsatz lassen sich dann recht einfach eine Versionierung und Aktualisierung durchf\u00fchren. Jeder Commit auf den Master-Branch des Projekts l\u00f6st den Bau einer neuen Version des Docker-Images aus, welches dann auf dem Produktivserver \u00fcber die Docker Registry einfach bezogen und gestartet werden kann.<\/p>\n\n\n\n

Zugriff auf das Projekt<\/h4>\n\n\n\n

Unter webcam.cojobo.net<\/a> kann man das Projekt selber ausprobieren. Der Sourcecode ist unter auf meinen GitLab-Server einsehbar<\/a>. Im Folgenden sind einige Screenshots des Projekts zu sehen.<\/p>\n\n\n\n