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.
Der Gründer von Linux Mint, Clement Lefebvre, arbeitet anscheinend an einem GNOME Shell Fork mit Namen Cinnamon. Ziel des Projekts ist es, dem Anwender ein GNOME-2-ähnliches Layout zur Verfügung zu stellen. Somit sollen sich Anwender wieder “zu Hause” fühlen. Das berichtet zumindest webupd8.org und der auf github.com gehostete Quellcode bestätigt das.
Wer wirklich nur Musik abspielen will, dem wird die Standardkonfiguration völlig ausreichen, wer mehr will kann über Edit->Customize mehr Spalten hinzufügen. 
Leider ist an dem Code seit Mitte letzten Jahres auch nichts mehr geschehen und das obwohl so eine Erweiterung auf jeden Fall sinnvoll ist. Naja vielleicht findet sich ja jemand….
