Problem
Bei den ersten OnSite Installationen stoßen viele auf das Problem der fehlenden Tonübertragung (RTP Stream), welches meist nur interne oder nur externe Geräte betrifft.
Ursache ist hier meist ein “Split-DNS” (FQDN wird intern auf die interne IP aufgelöst und extern auf die öffentliche IP) und/oder fehlendes “Hairpinning” (also ein zusätzliches SourceNAT/masquerading für den zur pascom weitergeleiteten (forwarding) Traffic von internen Geräten).
Lösung
Wir empfehlen daher OnSite das erste Interface mit „Einfach ohne Mobile Client Pairing“ für die lokalen Geräte zu konfigurieren und das sekundäre Interface als „Sicher (darf im gleichen Netz liegen) und aktiviertem Mobile Client Pairing“. Das Portforwarding (https://www.pascom.net/doc/de/howto/mobile-access/) muss dann auch auf das sekundäre/zweite Interface verweisen (während das erste ausgehend zum SIP Provider die Verbindung aufbauen muss).
Beispiel
Beim Kunden befindet sich nur ein Netzwerk.
Der Router hat intern die IP 192.168.100.254/24.
Das Primärinterface der pascom erhält die 192.168.100.100/24 mit der 192.168.100.254 als default Gateway und einem vernünftigen DNS Server. Auf dem Router darf dieses Interface/diese IP idealerweise uneingeschränkt raus (eine Einschränkung wäre aber möglich: die pascom muss mind. unseren Lizenzserver, den DNS+NTP+Mail Server sowie den SIP Provider erreichen können).
Als FQDN trägt man hier die interne IP 192.168.100.100 ein. Sollte es Endgeräte geben die SIP TLS und/oder SRTP nicht im benötigten Umfang unterstützen, kann man für dieses Interface bezüglich VoIP auch den einfachen Modus (udp+rtp) verwenden, da es ohnehin nur intern verwendet wird. Das Mobile Pairing wird hier deaktiviert.
Dem Sekundären Interface kann man dann eine IP im gleichen Netz mit gleichem Default Gateway geben, da dieser Container das Interface “zu sich” zieht und sozusagen als eigenständiger Host im Netzwerk agiert. Beispielsweise die 192.168.100.101/24 und ebenfalls die 192.168.100.254 als Gateway. Bei VoIP verwendet man den sicheren Modus (TLS+SRTP)und aktiviert hier auch das Mobile Pairing.
Auf der Firewall werden dann die benötigten Ports (mind. TCP 5061,5222 und UDP 30000 bis 35000) von der öffentlichen IP auf die 192.168.100.101 weitergeleitet (forwarding).
Technischer Hintergrund
Beim Start des Interface Containers löst der pascom Host den eingetragenen FQDN auf und parametriert damit den Session Border Controller (SBC, bei uns in Form des Kamailio).
Dies ist u. a. notwendig um den externen Clients als RTP Ziel, beispielsweise die öffentliche IP, mitzuteilen. Wird jedoch SPLIT DNS eingesetzt und der pascom Host erhält bei der Namensauflösung die interne IP, dann scheitert dadurch die Tonübertragung für externe Geräte. Umgekehrt erhalten interne Geräte die dieses Interface verwenden die öffentliche IP als RTP Ziel.
Hier kann es zu folgendem Problem kommen (aufgrund dessen viele Split DNS einsetzen und weswegen wir ein “internes” und ein “externes” Interface empfehlen):
Der Client schickt seine Pakete an die öffentliche IP, diese werden (je nach Konfiguration) von der Firewall auch korrekt an die pascom weitergeleitet, jedoch ergibt sich hier das Problem, dass entweder
- der Client im gleichen Netz wie die pascom ist und die pascom dadurch ein Paket vom Client mit der MAC Adresse des Routers erhält. (Der Router hat jedoch schon einen ARP Eintrag und der Client hat bei direkter Kommunikation ggf. ebenfalls bereits einen Eintrag, oder beim ARP Lookup die MAC des Clients ermittelt wird und nicht die des Routers). Das Paket wird dadurch vom pascom Host verworfen.
Oder
- der Client in einem anderen Netz wie die pascom ist, jedoch kennt der pascom Host eine andere Route zum Client und nimmt dadurch nicht wieder den Rückweg über den weiterleitenden (forwarding) Router. Dadurch kann keine Rückübersetzung stattfinden und der Client erhält eine Antwort von der internen privaten IP, obwohl bei der öffentlichen IP angefragt wurde und kann daher diese Antwort nicht dieser Verbindung zuweisen. Auch hier wird die Kommunikation scheitern da die Antwort beim Client verworfen wird.
Deswegen ist es notwendig, das interne Geräte die über das Portforwarding der öffentlichen IP mit der pascom kommunizieren auf dem Router zusätzlich vom Router maskiert (masquerading/SourceNAT) werden, damit die Anlage zum einen die korrekte MAC zur IP sieht und zum anderen nur dem Router antworten kann (da die neue Quelle ja der Router selbst ist) und nicht mehr auf ggf. anderem Wege dem Client direkt. So kann der Router die Antworten korrekt rückübersetzen.