5
Mit Drucker über SPA 122 an Fritz-Box faxen
Hallo zusammen,
ich hatte seit längerer Zeit einen Cisco SPA an einer Fritz-Box im Einsatz, an dem ein Drucker mit Faxfunktion angeschlossen ist. Der SPA nutzte die Fritz-Box als VOIP-Proxy.
Nun habe ich vor einigen Wochen im Netzwerk die Funktion der Fritz-Box stark eingeschränkt, das Netzwerk verwaltet nun eine Unifi Dream Machine, die Fritz-Box stellt noch die Internetverbindung her, regelt DECT und VOIP-Telefonie. Da die Fritz-Box keinen Bridge-Mode zulässt, habe ich die Dream Machine als exposed host in der Fritz-Box eingestellt, alle Clients, auch der SPA122 sind an die Dream Machine angeschlossen.
Aktueller Stand ist nun: die SPA122 scheint die Verbindung zur Fritz-Box herstellen zu können, im Web-Interface wird als Status der Line "registered" angezeigt. In der Fritz-Box werden die ausgehenden und eingehenden Versuche auch angezeigt. Empfange ich aber ein Fax, nimmt das Gerät nicht ab, sende ich ein Fax, geht einfach keines raus.
Die UDP Ports 5060 + 5061 sowie die in der Weboberfläche des SPA122 angezeigten RTP Ports (auch UDP) sollten durch die Dream Machine an den SPA122 weitergegeben werden, da ich hierfür Portfreigaben (von any sources zur IP des SPA122) angelegt habe.
Ich denke, es liegt ein Problem mit dem Netzwerk vor, im SPA122 sehe ich TX-Datenpakete, aber keine RX-Pakete.
Weiss einer Rat, woran es noch liegen könnte?
Danke für Eure Hilfe
Stefan
ich hatte seit längerer Zeit einen Cisco SPA an einer Fritz-Box im Einsatz, an dem ein Drucker mit Faxfunktion angeschlossen ist. Der SPA nutzte die Fritz-Box als VOIP-Proxy.
Nun habe ich vor einigen Wochen im Netzwerk die Funktion der Fritz-Box stark eingeschränkt, das Netzwerk verwaltet nun eine Unifi Dream Machine, die Fritz-Box stellt noch die Internetverbindung her, regelt DECT und VOIP-Telefonie. Da die Fritz-Box keinen Bridge-Mode zulässt, habe ich die Dream Machine als exposed host in der Fritz-Box eingestellt, alle Clients, auch der SPA122 sind an die Dream Machine angeschlossen.
Aktueller Stand ist nun: die SPA122 scheint die Verbindung zur Fritz-Box herstellen zu können, im Web-Interface wird als Status der Line "registered" angezeigt. In der Fritz-Box werden die ausgehenden und eingehenden Versuche auch angezeigt. Empfange ich aber ein Fax, nimmt das Gerät nicht ab, sende ich ein Fax, geht einfach keines raus.
Die UDP Ports 5060 + 5061 sowie die in der Weboberfläche des SPA122 angezeigten RTP Ports (auch UDP) sollten durch die Dream Machine an den SPA122 weitergegeben werden, da ich hierfür Portfreigaben (von any sources zur IP des SPA122) angelegt habe.
Ich denke, es liegt ein Problem mit dem Netzwerk vor, im SPA122 sehe ich TX-Datenpakete, aber keine RX-Pakete.
Weiss einer Rat, woran es noch liegen könnte?
Danke für Eure Hilfe
Stefan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670185
Url: https://administrator.de/contentid/670185
Ausgedruckt am: 16.12.2024 um 01:12 Uhr
5 Kommentare
Neuester Kommentar
Eine wichtige Frage die du leider nicht beantwortet hast ist ob in dem o.a. Kaskaden Setup die "Dream" Firewall auch NAT macht oder nativ routet ohne NAT?
Da RTP, was die Voicedaten transportiert, ggf. dynamische (asymetrische) RTP Ports nutzt kann zwar die SIP Verbindung passieren (registered) aber eben die RTP Daten nicht die dann inbound am NAT scheitern was dann wiederum zu dem o. g. Verhalten führt. Hier wäre ein Wireshark Trace hilfreich ob dem so ist oder die RTP Daten passieren. "Symetric" RTP ist vorteilhafter.
Dieser Thread erklärt die Thematik recht gut.
Sofern doppeltes NAT und doppeltes Firewalling verwendet wird wäre ein rein geroutetes Design ohne NAT am kaskadierten Device besser was diese NAT Problematik sicher vermeidet.
Alternativ kann man die Fritte entfernen und durch ein reines nur Modem ersetzen (Vigor 167, Zyxel VMG3006 etc.) um den Internet Zugang direkt auf der Firewall zu terminieren. Die Fritte wird dann idealerweise im IP Host Modus im lokalen Netz rein nur noch als VoIP Anlage betrieben. Auch das vermeidet die NAT Problematik mit RTP.
Da RTP, was die Voicedaten transportiert, ggf. dynamische (asymetrische) RTP Ports nutzt kann zwar die SIP Verbindung passieren (registered) aber eben die RTP Daten nicht die dann inbound am NAT scheitern was dann wiederum zu dem o. g. Verhalten führt. Hier wäre ein Wireshark Trace hilfreich ob dem so ist oder die RTP Daten passieren. "Symetric" RTP ist vorteilhafter.
Dieser Thread erklärt die Thematik recht gut.
Sofern doppeltes NAT und doppeltes Firewalling verwendet wird wäre ein rein geroutetes Design ohne NAT am kaskadierten Device besser was diese NAT Problematik sicher vermeidet.
Alternativ kann man die Fritte entfernen und durch ein reines nur Modem ersetzen (Vigor 167, Zyxel VMG3006 etc.) um den Internet Zugang direkt auf der Firewall zu terminieren. Die Fritte wird dann idealerweise im IP Host Modus im lokalen Netz rein nur noch als VoIP Anlage betrieben. Auch das vermeidet die NAT Problematik mit RTP.
Hallo aqui,
Im SPA122 wird eine Range von UDP-Ports für RTP angezeigt, exakt diesen Bereich habe ich freigegeben, in der Hoffnung dass damit alles erledigt ist.
Die "Dream" Machine (ja, bescheuerter Name) lässt NAT leider nicht deaktivieren, so dass ich aktuell mit Doppel-NAT leben muss. Der Grund, weshalb ich nicht auf ein reines Modem gewechselt bin, liegt hauptsächlich an DECT und der VOIP-Telefonie - ich habe nicht gewusst, dass diese Funktionen auch als Client zur Verfügung stehen. Trotz Doppel-NAT hatte ich bisher keine Probleme, darum hatte ich gehofft, um die Anschaffung eines Modems herumzukommen. Wenn ich dies mit der Fritte als Modem nicht hinbekomme, muss ich das wohl in Betracht ziehen. So lange versuche ich noch, das Problem anderweitig zu lösen
Ich werde mal versuchen, mit Wireshark nachzuforschen, wo das Problem liegt. Die Nutzung von Wireshark ist nicht gerade eine meiner Stärken
Im SPA122 wird eine Range von UDP-Ports für RTP angezeigt, exakt diesen Bereich habe ich freigegeben, in der Hoffnung dass damit alles erledigt ist.
Die "Dream" Machine (ja, bescheuerter Name) lässt NAT leider nicht deaktivieren, so dass ich aktuell mit Doppel-NAT leben muss. Der Grund, weshalb ich nicht auf ein reines Modem gewechselt bin, liegt hauptsächlich an DECT und der VOIP-Telefonie - ich habe nicht gewusst, dass diese Funktionen auch als Client zur Verfügung stehen. Trotz Doppel-NAT hatte ich bisher keine Probleme, darum hatte ich gehofft, um die Anschaffung eines Modems herumzukommen. Wenn ich dies mit der Fritte als Modem nicht hinbekomme, muss ich das wohl in Betracht ziehen. So lange versuche ich noch, das Problem anderweitig zu lösen
Ich werde mal versuchen, mit Wireshark nachzuforschen, wo das Problem liegt. Die Nutzung von Wireshark ist nicht gerade eine meiner Stärken
Die Nutzung von Wireshark ist nicht gerade eine meiner Stärken
https://www.heise.de/ratgeber/Fehler-erschnueffeln-221587.htmlLesen und verstehen...
Wo im Netzwerk sollte ich denn die Datenpakete überwachen? Direkt am SPA122 mit einem Hub, an dem der Rechner mit Wireshark und der SPA hängen?
Hast du in der Konfiguration des SPA unter Voice -> LineX folgendes eingestellt?
Audio Configuration:
Preferred Codec: G771a
Symmetric RTP: YES
Modem Line: YES
Fax enable T.38: NO
Echo Canc Enable: NO
Silence Supp Enable: NO
Die fett hervorgehobenen sind wichtig und können dein Problem verursachen, wenn falsch konfiguriert.
T.38 ist unnötige und vor allem fehleranfällige umwandlerei, benutzt aber auch andere RTP-Ports.
Symmetric RTP ist noch wichtiger, denn das macht dass der SPA den RTP-Port als Quelle benutzt, auf dem er auch empfangen will.
Damit kannst (und solltest) du die angelegten Portforwarding-Regeln entfernen, denn die benötigst du bei Symmetric RTP nicht und sie können mehr Schaden anrichten als nützen.
Wenn die FritzBox nicht ganz dämlich ist, wird sie auch erkennen, dass SIP-Client-IP und die darin stehenden RTP-Ziel-Adressen sich unterscheiden und das intern angleichen.
Audio Configuration:
Preferred Codec: G771a
Symmetric RTP: YES
Modem Line: YES
Fax enable T.38: NO
Echo Canc Enable: NO
Silence Supp Enable: NO
Die fett hervorgehobenen sind wichtig und können dein Problem verursachen, wenn falsch konfiguriert.
T.38 ist unnötige und vor allem fehleranfällige umwandlerei, benutzt aber auch andere RTP-Ports.
Symmetric RTP ist noch wichtiger, denn das macht dass der SPA den RTP-Port als Quelle benutzt, auf dem er auch empfangen will.
Damit kannst (und solltest) du die angelegten Portforwarding-Regeln entfernen, denn die benötigst du bei Symmetric RTP nicht und sie können mehr Schaden anrichten als nützen.
Wenn die FritzBox nicht ganz dämlich ist, wird sie auch erkennen, dass SIP-Client-IP und die darin stehenden RTP-Ziel-Adressen sich unterscheiden und das intern angleichen.
1
