DE112016001895T5

DE112016001895T5 - Bereitstellen von Hybrid-Diensten

Info

Publication number: DE112016001895T5
Application number: DE112016001895.9T
Authority: DE
Inventors: Amy Pendleton; Brian Leipprandt
Original assignee: Shoretel Inc
Current assignee: Mitel Networks Inc Wilmington Us
Priority date: 2015-04-24
Filing date: 2016-04-22
Publication date: 2018-01-04
Also published as: GB201714688D0; WO2016172501A1; GB2553689B; US10541863B2; US20180083830A1; GB2553689A

Abstract

Eine Portalanwendungsschnittstelle kann auf gehostete Dienste, die in einem gehosteten System eines vereinigten Hybrid-Kommunikationssystems arbeiten, zugreifen und diese bereitstellen, wobei das Hybrid-System auch mindestens ein premise-basiertes System umfasst. Ein Verbindungsmanagementdienst (CMS) kann CMS-Bereitstellungsdaten in einer gehosteten Konfigurationsdatenbank des gehosteten Systems in Reaktion auf eine Benutzereingabe über die Portalanwendungsschnittstelle speichern, um eine gegebene Premise-Trunk-Gruppe des premise-basierten Systems für den Betrieb in dem Hybrid-System dazu zu konfigurieren, einen Session Border Controller dafür bereitzustellen, mindestens eine Verbindung zwischen der Premise-Trunk-Gruppe und einer gehosteten Trunk-Gruppe des gehosteten Systems basierend auf den CMS-Bereitstellungsdaten zu steuern. Der CMS kann auch die gehostete Konfigurationsdatenbank aktualisieren, um die gehostete Trunk-Gruppe zu konfigurieren und zu bewirken, dass Premise-Konfigurationsdaten für die gegebene Premise-Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten in dem Premise-System gespeichert werden.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNG
Diese Anmeldung beansprucht den Vorteil der provisorischen US-Anmeldung Nr. 62/152476, eingereicht am 24. April 2015, mit dem Titel PROVISIONING HYBRID SERVICES, die durch Bezugnahme hierin enthalten ist.
TECHNISCHES GEBIET
Diese Offenbarung betrifft im Allgemeinen das Bereitstellen von Diensten in einem hybriden Kommunikationssystem.
ALLGEMEINER STAND DER TECHNIK
Das Hybrid-Cloud-Computing betrifft eine Zusammensetzung aus einem Cloud-Netzwerk und einem privaten Firmennetzwerk, die individuelle Entitäten bleiben, doch miteinander verbunden sind und die Vorteile multipler Einsatzmodelle bieten. Eine solche
ALLGEMEINER STAND DER TECHNIK
Das Hybrid-Cloud-Computing betrifft eine Zusammensetzung aus einem Cloud-Netzwerk und einem privaten Firmennetzwerk, die individuelle Entitäten bleiben, doch miteinander verbunden sind und die Vorteile multipler Einsatzmodelle bieten. Eine solche Zusammensetzung kann die Einsatzoptionen für Cloud-Dienste erweitern, was es Organisationen im Bereich der Informationstechnologie (IT) erlaubt, Cloud-Computing-Ressourcen zu nutzen, um bestimmte Bedürfnisse zu erfüllen. Durch die Nutzung einer „Hybrid-Cloud”-Architektur sind Unternehmen und Einzelpersonen in der Lage, ein Maß an Fehlertoleranz kombiniert mit sofortiger Vor-Ort-Nutzbarkeit ohne Abhängigkeit von einer Internetverbindung zu erhalten. Die Hybrid-Cloud-Architektur erfordert sowohl On-Premise-Ressourcen als auch eine serverbasierte (entfernte) Offsite-Cloud-Infrastruktur.
KURZDARSTELLUNG
Diese Offenbarung betrifft im Allgemeinen das Bereitstellen von Diensten in einem hybriden Kommunikationssystem.
Ein Beispiel der Erfindung sieht ein computerimplementiertes Verfahren vor, das in Reaktion auf das Freigeben eines Verbindungsmanagementdienstes (CMS – Connection Management Service) eines mandantenfähigen gehosteten Systems für ein premise-basiertes System, Premise- und Nutzerkonfigurationsdaten, die mit dem premise-basierten System verknüpft sind, in einer gehosteten Konfigurationsdatenbank des gehosteten Systems speichert. Das premise-basierte System und das gehostete System definieren ein hybrides Kommunikationssystem. Das Verfahren umfasst auch das Bereitstellen des CMS in Reaktion auf eine Benutzereingabe, um Benutzer- und Ressourcenparameter für eine Premise-Trunk-Gruppe des premise-basierten Systems anzugeben, um sich mit einer gehosteten Trunk-Gruppe des gehosteten System zu verbinden, und entsprechende CMS-Bereitstellungsdaten werden in der gehosteten Konfigurationsdatenbank gespeichert. In Reaktion auf das Bereitstellen des CMS wird ein Session Border Controller dafür bereitgestellt, mindestens eine Verbindung zwischen der Premise-Trunk-Gruppe und der gehosteten Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten zu steuern, und die gehostete Konfigurationsdatenbank wird aktualisiert, um die gehostete Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten zu konfigurieren. Premise-Konfigurationsdaten für die Premise-Trunk-Gruppe werden ebenfalls in dem premise-basierten System basierend auf den CMS-Bereitstellungsdaten gespeichert.
Als weiteres Beispiel kann ein oder können mehrere maschinenlesbare Medien Anweisungen umfassen. Die Anweisungen können eine Portalanwendungsschnittstelle umfassen, um auf gehostete Dienste, die dazu konfiguriert sind, in einem gehosteten System eines vereinigten hybriden Kommunikationssystems zu arbeiten, zuzugreifen und diese bereitzustellen, wobei das Hybrid-System auch mindestens ein premise-basiertes System umfasst. Die Anweisungen können auch einen Verbindungsmanagementdienst (CMS) umfassen, um CMS-Bereitstellungsdaten in Reaktion auf eine Benutzereingabe über die Portalanwendungsschnittstelle in einer gehosteten Konfigurationsdatenbank des gehosteten System zu speichern, um eine gegebene Premise-Trunk-Gruppe des premise-basierten Systems für den Betrieb in dem Hybrid-System zu konfigurieren. Der CMS stellt ferner einen Session Border Controller bereit, um mindestens eine Verbindung zwischen der Premise-Trunk-Gruppe und einer gehosteten Trunk-Gruppe des gehosteten Systems basierend auf den CMS-Bereitstellungsdaten zu steuern. Der CMS aktualisiert auch die gehostete Konfigurationsdatenbank, um die gehostete Trunk-Gruppe zu konfigurieren und zu bewirken, dass Premise-Konfigurationsdaten für die gegebene Premise-Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten in dem Premise-System gespeichert werden.
In einem noch anderen Beispiel umfasst ein hybrides Kommunikationssystem mindestens ein premise-basiertes System, das ein Portal umfasst, um auf freigegebene gehostete Dienste, die in einem mandantenfähigen gehosteten System des vereinigten Hybrid-Kommunikationssystems arbeiten, zuzugreifen und diese bereitzustellen. Das gehostete System umfasst einen gehosteten Konfigurationsmanager, um Konfiguration und Bereitstellung der gehosteten Ressourcen in dem gehosteten System zu steuern, wobei der gehostete Konfigurationsmanager einen Verbindungsmanagementdienst (CMS) umfasst, um CMS-Bereitstellungsdaten in einer gehosteten Konfigurationsdatenbank des gehosteten Systems in Reaktion auf eine Benutzereingabe zu speichern, die über das Portal bereitgestellt wurde, um eine gegebene Premise-Trunk-Gruppe des premise-basierten Systems für den Betrieb in dem Hybrid-System zu konfigurieren. Ein Session Border Controller steuert mindestens eine Verbindung zwischen der gegebenen Premise-Trunk-Gruppe und einer gehosteten Trunk-Gruppe des gehosteten Systems basierend auf der Bereitstellung des Session Border Controllers gemäß der CMS-Bereitstellungsdaten. Der CMS aktualisiert die gehostete Konfigurationsdatenbank, um die gehostete Trunk-Gruppe zu konfigurieren und zu bewirken, dass Premise-Konfigurationsdaten für die gegebene Premise-Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten in dem Premise-System gespeichert werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 stellt ein Beispiel für ein hybrides Kommunikationssystem dar.
2 stellt ein Beispiel für ein Signalisierungsablaufdiagramm dar, das Signale zeigt, die während eines Teils eines Bereitstellungsverfahrens kommuniziert wurden.
3 stellt ein Beispiel für ein anderes Signalisierungsablaufdiagramm dar, das Signale zeigt, die während eines anderen Bereitstellungsverfahrens kommuniziert wurden.
4 stellt ein Beispiel für einen Signalisierungsablauf dar, um eine premise-seitige Ressource zu authentifizieren, um eine sichere Verbindung mit den Cloud-Ressourcen zu ermöglichen.
AUSFÜHRLICHE BESCHREIBUNG
Diese Offenbarung betrifft im Allgemeinen das Konfigurieren ausgewählter Dienste, um den Betrieb eines hybriden Kommunikationssystems zu vereinfachen. Das Hybrid-System umfasst einen Verbindungsmanagementdienst, um die Bereitstellung und Aufrechterhaltung einer dynamischen Verbindung zwischen premise-basierten Ressourcen, die sich physisch in einem oder mehreren premise-basierten Systemen befinden (hierin auch als ein privates Netzwerk bezeichnet), und gehosteten Ressourcen, die sich in einem gehosteten System befinden (hierin auch als ein mandantenfähiges cloud-basiertes System bezeichnet), zu managen. Der Managementdienst kann als Teil des gehosteten Systems implementiert sein, um Konten- und Abrechnungsfunktionen für Ressourcen, die in dem gehosteten System gehostet und betrieben werden, zu vereinfachen.
Als ein Beispiel kann nach der Registrierung des premise-basierten Systems als ein gegebener Mandant, der in dem gehosteten System für ein oder mehrere Dienste, umfassend den Management-Dienst, betrieben werden soll, und nach der Bereitstellung von Identifizierungs- und zugehörigen Authentifizierungsparametern für das premise-basierte System, eine Instanz des Verbindungsmanagementdienstes für den gegebenen Mandanten, umfassend seiner verknüpften premise-basierten Ressourcen, freigegeben werden. In Reaktion darauf können Konto- und andere premise-basierte Konfigurationsinformationen für premise-basierte Ressourcen (z. B. Benutzer, Benutzergeräte, Premise-Hardware und Premise-Software) von dem Premise-System hochgeladen und in einer Konfigurationsdatenbank des gehosteten Systems gespeichert werden. Zur Bereitstellung des Verbindungsmanagementdienstes für den gegebenen Mandanten, für den er freigegeben wurde, können premise-seitige Konfigurationsparameter in Reaktion auf eine Benutzereingabe bereitgestellt werden. Zum Beispiel können die premise-seitigen Konfigurationsparameter eine oder mehrere Trunk-Gruppen (z. B. Site, Switch und Ports) angeben und Nebenstellenbereiche für jedes des premise-basierten Systems und des gehosteten Systems definieren. Basierend auf den premise-seitigen Konfigurationsparametern und zugehörigen gehosteten Daten, können Konfigurationsdaten bereitgestellt werden, um einen Session Border Controller und entsprechende gehostete Ressourcen bereitzustellen, um dem Verbindungsmanagementdienst zu ermöglichen, den SBC und die zugeteilten gehosteten Ressourcen zu nutzen. Das premise-basierte System kann Ressourcen, die Aktivierungseinstellungsdaten identifizieren, in der Cloud empfangen, die als Teil des Hybrid-Systems für Ressourcen in dem premise-basierten System freigegeben sind. Zum Beispiel können die Ressourcen in einem Verzeichnis identifiziert werden, das einheitliche Deskriptordaten umfasst, die alle für jeden entsprechenden Benutzer verfügbaren freigegebenen Ressourcen identifizieren.
Wie hierin verwendet, kann das gehostete (z. B. Cloud) System vielfältige Hardware- und/oder Software-Ressourcen umfassen, die in einer gegebenen Cloud unterstützt werden können, umfassend zum Beispiel Server, Nebenstellenanlagen (PBXs), Router und Datenbanken. Zum Beispiel können derartige Ressourcen Prozessoren, Speicher, Server, Software, Anwendungen umfassen, die zusammenarbeiten, um Cloud-Computing-Möglichkeiten für Nutzer und premise-basierte Systeme bereitzustellen, die Cloud-Ressourcen nutzen möchten, die die bestehende Funktionalität ihres premise-basierten Systems erweitern. Beispielsweise kann daher jeder der mehreren Nutzer des Premise-Systems einzeln oder als Teil einer entsprechenden Gruppe zur Nutzung der gehosteten Ressourcen bereitgestellt werden. Wie hierin verwendet, bezieht sich ein premise-basiertes System auf ein privates Netzwerk, das von oder im Auftrag einer privaten Entität (z. B. einem Unternehmen, einer Gruppe von Nutzern oder einem anderen Dienstanbieter) verwaltet und/oder betrieben wird, die sich von der Entität unterscheidet, die das gehostete cloud-basierte System betreibt. Das premise-basierte System kann lokal an einem einzelnen Standort (Site) implementiert werden oder kann auf mehrere Standorte verteilt, doch als ein einzelnes Unternehmen betrieben werden, z. B. ein vereinigtes Kommunikationssystem (UC – Unified Communication System) des Unternehmens.
Als ein Beispiel kann ein premise-basiertes System Dienste eines cloud-basierten PBX und/oder cloud-basierten UC-Systems zu seinem Vorteil nutzen, um Nutzern oder anderen Entitäten eines premise-basierten PBX/UC-Systems zusätzliche Dienste und Ressourcen bereitzustellen. Zum Beispiel kann ein Cloud-Dienstanbieter Dienste bereitstellen, verwalten und abrechnen, die einem oder mehreren Premise-Systemen und ihren entsprechenden Nutzern bereitgestellt wurden. Bei minimalem Aufwand an Einrichtung können Nutzer oder andere Entitäten, die im Allgemeinen an der Premise verwaltet werden und dort basiert sind, den Vorteil spezieller cloud-basierter Ressourcen nutzen, für die sie autorisiert wurden. Auf diese Weise können lokale Ressourcen des premise-basierten Systems in einem gegebenen Status oder Zustand verbleiben, und Nutzer derartiger Premise-Systeme können eine Netzwerkverbindung (z. B. über eine sichere Kommunikationsverbindung) mit entfernten gehosteten Ressourcen (z. B. in eine mandantenfähige Cloud implementierte Dienste und/oder Hardware) nutzen, um nahtlos auf zusätzliche Ressourcen (z. B. Cloud-Ressourcen) zuzugreifen und diese zu nutzen. Als ein Beispiel können premise-basierte und gehostete Ressourcen Nebenstellen umfassen, wobei Nebenstellen in dem gehosteten System als Offsite-Nebenstellen bezogen auf das premise-basierte System arbeiten, und Nebenstellen in dem premise-basierten System als Offsite-Nebenstellen bezogen auf das gehostete System arbeiten. Die in dem Verzeichnis aufgeführten Nebenstellen bleiben synchronisiert, um für ihre Nutzer als Set von in dem UC-System operierenden integrierten Nebenstellen zu erscheinen.
1 stellt ein Beispiel für ein Hybrid-System 10 dar, das implementiert werden kann. Das Hybrid-System umfasst ein gehostetes System 12 und ein premise-basiertes System 14. In diesem oder anderen hierin offenbarten Beispielen kann das gehostete System 12 ein mandantenfähiges Cloud-System umfassen, das dazu konfiguriert ist, cloud-basierte Ressourcen für das premise-basierte System 14 bereitzustellen. Während in 1 ein premise-basiertes System 14 dargestellt ist, kann das Hybrid-System 10 jede beliebige Anzahl an premise-basierten Systemen unterstützen, in welchen z. B. das gehostete System ein geteiltes Set von Ressourcen bereitstellt, die mehrere verschiedene Mandanten bedienen, wie hierin offenbart.
In dem Beispiel von 1 und anderen hierin offenbarten Beispielen ist das Hybrid-System im Kontext eines Unified Communication (UC) Systems beschrieben. Die UC vereint Echtzeitkommunikationsdienste (z. B. Instant Messaging (Chat), Präsenzinformationen, Telefonie, Mobilität, Telefonkonferenzen, Kontakt-Center-Funktionen, Videokonferenzen, Datensharing, Verbindungssteuerung und Spracherkennung) mit Nicht-Echtzeitkommunikationsdiensten (z. B. integrierte Sprachnachrichten, Transkriptionsdienste, E-Mail, SMS und Fax). Man wird verstehen, dass das Hybrid-System 10 auf andere Arten von Datenverarbeitung und/oder Kommunikationssystemen anwendbar ist, bei welchen es wünschenswert ist, Ressourcen bereitzustellen und zu konfigurieren, die in einem premise-basierten System (z. B. privaten Netzwerk) arbeiten, das außerhalb des gehosteten Systems liegt, doch noch im Wesentlichen nahtlosen Zugang und Nutzung cloud-basierter Ressourcen ermöglicht.
Das premise-basierte System 14 kann einen Premise-Konfigurationsmanager 16 umfassen, der dazu konfiguriert ist, das premise-basierte System bereitzustellen. Der Konfigurationsmanager 16 kann zum Beispiel Parameter für mehrere Ressourcen 18 festlegen, die innerhalb des premise-basierten Systems arbeiten, wobei die Parameter in einer Datenbank 20 des Premise-Systems 14 gespeichert werden können. Neben den Ressource-Parametern können in einigen Beispielen andere Konfigurationsdaten in der Datenbank 20 Authentifizierungsparameter, Firewall-Einstellungen für das Anwendernetzwerk, Einstellungen für den Session Border Controller und Einstellungen für die Quality of Service (QoS) für das premise-basierte System angeben. Die Arten und der Umfang der Parameter für das premise-basierte System 14 können abhängig von den verfügbaren Merkmalen, der Ausstattung und der in dem premise-basierten System laufenden Software und den Hybrid-Ressourcen in dem gehosteten System 12 variieren, wie hierin offenbart. In einigen Beispielen hierin kann die Premise-Konfigurationsdatenbank 20 Ressourcen-Parameter in einem Verzeichnis verfügbarer Ressourcen in dem Hybrid-System speichern, ungeachtet dessen, ob es sich dabei um premise-basierte oder gehostete Ressourcen handelt.
Das premise-basierte System 14 kann vielfältige Nebenstellenanlagen(z. B., Internetprotokoll (IP) PBX)-Ressourcen zum Implementieren von Kommunikationen, umfassend einen oder mehrere Switches 22 implementieren. Jeder der Switches 22 umfasst Hardware und Software, die dazu programmiert ist, Schalt- und Routing-Funktionen für eine bestimmte Site (z. B. ein Unternehmen, das eine oder mehrere Sites (Standorte) umfassen kann) bereitzustellen. Jeder Switch 22 kann somit verschiedene in dem Premise-System 14 enthaltene Server und Gateways miteinander verbinden, zum Beispiel zum Implementieren eines schnellen, nicht-blockierenden IP und IP-Multicast-Schicht 3 Switch und Routers.
Dies steht im Gegensatz zu einem Netzbetreiber (z. B. Telefondienstanbieter), der für viele Unternehmen oder für die breite Öffentlichkeit arbeitet. Zum Beispiel kann der Switch 22 des premise-basierten Systems 14 über ein Netzwerk 24 mit einem Dienstanbieter, der in einem Telefonnetz (PSTN) 25 arbeitet, und mit Ressourcen in dem gehosteten System 12 kommunizieren. Die Switches 22 können dazu konfiguriert sein, Kommunikationsitzungen aufzubauen, die paketvermittelte Anrufe implementieren, zum Beispiel Voice over Internet Protocol (VOIP), leitungsvermittelte Anrufe oder eine Kombination aus paket- und leitungsvermittelten Kommunikationen implementieren. In einigen Beispielen können die Switches 22 SIP Trunking für VoIP Kommunikationssitzungen implementieren.
Wie erwähnt, stellt das premise-basierte System 14 ein privates Netzwerk (z. B. ein Intranet) in dem Hybrid-System 10 bereit. Zum Beispiel kann der Konfigurationsmanager 16 implementiert werden, um eine grafische Benutzerschnittstelle zu umfassen, die dazu programmiert ist, auf Funktionen und Verfahren zum Konfigurieren und Managen der verschiedenen Komponenten des premise-basierten Systems 14 zuzugreifen.
Zum Zugreifen auf eine bestimmte Funktionalität des gehosteten Systems 12 kann das Hybrid-System 10 ein Portal (z. B. Webportal) 26 umfassen, das dazu konfiguriert ist, über das Netzwerk 24 (z. B. umfassend das öffentliche Internet) auf eine Portalanwendungsschnittstelle (API) 28 zuzugreifen. Während das Portal als in dem premise-basierten System 14 arbeitend dargestellt ist, kann zum Beispiel auch über einen webbasierten Browser oder eine andere außerhalb oder in dem premise-basierten System 14 arbeitende Anwendung darauf zugegriffen werden. In dem Beispiel von 1 ist die Portal-API 28 implementiert, um auf die mit einem gehosteten Konfigurationsmanager 30 des gehosteten Systems 12 verknüpfte Funktionalität zuzugreifen. Zum Beispiel kann die Portal-API 28 ein ausgewähltes Set an Funktionen des Konfigurationsmanagers 30 darlegen, das für das premise-basierte System 14 freigegeben wurde, um einen entsprechenden Hybrid-Betrieb zwischen dem premise-basierten bzw. dem gehosteten System 14 und 12 herzustellen. Zunächst können die freigegebenen Funktionen gemäß dem Stadium des Konfigurations- und Bereitstellungsablaufprozesses variieren, wie hierin offenbart.
Die API 28 kann genutzt werden, um Benutzereigenschaften angebende Parameter und Premise-Daten zu kommunizieren und/oder gehostete Ressourcen freizugeben. Die Verbindung über das Portal 26 und die Portal-API 28 des gehosteten Systems 12 kann als ein sicheres Kommunikationsprotokoll über die Netzwerk 24-Verbindung, wie die Nutzung des Https- oder anderen Protokolls (z. B. Secure Shell Tunnel) implementiert werden. Als ein Beispiel kann als Teil eines Setup-Prozesses zum Aktivieren des Hybrid-Systems 10 das Portal 26 die Portal-API 28 nutzen, um einen verknüpften Account für das premise-basierte System 14 zu erstellen und relevante Premise-Systemparameter kommunizieren, die zwischen dem premise-basierten System und dem gehosteten System 12 synchronisiert sind. Das Host-System 12 umfasst eine gehostete Konfigurationsdatenbank 36, die Parameter und Premise-Daten für jeden der mehreren Mandanten speichern, die für die Arbeit in dem mandantenfähigen Hybrid-System 10 freigegeben sind.
Als Beispiel kann, in Reaktion auf das Erstellen eines Mandanten-Accounts über die Portal-API 28, ein Mandanten-Datensatz in der gehosteten Konfigurationsdatenbank 36 gespeichert werden. Zum Beispiel kann der Mandanten-Datensatz eine eindeutige Mandanten-ID umfassen, die für jeden entsprechenden Mandanten, umfassend das premise-basierte System 14, automatisch generiert wird. Als Teil der Ersteinrichtung kann der gehostete Konfigurationsmanager 30 eine Instanz einer Synchronisierungs-API 40 erzeugen. Eine Premise-System-Synchronisierungskomponente 42 (PREMISE SYNC) innerhalb des premise-basierten Systems kann die Premise Sync API 40 nutzen, um über das Netzwerk 24 mit dem gehosteten System zu kommunizieren. Die Kommunikation zwischen der Premise Sync-Komponente 42 und der Premise Sync API 40 kann über eine sichere Verbindung (z. B. einen Synchronisierungskanal) erfolgen, wie hierin offenbart. Der Synchronisierungskanal kann genutzt werden, um Information an das und von dem premise-basierten System als Teil eines Synchronisierungsprozesses zu kommunizieren (siehe z. B. 2).
Als Beispiel kann der Synchronisierungsprozess die Premise Sync Komponente 42 umfassen, die einen eindeutigen Identifikator aus der gehosteten Konfigurationsdatenbank 36 herauszieht und eine Liste freigegebener Dienste für das premise-basierte System 14 herauszieht. Das premise-basierte System 14 kann auch die Premise Sync Komponente 42 nutzen, um dem gehosteten Konfigurationsmanager 30 Benutzerparameter und Premise-Daten bereitzustellen. Die Parameter und Premise-Daten können Benutzerkonfigurationsdaten, wie angebende Benutzeridentifikatorprofile, wie in Tabelle 1 dargestellt, umfassen. Das premise-basierte System 14 kann auch Authentifizierungsschlüssel vorsehen, die jede beliebige Anzahl von einem oder mehreren öffentlichen Schlüsseln oder anderer Information umfassen können, um ein tokenbasiertes oder ticketbasiertes Authentifizierungssystem zum Authentifizieren von Benutzern und Ressourcen des premise-basierten Systems bei entsprechenden in dem gehosteten System 12 implementierten Diensten und Ressourcen freizugeben. Ein Beispiel dafür, wie die Authentifizierungsschlüssel generiert und dem premise-basierten System bereitgestellt werden können, ist in 4 dargestellt.

Ein Beispiel für die Konfigurationsdaten, die in den Datenbanken 20 und 36 für jeden der mehreren Nutzer gespeichert werden können, ist unten in Tabelle 1 gegeben. TABELLE 1

USERNAME	Ein Benutzeridentifikator für jeden Benutzer in einem gegebenen
GUID	Global eindeutiger Identifikator für den Benutzer sowohl in dem Premise-System als auch in dem gehosteten
DN	Eine routingfähige Verzeichnisnummer für ein Gerät, einen Benutzer oder eine
User Type	Ein Feld, um zwischen den Arten von DNs, wie einer Arbeitsgruppe und einem Benutzer, zu unterscheiden.
First Name	Vorname des Benutzers.
Last Name	Nachname des Benutzers.
User Email	Eine oder mehrere E-Mail-Adressen für den Benutzer.
Mobility Username	Benutzername (Schattenbenutzername oder Hauptbenutzername) für die Mobilgeräte des Benutzers.

Als Beispiel kann der gehostete Konfigurationsmanager 30 eine global eindeutige ID generieren, die mit der Konfigurationsinformation jedes Benutzers, z. B. in Verbindung mit der Ersteinrichtung, verknüpft ist, die in der Datenbank 36 gespeichert werden kann. Die global eindeutige ID (z. B. eine GUID) kann (zusammen mit anderen Benutzereigenschaften und zusätzlicher Konfigurationsinformation) über die Portal-API in den Premise-Konfigurationsmanager 16 hochgeladen werden. Die GUID kann über alle derartigen Kunden-Premise-Systeme in dem mandantenfähigen Hybrid-System 10 eindeutig sein. Wenn dann der Konfigurationsmanager 30 die Konfiguration in dem gehosteten System für einen gegebenen Benutzer einrichtet, hält er ein Mapping zwischen einer Identität, die in dem gehosteten System für den Premise-Benutzer hergestellt ist, und der Identität des Benutzers in dem Premise-System 14 aufrecht.
Wie hierin offenbart, kann der gehostete Konfigurationsmanager 30 auch einen Verbindungsmanagerdienst (CMS) 32 umfassen, um das Zusammenwirken unter oder zwischen den premise-basierten Ressourcen 18 und den gehosteten Ressourcen 34 bei Kommunikationssitzungen zu erleichtern. In Reaktion auf das Synchronisieren von Parametern und Daten zwischen dem premise-basierten System 14 und dem gehosteten System 12, die jeweils in der Premise-Konfigurationsdatenbank 20 und der gehosteten Konfigurationsdatenbank 36 gespeichert sind, kann der CMS 32 für das entsprechende premise-basierte System 14 freigegeben werden. Zum Beispiel werden zum Zweck des CMS 32, wie hierin offenbart, Information und Konfigurationsdaten zwischen dem premise-basierten System 14 und dem gehosteten System 12 ausgetauscht, um eine Verbindung bereitzustellen, um die Kommunikation zwischen einer Gruppe von Ressourcen, hierin als eine dem premise-basierten System entsprechende Site bezeichnet, mit einer entsprechenden Mandanten-Site innerhalb des gehosteten Systems bereitzustellen. Der CMS ermöglicht Benutzern ferner, dem premise-basierten System 14 eine oder mehrere entfernte Sites mithilfe des gehosteten Systems (z. B. der Cloud) hinzuzufügen. In dem Beispiel von 1 umfasst eine Premise-Site 44 ein oder mehrere Switches 22 und die zugehörigen Ressourcen 18. Gleichermaßen wird in dem gehosteten System 12 eine gehostete Site 46 als ein oder mehrere Switches 48 und entsprechende gehostete Ressourcen 34 umfassend identifiziert. Der CMS 32 ist somit dazu programmiert, die jeweiligen Sites 44 und 46 und zugehörige Ressourcen in jedem der jeweiligen Systeme 14 bzw. 12 zu konfigurieren und bereitzustellen, um im Wesentlichen nahtlose Verbindungen zwischen den jeweiligen Sites und unter den entsprechenden Ressourcen 18 und 34 innerhalb der jeweiligen Sites zu ermöglichen.
Um den Aufbau einer Kommunikationssitzung für Ressourcen 18 und/oder 34 entweder zwischen oder außerhalb der Sites 44 und 46 zu steuern, umfasst das Hybrid-System 10 einen Session Border Controller (SBC) 50. Der SBC 50 ist in dem Signalisierungs- und Medienpfad zwischen der Premise-Site 44 und der gehosteten Site 46 implementiert. In dem Beispiel von 1 ist der SBC 50 außerhalb des privaten Netzwerks, das dem premise-basierten System 14 entspricht, und in dem gehosteten System 12 befindlich dargestellt. Jedoch wird davon ausgegangen, dass der SBC 50 als Teil von einem oder beiden Systemen 12 oder 14 oder separat von (z. B. außerhalb) einem der Systeme implementiert werden könnte. Zum Beispiel umfasst der SBC 50 Hardware und/oder Software, die dazu programmiert ist, Signalisierungs- (z. B. gemäß einem Session Initiation Protocol (SIP)) und Medienströme, die am Einrichten, Durchführen und Abbrechen von Telefonanrufen oder anderen interaktiven Medienkommunikationen beteiligt sind, zu steuern.
Um eine Signalisierungssteuerung zum Signalisieren und Kommunizieren von Medien bereitzustellen, die von der Premise-Site 44 oder der gehosteten Site 46 stammen, nutzt der SBC 50 eine SBC-Datenbank 52, die entsprechende Konfigurationsdaten umfasst, die bereitgestellt wurden, um einen Hybrid-Betrieb zu ermöglichen. Die Konfigurationsdaten in der Datenbank 52 umfassen Daten für das Mapping von Protokollnachrichten an oder von einem der Switches 22 oder 48 in einer der jeweiligen Sites 44 und 46 an die anderen entsprechenden Switches 48 oder 22. Zum Beispiel kann das Mapping von Daten direktionale Mapping-Information umfassen, um eine einer gegebenen Nebenstelle zugewiesene GUID auf einen zu der anderen Site gehörenden entsprechenden Nebenstellenidentifikator abzubilden. Der SBC 50 kann somit einen SIP-Header von einer an eine entfernte Nebenstelle (z. B. außerhalb des premise-basierten Systems 14 befindlich) gerichteten Nachricht basierend auf den Mapping-Daten modifizieren und die modifizierte Signalnachricht an den Switch der anderen Site zur Verteilung der identifizierten Ressource senden. In Reaktion auf die Zielressource, die die Kommunikation und das Signalisieren annimmt, die zur anrufenden Ressource zurückkommuniziert wird, kann die Kommunikationssitzung zum Durchführen der Sitzung zwischen Ressourcen (z. B. Endpunktnebenstellen), die sich an der Premise-Site und der gehosteten Site befinden, verbunden werden.
Als Beispiel nutzt der Switch 22 die Premise-Konfigurationsdatenbank 20 zum Lenken einer Kommunikation von einer der Premise-Ressourcen 18 an eine andere der Premise-Ressourcen (z. B. eine gegebene Benutzernebenstelle) 18. Als Alternative oder zusätzliches Beispiel nutzt der Switch 22 die Premise-Konfigurationsdatenbank 20 zum Lenken einer Kommunikation von einer der Premise-Ressourcen 18 über den SBC 50 an eine oder mehrere entsprechende gehostete Ressourcen 34 in der gehosteten Site 46. In dem Fall, in dem die Kommunikation von einer Premise-Ressource 18 initiiert wird und an eine gehostete Ressource 34 gerichtet ist, erscheinen jedoch aus der Perspektive des Switch 22 die gehosteten Ressourcen 34 als entfernte Offsite-Nebenstellen, die als Teil des dem premise-basierten System 14 entsprechenden privaten Netzwerk arbeiten. Das heißt, aufgrund der Bereitstellung des CMS 32 weiß der Switch 22 nicht, dass sich die Ressourcen 34 in dem gehosteten System 12 befinden. Gleichermaßen kann jeder Switch 48 an der gehosteten Site 46 direkt von einer der gehosteten Ressourcen (z. B. Endpunkte) an der Site 66 mit einer oder mehreren verschiedenen gehosteten Ressourcen 34 an der gehosteten Site über eine direkte Verbindung durch den Switch basierend auf den Mapping-Daten in der gehosteten Konfigurationsdatenbank 36 kommunizieren. Zusätzlich oder alternativ kann jeder Switch 48 an der gehosteten Site 46 direkt von einer der gehosteten Ressourcen (z. B. Endpunkte) an der Site 46 mit dem SBC 50 kommunizieren, basierend auf den Mapping-Daten in der gehosteten Konfigurationsdatenbank 36, und der SBC richtet die Kommunikation an den Switch 22 basierend auf der SBC-Datenbank 52 zur Herstellung einer Verbindung mit einer oder mehreren der Premise-Ressourcen 18. Jedoch erscheinen aus der Perspektive des Switch 48, der innerhalb der gehosteten Site 46 arbeitet, die über den SBC 50 an die Ressourcen 18 in dem premise-basierten System 14 gerouteten Kommunikationen als Offsite-Nebenstellen bezogen auf die gehostete Site 46. Jeder der Switches 22, 48 kann auch Protokollnachrichten für Anrufe an und/oder von dritten Parteien (z. B. Nachrichten von einem der Switches, die nicht an Ressourcen in dem Hybrid-System 10 gerichtet sind) über das Netzwerk 24 an das PSTN 25 senden.
Um Verbindungen zwischen Ressourcen an den Premise- und gehosteten Sites 44 und 46 freizugeben, wie oben erwähnt, ist der CMS 32 entsprechend bereitgestellt. Zum Beispiel kann ein autorisierter Benutzer (z. B. ein Administrator) bestimmte Aspekte des CMS 32 bereitstellen, umfassend Teile des Premise-Systems 14 und des gehosteten Systems 12, in Reaktion auf eine Benutzereingabe mithilfe des Portals 26 zum Zugreifen auf entsprechende Funktionen, die von der Portal-API 28 dargestellt wurden. Wie erwähnt, ist der CMS 32 dazu programmiert, einen Dienst in dem gehosteten System 12 zu implementieren, der für das gegebene premise-basierte System 14 freigegeben ist, um eine oder mehrere Verbindungen zwischen der Premise-Site 44 der gehosteten Site 46 herzustellen und aufrechtzuerhalten.
Beispielsweise kann die Benutzereingabe über das Portal 26 zur Bereitstellung des CMS 32 das Erstellen einer Premise-Trunk-Gruppe umfassen, die zur Site 44 gehört. Die Trunk-Gruppe umfasst einen oder mehrere ausgewählte Switches 22 und zugehörige Ressourcen 18. Zum Beispiel kann der CMS 32 dazu programmiert sein, eine entsprechende Partition (z. B. innerhalb eines gegebenen Clusters) des gehosteten Systems 12 anzugeben, die mit der Mandanten-ID verknüpft ist, die für das spezifische premise-basierte System 14 generiert wurde. Für die entsprechende Partition, die innerhalb des gehosteten Systems 12, das mit dem Premise-System (z. B. über eine Mandanten-ID) verknüpft ist, erzeugt wurde, können Benutzereingaben über das Portal 26 und die API 28 ferner eine oder mehrere Premise-Trunk-Gruppen (die der Site 44 entsprechen) innerhalb des premise-basierten Systems 14 programmiert werden, die über den SBC 50 mit der entsprechenden gehosteten Site 46 zusammenwirken sollen.
Das Premise-System 14 kann eine oder mehrere Sites umfassen; in einigen Beispielen jedoch wird beim Bereitstellen des CMS 32 nur eine Premise-Site 44 als eine „CMS-Site” zum Zwecke des Verbindens mit dem gehosteten System 12 in dem Hybrid-System 10 hergestellt.
Als Teil eines Bereitstellungsarbeitsablaufs kann zum Beispiel die gehostete Konfigurationsdatenbank 36 bereits Benutzerkonfigurations- und Parameterdaten für das premise-basierte System 14 darin gespeichert aufweisen. Diese können von der Premise Sync Komponente 42 zum Beispiel während eines vorherigen Teils des Einrichtungsprozesses für das Hybrid-System gepusht werden. Die Benutzerkonfigurations- und Parameterdaten für das premise-basierte System 14 können eine Anzeige verfügbarer Sites umfassen und, für jede entsprechende Site, einen Satz auf einem oder mehreren zugehörigen Switches. In Reaktion auf eine andere Benutzereingabe können Parameterdaten für jeden der Switches die Anzahl an Ports angeben, die verfügbar sind, sowie eine Anzahl an Ports, die der entsprechenden Trunk-Gruppe zuzuweisen sind, d. h. um die Premise-Site 44 zu definieren. Wie erwähnt, kann ein Benutzer jede beliebige Anzahl an Switches als Teil der entsprechenden Trunk-Gruppe, die der Premise-Site 44 entspricht, hinzufügen.
Neben dem Einrichten der Premise-Trunk für die Site 44 kann der CMS 32 Benutzereingaben über das Portal 26 empfangen, um einen oder mehrere Nebenstellenbereiche für das Set von Ressourcen, die an der Site 44 arbeiten, und für den Satz von Ressourcen zum Betrieb innerhalb der gehosteten Site 46 anzugeben. Zum Beispiel kann basierend auf den anfänglichen Konfigurationsinformationen, die über die Premise Sync Funktion der Sync API 40 bereitgestellt wurden, die gehostete Konfigurationsdatenbank Nebenstellendaten umfassen, die einen oder mehrere Nebenstellenbereiche angeben, die bereits für das premise-basierte System 14 eingerichtet wurden. Zusätzlich lassen sich in Reaktion auf Benutzereingaben über das Portal Premise-Bereiche hinzufügen oder ändern. Basierend auf den in der gehosteten Konfigurationsdatenbank für das Premise-System (z. B. basierend auf anfänglich bereitgestellten Nebenstellendaten während des hierin beschriebenen Synchronisierungsprozesses) gespeicherten Premise-Nebenstellenbereichen kann der CMS 32 einen angemessenen Bereich oder Bereiche der Nebenstellen zum Betrieb innerhalb des gehosteten Systems 12 (z. B. neben oder zwischen dem Bereich für das Premise-System) zur Nutzung als Teil des Premise-Systems bestimmen. Zusätzlich kann in Reaktion auf eine Benutzereingabe ein Nutzer einen oder mehrere Premise-Bereiche oder gehostete Nebenstellen hinzufügen oder entfernen, die in dem Hybridsystem 10 zu verwenden sind. Die Partitions-Trunk-Definitionen und Nebenstellenbereiche können alle als entsprechende CMS-Bereitstellungsdaten in der gehosteten Konfigurationsdatenbank gespeichert werden in Reaktion auf die Benutzereingabe in das Portal 26, wodurch der CMS 32 des gehosteten Konfigurationsmanagers 30 bereitgestellt wird. Wie hierin offenbart, kann der angesammelte Satz aus angegebenen Nebenstellen in ein vereinheitlichtes Verzeichnis (z. B. in jede der Datenbanken 20 und 36) gespeichert werden, um das direkte Anrufen der Nebenstelle zwischen mit jeder der Nebenstellen verknüpften Ressourcen zu erleichtern.
In Reaktion auf das Bereitstellen des CMS 32 kann der gehostete Konfigurationsmanager 30 die CMS-Bereitstellungsdaten nutzen, um den SBC 50 bereitzustellen, z. B. durch Speichern entsprechender Trunk-Daten für die für die Premise-Site 44 etablierte Premise-Trunk-Gruppe. Der CMS 32 kann SBC-Bereitstellung in Reaktion auf Benutzereingaben über das Portal 26 automatisch initiieren. Solche Premise-Trunk-Daten für die Site 44 können in der SBC-Datenbank 52 gespeichert werden, z. B. in einer Tabelle (oder einer anderen Datenstruktur), die eindeutige Benutzerparameter angegeben (z. B. Tabelle 1) und verknüpfte Nebenstellenbereiche für jede der Premise-Ressourcen 18 angeben. Angemessene Zertifikate für das Premise-System 14 können ebenfalls in der SBC-Datenbank 52 gespeichert werden, um sicheren Zugriff auf die in dem gehosteten System implementierten Dienste und Ressourcen zu ermöglichen, die für das premise-basierte System 14 autorisiert und freigegeben wurden. Der CMS 32 kann auch die Trunk-Gruppendaten für die gehostete Site 46, umfassend den einen oder die mehreren Switches 48 und die verknüpften gehosteten Ressourcen 34, aktualisieren. Da die Premise-Ressourcen 18 als entfernte Offsite-Nebenstellen bezogen auf die Ressourcen in der gehosteten Site 46 arbeiten, können die in den SBC-Daten 52 für die Premise-Ressourcen gespeicherten zugewiesenen Nebenstellenbereiche auf entsprechende global eindeutige IDs abbilden, die für jede der entsprechenden Premise-Ressourcen 18 definiert sind, um Verbindungen zu solchen Ressourcen von den gehosteten Ressourcen zu ermöglichen.
Der CMS 32 kann basierend auf den CMS-Bereitstellungsdaten auch die Trunk-Gruppe bereitstellen, die der gehosteten Site 46 entspricht, wobei das Bereitstellen automatisch in Reaktion auf Benutzereingaben über das Portal 26 initiiert werden kann. Zum Beispiel kann das CMS 32 entfernte Nutzer bezogen auf die Site 46 bereitstellen, umfassend die mit der Site 44 verknüpften Nutzer sowie andere Nutzer, die anderswo innerhalb des premise-basierten Systems 14 arbeiten. Dies kann das Spezifizieren von Nutzerkonfigurationsdaten für jeden der in dem Hybridsystem 12 arbeitenden entfernten Nutzer umfassen. Der Management-Dienst kann ebenfalls eine zusätzliche Tabelle für eine entsprechende entfernte Offsite-Nebenstelle erstellen, die den Premise-Ressourcen 18 entspricht. Somit kann jede der in der gehosteten Konfigurationsdatenbank 36 gespeicherten Offsite-Nebenstellen entsprechende Nebenstellen für die Premise-Ressourcen 18 abbilden. Jedoch wird für jeden der Nutzer der gehosteten Ressourcen 34 sowie der premise-basierten Ressourcen 18 ein einheitliches Verzeichnis für jeden der entsprechenden Nutzer und ihrer entsprechenden Nebenstellen in der gehosteten Konfigurationsdatenbank 36 aufrechterhalten, das den Nutzern, die implementiert wurden, um in der gehosteten Site 46 zu arbeiten, dargestellt werden kann.
Zum Synchronisieren und Bewahren der Information zum Freigeben der Intersite-Verbindungen für die Sites 44 und 46 können die Management-Dienste eine Meldung an die Premise Sync Komponente 42 des premise-basierten Systems 14 senden. Die Meldung kann zum Beispiel in Reaktion auf das Bereitstellen der gehosteten Site 46 gesendet werden. Zusätzliche Benachrichtigungsmeldungen können in Reaktion auf das Erfassen von Änderungen in den in der gehosteten Konfigurationsdatenbank 36 gespeicherten Bereitstellungsdaten an die Premise Sync Komponente gesendet werden. In Reaktion darauf kann die Premise Sync Komponente 42 entsprechende Daten über die Sync API 40 aus der gehosteten Konfigurationsdatenbank 36 herausziehen. Zum Beispiel kann die Premise Sync Funktion 42 Daten herausziehen, die Nutzer angeben, die in dem gehosteten System 12 arbeiten, wobei die herausgezogenen Daten in der Premise-Konfigurationsdatenbank 20 gespeichert werden können. Die Premise Sync Funktion 42 kann entfernte Offsite-Nebenstellen in der Premise-Konfigurationsdatenbank 20 speichern, um einen Bereich der Nebenstellen für jede der bereitgestellten gehosteten Ressourcen 34 anzugeben, um Nebenstellenanrufe und Routing von innerhalb des premise-basierten Systems zu den Nutzern in der gehosteten Site 46 zu ermöglichen. Zusätzlich wird die in Reaktion auf die Nutzereingabe über das Portal 26 eingebene Information zum Bereitstellen des CMS 32 auch dazu verwendet, die entsprechende Site 44 als eine Trunk-Gruppe zu konfigurieren, die den angegebenen einen oder die angegebenen mehreren Switches und entsprechenden Ressourcen 18 und verknüpften Nebenstellenbereiche umfasst, wie oben beschrieben. Wenn von der gehosteten Konfigurationsdatenbank auf die Daten zugegriffen wurde und sie in der premise-basierten Konfigurationsdatenbank zum Bereitstellen der Premise-Site zum Betrieb in dem Hybrid-System 10 gespeichert wurden, kann die entsprechende Verbindung zwischen dem premise-basierten System 14 und dem gehosteten System 12 für die Kommunikation zwischen den Sites 44 und 46 operativ werden.
2, 3 und 4 stellen Beispiele für einige Signalisierungsabläufe dar, die in dem vereinigten Hybrid-Kommunikationssystem (System 10 von 1) zum Durchführen der hierin offenbarten verschiedenen Funktionen implementiert werden können. Der Einheitlichkeit halber beziehen sich die gleichen Bezugsziffern auf die gleichen Teile in den verschiedenen Beispielen von 2, 3 und 4, die in Bezug zu 1 eingeführt wurden. Linien mit Pfeilen an beiden Seiten werden genutzt, um Signalisierung zwischen mehreren Einrichtungen oder bi-direktionale Interaktion anzuzeigen, wohingegen eine Linie mit einem einzelnen Pfeil anzeigt, dass Kommunikation von einer Einrichtung oder einem Nutzer zu einem anderen erfolgt.
2 stellt ein Beispiel für ein Signalisierungsablaufdiagramm 60 dar, dass demonstriert, wie Ressourcen in dem gehosteten System für das premise-basierte System 14 konfiguriert werden können. Man vermutet weiter, dass am Beginn von 2 das premise-basierte System nicht operativ mit dem gehosteten System 12 ist. Es erfolgt ein Rückbezug auf das Beispielsystem 10 von 1, um zusätzlichen Kontext für den Ablauf 50 bereitzustellen.
Ein autorisierter Nutzer des premise-basierten Systems 14 kann sich in das Portal 26 einloggen, um das premise-basierte System für den Hybridbetrieb bei dem gehosteten System 12 anzumelden. Zum Beispiel kann dem autorisierten Nutzer ein vorbestimmter Ressourcen-Standort (z. B. eine vorbestimmte URL) bereitgestellt werden, die dem Portal 26 entspricht. In 62 kann der Nutzer einen Satz Zugangsdaten eingeben, die einen Benutzernamen und ein Passwort umfassen. In Reaktion auf die Benutzereingabe werden in 64 Hybrid-Dienste freigegeben, z. B. durch Erstellen eines Nutzerkontos zum Autorisieren des premise-basierten Systems für den Hybrid-Betrieb mit dem gehosteten System 12. In Reaktion auf die Anmeldung der Premise kann in 66 das gehostete System 12 dem premise-basierten System 14 Kontobereitstellungsdaten bereitstellen. Die Kontobereitstellungsdaten können einem Administrator, Speicherort oder anderen autorisierten Person innerhalb des premise-basierten Systems zur Verfügung gestellt werden, z. B. in einer Meldung (z. B. E-Mail, SMS-Nachricht oder dergleichen).
Zum Beispiel können die Kontobereitstellungsdaten in 66 ein Token und einen Kontoidentifikator umfassen, die zur weiteren Autorisierung und Zugriff auf das Portal 26 und die Ressourcen innerhalb des gehosteten Systems 12 genutzt werden können. Das Token kann in Reaktion auf eine Benutzereingabe manuell in das Premise-System eingegeben (z. B. in ein Dateneingabefeld eines digitales Formulars eingetippt oder kopiert) werden. Das Token kann in Verbindung mit der Konto-ID genutzt werden, um das jeweilige premise-basierte System 14 gegenüber dem gehosteten System 12 zu authentifizieren. Die Kombination von Token und Rechenschaft kann somit genutzt werden, um jedes premise-basierte System in dem mandantenfähigen Hybrid-System 10 zu sichern und zu identifizieren. Die Kontobereitstellungsdaten können andere Formen von Authentifizierung umfassen, um Autorisierung und Zugang zu dem Portal 26 und zu anderen Ressourcen zu ermöglichen, umfassend Dienste innerhalb des gehosteten Systems 12, z. B. ticketbasierte Authentifizierung. Ein Beispiel für ticketbasierte Authentifizierung, die genutzt werden kann, um Zugang zu dem Portal 26 und gehosteten Ressourcen 34 zu autorisieren und zu ermöglichen, ist in der US-Patentanmeldung Nr. 14/590,418 mit dem Titel DISTRIBUTED AUTHENTICATION, offenbart, die durch Bezugnahme hierin enthalten ist.
Als weiteres Beispiel kann in 68 das premise-basierte System 14 dem gehosteten System 12 über eine sichere Verbindung (z. B. Premise Sync Komponente 42 und Sync API 40 von 1) Konfigurationsdaten bereitstellen. Die Verbindungskonfigurationsdaten können Konfigurationen, Eigenschaften und Nutzerdaten für jeden der mehreren Nutzer und Ressourcen in dem premise-basierten System umfassen. Das heißt, in Reaktion auf das Authentifizieren des premise-basierten Systems 14 kann die gesamte Liste mit Nutzern und Nutzergruppen für das Premise-System dem gehosteten System 12 bereitgestellt werden. Als weiteres Beispiel kann der in Nutzung befindliche Authentifizierungsmechanismus in nachfolgenden Meldungen und Kommunikationen, die dem gehosteten System 12 von dem premise-basierten System 14 bereitgestellt werden, als Header-Information bereitgestellt werden. Die Konfigurationsdaten für die Nutzer können basierend auf Nutzereigenschaften generiert werden, die in Nutzertabellen gespeichert sind, welche in der Datenbank 20 des premise-basierten Systems 14 gespeichert sind.
Nachdem die Konfigurationsdaten in 68 dem gehosteten System 12 bereitgestellt und in der Konfigurationsdatenbank 36 gespeichert sind, kann in Reaktion auf eine Nutzereingabe in 70 der autorisierte Nutzer auf das Netzwerkportal zugreifen (z. B. mithilfe des Token und der Konto-ID, die für das premise-basierte System generiert wurden) und entsprechende Nutzerbereitstellungsdaten können dem gehosteten System 12 bereitgestellt werden, um verschiedene Ressourcen für die Hybrid-Nutzer des premise-basierten Systems 14 bereitzustellen. Die Benutzereingabe 70 kann von dem Nutzer an dem Netzwerkportal (z. B. über einen Webbrowser) bereitgestellt werden oder sie kann von einer grafischen Benutzeroberfläche an dem premise-basierten System (z. B. als Teil des Konfigurationsmanagers 16) bereitgestellt werden. Zum Beispiel kann, wie durch die mit der Benutzereingabe 70 verknüpfte gepunktete Linie dargestellt, der Konfigurationsmanager 16 des Premise-Systems 14 die Nutzerbereitstellungsdaten dem Portal 26 über die Portal-API 28 bereitstellen, welche wiederum in der gehosteten Konfigurationsdatenbank 36 gespeichert werden können. Die Nutzerbereitstellungsdaten können gehostete Ressourcen bereitstellen (z. B. Ressourcen 18 und 34) zum Betrieb mit jedem oder einer Teilmenge der Hybrid-Nutzer des premise-basierten Systems 14. Die Nutzerbereitstellungsdaten können jedem der Nutzer individuell gehostete Ressourcen zuweisen. Alternativ oder zusätzlich können gehostete Ressourcen für Nutzer gemäß einer Gruppe bereitgestellt werden, zu der jeder jeweilige Nutzer aktuell gehört. Auf diese Weise können bestehende Arbeitsgruppen von dem premise-basierten System wirksam eingesetzt und für Bereitstellungsdienste genutzt werden.
Als noch weiteres Beispiel könnte der Ablauf 50 dazu konfiguriert werden, einen autorisierten Nutzer freizugeben, um die Benutzereingabe 70 über eine grafische Benutzeroberfläche einzugeben, die direkt in dem Premise-System 14 implementiert ist (anstelle des Portals 26, wie dargestellt). In diesem anderen Beispiel würden somit die Nutzerbereitstellungsdaten 72 von dem premise-basierten System 14 zu dem gehosteten System 12 fließen. Da das Portal 26 bei diesem Ansatz effektiv umgangen wird, kann ein anderer Mechanismus genutzt werden, um den Nutzer sicher an dem Premise-System für den Zugriff auf das gehostete System 12 zu autorisieren.
Um Zugriff auf und Nutzung der gehosteten Ressourcen innerhalb des gehosteten Systems 12 zu ermöglichen, kann in 64 das gehostete System 12 dem premise-basierten System 14 Aktivierungsdaten basierend auf den über das Portal 26 bereitgestellten Nutzerbereitstellungsdaten bereitstellen. Die Aktivierungsdaten können somit angeben, welche Ressourcen für jeden Nutzer und jede identifizierte Nutzergruppe aktiviert wurden. Durch Angeben oder Zuweisen von Ressourcen bezogen auf eine jeweilige Gruppe, können, da sich ein Nutzer von einer Gruppe in eine andere bewegen könnte, die Ressourcen für die aktuelle Gruppe dynamisch für einen jeweiligen Nutzer gemäß der aktuellen Gruppe des Nutzers modifiziert werden.
Durch Konfigurieren des gehosteten Systems 12 zum Steuern der Aktivierung von Ressourcen (z. B. als die Quelle von wahrheitsbezogener Aktivierung) und wiederum Bereitstellen entsprechender Aktivierungsdaten für das premise-basierte System 14, können Konflikte vermieden werden, was die Komplexität der Implementierung in sowohl dem premise-basierten als auch dem gehosteten System 14 und 12 reduziert. Somit ist der Konfigurationsmanager 16 verantwortlich für einen bestimmten Satz aus Benutzereinstellungen in dem Premise-System 14, und das gehostete System 12 ist verantwortlich für einen anderen eindeutigen Satz aus Benutzereinstellungen, um Konflikte wie hierin beschrieben abzuschwächen. Zum Beispiel kann die Aktivierung der gehosteten Ressourcen über das Portal 26 eingestellt werden, wohingegen andere Benutzereinstellungen und -eigenschaften über den Konfigurationsmanager 16 des premise-basierten Systems verwaltet und gesteuert werden können. Die unterschiedlichen Sätze aus Benutzerparametern kooperieren, um das Bereitstellen und die Nutzung der gehosteten Ressourcen durch das Premise-System zu vereinfachen.
Wie erwähnt, können, wenn der autorisierte Benutzer Konfigurationseigenschaften für einen oder mehrere Benutzer an dem premise-basierten System modifiziert (z. B. Benutzerdaten 76 aktualisiert), Premise-Konfigurations- und Bereitstellungsdaten in 78 dem Konfigurationsmanager des gehosteten System 12 bereitgestellt werden, z. B. über die Portal-API 28. Zum Beispiel können die aktualisierten Premise-Konfigurations- und Bereitstellungsdaten in 78 dem gehosteten System 12 in Reaktion auf den Datenbank-Trigger oder in einem vorbestimmten Zeitintervall nach einer letzten Aktualisierung bereitgestellt werden. Das Zeitintervall kann zum Beispiel in Reaktion auf die Benutzereingabe in dem premise-basierten System programmiert werden. Die Premise-Konfigurations- und Bereitstellungsdaten, die in 78 bereitgestellt wurden, können wiederum genutzt werden, um die Konfigurationsdatenbank 36 zu aktualisieren, wie durch die gepunktete Linie 80 dargestellt. In Reaktion auf aus der Aktualisierung resultierender Änderungen können entsprechende Aktivierungsdaten in 74 von dem gehosteten System 12 über die sichere Verbindung an das premise-basierte System zurückgegeben werden. Wie hierin offenbart, können verschiedene Ressourcen in dem gehosteten System 12 ein anderes Bereitstellen über den Konfigurationsmanager 16 erfordern, z. B. um die Benutzer hinzuzufügen oder zu entfernen, um verschiedene Ressourcen zu nutzen.
Mit Rückbezug auf das Beispiel von 1 kann der Konfigurationsmanager 16 des premise-basierten Systems dazu programmiert werden, Ressourcen für die jeweiligen Benutzer über die Portal-API 28 zu aktivieren und zu deaktivieren. Wie erwähnt, kann dies auf Basis eines individuellen Benutzers oder auf einer Benutzergruppe durchgeführt werden. Die Portal-API 28 kann implementiert werden als eine Representational State Transfer (RESTful) API, die genutzt werden kann, um Benutzerkonfigurationsdaten an die Portal-API 28 zu exportieren oder um Einstellungen aus dem gehosteten Konfigurationsmanager zu ziehen, umfassend die Aktivierungsdaten für die Benutzer und Benutzergruppen. In anderen Beispielen kann ein autorisierter Benutzer das Portal 26 (von innerhalb oder außerhalb des Premise-Systems 14) direkt nutzen, um die Aktivierungseigenschaften für Benutzer oder Benutzergruppen in dem gehosteten System 12 zu modifizieren.
3 stellt ein Beispiel eines anderen Signalisierungsablaufdiagramms 100 zum Bereitstellen eines Verbindungsmanagementdienstes (CMS) dar, um die Sites 44 und 46 für Verbindungen zwischen Ressourcen in dem premise-basierten System 14 und dem entsprechenden gehosteten System 12 zu konfigurieren. Am Anfang des in dem Ablaufdiagramm 100 dargestellten Bereitstellungsprozesses wird angenommen, dass die anfängliche Synchronisierung der Parameter und Premise-Konfigurationsdaten und Kontoeinrichtung bereits implementiert wurden, z. B. gemäß des bezogen auf 2 offenbarten Ablaufs durchgeführt. Somit wird als Teil einer solchen anfänglichen Synchronisierung das premise-basierte System (das als ein Mandant in dem mandantenfähigen gehosteten System arbeitet) aktiviert, um einen Satz aus Diensten zu nutzen, der in dem gehosteten System aktiviert ist gemäß einer Anmeldung für einen gegebenen Mandanten, dem eine eindeutige Mandanten-ID zugewiesen wurde. Zusätzlich speichert in dieser Stufe das gehostete System 12 in seiner Konfigurationsdatenbank (z. B. Datenbank 36) Benutzerkonfigurationsdaten (siehe z. B. Tabelle 1), wie hierin offenbart. Zusätzlich hat jeder der Dienste innerhalb des gehosteten Systems 12, die für das premise-basierte System 14 aktiviert wurden, Authentifizierungsschlüssel empfangen und gespeichert, um eine sichere Kommunikation und authentifizierte Nutzung solcher Dienste durch die Benutzer und andere Ressourcen des premise-basierten Systems 14 zu ermöglichen.
Mit Bezug zu 3 werden in 102 Benutzereingaben über das Portal 26 bereitgestellt, um eine entsprechende Trunk-Gruppe für die Premise-Site zu erstellen, die mit der gehosteten Site zu verbinden ist. Die in 102 erstellte Trunk-Gruppe kann einer SIP-Trunk-Gruppe entsprechen, die dazu konfiguriert wurde, SIP zum Etablieren, Aufrechterhalten und Umleiten von Verbindungen zwischen den jeweiligen Ressourcen in dem premise-basierten System 14 und dem gehosteten System 12 zu implementieren. Als ein weiteres Beispiel kann die Trunk-Grupenbenutzereingabe 102 eine entsprechende Premise-Site angeben, die aus einer oder mehreren innerhalb des Premise-Systems 14 implementierten Sites ausgewählt werden kann. In 103 kann die Benutzereingabe auch einen oder mehrere Switches angeben, die Teil der ausgewählten Site und Zuweisung solcher Switches für Port-Zuweisung der in 10 erstellten Trunk-Gruppe sein sollen. Zum Beispiel können solche Benutzereingaben auch Port-Parameter für jeden entsprechenden Switch in der ausgewählten Site angeben, z. B. umfassend eine Identifikation einer Anzahl an verfügbaren Ports (z. B. bereitgestellt über Premise-Systemsynchronisierung von 2) und die Anzahl von Ports, die für die ausgewählte Site angefordert wurden. Die Anzahl der verfügbaren und angeforderten Ports für die Switches können in Reaktion auf die Benutzereingaben eingestellt werden.
In 104 werden die Nebenstellenbereiche in Reaktion auf eine andere Benutzereingabe eingestellt. Zum Beispiel können solche Nebenstellenbereiche über das Portal mithilfe eines wohlgeformten Dokuments, z. B. einem XML- oder HTML-Dokument, eingegeben werden. Die Nebenstellenbereiche können zum Beispiel Bereiche für Endpunkt-Nebenstellen (z. B. Telefonnebenstellen) angeben, die in dem Hybrid-System arbeiten. Die Nebenstellenbereiche können einen oder mehrere Bereiche umfassen, die mit dem premise-basierten System 14 (z. B. einem oder mehreren Bereichen) sowie einem oder mehreren jeweiligen Bereichen von Nebenstellen innerhalb des gehosteten Systems 12 verknüpft sind, die zusammen angesammelte Nebenstellenbereiche für das Hybrid-System definieren. Basierend auf den über das Portal 26 in 106 eingegebenen Informationen wird der CMS basierend auf den in 102 und 104 bereitgestellten Konfigurationsdaten bereitgestellt.
In Reaktion auf das Bereitstellen des CMS 32 kann der Konfigurationsmanager des gehosteten Systems 12 das SBC 50 bereitstellen, dargestellt in 108. Wie hierin dargestellt, können die Bereitstellungsinformationen für das SBC 50 in einer SBC-Datenbank (z. B. Datenbank 52) gespeichert werden und können Konfigurationsdaten für die Premise-Trunk-Gruppe umfassen, die in 102 angegeben wurde. Zusätzlich kann das SBC-Bereitstellen in 108 das Speichern entsprechender Nebenstellenbereiche für die gehosteten Ressourcen (z. B. Ressourcen 34) in der SBC-Datenbank umfassen. Das Bereitstellen in 108 kann auch das Hinzufügen von einem oder mehreren Zertifikaten für die Premise-Trunk-Gruppe umfassen, die erstellt wurde, um die entsprechende Verbindung zwischen jedem Switch in der Trunk-Gruppe (erstellt in 102) und dem SBC 50 (siehe z. B. 4) zu aktivieren. Der Premise-Trunk-Gruppenanteil des Bereitstellens für das SBC in 108 handhabt das Kommunikations-Mapping zwischen dem SBC und der Premise-Trunk-Gruppe, entsprechend den Ressourcen der Premise-Site 44.
Zusätzlich zu den mit der Premise-Trunk-Gruppe (z. B. Site 44) verknüpften Konfigurationsdaten umfasst das Bereitstellen der SBC in 108 auch das Aktualisieren der gehosteten Trunk-Gruppenkonfigurationsdaten (z. B. für Site 46), die für das gehostete System 12 etabliert wurde. Der gehostete Trunk-Gruppenanteil des Bereitstellens für das SBC in 108 wird von der SBC genutzt, um Verbindungen zwischen dem SBC und der gehosteten Trunk-Gruppe, entsprechend den Ressourcen der gehosteten Site 46 zu etablieren, durchzuführen und abzubrechen.
Zum Beispiel kann die gehostete Trunk-Gruppe (z. B. Site 46) als eine geteilte Gruppe von Ressourcen implementiert werden, die von allen Mandanten genutzt wird, die den CMS für den Hybrid-Betrieb aktiviert hatten, wie hierein beschrieben. Basierend auf dem Bereitstellen des SBC 50 arbeitet die SBC, um zwischen eindeutigen Identifikatoren für jede der Ressourcen und entsprechenden Ressourcen in jeder der entsprechenden Trunk-Gruppen in dem premise-basierten System 14 und dem gehosteten System 12 abzubilden. Der SBC nutzt das Mapping (z. B. In der SBC-Datenbank 52 gespeichert), um Verbindungen zur Kommunikationssitzung (z. B. Anrufen) zwischen der Premise-Site und der gehosteten Site 44 und 46 einzurichten und zu etablieren. Zum Beispiel kann der SBC 50 Anrufe, die von innerhalb des gehosteten Systems stammen, auf Ressourcen in dem premise-basierten System basierend auf dem eindeutigen Identifikator abbilden, der mit einer Nebenstelle verknüpft ist, die als Ziel des Anrufs eingestellt ist. Gleichermaßen kann der SBC die Mapping-Daten nutzen, um Anrufe abzubilden, die von Ressourcen innerhalb des premise-basierten Systems auf entsprechende eindeutige Identifikatioren in Ressourcen innerhalb des gehosteten Systems platziert werden.
In 110 kann das gehostete System die gehostete Trunk-Gruppe bereitstellen, z. B. durch Speichern einer entsprechenden Konfigurationsinformation in der gehosteten Konfigurationsdatenbank (z. B. Datenbank 36). Das Bereitstellen in 110 kann ein Identifizieren von Konfigurationsdaten für jeden der Premise-Nutzer umfassen gemäß den Premise-Daten, die in den Konfigurationsmanager des gehosteten System 12 hochgeladen wurden. Zusätzlich kann das Bereitstellen in 110 das Erstellen einer neuen Tabelle umfassen, die Nebenstellenbereiche angeben (z. B. umfassend einen oder mehrere Bereiche von Nebenstellen, die sich nicht innerhalb des premise-basierten Systems 14 befinden) und das Mapping solcher Nebenstellen auf entsprechende eindeutige Identifikatoren für jeweilige Nutzer und jeweilige Ressourcen.
Das Bereitstellen in 108 und 110 entspricht somit dem Bereitstellen für Teile des Hybrid-Systems innerhalb der Steuerung des gehosteten Systems 12. In 112 kann das CMS des gehosteten Systems 12 dem premise-basierten System 14 eine entsprechende Benachrichtigung bereitstellen. Zum Beispiel kann die Benachrichtigung über einen zuvor etablierten sicheren Kanal wie SSL über einen HTML-Befehl oder ein anderes Protokoll bereitgestellt werden. Die Benachrichtigung kann bewirken, das das premise-basierte System in 114 eine Anfrage nach entsprechenden CMS-Daten über einen sicheren Kommunikationskanal (z. B. eine HTTPS-, SSL- oder andere sichere Verbindung) an das CMS ausgibt.
In Reaktion auf die Anfrage in 114 kann das CMS des gehosteten Systems 12 (in 116) dem premise-basierten System 14 entsprechende CMS-Konfigurationsdaten bereitstellen. Das premise-basierte System 14 kann die CMS-Konfigurationsdaten in einer entsprechenden Konfigurationsdatenbank (z. B. Datenbank 20) des premise-basierten Systems speichern. Die CMS-Konfigurationsdaten können zum Beispiel eine Identifikation von entfernten Nutzern umfassen, z. B. die mit Bezug auf Tabelle 1 identifizierte Information umfassen. Zusätzlich können die Konfigurationsdaten Daten umfassen, die einen Satz entfernter Nebenstellenbereiche angeben, die einem oder mehreren Bereichen von Nebenstellen entsprechen, die Nutzern innerhalb des premise-basierten Systems 14 verfügbar sind, um auf entsprechende Nutzer (z. B. Cloud-Ressourcen) zuzugreifen, die physikalisch in dem gehosteten System 12 implementiert sind.
Die entfernten Offsite-Nebenstellen und die Onsite-Nebenstellen für das premise-basierte System 14 können in ein vereinheitlichtes Verzeichnis in der Premise-Konfigurationsdatenbank integriert werden, um das Etablieren, Durchführen und Abbrechen von Kommunikationssitzungen (z. B. Anrufen) von innerhalb des premise-basierten Systems zu einer beliebigen der in dem Verzeichnis bereitgestellten Nutzernebenstellen zu ermöglichen. Wie erwähnt, können die CMS-Konfigurationsdaten auch die CMS-Trunk-Gruppendaten umfassen, um Ressourcen innerhalb einer gegebenen Site des premise-basierten Systems (z. B. Site 44) anzugeben. Zum Beispiel kann, wie erwähnt, die CMS-Trunk-Gruppe Switches und Ports angeben, die der Trunk-Gruppe zugewiesen wurden (z. B. in 102) mit ausreichend Partikularität, um in der Gruppe befindlichen Nutzern das Arbeiten zu ermöglichen (z. B. Anrufe zu tätigen und zu empfangen). Zum Beispiel können die CMS-Konfigurationsdaten konfigurationsdatenidentifizierende Switches umfassen, die dem CMS-Dienst zugewiesen sind, sowie eine oder mehrere Sites innerhalb des premise-basierten Systems 14, die dem CMS zugewiesen sind. Somit können, sobald die CMS-Konfigurationsdaten in den Premise-Konfigurationsdatenbank gespeichert wurden, Ressourcen im premise-basierten System 14 und im gehosteten System 12 Verbindungen über den SBC 50 etablieren. Zum Beispiel können der eine oder die mehreren Switches innerhalb der CMS-Trunk-Gruppe mit dem SBC 50 verbunden werden über eine sichere Verbindung (z. B. über SSL) mittels einer vordefinierten URL für das SBC. Der SBC 50 kann wiederum Anrufe von dem premise-basierten System an das gehostete System weiterleiten, basierend auf der Mapping-Tabelle, umfassend das Mapping zwischen eindeutigen Identifikatoren, die in der SBC-Datenbank gespeichert sind, und entsprechenden Ressourcen (z. B. Nebenstellen) in dem gehosteten Teil der Trunkverbindung. So werden die Premise-CMS-Trunk-Gruppe (z. B. entsprechend Site 44) und die gehostete CMS-Trunk-Gruppe (z. B. entsprechend Site 46) über das SBC 50 miteinander verbunden.
4 stellt ein Beispiel für ein anderes Signalisierungsdiagramm 150 dar, das genutzt werden kann, um Switches innerhalb einer CMS-Gruppe entsprechend Zertifikaten bereitzustellen, um einen authentifizierten Betrieb zum Etablieren von Verbindungen über das SBC 50 zu ermöglichen. In Reaktion auf den aktivierten CMS-Dienst, wie hierin offenbart, kann in 152 der Konfigurationsmanager des Premise-Systems 14 eine Zertifiikatsregistrierungsanforderung (CSR) an den gehosteten Konfigurationsmanager ausgeben, z. B. über die Verbindung über die Premise Sync Komponente 42 und die Sync API 40. In 154 kann der gehostete Konfigurationsmanager 30 wiederum die CSR an eine entsprechende Zertifikatsautorität weiterleiten. Zum Beispiel kann die Aufforderung in 154 über eine RESTful API ausgegeben werden. In Reaktion kann in 156 die Zertifikatsautorität das entsprechend signierte Zertifikat dem gehosteten Konfigurationsmanager 30 bereitstellen. Der gehostete Konfigurationsmanager 30 kann das signierte Zertifikat in der gehosteten Konfigurationsdatenbank 36 zum Senden an den Premise-Konfigurationsmanager speichern. Der Premise-Konfigurationsmanager 16 kann die Premise Sync Komponente 42 nutzen, um wiederum das Zertifikat gemeinsam mit einem Zertifikat einer öffentlichen Zertifikatsautorität zu ziehen, wie in 158 dargestellt. Der Premise-Konfigurationsmanager 16 kann das ausgegebene Zertifikat speichern, das öffentliche-CA-Zertifikat von dem gehosteten Konfigurationsmanager zusammen mit jedem zugewiesenen Schlüssel zu dem Switch oder den Switches 22 in 158, die mit der CMS-Premise-Trunk-Gruppe konfiguriert wurden (z. B. entsprechend der Premise-Site 44). Der eine oder die mehreren Switches 22 können somit das neue Schlüsselpaar (z. B. umfassend die Zertifikate und den entsprechenden Schlüssel) für authentifizierte sichere Verbindungen mit dem SBC und anderen gehosteten Diensten (z. B. umfassend CMS 32), die für Nutzer und andere Ressourcen der premise-basierten Site aktiviert wurden, nutzen.
Angesichts des Vorstehenden wird ein Ansatz zum Vereinfachen der Bereitstellung von Hybrid-Systemressourcen offenbart. Wie erwähnt, umfasst eine solche Bereitstellung das Bereitstellen von cloud- und premise-basierten Ressourcen in Reaktion auf minimale Nutzerinteraktion. Zum Beispiel kann nach Hochladen anfänglicher Premise-Information über sichere Kanäle, die mit dem System-Setup verknüpft sind, eine CMS-Verbindung in Reaktion auf minimale Nutzereingaben bereitgestellt werden, die die Premise-Site und verknüpfte Ressourcenparameter für die Premise-Site angeben. Im Ergebnis können die gehostete Site 46 und ihre verknüpften Ressourcen als Teil einer virtuellen private Cloud innerhalb des gehosteten Systems 12 implementiert werden, umfassend Ressourcen der gehosteten Site 48 und 34, die eine erhöhte Quantität an Nebenstellen zum Erweitern des Premise-Systems bieten, um Cloud-Nutzer aufzunehmen. Cloud-Nutzer können dem Premise-System zugewiesen werden in Reaktion auf das Zuweisen einer Nebenstelle, die die eine oder die mehreren in der gehosteten Site 46 implementierten Nebenstellenbereiche sind, zu einem bestehenden oder neuen Nutzer (z. B. in Reaktion auf die Nutzung von Eingabe über den Premise-Konfigurationsmanager. Der Administrator oder andere autorisierte Nutzer sind sich eventuell nicht bewusst, dass der Bereich der Nebenstellen, zu dem der eine oder die mehreren Nutzer zugewiesen wird, in einer mandantenfähigen Cloud gehostet ist.
Fachleute werden verstehen, dass Abschnitte der Erfindung als ein Verfahren, Datenverarbeitungssystem oder Computerprogrammprodukt (z. B. einem nicht flüchtigen computerlesbaren Medium mit Anweisungen, die von einem Prozessor ausgeführt werden können) verkörpert werden können. Dementsprechend können diese Abschnitte der Erfindung die Form einer kompletten Hardware-Ausführungsform, einer kompletten Software-Ausführungsform oder eine Ausführung annehmen, die Software und Hardware kombiniert. Darüber hinaus können Abschnitte der Erfindung ein Computerprogrammprodukt auf einem computernutzbaren Speichermedium mit computerlesbarem Programmcode auf dem Medium sein. Jedes geeignete nicht flüchtige computerlesbare Medium kann genutzt werden, umfassend, doch nicht darauf beschränkt, statische und dynamische Speichereinrichtungen, Festplatten, optische Speichereinrichtungen und Magnetspeichereinrichtungen.
Bestimmte Ausführungsformen sind hierin mit Bezug auf Darstellungen von Verfahren, Signalisierungsablaufdiagrammen, Systemen und Computerprogrammprodukten offenbart. Man wird verstehen, dass Blöcke der Darstellungen und Kombinationen der Blöcke in den Darstellungen durch computerausführbare Anweisungen implementiert werden können. Diese computerausführbaren Anweisungen können einem oder mehreren Prozessorkernen eines Allzweckcomputers, Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung (oder einer Kombination von Einrichtungen und Schaltungen) bereitgestellt werden, um eine Maschine herzustellen, sodass die Anweisungen, die über den Prozessor ausgeführt werden, die in dem Block oder in den Blöcken angegebenen Funktionen implementieren.
Diese computerausführbaren Anweisungen können auch in einem nicht flüchtigen computerlesbaren Medium gespeichert werden, das einen Computer oder eine andere programmierbare Datenverarbeitungsvorrichtung (z. B. einen oder mehrere Verarbeitungskerne) anweisen kann, auf eine bestimmte Weise zu funktionieren, sodass die in dem computerlesbaren Medium gespeicherten Anweisungen in einem Produkt resultieren, das Anweisungen umfasst, welche die in dem Block oder den Blöcken des Flussdiagramms angegebene Funktion implementiert. Die Computerprogrammanweisungen können auch auf einen Computer oder eine andere programmierbare Datenverarbeitungsvorrichtung geladen werden, um zu bewirken, dass eine Reihe von Arbeitsschritten auf dem Computer oder der anderen programmierbaren Vorrichtung durchgeführt wird, um einen computerimplementierten Prozess zu produzieren, sodass die Anweisungen, die auf dem Computer oder der anderen prorammierbaren Vorrichtung laufen, Schritte zum Implementieren der in dem Block oder den Blöcken des Flussdiagramms oder der zugehörigen Beschreibung angegebenen Funktionen vorsehen.
Vorstehend wurden Beispiele beschrieben. Es ist natürlich nicht möglich, jede erdenkliche Kombination aus Komponenten oder Methodologien zu beschreiben, doch Fachleute werden erkennen, dass viele weitere Kombinationen und Permutationen möglich sind. Zum Beispiel können, während einige hierin offenbarte Beispiele ein hauptsächlich premise-basiertes, das eine gehostete Verwendung von Ressourcen zum Vorteil nutzen kann, System zu beschreiben scheinen, die hierin offenbarten Systeme und Verfahren verschiedene Kombinationen anderer Mengen an gehosteten und premise-basierten Ressourcen gemäß Nutzeranforderungen nutzen. Dementsprechend ist die Offenbarung dazu gedacht, alle derartigen Änderungen, Modifikationen und Variationen zu umfassen, die in den Schutzumfang dieser Anmeldung fallen, umfassend der angefügten Ansprüche. Wie hierin genutzt, meint der Begriff „umfasst” umfasst, ist jedoch nicht darauf beschränkt, der Begriff „umfassend” meint umfassend, ist jedoch nicht darauf beschränkt. Der Begriff „basierend auf” meint basierend auf, zumindest teilweise. Zusätzlich, wo die Offenbarung oder die Ansprüche „ein”, „ein erstes” oder „ein anderes” Element oder das Äquivalent davon angeben, ist dies als ein oder mehr als ein solches Element umfassend, und nicht als zwei oder mehrere solche Elemente erfordernd noch ausschließend zu interpretieren.

Claims

Computerimplementiertes Verfahren, umfassend: in Reaktion auf das Aktivieren eines Verbindungsmanagementdienstes (CMS) eines mandantenfähigen gehosteten Systems für ein premise-basiertes System Speichern von Premise-Daten und mit dem premise-basierten System verknüpften Nutzerkonfigurationsdaten in einer gehosteten Konfigurationsdatenbank des gehosteten Systems, wobei das premise-basierte System und das gehostete System ein Hybrid-Kommunikationssystem definieren; Bereitstellen des CMS in Reaktion auf eine Benutzereingabe, um Benutzer- und Ressourcenparameter für eine Premise-Trunk-Gruppe des premise-basierten Systems anzugeben, um sich mit einer gehosteten Trunk-Gruppe des gehosteten System zu verbinden, wobei CMS-Bereitstellungsdaten in der gehosteten Konfigurationsdatenbank gespeichert sind; in Reaktion auf das Bereitstellen des CMS Bereitstellen eines Session Border Controller, um mindestens eine Verbindung zwischen der Premise-Trunk-Gruppe und der gehosteten Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten zu steuern; Aktualisieren der gehosteten Konfigurationsdatenbank, um die gehostete Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten zu konfigurieren; und Speichern der Premise-Konfigurationsdaten für die Premise-Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten.
Computerimplementiertes Verfahren nach Anspruch 1, wobei das Bereitstellen des CMS ferner umfasst: Erstellen der Premise-Trunk-Gruppe für eine ausgewählte Premise-Site in Reaktion auf die Benutzereingabe, wobei die Premise-Trunk-Gruppe zum Verbinden mit der gehosteten Trunk-Gruppe für eine Kommunikationssitzung eine Ressource in der ausgewählten Premise-Site und eine Ressource in einer entsprechenden die gehostete Trunk-Gruppe umfassenden gehosteten Site umfasst; und Erstellen von Nebenstellenbereichen zum Definieren von Nebenstellen, die in Reaktion auf eine andere Benutzereingabe für das Hybrid-Kommunikationssystem aktiviert werden.
Computerimplementiertes Verfahren nach Anspruch 2, wobei die Nebenstellenbereiche für das Hybrid-Kommunikationssystem mindestens einen Nebenstellenbereich für das premise-basierte System und mindestens einen Nebenstellenbereich für das gehostete System umfassen, von denen mindestens einer in Reaktion auf über eine Nebenstellenbenutzereingabe bereitgestellte Nebenstelleninformation angegeben wird.
Computerimplementiertes Verfahren nach Anspruch 2, wobei das Aktualisieren der gehosteten Konfigurationsdatenbank ferner das Generieren eines Verzeichnisses der Nebenstellen für Nutzer und Ressourcen in dem Hybrid-Kommunikationssystem umfasst, wobei das Verzeichnis eine Mapping-Tabelle zum Mapping zwischen eindeutigen Identifikatoren für Systemressourcen innerhalb des Hybrid-Kommunikationssystems und mit den Systemressourcen innerhalb des gehosteten Systems verknüpften Nebenstellen umfasst.
Computerimplementiertes Verfahren nach Anspruch 4, wobei die Nebenstellen in jedem in dem Verzeichnis der gehosteten Konfigurationsdaten gespeicherten Nebenstellenbereich für das premise-basierte System entfernte Offsite-Nebenstellen bezogen auf die gehostete Site definieren, und wobei die Nebenstellen in jedem Nebenstellenbereich in jedem in dem Verzeichnis der Premise-Konfigurationsdaten gespeicherten Nebenstellenbereich für das premise-basierte System entfernte Offsite-Nebenstellen bezogen auf die ausgewählte Premise-Site definieren.
Computerimplementiertes Verfahren nach Anspruch 2, wobei das Erzeugen der Premise-Trunk-Gruppe ferner umfasst: Angeben von mindestens einem Switch in der ausgewählten Premise-Site zum Verbinden mit der gehosteten Site; und Einstellen von Port-Parametern für jeden angegebenen Switch.
Computerimplementiertes Verfahren nach Anspruch 2, das Bereitstellungsdaten in der Premise-Konfigurationsdatenbank speichert, um mindestens einen Bereich von Offsite-Nebenstellen für das premise-basierte System zu definieren, wobei mindestens eine der Offsite-Nebenstellen cloud-basierten Nutzern entspricht, die in der gehosteten Site für den Betrieb mit dem premise-basierten System in dem mandantenfähigen gehosteten System bereitgestellt sind.
Computerimplementiertes Verfahren nach Anspruch 1, wobei vor dem Aktivieren des CMS das Verfahren ferner das Etablieren einer Premise-Synchronisierungsverbindung zur authentifizierten Kommunikation zwischen einem Premise-Konfigurationsmanager des premise-basierten Systems und einem gehosteten Konfigurationsmanager des gehosteten Systems umfasst.
Computerimplementiertes Verfahren nach Anspruch 8, wobei die Premise-Konfigurationsdaten, die in Reaktion auf das Bereitstellen des CMS gespeichert werden, über die Premise-Synchronisierungsverbindung aus der gehosteten Konfigurationsdatenbank herausgezogen werden, wobei die Konfigurationsdaten Nutzerparameter definieren und entsprechende Premise-Konfigurationsdaten für eine CMS-Premise-Site, die die Premise-Trunk-Gruppe umfasst.
Nicht flüchtiges computerlesbares Medium, das maschinenlesbare Anweisungen speichert, umfassend: eine Portalanwendungsschnittstelle, um auf gehostete Bereitstellungsdienste zuzugreifen, die dazu konfiguriert sind, in einem gehosteten System eines vereinigten hybriden Kommunikationssystems zu arbeiten, wobei das Hybrid-System auch mindestens ein premise-basiertes System umfasst; und einen Verbindungsmanagementdienst (CMS), um CMS-Bereitstellungsdaten in einer gehosteten Konfigurationsdatenbank des gehosteten System in Reaktion auf eine Benutzereingabe über die Portalanwendungsschnittstelle zu speichern, um eine gegebene Premise-Trunk-Gruppe des premise-basierten Systems für den Betrieb in dem Hybrid-System zu konfigurieren, den CMS, um ferner einen Session Border Controller bereitzustellen, um mindestens eine Verbindung zwischen der Premise-Trunk-Gruppe und einer gehosteten Trunk-Gruppe des gehosteten Systems basierend auf den CMS-Bereitstellungsdaten zu steuern, den CMS, um die gehostete Konfigurationsdatenbank zu aktualisieren, um die gehostete Trunk-Gruppe zu konfigurieren und zu bewirken, dass Premise-Konfigurationsdaten für die gegebene Premise-Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten in dem Premise-System gespeichert werden.
Medium nach Anspruch 10, wobei in Reaktion auf eine andere Benutzereingabe über die Portalanwendungsschnittstelle der CMS ferner dazu konfiguriert wird, CMS-Premise-Site-Parameter für die gegebene Premise-Trunk-Gruppe für eine ausgewählte Premise-Site in den CMS-Bereitstellungsdaten zu speichern, wobei die CMS-Premise-Site-Parameter mindestens einen Switch in der ausgewählten Premise-Site angeben, die mit dem Session Border Controller für Kommunikationen mit Ressourcen in der gehosteten Trunk-Gruppe über den Session Border Controller zu verbinden ist.
Medium nach Anspruch 11, wobei in Reaktion auf eine Nebenstellenbenutzereingabe über die Portalanwendungsschnittstelle der CMS ferner dazu konfiguriert wird, mindestens einen Bereich von Nebenstellen für Ressourcen in dem premise-basierten System als Teil der CMS-Premise-Site-Parameter für die gegebene Premise-Trunk-Gruppe zu speichern.
Medium nach Anspruch 12, wobei der CMS ferner dazu konfiguriert ist, mindestens einen Bereich von Nebenstellen für Hybrid-Ressourcen zu speichern, die in Reaktion auf die Nebenstellenbenutzereingabe in der aktualisierten gehosteten Konfigurationsdatenbank implementiert wurden.
Medium nach Anspruch 13, wobei die aktualisierte gehostete Konfigurationsdatenbank ferner ein Verzeichnis der Nebenstellen für Nutzer und Ressourcen in jedem des premise-basierten Systems und dem gehosteten System in dem Hybrid-System umfasst, wobei das Verzeichnis eine Mapping-Tabelle zum Mapping zwischen eindeutigen Identifikatoren für Systemressourcen innerhalb des Hybrid-Kommunikationssystems und mit den Systemressourcen innerhalb des gehosteten Systems verknüpften Nebenstellen umfasst.
Medium nach Anspruch 14, wobei die Nebenstellen in jedem in dem Verzeichnis der gehosteten Konfigurationsdaten gespeicherten Nebenstellenbereich für das premise-basierte System entfernte Offsite-Nebenstellen bezogen auf das gehostete System definieren, und wobei die Nebenstellen in jedem Nebenstellenbereich n in jedem in dem Verzeichnis der Premise-Konfigurationsdaten gespeicherten Nebenstellenbereich für das premise-basierte System entfernte Offsite-Nebenstellen bezogen auf die ausgewählte Premise-Site definieren.
Medium nach Anspruch 12, wobei der CMS dazu konfiguriert ist, Speicher mit Bereitstellungsdaten in der Premise-Konfigurationsdatenbank einzustellen, um einen Satz von Offsite-Nebenstellen für das premise-basierte System zu definieren, wobei mindestens eine der Offsite-Nebenstellen mindestens einem cloud-basierten Nutzer oder einer Ressource entspricht, die in dem gehosteten System für den Betrieb mit dem premise-basierten System in dem Hybrid-System bereitgestellt ist.
Medium nach Anspruch 16, das ferner eine Premise-Synchronisierungsanwendungsschnittstelle zum Bereitstellen einer authentifizierten Kommunikationsverbindung zwischen einem Premise-Konfigurationsmanager des premise-basierten Systems und einem gehosteten Konfigurationsmanager des gehosteten Systems umfasst, wobei die Premise-Konfigurationsdaten, die in Reaktion auf das Bereitstellen des CMS gespeichert werden, über die authentifizierte Kommunikationsverbindung aus der gehosteten Konfigurationsdatenbank herausgezogen werden, wobei die Premise-Konfigurationsdatenbank Nutzerparameter definiert und entsprechende Premise-Konfigurationsdaten für eine CMS-Premise-Site, die die Premise-Trunk-Gruppe umfasst.
Hybrid-Kommunikationssystem, umfassend: mindestens ein premise-basiertes System, das ein Portal umfasst, um auf aktivierte gehostete Dienste zuzugreifen und bereitzustellen, die in einem mandantenfähigen gehosteten System des vereinigten Hybrid-Kommunikationssystems arbeiten; wobei das gehostete System einen gehosteten Konfigurationsmanager umfasst, um Konfiguration und Bereitstellung gehosteter Ressourcen in dem gehosteten System zu steuern, wobei der gehostete Konfigurationsmanager einen Verbindungsmanagementdienst (CMS) umfasst, der für das premise-basierte System aktiviert ist, um CMS-Bereitstellungsdaten in einer gehosteten Konfigurationsdatenbank des gehosteten Systems in Reaktion auf eine Benutzereingabe zu speichern, die über das Portal bereitgestellt wurde, um eine gegebene Premise-Trunk-Gruppe des premise-basierten Systems für den Betrieb in dem Hybrid-System zu konfigurieren; und einen Session Border Controller, der dazu konfiguriert ist, mindestens eine Verbindung zwischen der gegebenen Premise-Trunk-Gruppe und einer gehosteten Trunk-Gruppe des gehosteten Systems basierend auf der Bereitstellung des Session Border Controller zu steuern basierend auf den CMS-Bereitstellungsdaten, wobei die gehostete Konfigurationsdatenbank aktualisiert wird, um die gehostete Trunk-Gruppe zu konfigurieren und bewirkt wird, dass Premise-Konfigurationsdaten für die gegebene Premise-Trunk-Gruppe basierend auf den CMS-Bereitstellungsdaten in dem premise-basierten System gespeichert werden.
System nach Anspruch 18, wobei die aktualisierte gehostete Konfigurationsdatenbank ferner ein Verzeichnis von Nebenstellen für Nutzer und Ressourcen in jedem des premise-basierten Systems und dem gehosteten System des Hybrid-Kommunikationssystems umfasst, wobei das Verzeichnis eine Mapping-Tabelle zum Mapping zwischen eindeutigen Identifikatoren, die mit Systemressourcen verknüpft sind, die konfiguriert sind, um innerhalb des Hybrid-Kommunikationssystems und innerhalb des gehosteten Systems mit den Systemressourcen verknüpften Nebenstellen zu arbeiten, wobei die Nebenstellen in jedem in dem Verzeichnis der gehosteten Konfigurationsdaten gespeicherten Nebenstellenbereich für das premise-basierte System entfernte Offsite-Nebenstellen bezogen auf das gehostete System definieren, und wobei die Nebenstellen in jedem Nebenstellenbereich n in jedem in dem Verzeichnis der Premise-Konfigurationsdaten gespeicherten Nebenstellenbereich für das premise-basierte System entfernte Offsite-Nebenstellen bezogen auf eine in Reaktion auf eine Auswahlbenutzereingabe ausgewählte Premise-Site definieren.
System nach Anspruch 18, das ferner eine Premise-Synchronisierungskommunikationsverbindung zum Bereitstellen einer authentifizierten Kommunikation zwischen einem Premise-Konfigurationsmanager des premise-basierten Systems und dem gehosteten Konfigurationsmanager des gehosteten Systems umfasst, wobei die Premise-Konfigurationsdaten, die in Reaktion auf das Bereitstellen des CMS gespeichert werden, über die Premise-Synchronisierungskommunikationsverbindung aus der gehosteten Konfigurationsdatenbank herausgezogen werden, wobei die Premise-Konfigurationsdatenbank Nutzerparameter definiert und entsprechende Premise-Konfigurationsdaten für eine CMS-Premise-Site, die die Premise-Trunk-Gruppe umfasst.