Ich habe vor kurzem einen Yeastar TG100 an unsere Compact 4000 angeschlossen. Eingehende Gespräche funktionieren ohne Probleme. Bei den ausgehenden Gesprächen wird jedoch nur ein Kanal weitergeleitet. Komischerweise tritt dieses Problem auch auf wenn ich mit einem internen VOIP Client über unseren Normalen VOIP Anbieter telefoniere. Die internen ISDN Telefonapparate funktionieren nach extern über unseren VOIP Anbieter ohne Probleme.
Anbei zwei Bilder aus Wireshark. Das erste Bild zeigt den internen VOIP Client zu der Auerswald. Das zweite Bild zeigt die Auerswald zu unserem Voip Anbieter. Wie man erkennen kann fehlt wirklich ein Kanal.
Hat zufällig jemand eine Idee was das sein kann? Vielen Dank für die Hilfe und einen schönen Abend
192.168.30.171 = Auerswald
212.117.203.45 = VOIP Anbieter
10.2.0.1 = Internes VOIP Telefon über VPN
Ich würde mal auf der Suche im VPN-Tunnel (NAT oder fehlende Route im Router für die Rückrichtung des Audiosignals) gehen, oder tritt das Verhalten auch bei lokalem VoIp-Telefon auf?
Frage wäre: was/wie wird der VPN-Tunnel aufgebaut, wo „landen“ die Daten, wird ggfs. NAT im Tunnel gemacht (wäre falsch).
Ggfs. auch, ob Stun für RTP Telefon aktiviert ist (wäre auch falsch).
Guten Morgen
Das Problem tritt auch intern auf. Es betrifft auch die interne ISDN -> GSM Adapter Verbindung. Es sieht irgendwie so aus als könne die Sprache nicht korrekt umgewandelt werden, der Datenstrom wird ja auch zweiseitig übertragen.
was ich mit meinen beschränkten VPN-/Netzwerkkenntnissen zumindest erkenne ist, dass Dein VPN-Router NAT in das lokale Netz macht.
In Deinem Bild „voip intern zu TZ.png“ taucht als Absende-IP des Streams, der eigentlich vom Telefon kommt, die IP 192.168.30.150 auf. Das ist aller Wahrscheinlichkeit nach Dein VPN-Router. Per SDP hat die Anlage vom Telefon aber erfahren, dass sie den RTP-Strom an die IP des Telefons schicken soll - sprich 10.2.0.1. Das Telefon ist aber für die Anlage gar nicht erreichbar, da es hinter dem VPN-NAT hängt. Ich bin mir fast sicher, dass Du von einem PC im Netz 192.168.30.0 das Telefon nicht anpingen kannst.
Du müsstest also entweder das NAT abschalten und dann das Routing in Deinem lokalen Netz entsprechend auf Vordermann bringen - oder im 192.168.30.0er Netz einen STUN-Server aufbauen, den Du im Telefon „10.2.0.1“ einträgst.
… hoffe das hilft weiter, kann aber auch sein, dass ich total daneben liege, da ich Deinen Netzaufbau nicht wirklich kenne
Denke nicht dass es am VPN liegt. Die Sprache wird ja zweiseitig über das VPN geleitet. Jedoch nur noch einseitig nach extern. Wie gesagt tritt das Problem auch von Intern ISDN zu Extern GSM via VOIP auf. Vermutlich ist irgendwo ein falscher Hacken gesetzt…
Gemäss Auerswald Handbuch:
Hinweise:
Sind alle außen liegenden Nebenstellen über einen VPN-Tunnel an das Netz der TK-Anlage angekoppelt, muss kein STUN-Server eingetragen werden.
Ist das IP-Protokoll IPv6 eingestellt, steht STUN als NAT-Methode weder für SIP noch für RTP zur Verfügung.
Die Seite Übersichten > Ports zeigt eine Übersicht über die Ports der TK-Anlage (eingehend und ausgehend).
Vermutlich melde ich mich dann mal beim Auerswald Support. Mal schauen was die meinen…
diese Aussage bezieht sich meiner Meinung nach auf ein VPN ohne NAT. Dort darf kein Externer STUN (einer beim Provider) verwendet werden. Mein Vorschlag bezog sich aber auf die Überwindung Deines internen VPN-NATs. Da wirst Du wahrscheinlich nur durch Betrieb eines eigenen STUN-Servers im 30er Netz darüber hinweg kommen.
Leider artet das ganze aber in Rätselraten aus, da die Beschreibung Deines Netzes nur schemenhaft vorliegt.
Welches VPN liegt denn wirklich vor?
Wie ist das Routing zwischen den Netzen organisiert?
in welchem Netz liegt das GSM-Gateway in Bezug auf die TK?
in welche Richtung wird denn was gehört, in welche nicht?
… so ist’s nur Raterei
Btw: Die aktuellen Versionen von Wireshark haben mich auch schon oft auf’s Glatteis geführt. In Deinem zweiten Bild zeigt Wireshark an, dass in beide Richtungen in etwa die gleiche Anzahl an RTP-Paketen laufen. Trotzdem ist keine Amplitude im Player zu sehen. Manchmal stellt der RTP-Player die nicht korrekt dar - Die Frage ist, ob da wirklich nur Stille in Richtung Telekom wegging. RTP-Pakete liefen ja offensichtlich.
I.d.R. hilft bei mir dieses Gespräch im Wireshark zu filtern, in eine separate Datei zu speichern und dann nochmal im Player anzuschauen. Das nur als Hinweis, um nicht dem falschen Hasen hinterherzurennen.
Zu der VPN Situation:
Unsere Netzsituation ist nicht wirklich goldig… Prinzipiell sitzen wir hinter einem Doppel Nat, was die Situation nicht einfacher macht. Öffentliche IP -> Router Provider -> Router Intern -> VPN Server (Synology). Wireshark scheint tatsächlich etwas aufzuzeichnen was es nicht gibt. Gespräche mit internen Teilnehmern sind nicht möglich, Rufaufbau klappt jedoch…
Werde mich wohl oder übel mal über das Thema STUN einlesen. -> Ist aber auch kein dringendes Problem, würde das testen von zuhause aus einfacher machen…
GSM Adapter:
Der GSM Adapter(192.168.30.175) und die Auerswald(192.168.30.171) hängen im gleichen Netz. Eingehende Gespräche vom GSM Adapter kommen mit guter Qualität an und funktionieren. Bei den ausgehenden Gesprächen funktioniert nur die eingehende Sprache, ausgehend wird nichts übertragen. Die eingehende Sprache ist jedoch extrem leise… Die angefügten Bilder stammen aus folgendem Aufbau: Internes ISDN Telefon <-> Auerswald <-> GSM Adapter <-> Mobiltelefon. Hilfreich für mich wäre den Fehler einzugrenzen, sprich mach der GSM Adapter Probleme oder liegt es an der Auerswald.
hab eben nochmal einen Blick auf die Bilder geworfen … was ich vorher gar nicht gesehen hatte war, dass die jeweiligen stummen Streams ja mit einer konstanten Linie angezeigt werden. Ich dachte das wäre der Rahmen der Grafik Sorry!
Da scheint ja die Anlage wirklich nichts in den abgehenden Stream zu schreiben.
Damit würde ich mich mal direkt an den Auerswald-Support wenden.
GSM Adapter:
Vielen Dank für die Bestätigung, dachte schon habe ein Problem mit meinen Ohren… . Habe das Problem mal Auerswald gemeldet.
VPN:
Es ist tatsächlich so, dass die Sprachpakete ihre Route nicht finden. Früher war der Gateway der VPN Server, da lief die Kommunikation ohne Probleme, leider kommt unser Gateway mit der Multi Nat Situation nicht klar (IP Öffentliche Adresse kann nicht geändert werden). Der VPN Dienst der Synology funktioniert jedoch. Wie Dauerbesetzt bereits vermutet hat geht auch kein Ping vom 192.168.30.0 Netz durch das VPN.
Wenn ich das Richtig verstanden habe: STUN Server auf der Auerswald aktivieren und anschliessend im VOIP Client diese IP Adresse als STUN Server eintragen?
Grüsse
Noch kurz zum Netzaufbau:
Öffentliche IP (178.192.172.202) -> Router Provider (192.168.1.1) -> Router Intern (192.168.30.1) -> TK Anlage und Synlogy VPN Server. Der Router vom Provider kann nicht in den Brigde Modus versetzt werden. Daher wurden dort alle Ports Richtung unseres Routers weitergeleitet, Zusätzlich ist auch DMZ Richtung unser Routers aktiviert.
So geht’s (leider) nicht. Wenn sich da nicht inzwischen was getan hat, dann können die Auerswald-TKs nicht selbst STUN-Server sein … also sie könnten schon, haben aber keinen. Die TK ist also komplett raus in Deinem Szenario. Du müsstest einen PC, oder Raspberry-PI oder soetwas in Dein 30er Netz stellen und darauf einen STUN-Server installieren. Dessen IP wird dann als zu verwendender STUN-Server in das TELEFON(!) eingetragen, da ja das Telefon herausbekommen muss, wie die IP-Adresse ist, unter der es von der Anlage gesehen wird. Der STUN-Server meldet dann die IP des Synology-NAS und den Port, den das VPN-NAT im 30er-Netz ausgesucht hat, an das Telefon. Damit ist das Telefon dann in der Lage sein SDP so aufzubauen, dass es der Anlage mitteilen kann „Du erreichst mich unter der IP des Synologies unter dem und dem Port“. Dorthin ist dann auch die Anlage in der Lage das Audio zu schicken, da das VPN-NAT diesen Rückkanal ja per NAT offen hält.
Gruß Dauerbesetzt
PS: Noch eine Variante wäre natürlich ein richtiges VPN-Gateway einzusetzen. Eines, was LAN-LAN-Kopplung beherrscht, oder Proxy-ARP … aber keines, was einfach nur NAT macht.
@VPN
Der Gateway könnte das, respektive hat es früher mit einer ‘richtigen’ Öffentlichen IP Adresse auch geklappt. Leider kann man beim Gateway keine alternative, öffentliche Adresse eintragen… Bleibt wohl nur das Hobby VPN
@GSM Gateway
Anbei die Antwort von Auerswald:
nach Rücksprache mit einem Kollegen verhält sich das GSM SIP Protokoll Technisch nicht Konform. Wir bekommen von dem GSM-Gateway keine Bestätigung das der Ruf Extern Klingelt oder aber entgegengenommen worden ist, dadurch schalten wir keinen Audio weg frei.
Die Antwort von Auerswald lässt mich nicht in Ruhe. Bevor ich das Teil zurückgebe möchte ich doch noch gerne wissen was da falsch läuft. Wo genau ist hier der Fehler?
.175 = GSM Adapter
.171 = Auerswald
@VPN:
Habe die Lösung für mein Problem gefunden, eine statische Route im Gateway löste das Problem. Nun werden die Pakete direkt an die Synology weitergeleitet und Ton funktioniert auf beide Seiten.
@GSM Adapter
Der Hersteller des GSM Adapters passt nun die Firmware an dass alles schön konform läuft und die korrekt agierende Auerswald auch mal was sendet.
dank Dir für die Rückmeldung. Das spannende an Deinem Aufbau ist ja eigentlich, dass Du dasselbe Symptom mit zwei völlig verschiedenen Fehlern zustandebekommen hast.
Der Fehler mit den VPN-Telefonen lag im IP-Routing, der Fehler beim Ruf zum GSM-Gateway lag an der Firmware des GSM-Gateways.
Das erschwert natürlich die Problemlösung, wenn man erstmal davon ausgeht, dass beides identische Ursachen hat.
Naja … Hauptsache Du hast (bald) 'ne Lösung für beides.
Sorry!
. Habe das Problem mal Auerswald gemeldet.