Mein Asterisk läuft ohne NAT direkt auf dem Gerät mit der öffentlichen IP, und bei einer Neueinwahl wird automatisch ein "sip reload" ausgeführt, um sofort wieder erreichbar zu sein.
Allerdings habe ich an meinem Anschluss eine weitere Fehlerquelle entdeckt. Eigentlich soll sich der SRV-Record für tel.t-online.de nur beim Verbindungsaufbau ändern und nicht während der laufenden Verbindung. Da ich aber auch IPv6 verwende, bekomme ich beim Verbindungsaufbau insgesamt 4 DNS-Server zugewiesen (2x IPv4, 2x IPv6) - und genau an dieser Stelle scheint die Lastverteilung nicht bis zu Ende sauber implementiert zu sein: die IPv4- und IPv6-DNS-Server liefern jeweils eine andere Antwort für den SRV-Record von tel.t-online.de:
Das war nützliche Info, danke sehr. Ich hatte nämlich genau die gleiche Symptomatik. Ausgehende Anrufe wurden abgelehnt und Teilnehmer, die mich erreichen wollten, kriegten nur ein besetzt. Sogar laufende Gespräche wurden mittendrin abgebrochen. Und der Grund war vermutlich genau die genannte Inkonsistenz unter den IPv4/IPv6 DNS Servern.
Über den genauen Ablauf bei den Verbindungsabbrüchen kann ich nur spekulieren, da ich keine Debug Info habe. Aber ich denke mal im Gespräch wurde die Registrierung an einen anderen SIP Server gesendet als an den, auf dem das Gespräch gerade lief. Dort wurde dann wohl die Registrierung "expired". Und das Gespräch folglich gekappt.
Dabei läuft bei mir Asterisk auch ohne NAT direct auf meinem Router, genau wie bei dir. In meinem Fall ein Openwrt, der ebenfalls vier DNS Server - zwei IPv4 und zwei IPv6 - cached. Die dann leider unterschiedlich auf SRV Lookups antworten.
Ich habe im Asterisk/chan_sip jetzt die srvlookups abgeschaltet. Und seither, ein paar Tage mittlerweile, scheint die Situation stabil zu sein. Zur Sicherheit setze ich aber jede Stunde einen automatisierten Testcall auf die Sprachbox ab, mit sipp. Man kriegt ja sonst wirklich nicht mit wenn Asterisk die Registrierung verliert, weil eben Asterisk selbst nicht Notiz davon nimmt.
Inwieweit der weiter unten genannte "Service-Route" Header noch eine Rolle spielen mag kann ich nicht sagen. Soweit ich sehe zeigt der immer auch auf den Registrierungsserver. Aber die Inkonsistenz in den DNS Servern ist in jedem Fall ein massives Problem.
