Kleine und große Linux AHAs
Asterisk
Asterisk Projekt: Season 12 – Snoms Registriert Euch!!! Jetzt!!!
03. Mai
Folgendes Szenario: Der Asterisk Prozess schmiert aus irgendeinem Grund ab. Der Dienst wird wieder hochgefahren und die Telefone sind nicht mehr registriert. Was nun? Klar, nach einer gewissen Zeit erneuern die Geräte ihre Registrierung und sind wieder erreichbar. Aber bis dahin? Und wie lange dauert das?
Kurz und dreckig – ich will dass sie das jetzt tun!
Ok, wir sprechen hier über Snom Telefone. Diese können per Remote bedient werden und das machen wir uns zu Nutze. Wir simulieren einfach den Klick auf “Re-Registrieren” der Weboberfläche. Dazu nutzen wir wget.
Aber
Normalerweise nutze ich um die Telefone anzusprechen die IP aus der Datenbank. Leider ist in dem Fall in der Datenbank auch kein IP Eintrag – Telefon ja nicht registriert 
Also was anderes. Mir kam die Idee das ganze über den ARP Cache zu machen. OMG! Warum das denn?
Naja eigentlich ganz einfach. Anhand der MAC kann man Snom Geräte bestimmen. Damit ich dann wirklich nur Snom Geräte mit dem Befehl anspreche muss ich lediglich alle MAC Adressen nehmen die mit 00:04:13 beginnen. Damit hab ich alle IPs die ich ansprechen muss.
Das Script dazu
#!/bin/bash
#
# Scan ARP Cache for Snom Devices and send a re-register to them
#
SNOM_USER="webloginUser"
SNOM_PASSWORD="webloginpw"
for IP in `grep "00:04:13" /proc/net/arp | cut -f1 -d " "`</p>
do
wget --no-proxy --post-data="REREGISTER:1=Re-Registrieren" http://${SNOM_USER}:${SNOM_PASSWORD}@${IP}/line_login.html >/dev/null 2>&1;
print "Did ${IP}";
}
Nachdem das Script gelaufen ist sollten sich wieder alle Telefone am Asterisk Server angemeldet haben.
(No Ratings Yet)
Loading ... Asterisk Projekt: Season 11 – Asterisk <-> MySQL UTF8
30. Apr
Um unseren Asterisk möglichst flexibel zu halten wurde Asterisk mit MySQL Schnittstelle installiert. Das bringt uns in die Lage recht einfach Konfigurationsänderungen vorzunehmen – nämlich in der Datenbank und damit ohne Neustart des Dienstes. Nun leben wir in Deutschland und in Deutschland gibt es Umlaute. Umlaute sind immer so eine Sache in Datenbanken, Programmen, Scripten etc..
Auch unser Asterisk kann per Default nichts mit Umlauten anfangen – wenigstens nicht aus der Datenbank so wie wir sie aufgesetzt haben. Server als auch Client (MySQL & Asterisk) müssen auf einen passenden Zeichensatz gebracht werden um ohne Verluste miteinander sprechen zu können – es empfiehlt sich UTF8.
Woran sieht man ob es überhaupt Probleme gibt? Naja, man lege eine Nebenstelle an. Die CallerID (Name) lautet “Max Müller”. Was kommt beim Angerufenen an? Ich schätze Sonderzeichen stehen im Display anstatt “Max Müller”. Das ganze ebenfalls bei der Queue – wenn man diese aus der Datenbank bedient. Schaut man sich dann die Mitglieder der Queue an und hat ein Mitglied mit Sonderzeichen im Namen, so ist das weniger hübsch 
Wie wird das ganze korrigiert?
Hat man nun einen Asterisk mit MySQL Anbindung in Betrieb, so kann man wie folgt vorgehen:
- Anpassen der MySQL Konfiguation
- Dump der Datenbank(en)
- Restart von MySQL
- Anpassen des Dumps
- einspielen des Dumps in die DB (ersetzen der alten DB)
- Neustart von Asterisk
en Detail
Anpassen der MySQL Konfiguration (/etc/mysql/my.cnf oder /etc/my.cnf):
im Bereich [Client] folgendes hinzufügen:
default-character-set=utf8
im Bereich [mysqld] dieses:
default-character-set=utf8 default-collation=utf8_general_ci character-set-server=utf8 collation-server=utf8_general_ci
mysqldump
mysqldump -uroot -pasterisk -c -e --default-character-set=utf8 --single-transaction --skip-set-charset --add-drop-database -B asterisk_db > /tmp/asterisk_db.sql cp /tmp/asterisk_db.sql /tmp/asterisk_db_utf8.sq
Anpassen des Dumps
sed -i 's/DEFAULT CHARACTER SET latin1/DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci/' /tmp/asterisk_db_utf8.sql sed -i 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/' /tmp/asterisk_db_utf8.sql sed -i 's/CHARACTER SET latin1/CHARACTER SET utf8/' /tmp/asterisk_db_utf8.sql
Durch diese sed Befehle werden alle latin1 Character Sets durch UTF8 ersetzt. Dadurch wird beim Import für MySQL die Datenbank und alle Tabellen/Spalten auf UTF8 gesetzt.
Als Script sieht das ganze dann so aus:
#!/bin/bash # Dump the DB mysqldump -uroot -pasterisk -c -e --default-character-set=utf8 --single-transaction --skip-set-charset --add-drop-database -B asterisk_db > /tmp/asterisk_db.sql /etc/init.d/mysql restart # make copy cp /tmp/asterisk_db.sql /tmp/asterisk_db_utf8.sql # update table and column definitions sed -i 's/DEFAULT CHARACTER SET latin1/DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci/' /tmp/asterisk_db_utf8.sql sed -i 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/' /tmp/asterisk_db_utf8.sql sed -i 's/CHARACTER SET latin1/CHARACTER SET utf8/' /tmp/asterisk_db_utf8.sql mysql -uroot -pasterisk < /tmp/asterisk_db_utf8.sql sleep 1 /etc/init.d/asterisk restart
Wann durchführen?
Da das Script quasi alles macht und die Datenbank im Normalfall nicht so wahnsinnig groß ist, kann man das “Zwischendurch” machen. Je nach Umgebung sollte natürlich eine Zeit gewählt werden, in der wenig bis gar nichts los ist. Das Script braucht nur wenige Sekunden. Bisschen Mut gehört dazu 
Wichtig zu wissen ist, dass sich die Telefone neu registrieren müssen bevor sie wieder Gespräche annehmen können.
(No Ratings Yet) Loading ... Asterisk Projekt: Season 10 – Hardwarekonfig Patton 4960 E1 (PMX) Gateway
23. Apr
Der nächste Hardware “Baustein” ist ein E1 (Primär Multiplex) Gateway. Wie in Season 3 bereits beschrieben werden die Geräte von Patton eingesetzt.
Konfiguration
Die Konfiguration für die 4960 ist vom handling her analog zur 4118. Von daher ist die Beschreibung der 4118 ein guter Anfang. Die 4960 ist relativ fett was die Funktionen angeht. Benötigt man lediglich ein Gateway für die Verbindung zwischen Asterisk und E1/PMX Anschluss, so genügt auch die 4940 die um einiges günstiger ist. Bei uns hätte die auch genügt Von der Konfiguration her wird das aber keinen allzu großen Unterschied machen. Es werden wohl – verglichen zu meinem Beispiel – einfach ein paar Teile wegfallen.
Konfigbeispiel
Ich versuche das ganze durch Kommentare möglichst verständlich zu machen
#----------------------------------------------------------------# # # # SN4960/1E30V # # R5.8 2011-07-01 H323 RBS SIP # # 2012-04-22T09:29:44 # # SN/00A0BA070FC4 # # Generated configuration file # # # #----------------------------------------------------------------# # Die ersten Teile sind analog zur 4118 cli version 3.20 administrator admin password NR7Hh4jseumPf7xjTSemHQ== encrypted clock local default-offset +02:00 dns-relay webserver port 80 language en snmp community nagios ro snmp community configsave rw snmp host 10.10.210.36 security-name monitoring snmp host 10.10.210.36 security-name configsave sntp-client sntp-client server primary 10.10.210.201 port 123 version 4 system hostname pat01 system location Schrank1 system contact netzwerkmanagement@meinefirma.de system ic voice 0 system # clock source ist extrem wichtig. Gerade fur den Faxempfang clock-source 1 e1t1 0 0 profile r2 default profile napt NAPT_WAN profile ppp default profile tone-set default profile voip default # preferierte Codecs codec 1 g711alaw64k rx-length 30 tx-length 30 codec 2 g711ulaw64k rx-length 30 tx-length 30 codec 3 g729 rx-length 30 tx-length 30 rtp traffic-class local-default dejitter-mode static dejitter-max-delay 120 # Fax per T.38 fax transmission 1 relay t38-udp # Modemkonfiguration, bspw. fuer Datentransfer etc. modem transmission 1 bypass g711alaw64k rx-length 10 tx-length 10 modem dejitter-max-delay 60 no modem detection on-remote-fax-request profile pstn default profile sip default no autonomous-transitioning profile dhcp-server DHCPS_LAN # die 4960 hat einen internen DHCP Server # diesen nutzen wir allerdings nicht # alternativ kann man auch eine Patton 4940 # nehmen, die hat weniger funktionen - wenn # es rein um ein E1 Gateway geht. network 192.168.1.0 255.255.255.0 include 1 192.168.1.10 192.168.1.99 lease 2 hours default-router 1 192.168.1.1 profile aaa default method 1 local method 2 none context ip router interface WAN ipaddress dhcp use profile napt NAPT_WAN tcp adjust-mss rx mtu tcp adjust-mss tx mtu interface LAN # die IP des LAN Interfaces ipaddress 10.31.2.13 255.255.255.0 tcp adjust-mss rx mtu tcp adjust-mss tx mtu context ip router # Default gateway route 0.0.0.0 0.0.0.0 10.31.2.201 0 context cs switch # analog zum 4118 die Routing Tables # RT_ISDN_IN routing-table called-e164 RT_ISDN_IN # Default Destination auf RT_LOCAL. Damit die Nummer # intern zurueckgerufen werden kann, wird 00 vor die # von der Telekom empfangene Nummer gesetzt. # eine 0 fuers Amt und eine, da die Nummer ohne fuehrende # 0 uebertragen wird. route default dest-table RT_LOCAL MAP_ADD_PREFIX_00 # route 0(.%) dest-interface IF_SIP_VOIPSERVER MAP_ADD_PREFIX_00 # die 501 ist die Nummer des Anschlusses und wird per # MAP_REMOVE_PREFIX_401 entfernt, damit nur die Nummer # der Nebenstelle als Ziel uebrig bleibt route 501(.%) dest-table RT_ISDN_IN MAP_REMOVE_PREFIX_501 # das ist ein Spezialfall. Frueher wurde die 30 als Zentrale # angerufen. Nun muss die 300 angerufen werden. # Mit dieser Regel wird die 30 in 300 umgeschrieben route 30$ dest-table RT_LOCAL CF_MAP30TO300 # Table RT_LOCAL routing-table called-e164 RT_LOCAL # Default zum Voipserver route default dest-interface IF_SIP_VOIPSERVER # 3 Stellen zum Voipserver route ... dest-interface IF_SIP_VOIPSERVER # Faxanschluesse zu der jeweiligen Patton route 338 dest-interface IF_SIP_PAT03 route 341 dest-interface IF_SIP_PAT03 route 344 dest-interface IF_SIP_PAT03 route 345 dest-interface IF_SIP_PAT03 route 346 dest-interface IF_SIP_PAT03 route 350 dest-interface IF_SIP_PAT03 route 310 dest-interface IF_SIP_PAT02 route 318 dest-interface IF_SIP_PAT02 route 323 dest-interface IF_SIP_PAT02 route 9366 dest-interface IF_SIP_PAT02 route 332 dest-interface IF_SIP_PAT02 route 333 dest-interface IF_SIP_PAT02 route 334 dest-interface IF_SIP_PAT02 route 335 dest-interface IF_SIP_PAT02 # Table RT_SIP_IN, Anrufe von dem Voipserver initiiert routing-table called-e164 RT_SIP_IN # Default nach RT_LOCAL route default dest-table RT_LOCAL # Zielnummer beginnt mit 0? Dann nach extern, aber zuerst noch # die Sendernummer anpassen (CF_CLIP_NO_SCREENING_501) route 0(.%) dest-interface IF_ISDN_0_0 CF_CLIP_NO_SCREENING_501 mapping-table calling-type-of-number to calling-type-of-number MAP_TON_TO_NATIONAL map default to national # Mapping um zwei Nullen voran zu stellen mapping-table calling-e164 to calling-e164 MAP_ADD_PREFIX_00 map (.%) to 00\1 # Mapping um eine Null am Anfang zu entfernen (die Amtsnull) mapping-table called-e164 to called-e164 MAP_REMOVE_PREFIX_0 map 0(.%) to \1 # Mapping um die Anschlussnummer zu entfernen (Nebenstelle bleibt uebrig) mapping-table called-e164 to called-e164 MAP_REMOVE_PREFIX_501 map 501(.%) to \1 # Mapping um die Anschlussnummer voran zu stellen mapping-table calling-e164 to calling-e164 MAP_ADD_PREFIX_1234501 # Alle Nebenstellen die mit einer 3 beginnen bekommen diese Anschlussnummer # vorangesetzt map (3..)$ to 1234501\1 # Mapping um aus der 30 die 300 zu machen (s.o.) mapping-table called-e164 to called-e164 MAP_30_TO_300 map 30 to 300 # Complex Functions (mehrere Mappings zusammengefasst) # Diese werden oben aufgerufen innerhalb der Tables complex-function CF_CLIP_NO_SCREENING_501 execute 1 MAP_ADD_PREFIX_1234501 execute 2 MAP_TON_TO_NATIONAL execute 3 MAP_REMOVE_PREFIX_0 complex-function CF_MAP30TO300 execute 1 MAP_30_TO_300 execute 2 MAP_ADD_PREFIX_00 # Das Interface IF_ISDN_0_0 interface isdn IF_ISDN_0_0 # Destination Table route call dest-table RT_ISDN_IN # Definition der Patton Gateways (meist Fax) # auf diese wird oben in der RT_LOCAL geroutet interface sip IF_SIP_PAT02 bind context sip-gateway GW_SIP route call dest-table RT_SIP_IN remote 10.31.2.14 interface sip IF_SIP_PAT03 bind context sip-gateway GW_SIP route call dest-table RT_SIP_IN remote 10.31.2.15 # Der Voipserver interface sip IF_SIP_VOIPSERVER bind context sip-gateway GW_SIP route call dest-table RT_SIP_IN remote 10.31.2.10 context cs switch no shutdown context sip-gateway GW_SIP interface GW_IF bind interface LAN context router port 5060 context sip-gateway GW_SIP no shutdown # ethernet 0 0 ist das LAN Interface port ethernet 0 0 medium auto encapsulation ip bind interface LAN router no shutdown # das zweite Interface nutzen wir nicht port ethernet 0 1 medium auto encapsulation ip shutdown # der Port e1t1 ist der PMX Port port e1t1 0 0 port-type e1 clock slave framing crc4 encapsulation q921 q921 uni-side auto encapsulation q931 q931 protocol dss1 uni-side user bchan-number-order ascending encapsulation cc-isdn # das Interface wird auf IF_ISDN_0_0 gebunden bind interface IF_ISDN_0_0 switch port e1t1 0 0 no shutdown
Dieses Konfiguarationsbeispiel sollte für viele Installationen ein guter Anfangspunkt sein. Wenn ihr sie anpasst und einspielt, dann könnt ihr über die Weboberfläche die Routing Tables ganz einfach administrieren (Nummern <-> Pattons (für Faxnummern)). Das sollte dann nach der Erstkonfiguration auch das sein, was man so im laufenden Betrieb machen muss. Bei Faxnummern oder generell bei Routing auf andere Patton Geräte daran denken, dass auch auf dem “ZielPatton” die Nebenstelle konfiguriert werden muss.
Übrigens: Um einen Eintrag zu ändern (gleiche Nummer, anderes Interface) legt man einfach einen neuen Eintrag mit der gleichen Nummer an
(No Ratings Yet) Loading ... Asterisk Projekt: Season 9 – Sicherung der Patton Konfiguration
27. Dez
Die Konfiguration eines Patton 4118 wurde im letzten Artikel beschrieben. Damit nichts verloren geht, sollte man regelmäßig die Konfiguration sichern. Das ganze zu Fuß zu machen macht keinen Sinn also automatisch. Aber wie?
Meine erste Idee
Meine erste Idee war die Sicherung über Telnet. So hat man auch früher die Konfiguation von Cisco Switches gesichert. Ein Script verbindet sich per Telnet auf das Gerät, listet die Konfiguration und sichert sie in einer Datei. Das würde mit den Pattons auch funktionieren. Allerdings gibt es eine bessere Möglichkeit.
Besser ist …
Es gibt die Möglichkeit die Konfiguration per TFTP zu sichern. Nicht als Cronjob auf dem Gerät selbst, sondern mit einem SNMP Aufruf (siehe SNMP Community zum schreiben im letzten Artikel). Dazu gibt es mehrere OIDs mit denen man
- den TFTP Server
- den TFTP Pfad / Dateinamen
setzen kann. Des Weiteren gibt es eine OID die die Sicherung ausführt und eine um den Erfolg zu prüfen.
In ein Script gepackt …
… sieht das ganze dann so aus:
#!/bin/bash
#
# Do Patton devices upload their current config via tftp
# -> for Backup
#
# .1.3.6.1.4.1.1768.100.3.1.1.0 = INTEGER: noOp(0)
# -- configsave $CLIENT SMARTNODE-MIB::uploadExecute.0
# .1.3.6.1.4.1.1768.100.3.1.2.0 = STRING: "10.21.3.10"
# -- SMARTNODE-MIB::uploadTftpServerAddress.0
# .1.3.6.1.4.1.1768.100.3.1.4.0 = STRING: "moe-pat05_20110929.cfg"
# -- SMARTNODE-MIB::uploadTftpServerPath.0
# .1.3.6.1.4.1.1768.100.3.1.5.0 = INTEGER: success(1)
# -- SMARTNODE-MIB::uploadStatus.0
UPLOAD_SERVER="10.21.3.10"
UPLOAD_FILENAME="_`date +%Y%m%d`.cfg"
UPLOAD_CLIENTS="patton01 patton02 patton03 patton04"
for CLIENT in $UPLOAD_CLIENTS
do
snmpset -v 1 -c configsave $CLIENT .1.3.6.1.4.1.1768.100.3.1.2.0 s $UPLOAD_SERVER >/dev/null
snmpset -v 1 -c configsave $CLIENT .1.3.6.1.4.1.1768.100.3.1.4.0 s "${CLIENT}${UPLOAD_FILENAME}" >/dev/null
snmpset -v 1 -c configsave $CLIENT .1.3.6.1.4.1.1768.100.3.1.1.0 i 1 >/dev/null
sleep 3
STATUS=`snmpget -v 1 -c nagios $CLIENT .1.3.6.1.4.1.1768.100.3.1.5.0`
if [[ $STATUS =~ failed ]]
then
echo "$CLIENT: tftp Backup via snmp failed"
fi
done
Damit liegen die Konfigurationen mit Namen patton01_20111217.cfg im TFTP Verzeichnis des – in meinem Fall – VoIP Servers. Das ganze hübsch in einen Cronjob verpackt und fertig ist die Sicherung.
(No Ratings Yet) Loading ... Asterisk Projekt: Season 8 – Hardwarekonfig Patton 4118 Analog Gateway
21. Dez
Der nächste Hardware “Baustein” ist ein Analog Gateway. Wie in Season 3 bereits beschrieben werden die Geräte von Patton eingesetzt.
Konfiguration
Die Patton Geräte sind von der Konfiguration her den Geräten von Cisco sehr ähnlich. Es gibt eine serielle Konsole, Zugriff per Telnet oder auch per Webfrontend.
IP Adresse
Zuerst einmal wäre eine IP Adresse hübsch. Also verbinden wir uns mit dem seriellen Kabel mit dem Gateway und nehmen das Terminalprogramm unseres Vertrauens (GtkTerm, minicom, …). Die Anmeldung geschieht mit Benutzernamen “admin” und Passwort “.”. Damit ist man angemeldet. Nun in den erweiterten Modus -> enable & configure.
IP Adresse und Default Gateway vergeben mit:
context ip router interface LAN ipaddress 10.21.3.122 255.255.255.0 context ip router route 0.0.0.0 0.0.0.0 10.21.3.201 0 port ethernet 0 0 medium auto encapsulation ip bind interface LAN router no shutdown
Damit sollte das Gateway über die LAN Schnittstelle 0/0 über die IP 10.21.3.122 erreichbar sein.
Telnet oder Web?
Da das Gerät nun über das Netzwerk erreichbar ist, hat man nun die Qual der Wahl. Hat man die wirklich?? Ja hat man. Es geht prinzipiell alles über CLI als auch über das Webfrontend. Die Grundkonfiguration (oder Template) kann man – sobald ein Beispiel vorhanden ist – in einem Editor anpassen und dann einfach per Copy&Paste im Terminalfenster an das Gateway weitergeben. Das geht um einiges einfacher als sich alles immer über das Webfrontend zusammen zu klicken.
Für andere Dinge (dazu kommen wir noch) ist das Webfrontend allerdings besser geeignet, bzw. einfacher.
Die Logik
Die Überschrift ist komisch – passt aber. Es ist eine eigene Logik die Patton innerhalb der Geräte anwendet. Es gibt verschiedene Contexte die auf verschiedene Interfaces gebunden werden (können) – das ganze läuft über Contexte und Bindings. Da die Konfiguration jedoch – so denke ich – bei fast allen recht gleich ist, sollte ein erklärtes Template den meisten eine gute Ausgangsbasis darstellen. Das gibt es gleich.
Die Logik zum Routen der Calls sieht so aus, dass man alles über 3 “Tabellen” abhandelt (kann man bestimmt auch anders machen). Dadurch ist man flexibel für viele Anforderungen und hat trotzdem einen relativ kompakten überblick über die aktuelle Konfiguration (Nebenstellen <-> Ports). Ein Anruf von “Außen” (über LAN an das Gateway) kommt zuerst einmal in das Routing Table “RT_SIP_IN”. Dort kann beispielsweise die Nummer bearbeitet werden (nur ein Beispiel), bevor es dann weitergeht in die “RT_LOCAL”. Innerhalb der RT_LOCAL wird dann entschieden an welchen Port der Anruf weitergeleitet wird. Dazu wird einfach die Nummer der Nebenstelle direkt auf ein Interface gebunden. Damit ist der Anruf zugestellt.
Ein Anruf von einem analogen Port aus funktioniert vergleichbar. Der Anruf landet zuerst in der Routing Table “RT_FXS_IN”. Dort kann je nach dem die ein oder andere Funktion ausgeführt werden, bevor es dann weitergeht in die RT_LOCAL. Dort wird entschieden wohin der Anruf geht. Würde der Anruf in unserem Beispiel an die 10 gehen, so würde der Anruf innerhalb der RT_LOCAL direkt an das betreffende Interface weitergereicht. Der Anruf würde also innerhalb des Patton Gateways abgehandelt. Trifft jedoch die angerufene Nummer nicht auf eine der lokalen Nebenstellen, so wird der Anruf an den default Eintrag weitergeleitet. Also an das SIP Interface, welches auf ein zentrales Gateway oder auf die Asterisk zeigen sollte. In unserem Beispiel (siehe Season 3) gehen alle Anrufe der analogen Gateways über das zentrale Patton Gateway (E1 Gateway zum PSTN). Dadurch bleiben Analoge Anrufe komplett in der Hand der Gateways (also reine Hardware) ohne dass eine Modulation von Asterisk benötigt wird. Das ist gerade für Faxe oder Modems ein wichtiger Vorteil.
Konfigbeispiel
Ich versuche das ganze durch Kommentare möglichst verständlich zu machen
#----------------------------------------------------------------#
# #
# SN4118/JS/EUI #
# R5.8 2011-07-01 H323 SIP FXS FXO #
# 2011-10-31T10:12:08 #
# SN/00A0BA052727 #
# Generated configuration file #
# #
#----------------------------------------------------------------#
cli version 3.20
clock local default-offset +02:00
webserver port 80 language en
# die SNMP Community zum auslesen von Statusinfos
snmp community nagios ro
# die SNMP Community zu schreiben von Werten
# diese ist sehr interessant und wichtig zum sichern der Konfiguration!!
snmp community configsave rw
# nun folgend die Hosts die SNMP abfragen duerfen und welche Rechte sie haben
snmp host 10.10.210.36 security-name monitoring
snmp host 10.10.210.36 security-name configsave
snmp host 10.21.3.10 security-name configsave
# NTP, die richtige Zeit ist wichtig
sntp-client
sntp-client server primary 10.10.210.201 port 123 version 4
# Hostname nicht nur fuer SNMP
system hostname patton03
system location "Schrank 1"
system contact netzwerkmanagement@einefirma.de
system
ic voice 0
low-bitrate-codec g729
profile ppp default
profile tone-set default
profile voip default
codec 1 g711alaw64k rx-length 20 tx-length 20
codec 2 g711ulaw64k rx-length 20 tx-length 20
rtp traffic-class local-default
# folgend nun diverse Einstellungen fuer die Faxuebertragung
# die sich bewaehrt haben
fax transmission 1 relay t38-udp
fax redundancy low-speed 2 high-speed 3
fax dejitter-max-delay 60
fax max-bit-rate 9600
fax detection fax-frames
# gleiches fuer Modems
modem transmission 1 bypass g711alaw64k rx-length 10 tx-length 10
modem dejitter-max-delay 60
no modem detection on-remote-fax-request
profile pstn default
profile ringing-cadence default
play 1 1000
pause 2 4000
profile sip default
no autonomous-transitioning
profile aaa default
method 1 local
method 2 none
context ip router
interface LAN
# IP Adresse des LAN Interfaces
ipaddress 10.21.3.122 255.255.255.0
context ip router
# Routen werden hier gesetzt, folgend die Default Route
route 0.0.0.0 0.0.0.0 10.21.3.201 0
context cs switch
digit-collection timeout 3
# im folgenden werden die Routing Tables definiert
# RT_SIP_IN
routing-table called-e164 RT_SIP_IN
route default dest-table RT_LOCAL
# RT_LOCAL (die zentrale Tabelle)
# inklusive einiger Portzuordnungen
routing-table called-e164 RT_LOCAL
route default dest-interface IF_SIP_patton01
route 334 dest-interface IF_FXS0
route 275 dest-interface IF_FXS1
route 285 dest-interface IF_FXS2
route 311 dest-interface IF_FXS4
route 312 dest-interface IF_FXS5
route 322 dest-interface IF_FXS7
route 270 dest-interface IF_FXS3
# der folgende Service ist eine "Hunt-Group"
# dabei wird auf mehrere verteilt (round-robin like)
route 310 dest-service DFUE_310
# RT_FXS_IN (Verbindung von analog Ports ausgehend)
routing-table called-e164 RT_FXS_IN
route default dest-table RT_LOCAL
route .T dest-table RT_LOCAL
# das Interface zur zentralen Patton
interface sip IF_SIP_patton01
bind context sip-gateway GW_SIP
# die Routing Table auf das Interface binden
route call dest-table RT_SIP_IN
# die IP des Gateways
remote 10.21.3.120
# nun kommen die einzelnen Interfaces
interface fxs IF_FXS0
# binden an die RT_FXS_IN
route call dest-table RT_FXS_IN
caller-id-presentation pre-ring
# die Nummer (fuer CLI)
subscriber-number 334
# und so weiter, fuer jedes Interface
interface fxs IF_FXS1
route call dest-table RT_FXS_IN
subscriber-number 275
interface fxs IF_FXS2
route call dest-table RT_FXS_IN
subscriber-number 285
interface fxs IF_FXS3
route call dest-table RT_FXS_IN
subscriber-number 270
interface fxs IF_FXS4
route call dest-table RT_FXS_IN
subscriber-number 311
interface fxs IF_FXS5
route call dest-table RT_FXS_IN
subscriber-number 312
interface fxs IF_FXS6
route call dest-table RT_FXS_IN
subscriber-number 313
interface fxs IF_FXS7
route call dest-table RT_FXS_IN
subscriber-number 322
# Das ist die Hunt-Group
# es wird nach quasi rr verteilt auf
# zwei Ports (siehe weiter unten)
service hunt-group DFUE_310
cyclic
drop-cause normal-unspecified
drop-cause no-circuit-channel-available
drop-cause network-out-of-order
drop-cause temporary-failure
drop-cause switching-equipment-congestion
drop-cause access-info-discarded
drop-cause circuit-channel-not-available
drop-cause resources-unavailable
drop-cause user-busy
# diese beiden Ports spielen mit
route call 1 dest-interface IF_FXS4
route call 2 dest-interface IF_FXS5
context cs switch
no shutdown
context sip-gateway GW_SIP
# hier wird das lokale interface erstellt, welches
# SIP Pakete entgegen nimmt
interface GW_IF
bind interface LAN context router port 5060
context sip-gateway GW_SIP
no shutdown
port ethernet 0 0
medium auto
encapsulation ip
bind interface LAN router
no shutdown
# nun wird jeder Port konfiguriert
port fxs 0 0
encapsulation cc-fxs
# gebunden wird dieses Interface an den Context IF_FXS0 (s. oben)
bind interface IF_FXS0 switch
# aktivieren
no shutdown
# und so weiter fuer jeden Port
port fxs 0 1
encapsulation cc-fxs
bind interface IF_FXS1 switch
no shutdown
port fxs 0 2
encapsulation cc-fxs
bind interface IF_FXS2 switch
no shutdown
port fxs 0 3
encapsulation cc-fxs
bind interface IF_FXS3 switch
no shutdown
port fxs 0 4
encapsulation cc-fxs
bind interface IF_FXS4 switch
no shutdown
port fxs 0 5
encapsulation cc-fxs
bind interface IF_FXS5 switch
no shutdown
port fxs 0 6
encapsulation cc-fxs
bind interface IF_FXS6 switch
no shutdown
port fxs 0 7
encapsulation cc-fxs
bind interface IF_FXS7 switch
no shutdown
Dieses Konfiguarationsbeispiel sollte für viele Installationen ein guter Anfangspunkt sein. Wenn ihr sie anpasst und einspielt, dann könnt ihr über die Weboberfläche die Routing Tables ganz einfach administrieren (Nummern <-> Ports). Das sollte dann nach der Erstkonfiguration auch das sein, was man so im laufenden Betrieb machen muss.
Übrigens: Um einen Eintrag zu ändern (gleiche Nummer, anderes Interface) legt man einfach einen neuen Eintrag mit der gleichen Nummer an
Wichtig noch …
Die Konfiguationsänderungen müssen – Cisco like – auf der CLI per
copy running-config startup-config
gesichert werden, bzw. auf dem Webinterface über “save”. Ansonsten sind die Änderungen bei einem Neustart verloren.
Das war die simple Variante
Was ich Euch hier gezeigt habe ist eine ganz simple Variante der Konfiguration. Man kann mit den Patton Gateways noch sehr viel mehr an Funktionen und allerhand Schweinereien treiben. Ein paar Funktionen werde ich noch zeigen, wenn es an das zentrale Gateway geht.
(No Ratings Yet) Loading ... Asterisk Projekt: Season 7 – Hardwarekonfig Aastra RFP L32IP, DECT Basis – Nachtrag: In Reichweite
20. Dez
Leider hab ich noch was wichtiges in Season 7 vergessen.
Am besten jeder mit jedem
Ich hatte die Installation beschrieben, jedoch kein Wort darüber verloren wie man am besten mehrere Basisstationen aufstellt. Die Frage stellt sich natürlich nur, wenn man mehr als eine Basisstation hat. Generell muss ein Basisstation mindestens eine weitere “sehen”. Am besten ist sogar (s. Bild), wenn sich – naja im besten Fall – alle sehen. Sehen bedeutet in diesem Fall über DECT eine Verbindung haben. Es gibt ein Tool von Aastra um zu sehen wie gut die Verbindung zwischen den Basen ist, bzw. welche überhaupt eine Verbindung haben. Das Tool ist (stand heute) hier zu finden und heißt “DECT Monitor”. Wir haben das ganze mit Hilfe dieses Tools “ausgeleuchtet”.
Quelle: Aastra Installation Guide
Warum muss denn jeder jeden “sehen”?
Die Basisstationen bieten support für Rooming. Man kann also während des Gesprächs von der einen zu anderen Basisstation springen ohne dass das Gespräch verloren geht. Schon alleine deshalb müssen die einzelnen Stationen sich über DECT unterhalten können um den Handshake ohne Probleme durchführen zu können. Des weiteren geht es um Redundanz. Baut man eine Kette aus Basisstationen, dann funktioniert das ganze bis zur ersten Basis die ausfällt. Hat jede Basisstation kontakt mit mehr als einer weiteren, so kann eine ausfallen ohne dass eine andere Probleme hat.
Das Szenario ist natürlich nur dann interessant wenn der auszuleuchtende Raum auch entsprechend groß ist. So groß dass eine Basis nicht genügt um den Raum – oder die Etagen – auszuleuchten.
(No Ratings Yet) Loading ... Asterisk Projekt: Season 7 – Hardwarekonfig Aastra RFP L32IP, DECT Basis
19. Dez
In der Season 4 hatte ich bereits die Aastra Stationen erwähnt. Die Konfiguration dieses Gerätes möchte ich nun beschreiben.
Requirements
Naja, also zuerst einmal benötigt man die Basisstation Dabei ist auf das “L” zu achten. Es gibt auch eine Version ohne “L”. Diese ist nicht für standard SIP sondern für die proprietären Anlagen von Aastra gedacht und funktioniert nicht mit unserer Anlage.
Möchte man mehr als 2 Basisstationen nutzen, also einen Cluster aufbauen, so benötigt man eine CD von Aastra. Die CD hat den Namen “OMM Activation Kit” und beinhaltet die Software & Firmware; interessanter ist allerdings der Lizenzkey auf der CD. Die CD kostet irgendwas zwischen 10 und 20€. Ohne diese Lizenz kann man jedoch nur zwei Basisstationen betreiben. Das ganze ist im Internet nur sehr schwer zu finden und auch die Vertriebsmenschen von Aastra kennen sich leider damit nicht aus. Damit ihr nicht auch so lange suchen müsst füge ich hier einen Screenshot der CD an (-> Artikelnummer ). Die aktuelle Version der Software gibt es hier.
Weiterhin benötigt man einen TFTP Server in Reichweite der Basisstationen. Diese wird zum Bereitstellen der Firmware benötigt.
Booten?
Um die Basis zu konfigurieren muss das Ding ins Netz. Dann kann mit Hilfe des OM_Configurators (Java Applikation zu finden im Software Bundle, bzw. auf der CD) das Gerät gesucht werden.
Folgende Schritte sind dann notwendig:
- use local config
- IP Addresse vergeben
- Netmask …
- TFTP Server eingeben
- TFTP file name (Firmware Datei aus dem Software Bundle, omm_ffsip.tftp)
- OMM IP Address (in dem Fall seine eigene)
- ggf Router
Wofür?
Man muss zuerst einmal verstehen wie diese Dinger arbeiten. Jedes für sich ist nämlich – auf deutsch gesagt – recht doof. Was man in dem OM_Configurator einstellen kann ist quasi schon alles. Mehr kann sich das Ding auch nicht merken. Bei jedem Start wird sich per TFTP ein Firmware Image gezogen – selbst diese ist nicht persistent auf dem Gerät.
Des Weiteren muss man wissen, dass es immer einen Master unter den Basisstationen gibt. Alle anderen Geräte bekommen gar keine Konfiguation. Sie suchen sich den Master und bekommen sämtliche Informationen und die Konfiguration von ihm. Auch die Information wo die Slave Stationen die Firmware finden wird intern ausgetauscht. Daher auch der Parameter OMM IP Address – OpenMobilityManager. Damit wird der Master festgelegt. Eine Basisstation die selbst die IP des Masters besitzt, erkennt damit automatisch dass sie die Führung hat.
Und weiter?
Hat man die erste Station so konfiguriert und startet sie neu, so wird das image per TFTP geladen und die Station ist per Webzugriff erreichbar. Benutzername “omm” und Passwort “omm” sollten den Zugang freigeben. Danach sind noch ein paar kleinere Systemeinstellungen zu machen. Ich möchte jedoch nur noch ein paar Dinge dazu schreiben.
- Unter dem Menüpunkt Basisstationen muss man einen Cluster erstellen, damit das Rooming funktioniert
- Unter dem Menüpunkt Endgeräte werden die Mobilen Endgeräte konfiguriert. Es gibt dabei zwei Möglichkeiten das ganze zu tun
- a) Die Basisstation wird in einen Zustand versetzt, in dem sie neue Geräte einfach aufnimmt und anzeigt
- b) Man legt die Mobilteile vorher an und registriert sie dann
Um Mobilteile zu registrieren nutzen wir die zweite Möglichkeit. Wir bestimmen die IPEI Nummer (quasi sowas wie die MAC eines DECT Telefons) und legen damit einen Account in der Basis an. Die Accountdaten müssen natürlich mit denen am Asterisk Server übereinstimmen (Nummer, Name, Passwort). Damit ist das Gerät hinterlegt und wird bei der Anmeldung automatisch der richtigen Nummer zugewiesen.
Bestimmen der IPEI:
“An einem Siemens Gigaset kann die IPEI Nummer (als HEX) mit folgendem Befehl angezeigt werden:
Menü öffnen, *#06# eingeben, die erste Zeile ist die IPEI als HEX.”
Um die IPEI von HEX auf Dezimal umzurechnen, kann man diese Website nutzen (oder eben diese Funktion dahinter möglicherweise lokal bereitstellen).
Wichtig zu wissen ist – gerade bei Siemens -, dass die PIN immer 0000 sein muss. Ansonsten funktioniert das anmelden des Mobilteils nicht.
Die Geräte laufen bischer absolut zuverlässig. Auf der Herstellerhomepage kann man auch einen userguide finden, der beispielsweise Auskunft darüber gibt was die Anzeige der LEDs auf der Gehäusevorderseite bedeutet.
(No Ratings Yet) Loading ... Asterisk Projekt: Season 6 – Manchmal kommt es anders, und öfters als man denkt
16. Dez
Was ein Sch…..
Also es ist nun schon einige Wochen her. Da gab es richtig Probleme mit der Anlage die ich hier beschreiben wollte. Auch daher die Verspätungen.
Was ist passiert?
Die Anlage wurde planmäßig installiert und in Betrieb genommen. Das waren so ca. 50 Telefone, 25 Analoge Nebenstellen (Faxe und DECT Telefone). Das ganze gepaart mit einer Queue und tollen Funktionen im Dialplan. Alle Tests waren erfolgreich und es sah super aus.
Die Anlage war also in Betrieb. Dann kam ein Elektriker. Der wollte einen Supertollen Umschalter im Rechenzentrum fertig installieren (Neubau). Ganz ohne dass der Strom ausfällt – versprochen Also alle Server eingeschaltet gelassen. Passiert doch nix. Aber dann … wie von Geisterhand … auf einmal …. Dunkelheit … und diese Ruhe. Huch. Strom doch weg. Haha. Also RZ tot.
Naja, eigentlich kein Problem sollte man denken. Ok, die Server wieder hochfahren und gut is. Vielleicht macht der ein oder andere noch einen Festplattencheck, aber dann hat sich die Sache. War auch so. Alles wieder gut.
Oder?
Wenige Minuten später … ein Anruf übers Handy. Die TK Anlage steht still. Hä? Das gab’s ja bisher noch nie – egal was ich an Konfigurationsfehlern eingebaut hatte auf allen Testsystemen. Von nun an ging es hin&her. Fehlersuche … überall. Es gab einfach keine Fehlermeldung mit einem Hinweis auf den Fehler. Das Szenario war auch verschieden. Einerseits zog der asterisk Prozess 100% CPU und nahm nichts mehr an. Andererseits schmierte der Prozess mit einem Core Dump einfach sang und klanglos ab. Auch die Laufzeiten waren total verschieden. Mal lief der Prozess ein paar Stunden, mal nur wenige Minuten.
Das ganze ging zwei Wochen hin&her. Zuerst habe ich versucht herauszufinden was los ist – strace, tcpdump, entfernen der Scripte aus dem Dialplan … alles hat nichts gebracht. Auch andere Versionen wurden ausprobiert, keine Änderung. Zwischenzeitlich wurde eine externe Firma mit ins Boot genommen. Die sich genauso die Zähne ausgebissen haben (Konfig geprüft, eigene Versionen von Asterisk paketiert, …), allerdings hatten die dann auch die entscheidende Idee. Das ganze ging gut 2 Wochen.
And the problem was *trommeln* ….
Das Problem waren am Ende Umleitungen am Telefon. Und jetzt fragt ja nicht “Hä?”! Es handelt sich dabei auch nicht um einen Konfigurationsfehler, sondern um ein Fehler in der Asterisk Software. Dieser Fehler ist in Version 1.6 genau so vorhanden, wie in der 1.8 – die wir mittlerweile dann doch einsetzen
genauer gesagt …
Man kann an einer solchen Telefonanlage vieles auf verschiedene Arten lösen. Auch Umleitungen. Einerseits kann man die Umleitungen innerhalb der Anlage abhandeln und andererseits geht das über das Telefon. Besser ist definitiv das ganze über die Anlage zu machen. Das erweist sich auch an vielen anderen Stellen als sinnvoll.
Nun hatte ich das sogar so gemacht. Der “alte” Ablauf für eine Umleitung sah so aus:
- Benutzer drückt eine gewisse Taste am Telefon
- gibt das Umleitungsziel ein
- mit der Bestätigung wird im Telefon lokal die Umleitung gesetzt und im Hintergrund eine Nummer angerufen, die als Parameter ebenfalls das Umleitungsziel besitzt. Dadurch wird in der Anlage ebenfalls eine Umleitung gesetzt.
Am Ende war also im Telefon eine Umleitung, die jedoch im normalfall nicht zum Zug kam, weil bereits in der Anlage umgeleitet wurde. Das ganze funktionierte einwandfrei. Die jeweilige Nummer wurde in der AstDB gespeichert und war somit für den Server jederzeit verfügbar. Bei jedem Anruf wurde geprüft ob eine Umleitung in der Datenbank vorhanden war und entsprechend gehandelt.
Wie gesagt, das ganze funktioniert wunderbar. Jedoch nur solange die Datenbankinformationen mit denen der Telefone gleich sind. Hat ein Telefon eine Rufumleitung aktiviert und der Server nicht, so wird der Anruf an das Telefon weitergeleitet. Das Telefon leitet um und dann …. macht’s PENG!!! Kein Witz. Sobald die Umleitung vom Telefon die Anlage erreicht streckt die Asterisk die Flügel und gibt den Geist auf. Auf diese Idee muss man erst einmal kommen. Vor allem, weil das sich von der Version 1.6x bis 1.8x durchzieht.
Aber was hat das ganze mit dem Stromausfall zu tun?? Na das ist dann auch recht einfach. Da der Server nicht heruntergefahren wurde sondern hart ausgeschaltet, waren die Informationen in der Asterisk DB verloren. Also gab es einige Telefone die eine lokale Umleitung aktiviert hatten, der Server davon jedoch nichts mehr wußte. Mit jedem Anruf auf ein solches Telefon wurde die Anlage gekillt. Es gab natürlich einige resets auf dem Server. Die Datenbank frisch gemacht, auf einen anderen Server umgeschwenkt. Das System sogar komplett neu installiert. Aber – naja am Ende ist mal halt schlauer – was sollte das bringen, so lange man die Telefone nicht zurücksetzt. Wir sind eben immer von einem Serverproblem ausgegangen.
Abhilfe
Nachdem das Problem erkannt war wurde dann erst einmal schnelle Hilfe geleistet. Nagios bekam von mir einen Plugin spendiert, der den Status der Telefone mit dem der Datenbank verglich. Sobald es inkonsistenzen gab wurde es rot. Des Weiteren habe ich ein Script geschrieben, welches alle Umleitungen auf allen Telefonen ausschaltet. Das war jedoch nur die Notfallmedizin.
Nachdem ein wenig Ruhe eingekehrt war habe ich mich dann hingesetzt und die ganze Logik für die Rufumleitungen neu geschrieben. Das ganze funktioniert nun über eine Website für die Snom Telefone (xml). Dort wird das Umleitungsziel eingegeben, das ganze wird dann in eine MySQL Datenbank geschrieben und von Asterisk genutzt. Lokal am Telefon gibt es keine Umleitung mehr. Seit dem ist nun auch Ruhe.
Das ganze war einfach extrem blöd, weil die Anlage ja bereits im produktiven Einsatz war. Dadurch entsteht durchaus ein gewisser Druck
(No Ratings Yet) Loading ... Asterisk Projekt: Season 5 – Die 5 Minuten Terrine oder: Asterisk installation
06. Okt
Ob nun 5 Minuten wirklich gebraucht werden
Asterisk Installation
Die Installation von Asterisk ist eine der Aufgaben die wirklich am einfachsten ist. Ich mache das ganze auf Debian, also hab ich auch die Debian Pakete genommen. apt-get la-le-lu und fertig. Welche Paket ich installiert habe? Diese:
ii asterisk 1:1.6.2.9-2+squeeze3 Open Source Private Branch Exchange (PBX) ii asterisk-config 1:1.6.2.9-2+squeeze3 Configuration files for Asterisk ii asterisk-core-sounds-en-gsm 1.4.19-1 asterisk PBX sound files - English/gsm ii asterisk-doc 1:1.6.2.9-2+squeeze3 Source code documentation for Asterisk ii asterisk-h323 1:1.6.2.9-2+squeeze3 H.323 protocol support for Asterisk ii asterisk-moh-opsound-g722 2.03-1 asterisk extra sound files - English/g722 ii asterisk-moh-opsound-gsm 2.03-1 asterisk extra sound files - English/gsm ii asterisk-moh-opsound-wav 2.03-1 asterisk extra sound files - English/wav ii asterisk-mp3 1.6.2.1-1 MP3 format support (format_mp3) for the Asterisk PBX ii asterisk-mysql 1.6.2.1-1 MySQL support for the Asterisk PBX (cdr mainly) ii libasterisk-agi-perl 1.01-2 Collections of Perl modules to be used with Asterisk PBX AGI
Damit hat man bereits quasi alles was benötigt wird um den Asterisk Server zu starten.
In den Debian Repositories ist noch Asterisk 1.6 – und das ist auch gut so. Asterisk 1.8 gibt es zwar auch schon länger, allerdings ist diese Version noch recht Buggy. Im Internet wird auch noch oft von der 1.8 abgeraten und die meisten Dokus beziehen sich auf 1.6. Ich hatte bisher auch noch keine Probleme mit dem Dienst an sich.
Auf die absoluten Basics (bspw. wie nun einen SIP/Account einrichten) möchte ich hier eigentlich – wie immer – nicht eingehen. Ich möchte mehr die Fallstricke beschreiben die ich auf meinem Weg beiseite räumen musste und ein Tipps geben. Eine gute Quelle ist das Asterisk Buch online ( http://www.das-asterisk-buch.de/2.1/ ). Dort werden gerade die Basics recht gut beschrieben.
Ein paar Konfighints
Konfiguration über Scripte erweitern
Datei: /etc/asterisk/asterisk.conf
Parameter: execincludes = yes ; support #exec in config files
Dadurch wird es möglich innerhalb von Konfigurationsdateien mit Hilfe von “#exec” externe Scripte auszuführen. Der Output eines solchen Scriptes muss im Format der Konfigurationsdatei sein.
Konfigurationen (Accounts & Voicemail) aus der Datenbank
Das ganze läuft unter dem Namen “realtime”. Der Name ist durchaus verständlich, da durch Änderungen an der Datenbank der Asterisk Prozess nicht neu geladen werden muss. Ändert man in den Dateien (sip.conf, voicemail.conf, etc.) muss der Dialplan oder teilweise der asterisk Prozess neu geladen werden.
Datei: /etc/asterisk/extconfig.conf
Parameter:
[settings] voicemail => mysql,general,voicemail sipusers => mysql,general,sip_devices sippeers => mysql,general,sip_devices
Diese Einstellungen bewirken, dass Asterisk nach den SIP Accounts (quasi der /etc/asterisk/sip.conf) auch in der Datenbank schaut. Das gleiche gilt für die /etc/asterisk/voicemail.conf.
Damit das ganze funktioniert müssen noch die Daten für den Connect auf die Datenbank eingerichtet werden.
Datei: /etc/asterisk/res_mysql.conf
Parameter:
[general] ;dbhost = 127.0.0.1 dbname = asterisk_db dbuser = root dbpass = test dbport = 3306 dbsock = /var/run/mysqld/mysqld.sock requirements=warn ; or createclose or createchar
Diese Einstellungen machen dem System die Datenbank bekannt. Man sieht nun auch, dass der Verweis aus der extconfig.conf “general” auf diese Verbindung zeigt und hier seine Referenz hat. Dem entsprechend können also auch mehrere Datenbanken genutzt werden.
Die Datenbanktabellen müssen noch erstellt werden. Dafür möchte ich gerne auf eine externe Seite verweisen -> http://www.voip-info.org/wiki/view/Asterisk+RealTime+Sip
Mit einem reload oder restart sollte dann die Konfiguration in der Datenbank berücksichtigt werden – falls vorhanden. Die Felder in der Datenbank sind analog zu denen in den Konfigdateien. Es gibt einige Spalten die in den jeweiligen Tabellen vorhanden sein müssen, die meisten können jedoch auch einfach gelöscht werden. Auch zusätzliche Spalten sind kein Problem – sie werden von Asterisk einfach ignoriert.
Dateirechte
Mir ist es häufig passiert, dass ich Änderungen vorgenommen habe die vom System nicht angenommen wurden. Das ganze ohne irgendeine Fehlermeldung (wenigstens in den “normalen” logs). Das passiert, wenn die Rechte einer Konfigurationsdatei nicht stimmen. Die Dateien sollten alle asterisk gehören.
Erster Test
Einen ersten Test kann man ganz einfach mit Hilfe eines Headsets und (bspw.) Ekiga oder Jitsi – also Softphones – machen. Ich habe dazu Voicemail konfiguriert und als Test die Mailbox angerufen.
(No Ratings Yet) Loading ... Asterisk Projekt: Season 4 – aber bitte auch mit ohne Kabel
30. Sep
Ups, eine Hardware-Kleinigkeit hab ich doch glatt vergessen 
Wir möchten doch auch Mobil telefonieren!
WLAN oder DECT?
Zuerst einmal muss man sich entscheiden welche Technologie man einsetzen möchte. Es gibt WLAN Mobiltelefone – mittlerweile sogar von AVM – welche dann direkt per WLAN mit dem Asterisk kommunizieren und sich registrieren. Auf der anderen Seite gibt es auch DECT für VoIP. Wo liegt nun der Unterschied bzw. Nachteile und Vorteile??
Mit WLAN wird jeder so seine Erfahrungen gemacht haben. WLAN ist nur relativ zuverlässig was die Geschwindigkeit und auch den Empfang angeht. Je weniger Empfangsstärke man hat, desto weiter geht die Übertragungsrate runter. Das ist ein Problem dabei. Das könnte man natürlich durch einen Haufen Sender in den Griff bekommen. Das andere Problem ist die Latenz. WLAN ist nicht für Echtzeitkommunikation gedacht und dem entsprechend bringt das auch Probleme beim VoIP Betrieb mit sich. Ein weiterer Aspekt: Die Geräte sind zur Zeit noch relativ teuer.
DECT ist seit vielen Jahren der Standard für Mobile Analogtelefone. Die Reichweite einer einzelnen Basisstation ist gut und man bekommt viele verschiedene Telefone von vielen Herstellern. Die Telefone sind auch von der Benutzung her fast jedem bekannt und müssen nicht groß erklärt werden. (Ich weiß gerade nicht so recht was ich noch zu DECT schreiben soll !?!)
Da WLAN für uns aus oben genannten Gründen und auch aus Erfahrungsberichten heraus nicht zur Diskussion stand, haben wir und für DECT entschieden.
Auch da gibt es was von Ratiopharm
Naja, nicht ganz Wie bildet man eine Schnittstelle zu Mobilteilen von der Asterisk Anlage ab?
Die LowCost Lösung wäre einfach ein ganz normales Mobiltelefon an einen analogen Port an eines der Patton Gateways anzuschließen. Das ist auch in Ordnung, wenn man nur ein paar Mobilteile hat und auch von der größe des Gebäudes auf Roaming (wenn die Reichweite einer Basisstation nicht das ganze Gebäude abdeckt) verzichten kann.
Muss man jedoch ein größeres Gebäude versorgen, so macht das mit den Pattons keinen Sinn. Erstens zu teuer und zweitens benötigt man dann die Roaming Funktionalität. Man kommt also um eine professionelle Lösung nicht herum. Ich habe mich bei einer solchen Basisstation für die “Aastra RFP L32IP” entschieden. Jede Basisstation kann bis zu 8 SIP Gespräche gleichzeitig handeln, bis zu 4096 Telefone verwalten ( ) und Cluster mit weiteren Basisstationen dieser Art bilden. Durch die Clusterbildung kann man große Gebäude in jeder Ecke ohne Probleme ausleuchten. Die Konfiguration der Geräte ist einerseits total kompliziert (wenn man nicht weiß wie diese Dinger ticken), andererseits jedoch vollkommen lapidar. Darauf werde ich in dieser Reihe definitiv noch eingehen!!
Fazit: Wir nutzen auch für DECT quasi Gateways, die für uns VoIP in DECT umwandeln und uns so in die Lage versetzen ganz normale Mobilteile an der Asterisk zu nutzen.
(No Ratings Yet) Loading ...
