HAMVOIP - Versionsgeschichte

IN3FQQ: Implementierung vom "Caller ID Name" dokumentiert und Updates beim Dialplan

2025-12-29T15:22:12Z

Implementierung vom "Caller ID Name" dokumentiert und Updates beim Dialplan

IN3FQQ am 22. August 2025 um 17:20 Uhr

2025-08-22T17:20:27Z

← Nächstältere Version		Version vom 22. August 2025, 17:20 Uhr
Zeile 254:		Zeile 254:
	Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl		Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl

	[[~~index.php?title=~~Kategorie:HAMNET]]		[[Kategorie:HAMNET]]

IN3FQQ: /* Anbindung von SVXLINK */

2025-08-22T17:20:00Z

Anbindung von SVXLINK

← Nächstältere Version		Version vom 22. August 2025, 17:20 Uhr
Zeile 236:		Zeile 236:

	* PJPROJECT		* PJPROJECT
	* Svxlink von Source kompiliert, mit der Option -~~DWITH~~		* Svxlink von Source kompiliert, mit der Option <code>-DWITH_CONTRIB_SIP_LOGIC=ON</code>

	== PJPROJECT und Svxlink Kompilieren ==		== PJPROJECT und Svxlink Kompilieren ==
Zeile 254:		Zeile 254:
	Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl		Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl

	[[Kategorie:HAMNET]]		[[index.php?title=Kategorie:HAMNET]]

IN3FQQ am 22. August 2025 um 14:17 Uhr

2025-08-22T14:17:40Z

← Nächstältere Version		Version vom 22. August 2025, 14:17 Uhr
Zeile 253:		Zeile 253:

	Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl		Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl
	[[~~index.php?title=~~Kategorie:HAMNET]]
			[[Kategorie:HAMNET]]

IN3FQQ: /* Dundi-Map Projekt */

2025-08-22T12:04:19Z

Dundi-Map Projekt

← Nächstältere Version		Version vom 22. August 2025, 12:04 Uhr
Zeile 32:		Zeile 32:
	Hier findet sich die Übersichtsseite im HAMNET:		Hier findet sich die Übersichtsseite im HAMNET:

	~~<nowiki>~~http://db0bt.hamnet.radio:85/~~</nowiki>~~		http://db0bt.hamnet.radio:85/

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

IN3FQQ: /* Dundi-Map Projekt */

2025-08-22T12:03:54Z

Dundi-Map Projekt

← Nächstältere Version		Version vom 22. August 2025, 12:03 Uhr
Zeile 46:		Zeile 46:
	#!/bin/sh		#!/bin/sh
	asterisk -r -x 'dundi show peers' > /var/www/html/dundi_show_peers.info		asterisk -r -x 'dundi show peers' > /var/www/html/dundi_show_peers.info

	~~<code>~# 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</code>~~

	== Technische Hintergründe ==		== Technische Hintergründe ==
Zeile 261:		Zeile 253:

	Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl		Die SipLogic hat auch eine eigene TCL-Logik, und zwar /usr/share/svxlink/events.d/SipLogic.tcl
	[[Kategorie:HAMNET]]		[[index.php?title=Kategorie:HAMNET]]

IN3FQQ am 22. August 2025 um 09:08 Uhr

2025-08-22T09:08:32Z

← Nächstältere Version		Version vom 22. August 2025, 09:08 Uhr
Zeile 261:		Zeile 261:

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

IN3FQQ: /* sip.conf / pjsip.conf */

2025-08-22T08:36:57Z

sip.conf / pjsip.conf

← Nächstältere Version		Version vom 22. August 2025, 08:36 Uhr
Zeile 128:		Zeile 128:
	protocol=udp ;udp,tcp,tls,ws,wss		protocol=udp ;udp,tcp,tls,ws,wss
	bind=0.0.0.0		bind=0.0.0.0

	~~<code>[global]~~
	~~regcontext=dundiextens~~

	~~[transport-udp]~~
	~~type=transport~~
	~~protocol=udp ;udp,tcp,tls,ws,wss~~
	~~bind=0.0.0.0</code>~~
	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 ''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.

IN3FQQ: Die Seite wurde neu angelegt: „ == 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 "Buchstabenwa…“

2025-08-22T08:36:40Z

Die Seite wurde neu angelegt: „ == 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 "Buchstabenwa…“

Neue Seite

== 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:

<nowiki>http://db0bt.hamnet.radio:85/</nowiki>

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

<code>~# 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</code>

== 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:

# Ist die Telefonnummer am lokalen Server registriert, dann kann diese natürlich direkt erreicht werden.
# Falls nicht, werden die DUNDi-Peers befragt, ob irgendjemand diese Nummer kennt.
# Falls ein Server die Nummer kennt, wird mitgeschickt, wie man diesen Server erreichen kann.
# Der eigene Server baut eine Verbindung zum Zielserver auf
# 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

<code>[global]
regcontext=dundiextens

[transport-udp]
type=transport
protocol=udp ;udp,tcp,tls,ws,wss
bind=0.0.0.0</code>
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 <nowiki>http://www.dundi.com</nowiki>
;
;
[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

== PJPROJECT und Svxlink Kompilieren ==
Damit PJPROJECT kompiliert, muss der Configure-Befehl lt. Doku mit der Option <code>-fPIC</code> ausgeführt werden. Auf unseren Relais habe ich mit dem folgenden Configure-Befehl erfolgreich kompiliert:

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

Danach
make dep
make
make install
Danach kann SVXLINK vorbereitet werden. Am besten mit den selben cmake Flags wie immer, aber zusätzlich mit <code>-DWITH_CONTRIB_SIP_LOGIC=ON</code>

== 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