5.01.2022 (zuletzt aktualisiert am 26.01.2022)
Mehrere Asterisk-Server lassen sich mit Hilfe des IAX2-Protokolls zu Netzwerken verbinden. Die einzelnen Asterisk-Server sind über Durchwahlen erreichbar. Sind die Server über das Internet verbunden, müssen in den Routern nur der Port 4569 UDP weitergeleitet werden. Über diesen Port können eine große Anzahl von Gesprächen geleitet werden. Selbst wenn mehrere Asterisk-Server über IAX2 erreichbar sind, reicht es aus nur den Port 4569 UDP weiterzuleiten.
Die einzelnen Asterisk-Server sind immer paarweise miteinander zu verbinden. Ein Asterisk-Server kann sich mit mehreren anderen Asterisk-Servern paaren. Dadurch bilden sich Netzwerke mit großer Gestaltungsfreiheit.
Getestet wurde das hier vorgestellte Verfahren mit 4 Asterisk-Servern, die miteinander über IAX2 verbunden sind. Über Vorwahlen kann die Route für Telefonate festgelegt werden. Telefonate lassen sich über mehrere Router durchleiten. Wer es sich zutraut, kann mit Hilfe von https://github.com/ybinzu/asterisk_mesh ein Mesh-Netz aus vielen Asterisk-Servern aufbauen.
Voraussetzung für das Verständnis dieses Artikels ist, dass man bereits erfolgreich einen Asterisk-SIP-Server mit mindestens zwei Telefonnummern und ein paar Testnummern eingerichtet hat.
Änderungen an der iax.conf müssen im Asterisk-CLI mit „iax2 reload“ geladen werden. Das erfolgreiche Connecten zum Partner-Server lässt sich mit „iax2 show peers“ überprüfen. Mit “ iax2 show channels“ lassen sich die „laufenden Telefonate“ anzeigen.
Beim Verfassen der interagierenden iax.conf-Skripte ist Sorgfalt angebracht, da sie miteinander symmetrisch verwoben oder verschränkt sind. Deshalb bediene ich mich konkreter Beispiele, die auch getestet wurden.
Beispiel 1 zur Einübung mit zwei Asterisk-Servern im eigenen LAN: Zwei Asterisk-Server befinden sich innerhalb desselben lokalen Netzwerks auf verschiedenen Rechnern mit statischen lokalen IPs. Der eine befindet sich im Keller mit der IP 192.168.1.44 , der andere in der Wohnung mit der IP 192.168.123. Die Verbindung hat sich als „bombenfest“ erwiesen.
Die iax.conf im Keller: Für Übungszwecke und zum Ausprobieren ist dieser Asterisk-Server nur über das lokale Netzwerk erreichbar.
; KELLER ; iax.conf für Asterisk-Server im Keller mit Asterisk 1.6.2.5 ; testweise auf einem 20 Jahre alten Notebook mit Lubuntu (Ubuntu 10.04.LTS) ; Lokale IP im Keller ist 192.168.1.44 ; Merke: ; peer darf nur anrufen ; user darf nur angerufen werden ; friend darf alles, anrufen und angerufen werden ; weitere Eklärungen der iax.conf: ; https://github.com/asterisk/asterisk/blob/master/configs/samples/iax.conf.sample [general] ; general immer gleich disallow=all allow=alaw allow=ulaw allow=gsm allow=g722 jitterbuffer=no forcejitterbuffer=no autokill=yes delayreject=yes requirecalltoken=no [outgoing-wohnung] ; Context für abgehende Gespräche zur Wohnung type=peer ; es funktionieren nur abgehende Gespräche host=192.168.1.123 ; Statische lokale IP des Servers in der Wohnung secret=qf00jnw7nj7exyz ; das Passwort muss bei beiden Servern dasselbe sein. auth=md5 ; Verschlüsselung (optional) context=telefone-aus ; Gespräche können von Extensions im Context "telefone-aus" ausgehen trunk=yes ; Viele Gespräche gleichzeitig möglich. qualify=yes ; macht Verbindungsqualität im CLI mit "iax2 show peers" sichtbar. requirecalltoken=no calltokenoptional=yes authdebug=yes username=incoming-keller ; Gespräch "landet" im Context "incoming-keller" iax.conf Wohnung tos=ef deny=0.0.0.0/0.0.0.0 ; alle erreichbaren IP-Adressen verbieten (optional) permit=192.168.1.123 ; und dann nur die IP des Servers in der Wohnung zulassen (optional) notransfer=yes iaxcompat=yes nochecksums=yes [incoming-wohnung] ; Hier kommen die Gespräche von der Wohnung herein type=user ; Es können nur Gespräche entgegengenommen werden host=192.168.1.123 ; Die statische lokale IP Asterisk-Wohnung-Server secret=qf00jnw7nj7exyz ; immer dasselbe Passwort verwenden auth=md5 context=telefone-ein ; Extensions im Context "telefone-ein" der extensions.conf erreichbar trunk=yes qualify=yes requirecalltoken=no calltokenoptional=yes authdebug=yes username=outgoing-keller ; Gespräche kommen von outgoing-keller der iax.conf Wohnung herein tos=ef deny=0.0.0.0/0.0.0.0 permit=192.168.1.123 notransfer=yes iaxcompat=yes nochecksums=yes ; Vieles ist nach dem Motto "doppelt genäht hält besser" ausgeführt und kann ; auch überflüssig sein oder wird von bestimmen Versionen ignoriert.
Der entsprechende Ausschnitt in der extensions.conf im Keller-Server:
[telefone-aus] ; siehe die Entsprechung in iax.conf "context=telefone-aus"
; in [outgoing-wohnung]
exten => _8899X.,1,NoOp(IAX2-Verbindung Keller ruft Wohnung an mit Vorwahl 8899)
same => n,Dial(IAX2/outgoing-wohnung/${EXTEN:4}) ; geht zu [outgoing-wohnung] der iax.conf
same => n,Hangup()
; Signalweg: Der Anruf aus dem Keller geht zu [outgoing-wohnung] in der eigenen iax.conf. Nachfolgend der entscheidende Auszug:
; [outgoing-wohnung] ; Context für abgehende Gespräche zur Wohnung
; type=peer ; es funktionieren nur abgehende Gespräche
; host=192.168.1.123 ; Statische lokale IP des Servers in der Wohnung
; secret=qf00jnw7nj7exyz ; das Passwort muss bei beiden Servern dasselbe sein.
; auth=md5 ; Verschlüsselung (optional)
; context=telefone-aus
; username=incoming-keller
; In der eigenen iax.conf steht als Ziel der host samt Passwort.
; Nur Extensions (Telefone) aus dem
; Context [telefone-aus] der eigenen extensions.conf dürfen heraustelefonieren.
; Der Ausdruck "username=incoming-keller" bestimmt das Ziel [incoming-keller]
; in der iax.conf ; des Partners.
; Das Pattern-Matching sorgt dafür, dass die ersten 4 Ziffern 8899 abgeschnitten werden.
; Die 8899 dient als Vorwahl für die Nummern auf dem Wohnungs-Server.
; Eine Vorwahl ist nur notwendig, wenn sich Nummernblöcke überschneiden können.
; Ein weiterer Witz mit den Vorwahlen ist, dass sie sich kaskadieren lassen,
; um ein Telefonat durch verschiedene Asterisk-Server durchzuleiten.
; Man kann auch ein Telefonat mit Vorwahlen innerhalb eines Servers hin- und zurückschicken,
; was keinen Sinn macht, aber dennoch funktioniert.
Zu Testzwecken wurden im Keller-Asterisk-Server noch 2 Accounts für zwei SIP-Telefone angelegt, damit über SIP-Telefone Gespräche möglich sind. Dieser SIP-Server muss einen vom üblichen SIP-Port 5060 abweichenden Port erhalten, damit sich die verschiedenen SIP-Server nicht ins Gehege kommen. Der Port 5060 ist meistens schon vom SIP-fähigen Router (z.B. FritzBox) belegt.
Die iax.conf des Asterisk-Servers mit der IP 192.168.1.123 in der Wohnung ist „spiegelbildlich“:
; WOHNUNG ; iax.conf für Asterisk-Server in der Wohnung mit Asterisk 16.2.1 ; auf einem Raspberry Pi mit Raspbian und der lokalen IP 192.168.1.123 [general] ; general immer gleich disallow=all allow=alaw allow=ulaw allow=gsm allow=g722 jitterbuffer=no forcejitterbuffer=no autokill=yes delayreject=yes requirecalltoken=no [outgoing-keller] ; Context für abgehende Gespräche zum Keller type=peer ; es funktionieren nur abgehende Gespräche host=192.168.1.44 ; Statische lokale IP des Servers in Keller secret=qf00jnw7nj7exyz ; das Passwort muss bei beiden Servern dasselbe sein. auth=md5 ; Verschlüsselung (optional) context=phones-out ; Gespräche können von Extensions im Context "phones-out" ausgehen trunk=yes ; Viele Gespräche gleichzeitig möglich. qualify=yes ; macht Verbindungsqualität im CLI mit "iax2 show peers" sichtbar. requirecalltoken=no calltokenoptional=yes authdebug=yes username=incoming-wohnung ; Gespräch "landet" im Context "incoming-wohnung" iax.conf Keller tos=ef deny=0.0.0.0/0.0.0.0 ; alle erreichbaren IP-Adressen verbieten (optional) permit=192.168.1.44 ; und dann nur die IP des Servers im Keller zulassen (optional) notransfer=yes iaxcompat=yes nochecksums=yes [incoming-keller] ; Hier kommen die Gespräche vom Keller herein type=user ; Es können nur Gespräche entgegengenommen werden host=192.168.1.44 ; Die statische lokale IP vom Keller-Server secret=qf00jnw7nj7exyz ; immer dasselbe Passwort verwenden auth=md5 context=phones-in ; Extensions im Context "phones-in" der extensions.conf erreichbar trunk=yes qualify=yes requirecalltoken=no calltokenoptional=yes authdebug=yes username=outgoing-wohnung tos=ef deny=0.0.0.0/0.0.0.0 permit=192.168.1.44 notransfer=yes iaxcompat=yes nochecksums=yes
Der Ausschnitt der extensions.conf des Wohnungs-Servers gestaltet sich nach demselben Muster:
[phones-out] ; siehe die Entsprechung in iax.conf "context=phones-out"
; in [outgoing-keller]
exten => _8877X.,1,NoOp(IAX2-Verbindung Wohnung ruft Keller an 8877)
same => n,Dial(IAX2/outgoing-keller/${EXTEN:4}) ; geht zu [outgoing-keller] der iax.conf
same => n,Hangup()
; Das Pattern-Matching sorgt dafür, dass die ersten 4 Ziffern 8877 abgeschnitten werden.
; Die 8877 dient als Vorwahl für die Nummern auf dem Wohnungs-Server.
; Eine Vorwahl ist nur notwendig, wenn sich Nummernblöcke überschneiden können.
Es ist übrigens nicht notwendig, zwischen den Contexten „phones-in“, „phones-out“ und so weiter zu unterscheiden. Man darf sie durch eine identische Bezeichnung (z.B. „eingehende-und-ausgehende-telefone“) ersetzen. Das hängt davon ab, wie die extensions.conf organisiert ist und ob man will, dass bestimmte Telefone nur bestimmte Nummern erreichen dürfen oder nicht. Mit getrennten Contexten in der iax.conf für eingehende und ausgehende Gespräche ist man flexibel. Wenn man es einmal kapiert hat, ist es ganz einfach und logisch.
*******
Beispiel 2 mit einer Vernetzung über das Internet: Dies geht nach dem gleichen Strickmuster. Der Wohnungsserver bekommt eine zweite IAX2-Verbindung zu einem weiteren Asterisk-Server über das Internet, das heißt außerhalb des eigenen LANs. Diese Methode ist ebenfalls „bombenfest“.
Der Wohnzimmer-Server besitzt auch eine öffentliche IP, die über einen der zahlreichen DynDNS-Anbieter erreichbar ist. Im Beispiel hat er die schneesturm.ddns.net. Der Partner-Server irgendwo in der Welt ist über palmenstrand.hopto.org erreichbar. Wir nehmen an er sei an einem Palmenstrand, damit wir es uns leichter merken können.
Server, die über eine öffentliche statische IP besitzen, benötigen nicht den Umweg über einen DynDNS-Anbieter. Anstelle der DynDNS kann die öffentliche IP eingetragen werden. Nicht vergessen bei den Routern die Ports 4569 UDP weiterzuleiten.
Aktivierung des regelmäßigen IP-Lookup in der dnsmgr.conf: Private Internetzugänge besitzen gewöhnlich keine statische öffentliche IP. Entweder ändert sie die eigene öffentliche IP bei jedem Neustart des Routers oder es findet regelmäßig je nach Internet-Provider sogar jede Nacht eine Zwangstrennung mit der Zuteilung einer neuen IP statt. Andere Internetanbieter teilen erst nach Monaten eine neu IP zu. Bei einer IAX2-Verbindung können dadurch Verbindungsprobleme entstehen, die erst nach vielen Monaten auftreten und für großes Rätselraten sorgen, wenn trotz des Einsatzes eines DynDNS-Anbieters erst nach einem „core restart now“ die Verbindung steht. Dies ist allerdings eine unnötig brutale Lösung. Es geht eleganter.
Ändert sich die öffentliche IP des entfernten Asterisk-Server, übersendet der DynDNS-Anbieter des entfernten Asterisk-Servers die neue IP dem eigenen Asterisk-Server. Der eigene Server aktualisiert für eine IAX2-Verbindung allerdings nicht automatisch die neue öffentliche IP des anderen Asterisk-Servers. Abhilfe: In der dnsmgr.conf (im Ordner /etc/asterisk) des eigenen Asterisk-Servers ist durch folgende Einträge dafür zu sorgen alle paar Minuten einen DNS-Lookup vorzunehmen zu lassen:
; Einträge in der dnsmgr.conf für einen regelmäßigen DNS-Lookup
;
[general]
enable=yes ; enable creation of managed DNS lookups
; default is 'no'
refreshinterval=120 ; refresh managed DNS lookups every <n> seconds
; default is 300 (5 minutes)
Im Asterisk-CLI ist auf Grund des aktivierten DNS-Lookup bei einem IP-Wechsel des entfernten IAX2-Servers folgendes zu beobachten:
Damit die Änderungen in der dnsmgr.conf wirksam werden, ist wie üblich in der Asterisk-Konsole der Befehl „reload“ auszuführen, was manchmal leicht vergessen wird.
Die iax.conf des Wohnzimmer-Servers wird dann um den folgenden Eintrag ergänzt:
; WOHNUNG
; iax.conf für Asterisk-Server in der Wohnung mit Asterisk 16.2.1
; auf einem Raspberry Pi mit Raspbian und der DynDNS schneesturm.ddns.net
; ausgehende Gespräche zum Server am Palmenstrand
[outgoing-palmenstrand] ; Context für abgehende Gespräche zum entfernten Server
type=peer ; es funktionieren nur abgehende Gespräche
host=palmenstrand.hopto.org ; DynDNS des anderen Servers am Palmenstrand
username=incoming-schneesturm ; Die abgehenden Gespräche "landen" im Context
; [incoming-schneesturm] der iax.conf des anderen Servers
context=phones-out ; Gespräche gehen von der Extensions im Context "phones-out"
; unserer extensions.conf aus.
; der nachfolgende Rest bleibt gleich
secret=sonnenschein123 ; das Passwort muss bei beiden Servern dasselbe sein.
auth=md5 ; Verschlüsselung (optional)
trunk=yes ; Viele Gespräche gleichzeitig möglich.
qualify=yes ; macht Verbindungsqualität im CLI mit "iax2 show peers" sichtbar.
requirecalltoken=no
calltokenoptional=yes
authdebug=yes
; nachfolgendes optional
tos=ef
notransfer=yes
iaxcompat=yes
nochecksums=yes
; Hereinkommende Gespräche vom Palmenstrand
[incoming-palmenstrand] ; Hier kommen die Gespräche vom Palmenstrand herein
type=user ; Es können nur Gespräche entgegengenommen werden
host=palmenstrand.hopto.org ; DynDNS des Servers am Palmenstrand
username=outgoing-schneesturm ; Die Gespräche kommen vom Context
; [outgoing-schneesturm] der iax.conf
; des Servers am Palmenstrand
context=phones-in ; Nur die Nummern (extensions) im Kontext [phones-in] unserer
; extensions.conf sind erreichbar
; der nachfolgende Rest bleibt gleich
secret=sonnenschein123 ; immer dasselbe Passwort verwenden
auth=md5
trunk=yes
qualify=yes
requirecalltoken=no
calltokenoptional=yes
authdebug=yes
; nachfolgendes optional
tos=ef
notransfer=yes
iaxcompat=yes
nochecksums=yes
Der entsprechende Eintrag in der extensions.conf des Wohnzimmers:
; Auszug extensions.conf Wohnzimmer
[phones-out] ; siehe die Entsprechung in iax.conf "context=phones-out"
; in [outgoing-palmenstrand]
exten => _8855X.,1,NoOp(IAX2-Verbindung Wohnung ruft Palmenstrand an mit Vorwahl 8855)
same => n,Dial(IAX2/outgoing-palmenstrand/${EXTEN:4})
same => n,Hangup()
; mit der Vorwahl 8855 sind die Nummern am Palmenstrand erreichbar.
Die iax.conf und die extensions.conf am Palmenstrand sind dann wieder spiegelbildlich:
; PALMENSTRAND
; iax.conf für Asterisk-Server am Palmenstrand
; auf einem Raspberry Pi mit Raspbian und der DynDNS palmenstrand.hopto.org
; ausgehende Gespräche zum Server im Wohnzimmer
[outgoing-schneesturm] ; Context für abgehende Gespräche zum entfernten Server
type=peer ; es funktionieren nur abgehende Gespräche
host=schneesturm.ddns.net ; DynDNS des anderen Servers "Wohnung"
username=incoming-palmenstrand ; Die abgehenden Gespräche "landen" im Context
; [incoming-palmenstrand] der iax.conf des anderen Servers
context=phones-out ; Gespräche gehen von der Extensions im Context "phones-out"
; unserer extensions.conf aus.
; der nachfolgende Rest bleibt gleich
secret=sonnenschein123 ; das Passwort muss bei beiden Servern dasselbe sein.
auth=md5 ; Verschlüsselung (optional)
trunk=yes ; Viele Gespräche gleichzeitig möglich.
qualify=yes ; macht Verbindungsqualität im CLI mit "iax2 show peers" sichtbar.
requirecalltoken=no
calltokenoptional=yes
authdebug=yes
; nachfolgendes optional
tos=ef
notransfer=yes
iaxcompat=yes
nochecksums=yes
; iax.conf PALMENSTRAND
; Hereinkommende Gespräche vom Wohnzimmer zum Palmenstrand
[incoming-schneesturm] ; Hier kommen die Gespräche vom Wohnzimmer Schneesturm herein
type=user ; Es können nur Gespräche entgegengenommen werden
host=schneesturm.ddns.net ; DynDNS des Partner-Servers im Wohnzimmer
username=outgoing-palmenstrand ; Die Gespräche kommen vom Context
; [outgoing-palmenstrand] der iax.conf
; des Servers im Wohnzimmer
context=phones-in ; Nur die Nummern (extensions) im Kontext [phones-in] unserer
; extensions.conf sind erreichbar
; der nachfolgende Rest bleibt gleich
secret=sonnenschein123 ; immer dasselbe Passwort verwenden
auth=md5
trunk=yes
qualify=yes
requirecalltoken=no
calltokenoptional=yes
authdebug=yes
; nachfolgendes optional
tos=ef
notransfer=yes
iaxcompat=yes
nochecksums=yes
Der Auszug der extensions.conf am Palmenstrand ist dann wieder entsprechend:
Auszug extensions.conf Palmenstrand
[phones-out] ; siehe die Entsprechung in iax.conf "context=phones-out"
; in [outgoing-schneesturm]
exten => _8877X.,1,NoOp(IAX2-Verbindung Palmenstrand ruft Wohnzimmer an mit Vorwahl 8877)
same => n,Dial(IAX2/outgoing-schneesturm/${EXTEN:4})
same => n,Hangup()
; mit der Vorwahl 8877 sind die Nummern im Wohnzimmer erreichbar.
Nach dieser Methode hat mein Asterisk-Server noch einen dritten IAX2-Zugang bekommen, was kein Problem war.
Hier ein Ansatz, wie sich in der extensions.conf mit Hilfe des Dialstatus auswerten lässt, ob ein Server erreichbar ist:
; Auszug der der extensions.conf von Hans
; Nur ein Ansatz zur Auswertung des DIALASTATUS
; wenn der angerufene Server nicht ereichbar, ist CHANUNAVAIL "ja"
exten => _8833X.,1,NoOp(IAX2 - Hans ruft Alfons an mit der Vorwahl 8833)
same => n,Dial(IAX2/outgoing-Alfons/${EXTEN:4})
; https://das-asterisk-buch.de/1.6/applications-gotoif.html
; https://www.voip-info.org/asterisk-variable-dialstatus/
same => n,GotoIf($[${DIALSTATUS} = CHANUNAVAIL]?ja)
same => n,GotoIf($[${DIALSTATUS} = BUSY]?ja)
same => n,GotoIf($[${DIALSTATUS} = NOANSWER]?ja)
same => n,GotoIf($[${DIALSTATUS} = CANCEL]?ja)
same => n,GotoIf($[${DIALSTATUS} = CONGESTION]?ja:nein)
same => n(ja),NoOp( Dial Status: ${DIALSTATUS})
same => n,Playback(/usr/share/asterisk/sounds/eigene/nichterreichbar)
same => n(nein),Hangup()
Warum ausgerechnet „Schneesturm“ und „Palmenstrand“? Beim Entwerfen dieser Seite war es hier in Schweden kalt und es schneite. Gerne wäre ich jetzt an einem Strand in der Südsee unter Palmen. So kam der Vergleich zustande, um sich die Zusammenhänge bildhafter vorstellen zu können.
Warum nicht mit SIP verschiedene Server verbinden? Das ginge im Prinzip auch. Allerdings ist der Aufwand die NAT-Router zu überwinden größer und es müssen mehrere Ports weitergeleitet werden. Ein anderer lästiger Umstand besteht, wenn der andere Server nicht erreichbar sein sollte. Dann erscheinen im Asterisk-CLI jede Sekunde eine neue Zeile, die vom gescheiterten Connect-Versuch berichtet. IAX2 hat sich für die Vernetzung von Asterisk-Servern durchgesetzt.
Wer betreibt auch als Steckenpferd einen Asterisk-Server? Das Hobby Asterisk hat Seltenheitswert, obwohl es ein sehr interessantes Thema behandelt, das die Schaffung persönlicher Kontakte mit dem Interesse für Technik verbindet. Um so begrüßenswerter wäre es, wenn sich möglichst viele kleine Asterisk-Server zu einem zwanglosen dezentralen Netzwerk verbinden würden. Der Erfahrungsaustausch ist dadurch unschätzbar und bietet wesentlich mehr Anregungen und Chancen als es die allermeisten Foren bieten können, da die Kontakte persönlicher Natur sind, geprägt von Freundschaft, Anstand und Respekt. Wer Interesse an der Anbindung seines Asterisk-Servers oder seines Endgerätes hat, möge deshalb mit mir Verbindung aufnehmen ( sm5zbs ätt janson bindestrich soft punkt de Stichwort Asterisk). Anfänger sind selbstverständlich auch willkommen. Telefon verbindet. Mein Name ist Volker.
An dieser Stelle meinen besten Dank an Gerd, Rainer und Adi für ihre unverzichtbaren Hilfestellungen und ebenso unermüdlichen und unverzichtbaren Versuche die IAX2-Verbindungen auf Herz und Nieren vorwärts, rückwärts, hin und her, mehrfach und gleichzeitig zu testen.
|
|
Asterisk-Telefonserver auf einem Raspberry Pi – Installation, Konfiguration, Programmierung, SIP, IAX2, AGI-Skripte, Sicherheit und Tipps zum praktischen Betrieb – 2.11.2022: Diese Seite richtet sich an jene, welche einen Asterisk-Telefon-Server auf einem Raspberry Pi betreiben möchten und später ein kleines Netzwerk aus Asterisk-Servern planen, um ein eigenständiges Telefonnetz aufzubauen. Los geht es mit der Installation von Raspbian und Asterisk auf einem Raspberry Pi und dann nach Lust und Laune immer tiefer in die Programmierung von Asterisk. Die Themen werden laufend erweitert.
Selbstverständlich muss es nicht unbedingt ein Raspberry Pi sein. Andere Linux-Rechner gehen auch. – weiter – |
