Asterisk Projekt: Season 8 – Hardwarekonfig Patton 4118 Analog Gateway

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.

Category: Asterisk, ubuntuusers.de Tags :

2 Responses to Asterisk Projekt: Season 8 – Hardwarekonfig Patton 4118 Analog Gateway

  1. Schuelli Daniel

    Hallo Ronny,

    ich habe diese Einstellungen benutzt. Es funktioniert bei mir leider nicht.
    Kannst du mir evtl. weiterhelfen?

    Vielen Dank und Gruss
    Daniel

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>