ich hatte im Netz gelesen das PJSIP und Asterisk das mittlerweile kann
NAPTR wird unterstützt - das hat aber nichts damit zu tun, dass sichergestellt wird, dass beliebige nach einem Register folgende Requests garantiert zur gleichen Destination geschickt werden, wenn der DNS SRV lookup mehr als einen Server zurückgibt.
Asterisk kennt keinerlei zwingende Abhängigkeit zwischen einem loszutretendem Request und der Transport-Ebene. Für einen ausgehenden Request wird der dem Trunk zugeordnete Transport verwendet und der bedient sich jeweils am erhaltenen DNS SRV record (falls vorhanden). Wenn da mehr als ein Ergebnis zurückkommt, wird normalerweise nach Priorisierung der primäre Server verwendet -
solange keine Störung auftritt,
"funktioniert" das zufälligerweise auch, weil aufgrund der Priorisierung eben immer der primäre Server verwendet wird.
Sobald aber mal eine Störung auftritt (weil z.B. ein Server nicht schnell genug antwortet), bedient sich der Transport für diesen Request dann dem nächsten Server aus der Liste - ohne dabei zu beachten, wohin der Register ehemals ging.
Aus Erfahrung hier tritt das Problem z.B. (Betonung liegt auf
Beispiel - es gibt auch andere Szenarien!) besonders gerne beim Start von Asterisk auf, weil nicht jeder Register durchgeht - v.a. dann, wenn mehrere Nummern praktisch gleichzeitig registriert werden sollen. Das scheint die Telekom als "Angriff" zu interpretieren und blockt die 2. oder n.te Nummer ab. Wenn man an diesem Punkt keine Maßnahmen ergriffen hat, nimmt Asterisk nun den 2. Server aus der SRV Liste - der dann auch "geht". Alle weiteren Requests werden dann aber wieder zum primären Server der Liste geschickt. Das war es dann - genau, wie bei Dir passiert.
Schränkt man die SRV-Liste auf einen Server ein, kann Asterisk nicht mehr springen (sondern macht eben Retries zum gleichen Server, was ja dann auch funktioniert) und das konkrete Problem ist bereinigt.
Damit man sich dadurch kein anderes Problem einfängt, sollte man die Einschränkung der Liste dynamisch machen und zyklisch nach Veränderungen im Original scannen und den einen verwendeten Server bei Bedarf anpassen (z.B. wenn der verwendete Server aus der original-Liste verschwunden ist - oder auch, wenn Probleme im Logfile, das man evtl. überwacht, erkannt wurden). Die Anpassung verbindet man dann mit einem bewussten unRegister beim alten und reRegister beim neuen Server. Sinnvollerweise dann, wenn gerade mal kein Gespräch geführt wird. Ist etwas aufwändig und nicht gerade schön - aber funktioniert.
Ergänzung:
Bsp. für die Anwendung einer rpz-Zone in bind:
in der options section von named.conf:
Code:
response-policy {
zone "rpz-tonline";
}
Nun wird eine Zone definiert in der named.conf:
Code:
zone "rpz-tonline" {
type master;
file "/var/named/rpz-tonline-override";
allow-query { any; };
allow-transfer { any; };
allow-update { any; };
};
Dann wird ein loadfile erstellt, um die rpz zu befüllen (Achtung - kein udp enthalten):
Code:
server [IP Deines bind DNS-Servers - ohne Klammern]
zone rpz-tonline
update delete tel.t-online.de.rpz-tonline.
update delete _sips._tcp.tel.t-online.de.rpz-tonline.
update delete _sip._tcp.tel.t-online.de.rpz-tonline.
update add tel.t-online.de.rpz-tonline. 60 NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
update add tel.t-online.de.rpz-tonline. 60 NAPTR 30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
update add _sips._tcp.tel.t-online.de.rpz-tonline. 60 SRV 10 0 5061 d-eps-110.edns.t-ipnet.de.
update add _sip._tcp.tel.t-online.de.rpz-tonline. 60 SRV 10 0 5060 d-epp-110.edns.t-ipnet.de.
send
Kommentar zu den einzelnen Zeilen des loadfiles:
1. IP-Adresse des Servers, auf dem Dein Bind läuft.
2. Name der Zone, die hier erstellt wird
3 - 5. Alle vorhandenen relevanten Einträge der Zone werden gelöscht.
6 - 9. Alle relevanten Einträge werden gesetzt.
10. Die Daten werden an den definierten Server gesendet.
Der Sendvorgang wird mit
ausgeführt.
In Asterisk verwendet man dann die ganz normalen Hostnames - tel.t-online.de z.B. Muss ja so sein, sonst würde SSL nicht gehen
. Kann man auch einfach über dig testen, der den eigenen DNS nutzt (gemäß Eintrag in /ect/resovl.conf - aus dem bedient sich ja auch Asterisk)
Das Script, das das loadfile erstellt, muss dann allerdings den nslookup so machen, dass es am lokalen DNS vorbei direkt den NS der telekom fragt, also z.B.
Code:
dig +noall +answer _sips._tcp.tel.t-online.de SRV @[DNS-IP vom Telekom Server]
