Bij mijn weten, en ben ook maar een relatieve leek op dit vlak:
WebRTC is een protocol om voornamelijk videa en audio "real time" tusssn twee of meer apparaten uit te wisselen. En dus de "camera beelden worden via WebRTC in de browser / app ontvangen" (en wordt dus ook gebruikt door veel software voor videobellen).
Om de verbinding zo real time mogelijk te maken wordt er gepoogd om een directe verbinding tussen beide apparaten op te zetten. Hiervoor is dus een stuk "discovery" nodig waarbij beide kanten een berg informatie met elkaar uitwisselen v.w.b. welke IP adressen ze hebben, welke routes doorlopen worden, etc. Dit aangezien de client meerdere IP adressen kan hebben, maar deze ook meerdere routes naar het internet heeft (dus een router met 2 of meer actieve internetaansluitingen), er mogelijk VPNs in het spel zijn die een route tussen twee endpoints geeft, you name it. STUN is daarbij hét protocol dat (door WebRTC, en andere protocollen) gebruikt wordt om deze "discovery" te doen. De initiële informatie uitwisseling vindt dus plaats via een STUN server die van beide apparaten informatie ontvangt hoe ze bereikbaar zijn etc. en "onderhandeld" over welke route uiteindelijk het WebRTC verkeer zal verlopen.
Echter kan het ook zijn dat een rechtstreekse verbinding tussen beide apparaten niet mogelijk is. Bv als je buiten de deur bent en je zit op de telefoon. Jouw server kan de data niet sturen naar de telefoon want jouw telefoon bevindt zich achter (CG)NAT van de provider en de firewall op de telefoon gooit mogelijk roet in het eten, en de telefoon kan de data niet ophalen vanaf de server omdat poorten dicht staan / NAT wordt toegepast etc. In dat geval heb je dus een tussenliggende server nodig waar beide partijen mee kunnen verbinden. Zodat de server de data stuurt naar de tussenpartij en de telefoon de data ook weer ontvangt van de server. En dat is dus een TUN server. Waarbij het dus zo zal zijn dat de STUN server bepaald dat er geen rechtstreekse verbinding mogelijk is en TUN gebruikt moet worden.
Dat de STUN server van Open Home is zal dan zijn omdat dit alleen nodig is voor een kleine informatie uitwisseling vooraf om te onderhandelen hoe de verbinding op te zetten. Dat is dus relatief goedkoop (en daardoor "gratis" aan te bieden?). De TUN server zal, indien deze nodig is, echter de volledige WebRTC datastream (video / audio) overheen gaan. Dit verbruikt dus veel meer resources (vooral data dus, elk pakketje dat binnen komt wordt een-op-een doorgestuurd naar de andere kant, en bij video zijn dat natuurlijk flink wat pakketjes (per seconde)). En dat zal de reden zijn dat dat bij Nabu Casa zit (achter het abonnement neem ik aan?).
Maar... er zijn meerdere publieke STUN en TUN servers en je zou ook je eigen kunnen opzetten. En die zul je dan vast ook ergens in HA kunnen configureren om te gebruiken vermoed ik.