VoIP-Telefonie - Eingehende Anrufe werden abgebrochen nach ca. 30 Sekunden (LTE-Versorgung, SIP)

[rkl7593]

Guten Tag,

zu Beginn hoffe ich, dass ich im richtigen Bereich gelandet bin, ansonsten verschiebt es gerne.
Seit ca. 4 Monaten bin ich privater Betreiber einer Senioren-WG, in welcher die jeweiligen Mieter Internet und Telefonie nutzen können. Aktuell läuft die Versorgung noch über LTE, da das Objekt noch neu ist und erst seit kurzem die Glas-Zuleitung liegt, um über DSL zu versorgen. Umgestellt wurde dies allerdings noch nicht, da mein Mitstreiter (der eigentliche Techniker und Experte über die gesamte Anlage) nun leider gesundheitsbedingt nicht mehr zur Verfügung steht.

Ich versuche euch mal als Laie den Aufbau zu erklären und habe zum graphischen Verständnis es künstlerisch wertvoll nachgezeichnet. Dieser gestaltet sich deshalb so, um über die Fernwartung mögliche Probleme oder Störungen bei einzelnen Mietern schnell beheben zu können. Und zum Anderen einfach auch auf das Vertrauen in den Techniker, der sich eben damit auskennt und es deshalb so aufgebaut hat (in der Reihenfolge miteinander verbunden):

1. welotec-LTE-Router mit einer Datenkarte
2. pfsense (Firma: Netgate)
3. Switch (Firma: TP-Link)
4. DSLAM (Firma: ZTE)
5. Fritzbox 7530 je Wohneinheit (Firma: AVM)

Zudem für die Fernwartung am DSLAM noch ein Pi.
Die IP-Telefonie läuft über eine auswärtige Firma, wo die Rufnummern aktiviert werden und kontrolliert werden können, es läuft alles über so einen SIP-Server, soweit ich weiß.
Die LTE-Versorgung scheint soweit zu laufen, die einzelnen Fritzboxen weisen gute Geschwindigkeiten im Down- und Upload aus.
Über die pfSense erhalten die Fritzboxen ihre jeweilige IP-Adresse. In den Fritzboxen sind die bestellten Rufnummern konfiguriert. Auch die dortigen Einstellungen in der Fritzbox haben wir anhand der empfohlenen Vorgaben umgesetzt. Auch die Funktion, dass nach 30 Sekunden immer wieder ein Ping gesendet wird. Transportprotokoll innerhalb Fritzbox und pfsense ist UDP für die Telefonie.

Nun haben wir eigentlich seit Beginn (ca. Anfang April) das Problem, dass die VoIP-Telefonie folgendes Problem aufweist:

Der erste, eingehende Anruf kann nur ca. 30-32sekunden aufrecht erhalten werden. Anschließend bricht es den Anruf ohne Vorankündigung oder Meldung ab. Ein direkt darauf folgender zweiter, eingehender Anruf kann anschließend problemlos über einen längeren Zeitpunkt getätigt werden. Ausgehende Anrufe sind nicht betroffen, laufen normal durch.

Was konnte ich noch so herausfinden:

• wenn ich mich über den Pi auf die jeweilige Fritzbox schalte, haut man mich nach ca. 5-10 Minuten (sehr unterschiedlich) aus der Fritzbox raus bzw. kann ich innerhalb der Fritzbox nichts mehr machen (Seite kann nicht geöffnet werden).
• innerhalb der Fritzbox habe ich die Einstellungen geprüft und an sich keine Auffälligkeiten entdeckt
• wenn ich vorher an der Fritzbox zu tun hatte, kam auch der erste Anruf über einen längeren Zeitraum durch
• die üblichen Ports (5060 usw.) werden benutzt
• in der pfSense habe ich an allen Ecken und Enden (mithilfe Handbuch Netgate) nach Einstellungen gesucht, die entweder was mit 30 Sekunden oder mit einer Passivität zu tun haben
• die Telefonie-Historie der jeweiligen Fritzboxen (aktuell ca. 10 Stück aktiv im Einsatz) zeigt, dass ein erster eingehender Anruf dann funktioniert, wenn bis ca. 30-40 Minuten vorher auch etwas aktiv an bzw. mit der Fritzbox (z.B. Festnetz- oder Internetnutzung) gemacht wurde. Bei größeren Zeitabständen wird die Fritzbox wieder passiv.

Vermutung:

• Wenn die Fritzbox längere Zeit nicht "aktiv" war, geht der erste Anruf nicht durch. Es scheint, als würde die Fritzbox ein Signal senden, um "aktiv" zu werden (z.B. an den SIP-Server) und erhält zu spät ein Rücksignal, sodass nach 30 Sekunden der Anruf abgebrochen wird. Irgendwann kommt aber dann doch ein Signal, sodass die Fritzbox dann den zweiten Anruf problemlos eingehen und durchlaufen lässt.

Ziel/Anfrage:

• einfach gesagt - es muss behoben werden. Aber ich hätte auch gern einfach erstmal Lösungsvorschläge, was man noch machen kann, um zu prüfen oder zu probieren. Ich habe leider auch Umsatzverluste im Sinne von Auszügen aus den Wohneinheiten und so etwas möchte ich vermeiden.
• wenn ihr noch Informationen braucht, fragt mich bitte so genau wie möglich und im Bestfall, wo ich die Informationen finden kann
• wichtige Info - die Fernwartung ist nicht umsonst eingerichtet. Ich betreue das Objekt aus über 100km Entfernung - aktuell ist es nicht wirklich möglich, zeitnah für einzelne Tests oder Ähnliches vor Ort zu sein.

Ähnliche Fehlermeldungen hier und in anderen Foren habe ich bereits abgeklappert und nichts gefunden. Ich danke für jeden Hinweis.

VG
Robert

 

[gforce4711]

Welche Firmware ist auf den FBs? Ist diese aktuell?

 

[Murray B.]

Was für Telefone werden verwendet? Was sagt der SIP-Provider zu dem Thema?

 

[TheCadillacMan]

Das ist alles ein relativ komplexer Aufbau. Mir erschließt sich schon nicht warum man da exotische Hardware wie einen DSLAM installiert hat wenn das Objekt sowieso neu ist.

einfach gesagt - es muss behoben werden. Aber ich hätte auch gern einfach erstmal Lösungsvorschläge, was man noch machen kann, um zu prüfen oder zu probieren. Ich habe leider auch Umsatzverluste im Sinne von Auszügen aus den Wohneinheiten und so etwas möchte ich vermeiden.

Ganz ehrlich: Dann hol dir Profis dafür. VoIP-Probleme sind teils sehr aufwändig zu debuggen und man muss dafür wissen was man tut. Dazu kommt die besondere Hardware.
Du willst Geld damit verdienen also musst du auch bereit sein dafür Geld auszugeben. Die Anlage braucht ja auch langfristig Wartung.

 

[rkl7593]

Welche Firmware ist auf den FBs? Ist diese aktuell?

Ja, die ist aktuell - FRITZ!OS: 07.27. Haben auf allen Fritzboxen, die genutzt werden und den anderen Geräten nach Updates gesucht bzw. diese aktualisiert.

Ergänzung (21. Juli 2021)

Das ist alles ein relativ komplexer Aufbau. Mir erschließt sich schon nicht warum man da exotische Hardware wie einen DSLAM installiert hat wenn das Objekt sowieso neu ist.


Ganz ehrlich: Dann hol dir Profis dafür. VoIP-Probleme sind teils sehr aufwändig zu debuggen und man muss dafür wissen was man tut. Dazu kommt die besondere Hardware.
Du willst Geld damit verdienen also musst du auch bereit sein dafür Geld auszugeben. Die Anlage braucht ja auch langfristig Wartung.

Die Wartung erfolgt ja auch durch unsere Jungs, jedoch sind diese aktuell aus gesundheitlichen Gründen (Corona) nicht arbeitsfähig bzw. im Urlaub. Ich will mich selbst halt auch einfach mal ein wenig erkunden und weiterbilden in dieser Hinsicht.

Bezüglich Frage nach den FN-Geräten: Diese kommen meist durch die Mieter selbst mit. Aktuell sind das z.B. noch nicht ganz so alte Gigasets oder auch das C5/C6.

Bezüglich SIP-Provider: Dieser hat keine Auffälligkeiten gefunden. Mehrere von uns angefertigten Protokolle wurden auch von denen geprüft, jedoch ohne Störung/Problem.

 

[Tunguska]

Was genau ist denn das langfristige Ziel?
Ein Kabelanschluss für jede Wohneinheit oder ein Kabelanschluss mit Sharing über 12 Wohneinheiten?

 

[rkl7593]

Was genau ist denn das langfristige Ziel?
Ein Kabelanschluss für jede Wohneinheit oder ein Kabelanschluss mit Sharing über 12 Wohneinheiten?

Das Ziel ist, dass bei einem eingehenden Anruf dieser länger als 30 Sekunden geht. Der Mieter wird auf seinem FN-Gerät angerufen. Dieses ist an die Fritzbox angeschlossen bzw. mit dieser verbunden. In der Fritzbox sind die SIP-Daten zur Datenweiterleitung über Server XY eingespeichert. Damit also die Verbindung bzw. Datenübertragung zum SIP-Server des Anbieters funktioniert.

Die Mieter erhalten von uns quasi Festnetz- und Internetnutzung. Beides über die Fritte. Auf Netzebene 4 sind vom Technikraum im Keller Fernmeldeleitungen bis in die jeweiligen Wohneinheiten gelegt. Von der Zuleitung (ÜP Straße) in das Haus ist Glas gelegt, wird aber aktuell noch nicht genutzt, weil in Bauphase. Deshalb aktuell LTE-Router, welcher über CAT an die pfSense angeschlossen ist.

 

[Mercator]

Hier ein ähnliches Problem, Ursache war ein Netgear Gerät.
https://de.comm.internet.telefonie....schalten-der-voip-verbindung-nach-30-sekunden

 

[snakesh1t]

Mal doof gefragt: aber wäre eine Telefonanlage mit einem Anlagenanschluss mit einem großen Rufnummerblock (jeder Mieter erhält 3 Durchwahlen) und ein Router mit mehreren Netzen (jeder Mieter erhält ein eigenes Netzwerk mit DHCP etc., z.B. per VLAN) nicht einfacher gewesen?

 

[FlaTLin3]

Ich vermute eine (für VOIP) ungünstige Konfiguration der pfSense.

Zunächst wäre da das Signalling von SIP (für gewöhnlich auf UDP-Port 5060). Hier nimmt die FB alle 30 Sekunden Kontakt zum VOIP-Dienstleister auf. Es besteht dann (abhängig von den Routern die NAT machen) ein Zeitfenster in welcher dieser Ereignisse an den SIP-Client (Fritzbox) senden kann. Das ist einfach ein Zustand den sich der NAT-Router für eine gewisse Zeit merkt. Dieser Zeitraum ist bei pfSense Standardmäßig ebenfalls 30 Sekunden. Wenn es nun zu einer Verzögerung kommt, dann kann der Zeitraum ablaufen und die pfSense wird die vom VOIP-Dienstleister verwerfen. Das resultiert dann in einem Verbindungsabbruch. Das lässt sich umgehen indem in den erweiterten Firewall-Einstellungen der "Conservative"-optimization-mode eingestellt wird. Dieser verlängert den Zeitraum in dem der Verbindungs-Status für UDP gehalten wird. Siehe dazu: https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html

Als zweites wäre da noch die RTP-Verbindung für das Audio während des Gesprächs. Hier wird üblicherweise UDP-Hole-Punching mittels STUN(-Server) betrieben. Eine Technik die bei fast allen P2P-Kommunikationen Anwendung findet. Diese hat jedoch ernste Schwierigkeiten wenn der NAT-Router ein "striktes NAT" macht. Das ist der Fall, wenn die Gegenstelle nicht erraten kann auf welcher Port-Nummer ein Client später erreichbar sein wird. Genau das verhindert eine standardmäßig eingerichtete pfSense aber indem es für jede UDP-Verbindung eine neue Port-Nummer auswürfelt. Das Verhalten kann geändert werden, indem eine NAT-Outbound-Regel mit der Option "Static Port" konfiguriert wird. Wenn bekannt ist, welche IP&Ports für die RTP-Verbindung genutzt werden kann man die Regel darauf beschränken. Ich tendiere jedoch zur besseren "NAT-Verträglichkeit" einfach eine Regel für alle UDP-Pakete zu machen. Denn das "strikte NAT" bereitet auch diversen anderen Diensten (Skype, Konferenzsoftware, Multiplayer-Videospiele, etc.) Probleme. Siehe dazu: https://docs.netgate.com/pfsense/en/latest/nat/outbound.html

 

[brainDotExe]

Das hört sich schwer nach einem NAT Problem an.
Probiere die Tipps von @FlaTLin3 aus.
Ansonsten könnte das aber auch am eventuellen Provider NAT (bei Mobilfunk eher die Regel) liegen. Diesbezüglich hast du keine Einstellungsmöglichkeiten.

Generell ist VoIP hinter (mehrfachem) NAT ein Alptraum. Wenn möglich VoIP per IPv6 abwickeln, da hat man bedeutend weniger Probleme.

 

[rkl7593]

Ich vermute eine (für VOIP) ungünstige Konfiguration der pfSense.

Zunächst wäre da das Signalling von SIP (für gewöhnlich auf UDP-Port 5060). Hier nimmt die FB alle 30 Sekunden Kontakt zum VOIP-Dienstleister auf. Es besteht dann (abhängig von den Routern die NAT machen) ein Zeitfenster in welcher dieser Ereignisse an den SIP-Client (Fritzbox) senden kann. Das ist einfach ein Zustand den sich der NAT-Router für eine gewisse Zeit merkt. Dieser Zeitraum ist bei pfSense Standardmäßig ebenfalls 30 Sekunden. Wenn es nun zu einer Verzögerung kommt, dann kann der Zeitraum ablaufen und die pfSense wird die vom VOIP-Dienstleister verwerfen. Das resultiert dann in einem Verbindungsabbruch. Das lässt sich umgehen indem in den erweiterten Firewall-Einstellungen der "Conservative"-optimization-mode eingestellt wird. Dieser verlängert den Zeitraum in dem der Verbindungs-Status für UDP gehalten wird. Siehe dazu: https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html

Als zweites wäre da noch die RTP-Verbindung für das Audio während des Gesprächs. Hier wird üblicherweise UDP-Hole-Punching mittels STUN(-Server) betrieben. Eine Technik die bei fast allen P2P-Kommunikationen Anwendung findet. Diese hat jedoch ernste Schwierigkeiten wenn der NAT-Router ein "striktes NAT" macht. Das ist der Fall, wenn die Gegenstelle nicht erraten kann auf welcher Port-Nummer ein Client später erreichbar sein wird. Genau das verhindert eine standardmäßig eingerichtete pfSense aber indem es für jede UDP-Verbindung eine neue Port-Nummer auswürfelt. Das Verhalten kann geändert werden, indem eine NAT-Outbound-Regel mit der Option "Static Port" konfiguriert wird. Wenn bekannt ist, welche IP&Ports für die RTP-Verbindung genutzt werden kann man die Regel darauf beschränken. Ich tendiere jedoch zur besseren "NAT-Verträglichkeit" einfach eine Regel für alle UDP-Pakete zu machen. Denn das "strikte NAT" bereitet auch diversen anderen Diensten (Skype, Konferenzsoftware, Multiplayer-Videospiele, etc.) Probleme. Siehe dazu: https://docs.netgate.com/pfsense/en/latest/nat/outbound.html

Zu deinem ersten Abschnitt: Also kann es sein, dass dieses Ereigniss/Paket einfach länger als 30 Sekunden braucht, um alle NAT´s zu durchbrechen und man eben in der Firewall der pfSense die Einstellung etwas zeitlich nach oben schraubt?

Welchen Zusammenhang hat dies dann damit, dass der darauffolgende 2.eingehende Anruf durchkommt? Besteht dann bereits über die Eigenschaften vom ersten Paket die jeweilige Beziehung oder wie kann ich mir das vorstellen?

Ansonsten war ich auch schon bei der Firewall der pfSense etwas skeptisch, wenngleich ich selbst auch nicht immer verstehe, warum wir teilweise 3-fach NAT nutzen. Mir wird dann immer der Schutz als Argument genannt. Aber danke erstmal für die Einblicke und Tipps, das bringt mich in meinem Verständnis schon mal weiter. Und die Option an der pfSense könnte ich auch mal ausprobieren.

 

[rkl7593]

Das hört sich schwer nach einem NAT Problem an.
Probiere die Tipps von @FlaTLin3 aus.
Ansonsten könnte das aber auch am eventuellen Provider NAT (bei Mobilfunk eher die Regel) liegen. Diesbezüglich hast du keine Einstellungsmöglichkeiten.

Generell ist VoIP hinter (mehrfachem) NAT ein Alptraum. Wenn möglich VoIP per IPv6 abwickeln, da hat man bedeutend weniger Probleme.

Könnte sich deine Vermutung dann auflösen, wenn wir von der Mobilfunk-SIM-Karte auf DSL umschwenken? Weil dort andere Einstellungen gegeben sind? Wir hatten auch beim Anbieter der Datenkarte nachgehakt, ob es da Sperren gibt, die noch rausmüssen. Wir hatte auch den LTE-Router von welotec zu AVM gewechselt. Nachdem wir dann die Karte eingelegt hatten, hatten wir aber nach wenigen Sekunden einfach keine Bandbreite mehr zur Verfügung. Nach einigen Versuchen sind wir dann zumindest erstmal wieder zu welotec zurück.

Das Problem besteht eben nur beim jeweils ersten, eingehenden Anruf.

 

[FlaTLin3]

Zu deinem ersten Abschnitt: Also kann es sein, dass dieses Ereigniss/Paket einfach länger als 30 Sekunden braucht, um alle NAT´s zu durchbrechen und man eben in der Firewall der pfSense die Einstellung etwas zeitlich nach oben schraubt?

Welchen Zusammenhang hat dies dann damit, dass der darauffolgende 2.eingehende Anruf durchkommt? Besteht dann bereits über die Eigenschaften vom ersten Paket die jeweilige Beziehung oder wie kann ich mir das vorstellen?

Soweit mir bekannt werden die Zeitfenster für Verbindungszustände nie dynamisch verändert. Dieser bleibt bei der pfSense immer auf dem eingestellten Wert, der üblicherweise durch den "optimation mode" vorgegeben wird.

Das es später stabiler funktioniert kann verschiedene Ursachen haben. Es kann aber sein das nach dem Wiederverbinden das Timing der Pakete "besser" wird. Oder das QOS (quality of service) Latenzen positiv beeinflusst. Letztlich kann nur eine Aufzeichnung des Datenverkehrs darüber mehr Einblick liefern.

Könnte sich deine Vermutung dann auflösen, wenn wir von der Mobilfunk-SIM-Karte auf DSL umschwenken? Weil dort andere Einstellungen gegeben sind? Wir hatten auch beim Anbieter der Datenkarte nachgehakt, ob es da Sperren gibt, die noch rausmüssen. Wir hatte auch den LTE-Router von welotec zu AVM gewechselt. Nachdem wir dann die Karte eingelegt hatten, hatten wir aber nach wenigen Sekunden einfach keine Bandbreite mehr zur Verfügung. Nach einigen Versuchen sind wir dann zumindest erstmal wieder zu welotec zurück.

Meiner Erfahrung und Erwartung nach sind übliche Kunden-(NAT-)Router (DSL, Kabel-TV, LTE, etc.) bezüglich der Zeitfenster ihrer gehaltenen Verbindungszustände meist großzügiger als eine (Standard-)pfSense. Außerdem verwenden sie keine randomisierung der Portnummern und unterstützen UDP-Hole-Punching so gut sie können. Gleiches denke ich von dem "Carrier-grade NAT" das beim Mobilfunk üblich ist. Wären die Geräte/Mobilfunkanbieter zu streng, dann würde es nur so an Störungsmeldungen frustrierter Kunden hageln das dieser oder jener Dienst nicht funktioniert.

Ich meine mich daran zu erinnern das die AGBs von Mobilfunkanbietern die Nutzung ausgewählte Dienste untersagten. Besonders VOIP, da sich damit die kosten für Mobil-Telefonie umgehen ließen. Ich habe mich damit aber nicht länger beschäftigt. Kann sein das, dass wegen Netzneutralität und LTE/5G als DSL-Ersatz kein Thema mehr ist.

 

[rkl7593]

Update: Es gibt ja im Bereich...
System / erweiterte Einstellungen / Firewall & NAT / State Timeouts
...die Möglichkeit, trotz der weiter oben auf der Seite eingestellten Firewall-Variante <Normal> , die Timeouts für UDP-Protokolle, mit denen wir ja über Fritzbox verkehren, manuell hochzustellen. Laut einem Netgate-Forum lohnt es sich, diese einmal weiter hoch zu stellen:

UDP First: 300
UDP Single: 150
UDP Multiple: 900

Ist das eine Option, um dem Paket zu ermöglichen, selbst nach 30 Sekunden über das UDP-Protokoll an den SIP-Server bzw. an die fritzbox durchzukommen? Oder liege ich da falsch. (Im Übrigen find ich das gerade mehr und mehr spannend muss ich sagen , hätte ich nicht vermutet.)

Kurz mal noch eine andere Frage eingeworfen:

pfsense - Ort: System / erweiterte Einstellungen / Firewall & NAT / Network Address Translation / TFTP-Proxy:
bei den Schnittstellen steht unter anderem ein MGT1 neben WAN und LAN. Was bedeutet MGT1?

 

[FlaTLin3]

Update: Es gibt ja im Bereich...
System / erweiterte Einstellungen / Firewall & NAT / State Timeouts
...die Möglichkeit, trotz der weiter oben auf der Seite eingestellten Firewall-Variante <Normal> , die Timeouts für UDP-Protokolle, mit denen wir ja über Fritzbox verkehren, manuell hochzustellen. Laut einem Netgate-Forum lohnt es sich, diese einmal weiter hoch zu stellen:

UDP First: 300
UDP Single: 150
UDP Multiple: 900

Da bist du genau an der richtigen Stelle. Ich bin mit den genauen Konfigurationsmöglichkeiten bei pfSense nicht mehr so vertraut. Ich bin zum Fork "opnSense" gewechselt, wo das Web-Interface etwas anders ausschaut und manches etwas anders ist.

Kurz mal noch eine andere Frage eingeworfen:

pfsense - Ort: System / erweiterte Einstellungen / Firewall & NAT / Network Address Translation / TFTP-Proxy:
bei den Schnittstellen steht unter anderem ein MGT1 neben WAN und LAN. Was bedeutet MGT1?

TFTP ist auch ein Dienst der arge Probleme mit NAT hat. pfSense bietet wohl einen Proxy um das zu umschiffen. Spielt aber meist keine Rolle, da sich TFTP-Server und TFTP-Clients bei üblichen Installationen im gleichen Netzwerksegment befinden oder ohne NAT geroutet werden kann.

MGT1 wird ein Interface sein. Also eine Netzwerkschnittstelle die konfiguriert ist. Vom Namen würde ich auf ein Management-LAN schließen. Es ist üblich zur Verwaltung von Netzwerkgeräten (Switches, Router, Server, etc.) deren Verwaltungs-Schnittstellen (Web-Interface, IPMI-Console, Telnet, etc.) mit einem virtuellen (Stichpunkt VLAN) oder physischen LAN isoliert zu betrieben. Das wird als Sicherheitsmaßnahme gegen Eindringlinge gemacht. Wird das "normale" Netzwerk z.B. durch einen befallenen Arbeits-PC kompromittiert, dann kann der Eindringling nicht (ohne weiteres) die Verwaltung der Geräte attackieren.

Aber das ist nur eine Vermutung aufgrund des Namens. Letztlich können Interfaces beliebig benannt werden. Siehe dazu: https://docs.netgate.com/pfsense/en/latest/interfaces/configure.html

 

[rkl7593]

Wiederum Update: Die Umstellung in der pfSense (Firewall-State-Timeouts für die UDP-Protokolle) scheint keine Lösung gebracht zu haben. Eingehende Anrufe brechen nach wie vor nach 30 Sekunden ab.

Wo gibt es in der pfSense die Option, sich mal anhand einer IP-Adresse (= 1 Wohneinheit bzw. 1Fritzbox) die Logs anzuschauen bzw. den Datenverkehr? Bei der fritzbox selbst bekomme ich es ja ausgelesen und auch beim SIP-Provider, aber mir fehlt der pfSense-Teil noch. Dann würde ich das mal spiegeln und schauen, ob ich dort Auffälligkeiten erkenne.

 

[FlaTLin3]

Wiederum Update: Die Umstellung in der pfSense (Firewall-State-Timeouts für die UDP-Protokolle) scheint keine Lösung gebracht zu haben. Eingehende Anrufe brechen nach wie vor nach 30 Sekunden ab.

Wo gibt es in der pfSense die Option, sich mal anhand einer IP-Adresse (= 1 Wohneinheit bzw. 1Fritzbox) die Logs anzuschauen bzw. den Datenverkehr? Bei der fritzbox selbst bekomme ich es ja ausgelesen und auch beim SIP-Provider, aber mir fehlt der pfSense-Teil noch. Dann würde ich das mal spiegeln und schauen, ob ich dort Auffälligkeiten erkenne.

Da die pfSense nur Datenpakete vermittelt gibt es keine Logs. Die gibt es nur für Dienste, welche von pfSense ausgeführt werden. Zur Diagnose kann Datenverkehr aufgezeichnet und analysiert werden. Siehe dazu https://docs.netgate.com/pfsense/en/latest/diagnostics/packetcapture/webgui.html

Einfache Sachverhalte kann man in der Web-Ansicht direkt nachvollziehen. Wenn es komplizierter wird, dann kann man die Aufzeichnung heruntergeladen und z.B. mit Wireshark analysieren.

Bedenke das die von dir angepassten UDP-Timeouts nur den ersten Abschnitt meiner Vermutung betreffen. Das UDP-Hole-Punching könnte möglicherweise durch die standardmäßige Randomisierung der Ports weiterhin Störungsquelle sein. Oder wurden für die Audio-/Medienübertragungen andere Maßnahmen ergriffen um diese sicherzustellen?

Auch ist nicht auszuschließen das der LTE-Router oder das "Carrier-grade NAT" des Mobilfunkanbieters nicht doch das Problem verursachen. Ggf. müsste man das mit einem Versuchsaufbau prüfen. z.B. eine Fritzbox direkt mit dem LTE-Router verbinden und das verhalten beobachten.

 

[TheCadillacMan]

Zur Diagnose kann Datenverkehr aufgezeichnet und analysiert werden. Siehe dazu https://docs.netgate.com/pfsense/en/latest/diagnostics/packetcapture/webgui.html

Man muss aber unbedingt beachten, dass wenn man dabei auch den RTP-Traffic mitschneidet Telefonate abgehört/mitgeschnitten werden.
D. h. man braucht die Zustimmung beider beteiligten Gesprächspartner, da man sich sonst tatsächlich strafbar macht.

 

[FlaTLin3]

Man muss aber unbedingt beachten, dass wenn man dabei auch den RTP-Traffic mitschneidet Telefonate abgehört/mitgeschnitten werden.
D. h. man braucht die Zustimmung beider beteiligten Gesprächspartner, da man sich sonst tatsächlich strafbar macht.

Ja, das sollte man berücksichtigen. Und eigentlich nicht nur bei RTP. Und am besten wäre der Verkehr sowieso mit TLS gesichert. Und letztlich müsste man auf POTS over VOIP (plain old telephone service) verzichten, da das Telefonnetz mangels E2E-Verschlüsselung immer angezapft werden kann.

Aber eine Aufzeichnung des eigenen Gesprächs von Mobiltelefon zu Festnetz zur Diagnose sollte straffrei möglich sein.

Aber ich muss mich korrigieren. Mit passenden Firewall-Regeln könnte man ebenfalls versuchen die Verbindung zu Debuggen. Wenn eine Regel Anwendung findet und die Log-Option für die Regel aktiv ist, dann wird in das Log der Firewall geschrieben. Möglicherweise steht dort sogar schon was nützliches drin. Sollte die SIP-Verbindung aufgrund der UDP-Timeouts abbrechen oder auch das RTP irgendwie unterbrochen werden, dann sollte die Standard-Deny-Regel verantwortlich sein die Pakete zu verwerfen. Und für diese Regel ist (soweit ich weiß) standardmäßig die Log-Option aktiviert. Daher sollte es dann etwas im Firewall-Log erscheinen. Mit zusätzlichen Pass-Regeln + Log-Option ließe sich noch mehr Information raus holen. Siehe dazu: https://docs.netgate.com/pfsense/en/latest/firewall/configure.html