[Projekt] Einrichtung einer VoIP-Telefonanlage auf Asterisk-Basis

Im heutigen Blogeintrag berichten wir von der Einrichtung unserer eigenen Telefonanlage, die wir vor wenigen Wochen in Betrieb genommen haben.

Die Ausgangssituation:
Bisher nutzten wir die Fritzbox von KabelBW mit einigen Cisco SPA525-G Telefonen als Telefonanlage. Es stellte sich jedoch mit zunehmender Mitarbeiterzahl heraus, dass Durchwahlen, Rufgruppen, mehr als zwei Telefonleitungen und Ferneinwahl unumgänglich sind.

Die Entscheidungsfindung:
Aktuell gibt es eine Reihe von Möglichkeiten, wie man die Aufgabenstellung „Telefonie“ lösen kann: über diverse Angebote der großen Telefongesellschaften (sei es über klassische ISDN oder VoIP), über im Web gehostete Telefonanlagen oder über selbst eingerichtete Telefonlagen (ISDN oder SIP-Trunking).
Wir entschieden uns für eine SIP-Trunk-Lösung und eine VoIP-Telefonanlage auf Asterisk-Basis, da es das Ziel war, möglichst viele Einstell- bzw. Erweiterungsmöglichkeiten und geringe Kosten zu haben. Zusätzlich haben wir einen 100er Rufnummernblock bestellt, damit eine ausreichende Anzahl an Durchwahlen zur Verfügung stehen.
Im Speziellen fiel die Wahl auf freepbx, das wir auf unserem Server in eine virtuelle Maschine auf Hyper-V-Basis installiert haben. Die Distribution lässt sich bequem als ISO herunterladen und ist direkt nach der Installation bereit zur Konfiguration.

Die Umsetzung:
Nach der Installation gibt es vier Punkte die für eine Basis-Konfiguration vorzunehmen sind:

1. Einrichtung SIP-Trunk:
Hier sind vor allem der „Register String“ und die Peer-Details wichtig. Diese Informationen stellt im Normalfall der SIP-Trunk-Anbieter zur Verfügung. Zudem muss die „Outbound CallerID“ angegeben werden, das geschieht hier im Format „0049+Vorwahl+Rufnummer“. Als Art der Rufnummerübertragung auf Seiten des SIP-Trunks (CLIP no screening) haben wir als Einstellung „Remote Party ID“ gewählt, somit wird die „Outbound CallerID“, die in der SIP-Trunk-Einstellung in freepbx konfiguriert ist, übertragen.

2. Einrichtung outbound routes
In diesem Punkt sind vor allem die „Dial Patterns“ erwähnenswert; damit wird angegeben, wie anzurufende Rufnummern auszusehen haben. Für eine Basis-Konfiguration reichen hier schon „+.“ zur Erkennung von beispielsweise +49 und „XX.“ zur Erkennung von zum Beispiel 0049. Weitere Erklärungen zu diesem Thema sind sehr rasch via Google zu finden.

3. Einrichtung inbound routes
Die eingehenden Routen sind zur Verteilung der Anrufe bestimmt. In unserem Fall haben wir hier eine default-route für alle Rufnummern des Rufnummernblocks angelegt, und einzelne Routen für die Rufgruppen und direkten Durchwahlen.

4. Einrichtung extensions
Im Reiter „extensions“ sind die einzelnen Accounts konfigurierbar mit entsprechender „Outbound CallerID“ die dann diejenige in (1) überschreibt. Diese sollte hier im Format „NAME“ <0049….> vorliegen.

Erste Erfahrungen:
Bisher läuft unsere Telefonanlage tadellos. Da wir über eine redundante WAN-Anbindung verfügen, konnten wir auch den Ausfall eines Internetanschlusses testen. Problemlos lief die Verbindung zum SIP-Trunk weiter, laufende Gespräche sind natürlich unterbrochen worden. Die Option des Telefonierens über einen Softclient via VPN aus dem Homeoffice ist nützlich und sinnvoll. Sollten allgemeine Fragen oder Fragen zur Konfiguration bestehen, können Sie sich gerne an uns wenden.

FreePBX-Administrationsoberfläche

[Projekt] Entwicklung einer Content-Marketing-Plattform für die Contiago AG

Seit Ende des Jahres 2013 arbeiten wir gemeinsam mit der Contiago AG mit Sitz in Hamburg und Hirschberg/Leutershausen an dem Webprojekt „Contiago“. Content Marketing ist in den letzten Jahren eines der wichtigsten Tools im SEO-Mix von Unternehmen geworden und die Bedeutung von Content Marketing nimmt weiterhin zu. Bereits 1996 sagte Bill Gates in einem visionären Essay die Wichtigkeit von Content im Internet voraus und prägte das Zitat „Content is king“. Dieses Zitat scheint aktueller denn je und wird im Zusammenhang mit Content Marketing sehr häufig verwendet.

Contiago versteht sich als „Content Marketplace“. Die Plattform verbindet Content-Produzenten (Redakteure), Content-Lieferanten (Verlage) und Content-Abnehmer (Endkunden mit Homepages) mit einem bisher einzigartigen Geschäftsmodell. Verlage bieten über Contiago sogenannten „Paid Content“ an. Dieser wird in Form von „Feeds“ (Nachrichtenströme aus bestimmen Themenbereichen) an die Endkunden-Webseiten ausgeliefert. Insgesamt entsteht eine Win-Win-Situation für alle Beteiligten. Redakteure können auf einfache Weise professionelle und hochwertige Artikel für verschiedene Verlage schreiben. Die Verlage haben wiederum die Möglichkeit, ihre Inhalte über einen bisher noch nicht genutzten Weg zu vertreiben – nämlich direkt auf themennahen Webseiten. Die Endkunden bieten den Besuchern ihrer Webseite aktuellen, hochwertigen Content aus Themenbereichen die für die Besucher der Seite relevant sind. Die Contiago AG konnte bereits viele Verlagskunden, teils Marktführer in ihren Branchen, gewinnen.

Die HW Computer Solutions GmbH betreut die Contiago AG in allen Bereichen rund um das Produkt „Contiago“. So entwickelten und betreuen wir sowohl das Portal als auch den Blog. Zudem entstand der erste Prototyp des Kernsystems und die Schnittstelle in unserem Hause. Auch Plugins für die beliebten Content Management Systeme „TYPO3“ und „Wordpress“ wurden von uns entwickelt.

In den nächsten Monaten werden zahlreiche weitere Verlage ihre Kooperation mit Contiago bekannt geben. Die HW Computer Solutions GmbH wird als technischer Partner den Rollout bei Endkunden-Seiten mit dem Content Management System „Websuite“ der OpenMinded GmbH unterstützen.

Weiterführende Links:
Contiago Portal: http://www.contiago.de/
Contiago Blog: http://blog.contiago.de/
YouTube – Contiago Erklärvideo: https://www.youtube.com/watch?v=mM-eq7LHoqo
YouTube – Wie funktioniert Contiago?: https://www.youtube.com/watch?v=-ULZ3NKk9XI
** Das Contiago Kernsystem ist nur angemeldeten Mitgliedern zugänglich.**

contiago_blog

[Projekt] Komfortable Softwaremigration durch Aufbau einer Parallelumgebung

Gerade in einer über viele Jahre gewachsenen Infrastruktur kommt bei umfassenden Softwareumstellungen der Punkt, an dem sich die Frage stellt, ob das bisherige Gerüst sinnvoll weiter verwendet werden kann, oder ob es nötig ist, die Serverlandschaft von Grund auf neu aufzubauen.

Dieses Szenario finden wir immer wieder bei (Neu)-Kunden vor. Dabei ist es besonders für Kunden, die rund um die Uhr eine funktionierende Arbeitsumgebung benötigen, wichtig, dass sämtliche „alten“ Applikationen bis zum Livegang der neuen Infrastruktur und somit der neuen Software verfügbar sind.

In der Praxis ist diese Aufgabenstellung mit dem Aufbau einer Parallelumgebung lösbar. Hierzu wird ein paralleles Netzwerk eingerichtet und beide Netzwerke über einen Router mit entsprechenden Firewallregeln verbunden. Da wir fast ausschließlich virtuelle Umgebungen einsetzen, ist es auf Serverseite möglich, die Netze über verschiedene Netzwerkkarten den alten und neuen virtuellen Maschinen zuzuordnen. Dies wird mit einer Grafik unten stehend veranschaulicht. 2014-12-11-Parallelumgebung-vmNIC

Eine weitere schematische Darstellung zeigt, wie auf den Hosts der virtuellen Server die Parallelumgebung aufgebaut ist.

2014-12-11-Parallelumgebung-Schema

Nach dem Aufsetzen der neuen Server, das ohne große Einschränkungen im Hintergrund geschehen kann, müssen die Clients umgestellt bzw. in die neue Domäne gebracht werden. Hierfür ist nur ein Umstecken auf einen (temporären) Switch und die Aufnahme in die neue Domäne notwendig. Es empfiehlt sich jedoch, die Rechner – je nach Zustand – komplett neu aufzusetzen.

Die alten Applikationen und alten Server sind nach wie vor über das Routing mittels IP-Adresse zu erreichen. Einige Anwendungen, wie zum Beispiel Lexware, erfordern jedoch DNS. In kleineren Netzwerken (bis 30-40 Clientcomputern) ist dies problemlos über die hosts-Datei des jeweiligen Rechners lösbar, alternativ ist es möglich, den DNS-Server anzupassen.

Selbstverständlich ist in der Übergangsphase mit Leistungseinbußen zu rechnen, jedoch sollten sich diese bei entsprechend dimensionierten Systemen in Grenzen halten.

Mit diesem Blog Eintrag verabschieden wir uns aus dem Jahr 2014 und freuen uns Ihnen nächstes Jahr wieder interessante Beiträge zu liefern.

Erfahrungen mit der OS-X-Server-App

Bei einem Kunden mit insgesamt 15 Computerarbeitsplätzen sollte eine Client/Server-Umgebung auf Apple-Basis geschaffen werden. Zu Beginn des Projektes fanden wir bei unserem Kunden eine reine Mac-Umgebung (Mac Mini, Macbook, iMac) vor. Die Daten wurden zentral auf einem QNAP NAS gespeichert. Die Benutzer waren in einer simplen Rechtestruktur lokal auf dem QNAP NAS angelegt.

Da der Kunde eine Client/Server Software benötigte deren Serverkomponente ein Apple-Betriebssystem voraussetzt, wurde hierfür ein Mac Pro (2014) angeschafft. Über einen weiteren Mac Pro sollte mit Hilfe der OS-X-Server-App für Mavericks eine Benutzerverwaltung sowie Netzlaufwerke mit einer Berechtigungsstruktur nachgerüstet werden. Die technischen Informationen rund um die OS-X-Server-App bestätigten alle Anforderungen. Als Datenspeicher wurde neben den beiden Mac Pro zudem ein 4-Bay Thunderbolt Storage System von Apple angeschafft.

In der Praxis stellte sich die Umstellung leider problematischer dar als zunächst erwartet. Konkret ergaben sich folgende Probleme:

  • Nach dem Anlegen der Benutzer konnten sich diese nicht authentifizieren/anmelden
  • Es war möglich Freigaben anzulegen, es konnte allerdings kein Benutzer darauf zugreifen
  • Berechtigungen auf die Freigaben konnten gesetzt werden, sie wurden aber nicht übernommen

Das einzige Feature, das zuverlässig funktionierte, war der DHCP-Server. Selbst der DNS-Server funktionierte nicht wie gewünscht.

Im Apple-Support-Forum fanden sich viele Beiträge zu dieser Problematik (https://discussions.apple.com/thread/5509703?tstart=0).

Auch der Support seitens Apple und die mehrmalige Neuinstallation des kompletten Mac Pro führten nicht dazu, die gewünschten Funktionen in Betrieb nehmen zu können.

Aufgrund der beschriebenen Fehlfunktionen, wurde letztendlich auf die OS-X-Server-App verzichtet. Es wurden alle Benutzer lokal auf dem Mac Pro mit dem angeschlossenen Storage-System angelegt und die Berechtigungen mit den lokalen Benutzern gesetzt. DNS und DHCP wurden auf dem Router eingerichtet.

In der Praxis zeigte sich in der Folgezeit bisher lediglich ein erwähnenswertes Problem: Berechtigungen können zwar über die GUI in OS X für die freigegebenen Ordner vergeben werden, sie werden allerdings nicht vererbt. Möchte man dies tun, muss man mittels dem Befehl

sudo chmod +a „user:USERNAME allow list, add_file, search, add_subdirectory, delete_child, readattr, writeattr, readextattr, writeextattr, readsecurity, file_inherit, directory_inherit“ /Volumes/PromiseRAID/Freigabe

die Berechtigungen über das Terminal für jede Freigabe / jeden Benutzer händisch setzen. Bei entsprechender Menge der vorhandenen User oder einer größeren Komplexität, handelt es sich hierbei um einen nicht zu unterschätzenden Aufwand.

[Projekt] Migration einer ISDN-Telefonanlage auf Voice over IP (VoIP)

Screenshot der Swyx-Software

Im heutigen Blogeintrag behandeln wir den Abschied von klassischer ISDN-Telefonie und den damit einhergehenden Umstieg auf IP-Telefonie.

Es handelt sich um folgendes Szenario, das wir bei einem Kunden vorgefunden haben:

  • ISDN-Telefonanlage eines französischen Herstellers mit 8 ISDN-Anschlüssen
  • 50 Systemtelefone
  • Mehrere tragbare DECT-Telefone
  • Ein Faxgerät
  • Anbindung einer Türsprechanlage per a/b Schnittstelle
  • Diverse Gruppenruffunktionen
  • Anrufweiterschaltungen und individuelle Wartemusik
  • spezielle Anrufbeantworter an verschiedenen Tagen bzw. verschiedenen Uhrzeiten

In der Planungsphase wurden Angebote und Präsentationen verschiedener Telefon- und VoIP-Anbieter eingeholt, letztlich fiel die Entscheidung auf ein Produkt, das seit einigen Jahren bei einem weiteren Kunden erfolgreich im Einsatz ist. Es handelt sich um eine IP-Kommunikationslösung aus dem Hause Swyx.

In der Umsetzungsphase erfolgte die Grundinstallation der Software auf einem virtuellen Windows 2008 R2 Server durch die Telefongesellschaft. Darüber hinaus wurden ein ISDN-Gateway (der aktuelle Anschluss ist noch auf ISDN-Basis und wird in ein bis zwei Jahren auf IP umgestellt) und ein a/b-Gateway im Serverraum eingebaut. Es besteht die Möglichkeit einer Active Directory-Integration, die wir jedoch nicht gewählt haben, da sehr viele Telefone nicht von einer Person (die jeweils einen eigenen AD-Account hat) sondern von mehreren Personen mit gleicher Rufnummer abwechselnd genutzt werden.

Vor der Konfiguration der Telefonanlage ist es ratsam, für die Telefone feste DHCP-Adressleases im DHCP-Server zu definieren. Die Konfiguration der Telefonanlage erfolgt über eine MMC-Konsole und ist sehr übersichtlich gehalten

Zunächst wird eine Trunk-Gruppe angelegt, die die Verbindung zur „Außenwelt“ herstellt. Momentan läuft diese – wie bereits erwähnt – über den ISDN-Gateway. Sobald die Umstellung auf einen IP-basierten Anschluss abgeschlossen ist, lässt sich hier (siehe Grafik 1) eine Verbindung zum SIP-Gateway in wenigen Klicks einrichten und anschließend die alten Trunks einfach löschen. Schließlich muss nur noch der ISDN-Gateway aus dem Rack ausgebaut werden.

Danach erfolgt das Anlegen der Nutzer und der verschiedenen Gruppen, die später für Gruppenrufe usw. genutzt werden können. Es gibt eine große Bandbreite von Konfigurationsmöglichkeiten hinsichtlich Berechtigungen (bspw. darf ein Nutzer nur innerdeutsch telefonieren) und Beziehungen zwischen Benutzern. Gemäß Kundenwunsch haben wir noch einige Call-Routings definiert, die unter anderem Anrufe außerhalb der Geschäftszeiten auf die Mailbox weiterleiten oder – falls alle Anschlüsse belegt sind – diese auf eine weitere Mailbox umleiten.

Auf den Computern ist ein Softclient installiert, der angenehmes Telefonieren über das Headset möglich macht. Ein weiterer Vorteil ist die Outlook-Integration: im Client sind sämtliche Kontakte aus Outlook zu sehen. Trotz des Softclients haben wir an häufig genutzten Arbeitsplätzen auf Wunsch des Kunden einfache Telefone verteilt, die per PoE mit Strom versorgt werden.

Die analogen Mobilgeräte haben wir durch SIP-Clients auf den Smartphones ersetzt, was sich bisher in der Praxis bewährt hat.

Die Türsprechanlage war bereits über eine Doorline-a/b-Schnittstelle mit der Telefonanlage verbunden und musste lediglich an den a/b-Gateway der neuen Lösung angeschlossen werden.

Die Praxiserfahrung zeigt bisher, dass die Telefonie zuverlässig und in sehr guter Sprachqualität arbeitet. Ein weiteres nützliches Feature für die „out-of-office“-Arbeit ist die VPN-Einwahl in das Firmennetz, welche die Möglichkeit bietet, über den Softclient so zu telefonieren (d.h. mit der „normalen“ Rufnummer), als wäre man gerade an seinem Arbeitsplatz.

[Projekt] Modernisierung der kompletten WLAN-Infrastruktur eines Hotels

In der heutigen Zeit, ist ein zuverlässiges und schnelles WLAN ein wichtiger Aspekt für Gäste eines Hotels.

In Anbetracht dessen, modernisierten wir das WLAN eines Hotel-Komplexes. Dabei erstreckt sich das WLAN über mehrere Gebäude mit ca. 300 Hotelzimmern und mehreren Tagungsräumen.

Aufgrund unserer bisherigen Erfahrungen mit größeren WLAN-Installationen (>10 Access-Points), fiel die Entscheidung auf den Hersteller Ubiquiti, weil dieser alle Komponenten anbietet und somit das Risiko von Inkompatibilitäten reduziert wird.

In der Planungsphase ist es besonders wichtig, die Besonderheiten der Gebäude zu berücksichtigen. So stellen Feuerschutzwände oder dicke Betondecken- und Wände bei einer drahtlosen Vernetzung ein besonderes Hindernis dar, weil dadurch die Signale erheblich gedämpft werden. Deshalb ist es nötig, vor Ort eine sogenannte On-Site-Survey durchzuführen. Hierbei werden in einer Muster-Etage an vorher definierten Stellen Access-Points montiert und die Pegel und der Durchsatz gemessen. Danach wird die Platzierung der Access-Points so lange variiert, bis die Messwerte im optimalen Bereich liegen.

Da in unserem Fall keine baulichen Unterschiede zwischen den Stockwerken existieren, kann der Verteilungsplan der Access Points auf alle anderen Etagen übernommen werden.

In diesem Szenario bietet es sich an, die Access-Points über PoE-fähige Switches mit Strom zu versorgen. Da in unserem Fall insgesamt rund 80 Access-Points eingesetzt werden, haben wir uns für eine gemanagte Lösung über die Ubiquiti Tough-Switches entschieden. Die Controller-Software erkennt Ausfälle der Access Points und kann Informationen über mehrere Wege (E-Mail, SMS) versenden. Darüber hinaus bietet die Software weitreichende Reporting- und Monitoringfunktionen.

Das Resümee des bisherigen produktiven Einsatzes ist durchweg positiv; selbst bei voller Auslastung des Hotels und der Tagungsräume, funktioniert das WLAN stets stabil, schnell und zuverlässig.

[Projekt] Standortvernetzung per VPN

In diesem Eintrag präsentieren wir Ihnen die bei einem Kunden kürzlich durchgeführte Standortvernetzung mittels verschlüsselter VPN-Verbindungen; dadurch ist eine sichere Kommunikation bzw. Vernetzung von Außenstellen mit der Firmenzentrale möglich. Für den Benutzer sind die zugrunde liegenden Verbindungen vollkommen transparent: Es fühlt sich an, als wäre man direkt mit dem Netzwerk am Hauptstandort verbunden.

Für Außendienstmitarbeiter, Arbeiten zu Hause oder für den Zugriff aus Hotels haben wir zusätzlich die Möglichkeit implementiert, sich per VPN-Client zu verbinden und sicher auf sensible Daten zuzugreifen.

Um das Projekt umzusetzen, fiel die Wahl auf LANCOM VPN-Router (1781A) in den Niederlassungen, um den bisherigen Router in der Zentrale (1721+ VPN) zu ergänzen. Sämtliche Standorte verfügen über feste IP-Adresse und über ausreichend schnelle Internetverbindungen; die Zentrale ist redundant über VDSL und Kabel angebunden.

Nach der Vorkonfiguration der Router haben wir ein site-to-site VPN aufgebaut, welches mit modp-1024 verschlüsselt ist. Da die Niederlassungen nicht miteinander verbunden sein sollen, sondern nur sternförmig auf die Zentrale zugreifen, wurde die Option der kompletten Vernetzung nicht gewählt. Zudem wurden diverse Firewallregeln erstellt, so dass nur bestimmte Dienste (Webserver Intranet, Dateidienste, Terminaldienste, usw.) aus dem Netz der Niederlassungen genutzt werden können.

Abschließend zur Veranschaulichung eine Visio-Grafik:

Blog_2

[Projekt] Installation und Einrichtung virtuell getrennter Netzwerkhardware mit WLAN

Heute stellen wir Ihnen ein kürzlich abgeschlossenes Projekt vor. Die Anforderungen des Kunden an unsere Netzwerklösung war die komplette Einrichtung des Netzwerkes in einem Neubau. Hierbei war besonders wichtig, dass den Gästen ein Internetzugang sowohl über Kabel als auch drahtlos zur Verfügung steht. Zudem sollte das komplette Firmenareal inklusive Firmengebäude und Montagehalle abgedeckt werden (ca. 2000-2500 m²).

Wir empfahlen eine vollständige logische Trennung zwischen Büronetzwerk und Gastzugang, die über passende Hardware mit wenigen Geräten – somit kostengünstig und stromsparend – realisiert werden kann. Darüber hinaus stand die Verschlüsselung beider drahtlosen Netzwerke (WLAN) im Vordergrund.

Um diese Anforderungen umzusetzen, fiel die Wahl auf Netzwerkhardware aus dem Hause LANCOM. Wir setzten dabei folgende Komponenten ein:

  • LANCOM 831A Router
  • LANCOM GS 2326p PoE-fähiger Layer2 Switch
  • LANCOM L-321agn Access Points in hinreichender Anzahl nach WLAN-Messung des Areals

Wir haben zwei verschiedene virtuelle LANs (vLAN) definiert, zum einen ID 2 für das Büronetzwerk und zum anderen ID3 für die Gästezugriffe. Am Switch sind zwei Trunks zum Router eingerichtet, worüber am Router beide Netze per Schnittstellen-TAGs getrennt werden.

Weiter ist am Switch an einigen Ports PoE aktiv, um die Access Points mit Strom zu versorgen. Die Access Points hängen auch an Trunk-Ports und auf ihnen sind ebenfalls beide vLANs eingerichtet, um die Segmentierung an die WLAN-Endgeräte durchzureichen.

Zum Abschluss dieses Blogeintrages noch eine kleine Visio-Skizze, die den ganzen Aufbau verdeutlicht.

Zeichnung1

Bis zum nächsten Mal!