[Problem] Asterisk legt nicht auf

[neitmedia]

Hallo zusammen,

ich habe in Asterisk einen Telekom All IP-Anschluss konfiguriert. Klappt auch soweit alles, rein wie raus.

Leider legt jedoch Asterisk das Gespräch nicht auf, wenn es von innen (also per Softphone oder DECT-Gerät) aufgelegt wird, bevor der Angerufene aufgelegt hat.

Was dann dazu führt, dass das Telefon des Angerufenen bis in die Unendlichkeit weiterklingelt, was natürlich ein absolut inakzeptables Verhalten ist.

Der relevante Teil der extensions.conf:

[telekom-in-xxxxxxx]
exten => +49xxxxxxxxxx,1,Noop(Processing an incoming call)
same => n,Dial(PJSIP/6001&PJSIP/6002)
same => n,Hangup()

[telekom-out-xxxxxxxx]
exten => _X.,1,Noop(Processing an outgoing call)
same => n,Dial(PJSIP/${EXTEN}@tcom_xxxxxxxx_endpoint)
same => n,Hangup()

include => telekom-in-xxxxxxxx
include => telekom-out-xxxxxxxx

Der relevante Teil der pjsip.conf:

; xxxxxxxxxxxxxx
[tcom-allip-reg-xxxxxxxxx](!)
transport=transport-udp
line=yes
expiration=487
auth_rejection_permanent=yes
server_uri=sip:tel.t-online.de
outbound_proxy=sip:tel.t-online.de

[tcom-allip-auth-xxxxxxxxx](!)
auth_type=userpass
realm=tel.t-online.de
password=xxxxxxx

[tcom-allip-endpoint-xxxxxxxxx](!)
transport=transport-udp
context=telekom-in-xxxxxxxx
allow=alaw,ulaw,g722
outbound_proxy=sip:tel.t-online.de
from_domain=tel.t-online.de
direct_media=no
rewrite_contact=yes
rtp_symmetric=yes
timers=yes
dtmf_mode=rfc4733

[tcom-allip-identify-xxxxxxxxx](!)
match=tel.t-online.de

[tcom-allip-aor-xxxxxxxx](!)
default_expiration=120
qualify_frequency=67
qualify_timeout=3.0
authenticate_qualify=yes
outbound_proxy=sip:tel.t-online.de
remove_existing=yes

[tcom_xxxxxxxx_reg](tcom-allip-reg-xxxxxxxxx)
type=registration
outbound_auth=tcom_xxxxxxxx_auth
endpoint=tcom_xxxxxxxxx_endpoint
contact_user=+492644xxxxxxx
client_uri=sip:[email protected]-online.de

[tcom_xxxxxxxx_auth](tcom-allip-auth-xxxxxxxx)
type=auth
username=+492644xxxxxxxx

[tcom_xxxxxxxx_aor](tcom-allip-aor-xxxxxxxxx)
type=aor
contact=sip:[email protected]-online.de

[tcom_xxxxxxxx_identify](tcom-allip-identify-xxxxxxx)
type=identify
endpoint=tcom_xxxxxxx_endpoint

[tcom_xxxxxxxx_endpoint](tcom-allip-endpoint-xxxxxxxx)
type=endpoint
aors=tcom_xxxxxxx_aor
outbound_auth=tcom_xxxxxxx_auth
from_user=xxxxxxxxxxx

Was mir aufgefallen ist, dass in der Asterisk Konsole (wenn sip debug aktiviert ist) folgendes angezeigt wird, wenn mit dem Gerät aufgelegt wird:

<--- Received SIP response (368 bytes) from UDP:217.0.28.160:5060 --->
SIP/2.0 400 Bad header field: request line
Via: SIP/2.0/UDP 192.168.178.70:5060;rport;branch=z9hG4bKPj19af61a4-ebaa-4583-b016-603e559ade94
To: <sip:xxxxxxxxxxxxx@tel.t-online.de>;tag=huagg82c1el
From: <sip:xxxxxxxxxxxxx@tel.t-online.de>;tag=78e56ce7-4196-4ff4-a859-59cf4533d5c4
Call-ID: de430f72-ac98-443d-ac50-27c2782542d9
CSeq: 13857 CANCEL
Content-Length: 0

--> SIP/2.0 400 Bad header field: request line <---

Irgendetwas scheint da also nicht zu stimmen, ich bin aber überfragt, was und wo.

 

[ubsyathEe]

Bitte mal einen vollständigen SIP-Trace posten. Auf Anhieb sehe ich keinen Fehler in der Asterisk-Konfiguration, wobei die angegebene Konfiguration sehr verbreitet ist und eigentlich keine Probleme macht.

Die Fehlernachricht verweist auf ein Problem in dem Request, der aber selbst oben nicht angegeben ist.

 

[neitmedia]

Danke für die Antwort!
Einen vollständigen Trace kann ich frühestens morgen posten.

Was aber auffällig ist, ist, dass es bei Sipgate (ebenfalls konfiguriert) problemlos funktioniert mit dem Auflegen, dort gibt es beim SIP-Response auf CANCEL keine Fehlermeldung.

 

[ubsyathEe]

Sipgate hat auch andere Einstellungen, bzw. die Sipgate Server verhalten sich etwas anders.

 

[neitmedia]

Ich habe es nun mit einer gänzlich anderen Konfiguration hinbekommen. Vielen Dank für die netten Antworten!

 

[ubsyathEe]

Und wie sieht die gänzlich andere Konfiguration aus?

 

[neitmedia]

Seit gestern Abend läuft jetzt (bisher fehlerfrei) eine Konfiguration, die aus einer Kombination der Beispielkonfigurationen von hier: https://community.asterisk.org/t/pjsip-settings-for-two-german-telekom-products/79293 und hier: http://www.rotherland.de/de/voip.html besteht.

Die vorher von mir verwendete Konfiguration beruhte komplett auf https://community.asterisk.org/t/pjsip-settings-for-two-german-telekom-products/79293. Dort kam es zu dem genannten Problem, dass ausgehende Anrufe von innen nicht aufgelegt werden konnten, bevor das angerufene Gerät das Gespräch angenommen hat. Ich habe daraufhin die Konfiguration von Rotherland komplett übernommen (allerdings aus Sicherheitsgründen ohne Port-Forwarding im Router). Daraufhin funktionierte das rein- und raustelefonieren, allerdings kam es in mehr oder weniger regelmäßigen Abständen dazu, dass Asterisk von Außen über die Telekomnummern nicht erreichbar ist (es kommen gar keine SIP Pakete mehr bei Asterisk an). Ich führte das im Rahmen einer Problemdiagnose darauf zurück, dass der Router ab einem bestimmten Zeitpunkt keine UDP Pakete von der Telekom-IP mehr zum Asterisk durch"nattet".

Daraufhin habe ich die Stelle qualify_frequency = 10 bei den Telekom AORs hinzugefügt (das ist bei dem Szenario von Rotherland offensichtlich nicht erforderlich, da der Router alle Pakete auf 5060 direkt an Asterisk forwarded, während in meinem Szenario der Router dies aktiv tun muss, wozu ihm bekannt sein muss, dass Asterisk auf Pakete von der jeweiligen Telekom-IP wartet).

Ich habe das auch reproduzieren können. Ist qualify_frequency nicht gesetzt, kommt es nach etwa 5 Minuten dazu, dass die Anlage nicht erreichbar ist, es sei denn zwischenzeitlich erfolgten Anrufe nach draußen (dann wurden die Telekomserver ja nochmal kontaktiert und der Router hält den Port "offen". Etwa 3 Minuten später geht es von alleine wieder, da die Anlage nach 8 Minuten sich erneut beim Telekom-Server registriert und damit die Fritzbox wieder Pakete von der Telekom zum Asterisk durchlässt. Das passt zur Reregistrierung nach 480 Sekunden (expiration = 480) und dem angenommenen NAT-Timeout von 5 Minuten (https://avm.de/service/fritzbox/fri...h-die-Verbindung-zu-Gegenstellen-im-Internet/) der verwendeten Fritzbox.

Damit läuft es jetzt ohne Unterbrechnung seit gestern Abend. Ich hoffe das bleibt auch so.

Wieso es bei der Konfiguration von https://community.asterisk.org/t/pjsip-settings-for-two-german-telekom-products/79293 (die ja ansonsten wunderbar funktioniert hat) dazu kommt, dass man ausgehende Anrufe nicht auflegen kann, ist mir aber weitgehend schleierhaft. Aber vielleicht hat ja jemand Zeit und Lust, das anhand der Unterschiede beider Konfigurationen zu ergründen.

 

[ubsyathEe]

Die in dem Asterisk-Forum beschriebene Konfiguration funktioniert bei mir einwandfrei. Port Forwarding ist nicht nötig (ist auch hier technisch nutzlos), aber es ist hilfreich, wenn der Router für die Verbindungen zur Telekom "Full Cone NAT" verwendet. Das hängt aber von der Grundeinstellung des eigenen Routers ab. Bei mir wird im Normalfall symmetrisches NAT verwendet. Es ist auch hilfreich zu wissen, wie lange der Router in der NAT Tabelle die Einträge bei Inaktivität hält. Da sollte man sich die Kommunikation im Detail mal ansehen. 10 Sekunden deuten eher auf ein grundsätzliches Problem hin. Ich bin mir auch nicht sicher, ob die Telekom hierauf immer mit einer Antwort reagiert, aber zum Offenhalten der Ports reicht das wohl.

Das mit dem Auflegen kann ich nicht nachvollziehen. Ich würde hier eine falsche Routereinstellung vermuten, die in die Kommunikation eingreift. Ich habe das auch schon einige Male gesehen, aber da waren es immer ziemlich triviale Falscheinstellungen bei Asterisk in diesen Fällen. Das ist aber schon länger her und betraf den alten SIP Stack.

Ich halte es grundsätzlich für problematisch eine VoIP Anlage unabhängig vom Router/Gateway zu betrachten. Das ist zwar alles keine Hexerei, aber notfalls sollte man pcap Traces an allen Schnittstellen machen können. Bei Konsumentengeräten wie Fritzbox etc ist es schon in der Regel ein Problem einen SIP Trace über mehrere Stunden auf der WAN-Seite laufen zu lassen. Es gibt da noch einige andere Problemchen, die sehr sporadisch auftreten und dann auch noch von der Gegenstelle abhängen. Im Asterisk Forum wurde letztlich ein Problem beschrieben, wo durch Abfolge von mehreren reINVITES auf einmal keine Audio Parameter mehr da waren und die Verbindung nicht zu stande kam. Ich konnte das hier auch einmal nachvollziehen, weil ich SIP Monitoring fast ständig an einem Anschluss laufen habe und mir notfalls die Bits nach Wochen noch mal ansehen kann...

Wenn die Anlage von außen nicht erreichbar ist, dann gibt es hierfür mehrere Gründe. Das hier und anderswo beschriebene Problem sollte eigentlich nicht mehr bestehen. Ich kann es jedenfalls seit Wochen nicht mehr feststellen. Es gibt aber noch andere Gründe warum eine Anlage nicht erreichbar ist als die sprunghaft wechselnden priorisierten SIP Proxies der Telekom.

 

[neitmedia]

Die 10 Sekunden waren nur testweise.

Ich werde das jetzt nach und nach erhöhen, vermute aber, dass 60 Sekunden ausreichen werden, wie in dem Forumseintrag.

 

[gehtdoch]

Die 10 Sekunden waren nur testweise.

Ich werde das jetzt nach und nach erhöhen, vermute aber, dass 60 Sekunden ausreichen werden, wie in dem Forumseintrag.

Du machst mehrere Dinge, die man grundsätzlich nicht tun sollte und hast entsprechenden Ärger, den Du auch weiterhin immer wieder haben wirst:

1. SIP und NAT will man nicht, weil es das an sich schon komplexe Protokoll noch komplexer und damit noch fehleranfälliger und schwieriger zu debuggen macht.
2. Wenn man 1. ignoriert, sollte man wenigstens die NAT-Stelle davor so einstellen, dass keine wiederum fehleranfällige deep packet inspection nötig ist, sprich: Die Einstellung sollte für alle relevanten Ports statisch sein. Das funktioniert dann sogar auch mit SIPS. Damit kannst Du Dir dann auch den zyklischen qualify sparen oder auf wenigstens 480s setzen (stell Dir vor, jeder würde das machen, bloss um die bescheuerte Firewall von irgendeinem Konsumerrouter offenzuhalten).
3. Für Telekom AllIP und Asterisk gilt, dass Du selbst sicherstellen musst, dass Asterisk für alle Requests den selben Server wie für den zuvor durchgeführten Register verwendet - sonst wird das nichts (bzw. ist alles nur Zufall). Da helfen dann z.B. auch authentifizierte Options-Pakete nicht weiter, weil Dein Register einfach bei einem anderen Server ist (und nur der kennt Dich). Wenn Du das nicht machst, kann es zu so seltsamen Situation kommen, dass outbound calls nicht mehr funktionieren - inbound aber trotzdem.

Wenn man das alles beherzigt, ist Telekom AllIP eine extrem stabile VoIP-Plattform (wobei Asterisk trotzdem das Problem hat, dass es mit plötzlich oder temporär ausfallenden SIP-Servern nach wie vor grundsätzlich nicht umgehen kann - kommt Gott sei Dank äußerst selten vor. Trotzdem kann man da der Telekom dann keine Vorwürfe machen, wenn man selbst einen Client betreibt, der "Sessionstabilität" grundsätzlich nicht kennt).

 

[neitmedia]

Dann wäre es schön zu wissen, was ich an der Konfiguration von Rotherland ändern muss, damit diese Dinge erfüllt sind (abgesehen von den Routereinstellungen, das bekomme ich selbst hin).

Hast du vielleicht eine funktionierende Konfiguration für AllIP, die stabil läuft?

 

[ubsyathEe]

Für Telekom AllIP und Asterisk gilt, dass Du selbst sicherstellen musst, dass Asterisk für alle Requests den selben Server wie für den zuvor durchgeführten Register verwendet - sonst wird das nichts (bzw. ist alles nur Zufall).

Das gilt möglicherweise nicht mehr. Bei mir wechseln die Server nicht mehr und die NAPTR Requests liefern jetzt Ergebnisse, die den 10er Server nicht mehr ändern. Ich habe das zuletzt über fast 2 Tage gesammelt und dann ausgewertet. Damit verhält sich bei mir der private ALL-IP Anschlus genauso im Hinblick auf die DNS-Auflösungen wie der geschäftliche SIP-Trunk.

Ob das überall so ist, weiß ich nicht. Statt zu spekulieren sollte man halt mal nachschauen was Sache ist.

Dann wäre es schön zu wissen, was ich an der Konfiguration von Rotherland ändern muss, damit diese Dinge erfüllt sind (abgesehen von den Routereinstellungen, das bekomme ich selbst hin).

Hast du vielleicht eine funktionierende Konfiguration für AllIP, die stabil läuft?

Klar, die zuerst angegebene, .

Wie schon gesagt, es reicht nicht aus nur die Telefonanlage zu betrachten. Das Routing-Verhalten spielt auch eine Rolle. Im Grunde muss man sogar berücksichtigen was der Router und die Proxies beim Anbieter machen. Wie schlau die Proxies sind, erfährt man nur durch Beobachten und Auswertungen der SIP Kommunikation. Bei der Telekom kann man an einigen Stellen ziemlichen Stuss eingeben und es funktioniert immer noch, bzw. einige SIP Header scheinen keine besondere Bedeutung zu haben. Den eigenen Router sollte man besser gut kennen, aber gute Router sind auch gut dokumentiert.

Ich selbst würde keine Telefonanlage z.B. hinter einer Fritzbox verwenden, sondern die Fritzbox selbst verwenden. Wenn das nicht reicht, dann würde ich mich nach einem anderen Router umsehen.

Das ist in etwa so, als wenn man einen Kardiologen seine gesundheitlichen Probleme schilder, der dann alles auf das Herz zurückführt. Soche Diagnosen habe aber ihre Grenzen, wenn es sich um einen Tripper handelt.

 

[neitmedia]

Ich beobachte das jetzt einmal.

Habe mittlerweile qualify_frequency auf 60 gesetzt. Bisher läuft alles glatt.

Sofern es weiterhin Probleme gibt, werde ich entsprechend ggf. auf einen anderen Router umsteigen oder einen anderen SIP-Provider wie Sipgate verwenden, die die Einrichtung in Asterisk auch selbst supporten.

 

[gehtdoch]

Das gilt möglicherweise nicht mehr. Bei mir wechseln die Server nicht mehr und die NAPTR Requests liefern jetzt Ergebnisse, die den 10er Server nicht mehr ändern. Ich habe das zuletzt über fast 2 Tage gesammelt und dann ausgewertet.

Ich kann das sogar für viele Monate (fast ein Jahr) sagen, dass sie sich bei mir nicht verändert haben.
Trotzdem - selbst diese Aussage ist exakt nichts Wert, weil sie sich jederzeit ändern können (niemand wird Dir das garantieren). Der DNS SRV lookup bringt drei Adressen in priorisierter Reihenfolge. Es kann sich sowohl die Prio ändern als auch die Server selbst. Das Entscheidende ist auch gar nicht primär die Stabilität der Liste, sondern die Tatsache, dass alle dem Register folgende Requests an den gleichen Server müssen. Wenn einer oder zwei davon jeweils z.B. nur wiederholt temporär wackeln - wie kürzlich mal - dann kann Asterisk bis dato damit in keiner einzigen Version umgehen und der Trunk ist de facto tot (obwohl 1 oder 2 funktionierende Server zur Verfügung stehen).

 

[ubsyathEe]

Praktisch schon. Nur, wie will man das Problem durch Code-Änderung patchen, wenn man es nicht mehr überprüfen kann? Das Problem war ja nicht, dass ab und zu der Server wechselte, sondern alle paar Minuten. Ich halte es für möglich, dass das auch nicht so gewollt war und nur eine falsche DNS Konfiguration war.

 

[gehtdoch]

Das Problem war ja nicht, dass ab und zu der Server wechselte, sondern alle paar Minuten. Ich halte es für möglich, dass das auch nicht so gewollt war und nur eine falsche DNS Konfiguration war.

Missverständnis: Auch in der akuten Ausfallsituation war die DNS-Liste konstant.

Es gibt verschiedene Möglichkeiten der Betriebskonzepte, die man bei der sichtbaren Implementierung seitens der Telekom fahren könnte (ja, es gibt noch viel mehr denkbare Szenarien - daher nur mal als Bsp.):

Use case 1: Ungeplante (-> plötzliche) Ausfälle
Der Client muss sich selbst einen funktionierenden Server aus der vorhandenen Liste aussuchen und dann diesen konsequent solange nutzen, bis dieser auch als nicht mehr funktional erkannt wird.

Use case 2: geplante Changes
Entweder keine Änderungen in der Liste, weil immer nur ein Server gleichzeitig offline genommen wird (das kann der Client ab - siehe Use case 1 - es sind ja dann nach wie vor 2 von 3 Servern verfügbar) oder der für den Change eingeplante Server wird aus der Liste genommen (und durch einen anderen ersetzt) oder die Prio wird geändert. Wobei ich das mit der Prio-Änderung nicht glaube, da ich den Eindruck habe, dass die Prio nur aus formalen Gründen vorhanden ist und ein echter Telekomclient auf Zufallsbasis einen der 3 Server aus der Liste nimmt (die quasi als gleichberechtigt ansieht und somit eine Lastverteilung durchgeführt wird - könnte aber auch sein, dass jedem User eine dedizierte Liste angeboten wird und darüber die Lastverteilung abgefackelt wird - was ich aber nicht wirklich glaube).

Wie man es jedoch dreht und wendet: Final ist immer der Client derjenige, der sich einen Server aussuchen können muss und konsequent nutzen muss (unabhängig vom Trigger) - das ist genau der Punkt, an dem Asterisk scheitert. Eigentlich nichts Weltbewegendes und die Argumentation von J. Colp hier kann ich nicht nachvollziehen: "at least I’ve never seen an RFC/draft as such": Es gibt aber auch keinen RFC, der seine Sicht der Dinge definieren würde (sonst hätte er ihn wohl benannt). Daraus dann eine Vorgehensweise, die man cool findet (weil einfachste), als die einzig richtige abzuleiten ist schon gewagt (aber nachvollziehbar aus Sicht eines Asterisk Programmierers, weil deren derzeitige Architektur die geforderte Funktion grundsätzlich nicht hergibt).

 

[ubsyathEe]

Letztlich kann ein Client das aber nicht, insofern hat Joshua Colp schon recht. Wenn man den Registrierungsserver aus irgendwelchen Gründen wechselt, dann muss man auch den Fall berücksichtigen, das bereits Gespräche bestehen. Insofern kann man nie den Registrierungsserver selbst wechseln, da sonst das Gespräch mit dem Code 28:17 abgebrochen wird. Wenn die Telekom aber im Hintergrund Buch führen würde, wäre das alles kein Problem solange noch mindestens ein Server aktiv bleibt.

Ich schaue mir seit einiger Zeit den Asterisk Code schon an, habe aber bisher nur die diagnostischen Ausgaben erweitert um Asterisk bzw. pjsip besser kennen zu lernen. Ich glaube schon, dass man mit letztlich relativ wenig Aufwand den Zustand erfassen kann und dann entsprechend seine Verbindungen verwalten kann. Mir ist bisher noch nichts eingefallen, was man machen kann, wenn man etwa bei Server A registriert ist, der dann ausfällt und man sich dann an Server B anmeldet. Bestehende Gespräche würden so immer gekappt werden. Da ich bisher noch nie einen wirklichen Serverausfall gesehen habe, wäre das momentan eine eher theoretische Fragestellung.

Wie gesagt, bei den SIP-Trunk Produkten wird ja auch nicht so diskutiert wie bei dem ALLIP Produkt, obwohl manches ähnlich ist.

Zu "use case 2": Ich habe eine zeit lang an Wochenenden ein Skript laufen lassen und alle paar Sekunden die gesamte Hierarschie NAPTR/SRV ausgewertet. Während die 20er und 30er Einträge konstant blieben, wechselte alle paar Minuten der 10er Server. Bei Asterisk würde das aber so nie ankommen, da die TTL Zeiten berücksichtigt werden und es im Mittel erst nach einer halben Stunde zu Wechseln kommen kann. Da die Server im Hintergrund häufiger wechseln, kommt noch eine Zufallskomponente hinzu und die mittlere Zeit ist etwas größer als eine halbe Stunde.

 

[gehtdoch]

Letztlich kann ein Client das aber nicht,

Natürlich kann ein Client das. Wo soll das Problem sein?

Wenn man den Registrierungsserver aus irgendwelchen Gründen wechselt, dann muss man auch den Fall berücksichtigen, das bereits Gespräche bestehen.

Klar - im geplanten Fall wird einfach die Liste geändert und bei der nächsten passenden Gelegenheit wechselt der Client auf den neuen Registrar. Wenn man einen Change plant, hat man ja auch genügend Vorlaufzeit. 1 Tag sollte auf jeden Fall genügen. Der Client kann den Registrar natürlich nur dann wechseln, wenn er idle ist. Sollte aber über einen längeren Zeitraum problemlos gehen. Genauso habe ich meine Routine um Asterisk herum gebaut. Ist wahrlich kein Act.
Fällt ein Registrar plötzlich aus (weil er z.B. netztechnisch nicht mehr erreichbar ist), wird Dein Gespräch so oder so früher oder später unterbrochen (spätestens nach ca. 12 Minuten (660s + Karrenzzeit)). Wenn der Mediaserver nicht mehr erreichbar ist, ist sofort Feierabend.
Der Client kann nun aber sofort reagieren und den nicht mehr erreichbaren Registrar blacklisten und den nächsten aus der Liste anfahren. Die nächsten Calls gehen dann wieder problemlos. Die Ausfallzeit ist also maximal ca. 12 Minuten.
Arbeitet man mit options-Paketen / qualify alle 5 Minuten z.B. kann man den Wechsel schon früher einleiten und die Ausfallzeit kann nochmal deutlich reduziert werden.

Ich glaube schon, dass man mit letztlich relativ wenig Aufwand den Zustand erfassen kann und dann entsprechend seine Verbindungen verwalten kann. Mir ist bisher noch nichts eingefallen, was man machen kann, wenn man etwa bei Server A registriert ist, der dann ausfällt und man sich dann an Server B anmeldet. Bestehende Gespräche würden so immer gekappt werden. Da ich bisher noch nie einen wirklichen Serverausfall gesehen habe, wäre das momentan eine eher theoretische Fragestellung.

Bei einem ungeplanten Ausfall hast Du (je nach Ursache natürlich) so oder so kaum eine Chance. Beim Mediaserver sowieso nicht. Wenn ein laufender Call wegbricht, ist das natürlich nicht toll - wenn ich dann aber sofort den Call neu aufbauen kann, ist das nicht mehr so kritisch.

Wie gesagt, bei den SIP-Trunk Produkten wird ja auch nicht so diskutiert wie bei dem ALLIP Produkt, obwohl manches ähnlich ist.

Was nicht viel sagt. Ich selbst kenne die nicht - kann ich also nichts zu sagen.

Zu "use case 2": Ich habe eine zeit lang an Wochenenden ein Skript laufen lassen und alle paar Sekunden die gesamte Hierarschie NAPTR/SRV ausgewertet. Während die 20er und 30er Einträge konstant blieben, wechselte alle paar Minuten der 10er Server.

Kann ich hier allerdings nicht nachvollziehen. Die Reihenfolge der Server ändert sich natürlich ständig - die Prio der einzelnen Server ist aber unverändert - und damit stört das grundsätzlich nicht (weil Asterisk die Prio berücksichtigt). Welchen Nameserver hast Du gefragt? Probiers mal mit 2003:180:2:a000::53.

Bei Asterisk würde das aber so nie ankommen, da die TTL Zeiten berücksichtigt werden und es im Mittel erst nach einer halben Stunde zu Wechseln kommen kann. Da die Server im Hintergrund häufiger wechseln, kommt noch eine Zufallskomponente hinzu und die mittlere Zeit ist etwas größer als eine halbe Stunde.

Asterisk fragt bei jedem Request vorher den DNS (habe ich hier im Logfile vom named). Bei 3 Trunks ist das ca. jede Minute der Fall. Daraus würden sich auch die Probleme erklären, die immer wieder aufschlagen im Internet und warum man dann auch plötzlich authentifizierte qualifys benötigt. Ist auch das von J. Colp mir gegenüber beschriebenes Verhalten von Asterisk.

 

[ubsyathEe]

Asterisk hat verschiedene Möglichkeiten mit DNS umzugehen. Unter anderem kann man libunbound direkt einbinden. Es wird dann auch nicht zwingend der Standard DNS Server des lokalen Netzes verwendet.