Virtuelle Telefonanlage in der Cloud - Quickstart
Vor über 20 Jahren revolutionierte asterisk als beliebig konfigurierbarer Werkzeugkasten den Markt für Telekommunikation und bildet seither die Geschäftsgrundlage vieler Firmen vom ersten VoIP-Anbieter sipgate bis zum Heim-Router-Platzhirsch AVM.
So stellen moderne FritzBoxen wie virtuelle Cloud-Telefonieanlagen der VoIP-Anbieter letztlich nur Asterisk-Implementierungen mit eigenem GUI dar.
Da die Gesamtthematik SIP, RTP, IPv4/IPv6, NAT, STUN, Firewall nicht ganz trivial ist, die meisten Anleitungen, aber auch Standardwerke lange veraltete Asterisk-Versionen heranziehen und keine mir bekannte Quelle alle Aspekte umfasst,
sei eine aktuelle Konfiguration für die eigene Cloud-Telefonanlage hier kompakt zusammengefasst. Diese bietet neben beliebig vielen weltweit erreichbaren Anschlüssen und Konferenzräumen unbegrenzter Teilnehmerzahl natürlich auch Sprachnachrichten inkl. Mailversand und die Anbindung an das öffentliche Telefonnetz.
VoIP
Telefonnummern und klassisches Telefonnetz sind überholt. Allerdings bieten erstere durch gesetzliche Regelungen ihrer Vergabe zusammen mit der auch über Internet kostenpflichtigen Gesprächsübertragung einen Schutz vor SPAM, welchen wir
bei Mailadressen und kostenfreier Mailübertragung genau nicht haben. Niemand will sich vorstellen, welche Flut kaum rückverfolgbarer Werbetelefonanrufe uns sonst täglich erreichte. Daher wird uns der Begriff Telefonnummer noch eine längere
Zeit erhalten bleiben, obwohl vermutlich die meisten Telefonate in den Backbones der Carrier über das Internet "gänzlich nummernfrei" übertragen werden.
Ebendort sind gedankliche Endstellen nurmehr Accounts analog Mailadressen, welchen lediglich zur Erreichbarkeit aus herkömmlichen Fest- oder Mobilfunknetzen ein oder mehrere Nummern rein konfigurativ zugeordnet sind, weswegen sich auch
eine Rufnummernportierung auf wenige Konfigurationseinträge des abgebenden wie aufnehmenden Carriers beschränkt. Bei Übergang in und Verlassen des Internet werden Telefonnummern also lediglich auf Konten bei Providern abgebildet und umgekehrt.
Diese haben Mailadressen gleichbedeutend das Format
- <user>@<voipprovider>
- der Domainname kann dabei als IPv4- (bei Fonial etwa ausschließlich) oder IPv6-Adresse (bei z.B. sipgate beide Protokollversionen) aufgelöst werden
und referenzieren somit ein Konto bei einem Internet-Telefonieanbieter, dessen Gateway zum Telefonnetz zwischen Nummern außerhalb und Konten innerhalb vermittelt, wobei einem Konto beliebig viele echte Nummern zugeordnet sein können.
Bei Einrichtung von Internet-Rufnummern in der FritzBox ist das einzugebende Passwort ebenjenes des Telefoniekontos bei Ihrem Internet- oder anderen VoIP-Provider und die FritzBox wird mit dieser Anmeldung zu einer (aber nicht der einzig möglichen)
diesem Konto zugeordneten Telefonanlage, an welche wiederum analoge, ISDN-, DECT- oder VoIP-Telefone angeschlossen und ein oder mehreren über diesen Account übermittelten Nummern zugewiesen werden können. Für VoIP-Telefone wird dazu in der FritzBox
ebenfalls erst ein VoIP-Account angelegt, an welchem sich beliebige Softphones wie echte VoIP-Telefone als Endstellen aus dem Intranet (bei entsprechender Konfiguration auch dem Internet) anmelden können.
Ein Anruf Tante Ernas aus dem echten Telefonnetz an die vermeintliche Telefonnummer des Enkels wird also im letzten Fall routed als
Anruf unter 089 123456 => Gateway des der Nummer zugeordneten Internet-/Telefonieanbieters => Account des Enkels => dort angemeldete FritzBox => VoIP-Account in FritzBox => dort angemeldete VoIP-Telefone im Heimnetz
Dabei ist nur sichergestellt, dass alle einem Account zugeordneten Telefonnummern zu Anrufsignalisierung aller dort angemeldeten Telefone führen, nicht jedoch (selbstverständlich), dass die gewählte Nummer diesen
übermittelt wird. Letzteres hängt davon ab, welches Paket man zu diesem VoIP-Account erworben hat, also z.B. eine zweite Leitung, einen Komfortanschluss). Auch wäre technisch problemlos, sich z.B. mit einem Softphone von unterwegs
bei seinem kombinierten Internet-/Telefonprovider anzumelden; dies wird jedoch von diesen meist und dann rein künstlich auf den Heim-Router und kaskadiert dahinter liegende Telefone des Heimnetzes beschränkt. Daher ist ratsam, Telefonnummern
möglichst unabhängig vom Internetanbieter bei eigenen VoIP-Providern zu buchen, zumal diese bei einem Wechsel praktisch (und technisch wie dargelegt ohnehin) problemlos portiert werden können.
SIP/RTP, IPv4/IPv6, TCP/UDP und NAT
Ein VoIP-Telefonat besteht aus 2 Komponenten
- Steuerinformationen wie Rufaufbau, Anrufsignaliserung, Endesignalisierung und Rufabbbau
- Diese werden entweder über UDP oder TCP auf dem Standardport 5060 zwischen allen beteiligten Stellen im sogannten Session Initialization Protocol == SIP übertragen
- Ist ein Telefon z.B. am VoIP-Konto einer FritzBox und/oder diese am VoIP-Konto eines Internet-/Telefonieanbieters angemeldet, entspricht dies der Anmeldung eines Mail-Clients an einem IMAP-Mail-Server => eingehende Mails/Anrufe werden dem Client
(Mailprogramm bzw. Telefon) signalisiert; umgekehrt kann der Client Mails versenden, bzw. Anrufe initiieren.
- Bei Anmeldung/Registrierung übermitteln das Telefon/der Client die eigene IPv4/IPv6-Adresse in einem Feld des SIP-Headers praktisch als Rückrufadresse an die Account führende Stelle (cf. unten)
- Die Anmeldung des Heimrouters am Account des Anbieters ist netzwerktechnisch problemlos. Ebenso können sich Telefone im Heimnetz sowohl direkt (ohne Umweg über den Heim-Router) an einem solchen Account anmelden als auch erreicht werden; letzteres
jedoch nur, weil die Anmeldung per se für die Firewall eine ausgehende Verbindung darstellt und Anrufe auf dem Rückweg daher als potentielle Antwort derselben durchgelassen werden, sofern nicht vorher ein Timeout wegen Inaktivität greift.
- Sprachübertragung
- Hierfür wird nach Sitzungsaufbau über SIP eine direkte (nicht mehr vermittelte) UDP-Verbindung zwischen beiden Endstellen über Realtime Transport Procotol == RTP geschaffen
- Zum Heim-Router sind Gespräche problemlos möglich, solange dieser eine globale IPv6- oder öffentliche IPv4-Adresse besitzt.
- Telekom und 1und1 ändern mit der täglichen Routerzwangstrennung nicht nur die öffentliche IPv4-Adresse, sondern auch auch die IPv6-Adresse des Routers UND das globale IPv6-Prefix
- Ebenso unproblematisch sind vom Heimrouter an dahinter liegende Telefone (über oben dargelegte Kette zweier VoIP-Accounts) vermittelte Gepräche
- Gleiches gilt für direkt beim Provider angemeldete VoIP-Clients mit globaler IPv6-Adresse
- Unter Linux etwa ist Linphone IPv6-fähig, nicht jedoch Twinkle
- Nicht (ohne weiteres) möglich sind Gespräche von/zu direkt angemeldeten VoIP-Clients mit privater IPv4-Adresse des Heimnetzes
- Hier nämlich übermittelt (cf. oben) das Soft- oder SIP-Phone bei Registrierung lediglich die interne IPv4-Adresse, welche öffentlich natürlich nicht erreichbar ist.
- Als Lösung hierfür kann ein sogenannter STUN-Server (STUN == Session Traversal Utilities for NAT (Network Address Translation)) verwendet werden
- Unter Linux empfiehlt sich dazu schlicht die Installation von stuntman als Service auf demselben Rootserver, mit welchem die eigene Cloud-Telefonanlage unter asterisk betrieben wird
- Genau so kann jedoch auch ein öffentlicher STUN-Server verwendet werden
- Das direkt anzumeldende IPv4-Telefon im Heimnetz kontaktiert dann vor Registrierung den außenliegenden STUN-Server und erfährt von diesem seine öffentliche IPv4-Adresse (und den öffentlichen Port). Beide Informationen schreibt das Telefon
dann anstelle der privaten IPv4-Adresse in den Header der Registrierung am VoIP-Konto des externen Anbieters oder der eben eigenen Telefonanlage im Internet.
Konfiguration der asterisk-Telefonanlage
Mit diesem Wissen können wir nun unsere eigene virtuelle Telefonanlage auf einem beliebigen (Root-)Server im Internet konfigurieren
- Beliebige Zahl an SIP-Konten mit Anrufbeantworter, Mailversand von und Abhören der Sprachnachrichten
- Beliebige Zahl moderierter Konferenzräume mit allenfalls technisch begrenzter Teilnehmerzahl
- Da Konferenzen per se immer nur eingehende Gespräche haben, genügt hierzu ein nur inbound genutzer und daher effektiv kostenloser SIP-Account bei einem VoIP-Provider
- Anbindung an das öffentliche Telefonnetz für aus- und eingehende Gespräche
- Hierfür registriert sich die Cloud-Telefonanlage an einem SIP-Account eines VoIP-Providers. Account und/oder Provider müssen vom vorigen verschieden sein, da VoIP-Provider eben nicht die zu einem Account angerufen Nummer (so diesem
mehrere zugeordnet worden sein sollten) übermitteln, sondern lediglich allen an diesem Account angemeldeten Telefonen einen Anruf (und dessen Ursprung (Nummer oder Konto) auf ebendiesem Account signalisieren
Wichtig
- Die Begriffe Konto, Endpunkt, Anschluss, Kanal und Leitung werden im folgenden synonym verwendet, obwohl dies technisch nicht korrekt ist, da sie in den meisten praktischen Fällen hinreichend dasselbe bedeuten.
- Konfiguriert werden nun einerseits Endpunkte und andererseits Aktionen (sogenannte extensions), welche bei einem Ereignis dieses Endpunktes (etwa ein Anruf) auszuführen sind. Dabei werden sowohl Endpunkte als auch Aktionen sogenannten contexts zugewiesen,
infolgewessen nur Aktionen ausgeführt werden, für welche der Endpunkt (durch Zuweisung desselben Kontextes) auch berechtigt wurde
- Bei Installation von asterisk mit apt-get install asterisk asterisk-mp3 asterisk-prompt-de wird implizit der user asterisk angelegt; alles Notwendige finden wir im Anschluss unter /etc/asterisk.
- asterisk kann als service (unter user asterisk) gestartet/-stoppt oder interaktiv aufgerufen werden mit sudo -U asterisk asterisk -vvvvvc (hier für Debug-Level 5). Genau so kann von einer zweiten Konsole die als
Service laufende Instanz mit rasterisk -vvvvv oder asterisk -rvvvvv überwacht und gesteuert, bzw. debugged werden (hier ebenfalls für Debug-Level 5).
- Cf. hierzu die umfangreiche Befehlsreferenz und Autovervollständigungsfunktion der asterisk-Kommandozeile
Beispiele (jeweils durch <tab> komplettierbar)
- core show applications
- core show functions
- core show application ConfBridge
- core show function CONFBRIDGE
- pjsip show registrations
- core reload
- pjsip reload
- dialplan reload
- Nach Editierung von Konfigurationsdateien sicherstellen, dass diese weiterhin user/group asterisk gehören. Durch den autoload-Mechanismus für Module kann sonst etwa sein, dass das SIP-Modul nicht geladen wird, weil die zugehörige
Konfigurationsdatei nur von root lesbar war.
- astersik.conf
- Hier nur zu bestimmen, ob der asterisk-Prozess mit den Rechten des users und der Gruppe asterisk laufen soll
- runuser=asterisk
- rungroup=asterisk
- modules.conf
- Legt fest, welche Module geladen werden sollen; hier ausreichend ist, alle Module zu landen und chan_sip, den Voränger von chan_pjsip, auszuschließen
- pjsip.conf
- definiert alle Endpunkte (== Anschlüsse == Konten == Leitungen == Kanäle)
- sehr viele Internet-Anleitungen und auch gedruckte Standardwerke beziehen sich auf den Vorgänger sip.conf, welcher jedoch seit vielen Asterix-Generationen als deprecated nicht mehr weiterentwickelt wird.
- Die Definition eines Endpunktes besteht aus mehreren Abschnitten bestimmten Typs, welche einander referenzieren (Zu deren Bedeutung cf. das Asterisk-Wiki) . Aufgrunddessen können die meisten Abschnitte frei benannt werden. Die "hierarchisch obersten" Abschnitte endpoint
und aor jedoch müssen genau so lauten wie die bei SIP-Anfragen registrierter/verbundener Geräte übertragene SIP-ID des zugehörigen Kontos, um den Einsprung zu finden. Dies gilt im Beispiel unten für die Konten user und user_nat.
Alternativ kann der Einspung zum richtigen Endpunkt (und weiteren darüber referenzierten Abschnitten) durch einen identify-Abschnitt erreicht werden, welcher den Domain-Namen oder die IP-Adresse des Absenders festlegt. Im Beispiel
unten verweist der identify-Abschnitt für das Absender-Muster voipprovider.de auf den Abschnitt voipprovider als Einsprungpunkt. Zusätzlich gibt es mindestens einen unabhängigen Abschnitt, welcher
die Protokolle UDP, TCP, IPv4 oder IPv6 nebst zugehörigen Netzwerk-Interfaces festlegen und wiederum von den Endpunkt-Definitionen verwendet werden. Damit ergeben sich
- [ipv4] und [ipv6]
- Abschnitte mit frei gewählten Namen, welche die verschiedenen Netzwerkschnittstellen und Protokoll(versionen) für die Verwendung durch untere Abschnitte definieren
- [user|user_nat] jeweils mit den Abschnitten/Typen endpoint, aor, auth
- Interne Konten im Kontext intern_privileged für Anmeldungen über IPv6 oder IPv4/NAT. Der Einsprung in die Abschnitte endpoint und aor funktioniert, da die Abschnitte jeweils so lauten wie
die mit SIP-Anfragen angemeldeter Geräte übertragene SIP-ID (== Kontobezeichnung)
- [voipprovider] mit den zusätzlichen Abschnitten registration und identify
- Anbindung an das öffentliche Telefonnetz über einen VoIP-Anbieter. Alternativ zu einem identify-Abschnitt, welcher SIP-Anfragen anhand der Absender-IP zuordnet, könnten alle Abschnitte analog oben auch so
benannt werden wie die ebenfalls übermittelte SIP-ID bei diesem Provider.
- rtp.conf
- legt fest, ob und welcher STUN-Server ggf. verwendet werden soll (sofern asterik selbst hinter einer NAT-Firewall liegt)
- voicemail.conf
- hier werden die Sprachnachrichten-Konten festgelegt; dazu sind (hier in der letzten Zeile) je Mailbox nur eine PIN, optional ein Klarname und eine Mailadresse anzugeben. Die Mailbox des Beispieles hat den Kontext intern
- confbridge.conf
- hier können Konferenzräume, deren Nutzer und Menüfolgen konfiguriert werden. Wir nutzen diese Datei jedoch nicht, sondern programmieren unseren Konferenzraum selbst
- Der Code hierfür wurde nach Asterisk, The Defnitive Guide 5th Edition modifiziert
- extensions.conf
- Legt den sogenannten Dialplan, also die Reaktionsfolge auf sämtliche Ereignisse fest und ist daher neben pjsip.conf das Kernstück der Konfiguration
- Für jeden context eines Endpunktes (cf. oben) werden hier mögliche, d.h. für diesen Kontext erlaubte Ereignisse und Folgeverzweigungen analog Callback-Funktionen eines GUI konfiguriert. (Für Details zur
Syntax cf. das Asterisk-Wiki oder "Asterisk - The Definitive Guide 5th Edition")
- So definieren die Abschnitte des Beispieles
- Kontext intern
- Anruf unter 1001 => Signalisierung an alle unter Account user (weltweit) angemeldeten Geräte (z.B. Softphone im Heimnetz oder mobil) und nach 10 Sekunden Beantwortung des Anrufes durch die interne Voicebox.
- Anruf unter 1102 => Abhören derjenigen Voicebox, welche dem Account des Anrufers zugeordnet ist.
- Anruf unter dem Account bei VoIP-Provider_1 (d.h. bei der dort unter diesem Account geführten Telefonnummer) => Anrufsignalisierung bei (weltweit) allen unter user und user_nat angemeldeten Geräten mit Anrufbeantworter nach 10 Sekunden
- Anruf unter 1200 oder dem Account bei VoIP-Provider_2 => Konferenzteilnahme als Nicht-Admin (Wechsel zu Kontext conference)
- Anruf unter 1201 => Konferenzteilnahme als Admin (Wechsel zu Kontext conference)
- Kontext intern_privileged
- Dieser Kontext erbt alle Regeln des Kontextes intern
- Bei Wahl einer beliebigen Nummer mit Vorwahl 0 (von einem Endpunkt im selben Kontext (cf. pjsip.conf) Anwahl über den Account bei VoIP-Provider_1
Zwar kann asterisk alternativ auch über Datenbanktabellen konfiguriert werden, aber wir verfolgen wie immer den minimalistischen Ansatz (welcher uns
auch nicht auf Free-PBX verweisen lässt, da wir ja nicht mit der Maus programmieren ;-)) über die klassische Konfigurationsdatei. Die Art, bzw. Präferenz der Konfiguration kann über sorcery.conf geändert werden.
Abschließend empfiehlt sich, die Firewall des Root-Servers z.B. über ufw == uncomplicated firewall für IPv4 und IPv6 so zu konfigurieren, dass Anfragen auf UDP-Port 3478 des STUN-Servers von überall, solche auf UDP-SIP-Port 5060 jedoch nur von bestimmten Adressen zugelassen werden.
Impressum und Datenschutzerklärung