[Problem] Gespräche werden sporadisch abgebrochen (Log anbei)

[Picormorant]

Hallo zusammen,

ich verwende seit kurzem eine FritzBox 7412 mit FritzOS 6.87 als Telefonanlage hinter einem Ubiquiti Edge Router 4.
Das ganze funktioniert tadellos und ich kann teilweise Gespräche mit bis zu einer Stunde führen. Allerdings tritt ganz sporadisch das Problem auf, dass ein Gespräch unterbrochen wird und das Besetztzeichen ertönt. Ich hatte das schon nach ~ 20 Minuten aber auch schon bei einem Telefonat, das über eine Stunde lief.

Laut TCPDump passiert beim Gesprächsabbruch immer folgendes:

//NORMAL:

12:41:31.057126 IP (tos 0x0, ttl 63, id 4614, offset 0, flags [none], proto UDP (17), length 32)
x.dip0.t-ipconnect.de.sip > 217.0.29.33.sip: SIP
12:41:31.057351 IP (tos 0x0, ttl 64, id 53151, offset 0, flags [none], proto UDP (17), length 32)
fritz.box.sip > 217.0.28.33.sip: SIP
12:41:31.057523 IP (tos 0x0, ttl 63, id 53151, offset 0, flags [none], proto UDP (17), length 32)
xdip0.t-ipconnect.de.sip > 217.0.28.33.sip: SIP

// JETZT KOMMT ES ZU ABBRUCH:

12:41:41.012389 IP (tos 0xb8, ttl 57, id 56902, offset 0, flags [DF], proto UDP (17), length 507)
217.0.21.129.sip > x.dip0.t-ipconnect.de.sip: SIP, length: 479
BYE sip:x@x;uniq=B0937753D0717123E563F72A5D570 SIP/2.0
Max-Forwards: 70
Via: SIP/2.0/UDP 217.0.21.129:5060;branch=z9hG4bKg3Zqkv7ie8mx4u4hvhuct6zytpef457s2
To: <sip:[email protected]>;tag=F959F8ED5AE71FE2
From: <sip:[email protected]>;tag=h7g4Esbg_p65544t1671445088m884405c104603s1_2731073436-1375279426
Call-ID: 6252A90E6CC2E7A9@x
CSeq: 10 BYE
Reason: SIP;cause=404;text="Not Found (1:27)"
Content-Length: 0

12:41:41.012416 IP (tos 0xb8, ttl 57, id 56902, offset 0, flags [DF], proto UDP (17), length 507)
217.0.21.129.sip > x.dip0.t-ipconnect.de.sip: SIP, length: 479
BYE sip:x@x;uniq=B0937753D0717123E563F72A5D570 SIP/2.0
Max-Forwards: 70
Via: SIP/2.0/UDP 217.0.21.129:5060;branch=z9hG4bKg3Zqkv7ie8mx4u4hvhuct6zytpef457s2
To: <sip:[email protected]>;tag=F959F8ED5AE71FE2
From: <sip:[email protected]>;tag=h7g4Esbg_p65544t1671445088m884405c104603s1_2731073436-1375279426
Call-ID: 6252A90E6CC2E7A9@x
CSeq: 10 BYE
Reason: SIP;cause=404;text="Not Found (1:27)"
Content-Length: 0

12:41:41.023131 IP (tos 0x0, ttl 63, id 64807, offset 0, flags [none], proto UDP (17), length 810)
x.dip0.t-ipconnect.de.sip > 217.0.21.129.sip: SIP, length: 782
SIP/2.0 200 OK
Via: SIP/2.0/UDP 217.0.21.129:5060;branch=z9hG4bKg3Zqkv7ie8mx4u4hvhuct6zytpef457s2
From: <[email protected]>;tag=h7g4Esbg_p65544t1671445088m884405c104603s1_2731073436-1375279426
To: <sip:[email protected]>;tag=F959F8ED5AE71FE2
Call-ID: 6252A90E6CC2E7A9@x
CSeq: 10 BYE
X-RTP-Stat: CS=1918;PS=250168;ES=250389;OS=40026880;SP=0/0;SO=0;QS=-;PR=250249;ER=250389;OR=40039840;CR=0;SR=0;QR=-;PL=0,0;BL=1;LS=100;RB=31/255;SB=-/-;EN=PCMA;DE=PCMA;JI=23,0;DL=0,0,0;IP=x:7078,217.0.5.246:13534
X-RTP-Stat-Add: DQ=3;DSS=1240;DS=3103;PLCS=20247;JS=1
X-SIP-Stat: DRT=0;IR=0
User-Agent: AVM FRITZ!Box 7412 (UI) 137.06.87 (Oct 12 2021)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer
Content-Length: 0

So wie es aussieht kommt wohl Telekomseitig aus heiterem Himmel ein "BYE" mit der Begründung "Reason: SIP;cause=404;text="Not Found (1:27)".
Die Telekom IP, die diese Meldung versendet, ist dabei neu und mit dieser wurde während des Gesprächs vorher nie per SIP kommuniziert.
Ich habe das bereits mal recherchiert und habe herausfgefunden, dass das wohl mit wechselnden SIP Servern während des Gesprächs zutun hat. (Aufgrund der SRV Records im Hintergrund)
(Quelle: https://www.mittelstedt.net/?p=131)

Hat vielleicht jemand das gleiche Problem bzw. eine Lösung dafür parat? Ist das ggf. mit einer neueren FritzBox bzw. Firmware gelöst? Für 7412 gibts ja leider nichts neueres mehr.

Würde mich über jegliche Hilfe sehr freuen!

 

[frank_m24]

Ich kann mich erinnern, dass es mal ein extra Update gab für die SRV Records bei der Telekom bzw. den Hinweis "bitte keine Firmware verwenden älter als x.y". Ich weiß aber nicht mehr, was x.y war, und ob die 7412 was neueres hat.

 

[KunterBunter]

​

Wahrscheinlich meinst du das hier aus dem Forum. Telekom: Kunden sollten unbedingt die FRITZ!Box aktualisieren
Das ist aber noch gar nicht so lange her und die Fritzbox 7412 ist davon nicht betroffen.

 

[Picormorant]

Hmmm, da ich noch auf Version 6.87 bin, könnte das schon sein oder?

 

[KunterBunter]

Nein, damit kannst du doch gar nicht verschlüsselt telefonieren.

 

[Picormorant]

Alles klar. Ich denke aber vom Fehlerbild hat das nichts mit den typischen NAT oder SIP ALG Problemchen zu tun, wie seht ihr das?
Falls nicht, würde ich nachher mal zum Media Markt rennen und eine 7510 testen.

Ergänzung: Ich habe jetzt mal etwas getrickst und auf meinem DNS Server den SRV Record der Telekom überschrieben, so dass es für die FritzBox nur noch einen Record gibt:
_sip._udp.tel.t-online.de SRV service location:
priority = 0
weight = 0
port = 5060
svr hostname = d-epp-110.edns.t-ipnet.de
d-epp-110.edns.t-ipnet.de internet address = 217.0.28.33

Sollte es wirklich am wechselnden SIP Server liegen, sollte das Problem ja damit behoben sein. Ich werde das nun testen.

 

[Picormorant]

Ich konnte nach der Anpassung nun ein Gespräch für knapp 4 Stunden problemlos halten. Es scheint als wäre ein wechselnder SIP Registrar tatsächlich das Problem.

Obwohl das alles andere als schön ist, werde ich die Konfiguratoin jetzt mal so lassen. Knapp 100€ für eine neue FB sind es mir dann doch nicht Wert.

 

[sonyKatze]

FritzBox 7412 mit FritzOS 6.87

Unbedingt an AVM melden. Vielleicht machen die ein Kompatibilitäts-Update.

Allerdings hat die Vergangenheit gezeigt, dass AVM selten Kompatibilitäts-Updates in alten Software-Branches nachgeliefert hat, jedenfalls im Bereich Telefonie. Daher mein Tipp – wenn man eine FRITZ!Box im Modus IP-Client rein für die Telefonie nimmt –, ein Modell nehmen, das noch Feature-Updates erhält, also aktuell mindestens FRITZ!OS 7.50.

7510 testen

Du könntest eine FRITZ!Box 7362 SL probieren. Die ist Feature-seitig zwar auch schon stehen geblieben, aber hat noch FRITZ!OS 7.1x bekommen, und die ist günstig gebraucht zu bekommen. Wäre interessant, wenn Du berichten könntest. Halt uns auf dem Laufenden!

 

[Picormorant]

Hi,

vielen Dank für die Rückmeldung. Ich habe das Problem nun nach einiger Recherche nachhaltig beheben können.
Durch die Änderung des öffentliche DNS-Resolvers auf die Adressen die ich von der Telekom per PPPoE erhalte, sieht der SRV Lookup ganz anders aus als bei Quad9. Die Telekom gibt hier scheinbar regional bezogen andere SRV Records zurück.

Durch die Änderung erhalte ich nun einen SRV Record mit einem Server aus der nächstgrößeren Stadt mit der niedrigsten Priority. Im Gegensatz zu Quad9 ändert sich dieser auch nicht alle paar Minuten.

Daher passiert während des Gesprächs kein Failover mehr und das Problem tritt nicht mehr auf.

Wenn ich das richtig verstanden habe, löst das aber im Kern nicht das Problem. Anhand dieser SRV-Records soll ja gerade ein transparenter Failover auf eine andere IP möglich werden. Hier ist vielleicht dann einfach die Firmware der FritzBox zu alt.

 

[sonyKatze]

Wenn ich das richtig verstanden habe

Das ist eine gute Frage. Ist das ein Failover oder ein Load-Balancing? Sieht für mich nach einer Mischung aus. Load-Balancing ist dieses Regionale. Failover sind diese drei Angebote. Eigentlich müssten die Server in jedem Fall intern synchron sein. Ich kenne keine Beschreibung oder Thread in dem das mal richtig aufgelöst wurde. @Meester Proper

Übrigens: In beiden Fällen wäre es „nicht-transparent“. Transparent bedeutet in diesem Zusammenhang nicht die landläufige Übersetzung „durchschaubar“ oder „nachvollziehbar“ sondern „durchsichtig“ bzw. „durchlässig“. Bei einer transparenten Verteilung würde der VoIP/SIP-Client mit der Änderung nicht behelligt, es wäre ihm egal und es gäbe für ihn keinerlei Indiz, dass sich etwas geändert hat. Er sähe immer die selbe IP-Adresse.

Hier ist vielleicht dann einfach die Firmware der FritzBox zu alt.

Meine Vermutung. Aber ich konnte es bisher nicht nachstellen. Daher die Bitte das mal weiter zu untersuchen, wenn Du die Lust und Zeit hast.

 

[Picormorant]

Hi,

das würde mich schon auch interessieren, allerdings habe ich aktuell keine neuere FritzBox zum Testen da. Da jetzt auch alles erstmal läuft, möchte ich auch keinen Invest für ein neues Gerät tätigen.

 

[chrsto]

Da die VoIP-Plattform hochredundant und georedundant aufgebaut ist, führt die DNS-Auflösung je nach Standort/IP-Leitung oder im
Fremdnetzen zu unterschiedlichen Antworten. Da sich diese regelmäßig ändern (z.B. im Wartungsfall) und auch Erweiterungen
vorgenommen werden, wird die Gesamtliste grundsätzlich nicht bekannt gegeben. Ebenfalls kann ein manuelles Eintragen der IP-
Adresse in die TK-Anlage zu einem Ausfall führen, wenn der Server in Wartung geht oder Umbauarbeiten vorgenommen werden.

Das schrieb die Telekom 2019 in Ihrer technischen Unterlage zu SIP Trunks. Ich bin mir sicher, dass in deren TR das auch so drin steht. Irgendwo stand auch mal, dass die Telekom bei VoIP die Verwendung von externen (= außerhalb des Telekom Netzes) DNS Servern nicht empfiehlt. Das hab ich aber auf die schnelle nicht gefunden.

 

[Meester Proper]

Wenn ein externer DNS-Server genutzt wird, muss dieser EDNS0 (RFC 2671) beherrschen, denn darüber wird das Client Subnet übergeben, von der die Abfrage erfolgte. Anhand des übergebenen Client Subnet wird dann ein regionaler Proxy mit der höchsten Priorität (niedrigster Priority-Wert) übergeben.

Die anderen beiden Einträge sind dann wie gesagt Failover-Einträge, für den Fall, dass der Proxy mit der höchsten Priorität nicht funktionieren sollte.

 

[Picormorant]

Hi,

alles klar. Das macht Cloudflare laut deren Docs wohl nicht. Ich hatte deren Server vorher in Nutzung.
der Google DNS resolved mir hingegen genau die gleichen Records wie der Telekom DNS, sollte also demnach genauso funktionieren.

Sollte aber in der Theorie das Telefonat nicht trotzdem weitergehen, wenn der präferierte Proxy während des Gesprächs wechselt?

 

[Meester Proper]

Sollte aber in der Theorie das Telefonat nicht trotzdem weitergehen, wenn der präferierte Proxy während des Gesprächs wechselt?

Nein, die Zustandsdaten zu diesem Call für den Proxy sind nur dort vorhanden. Ein anderer Proxy kennt den Call nicht. Das Gespräch wird also kurze Zeit nach dem Auslaufen der Registrierung auf dem alten Proxy terminiert oder wenn ein Session-Refresh anstehen sollte. Je nach dem welches Ereignis vorher stattfindet.

 

[LastRaven]

Ein anderer Proxy kennt den Call nicht. Das Gespräch wird also kurze Zeit nach dem Auslaufen der Registrierung auf dem alten Proxy terminiert oder wenn ein Session-Refresh anstehen sollte.

und genau das darf nicht passieren, wenn beide Seiten (Registrar und Registerer) richtig arbeiten. Eine aktive RTP-Session darf sich gar nicht mehr dafür interessieren, was der Rest der Konstellation für (Proxy-)Daten aushandelt. Das ist ja der Sinn (und wenn man es richtig macht auch der Vorteil) von SIP, dass eine aktive Payload-Session völlig unabhängig vom Rufaufbau/Signaling ist.
Mit deiner Begründung müssten ja (fast) alle SIP-Nutzer dieses Problem haben...

Wir hatten das kürzlich erst selbst, dass die Verbindung beendet wurde (in unserem Fall nach exakt 15 Minuten), weil bei der Kommunikation zwischen unserem SBC und dem Provider die Session-ID falsch behandelt wurde. Der SBC-Hersteller hat das dann fixen müssen.

 

[Meester Proper]

und genau das darf nicht passieren, wenn beide Seiten (Registrar und Registerer) richtig arbeiten. Eine aktive RTP-Session darf sich gar nicht mehr dafür interessieren, was der Rest der Konstellation für (Proxy-)Daten aushandelt. Das ist ja der Sinn (und wenn man es richtig macht auch der Vorteil) von SIP, dass eine aktive Payload-Session völlig unabhängig vom Rufaufbau/Signaling ist.
Mit deiner Begründung müssten ja (fast) alle SIP-Nutzer dieses Problem haben...

So ist nun einmal die aktuelle Implementierung mit geographisch getrennten Proxy-Standorten ohne zentralen Zustandsspeicher. Das ist natürlich nicht auf ewig in Stein gemeißelt, sondern kann sich z.B. mit der Einführung eines "shared data layer" ändern.

Wir hatten das kürzlich erst selbst, dass die Verbindung beendet wurde (in unserem Fall nach exakt 15 Minuten), weil bei der Kommunikation zwischen unserem SBC und dem Provider die Session-ID falsch behandelt wurde. Der SBC-Hersteller hat das dann fixen müssen.

Gut, das war dann vermutlich einfach eine RFC-Verletzung und relativ einfach zu behoben. Keine Eigenschaft der generellen Systemarchitektur.

 

[LastRaven]

Ich glaub du hast mich nicht richtig verstanden. (oder reden wir aneinander vorbei?)
Das Ändern der aktuell gültigen SIP-Proxy-Daten, egal wie das zustande kommt, darf sich nicht auf aktive Verbindungen auswirken! Genau so wenig darf ein Session Refresh Einfluss auf die ausgehandelten (SIP-Proxy-)Daten der Session haben! Da macht einer der beiden SIP-Signaling Endpunkte (also entweder dein Router oder der Provider) irgendwas falsch.

 

[gehtdoch]

und genau das darf nicht passieren, wenn beide Seiten (Registrar und Registerer) richtig arbeiten.

Wenn beide richtig arbeiten, passiert das auch nicht!

Eine aktive RTP-Session darf sich gar nicht mehr dafür interessieren, was der Rest der Konstellation für (Proxy-)Daten aushandelt.

Eine RTP-Session wird immer über das (SIP-)Signaling und damit (nicht nur, aber auch) vom SIP-Proxy, gesteuert (welcher ein Teil der SIP-Kette ist). Eine RTP-Session kann (nicht nur!) daher nie getrennt vom (SIP-) Proxy sein. Wenn ein Teil dieser SIP-Kette nicht korrekt mitspielt, ist das eben das Ende des gesamten Calls.

Der riesige Vorteil der Telekom-Infrastruktur ist, dass es viele, vollkommen voneinander unabhängige VoIP-Systeme gibt und man im Zweifel (sogar selbst!) auf andere ausweichen kann, wenn einer nicht brauchbar funktioniert (wie gerade zum Beispiel). Voraussetzung dafür ist natürlich KnowHow und brauchbare Software.

Wie @Meester Proper schon geschrieben hat, gibt es keinen zentralen Zustandsspeicher - weil sowas der extrem hohen Ausfallsicherheit der bestehenden Architektur widersprechen würde: der wäre dann nämlich das schwächste Glied der Kette und im Falle des Ausfalls ist die Telefonie für alle Telekomkunden weg und man hätte auch keine Möglichkeit zum Ausweichen auf ein davon unabhängiges System. So kann man problemlos auf andere jeweils autark arbeitende Systeme ausweichen und ist wieder voll dabei. Das kann die Telekom entweder selbst steuern, indem sie den defekten Proxy einfach ersetzt durch einen anderen Server im SRV-Eintrag oder die Clients sich gleich selbst einen anderen auswählen, wenn der primäre nicht mehr antwortet.

 

[LastRaven]

eine RTP-Session hat üblicherweise nur 2 aktive Beteiligte, und das sind die beiden Endpunkte der RTP-Verbindung. Alles dazwischen wurde beim Rufaufbau via SIP ausgehandelt und darf sich für die Dauer der Session nicht mehr ändern. Bzw. Alles was sich ändert darf keine Auswirkungen auf den Payload-Pfad haben.

Session Initiation Protocol – Wikipedia

de.wikipedia.org

Das Bild in diesem Abschnitt veranschaulicht recht deutlich, dass der SIP Proxy keinen unmittelbaren Einfluss auf den RTP-Stream haben kann. Wenn hier irgendetwas schief läuft, macht eine der Komponenten im SIP-Dialog etwas falsch.

Genauer für diesen Fall: wenn sich der bevorzugte SIP-Proxy während einer aktiven Verbindung ändert, muss der betroffene SIP-Endpunkt für die aktive Verbindung weiterhin den "alten" SIP-Proxy benutzen. Ist ja auch logisch, weil der neue Proxy die Session ID bei einem Session-Refresh ja gar nicht kennen kann. Dann bekommt man die Meldung, das die Session nicht (mehr) existiert.