HAMVOIP

Allgemeine Infos

Im HAMNET existiert ein VOIP-Verbund auf Basis von Asterisk (teils "bare-bone" Asterisk, teils FreePBX).

Die Telefonieserver heißen in der HAMNETDB meist sip.standort und haben auch meist die Beschreibung asterisk_dundi im Kommentarfeld.

Da sich diese Server im Verbund befinden, ist es möglich, auch Rufnummern auf anderen Servern anzuwählen.

Rufnummernschema

Das Rufnummernschema leitet sich durch "Buchstabenwahl" direkt vom Rufzeichen ab:

• Erste Zahl: auf welcher Taste befindet sich der Buchstabe?
• zweite Zahl: der wievielte Buchstabe auf der Taste?
  • für die Ziffer selbst ist die zweite Zahl die 0

Beispiel: IN3FQQ wird zu:

• I => 4 3 (dritter Buchstabe auf der Taste 4)
• N => 6 2
• 3 => 3 0 (die Ziffer selbst auf der Taste 3)
• F => 3 3
• Q => 7 2
• Q => 7 2

Die gesamte Nummer für IN3FQQ lautet also: 43 62 30 33 72 72

Sofern das verwendete Telefon eine Tastatur mit Buchstaben hat, ist die "Übersetzung" des Rufzeichens recht intuitiv.

Dundi-Map Projekt

Es gibt ein Projekt, welches versucht, den DUNDi-Verbund im HAMNET mit seinen Peerings auf einer Karte darzustellen.

Hier findet sich die Übersichtsseite im HAMNET:

http://db0bt.hamnet.radio:85/

Um mit einem eigenen Asterisk-Server am Projekt teilzunehmen, muss:

• In der HamnetDB im Kommentar des SIP-Servers asterisk_dundi stehen
• Auf dem SIP-Server muss ein Webserver laufen, der die beiden Files /dundi.info und /dundi_show_peers.info bereitstellt. Das erste File ist statisch, letzteres wird durch einen Cronjob stündlich aktualisiert:

~# cat /var/www/html/dundi.info 
#Rufzeichen;IP des Asterisk-Servers;MAC des Asterisk-Servers;Names des Betreibers;Rufzeichen des Betreibers;Email des Betreibers
IR3UHF;44.169.1.29;ee:19:2c:04:d9:fe;Simon;IN3FQQ;tech@drc.bz

~# cat /etc/cron.hourly/dundistatus
#!/bin/sh
asterisk -r -x 'dundi show peers' > /var/www/html/dundi_show_peers.info

Technische Hintergründe

Funktionsweise

Als Basis verwenden die Server jeweils die Software asterisk. Manche verwenden die Distribution FreePBX, welche mit einer Weboberfläche und einer ganzen Reihe an Erweiterungen kommt.

Auch das "HamServerPI"-Image, das in DL recht verbreitet ist, hat unter anderem Asterisk mit eingebaut. Auch dieses verwendet FreePBX, welcher standardmäßig auf Port 81 mit einer Weboberfläche antwortet.

Unser Server sip.ir3uhf auf dem Rittnerhorn hingegen ist eher minimalistisch aufgebaut: es läuft ein asterisk "standalone" auf einem Debian LXC Container.

Verteiltes Telefonverzeichnis

Für die internationale Vernetzung via HAMNET hat sich das Modul "DUNDi" etabliert. DUNDi steht für Distributed Universal Number Discovery und ist vereinfacht gesagt eine Implementierung eines verteilten/Peer-to-Peer basierten Telefonbuchs.

Der Ablauf eines Verbindungsaufbaus läuft vereinfacht dargestellt folgendermaßen ab:

1. Ist die Telefonnummer am lokalen Server registriert, dann kann diese natürlich direkt erreicht werden.
2. Falls nicht, werden die DUNDi-Peers befragt, ob irgendjemand diese Nummer kennt.
3. Falls ein Server die Nummer kennt, wird mitgeschickt, wie man diesen Server erreichen kann.
4. Der eigene Server baut eine Verbindung zum Zielserver auf
5. Das Telefon des gewählten Verbindungspartners klingelt.

Zuerst einmal das einfachere Negativbeispiel anhand einer fiktiven Nummer 12345 welche nicht existiert:

In diesem Fall sieht die Antwort folgendermaßen aus:

vdrcsip01*CLI> dundi lookup 12345@priv
DUNDi lookup returned no results.
DUNDi lookup completed in 532 ms

Sollte diese Nummer also auch auf dem lokalen Server nicht bekannt sein, ist in diesem Fall nichts mehr zu machen. Die Verbindung kann nicht aufgebaut werden und das Telefon signalisiert dies dem Benutzer.

Im folgenden Beispiel wird nun nach der Nummer des DL-Rundspruchs 3122007431213153 gesucht.

Diese ist existent und es sollte folglich ein Server im Verbund gefunden werden, der diese Nummer kennt:

vdrcsip01*CLI> dundi lookup 3122007431213153@priv
  1.     0 IAX2/iaxuser:##secret##@44.149.166.36/3122007431213153 (EXISTS)
     from 62:ec:e3:5a:57:7f, expires in 50 s
DUNDi lookup completed in 1668 ms

In diesem Fall konnte der Server ermittelt werden, welcher diese Nummer aktuell aufliegen hat. Konkret handelt es sich im Beispiel um den Server 44.149.166.36 (sip.db0sda) bei DB0SDA in Aachen.

Dabei ist hervorzuheben, dass es nicht zwingend notwendig ist, zu diesem Server ein direktes DUNDi-Peering zu haben.

Jeder Peer kann nämlich von sich aus bei einem seiner eigenen Peers weiterfragen, falls er die Information nicht selbst kennt.

Das DUNDi-Netzwerk muss somit also nicht zwingend ein Full-Mesh sein. Es reicht jemanden zu kennen, der einen kennt, der die Nummer aufliegen hat. Die Rekursionstiefe kann dabei in der Konfigurationsdatei angegeben werden.

Außerdem müssen keine IAX-Trunks oder ähnliches statisch konfiguriert werden.

Wie man aus der Antwort des DUNDi-Lookups erkennen kann, wird beim Auffinden einer Telefonnummer die Information mitgeliefert, wie man diese Nummer erreichen kann. Diese besteht aus den folgenden Teilen:

• Technologie/Protokoll, in diesem fall IAX2
• Benutzername und temporäres Passwort für die Verbindung
• IP Adresse des Zielservers
• die Anschlussnummer
• die ID des DUNDi-Peers, von dem die Information empfangen wurde

Im HAMNET VOIP Verbund wird die Verbindung zum Zielserver in den meisten Fällen über das IAX2-Protokoll realisiert.

Die entsprechenden Zugangsdaten für die Verbindung werden in der DUNDi-Antwort mitgeliefert, wobei das Passwort mehrmals täglich rotiert.

In vielen HAMNET VOIP Beispielen wird in der dundi.conf ein secret angegeben. Dieses ist vermutlich ein Relikt aus vergangenen Zeiten.

In der DUNDi-Dokumentation ist diese Konfigurationsvariable nicht mehr dokumentiert und effektiv funktionieren die Peerings im HAMNET auch ohne ein Secret anzugeben

Konfiguration

Im Folgenden wird eine funktionierende Basiskonfiguration geschildert, so wie sie auch bei sip.ir3uhf verwendet wird.

sip.conf / pjsip.conf

[global]
regcontext=dundiextens

[transport-udp]
type=transport
protocol=udp    ;udp,tcp,tls,ws,wss
bind=0.0.0.0

Die regcontext Option legt fuer jeden angemeldeten Benutzer dynamisch einen Eintrag im angegebenen Dialplan-Kontext dundiextens an und entfernt ihn wieder, sobald sich ein Benutzer/Telefon abmeldet.

Die hier eingetragenen Nummern sind jene, die spaeter von DUNDi announced werden.

Die Benutzeraccounts selbst werden in unserem Fall über die Konfigurationsdatei pjsip_wizard.conf anhand der Wizard-Funktion von PJSIP angelegt.

Alternativ kann das auch anhand einer Datenbank gemacht werden, welche man dann ggf. auch auf weitere Standorte replizieren kann, um den Benutzern auf weiteren Servern in der Region einen Login mit denselben Zugangsdaten zu erlauben.

dundi.conf

;
; DUNDi configuration file
;
; For more information about DUNDi, see http://www.dundi.com
;
;
[general]
department=DRC
organization=Dolomites Radio Club
locality=Bozen
country=IT
email=drc@drc.bz
ttl=2
cachetime=50
autokill=yes
; eigene ID, normalerweise die eigene MAC Adresse.
; diese geben wir explizit an, damit nach etwaigem Serverumzug die ID gleichbleibt
entityid=ab:cd:ef:ab:cd:ef  

[mappings]

priv => dundiextens,0,IAX2,iaxuser:${SECRET}@44.169.1.29/${NUMBER},nopartial


;; konfiguration eines DUNDi-Peers
[aa:bb:cc:dd:ee:ff]
; ip adresse oder hostname des Peers
host=sip.standort.hamnet.radio
include=priv
model=symmetric
order=primary
permit=priv
qualify=yes

In der dundi.conf werden nun die eigenen Details (department, organization etc. sind im Grunde nicht notwendig) konfiguriert.

Wichtig sind die Optionen ttl, cachetime sowie autokill und entityid.

Die entityid wird - sofern nicht explizit angegeben - von der eigenen MAC-Adresse abgeleitet. Da diese aber bei allen Peers angegeben werden muss, empfiehlt es sich die ID explizit in der Konfigurationsdatei anzugeben, damit diese im Falle eines Server-Umzugs beibehalten werden kann.

Die option ttl beschreibt, wieviele Hops der DUNDi-Lookup "weitergereicht" werden darf. Der wert 2 bedeutet also, dass alle angeschlossenen DUNDi-Peers auch noch ihre eigenen Peers befragen dürfen. Danach wird nicht mehr weitergefragt.

Die cachetime gibt an, für wieviele Sekunden eine empfangene Antwort zwischengespeichert werden soll. Sofern nicht angegeben ist der Standardwert 3600 Sekunden (1 Stunde), was für den Einsatzzweck im HAMNET natürlich nicht sinnvoll wäre.

In unserem Fall setzen wir die cachetime auf einen wesentlich kürzeren Wert.

autokill definiert, dass Anfragen an nicht antwortende Peers nach standardmäßig 2sec abgebrochen und der Peer als offline markiert wird.

Der wichtigste Teil der Konfiguration befindet sich jedoch im Bereich [mappings].

Hier wird definiert, welche Nummern vom eigenen Server in den DUNDi-Verbund announced werden.

Die Konfigurationszeile ordnet dem DUNDi-Kontext priv den internen Kontext dundiextens zu. Dieser enthält (siehe vorhergehende pjsip.conf Konfiguration) die Telefonnummern aller aktuell am eigenen Server angemeldeten Benutzer/Telefone.

Die darauffolgende Zahl 0 gibt an, dass die Nummern direkt an diesem Server aufliegen.

Abschließend wird der Verbindungsstring angegeben, welcher den anfragenden DUNDi-Peers in der Antwort zurückgeschickt wird.

Die Option nopartial beschreibt, dass der Server nur für exakt übereinstimmende Nummern und nicht für partielle übereinstimmungen antworten soll.

iax.conf

Nach dem Auffinden des Zielservers über ein DUNDi-Lookup kann eine Verbindung zu diesem hergestellt werden.

Dafür wird das IAX2-Protokoll verwendet.

Die Datei iax.conf definiert die Einzelheiten des Protokolls. Besonders wichtig dabei ist das Anlegen des Benutzers iaxuser für die einkommenden Verbindungen aus dem Verbund.

Für die Wahl des Passwortes wird dbsecret=dundi/secret angegeben. Damit wird ein temporäres Passwort referenziert, welches von DUNDi automatisch generiert und mehrfach täglich rotiert wird.

Die eingehenden Verbindungen werden in den Dialplan-Kontext incomingdundi geleitet.

Im Abschnitt [general] sind die erlaubten Codecs definiert, welche für eingehende und ausgehende Verbindungen von/in den Verbund verwendet werden dürfen.

[general]
nochecksums=no
bandwidth=low
disallow=all
allow=g722
;allow=ulaw
allow=alaw
allow=gsm                      
;jitterbuffer=no
jitterbuffer=yes

[iaxuser]
type=friend
dbsecret=dundi/secret
context=incomingdundi 

extensions.conf

[lookupdundi]
switch => DUNDi/priv

[internal]
include => dundiextens

exten => _Z.,1,Dial(PJSIP/${EXTEN})
same => n,Goto(lookupdundi,${EXTEN},1)
same => n,Hangup()

[incomingdundi]
exten => _Z.,1,Goto(internal,${EXTEN},1)

Anbindung von SVXLINK

Svxlink kann durch die Erweiterung SipLogic an einen VOIP-Server angebunden werden.

Dazu braucht es:

• PJPROJECT
• Svxlink von Source kompiliert, mit der Option -DWITH_CONTRIB_SIP_LOGIC=ON

PJPROJECT und Svxlink Kompilieren

Damit PJPROJECT kompiliert, muss der Configure-Befehl lt. Doku mit der Option -fPIC ausgeführt werden. Auf unseren Relais habe ich mit dem folgenden Configure-Befehl erfolgreich kompiliert:

./configure --disable-libwebrtc --disable-video CPPFLAGS=-fPIC CXXFLAGS=-fPIC CFLAGS=-fPIC

Danach

make dep
make
make install

Danach kann SVXLINK vorbereitet werden. Am besten mit den selben cmake Flags wie immer, aber zusätzlich mit -DWITH_CONTRIB_SIP_LOGIC=ON

SVXLINK Konfiguration

Sämtliche Konfigurationen der SIP-Logic befinden sich in /etc/svxlink/svxlink.d/SipLogic.conf.

Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl