;=========== General settings ===========
[global]
type=global
user_agent=Asterisk PBX
endpoint_identifier_order=ip,username
default_from_user=021156215202
language=de
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
local_net=192.168.10.0/24
[transport-tcp]
type=transport
protocol=tcp
bind=0.0.0.0
local_net=192.168.10.0/24
endpoint_identifier_order
Ein SIP-Request ist für Asterisk einfach ein ankommendes UDP-Datenpaket. Allerdings für die weitere Verarbeitung sollte Asterisk wissen, von welchem Endpoint das Paket kommt. Nachdem bis zu diesem Zeitpunkt alle anderen Geräte noch unbekannt sind, wird hier gefordert, dass zunächst die IP-Adresse untersucht werden soll. Und von dem Provider ist die IP-Adresse auch noch unbekannt. Deshalb soll auch nach dem username gesucht werden.
Defaultmäßig ist anonymous in Asterisk aktiviert. Die anonymen SIP-Requests lassen wir sicherheitshalber nicht zu. Es gilt der Hinweis, dass anonymous sich hier auf die Zuordnung von SIP-Paketen zu den Endpoints bezieht. Mit dem Mitsenden der Anrufernummer hat das gar nichts zu tun.
default_from_user
In dieser Stelle steht wie abgebildet unsere komplette Festnetznummer ohne Leer-/Trennzeichen, die Asterisk als From User in den SIP-Requests mitsendet, sofern keine CallerID zur verfügung gestellt wird.
Normalerweise reicht der UDP-Transport vollkommen aus. Nur macht es Sinn auch den TCP-Transport zur Verfügung zu stellen, um via TCP mit Asterisk kommunizieren zu können.
bind
Hier wird der Netzwerkanschluss konfiguriert, auf dem PJSIP hört. Mit 0.0.0.0 lauscht Asterisk an allen verfügbaren Netzwerkkarten.
local_net
Dieser Parameter identifiziert für PJSIP das lokale Netzwerk. Das wird in NAT-Szenarien relevant, in diesem Fall steht hier das separate Telefonienetzwerk 192.168.10.0/24.
Das wird je einmal für UDP und TCP definiert und sinnvoll mit einem Context wie beispielsweise „transport-udp“ versehen.
Der Asterisk-Server und mit ihm seine Endpoints (Telefone, Fax) will ja auch nach außen über einen Provider senden können. Dazu dienen jetzt die Abschnitte, bei denen jede Rufnummer separat konfiguriert werden muss und sich separat beim Provider registrieren muss. So gibt einen Abschnitt, der die Rufnummer konfiguriert und einen Abschnitt, der die Authentifizierung regelt. Letzterer Abschnitt kann dann auch mehrfach verwendet werden, wie gleich gezeigt.
;=========== Call-ID +49 211 562 152 01 Outbounds ===========
[telekom_021156215201]
type=registration
transport=transport-udp
outbound_auth=telekom_021156215201_auth
server_uri=sip:tel.t-online.de
client_uri=sip:+497117115201@tel.t-online.de
contact_user=021156215201
retry_interval=60
forbidden_retry_interval=300
expiration=480
auth_rejection_permanent=false
[telekom_021156215201_auth]
type=auth
auth_type=userpass
password=telekom_passwort
username=021156215201
realm=tel.t-online.de
Dieser Abschnitt, den es für jede Rufnummer mit eigenen Context [provider_number] und [provider_number_auth]gibt – andere Bezeichnungen sind auch machbar -, erledigt die Registrierung beim Provider, hier die Telekom. Damit weiß der Provider über die Benutzer-Logins (Passwort und Telefonnummer), dass diese Konstellation über ihn telefonieren respektive senden darf.
Wichtig ist in diesem Zusammenhang auch zu wissen, dass diese Registrierung andere PBX-Server nicht daran hindern wird, diesem Asterisk-Server SIP-Requests zu senden und die hier bereitgestellte Telefonie für sich zu nutzen. Daran ändert auch die Firewall nichts, zumal sie ja den Port 5060 geöffnet hat. Zwar existiert hier eine Regel, die das Forwarding nur den Telekom-Servern erlaubt, das ist jedoch keine 100%ige Sicherheit. Das Abblocken fremder Server-Requests erfolgt später an anderer Stelle.
transport=transport-udp
Die Telekom kommuniziert nur per UDP. transport-udp ist der Name des entsprechenden type=transport-Abschnittes, den wir oben definiert haben.
outbound_auth
Dieser Parameter referenziert den Namen eines type=auth-Abschnittes. Der angegebene Name muss mit dem des entsprechenden Abschnitts übereinstimmen.
server_uri=sip:tel.t-online.de
Hiermit wird der Name des SIP-Servers der Telekom oder eines anderen Providers angegeben.
client_uri
Liefert die URI, mit der sich Asterisk bei dem Provider meldet. Hier wird die jeweilige Telefonnummer (mit +49, Vorwahl ohne 0) verwendet.
contact_user
Das ist die eigene User-Identifikation. Idealerweise funktioniert hier ebenfalls die eigene Telefonnummer (mit +49, Vorwahl ohne 0).
retry_interval=60
Sofern ein Timeout von der anzufragenden Seite kommt, dient dieser Parameter erneuten Versuchen im 60 Sekunden-Rythmus.
forbidden_retry_interval=300
Sofern ein "Forbidden" gesendet wird, dann erfolgt ein neuerlicher Versuch wie hier deklariert 5 Minuten später.
expiration=480
Das bedeutet für alle 8 Minuten eine Neuregistrierung. Das Intervall sollte nicht zu kurz sein, ansonsten wird ein "Forbidden" erzwungen. Längere Intervalle sind in Ordnung und verringern gleichzeitig den Datenverkehr. Wenn allerdings die Registrierung verloren geht, dann ist der Anschluß bis zur Neuregistrierung nicht erreichbar. Zu groß sollte das Intervall also auch nicht gehalten werden.
auth_rejection_permanent=false
Sofern die Registrierung abgelehnt wird, dann versucht es Asterisk trotzdem weiter. Das kann durchaus zeitweise vorkommen. Eine Aufgabe macht allerdings keinen Sinn, denn irgendwann sollte die Verbindung wieder stehen.
Um einen dauerhaften REJECT zu vermeiden, lässt sich auch ein via Cronjob gesteuertes Bash-Script schreiben, das den Server neu startet und somit die Registrierung erzwingt.
auth_type=userpass
Das wird bereits von Asterisk als Default gesetzt. Das wird auch beibehalten, um auf die klassische Username/Passwort-Kombination der Telekom zu verweisen.
password
Das ist das klassische Telekom-Passwort, das zu jedem Anschluss gehört.
xxxxxxxx:yyyyyyyyyyyy-zzzz@t-online.de:
xxxxxxxx ist die Ziffernkombination des persönlichen Kennwortes, yyyyyyyyyyyy die Nummer aus den Zugangsdaten (vormals T-Online Nummer) und zzzz die Mitbenutzernummer (typisch 0001). Die eigene Telefonnummer kommt als Benutzername in den folgenden Eintrag „username“.
username
Das ist der Telekom-Benutzername zum Passwort soeben. Hier kommt die eigene Telefonnummer (ohne +49, Vorwahl mit 0) hinein.
Das ist der SIP-Realm zum eigenen Endpoint. Da dieser einen Telekom-Festnetzanschluss repräsentiert, liegt dieser Endpoint im Realm tel.t-online-de.
Wie bereits erwähnt wird dieser Abschnitt für jede Rufnummer notwendig. Insbesondere wenn auf mehreren unterschiedlichen Rufnummern heraus telefoniert werden soll.
Hier folgt die Konfiguration der Abschnitte, die notwendig sind, dass die Endpoints über den asterisk-Server hinaus telefonieren können.
;=========== Call-ID +49 211 562 152 01 Endpoints outgoing===========
[telekom_15201_out]
type=endpoint
transport=transport-udp
context=unspecified
disallow=all
allow=g722
allow=alaw
direct_media=no
outbound_auth=telekom_021156215201_auth
aors=telekom_15201_out
callerid=021156215201
from_user=021156215201
from_domain=tel.t-online.de
timers=no
rtp_symmetric=yes
transport=transport-udp
Die Telekom kommuniziert nur per UDP. transport-udp ist der Name des entsprechenden type=transport-Abschnittes, den wir oben definiert haben.
context
Definiert den Context im Dialplan (extensions.conf), in den auf diesem Endpoint ankommende Gespräche geleitet werden. Hier wird er mit unspecified definiert, der später auch in der extensions.conf entsprechend konfiguriert und dort leer gelassen wird. Damit ist sichergestellt, dass ein irrtümlich (oder in betrügerischer Absicht) hier ankommender Anruf nicht weitervermittelt wird. Somit ist das eine Sicherheitseinstellung.
disallow/allow
Definieren die erlaubten Codecs an. Die Telekom spricht alaw (ISDN) sowie neuerdings g722 (bessere Sprachqualität).
outbound_auth
Referenziert den bei der Registrierung definierten gleichnamigen type=auth-Abschnitt Die Telekom verlangt berechtigterweise für ausgehende Telefonate eine Autorisierung, die hiermit übermittelt wird.
aors=telekom_out
Bezieht sich auf den gleichnamigen AOR, der ein paar Zeilen weiter unten ebenfalls definiert wird. Wie erwähnt registriert sich die Telekom nicht bei dem Asterisk-Server. Mit diesem Eintrag und dem AOR wird Asterisk mitgeteilt, auf welchem Endpoint sich die eigene Festnetznummer befindet.
callerid
Hierdurch wird eine feste CallerID für alle Anrufe gesetzt, die über diesen Endpoint rausgehen. Die Telekom erwartet hier die eigene Festnetznummer (ohne +49, Vorwahl mit 0).
from_user
Der "From User" im SIP-Header muss ebenfalls die eigene Festnetznummer sein, analog zu callerid.
from_domain
Das muss tel.t-online.de sein, oder bei anderen Provider der entsprechende Server.
timers
Die werden sicherheitshalber abgeschaltet.
rtp_symmetric
Aktiviert symmetrischen RTP Datenverkehr. Damit werden die RTP-Sprachdaten auf dem gleichen Port gesendet und empfangen. Nachdem RTP-Daten direkt zwischen den Endpoints versendet werden ohne Asterisk dazwischen, sollte auf den SIP-Telefonen das symmetrisches RTP eingestellt werden.
Dieser Part ist ein sogenannter „Contact“, damit die Telefonnummer von Asterisk als SIP-URI dem jeweiligen Endpoint zuordnen kann.
[telekom_15201_out]
type=aor
contact=sip:021156215201@tel.t-online.de
contact
Das ist die SIP-Form der eigenen Festnetznummer (mit +49, Vorwahl ohne 0 ).
Eingehende Gespräche lassen sich den Endpoints wie folgt zuordnen. Da diese Endpoints, in der Regel SIP-Telefon oder Fax-Server nicht dazu dienen, dass über sie heraustelefoniert werden soll, entfällt in diesem Abschnitt der Address-Of-Record (AOR). Das dient der Sicherheit, wenn über die Endpoints ein Heraustelefonieren nicht möglich ist. Außerdem lassen die ankommenden Gespräche so auch im Dialplan sauber von den Ausgehenden trennen.
;=========== Call-ID +49 211 562 152 01 Endpoints incoming===========
[telekom_15201_in]
type=endpoint
transport=transport-udp
context=telekom_15201_in
disallow=all
allow=g722
allow=alaw
direct_media=no
outbound_auth=telekom_021156215201_auth
[telekom_15201_in]
type=identify
endpoint=telekom_in
match=217.0.0.0/13
context=telekom_in
Das ist der Dialplan-Kontext auf dem ankommende Gespräche weitergeleitet werden sollen. Hier kann durchaus eine andere Bezeichnung gewählt werden, wichtig ist nur, dass im Dialplan der gleiche Context auftritt.
disallow/allow
Damit sind die erlaubten Codes gemeint. Die Telekom verwendet alaw (insbesonder bei dem alten ISDN) mittlerweile g722, das eine bessere Sprachqualität impliziert.
outbound_auth
Dieser Context referenziert den bereits erwänhten Autorisierungsabschnitt. Das könnte durchaus irritierend wirken, denn die Provider senden keine Autorisierungen an unseren Asterisk mit, wenn ein Anruf an den Asterisk eingeht. Wenn überhaupt, dann wäre das jedoch eine inbound-Autorisierung, die allerdings nicht angegeben ist. Die hier genannte outbound-Autorisierung ist notwendig, weil Asterisk beim Vermitteln des ankommenden Gesprächs ("Bridging") Anweisungen zum RTP-Datenverkehr an den Provider sendet.
Ein type=aor-Abschnitt ist hier nicht notwendig. Dafür wird aber ein type=identify-Abschnitt mit dem IP-Adressbereich, der auch bei den Filtern der Firewall angegeben wurde, notwendig. Dieser sorgt dafür, dass Asterisk alle ankommenden SIP-Anfragen aus diesem Addressbereich dem genannten Endpoint zuordnet. Das betrifft alllerdings jeglichen SIP-Datenverkehr aus diesem Adressbereich. Dieser wird aber auf die SIP-Server des Provider eingegrenzt, in diesem Fall auf die der Telekom
endpoint=telekom_in
Das ist eine Referenz auf den bereits deklarierten Endpoint.
match=217.0.0.0/13
Damit wird Asterisk mitgeteilt, dass jedes SIP-Paket aus dem genannten Adressbereich dem entsprechenden Endpoint zugeordnet werden soll. Die IP-Adresse 217.0.0.0/13 repräsentiert die SIP-Server der Telekom, bei anderen Providern steht hier deren IP-Adresse.
Als generelle Syntax für eine Telefon-Definition kann folgendes Template dienen:
[phone]
type=endpoint
transport=transport-udp
context=internalsip
disallow=all
allow=g722
allow=alaw
auth=auth-value
aors=aor-value
;mailboxes=6001@default,7001@default
[auth-value]
type=auth
auth_type=userpass
password=secretpassword
username=ownusername
realm=ownrealm
[ownusername]
type=aor
max_contacts=1
remove_existing=true
[ownusername]
type=identify
endpoint=phone
match=ip-address-phone
Der Abschnitt ACL verbessert die etwas die Sicherheit, in dem hier die erlaubten Netzwerke definiert werden können, die mit dem Asterisk kommunizieren dürfen.
;=========== ACL's ===========
[acl]
type=acl
deny=0.0.0.0/0.0.0.0
permit=217.0.0.0/13
permit=192.168.0.0/16