VoIP-TK-Anlagen auf Basis von Open Source (PDF

Fachzeitschrift
für
InformationsundKommunikationstechn
Voice over IP
VoIP-TK-Anlagen auf Basis von
Open Source
Jan Schumacher • Diederich Wermser
Die fortschreitende Verbreitung von VoIP (Voice over IP)
und die damit verbundenen Vorteile, wie z. B. eine einfache
Vernetzung von verteilten VoIP-TK-Anlagen über mehrere
Standorte hinweg oder die leichte Integrierbarkeit in andere
Anwendungen wie z. B. Groupware, führen dazu, dass immer
mehr Unternehmen sich für eine hybride oder eine reine
VoIP-Nebenstellenanlage entscheiden.
Hybride Nebenstellenanlagen können
sowohl VoIP-Telefone als auch die Telefone und Amtsleitungen der „herkömmlichen“ Techniken (ISDN, a/b) anbinden.
Hierfür werden entweder in der PBX
(TK-Anlage) eingebaute Schnittstellenkarten oder getrennte Gateways benutzt.
Die Gateway-Lösung hat den Vorteil,
dass sie besser skalierbar ist und sich
durch eine geschickte Verteilung lokale
„Breakout“-Möglichkeiten in das öffentliche ISDN realisieren lassen. Die Gateways werden üblicherweise über IP und
darauf aufbauend SIP (Session Initiation
Protocol [1]) für die Zeichengabe und
RTP für die Nutzdaten mit der PBX verbunden. Durch die IP-Anbindung können die Gateways redundant ausgelegt
werden.
Prinzipiell gibt es zwei alternative
Architekturen von hybriden TK-Anlagen.
PBX mit TDM-Kern sind kanalvermit-
übrige
Anbieter
4,22 Mio.
Open Source
2,85 Mio.
Nortel
2,63 Mio.
NEC
1,22 Mio.
Mitel
1,22 Mio.
Avaya
1,75 Mio.
Cisco
1,99 Mio.
Bild 1. Verteilung der Marktanteile 2008
in Nordamerika im TK-Bereich (Quelle:
Digium/Eastern Management Group)
24
telnde Anlagen, die standardmäßig mit
ISDN- bzw. analogen a/b-Schnittstellen
ausgestattet sind. Sofern sie keine VoIPUnterstützung bieten, werden VoIP-Endgeräte und -Anschlüsse per VoIP-Gateways eingebunden. Unterstützen die
TK-Anlagen VoIP, haben sie auf der
VoIP-Seite eine B2BUA-Architektur
(Back-to-Back User Agent). Das bedeutet,
dass die angeschlossenen Endgeräte nicht
unterscheiden, ob sie mit einer PBX,
einem VoIP-Anbieter oder einem anderen Endgerät sprechen. Die Zeichengabe
wird in der TK-Anlage terminiert.
Hybride TK-Anlagen mit VoIP-Kern
haben eine dem SIP entsprechende ProxyArchitektur, in der nur die Zeichengabe
(SIP) durch den PBX-Kern geht und
standardmäßig die Nutzdaten (RTP) direkt zwischen den Endgeräten bzw. zwischen Endgerät und dem Mediaserver
ausgetauscht werden. Mediaserver können einerseits Gateways in andere Netz
sein, anderseits können sie auch komplexe Ruffunktionen bereitstellen, z. B.
Mehrteilnehmerkonferenzen oder automatische Rufverteilung (ACD, Automatic Call Distribution).
TK-Anlagen mit VoIP-Kern können
aufgrund ihrer Architektur eine Hochverfügbarkeit gewährleisten, da die Nutzdaten (RTP) direkt zwischen den Endgeräten ausgetauscht werden; lediglich
die Zeichengabe läuft über die PBX. Dies
entspricht dem eigentlichen Konzept
von SIP [2]. Telefoniefunktionen, wie
beispielsweise IVR (Interactive Voice
Response) oder Managed Conference,
werden durch „Application Server“, die
auf der gleichen oder auf zusätzlicher
Hardware laufen, realisiert.
N90735Zst ntz 7-8 2009 Schumacher Seite 24
Open-Source-Software
Open-Source-Lösungen haben sich in
vielen kommerziellen Bereichen, etwa
bei Web-Servern, E-Mail-Servern und
Betriebssystemen, bereits durchgesetzt.
Dieser Trend setzt sich nun in der Telefonie fort, Bild 1.
Der große Vorteil einer Open-SourceVoIP-PBX liegt einerseits darin, dass
keine Lizenzkosten anfallen, anderseits
bieten solche Lösungen viele offene,
standardisierte Schnittstellen, die eine
einfache funktionale Integration in beim
Kunden vorhandene IT-Anwendungen
wie z. B. CRM- und Groupware-Systeme
ermöglichen. Darüber hinaus haben OpenSource-Systeme eine „Community“,
Auf einen Blick
Wer sich für eine VoIP-TKAnlage interessiert, steht
vor der Wahl, ob er eine
proprietäre Lösung oder
eine Open-Source-Lösung
wählen soll. Eines ist sicher: Auch Open-SourceLösungen werden inzwischen professionell unterstützt und stehen in den
Leistungsmerkmalen den
proprietären TK-Anlagen
keineswegs nach.
die bereits in der Entwicklung befindliche Systeme sehr früh in vielen Anwendungsbereichen testet. Die gefundenen Fehler können so in der weiteren
Entwicklung berücksichtigt werden.
Besonders im VoIP-Bereich, wo der
Standard für das Zeichengabeprotokoll
SIP viel Raum für divergierende Interpretationen lässt, sind Interoperabilitätsund Konformitätstests notwendig. ETSI
(European Telecommunications Standards
Institute) hat für SIP eine Testspezifikation [3, 4] veröffentlicht, die Konformitätstests, wie sie auch von IANT vorgenommen werden, spezifiziert.
Heft 7-8/2009 •
Open-Source-PBX
Asterisk
Freeswitch
SipXecs
Philosophie
Anwendung, gesteuert über Kommandozeilen mit verschiedenen Open- und
Closed-Source-Erweiterungen
Telefonieplattform, skalierbar von
einem Softphone bis hin zu einer TKAnlage
modulare TK-Anlage mit unabhängigen
Serverkomponenten wie Konfigurationsoder Mediaserver
Architektur
monolithische Architektur, Schnittstellenkarten zum Anschluss an ISDN- und
analoge Leitungen
Softswitch mit ladbaren Modulen für
TK-Anlagen-Merkmalen wie Voice-Mail
vollkommen verteiltes System; die verteilte Architektur erlaubt Lastverteilung,
Skalierbarkeit und Umschalten im Fehlerfall;
aus Nutzersicht ist es „ein großes
System“
Hauptunterstützer
Digium
–
Pingtel
Konfiguration
mit Textdateien
mit XML-Dateien
Datenbank mit Web-GUI
Leistungsaspekte
Nutzdaten und Zeichengabe laufen normalerweise durch die TK-Anlage
Nutzdaten und Zeichengabe laufen normalerweise durch die TK-Anlage
Nutzdaten und Zeichengabe verlaufen
getrennt, wie im SIP-Standard vorgesehen; das ergibt eine höhere Leistungsfähigkeit
Tabelle. Vergleich bekannter Open-Source-VoIP-TK-Anlagen
Die bekanntesten Open-Source-VoIPPBX sind Asterisk, Freeswitch und SipXecs, Bild 2. Sie unterscheiden sich vor
allem in ihrer Architektur, der Konfigurierbarkeit und in ihrer Skalierbarkeit, Tabelle.
Asterisk
Asterisk, die am weitesten verbreitete
Open-Source-VoIP-PBX, wurde 1999 von
Mark Spencer ins Leben gerufen. Heute
wird das Asterisk-Projekt hauptsächlich
von der Firma Digium gesponsert, die
Schnittstellenkarten für Asterisk herstellt. Asterisk besitzt eine monolithische
Softwarearchitektur, die im Kern TDMähnlich arbeitet. ISDN- und analoge
Leitungen (a/b) werden über Schnittstellenkarten per API wie z. B. DAHDI
(Digium Asterisk Hardware Device Interface) angeschlossen.
Durch die monolithische Softwarearchitektur lässt sich Asterisk besonders
gut kompaktifizieren. Ein Beispiel dafür ist die Askozia-PBX [5]. Sie ist eine
für Kompakt-Hardware entwickelte Asterisk-Distribution, die rd. 15 MByte Fest-
Asterisk
88 %
Freeswitch 5 %
sipX/sipXecs 4 %
Call Weaver 2 %
Yate 1 %
Bild 2. Marktanteile der bekanntesten
Open-Source-VoIP-TK-Anlagen 2008 in
Nordamerika (Quelle: Digium/Eastern
Management Group)
• Heft 7-8/2009
plattenspeicher und mindestens 64 MByte
RAM benötigt. Darüber hinaus bietet
Askozia bereits eine Web-Oberfläche
zur einfachen Konfiguration der PBX.
Solche Kompaktlösungen eignen sich
gut für den Aufbau kleiner Nebenstellenanlagen für typisch bis zu 25 Teilnehmern.
Aus der monolithischen Softwarearchitektur ergibt sich eine schlechte Skalierbarkeit der Asterisk-PBX. Ebenfalls
durch die monolithische Architektur ist
Asterisk nicht für hochverfügbare Anwendungen geeignet.
Die beispielsweise aus der Web-Server-Technik bekannten Konzepte für
Hochverfügbarkeit (HA, High Availability), wie unter anderem Hot-Standby,
sind auf VoIP bzw. auf SIP nicht anwendbar. SIP ist ein „stateful“ arbeitendes Protokoll, während z. B. HTTP „stateless“ arbeitet. Konkret heißt das, dass der
PBX immer der Status aller aktiven Gespräche bekannt sein muss.
In der Praxis macht sich das bei einem
Ausfall der Asterisk-PBX durch Abbruch aller Gespräche, gefolgt von einer
Nichterreichbarkeit der Telefone bemerkbar. Sollte bei einem Ausfall ein
weiterer Asterisk-Server zur Verfügung
stehen, z. B. als „Hot-Standby“-Server,
müssen sich erst alle Telefone an diesem
Server durch eine SIP-Registrierung
neu anmelden. Die standardmäßige Registrierungszeit beträgt 1 h. Dies bedeutet, dass alle Teilnehmer erst nach
Ablauf dieser Registrierungszeit wieder
erreichbar wären.
Freeswitch
Freeswitch ist eine Telefonieplattform,
die verschiedene Telefoniedienste vom
Softphone (Software-gestütztes „PC-
N90735Zst ntz 7-8 2009 Schumacher Seite 25
Telefon“) über Mediagateways bis hin
zu Funktionen einer Nebenstellenanlage
bereitstellt. Das heißt, dass Freeswitch
eher ein Anwendungsserver für einzelne Telefoniefunktionen als eine Nebenstellenanlage ist. Die Konfiguration ist
über XML-Dateien wie auch über Skripte
in diversen Programmiersprachen möglich. Da die Konfiguration von Freeswitch
sehr systemnah abläuft und die zurzeit
verfügbaren grafischen Konfigurations-
Abkürzungen
ACD
API
B2BUA
BHCC
CRM
CUCM
DAHDI
Automatic Call Distribution
Application programming interface
Back-to-Back User Agent
Busy Hour Call Completions
Customer Relationship Management
Cisco Unified Communications Manager
Digium Asterisk Hardware Device Interface
DBMS Database Management System
ETSI
European Telecommunications Standards Institute
HA
High Availability
HTTP
Hypertext Transfer Protocol
IMS
IP Multimedia Subsystem
IP
Internet Protocol
ISDN
Integrated Services Digital Network
IVR
Interactive Voice Response
MS OCS Microsoft Office Communications Server
NGN
Next Generation Networks
PBX
Private Branch Exchange (Nebenstellenanlage, TK-Anlage)
RTP
Real-Time Transport Protocol
SIP
Session Initiation Protocol
SQL
Structured Query Language
TDM
Time Division Multiplex
VoIP
Voice over IP
25
oberflächen nur einen kleinen Teil der
verfügbaren Funktionen abdecken, ist
Freeswitch mehr für Anwendungen als
„Application Server“ in einer PBX mit
VoIP-Kern geeignet.
Freeswitch und Asterisk sind beides
VoIP-PBX der ersten Generation. Im
Kern der beiden TK-Anlagen werden
PBX-spezifische Protokolle verwendet.
Sie arbeiten beide standardmäßig als
B2BUA und terminieren somit Zeichengabe und Nutzdaten, was die erwähnten Nachteile bedingt.
SipXecs
Der SipX Enterprise Communication
Server (SipXecs oder kurz: SipX) ist
eine VoIP-PBX der zweiten Generation,
die die dem SIP hinterliegenden Konzepte tatsächlich aufnimmt. Das Architekturkonzept von SipX ist den NGN
(Next Generation Networks) für den
Bereich der öffentlichen Netze sehr ähnlich, Bild 3. In solchen NGN werden verteilte Server für einzelne Aufgaben wie
Proxy-Funktionen (CSCF, Call Session
Control Function), Teilnehmerinformationen (HSS, Home Subscriber Server)
oder Gateway-Funktionen zu herkömmlichen Netzen (SG, Signalling Gateway;
MGCF, Media Gateway Control Function; MGW, Media Gateway) benutzt, die
untereinander über standardisierte Protokolle, insbesondere SIP, kommunizieren. Kundengruppenspezifische Dienste können über Application Server (AS)
gesteuert werden.
Die Entwicklung des SipX wurde 1999
von der Pingtel Corp. als kommerzielles
Closed-Source-Produkt gestartet. Diese
Firmenstrategie hat Pingtel jedoch Ende
Dipl.-Ing. Jan Schumacher ist
Leiter Produktentwicklung der
IANT GmbH in Wolfenbüttel.
E-Mail: [email protected]
Prof. Dr.-Ing. Diederich Wermser
ist Leiter des IKT Institut für
Kommunikationssysteme und
-technologien an der Ostfalia –
Hochschule für angewandte
Wissenschaften in Wolfenbüttel.
E-Mail: diederich.wermser
@itison-ikt.de
26
Diensteebene
Steuerungsebene
AS
AS
HSS
CSCF
MRF
SG/MGCF
Transportebene
IP mit QoS
MGW
PSTN/PLMN
unterstützende Systeme
Voice over IP
Management
Bereitstellung
Abrechnungsdaten
Nummernzuordnung
Bild 3. Schichtenarchitektur eines NGN für öffentliche Netze (IMS: IP Multimedia
Subsystem; vereinfacht) [6, 7]
2004 aufgegeben und stellte den gesamten Sourcecode von SipX der von
Pingtel mit gegründeten Non-profit-Organisation SIPfoundry zur Verfügung.
Seitdem ist SipX ein Open-SourceProjekt mit einer ständig wachsenden
Community. Durch die nahezu hundertprozentige Konformität zu den SIP-Standards und deren Erweiterungen dient
der SipXecs als Referenzimplementation
des SIP Standards [1].
Nortel bietet seit Mitte 2008 das
SCS500 (Software Communication System) als kommerzielle PBX auf SipXBasis an.
Charakteristisch für die SipX-PBX ist
der modulare Aufbau, der die Verteilung
der einzelnen Dienste der SipX-PBX auf
mehrere physikalische Server ermöglicht,
Bild 4. Die Dienste sind als getrennte
Softwareprozesse realisiert, die miteinander über standardisierte Schnittstellen bzw. Protokolle kommunizieren.
Einer der größten Vorteile gegenüber
den anderen Open-Source-TK-Anlagen
ist die enthaltene relationale Datenbank
(DBMS, Database Management System),
die alle Konfigurationsdaten, Benutzerdaten sowie die Zustände aller aktuellen Gespräche verwaltet. Dieser Aspekt
ermöglicht eine dem SIP-Standard entsprechende Hochverfügbarkeit und bietet die Möglichkeit des Lastausgleichs
zwischen mehreren physikalischen Servern. Bei einer Auslegung der PBX über
mehrere physikalische Server wird die
Datenbank repliziert. Als DBMS dient
PostgreSQL, das sich für Anwendungen
mit komplexen SQL-Operationen und
vielen Schreibzugriffen gegenüber anderen Open-Source-DBMS in den letzten Jahren etabliert hat [8].
Der Konfigurationsserver bietet eine
komfortable Web-Oberfläche, über die
nahezu alle Einstellungen für die PBX
und deren Endgeräte vorgenommen werden können. Endgeräte und Gateways
N90735Zst ntz 7-8 2009 Schumacher Seite 26
lassen sich über die Web-Oberfläche
auch „auto-provisionieren“.
Die SIP-Server wie z. B. Proxy-Server
und Registry-Server können ebenfalls
für Hochverfügbarkeit und Lastausgleich redundant auf mehreren Servern
betrieben werden. Gleiches gilt für die
Media Server, die Dienste wie Mehrteilnehmerkonferenz oder Call-Center-Anwendungen bereit stellen (ACD, Automatic Call Distribution).
Die Verwaltung und Steuerung aller
Serverprozesse bzw. -dienste wird zentral über die SipX-Web-Oberfläche vorgenommen.
SipXecs im Praxiseinsatz
Die offenen, standardisierten Schnittstellen ermöglichen eine vergleichsweise einfache Integration in Unternehmensanwendungen. Da SipX auch intern VoIP
(SIP) spricht, kann SipX zur Vernetzung
von verteilten TK-Anlagen verwendet
werden. Ebenfalls ist eine Anbindung
an VoIP-PBX von Dritten möglich, wie
z. B. CUCM (Cisco Unified Communications Manager) oder Microsoft OCS
(Office Communications Server).
Die Implementation einer SipX-PBX
benötigt im Gegensatz zu den anderen
hier betrachteten PBX-Alternativen, Asterisk und Freeswitch viel Wissen über
das Zeichengabeprotokoll SIP und dessen Funktionsweise. Um die Vorteile
einer zentralen Konfiguration (Autokonfiguration) aller Endgeräte und Gateways zu nutzen, müssen alle Protokoll-,
PBX- und benutzerspezifischen Angaben
richtig eingestellt werden. Von IANT
integrierte VoIP-PBX können, nach einer kurzen Einweisung, dann vom ITAdministrator der jeweiligen Unternehmen betreut werden.
IANT hat inzwischen bei einer Vielzahl von Kunden VoIP-PBX auf SipXBasis implementiert. Erwartungsgemäß
hat sich die Hochverfügbarkeit, Skalier-
Heft 7-8/2009 •
SipX-PBX
LDAP-Schnittstelle
TFTP-Server
FTP-Server
HTTP-Server
CSV-Import-Schnittstelle
SOAP-Schnittstelle
Konfigurationsserver
(Java)
PostgreSQLServer
SIPXCONIG.
XML-RPC-API
SIPXCALLSTATES
SIPXACD
Signalisierungs-bezogene Dienste
Registrierungs-/
Redirekt-Server
Präsenzserver
RAM-/XMLDatenbank
(C++)
(C++)
CDRProzessor
Proxy-Server
VoIP-Teilnehmer
und Gateways
(C++)
(Java)
Ablaufsteuerung
Statusserver
(C++)
(C++)
Nutzdaten-bezogene Dienste
Mediaserver
(Voicemail und Auto-Attendant)
(Java)
Konferenzserver
Rufe-HaltenServer
(Freeswitch-Package)
(C++)
Paging-Server
(Java, JainSIP-Stack)
B2BUA
(Java, JainSIP-Stack)
ACD-Server
(C++)
Konfigurationsdaten (HTTP/TFTP/FTP)
Signalisierung (Rufdaten) (SIP)
Ruf- und Nutzdaten (SIP und RTP)
SQL
Konfigurationsdateien
XML/RPC
SIP
Bild 4. SipXecs Architekturdiagramm
CPU-Nutzung
barkeit und Integrierbarkeit dieser Lösung bewährt. Ein weiterer Aspekt für
Kunden ist die mögliche sanfte Migration hin zu VoIP. Wenn der Ausbau der
bisherigen TK-Anlage nicht mehr möglich ist und sie trotzdem noch weiterbetrieben werden soll, können SipXAnlagen über Gateways mit der alten
TK-Anlage verbunden werden.
Lasttests haben gezeigt, dass bereits
zwei Server (Standard-Hardware, mitt-
30
25
20
15
10
5
0
0
lere Leistungsfähigkeit) mit Lastausgleich ausreichen, um Verkehrslasten von
über 50 000 BHCC (Busy Hour Call Completions) bzw. 14 Anrufe/s zu vermitteln. Konkret entspricht das bei zehn
Telefonaten pro Teilnehmer und Stunde
einer VoIP-TK-Anlage mit 5 000 Teilnehmern. Sollten selbst diese zulässigen
Anrufaufkommen bzw. Teilnehmerzahlen nicht ausreichen, setzt IANT entweder auf leistungsfähigere Hardware oder
CPU-Nutzung
(Master-Server)
10 000
CPU-Nutzung
(verteilter Server)
20 000
30 000
40 000
50 000
60 000
Busy hour call completion (BHCC)
Bild 5. Lasttest einer SipX-PBX mit Lastausgleich über zwei Server
• Heft 7-8/2009
N90735Zst ntz 7-8 2009 Schumacher Seite 27
installiert einzelne logische Serverkomponenten auf getrennter Hardware.
Literatur
[1] IETF RFC 3261
[2] Ahson, S.; Ilyas, M.: SIP Handbook, CRC
Press, Boca Raton, 2008
[3] ETSI TS 102 027
[4] Bormann, M.; Wermser, D.; Patz, R.: Conformance Testing of Complex Services Exemplified with the IMS’ Presence Service.
Angenommen für: IEEE Conf. on Next Generation Mobile Applications, Services and
Technologies, Cardiff, September 2009
[5] www.askozia.de
[6] Wermser, D. u. a.: Adaptive Mobile Multimedia-Dienste für das zukünftige All-IP
UMTS. Proc. ITG-Fachtagung „Ambient
Intelligence“, VDE Kongress 2004. Berlin
· Offenbach: VDE VERLAG, 2004
[7] Jusek, A.; Hans, M.; Kowalewski, F.; Wermser, D.: SIP-basierte Dienstentwicklung für
das IMS CN (UMTS Release 5). Proc. 9. VDE/
ITG-Fachtagung: Mobilfunk – Stand der
Technik und Zukunftsperspektiven. Berlin ·
Offenbach: VDE VERLAG, 2004.
[8] http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL: Comparing_Reliability_and_Speed_in_2007
[9] Trick, U.; Weber, F.: SIP, TCP/IP und Telekommunikationsnetze. 4. Aufl., München:
Oldenbourg, 2009

27