[Problem] Telefonat endet in Stille

[bovono]

Ich hab VDSL100 bei der Telekom mit drei Telefonnummen

Hauptrouter ist eine Easybox 904x DSL
Nebenrouter ist eine 1&1 Fritzbox 7362 SL
Als Accespoints noch diverse Fritzbox 4040

An der Easybox 904X sind zwei Analoge Telefone angeschlossen und alles ohne Probleme

Am Nebenrouter ein Telefon Analog, später FritzFon über DECT.


Bei längeren Telefongesprächen mit einem Telefon beim Nebenrouter wird das Gespräch mit Stille unterbrochen. Ich höre nichts mehr und auf der anderen Seite der Leitung auch nichts mehr. Beim auflegen und neuanwahl kann das Gespräch wieder fortgeführt werden oder einige Minuten lang kann ich niemand anrufen, während die Internetverbindung weiter besteht. Zu sehen z.B. wenn ich mit dem Teamviewer einen Computer fernsteuere und simultan mit dem Besitzer des gesteuerten Computer telefoniere.

In der Fritzbox Log gibt es keinen Eintrag bezüglich des Gesprächsabbruchs aber bei den neu Anwahlversuchen folgenden Eintrag

Internettelefonie mit 08003301000 über tel.t-online.de war nicht erfolgreich. Ursache: Forbidden (403)

Ich bilde mir ein dass die Probleme angefangen haben als ich die Mesh Funktion angefangen habe zu nutzen, aber kann auch Zufall sein.

Am Nebenrouter hatte ich längere zeit mein gutes altes Analog Panasonic Funktelefon im Betrieb. Es ist paar mal auf den Boden gefallen und so dachte ich zeitweise das es daran liegt und hab mir so ein Fritz Fon C4 gekauft aber damit besteht das problem weiter.

Testweise den Hauptrouter und auch den Nebenrouter gegen baugleiche Modelle ausgetaucht. Keine Veränderung.


Ist jedenfalls nicht so toll wenn die Gegenseite denkt man hätte einfach aufgelegt und es nervt auch immer paar Minuten damit zu verplempern mit dem vorwarnen dass das Gespräch evt. einfach unterbrochen werden kann.

Jemand eine Idee?

 

[KunterBunter]

In deinem anderen nahezu zeitgleichen Beitrag mit ähnlichem Inhalt steht dazu noch, dass die Telefongespräche oft erst nach 1 Stunde + X Minuten abbrechen. Das Registrierungsintervall von 900 Sekunden scheint also hier nicht die Ursache zu sein.
Manche VoIP-Provider trennen sogar absichtlich überlange Gespräche, weil sie Missbrauch vermuten. Die Telekom gehört aber noch nicht dazu.
Es muss also eine technische Ursache haben, warum der RTP-Stream abreisst. Mit Wireshark kannst du versuchen, diese zu ermitteln.

 

[bovono]

Bei so 1 Stunde + X blabla anrufe fällt es eben besonders auf... gab aber auch schon zwei Unterbrechungen in jeweils unter 20min.

Bei einem der KabelBW (Unitimedia) hat meinte das die Probleme bei Ihm liegen würden da er das manchmal auch hat. Er hat nur eine original KabelBW Fritzbox direkt mit Analog Telefon.

Bei einem anderen ist es ein Telekom Anschluss mit original Telekom Router und so einem extra Adapter-Box zu ISDN die weiter geht zu einer alten Telefonanlage zu Analog Telefone.

Bei noch einem ein Telekom Anschluss DSL 1000 mit VoIp an einem etwas älteren Telekom Speedport und Analog Telefon


Solche Überlangen Telefongespräche kommen vielleicht 2-3 mal im Monat vor, entsprechend niedrig war jetzt der Leidensdruck da eine Lösung zu finden. Ich will mal verstärkt darauf achten nach wie viel Zeit das Gespräch immer endet.

 

[sonyKatze]

Kannst Du den Fehler bereits gezielt nachstellen oder passiert das (noch) nicht immer?

Du kannst den Daten-Verkehr mitschneiden und dann mal am Computer mittels Wireshark anschauen. In Wireshark filterst Du nach „dns || sip || rtp“. Weißt Du wie das Mitschneiden geht? Idealerweise machst Du das im aller ersten Internet-Access-Device (IAD), also in Deinem Fall die EasyBox 904 xDSL. Ich meine mich zu erinnern, dass die das kann; bin aber gerade zu faul meine auszupacken/anzuschließen. Auf jeden Fall kannst Du den Internet-Anschluss der FRITZ!Box mitschneiden …

Wenn Du den Fehler nicht gezielt nachstellen kannst, würde ich zum Test alle FRITZ!Box 4040 ausschalten, alle Ethernet-Kabel entfernen und die EasyBox 904 xDSL durch die FRITZ!Box 7362 SL ersetzen. In der FRITZ!Box löschst Du alle Telefone außer einem FRITZ!Fon C4. Dann machst Du erneut den Test (und schneidest mit). Wenn der Fehler immer noch auftritt, lösche auch das FRITZ!Fon C4 aus der FRITZ!Box und probiere stattdessen ein analoges Schnur-gebundenes Telefon. Wenn es jetzt nicht mehr passiert, dann würde ich auf HD-Voice tippen.

Oder anders formuliert:
VoIP/SIP-Fehler sind dermaßen komplex, dass ich davon abrate wild Komponenten auszutauschen. Manchmal hat man nämlich mehrere unterschiedliche Fehler, die aber ähnliche Symptome haben. Am Ende jagt man einen Fehler und in Wirklichkeit ist es was ganz anderes. Wenn Du den Fehler nicht gezielt nachstellen kannst, dann hilft nur eine „saubere“ Konfiguration (auf beiden Seiten) herzustellen, also als Referenz jeweils eine Box mit aktuellem FRITZ!OS jeweils nur ein analoges Schnur-gebundenene Telefon.

 

[bovono]

Hatte vorhin mit einer Bekannten telefoniert und mal gezielt das Gespräch in die länge gezogen... nach 43 Minuten wurde ich abgewimmelt... sie wolle nun Frühstücken. Nun bei so Teamviewer Hilfen kommt es eher vor das man da eine Stunde oder länger an der Strippe hängt und nebenbei über irgend einen Quatsch sich unterhält. Ich werde mal genauer darauf achten ob es da Muster gibt. Bei Kurztelefonate unter 5min ist das Problem noch nie aufgetaucht. Die Stille gab es auch über die FritzFon App des Smartphone und auch dem Programm Phoner Lite auf Windows PC.

Nun etwas Computerkram kann ich schon deutlich mehr als der Bevölkerungsdurchschnitt aber aus einem großen Wireshark Log was konkretes heraus zu interpretieren... das überschreitet meine Kompetenz. Ich will trotzdem mal etwas zu diesem Programm Googeln ob ich mich da vielleicht etwas reinlesen kann.

 

[sonyKatze]

Ein Schritt nach dem anderen! Erstmal das Problem nachstellen, aufzeichnen und dann damit Wireshark füttern. Wie das dann zu lesen ist, dabei helfen wir gerne. Entweder schickst Du mir die Datei mittels Privater Nachricht oder wenn Du mir nicht soweit vertraust – erklären wir Dir auf was Du im Paketmitschnitt zu achten hast. Wenn ich sowas wie Wireshark empfehle, dann wird niemand damit allein gelassen. Brauchst Dich also nichtmal einlesen. SIP im Allgemeinen ist viel zu komplex. Aber mit einem konkreten Beispiel wie Deinem Paketmitschnitt ist SIP eigentlich nicht viel.

Aber ganz andere Frage: Warum hast Du überhaupt zwei Zugangsboxen, also noch eine vorgeschaltete EasyBox 904 xDSL?

 

[bovono]

Drei Telefonnummern mit drei getrennte Telefone. Die Easybox hat nur zwei analoge Ausgänge. Der ISDN S0 Ausgang mit der alten ISDN Telefonanlage hat nicht einwandfrei funktioniert. Die Box hat auch kein DECT.

Die Easybox ist der Hauptrouter, die Fritzbox ist dahinter geschaltet und darauf sind drei 4040er aufgepropft.

Ich selbst nutze nur die dritte Nummer. Die ersten beiden gehören zu den Mitbewohnern. Die Easybox macht neben dem Telefon noch das WLAN für die Mitbewohner und die Fritzboxen für meine Rufnummer und mein eigenes WLAN. Spielt sich alles über mehre Stockwerke ab.Als Gag hab ich bei Sipgate noch eine vierte Nummer nur für Fax eingerichtet. Letztere macht nie ärger.

 

[sonyKatze]

Mhm. Ich stehe irgendwie auf dem Schlauch. Deine Beschreibung habe ich nämlich so verstanden, als dass Du die EasyBox mit Deiner FRITZ!Box ersetzen könntest. Ordentliche DECT-Telefone bekommt man schon ab 27 Euro. Falls ein Mitbewohner kein DECT-Telefon nutzen will, klemmt er sein Telefon analog an. Falls alle beide Mitbewohner etwas Schnur-gebundenes brauchen, entweder ein DECT mit Schnur (Gigaset T480HX, Gigaset Pro Maxwell C) oder ein SIP-Telefon mittels eBay; letzteres kostet ähnlich wenig.

Aber mach doch mal einen Mitschnitt auf dem WAN-Seite der FRITZ!Box.

 

[Meester Proper]

Das Problem wirst du vermutlich leicht lösen können, wenn du die SIP-Registrierung an der Fritzbox auf TCP umstellst:

https://abload.de/img/telekom-tcp5vj0s.jpg

Du musst hierfür die Nummern in der Fritzbox bearbeiten, den Anbieter auf "Anderer Anbieter" stellen und unten unter Registrar :tcp ergänzt.
Dann einfach ein beliebiges Kennwort eintragen und Eintrag speichern.

//Bilder bitte dem Forum anhängen, um die Verfügbarkeit dessen zu gewährleisten

 

[bovono]

Die Fritzbox 7362 SL habe ich im Juni gegen eine Fritzbox 7362 SL ausgetauscht. Die Einstellungen von der einen zur anderen übernommen. Seither keine Gesprächsabbrüche mehr.

 

[KunterBunter]

Die Fritzbox 7362 SL habe ich im Juni gegen eine Fritzbox 7362 SL ausgetauscht.

Und hast du noch irgendeinen anderen Unterschied zwischen den beiden Boxen bemerkt?
Hast du das Netzteil der Fritzbox dabei auch mit ausgetauscht?

 

[bovono]

Theoretisch ja... die Fritz 7362SL ist wie die alte 7362SL der Mesh-Master und zwei mal ist es mit der "neuen" Box passiert dass das WLAN total unbrauchbar wurde und irgendwas sich im Netzwerk hochschaukelt wo die Easybox 100% CPU Last hat und eine der Fritz 4040 Boxen über die GUI nicht mehr ansprechbar ist. Das Problem ist zwei mal bisher aufgetaucht, hatte ich davor nicht. Laut Freund Google könnte es was mit gescheiterten Anmeldevorgängen durch so ein Apple Handy einer Mitbewohnerin im zusammenhäng stehen da es wahnsinnig viele gescheiterte WLAN Login Vorgänge hat und irgendwann es dann doch geht. Telefonieren ging problemlos, auch mit den 100% CPU Last bei der Easybox.

Die Netzteile hab ich nicht ausgetauscht. Ich hab aber beide Firtz Boxen und die eine 4040 aufgeschraubt um nachzuschauen ob die Elkos evt. aufgeblasen sind. Sehen optisch unauffällig aus.

 

[ubsyathEe]

Den Beschreibungen entnehme ich, dass es sich wahrscheinlich um einen Telekom All-IP Anschluss handelt. Es gibt bei diesem Anschluss ein technisches Problem, was zeitweise zu 403s und Abbrüchen führen kann, aber relativ selten ist. Mit PCAP-Traces kann man der eigentlichen Ursache aber leicht auf die Spur kommen. Der Telekom SIP-Trunk ist von diesem Fehler nicht betroffen, so dass ein Wechsel das Problem lösen könnte.

Einige Anlagen haben hierfür besondere Optionen (etwa nur IP der Registrierung verwenden), oder es gibt andere Workarounds. Die Umstellung des Transportes von UDP auf TCP löst das Problem nicht wirklich.

Haben die beiden Fritzboxen die gleiche Firmware? Ich würde vermuten, dass neuere Firmware auch irgendeine Art von Patch hat, so dass das All-IP Problem nicht mehr auftaucht ( aber möglicherweise dann ein anderes).

Im Kern tauchen die gelegentlichen 403s zeitweise immer dann auf, wenn
(1) die Telefonanlage bei jedem Request erst eine volle DNS-Auflösung vornimmt und die aktuell priorisierte IP verwendet, die von der der letzten Reregistrierung so abweichen kann
(2) die IPs für OPTIONS und INVITE weichen so zwischendurch mal immer wieder von der der Registrierung ab und man läuft in das "403 Forbidden" Problem
(3) nach der nächsten Reregistrierung ist das Problem zunächst wieder behoben.

Würden im Hintergrund alle Telekom-Proxy-Server auf die aktuellen Registrierungsdaten zugreifen können, dann gäbe es das Problem nicht. Die etwas andere Technik beim SIP-Trunk scheint so zu funktionieren, da die DNS-Auflösungen (NAPTR, dann SRV) vergleichbar sind.

Es gibt noch andere Ursachen für Verbindungsprobleme und ich bin mir nicht sicher, ob hier in diesem Fall noch zusätzliche Ursachen in Frage kommen.

 

[gehtdoch]

Sehe ich genauso bzw. entspricht dem, was ich aus eigenen Messungen bisher ableiten konnte (All IP).
Asterisk arbeitet an dieser Stelle ebenfalls "sessionless" - d.h., der merkt auch nicht, wenn sich IP's plötzlich ändern.

Als Workaround verwende ich folgende Technik:

Was Asterisk in Sachen DNS zu Gesicht bekommt, wird von mir gesteuert. Das läuft darauf hinaus, dass ich alle 15 Minuten den relevanten SRV-lookup direkt beim Telekom-DNS mache, der mir beim PPPoE - Login zugewiesen wurde.

Diese Info wird in eine rp-Zone eines lokalen Bind eingespeist. Von dort bedient sich dann Asterisk.

Der Trick dabei ist nun, dass sobald Änderungen erkannt werden, zunächst am laufenden Asterisk nachgeschaut wird, ob Gespräche aktiv sind. Falls ja, wird der Update der rp-Zone so lange verzögert, bis keine Gespräche mehr aktiv sind.

Sobald ein Update möglich ist, wird ein unRegister auf alle relevanten Telekom Trunks ausgeführt. Danach wird der Update der rp-Zone durchgeführt. Am Schluss wird ein Register für alle Telekom-Trunks ausgeführt.

Auf diese Art und Weise sollte es zu keinen Ausfällen / Problemen auf Basis geänderter SRV-Einträge mehr kommen.

options-Eintrag der rp-Zone in Bind:

response-policy {
            zone "rpz-tonline";
};

Das rp-Zonen-File dazu (rpz-tonline-override):

$ORIGIN .
$TTL 660        ; 11 minutes
rpz-tonline             IN SOA  localhost. root.localhost. (
                                35         ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                3600       ; minimum (1 hour)
                                )
                        NS      localhost.

Mit nsupdate können die potentiellen Änderungen in einem change-File übergeben werden (bzw. eben das erste mal, um die rp-Zone zu füllen):

server [IP des eigenen lokalen bind]
zone rpz-tonline
update delete _sips._tcp.tel.t-online.de.rpz-tonline.
update delete _sip._tcp.tel.t-online.de.rpz-tonline.
[Was jetzt folgt ist das Ergebnis vom durchgeführten dig direkt beim Telekom-Nameserver - das, was hier steht, ist nur als syntaktisches Beispiel zu sehen und nicht vollständig]
update add _sips._tcp.tel.t-online.de.rpz-tonline.      60 SRV  10 0 5061 s-eps-110.edns.t-ipnet.de.
update add _sip._tcp.tel.t-online.de.rpz-tonline.       60 SRV  10 0 5060 s-epp-110.edns.t-ipnet.de.
send

In /var/log/messages (oder wohin bind auch immer loggen mag), kann überprüft werden, ob Asterisk tatsächlich die gefakten Einträge bekommt:

named[32307]: client [IP vom lokalen Bind]#38930 (_sips._tcp.tel.t-online.de): rpz QNAME Local-Data rewrite _sips._tcp.tel.t-online.de via _sips._tcp.tel.t-online.de.rpz-tonline

 

[ubsyathEe]

Sollte es zu einem (re-)INVITE wegen einer Medienänderung, oder so, kommen, dann ist man in einem laufenden Gespräch in den Popo gekniffen. Sollte bei eigener DNS-Verwaltung der aktuelle Server ausfallen, dann funktioniert das auch alles zunächst nicht mehr. Das habe ich noch nie gesehen, aber von theoretischem Interesse könnte es dort sein, wo Notrufe gesendet werden müssen. Ich habe eine ähnliche Lösung mit DNS-Handling, aber derzeit bevorzuge ich eine andere Vorgehensweise.

Die 403 Antwort kann man bei PJSIP abfangen und darauf reagieren. Wenn beim ersten Aufbauversuch, oder später, ein INVITE verboten wird, dann kann man in diesem Fall das Konto neu registrieren. Mit System(...) rufe ich ein Script auf, dass im wesentlichen einem "pjsip send unregister" (um alte Brücken abzubrechen) einem "pjsip send register" folgt. Nach einigen Sekunden wird dann der alte Dial-Befehl wiederholt. Solange einer der angebotenen Proxy-Server funktioniert, geht das. Der Nachteil ist eine ca. 10-15 lange Verzögerung.

 

[gehtdoch]

Bei meinem Workaround passiert absolut gar nichts in Sachen IP-Adressänderung, solange ein Call aktiv ist. Da kann kommen, was will. Asterisk bekommt nach wie vor die selbe IP präsentiert und alles bleibt gut.
Wegen der Stabilität / Erreichbarkeit von Bind mache ich mir keine Gedanken - niemand hindert mich daran, in der resolv.conf n Server einzutragen - damit ist auch die HA gewährleistet. Außerdem ist der Bind ja sowieso die Schnittstelle - mit oder ohne RPZ.

Dein Workaround verhindert leider nicht (zumindest konnte ich das bisher nicht erkennen), dass ein laufendes Gespräch abbricht, wenn der REGISTER ausläuft und der ReREGISTER bereits an den neuen Server ging. Dann bricht das laufende Gespräch nämlich einfach ab ohne dass irgendwo ein 403 auftaucht (weil es von der Telekom mangels vorhandenem gültigen REGISTER beendet wird - habe ich selbst mal getestet). Wer noch eine entsprechende Firewall laufen hat, darf sich auch nicht wundern, wenn die an der Stelle auch zu macht.

Meinen Workaround sehe ich auch nur in einer gering belasteten (privaten) Anlage. Mit einer nonstop (7x24) belasteten Anlage (= keine callfreie Zeit) wäre das gar nicht möglich, weil es zu keinem Zeitpunkt möglich wäre, umzustellen. Wobei man da auch noch genauer hinsehen müsste, ob evtl. lediglich die Prio bei einem Server geändert wurde, oder ob er ganz rausgefallen ist. Im Prinzip bräuchte man nur dann reagieren, wenn er komplett aus der Liste rausgefallen ist.

Eine Lösung kann nur innerhalb Asterisks selbst sein, die dann u.U. mehrere Server gleichzeitig handeln muss (den neuen aufnehmen und alte Sessions mit dem alten Server weiterfahren inkl. zugehöriger REGISTER). Dann muss man aber auch beachten, dass man eingehende Gespräche von beiden Servern bekommt (auch schon gesehen - dann muss man hier richtig auswählen). Die Lösung würde also einen enormen Aufwand darstellen.

 

[ubsyathEe]

Ich rechne damit, dass ein Gespräch abbrechen kann, bzw. es zu einem re-INVITE kommt. Dial() beendet sich dann und liefert den DIALSTATUS CHANUNAVAIL. Nach einer kurzen Pause geht es dann weiter. Wenn aber der aktuelle Server physisch ausfallen sollte, geht gar nichts mehr, wenn es zu einem re-INVITE kommt. Die DNS-Lösung ist ohne Fehler auf der eigenen Seite, kann aber Probleme bei dem aktuellen Telekom-Server nicht mehr ausgleichen. In der Praxis wäre es besser, wenn der Load Balancing Kram der Telekom immer schön auf die Registrierungen achten würde, damit man selbst hier nicht aktiv werden muss.

Die Handhabung mehrerer Server gleichzeitig ist kein großes Problem, wenn man in der Registrierungs-Sektion der PJSIP-Konfiguration "line" aktiviert und damit einen Endpunkt verknüpft. Die Telekom-Server geben den richtigen line-Parameter jeweils zurück, so dass man eigentlich keine Identify-Paramter oder auf die Reihenfolge der Zuordnung achten muss.

Die andere Lösung: SIP-Trunk Pure oder nicht.