Callmanager

Cisco Unified Communications Manager (Callmanager)
Basisdaten
Entwickler	Cisco Systems, Inc.
Aktuelle Version	15.0 (16. Oktober 2023)
Betriebssystem	Linux
Kategorie	VoIP (Software)
Lizenz	proprietär
deutschsprachig	ja
Cisco Unified Communications Manager

Der Cisco Unified Communications Manager (Callmanager) (kurz: CUCM) ist eine Software zur Steuerung und Vermittlung von Telefonsystemen, die auf dem Internet Protocol basieren. Ein derartiges System wird auch als IP-Telefonie-Lösung oder VoIP-System bezeichnet. Der CallManager-Server übernimmt wesentliche Funktionen einer klassischen Telefonanlage und integriert zunehmend Video, Mobility, CTI- und Collaboration-Anwendungen. Bei anderen Herstellern findet man häufig den Begriff Soft-PBX.

Im Jahr 1994 wurde auf HP-UX der „Multimedia Manager 1.0“ veröffentlicht, der der Vermittlung von Videotelefonaten diente. Nach der Portierung auf Windows NT 3.51 und der Umbenennung in „Selsius Callmanager“ wurde der Softswitch für die Vermittlung von Voice-only-Gesprächen optimiert. Die Firma „Selsius“ wurde 1998 von Cisco Systems aufgekauft. Das dann nochmals umbenannte Produkt „CallManager“ wurde forthin als Cisco CallManager verkauft. Am 6. März 2006 wurde Cisco CallManager in Cisco Unified CallManager umbenannt. Die im März 2007 erschienene Version 6 der IP-PBX wurde in Cisco Unified Communications Manager umbenannt. Ein seitdem auch erhältlicher Abkömmling davon ist der Cisco Unified CallManager Business Edition, der zusätzlich zu den bekannten Services noch Unified Messaging auf einem Server, unter einer Oberfläche bedienbar, vereint. Hierfür ist ein spezieller Server, der MCS7828, nötig.

Der CUCM steuert alle notwendigen Komponenten und Funktionen einer IP-Telefonie-Anlage (VoIP). Zu den Komponenten gehören im Wesentlichen IP-Telefone, Voice-Gateways, Applikationsserver und Konferenzbrücken. Alle Einstellungen, Betriebszustände und Auswertungen werden vom CUCM in einer Informix Datenbank gespeichert. Mehrere CUCM können zu einer CUCM-Gruppe (Cluster) zusammengeschaltet werden, um die Betriebssicherheit zu erhöhen, einzelne CUCM für spezielle Aufgaben zu separieren (TFTP-Server) und/oder die Leistungsfähigkeit zu erhöhen. In einem Cluster werden Konfigurationsänderungen grundsätzlich nur auf einem CUCM durchgeführt. Die (geänderten) Konfigurationsinformationen dieser Datenbank werden regelmäßig zu den restlichen CUCM im Cluster repliziert. Dieser CUCM wird als Publisher, die anderen CUCM als Subscriber (Teilnehmer) bezeichnet.

• Skalierbarkeit:
  • Bis zu 10.000 Nutzer pro Server
  • Bis zu neun Server pro Cluster (ein Publisher + acht Subscriber = 80.000 Nutzer/Cluster)
  • Verwaltung von über 1.000.000 Teilnehmern an über 100 Standorten bei Vernetzung mehrerer Cluster^[1]
• Systemanforderungen:
  • Virtueller Server (VMware vSphere ESXi 5.0 U1, 5.1, 5.5, 6.0) auf Cisco UCS Blade Center als Tested Reference Configuration oder "specs-based" Hardware anderer Hersteller

Die Konfiguration des CUCM erfolgt primär über eine grafische Benutzeroberfläche. Als Browser wird der Microsoft Internet Explorer (ab Version 5.x) und Mozilla Firefox unterstützt. Für umfangreiche Importe, Exporte und Änderungen steht das Bulk Administration Tool (BAT) zur Verfügung, ein Microsoft-Excel-Template, um z. B. eine Vielzahl von Benutzer- oder Rufnummerdaten einzuspielen oder zu ändern. Neben der administrativen GUI können Benutzer ein personalisiertes Interface nutzen, um z. B. persönliche Telefonbücher oder Rufumleitungen zu pflegen.

Ab CUCM Version 5.x ist der Zugriff auf das Betriebssystem (Red Hat Linux) oder die Datenbank (Informix) grundsätzlich nicht mehr möglich. Es existiert ein vereinfachtes Command Line Interface (CLI) mit eingeschränkten Befehlssatz zur Störungsbearbeitung oder dem Abfragen von System- und Datenbankinformationen.

Der Cisco Unified Communications Manager (CUCM) lässt sich auch durch Provisioning-Systeme, wie zum Beispiel dem Cisco Unified Provisioning Manager (CUPM) oder Produkten von Drittherstellern, wie zum Beispiel dem Telephone Interface Communications Manager (TiM), bedienen. Diese Programme erleichtern und automatisieren wiederkehrende Aufgaben. Provisioning-Systeme nutzen die Extensible Markup Language XML-basierte Application Programming Interface (API) des CUCM.

Der (Windows-basierte) Callmanager 4 bot neben einem gehärteten System, https (Webzugriff), SLDAP (Secure LDAP, oder LDAP via SSL, auch „LDAPS“ genannt), Zertifikats-basiertem TLS und SRTP zu Telefonen und MGCP-Gateways später dann auch SRTP für H.323-Gateways und SRTP-Unterstützung bei der Fall-Back-Telefonie.

Im Unified Callmanager 5 wurden diese Funktionen übernommen und erweitert. So sind einige Sicherheitsmerkmale im Hinblick auf die SIP-Terminals und auf die Appliance-Plattform hinzugekommen.

Ab Version 5 wird als Betriebssystem Red Hat Enterprise Linux verwendet. Damit einhergehend sind Aspekte der OS-Härtung (Gastkonten, Abschalten ungenutzter Dienste, …), das Konzept des „Least Privilege“ und die Security Passphrase (mit Überprüfung der Komplexität, …) adressiert worden. Ein direkter Root-Zugriff des Anwenders/Administrators auf das Betriebssystem mit Red Hat Linux-Werkzeugen (Shell etc.) ist nicht gestattet. Dem Administrator steht für Basisdienste eine proprietäre Kommandozeile (CLI) zur Verfügung. Die überwiegende Konfiguration erfolgt mit einem Web Browser über Webseiten.

Als Datenbankmanagementsystem (DBMS) wird Informix von IBM eingesetzt.

Da aber auf dem CUCM auch keine Applikation von einer Shell, einem Dateisystem oder der Konsole aus gestartet werden kann, die Netzwerkzugriff hat, sind Virus- und Wurmangriffe signifikant erschwert. Es gibt einen dedizierten Mechanismus, der es dem Cisco TAC für Trouble Shooting Arbeiten ermöglicht, einen privilegierten Remote Access Account zu erstellen. Hierfür wird durch den Benutzer ein CLI-Kommando ausgeführt, das ein zeitlich eng begrenztes, serverspezifisches Konto kreiert, welches dann vom Cisco TAC genutzt werden kann.

Früher zugängliche Dienste wie DHCP, DNS, PING, Logdatei-Zugang etc. sind nun nur noch über das GUI via https oder das CLI via SSH zugänglich. Die Images für den Unified Callmanager sind digital signiert. Dies stellt sicher, dass bei Updates nur Images von Cisco, die nicht verändert wurden, auf dem Unified Callmanager installiert werden können. Der CCM5/6 benutzt eine dynamische Firewall, die den Intra-Cluster-Verkehr ausschließlich auf bekannte Geräte limitiert. Daher muss bei einer Installation (anders als noch beim CCM4) auch erst der Publisher komplett laufen, bevor dem Cluster weitere Server hinzugefügt werden können. Die Interfaces des CCM5/6 sind bis auf wenige Ausnahmen durch Verschlüsselung gesichert (HTTPS, SLDAP, SSH, SFTP, SNMPv3). Web-Applikationen sind speziell gesichert (30 min-Auto-Logoff bei Untätigkeit, …) Die sicherheitsrelevanten Logdateien (Security/Event/CSA-Agent) sind nur durch das „Real-Time-Monitoring-Tool“ (RTMT), welches ausschließlich via SSH mit dem CCM5/6 kommuniziert, abrufbar. SFTP ist eine Alternative hierzu.

In der Pre-CCM5/6-Ära war es möglich, den CSA als managed CSA zu installieren. Da hierfür der Client von der Management Konsole kompiliert wird, unterstützten die CCM5/6 diese Variante nicht mehr. Dies geschieht deshalb, damit die Policy und der Public Key der Management Konsole in das Image des Clients eingefügt werden können. Die neueren CallManager akzeptieren ausschließlich signierte Images, wodurch nur die durch Cisco direkt bereitgestellten COP-Dateien für Updates und Policies des CSA zur Verfügung stehen. Gleichzeitig werden von Cisco speziell optimierte Policys designed, deren Anwendung Fehlkonfigurationen durch die Administratoren vermeidet und deren Arbeit vereinfacht.

Die neueren Cisco Unified CallManger unterstützen nur authentifizierte oder authentifizierte und gleichzeitig verschlüsselte IPSec-Verbindungen zu Remote-Geräten (Pre Shared Keys oder Zertifikate). Das gilt für Gateways (MGCP und H.323) wie auch für Inter Cluster Trunks. Entsprechende Kommandos sind sowohl auf der CLI wie auch im GUI vorhanden. So können mit ihrer Hilfe Zertifikate gemanagt, „eigene Zertifikate“ angelegt oder auch „fremde Zertifikate“ eingepflegt und externe Certificate Authority (CA) angelegt werden. Das noch im Unified Callmanager 4 genutzte „Simple Certificate Enrolment Protocol“ (SCEP) wurde durch das CSR (Certificate Signature Request) Protokoll ergänzt, mit dem sich eine Nachfrage bei der CA, z. B. ein Zertifikat zu erzeugen, signieren lässt.

Cisco benutzt ein bidirektionales Austauschen der X.509v3-Zertifikate als Basis der beiderseitigen Vertrauensbeziehung. Eine CTL-Datei (Certificate Trust List) wird erzeugt und zu den Telefonen übertragen, in dem die Zertifikate und eine Liste der vertrauenswürdigen Geräte enthalten ist. Beispielsweise der TFTP-Dienst ist hierin enthalten, wie auch die CAPF-Server. Die Telefone müssen aber auch die Zertifikate der eTokens kennen, die die Zertifikate mitbringen, mit denen das CTL-Datei selbst vom Administrator signiert wird. Korrespondierend müssen aber auch die Unified CallManager, TFTP-Server und diverse Services den Telefonen vertrauen können. So genannte LSCs (Locally Significant Certificates), die durch die CAPF (Certificate Authority Proxy Function) erzeugt werden (oder zur CA geroutet werden), und MSC’s (Manufacturer Signed Certificates) bilden hierfür die Grundlage. Sie werden über eine gesicherte TLS-Verbindung^[2] zum Unified Callmanager übertragen. Bei Gateways kommt IPSEC zur Sicherung zum Einsatz. Einmal authentifiziert und autorisiert, wird ein „Preshared Master Secret“ erzeugt, von dem die diversen SALT- und HMAC-Werte abgeleitet werden. Danach ist eine Vertrauensbeziehung für alle Geräte etabliert. Verschiedene Modi für den Zertifikatsaustausch sind wählbar, wie auch verschiedene Kombinationen bei der Authentifizierung. Es ist so möglich, einen matrixartig gemischten Betrieb Authentifiziert/Verschlüsselt optional/obligatorisch im Netz zu konfigurieren. Damit werden je nach eingesetzter Technik auch Mischkonstellationen umsetzbar. Das „Cisco Callmanager Capacity Tool“ ist in der Lage, Kapazitätsberechnungen auch für TLS-betriebene Telefone vorzunehmen. Generell nutzen Telefone 36 kB mehr Speicher und 3–5 % mehr CPU auf dem CCM als Telefone ohne TLS. Mit dem Unified CallManager 5.1 kam allerdings auch ein Mechanismus hinzu, der die TLS-Speicher-Allokation auslagerte und somit den gesamten Prozess noch skalierbarer gestaltete.^[3]

Ist die Sprache (besser: der Signalisierungsverkehr für Sprache) verschlüsselt, kann eine Firewall den Signalisierungsverkehr nicht mehr monitoren und dynamisch Ports öffnen/schließen oder umsetzen. Gleiches gilt für Session Border Controller. Mit dem CCM 5.1 und Cisco’s Firewall-Familie (PIX/ASA seit Version 8.0) gibt es eine spezielle Funktion, um in den Verkehr zu „horchen“, indem ein Zertifikat der Firewall in die CTL-Datei geschrieben wird. Damit wird die Firewall als vertrauenswürdig angesehen und kann als „Man in the Middle“ die TLS-Sitzung zwischen den Telefonen und dem CCM5.1+ terminieren. Gleichzeitig kann man so in großen Netzen Last vom CCM nehmen, da er die Sitzungen nicht mehr selbst terminieren muss. Das entsprechende Leistungsmerkmal nennt sich „TLS-Proxy“.

Das Trouble Shooting solcher Techniken kann sehr komplex werden. Cisco hat diverse Hilfen explizit dafür in den CCM5+ eingebaut, wie auch Schnittstellen, um Sitzungsschlüssel über gesicherte CTI-Schnittstellen im „Packet Capture Mode“ abzugreifen. Auch im Zusammenhang mit Lawful Interception („Sprachaufzeichnung“) wird dies verwendet, um berechtigten Servern Mitschneidemöglichkeiten für verschlüsselte Gespräche zu bieten.

Unified CallManagerversionen vor 4.0 hatten ein eingebautes LDAP-Verzeichnis. Mit der Version 5.0 kam eine Methode dazu, LDAP-Verzeichnisse abzufragen und die Benutzer in der internen Datenbank des Unified CallManagers (nicht etwa einem internen LDAP) zu speichern. Damit war es nun möglich, sich in externe LDAP-Verzeichnisse über zwei getrennte Prozesse zu integrieren: 1. Synchronisation, 2. Authentifikation. Eindeutige Such-Zeichenfolgen und multiple Suchinstanzen erlauben die dedizierte Extraktion nur der wirklich benötigten Benutzernamen im externen Directory. Ein Authentifizierungsprozess (genannt „Identity Management System“, IMS) bestimmt, ob Authentifizierungsnachfragen entweder durch die interne Datenbank beantwortet werden oder via SLDAP zum externen Directory weitergeleitet werden. Der Unified Callmanager 5+ kennt zwei Arten von Benutzern: „Enduser“ und „Application User“. Der Unterschied besteht darin, dass Application User immer gegen die interne Verzeichnisdatenbank authentifiziert werden, wogegen Enduser auch gegen externe LDAP-Verzeichnisse geparst werden. Vorkehrungen für die vereinfachte Integration in Directorys wie Microsofts AD, Netscape, iPlanet, SUN ONE wurden getroffen, was einer extrem vereinfachten Konfiguration bei diesen Directories bei Synchronisation, Moves Adds and Changes und der Datensicherheit bei Migrationsaufgaben und Netzproblemen zugutekommt. Viele Applikationen wie Unity, Meeting Place und IPCC integrieren sich hier auch, was der Authentifikation gegen dieselben Credentials gleichkommt und daher die Administration vereinfacht.

• Web-Browser für Administrations- und Benutzerwebseiten (Internet Explorer/Firefox/Chrome/Safari)
• Kommandozeile (VMWare Konsole oder SSH)

• Cisco Unified Communications Manager. cisco.com (englisch).
• Virtualisierung des Cisco Unified Communication Manager. cisco.com (englisch).
• Release Notes Cisco Unified Communications Manager 11. cisco.com (englisch).

1. ↑ Cisco Unified Communications Manager 6.0. (Memento vom 7. Oktober 2008 im Internet Archive) cisco.com
2. ↑ RFC: 2246 – The TLS Protocol Version 1.0. Januar 1999 (englisch).
3. ↑ RFC: 3711 – The Secure Real-time Transport Protocol (SRTP). März 2004 (englisch).