CommuniGate Pro sollte auf einem Server (oder einem Cluster aus mehreren Servern) mit dem Betriebssystem Unix, Linux, Microsoft Windows, Mac OS X oder einem anderen unterstützten Betriebssystem installiert werden.

CommuniGate Pro arbeitet sehr effizient und kann deshalb schon auf einem einfachen Server (mindestens Quadcore CPU und 4 GB RAM) mehr als 1.500 gleichzeitige Gespräche verarbeiten und 2.500 – 10.000 Accounts öffnen (die genaue Anzahl hängt vom Betriebssystem, Art der Gespräche und anderen Verbindungen ab).

Die Beispielsinstallation geschieht auf Microsoft Windows und kann einfach auf einem Laptop oder Desktop Rechner durchgeführt werden. Die Installation dauert lediglich 5-10 Minuten und erfordert etwa 100 MB Festplattenspeicherplatz.

CommuniGate Pro kann im "Community" Modus kostenlos für bis zu 5 Accounts mit allen Funktionen genutzt werden.

Ihre Wahl

Hier finden Sie die aktuellen stabile Versionen für die verschiedenen Betriebssysteme (mehr als 15 OS zur Auswahl).

Windows Installation

Der Installer ist .zip gepackt, für die Installation die installer.exe starten:

• Application Folder: Programmdateien, Einstellungen und Interface.
• Base Folder: Nutzerdaten und angepasste Einstellungen.

Bei einem Update auf eine neuere Version wird nur der "Application Folder" überschrieben.

Nach der Installation überprüfen Sie bitte ob der CommuniGate Dienst läuft.

Hauptinterface

Öffnen Sie diese URL in einem Browser:

Sie sehen jetzt die WebAdmin Oberfläche.

Der voreingestellte Administrator Account heißt "postmaster". Legen Sie beim ersten Anmelden ein Passwort fest:

Nach dem Anmelden als "postmaster" erreichen Sie die Seite „Main Settings“:

Hier können Sie die Sprache, Zeitzone und den Domain Namen festlegen. Wir empfehlen die Ansicht von "Basic" zu "Expert" zu wechseln, es können so mehr Einstellungen vorgenommen werden.

WebAdmin ist in hierarchische Reiter (Tabs)eingeteilt. Um die beschriebenen Einstellungen zu finden werden wir die Tabhierarchie angeben:

Tab1->Tab2->Tab3->«Einstellung»

Um z.B. einen Nutzer anzulegen, gehen Sie über die Tabs Users->Domains->[DomainName]->«Create Account».

Ab Version 6.1c1 gibt es eine neue Adminoberfläche „Dash“für mehr Übersicht. Um zu Dash zu wechseln gehen Sie über WebAdmin -> Settings und klicken Sie auf "Preferences" um als "Layout" die neue Dash Ansicht auszuwählen. Für die ursprünglicher Ansicht zurück zu "Basic" wechseln.

Neben WebAdmin gbt es noch 3 weiter Web Oberflächen:

• WebUser – HTML Oberfläche mit Email, Kalender und Kontakten, voreingestellt über Port 8100 erreichbar: http://localhost:8100/


• Pronto Flash – für erweiterte Funktionen wie Telefonie, IM etc: http://localhost:8100/Pronto/


• Pronto! – neue HTML5 Oberfläche mit erweiterten Funktionen: http://localhost:8100/hPronto/

Nach der Installation stehen Nutzern Funktionen wie Email, IM oder Telefonie, etc zur Verfügung. Bitte beachten Sie, dass wenn keine DNS Namen eingerichtet wurden, die IP Adressen des Servers in den Client Einstellungen eingetragen werden müssen. Auch müssen für Telefonate die vollständigen Emailadressen eingetragen werden solange keine Kurzwahlen konfiguriert wurden.

Wichtig: standardmäßig sind in Pronto! Flash alle eingehenden Anrufe deaktiviert.

Um eingehende Anrufe zu empfangen, nehmen Sie diese Einstellung vor: Settings->Dialer->Incoming Calls (Enabled).

Nutzer Accounts erstellen.

Nachdem CommuniGate Pro installiert und der „Main Domain Name“ festgelegt wurde können jetzt die Nutzer Accounts angelegt werden. Wählen Sie unter Users -> Domains Ihre Domain:

Hier sehen Sie, dass bereits zwei Accounts existieren: Postmaster (Administrator) und PBX (führt standardmäßig Telefonieanwendungen aus und speichert deren Einstellungen)

Um einen neuen Nutzer anzulegen tragen Sie den Namen ein und klicken Sie daneben auf "Create Account". Sie gelangen dann auf die Seite mit den Nutzereinstellungen, dort können Sie das Nutzerpasswort festlegen.

Nachrichten empfangen

Diese Einstellungen sind am zeitaufwändigsten da unter anderem ein effektiver SPAM Schutz eingestellt werden muss. Einerseits müssen unnötige Emails geblockt werden um einen eventuellen Filterdurchsatz zu reduzieren und die generelle Last auf dem Server zu verringern und andererseits sollen aber keine gewünschten Email verloren gehen.

DNS

Obwohl jetzt schon in den erstellten Accounts Emails empfangen werden können muss noch die IP Adresse in dem Domainteil der Empfängeradresse eingegeben werden. Dies ist sehr aufwendig weshalb alle Email Protokolle DNS nutzen.

Das Standardprotokoll für den Emailversand ist SMTP. Es kommt sowohl zwischen Servern als auch vom Client zum Server (aber nicht umgekehrt) zum Einsatz.

Wir werden hier für die Übertragung vom Client zum Server den Begriff "Senden" und vom Server zum Client den Begriff "Empfangen" verwenden (im Fall von SMTP: Clients die mit anderen Servern verbunden sind).

MX DNS Einträge sind notwendig damit dieses Protokoll funktioniert, jeder dieser Einträge beinhaltet drei Informationen:

• Email Server Name
• Priorität
• Dienst Server Name

Für jeden Server Namen muss ein A- DNS Eintrag vorhanden sein.

Der Eintrag mit der höchsten Priorität wird als Haupt-Email Server behandelt und die anderen als Backup Server.

Beispiel:

>nslookup -type=MX google.com

google.com      MX preference = 50, mail exchanger = alt4.aspmx.l.google.com
google.com      MX preference = 10, mail exchanger = aspmx.l.google.com
google.com      MX preference = 20, mail exchanger = alt1.aspmx.l.google.com
google.com      MX preference = 30, mail exchanger = alt2.aspmx.l.google.com
google.com      MX preference = 40, mail exchanger = alt3.aspmx.l.google.com

aspmx.l.google.com      internet address = 74.125.143.26
alt1.aspmx.l.google.com internet address = 173.194.64.26
alt2.aspmx.l.google.com internet address = 74.125.142.26
alt3.aspmx.l.google.com internet address = 74.125.140.26
alt4.aspmx.l.google.com internet address = 173.194.74.26

Client IP Adressen (Client IPs)

In CommuniGate Pro können Client IP Adressen festgelegt werden, die als vertrauenswürdig behandelt werden. In bestimmten Sicherheitseinstellungen können Aktionen nur für diese vertrauenswürdigen Clients festgelegt werden, oder sie können von bestimmten Aktionen ausgeschlossen werden.

In der WebAdmin Oberfläche finden sie diese Client IPs in „Address list“. Diese Daten werden auch in vielen anderen Einstellungen genutzt (Setting->Network->Client IPs):

Listeners (Server Objekte, reagieren auf festgelegte Parameter)

Jedes Protokoll, dass in CommuniGate Pro verarbeitet werden kann, hat eigene Listener. Beispielsweise für SMTP (Settings->Mail->SMTP->Receiving->«Listener»):

Jeder Listener öffnet Sockets an definierten Ports und Adressen. Dies ist nützlich falls noch ein Web Server auf dem gleichen Server wie CommuniGate Pro läuft. Der Web Server kann Port 80 auf einer IP Adresse nutzen und CommuniGate Pro kann Port 80 auf einer anderen IP Adresse nutzen.

Als Standard ist im SMTP Modul nur Port 25 gesetzt. Setzen wir noch zwei weitere Ports die benötigt werden:

In der aktuellsten Version von SMTP wird Port 25 hauptsächlich von Servern genutzt, Clients nutzen Port 587 welcher Authentifizierung erfordert (mit Befehl SMTP AUTH).

Schutz

Neben SMTP gibt es andere Protokolle für den Versand (Client zu Server) die alle mit Account Authentifizierung arbeiten. SMTP kann dies nicht zuverlässig da es entwickelt wurde um Emails von allen beliebigen Servern zu empfangen.

Aufgrund dieser Tatsache müssen Mechanismen gegen SPAM getroffen werden.

Relaying

Relaying bedeutet Befördern von "Transit-Nachrichten".

SMTP kann Nachrichten an andere Server versenden, jedoch wird empfohlen diese Funktion zu deaktivieren (außer für vertrauenswürdige Accounts). Wenn der Server sonst Nachrichten von Spammer IP Adressen weiterleitet, so wird der Administrator des empfangenden Servers den weiterleitenden Server blockieren.

Die entsprechenden Einstellungen sind voreingestellt und sollten nur mit Vorsicht geändert werden Settings->Mail->SMTP->Relaying and default settings can be used:

Do not change it without reason.

Überprüfung des Header

Beim Empfang sind die Haupteinträge des Headers MAIL FROM und RCPT TO. Hier ein Beispiel einer SMTP Session:

220 mycgpro.com ESMTP CommuniGate Pro 6.0.4 is glad to see you!
helo
250 mycgpro.com domain name should be qualified
Mail from:sender@gmail.com
250 sender@gmail.com sender accepted
rcpt to: recipient@mycgpro.com
250 recipient@mycgpro.com will leave the Internet
data:
354 Enter mail, end with "." on a line by itself
From: Name That Everybody See <tvoya@mama.com>

Tra ta ta Prishli mne deneg na telephon!
.
250 90001 message accepted for delivery

Es gibt die MAIL FROM und RCPT TO Einträge. Client übergreifend befindet sich der FROM Eintrag lediglich im Nachrichtentext (Message body), aber nicht im Header. Die meisten Header Überprüfungen (einschließlich "Remote BlackLists") arbeiten mit dem RCPT TO Eintrag im Header und überprüfen nicht den Nachrichtentext. Im MIME Format wird der Absender im "Return-path" Eintrag gespeichert.

(Hier eine Email die in einer SMTP Session im MIME Format empfangen wurde.)

Zur Überprüfung des "Return-path" vergleicht der Server den Domain-Teil der Adresse mit den DNS Einträgen. Es gibt eine noch sichere Überprüfung, das "Reverse Connect". Hier verbindet sich CommuniGate Pro mit dem Server und versucht eine Testnachricht an den speziellen "Return-path" zuzustellen.

Eine der beliebtesten "Return-path" Überprüfungen ist SPF. Diese Überprüfung benötigt TXT DNS Einträge in einem bestimmten Format, sogenannte SPF Einträge. Sie enthalten den Servernamen und eine Liste mit IP Adressen von Vertrauenswürdigen Absendern für diese Domain. Zum Beispiel:

>nslookup -type=TXT google.com
google.com      text = "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31~all"

Problematisch ist, dass nicht alle Administratoren SPF Einträge verwenden und dementsprechend nicht alle vertrauenswürdigen Absender auch so erkannt werden. In der WebAdmin Oberfläche können entsprechende Einstellungen vorgenommen werden Settings->Mail->SMTP->Receiving:

Da RBL und Blacklists gewöhnlich bekannt sind, wird hier nicht weiter darauf eingegangen.

Nachrichtenverarbeitung

Nach der Übertragung der Nachricht vom Client an den Server wird die Nachricht auf die Festplatte in den "Queue" Ordner mit einer .tmp Endung geschrieben. Sobald die Nachricht vollständig empfangen wurde ändert sich die Endung zu .msg und die Nachricht wird in die allgemeine Queue (abzuarbeitende Nachrichten) geladen.

Im Falle eines unplanmäßigen Neustarts des Servers werden die Nachrichten aus dem "Queue" Ordner mit der .msg Endung wieder in die Queue zu Verarbeitung geladen.

Queue (abzuarbeitende Nachrichten)

Module übertragen Nachrichten an die Queue zur weiteren Verarbeitung. Einmal in der Queue warten die Nachrichten auf die Übertragung an ein anderes Modul und/oder in ein Account Postfach.

Für Nachrichten in der Queue gibt es folgende Aktionen:

• Bearbeitung und Analyse der Absender Adresse.
• Anwendung von allgemeinen Server Regeln.
• Weiterleitung an eine oder mehrere logische Warteschlangen (Abhängig von den weiterverarbeitenden Modulen).
• Anwendung von Domain oder Nutzer Regeln.
• Verarbeitung in weiteren Modulen.

Router

Jede von CommuniGate Pro empfangene Email Adresse wird in dem Router Modul verarbeitet. Neben weiteren Möglichkeiten zur Routing Kontrolle (wie z.B. Regeln, Domain und Nutzer Aliases, etc) erlaubt der "Routing Table" direkten Zugriff auf die Adressverarbeitung und ist damit ein sehr wirkungsvolles Werkzeug:

Jede Zeile in dieser Tabelle entspricht diesem Format:

[relay prefix:][record type prefix:]left=right[; comment]

Mit der ersten Zeile beginnend wird jede Zeile der Tabelle verarbeitet. Wenn eine Adresse konvertiert werden kann, so wird diese unter Berücksichtigung der aktuellen Zeile konvertiert und dann vom Beginn der Tabelle an neu verarbeitet.

Standardmäßig sind die Einträge in dem Routing Table“ für alle Service Adressen des Servers vorhanden. Ein Eintrag kann für drei verschiedene Funktionen stehen und sollte entsprechend gekennzeichnet sein: «Mail», «Access» und «Signal».

Es gibt noch eine weiteren Typen : "Relay".Wenn ein Eintrag dieses Types für alle Empfänger vorhanden ist, dann wird die Nachricht mit einem bestimmten Merkmal versehen und wird unabhängig von der Vertrauenswürdigkeit des Absenders verschickt. Dieser Eintrag ermöglicht den Missbrauch für Spam, daher sollte er wenn vermieden werden.

Logische Warteschlangen (Logical Queues)

Es gibt vier Arten von Nachrichten Warteschlangen: an andere SMTP Server (SMTP), an lokale Mailboxen (LOCAL), and Drittanbieter Software (PIPE) und an Mailing Listen (LIST).

Jede dieser Warteschlangen enthält weitere Warteschlangen. Z.B. gibt es SMTP Wartschlangen für heden Domain Empfänger und es git LOCAL Warteschlangen für jeden Account. Dies ermöglicht das Hinzufügen von vielen Nachrichten auf einmal mit nur einer Verbindung oder einem Mailbox Aufruf.

Regeln (Rules)

Regeln werden in zwei Durchgängen verarbeitet. Zuerst die Server Regeln für alle Nachrichten (bevor Sie zur Warteschlange hinzugefügt werden) und zweitens die Domain und Nutzer Regeln, aber nur für Nachrichten in LOCAL Warteschlangen. In Bezug auf die interne Verarbeitung verhalten sich Domain Regeln wie Nutzer Regeln, aber sie werden auf alle Accounts in der Domain angewandt.

Aufgrund dieses Regelsystems können Domain und Nutzer Regeln nur für eingehende Nachrichten angewandt werden (ausgehende Nachrichten gehen nicht durch die LOCAL Warteschlange). Für ausgehende Nachrichten müssen daher Server Regeln bestimmt werden.

Mit der Account Mailbox verbinden

Wie für den Nachrichtenversand gibt es auch viele Protokolle um Daten von der Mailbox vom Server abzurufen (POP, IMAP, XIMSS, http (AirSync, WebUser), etc). Aber die Verbindung zur Mailbox bedeutet fast immer auch Authentifizierung.

In diesem Abschnitt sind keine besonderen Einstellungen vorzunehmen. Die Standardeinstellungen sollten die korrekte Authentifizierung ermöglichen.

Es wird empfohlen den vollständigen Namen in den Client Einstellungen zu verwenden, inkl. Domain Namen. Sollte der Client, wie MS Outlook den Domain Namen nach dem "@" abtrennen, so benutzen Sie stattdessen "%".

CommuniGate Pro mit PSTN Gateways und SIP Anbietern verbinden.

Analoge Telefone sind noch immer weit verbreitet, unabhängig von der wachsenden IP basierten Telefonie. Daher ist es notwendig zu wissen wie SIP/PBX mit PSTN Anlagen verbunden werden.

PSTN Gateways sind normalerweise gewöhnliche SIP Anlagen, aber aufgrund von bestimmten Eigenheiten der analogen Leitungen kann es zu folgenden Problemen kommen:

• Altes E.163 Format (z.B. +123456789) wird im PSTN Netz genutzt anstatt "account@domain" bei SIP
• Ausgehende Gespräche benötigen Authentifizierung
• Nicht alle Gateways unterstützen Call Transferring (Anrufübergabe)
• Einige PSTN Gateways und SIP Anbieter arbeiten mit separaten SIP Anlagen und benötigen REGISTER Anfragen um Anrufe an diese Anlage zu übertragen

Um diese Probleme zu umgehen nutzt CommuniGate Pro zwei PBW Anwendungen für ein- und ausgehende Gespräöche von/zu Gateways – "gatewaycaller" und "gatewayincoming". Daneben gibt es noch die bekannte "pbx" Anwendung um Telefonate aus PSTN Netzen zu empfangen, sie unterstützt "Auto-Secretary".

Die PBX Anwendung in CommuniGate Pro ein Programm in CG/PL Sprache und kann als B2BUA (back to back user agent) genutzt werden. Standardprogrammen mit Open Source könne hier gefunden werden: Users->PBX:

Ein gängiger Weg um Anwendungen zu starten ist das Transferieren von „Signal“ über eine Regel oder den Routing Table an eine Adresse wie "appName#account@domain" (z.B. SIP INVITE).

Anrufe von PSTN Gateways empfangen

Großteil moderner Gateways kann konfiguriert werden um eingehende Anrufe and die SIP Anlage (CommuniGate Pro) weiterzuleiten. Für das interne weiterleiten nutzt CommuniGate Pro den Routing Table: Settings->Router

Beispielsweise kommt ein Anruf von einem Gateway mit dem SIP Feld To: +74951234567@gateway.company.dom an (gateway.company.dom ist eine Fake Domain welche nur für Routing der Calls vom Gateway genutzt wird). Folgender Eintrag im Routing Table transferiert den Anruf zu dem Sprach Menü des "Auto Secretary":

<+74951234567@gateway.company.dom> = pbx#pbx@localhost

Manche Gateways haben eine andere Methode um Anrufe von PSTN Netzen zu empfangen. Beim Anruf von PSTN kann der Anrufer auf ein Signal eine weitere Nummer eingeben um verbunden zu werden.

Natürlich ist so eine Funktion nicht nötig wenn ein IVR vorhanden ist und sollte deaktiviert werden.

Trotzdem gibt es eine sinnvolle Einstellung. Feld "To:":

nnn@gateway.company.dom wobei "nnn" der gewählten Nummer entspricht

;calls addressed on number (3 digits)@gateway.company.dom going to gatewayincoming, 
;digits sent to application as parameter
<(3d)@gateway.company.dom> = gatewayincoming{*}#pbx@localhost
;all the other calls goes to IVR
<*@gateway.company.dom> = pbx#pbx@localhost

Anrufe vom SIP Anbieter empfangen

SIP Anbieter und manche alte/einfache PSTN Gateways erfordern eine SIP Registrierung um SIP Geräte anzurufen. In diesem Fall muss in CommuniGate Pro ein Account festgelegt werden der diese Anrufe empfängt (gewöhnlich der „pbx“ Account, da alle für diesen eingehenden Anruf zum IVR geleitet werden). Daher muss ein RSIP festgelegt werden:

RSIP Einstellungen sind die gleichen wie für einen normalen SIP Client.

Ausgehende Gespräche

Routing für ausgehende Gespräche kann sehr kompliziert werden. Hier ein einfaches Besispiel:

• Wenn die Nummer mit 7 beginnt und 11 Stellen hat, so soll sie and PSTN Gateway 10.1.1.1 geleitet werden
• Beginnt die Nummer mit einer 1 und hat 11 Stellen, so soll sie an (Fake) SIP Anbieter sip.net geleitet werden
• All Dienste erfordern Authentifizierung

Zuerst sollten die Einstellungen für die Authentifizierung für beide Gateways und alle Accounts auf dem Server vorgenommen werden:

Jede Einstellung wird nach Gatewaynamen abgespeichert, da wir mehr als ein Gateway haben. "$" im CallerID Feld wird im Account Namen gesetzt.

Einträge im Routing Table mit Authentifizierung und den genannten Parametern sehen wie folgt aus:

Signal:<7(10d)@*>=gatewaycaller{+7*,gwru}#pbx
Signal:<1(10d)@*>=gatewaycaller{+1*,gwus}#pbx

Die Verarbeitung der Regeln anhand eins Anrufes in die USA.

Die gewählte Nummer ist 1(23)456-78-90.

Wenn eine Regel zutrifft überimmt der Router die letzten 10 Stellen und fügt +1 hinzu (Nummern mit E.164 Format werden von jedem PSTN Anbieter akzeptiert) um dann die finale Nummer als ersten Parameter an die gatewaycaller Anwedung zu schicken.

Danach sucht die gatewaycaller Anwendung Parameter mit dem Schlüssel "gwus" in den Anrufer Einstellungen, welcher als zweite Information übertragen wurde.

PSTN Einstellungen als Account Einstellungen zu speichern erlaubt einerseits die Einstellungen für alle Accounts einfach zu ändern aber auch individuell Gateways für jeden Nutzer.

Media Proxy Einstellugen

Für den Fall, dass Protokoll für den Datenaustausch nicht direkt zwischen Geräten funktioniert, so kann der CommuniGate Pro Server als Proxy für diese Geräte fungieren. Wenn beispielsweise Client oder Server eine NAT Verbindung haben oder Media Daten zwischen IPv4 und IPv6 Netzwerken bewegt werden, so erstellt CommuniGate Pro einen Media Proxy – einen separaten Port um Daten vom LAN Client an das Remote System im Internet zu übertragen, und umgekehrt. Geräte sind in diesem Fall also nicht direkt verbunden sondern durch das Media Proxy.

Der Einsatz von Media Proxies kann Probleme verursachen, wie z.B. einseitiger oder auch kompletter Tonausfall trotz erfolgreicher Verbindung. Folgende Einstellungen sollten bei auftretenden Problemen geprüft werden:

1. Unter Settings: Settings->Network->LAN die korrekte IPv4 oder IPv6 WAN und LAN Server Adresse eintragen.

2. In der Firewall die TCP und UDP Ports freigeben, die in den "Port allocation" Feldern angegeben sind. Diese Ports werden für das Media Proxy genutzt. Stellen Sie sicher, dass die Firewall die Ports 1:1 übernimmt, anders ausgedrückt, dass die Port Adresse dieselbe ist, ob von außerhalb nach innerhalb oder von innerhalb nach außerhalb transferiert wird.

Sollten Sie Schwierigkeiten bei der Konfiguration haben, so helfen wir Ihnen gerne unter support@communigate.ru weiter (vorzugsweise auf Englisch).