Telekom All-IP mit RasPBX

[mschlee]

Hallo zusammen,

inzwischen funktioniert unsere RasPBX mit Telekom All-IP hinter einem Draytek Router meistens. D. h., besonders wenn man dringend telefonieren muss, kommt "All circuits are busy now" oder Telefonate brechen ab (bzw. mindestens einer der Teilnehmer hört nichts mehr).

Ich habe herausgefunden, dass "All circuits are busy now" sich durch einen kompletten Reboot des Raspberry, nicht aber durch einen Neustart von Asterisk beheben lässt. FreePBX zeigt die Trunks als "registered" an, auch wenn "All circuits are busy" gemeldet wird.

Offenbar muss hier noch einiges an Fine-Tuning geschehen.

Hat jemand bereits FreePBX mit Telekom All-IP im Einsatz und kann mir Hinweise zum Konfigurieren des PJSIP-Trunks (und anderer Parameter, falls nötig) geben ?

Meine Einstellungen sind:

General

Trunk Name: <Telefonnummer 0049 …>
Hide Caller ID: none
Outbound Caller ID: <Telefonnummer 0049 …>
CID Options: Allow Any CID
Maximum Channels: 6
Asterisk Trunk Dial Options: T / System
Continue if busy: No
Disable Trunk: No
Monitor Trunk Failures: No

PJSIP

Username: leer
Password: leer
Authentication: outbound
Registration: send
Language Code: default
SIP-Server: tel.t-online.de
SIP-Server Port: 5060
Context: from-pstn
Transport: 0.0.0.0-udp

Advanced

DTMF mode: auto
Permanent auth rejection: Yes
Forbidden Retry Interval: 10
Fatal Retry interval: 0
General Retry interval: 60
Expiration: 480
Max Retries: 10
Qualify Frequency: 60
Outbound Proxy: leer
Contact User: <Telefonnummer 0049 …>
From-Domain: tel.t-online.de
From-User: <Telefonnummer 0049 …>
Client URI: leer
Server URI: leer
Media Adress: leer
AOR: leer
AOR contact: leer
Match (permit): leer
Support Path: No
Support T.38 UDPTL: No
T.38 UDPTL Error correction: None
T.38 UDPTL NAT: No
T.38 UDPTL MAXDATAGRAM: leer
Fax Detect: no
Trust RPID/PAID: no
Send RPID/PAID: no
Match Inland Authentication: default
Inband Progress: No
Direct Media: No
Rewrite Contact: Yes
RTP Symmetric: Yes
Media Encryption: None
Message Context: Leer

Codecs

Alaw, Ulaw, G722

Die Asterisk General SIP Settings sind wie folgt:

Allow Anonymous Inbound SIP calls: No
Allow SIP guests: No
Default TLS assignment: ausgebaut
External Address: leer
Local Networks: leer
RTP Port Ranges: from 10000 to 20000
RTP checksums: yes
Strict RTP: yes
RTP Timeout: 30
RTP Hold Timeout: 300
RTP Keep Alive: 0
Stun Server Address: leer (Media Transport settings)
TURN Server Address: leer
TURN Server User Name: leer
TURN Server Password: leer
IP Addresses: leer
Candidates: leer
Stun Server Address: leer (WEB rtc settings)
TURN Server Address: leer
TURN Server User Name: leer
TURN Server Password: leer
T38 passthrough: no
Codecs: g722, ulaw, alaw, gsm, g726

CHAN_PJSIP Settings

Allow Transports Reload: No
Show Advanced settings: No
Endpoint identifier order: ip, username, anonymous, header, auth_username
Certificate Manager: Select A Certificate
SSL Method: default
udp: udp-0.0.0.0-all Yes
tcp: tcp-0.0.0.0-all No
tls: tls-0.0.0.0-all No
ws: ws-0.0.0.0-all No
wss: wss-0.0.0.0-all No
0.0.0.0-udp Port to listen on: 5060
Domain the transport comes from: leer
External IP-Address: leer
Local Network: leer

[Edit Novize: Code-Tage zwecks besserer Lesbarkeit eingefügt]
Was kann ich ansonsten tun, um den Ursachen auf den Grund zu kommen ? Switch bzw. Firewall mit Port-Mirroring ist vorhanden.

Kann ich etwas an der Firewall einstellen, um (ohne gravierende Sicherheitslücken zu erzeugen) die Verbindungsqualität zu verbessern (Ports freigeben, ALG ein- oder ausschalten) ?

Im Einsatz sind: FreePBX 14.0.13.4 / Asterisk 13.27.0 auf PI3B+ mit Draytek Vigor 3220 und All-Net Modem an 16 MBit/s-Leitung. Telefone Snom D-385. Separates VLAN für Telefonie.

Vielen Dank, dass Ihr bis zum Ende gelesen habt.

Für jeden Hinweis bin ich dankbar.

Gruß - Martin

 

[Voly]

Hi Martin,

hast du die aktuelle Firmware auf dem Draytek Vigor 3220?
So ein ähnliches Problem hatte ich ich auch mal damit und es lag an dem Vigor.

Gruß
Axel

 

[mschlee]

Vor lauter Verzweiflung habe ich mal den SIP Port 5060 geöffnet und den Bereich für RTP (10001-20000) ebenso. Seitdem empfange ich alle Anrufe zuverlässig. Trotzdem geschieht es, dass Anrufe abbrechen (oder einer den anderen nicht mehr hört). Versuche ich dann, zurückzurufen, bekomme ich das verhasste "all circuits are busy now ...". Freepbx zeigt dabei an, dass alle Trunks korrekt registriert sind.

Woran kann das liegen ?

Martin

 

[ubsyathEe]

Ich würde mal einen pcap Trace erstellen. Es braucht nicht telefoniert zu werden und es reicht aus, die Reregistrierungen und OPTION Requests zu verfolgen. Es sieht hier nach einem ALL-IP Anschluss aus und da gibt es eine Besonderheit, die hier irgendwo auch schon mehrfach beschrieben worden ist.

Es kann sein, dass nach einer gewissen Zeit die OPTION Requests abgelehnt werden, dann laufen zunächst auch alle INVITEs ins Leere. Asterisk wertet die jeweiligen Adressen bei jeder Aktion aus und es kann vorkommen, dass bei einem Prioritätswechselt nach einer SRV Abfrage zunächst ein anderer Proxy verwendet wird als der, bei dem man registriert ist. Bei dem ALL-IP Anschluss tauschen sich die Server im Hintergrund nicht aus. Defacto kommuniziert man verschiedenen Servern unter der gleichen Adresse.

Bei den SIP Trunk Produkten taucht das Problem (anscheinend) nicht auf. Wenn man nachts mal tcpdump laufen lässt, dann lässt sich das beschriebene Problem leicht verifizieren, oder es ist doch etwas anderes.

 

[mschlee]

Ich habe mal sngrep laufen lassen. In der Tat gibt es Probleme mit den OPTION Requests. Immer wenn die Telekom unter tel.t-online.de einen anderen Server aktiviert (andere IP-Adresse), schlägt der OPTION Request (und alle folgenden) fehl. Erst nach einiger Zeit sind die OPTION Requests wieder erfolgreich. Kann FreePBX/Asterisk damit nicht umgehen ? Ist es empfehlenswert, kurzerhand den Provider zu wechseln oder gibt es ein Rezept ?

--

Hmm, habe einfach mal per /etc/hosts die IP-Adresse für tel.t-online.de festgetackert. Mal sehen, ob das was bringt.

 

[ubsyathEe]

Von Haus aus kann Asterisk nicht damit umgehen, aber es ist kein Asterisk Problem. Bei dem ALL-IP Produkt geht man fälschlicherweise davon aus, dass nach einer Registrierung grundsätzlich nur die Kontakte der entsprechenden Registrierung verwendet werden und das verursacht die Probleme. Ein SIP Stack müsste also den Zustand der Registrierungen verwalten und sich dann später immer darauf beziehen. Das wäre eine ungewöhnliche Kommunikation mit einem Server.

Es gibt nur Behelfslösungen, die alle gewisse Nachteile haben. Eine zu tel.t-online.de zugehörige IP einzufrieren hat den Nachteil, dass gar nichts mehr geht, wenn dieser Proxy Server vom Netz geht (nix für Kunden). Könnte man die Daten der Registrierung weiter verwenden, dann wäre die PBX auch weg bis es zur nächsten Registrierung kommt. Ob das notfalls für eine Notrufnummer ausreichen würde, kann man in Frage stellen.

Es gibt noch andere Möglichkeiten damit umzugehen. Das fehlgeschlagene INVITE kann Asterisk erkennen und dann selbst eine Neuregistrierung anleiern bevor ein zweites Mal das INVITE geschickt wird. Das Problem ist hier, dass möglicherweise bestehende Verbindungen sofort gekappt werden. Das wäre nichts für Geschäfte mit vielen Anrufen. Bei mir privat habe ich das so geregelt.

Es gibt noch eine Nebenwirkung dieses Serververhaltens. Wenn die Telekom einen neuen Server mit Priorität 10 vorgibt und eine Telefonanlage sich damit registriert, dann werden bereits bestehende Gespräche nach einiger Zeit von der Telekom beendet wegen fehlender Autorisierung am altern Server. In diesem Fall wird das Gespräch mit dem Fehlercode [Not Found 1:27] beendet. Das kann einem nach 60 Sekunden oder nach einer halben Stunde passieren.

 

[mschlee]

Vielen Dank für Deine ausführlichen Hinweise. Das hat mich wirklich weitergebracht. Meine Lösung ist: Reboot der Anlage jede Nacht um 4:00 Uhr. Danach die IP-Adresse für tel.t-online.de ermitteln und über /etc/hosts einfrieren. Parallel dazu alle 5 min überprüfen, ob sich diese Adresse anpingen lässt. Wenn dies nicht möglich ist, wird nachgesehen, ob unter tel.t-online.de nun eine andere IP zur Verfügung steht, und diese wird dann verwendet.

So sollte es eigentlich störungsfrei laufen. Ansonsten weiß ich nicht, weshalb ich überhaupt auf die Idee gekommen bin, die Telekom zu beauftragen. Viele schlechte Erfahrungen mit dem Laden (auch wenn über 10 Jahre her) hätten mich warnen müssen.

Gruß - Martin

 

[ubsyathEe]

Soweit ich weiß, hat 3CX eine Option, wo dann nur noch mit dem Registrierungsserver zu kommunizieren. Das ginge mit Code-Änderungen auch bei Asterisk, bzw. man muss sich den PSJIP Code von Teluu ansehen. Steht auf meiner Liste, aber nicht mit höchster Priorität. Insgesamt handelt es sich bei dem ALL-IP Anschluss um ein wenig durchdachtes Produkt.

Der SIP Trunk der Telekom ist da ganz anders und verwendet intern auch ein anderes Produkt von IBM.

Was mich am meisten hier stört ist, dass man am Telefon schon ziemlich penetrant werden muss um überhaupt so ein technisches Problem beschreiben zu können. Auch dann wird die Existenz des Problems noch über Wochen geleugnet, wobei unterschwellig signalisiert wird, dass man keine Ahnung habe und wohl doch besser Telekomprodukte hätte kaufen sollen. Wäre mal interessant zu wissen, was die Digibox intern so macht. Mir sind jedenfalls im Frühjahr recht viele DNS SRV Abfragen aufgefallen, was wohl auch eine ähnlich Sicherung darstellt wie von Dir beschrieben...

 

[Meester Proper]

Ich glaube es müssen hier einige Mythen aufgeklärt werden:

Es können natürlich nur Gespräche über P-CSCF getätigt werden, mit denen vorher eine Registrierung erfolgt ist. Das gleiche gilt für OPTION-Requests.
Werden bei der SRV-Abfrage andere / anders priorisierte P-CSCF vorgegeben, muss dort erst eine Registrierung erfolgen, damit darüber neue Gespräche aufgebaut werden können.

Bestehende Gespräche sind allerdings an die P-CSCF gebunden, über die sie aufgebaut wurden. Problematisch kann hier das (UDP) NAT-Portbinding sein, wenn hier längere Zeit keine Signalisierung erfolgt, löscht der Router in seiner NA(P)T-Tabelle den Eintrag und von außen eingehende Pakete werden nicht mehr in das LAN weitergeleitet. Daher sollte möglichst TCP eingesetzt werden, denn der Timeout für TCP NAT-Portbindings ist gewöhnlich deutlich höher.

Um die DNS-Ergebnisse möglichst konstant zu halten, sollte übrigens immer der selbe DNS-Server genutzt werden, also bspw. der in der PPPoE-Einwahl mitgeteilte DNS-Server (bzw. der DSL-Router, der diese/n DNS-Server nutzt).

Das Verhalten beim DLAN SIP-Trunk Produkt ist übrigens identisch, auch hier muss erst eine Registrierung erfolgen, damit Gespräche aufgebaut werden können oder OPTIONS beantwortet werden.

 

[ubsyathEe]

Es handelt sich hier nicht um Mythen, sondern um Fakten und das Telekom ALL-IP Produkt verhält sich anders als die beiden SIP-Trunk Produkte. Es macht keinen Unterschied, ob man TCP oder UDP als Transport verwendet, es sei den man hat die Timings für die NAT-Tabellen falsch konfiguriert, wobei das bei Haushaltsgeräten eher nicht möglich ist. Übrigens erlaubt die Telekom seit einiger Zeit auch OPTION Requests.

Wenn man eine symbolische Adresse bekommen hat, dann kann man erwarten, dass die auch funktioniert, denn durch die NAPTR und SRV Lookups hat man die Kontrolle über die darunterliegenden Server aufgegeben. Übrigens hat man auch keine wirkliche Kontrolle über den verwendeten DNS-Server, da bei neueren Asterisk-Versionen der von der NAPTR beworbene verwendet wird und nicht, was immer ansonsten verwendet wird.

Das mit der PPPoE-Einwahl kann man wohl als Scherz auffassen, denn es macht keinen Sinn diese Server zu verwenden, da letztlich die Proxy-Struktur der Telekom intern ist und im Zweifel gar nicht durch allgemeine Server aufgelöst werden. Derzeit werden aber die *.t-ipnet.de Server durch allgemeine DNS-Server aufgelöst, was aber nicht wirklich nötig wäre.

Das mit den Mythen verhält sich genau andersherum. Man könnte sich ja mal einen pcap-Trace ansehen...

 

[Meester Proper]

Zum Thema DNS-Server: Ich wollte hier nur darauf hinweisen, dass unterschiedliche DNS-Server unterschiedliche Antworten liefern:

dig @1.1.1.1 SRV _sip._udp.tel.t-online.de

; <<>> DiG 9.10.6 <<>> @1.1.1.1 SRV _sip._udp.tel.t-online.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27000
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.    IN    SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 2984    IN    SRV    10 0 5060 h-epp-100.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 2984    IN    SRV    20 0 5060 d-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 2984    IN    SRV    30 0 5060 h2-epp-110.edns.t-ipnet.de.

;; Query time: 27 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Sep 08 12:57:25 CEST 2019
;; MSG SIZE  rcvd: 190

dig @8.8.8.8 SRV _sip._udp.tel.t-online.de

; <<>> DiG 9.10.6 <<>> @8.8.8.8 SRV _sip._udp.tel.t-online.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20262
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.    IN    SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 3599    IN    SRV    10 0 5060 k-epp-100.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3599    IN    SRV    30 0 5060 d-epp-100.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3599    IN    SRV    20 0 5060 h2-epp-100.edns.t-ipnet.de.

;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Sep 08 12:58:51 CEST 2019
;; MSG SIZE  rcvd: 190

dig @9.9.9.9 SRV _sip._udp.tel.t-online.de

; <<>> DiG 9.10.6 <<>> @9.9.9.9 SRV _sip._udp.tel.t-online.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39587
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.    IN    SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 3600    IN    SRV    10 0 5060 h-epp-100.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600    IN    SRV    20 0 5060 h2-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600    IN    SRV    30 0 5060 d-epp-110.edns.t-ipnet.de.

;; Query time: 96 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sun Sep 08 12:59:42 CEST 2019
;; MSG SIZE  rcvd: 190

Wenn nun der genutzte DNS-Server für die Asterisk unterschiedliche Upstream-Resolver nutzt, kann es sein, dass sich das Ergebnis bei jeder Abfrage ändert. Die Asterisk würde also immer hin- und herspringen, zwischen den gelieferten P-CSCF.

Der Grundirrtum liegt jedoch darin, dass die Asterisk offenbar denkt, dass alle per DNS gelieferte Server zustandslos sind, d.h. dass dort die Registrierung ebenso besteht. Tatsächlich sind die P-CSCF zustandsbehaftet, d.h. es muss eine gültige Registrierung vorliegen, damit ein Anruf getätigt werden kann und bestehende Gespräche sind immer hart an ihre P-CSCF gebunden. Die Signalisierung darf nicht an andere P-CSCF geschickt werden.

 

[ubsyathEe]

Das ist kein Asterisk bzw. PJSIP Irrtum; es ist ein Telekom Irrtum. Genau in diesem Punkt unterscheiden sich die beiden SIP-Trunk Produkte von dem ALL-IP Produkt.

Im Hinblick auf die Server-Auflösung verhält sich Asterisk genau so wie in der 1TR114 beschrieben.

 

[Meester Proper]

Es gibt in diesem Hinblick keinen Unterschied zum SIP-Trunk Produkt: Ohne gültige Registrierung kein Gesprächsaufbau und positive Beantwortung von OPTION-Requests.

Gerne lasse ich mich mit PCAPs vom Gegenteil überzeugen.

 

[gehtdoch]

Mal ein paar grundsätzliche Punkte:

1. Die vom OP eingesetzte Asterisk-Version kann weder NAPTR noch SRV. Dazu ist mindestes Asterisk 16.x nötig. 16.x kann auch mit mehreren SRV-Einträgen umgehen (ein bisschen zumindest).
2. Asterisk macht vor jedem Request eine DNS-Auflösung und nimmt dann den zu diesem Zeitpunkt vorhandenen Eintrag.

Dieses Konzept passt nicht zum (Betriebs-)Konzept von Telekom AllIP, da hier grundsätzlich alle Requests immer zum selben Server gehen müssen.
IaW: Man muss selbst von Außen dafür sorgen, dass diese Bedingung gegeben ist, z.B. durch den geschicktes Verwenden der RPZ-Technik von bind.

Selbst dieser Workaround hilft nichts, wenn, wie kürzlich geschehen, der primäre Server in der SRV-Liste einfach nicht mehr will, weil das Asterisk nicht geordnet auf die Reihe kriegt: da hat er für den REGISTER schon korrekterweise zum zweiten Server gefunden - aber macht dann den INVITE hinterher doch wieder zum ersten Server (ich habe Logs, die genau dieses Problem zeigen). Das war's dann.

Es macht bei einer Liste von möglichen Servern einfach keinen Sinn, stateless zu operieren! Asterisk muss sich auf jeden Fall global merken, welche Server genutzt werden können und welche nicht. Server, die als unbrauchbar erkannt wurden, müssen auf eine Blacklist gesetzt werden und dürfen bis auf Weiteres nicht mehr verwendet werden - egal für welchen Request auch immer!

 

[ubsyathEe]

Im Asterisk Forum gibt es eine Stellungnahme von Joshua Colp (Digium). Das Verhalten der Telekom-Server wird als "ungewöhnlich" bezeichnet. Ich stimme dem zu, und zwar aus folgender Überlegung heraus.

Wenn Asterisk darüber buchführen soll wie kommuniziert wird, dann kann es minutenlang zu Ausfällen kommen, was bei Notrufen ein (rechtliches) Problem ist. Sollte ein Telekomproxy ausfallen, dann merkt Asterisk das erst, wenn es zu einer Neuregistrierung kommt (derzeit bis zu 650s). Wenn die Telekom (wie bei dem SIP-Trunk) buchführt, führt die nächste Kommunikation automatisch zum nächsten funktionierenden Server, vorausgesetzt nicht alle sind ausgefallen.

Asterisk kann mit den Telekom-Servern nur sauber umgehen, wenn man den PJSIP-Stack verwendet. Dazu gibt es auch einen Blog-Eintrag von Joshua Colp, wobei die Unterschiede bei der SRV-Auflösunge zwischen chan_sip und PJSIP erklärt sind.

Für jede VoIP-Anlage sieht das Telekom ALL-IP so aus, als ob hinter tel.t-online.de sich mehrere unabhängige Server befinden. Das macht überhaupt keinen Sinn. Ich selbst habe Kunden, die mehrfach pro Woche in das Problem laufen, aber auch welche, die noch nie ein Problem hatten. Kann sein, dass es hier sogar regionale Unterschiede gibt, was die Wechsel der Server-Prioritäten angeht. Kann aber auch sein, dass ich keine korrekte Infos bekomme.

 

[gehtdoch]

Wenn Asterisk darüber buchführen soll wie kommuniziert wird, dann kann es minutenlang zu Ausfällen kommen, was bei Notrufen ein (rechtliches) Problem ist. Sollte ein Telekomproxy ausfallen, dann merkt Asterisk das erst, wenn es zu einer Neuregistrierung kommt (derzeit bis zu 650s).

Die Aussage ist korrekt im Zusammenhang, wie Asterisk incl. 16.x programmiert ist - weil es stateless ist. Das wäre aber problemlos zu ändern. Es gibt OPTIONS-Pakete, deren Intervall man selbst definiert. Über diese kann man einen Ausfall sehr viel schneller erkennen. Oder in Kombination mit TCP Keepalive.

Selbst ohne die Options wäre das kein Problem, wenn Asterisk nicht stateless wäre: Innerhalb von z.B. 3 Sekunden kommt keine brauchbare Antwort auf ein Invite -> Nächster Server aus der Liste. Erst Register, dann Invite wiederholen. Ausgefallenen Server auf die derzeit nicht vorhandene Blacklist setzen.

Asterisk kann mit den Telekom-Servern nur sauber umgehen, wenn man den PJSIP-Stack verwendet.

Nein (bezogen auf "sauber"). Nicht bis zu 16.x - ab 17.x wäre mir auch noch nicht bekannt. Aber es ist in soweit korrekt, dass es mit PJSIP besser ist als mit chan_sip.

Dazu gibt es auch einen Blog-Eintrag von Joshua Colp, wobei die Unterschiede bei der SRV-Auflösunge zwischen chan_sip und PJSIP erklärt sind.

SRV und NAPTR allein bringt absolut nichts, solange Asterisk stateless arbeitet. Selbst wenn es stateful arbeiten würde, wäre die Implementierung derzeit nicht brauchbar, weil es defekte Server nicht markiert, sondern an ihnen immer wieder kleben bleibt - was ich an dem Ausfall kürzlich schmerzlich feststellen musste. Wenigstens einen defekten Server könnte man sich merken. Erst als ich den defekten Server (war der primäre) aus der RPZ-Liste genommen habe, war wieder alles gut.

Für jede VoIP-Anlage sieht das Telekom ALL-IP so aus, als ob hinter tel.t-online.de sich mehrere unabhängige Server befinden. Das macht überhaupt keinen Sinn. Ich selbst habe Kunden, die mehrfach pro Woche in das Problem laufen, aber auch welche, die noch nie ein Problem hatten. Kann sein, dass es hier sogar regionale Unterschiede gibt, was die Wechsel der Server-Prioritäten angeht. Kann aber auch sein, dass ich keine korrekte Infos bekomme.

Das ist das nächste Problem: Asterisk kann noch nicht einmal von sich aus ohne äußere Unterstützung mit dem Wechsel der Prioritäten umgehen (im Zusammenhang mit dem Betriebskonzept von All-IP) - immer wieder das gleiche Problem als Ursache: Stateless - es wird kein Zusammenhang sichergestellt zwischen REGISTER und allen anderen Requests. Ob das jetzt seitens der Telekom ungewöhnlich ist oder nicht (das ist eine Wertung) - es ist eben so.

Dass bei AlI-IP hinsichtlich HA viel Logik dem Client überlassen wird, kann man wohl sagen. Ich gehe mal positiv davon aus, dass dies gute Gründe hat. Abgesehen davon habe ich außer All-IP noch zwei weitere VoIP-Provider (die das "übliche" Konzept fahren), die (zumindest bisher) an die Verfügbarkeit der All-IP-Infrastruktur noch nicht einmal ansatzweise rankommen.

 

[ubsyathEe]

Wenn ALL-IP wie SIP-TRUNK arbeiten würden, würden wir hier nicht geschrieben haben.

 

[mschlee]

Okay, bei diesen Details komme ich nicht mit. Seit ich den oben beschriebenen Workaround nutze (von meiner Leitung aus gibt es offenbar nur zwei IP-Adressen, die abwechselnd unter tel.t-online.de ausgegeben werden), kann ich zuverlässig nach draußen wählen und werde auch bei Anrufversuchen problemlos erreicht. Allerdings kommt es noch vor, dass die Telefonate nach einiger Zeit beendet werden müssen, weil eine Seite nichts mehr hört. Ich habe auf unserer Firewall alle Ports von 10000 bis 20000 für UDP und Telekomserver als Source freigegeben. Was könnte hier noch als Ursache in Frage kommen ?