Heute mal in anderer Sprache, da die betroffen Nutzer am ehesten aus dem deutschem Sprachraum kommen.
Wir haben einem CompanyFlex oder im Telekom-Fachchinesisch 1TR119 ausprobiert. Hier litten wir unter häufigen Gesprächsabbrüchen. Diese wurden immer von der Telekomseite verursacht und hatten folgenden Grund drin:
Reason: SIP;cause=404;text=”Not Found (1:27)”
wie zum Beispiel in folgendem Bye:
BYE sip:+49190000000123@192.168.1.2:5060;transport=tcp SIP/2.0
Max-Forwards: 70
Via: SIP/2.0/TLS 217.0.137.51:5061;branch=z9hG4bKg3Zqkv7iscypm2yeo4cl9nwd182p3bgqb
To: <sip:+49190000000123@tel.t-online.de:5060>;tag=WRIRDULZNU
From: <sip:+493012345@tel.t-online.de:5060;transport=tls>;tag=h7g4Esbg_898065121-1618311345090
Call-ID: c875dd16cf44479e828473e429de19e6
CSeq: 1 BYE
Reason: SIP;cause=404;text="Not Found (1:27)"
Content-Length: 0
Grund hierfür war das Verhalten des SIP-Stacks bei der Registrierung an tel.t-online.de. Das ist mittlerweile ja kein A sondern ein SRV basierter Eintrag im DNS. Dieser sieht bei SIP mit TLS und TCP dann so aus:
dig srv _sips._tcp.tel.t-online.de
;; ANSWER SECTION:
_sips._tcp.tel.t-online.de. 3600 IN SRV 10 0 5061 do-eps-100.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 3600 IN SRV 20 0 5061 h2-eps-100.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 3600 IN SRV 30 0 5061 d-eps-100.edns.t-ipnet.de.
Hier bekommt man 3 mögliche Anmeldeserver. Sollte der SIP-Stack sich während eines laufenden Gesprächs an einem anderen Server anmelden, weil zum Beispiel die Telekom die Prioritäten der SRV-Records ändert, dann beendet der vorherige Registrierungsserver und damit auch SIP-Session-Partner nach einem Timeout das Gespräch. Ein schneller Test und provisorische Problembehebung ist der Eintrag eines der Ergebnisse des SRV-Lookups wie zum Beispiel do-eps-100.edns.t-ipnet.de. Das ist natürlich keine Dauerlösung, da die Einträge jederzeit wechseln können. Eigentlich müsste der SIP-Stack hier solange am Erstregistrierungsserver dran bleiben, bis er aus der SRV-Liste verschwindet oder unerreichbar ist. Andererseits könnte die Deutsche Telekom die bestehenden Gespräche auch weiterlaufen lassen.
Ich vermute, dass das auch bei DeutschlandLAN-Anschlüssen nach 1TR114 und 1TR118 passieren kann. Je nach Protokoll muss hier die Frage nach den SRV-Records aber auch nach SIP und UDP erfolgen. Das sieht dann so aus:
dig srv _sip._udp.tel.t-online.de
;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 3368 IN SRV 30 0 5060 d-epp-100.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3368 IN SRV 10 0 5060 do-epp-100.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3368 IN SRV 20 0 5060 h2-epp-100.edns.t-ipnet.de.