Porthandler Die vorliegende Erfindung betrifft ein Verfahren zum Ausführen einer Anrufsteuerung eines Clients auf einen einen Benutzer repräsentierenden Telefonie-Endpunkt sowie ein Computerprogrammprodukt zur Implementierung des Verfahrens, einen maschinenlesbaren Datenträger mit darauf gespeichertem Computerprogrammprodukt sowie einen entsprechend hierfür ausgebildeten Porthandler.

Für die folgende Beschreibung seien folgende Begriffe kurz erläutert:

Eine Telekommunikationsplattform (kurz auch TK-Plattform) ist beispielsweise eine Vermittlungsstelle oder eine Telekommunikationsanlage (auch als PBX bzw. "Private Branch Exchange" bezeichnet). Solche TK-Plattformen bieten meist SIP-basierte VolP/Video- over-IP-Technologien an. Ein Telefonie-Endpunkt ist beispielsweise ein Telefon,

Smartphone, ein Computer zur Nutzung beim Aufbau oder Betrieb einer Telefonverbindung bzw. "Call" oder einer Datenverbindung, oder ein anderes - ggf. virtuelles - Endgerät.

Ein Cloud-Kommunikationsserver (CKS) ist beispielsweise eine SaaS-Cloud-Plattform für die teamübergreifende Zusammenarbeit. Hier erhalten Teams, was sie für eine effektive Kommunikation benötigen, in einem einzigen Client (kurz auch CKS-Client). Ein CKS-Client ist beispielsweise eine Anwendungssoftware (App), mit der u.a. Sprache, Video, Screensharing, Messaging, Chat und Dateifreigabe vereint werden und ermöglicht somit eine problemlose und vereinfachte Zusammenarbeit. Ein derartiger CKS-Client eines Cloud-Kommunikationsservers ist meist auf Basis der WebRTC-Technologie realisiert und kann beispielsweise auf einem (Telefonie-)Endpunkt installiert sein.

Ferner seien die folgenden Abkürzungen erläutert:

ATC: Advanced Telephony Connector

App: Anwendungssoftware, Applikation Software, Webanwendung

CKS: Cloud-Kommunikationsserver

CSTA: Computer Supported Telecommunications Applications (ECMA)

CTI: Computer Telephony Integration (z.B. CSTA, TAPI)

GTC: Generic Telephony Connector PBX: Telekommunikationsanlage, Telekommunikationsplattform, Switch

SaaS: Software as a Service

SIP: Session Initiation Protocol

TK: Telekommunikation

UTC: Universal Telephony Connector

VolP: Voice over IP

WebRTC: Web Real-Time Communication

Nachdem immer mehr Web-basierte Real-time-Kommunikationslösungen auf Basis der WebRTC-Technologie ausgerollt werden, steht die Integration mit den vorhandenen meist SIP-basierten VolP/Video-over-IP-Plattformen an.

Dabei können dann auch SIP-basierte IP-Telefone als weitere Endpunkte bzw. Endgeräte eines TK-Plattform-Nutzers verwendet werden. Viele Hersteller von IP-basierten PBXen bzw. TK-Plattformen (sogenannte Converged Systems) und auch Soft-PBXen nutzen aber auch weitere Protokolle wie H.323 oder proprietäre Protokolle, die über Standardprotokolle getunnelt werden. Als Konnektivität zu öffentlichen Netzen hat sich der SIP-T (Trunking)-Standard durchgesetzt. In der ersten Stufe der Integration geht es um die reine Konnektivität, das heißt Basic- Call-Fähigkeit ohne Leistungsmerkmale. Dazu wurde der SIP-Border-Proxy zur sicheren Anbindung anderer SIP-Domänen zu einem sogenannten Universal Telephony Adapter (UTC) erweitert. Der UTC realisiert neben dem Interworking zwischen WebRTC- Protokollen und SIP-T auch eine Adressumsetzung und registriert einen WebRTC-Client eines Cloud-Kommunikationsservers (CKS) beim SIP-Proxy/Registrar einer TK-Plattform (PBX). Da es sich um eine 1 :1-Beziehung zwischen WebRTC-Client und SIP-Trunking- Endpunkt handelt, kann aufgrund der Rufnummer der SIP-Trunking-Endpunkt mit dem dahinterliegenden WebRTC-Client eine logische Teilnehmerassoziation erfolgen. Damit ist der WebRTC-Client vermittlungstechnisch in der PBX bzw. TK-Plattform integriert und funktioniert für abgehende und ankommende Rufe.

Dies ist dem Gebrauchsmuster DE 20 201 1 003 225 U1 zu entnehmen. Hier werden innerhalb des Call Processing (auch als Anrufverarbeitung bezeichnet) alle weiteren Aktionen des externen Teilnehmers auf ein Teilnehmer-Device umgelenkt (assoziiert). Das verwendete Teilnehmer-Device ist ein sogenanntes virtuelles Device, d.h. ein Device ohne eine physikalische Anbindung. Die Anbindung an die Physik, d.h. den UTC repräsentierenden SIP-Trunk, erfolgt mittels Assoziierung. Dieser virtuelle Teilnehmer erbt somit die Eigenschaften des CKS-Clients und repräsentiert diesen gleichzeitig im Call Processing. Die Zuordnung WebRTC-Client (CKS-Client) eines Cloud- Kommunikationsservers (CKS)/UTC/SIP-Trunk/Virtueller Teilnehmer einer TK-Plattform (PBX) steht hierbei in einer "1 zu 1 "- bzw. "1 :1 "-Beziehung.

Bei der Analyse der TK-Plattform-Use-Szenarien und -Use-Cases wurden einige vorteilhafte Leistungsmerkmale wie Halten, Rückfrage, Übergeben, Rufweiterleitung sowie Rufweiterschaltung insbesondere zwischen den Clients und den Endpunkten _T etc. identifiziert. Zur Steuerung dieser Leistungsmerkmale wird der UTC zum Advanced Telephony Con- nector (ATC) erweitert. Zur Leistungsmerkmalsignalisierung kann beim ATC u.a. das proprietäre Konstrukt CTI-Protokoll CSTA over SIP genutzt werden, welches von SIP- basierten Plattformen interpretiert werden kann und bereits von mobilen UC-Clients verwendet wird. Die vorliegende Erfindung beschäftigt sich mit der Aufgabe, wie Leistungsmerkmale ohne proprietäre Signalisierung in einer solchen Konfiguration bei vielen, wenn nicht sogar allen Herstellern genutzt werden könnten.

Diese Aufgabe wird erfindungsgemäß gelöst mit einem Verfahren gemäß Anspruch 1 , einem Computerprogrammprodukt gemäß Anspruch 6 zur Implementierung des Verfahrens, einem maschinenlesbaren Datenträger gemäß Anspruch 7 mit darauf gespeichertem Computerprogrammprodukt sowie einem entsprechend ausgebildeten Porthandler gemäß Anspruch 8. Vorteilhafte Weiterbildungen der Erfindung sind Gegenstand der abhängigen Ansprüche.

Erfindungsgemäß funktionieren in vorteilhafter Weise die betrachteten Leistungsmerkmale, ohne dass eine Leistungsmerkmalsignalisierung in SIP erfolgen muss. Während der Ausführung von Leistungsmerkmalen sollten aber mindestens zwei resultierende Verbin- düngen assoziiert werden. Dazu dient die Erfindung mit dem erfindungsgemäßen Porthandler, der mehrere SIP-T-Verbindungsendpunkte anhand der Teilnehmer-Nummer assoziiert und der SIP-basierten Vermittlung als einen (virtuellen) Benutzer darstellt. Dabei benutzt die Erfindung eine Eigenschaft heutiger WebRTC-Clients, zu einem Zeitpunkt nur in einer aktiven RTC-Session teilzunehmen. Das Verfahren kann aber auch bei meh- reren gleichzeitigen Sessions funktionieren. Mit dem vorliegenden Verfahren können somit (z.B. über einen UTC integrierte) CKS-Clients einen erweiterten Zugriff auf die Anrufsteuerung (auch als Call Control bezeichnet) der angeschalteten TK-Plattform erhalten. Die vorher genannten Konnektoren UTC und ATC benutzen zwei unterschiedliche Ansätze zur Anschaltung von CKS-Clients an eine TK-Plattform. Beim UTC werden die CKS- Clients über SIP-Leitung-Verfahren (Trunking) und beim ATC über SIP-Teilnehmer- Verfahren (Endpoint) integriert. Die Integration von WebRTC-Clients über SIP-

Teilnehmer-Verfahren ermöglicht auf einfache Art und Weise eine erweiterte Anrufsteuerung und damit einen tieferen Zugriff auf die Leistungsmerkmale der angeschalteten TK- Plattform. Beispielsweise verwendet der WebRTC-Client zur Steuerung des zugeordneten Telefons CSTA over SIP. Bei CSTA handelt es sich um die Möglichkeit, Informationen der Anrufverarbeitung zwischen einer TK-Plattform und einer Applikation auszutauschen, und die Applikation wird in die Lage versetzt auf die Anrufverarbeitung der TK-Plattform einzuwirken.

Die für die Ausführung von Leistungsmerkmalen erforderliche Signalisierung (z.B. Rück- frage) wird bei Anwendung des erfindungsgemäßen Verfahrens über den am UTC registrierten CKS-Client mittels eines zweiten Ports (hier z.B. SIP-Trunk) in die Anrufverarbeitung (auch als Call Processing bezeichnet) geleitet. Voraussetzung hierfür ist die Implementierung einer "n zu 1 "- Beziehung (auch mit "n:1 "-Beziehung bezeichnet) in der Anrufverarbeitung. Hierzu wird der (virtuelle) Device-Handler durch einen universellen erfin- dungsgemäßen Porthandler abstrahiert.

Bei der "n zu 1 "-Implementierung verweisen n Instanzen von Ports (hier SIP-Trunks) auf den einen Benutzer, welcher den CKS-Client im Call Processing repräsentiert. Der Benutzer kann innerhalb einer Anrufverarbeitung-Implementierung beispielsweise mittels einer funktionalen oder einer Stimulus-gesteuerten Signalisierung realisiert werden. Im Gegensatz zur funktionalen Signalisierung (beispielsweise gemäß SIP-Teilnehmer) besitzt im Wesentlichen die den Benutzer repräsentierende Instanz bei der Stimulus-Signalisierung (meist proprietär) keinen vermittlungstechnischen Zustand. Für das hier beschriebene Verfahren sind die Abbildung Stimulus-Signalisierung und Funktionale-Signalisierung in der Anrufverarbeitung-Implementierung unabhängig vom gewählten Ansatz.

Das hier beschriebene Verfahren nutzt hier z.B. lediglich native SIP-Trunking-Mittel und lässt sich auch durch sogenannte "3rd-pty-SIP-Server" anwenden und ist darüber hinaus auch fähig, völlig andere Protokolle an die Anrufsteuerung einer PBX anzuschließen (z.B. "Skinny von Cisco"), um eine erweiterte Anrufsteuerung für z.B. integrierte WebRTC- Clients und deren zugeordneten Telefonen durchzuführen. Auf die verwendete Technik projiziert bedeutet dieses, dass der proprietäre WebRTC um CSTA angereicherte SIP-Teilnehmer-Tunnel des ATC durch einen nativen SIP Trunk des UTC bei gleichzeitiger Erhaltung der geplanten erweiterten Steuerung der Anrufverarbeitung vollständig ersetzt wird.

Hinsichtlich der Verwendung des Begriffes Integration ist zu bemerken, dass die Integration hier meist aus Sicht der TK-Plattform beschrieben ist, die die Möglichkeit zur Integration von z.B. WebRTC-Clients zur Verfügung stellt. Andersherum stellen Cloud- Kommunikationsserver wie "Unify Circuit" und "Skype for Business" Möglichkeiten zur Integration von TK-Plattformen zur Verfügung.

Weitere Vorteile, Merkmale und Besonderheiten der vorliegenden Erfindung ergeben sich aus der nachfolgenden Beschreibung vorteilhafter Ausführungsformen unter Bezugnahme auf die Zeichnung. Es zeigen schematisch:

Fig. 1 eine Übersichtsanordnung einer Ausführungsform eines erfindungsgemäßen Port- handlers,

Fig. 2 eine Übersichtsanordnung für die Darstellung einer "n zu 1 "-Zuordnung für Leistungsmerkmale,

Fig. 3 ein Ablaufdiagramm für die Darstellung einer "n zu 1 "-Zuordnung für eine Rückfrage,

Fig. 4 ein Verfahrensschema für im Porthandler ablaufende Schritte einer Kommunikation mit Rufrichtung von einem Client zu einem UTC,

Fig. 5 ein Ablaufdiagramm für die Darstellung einer "n zu 1 "-Zuordnung für ein Anklopfen,

Fig. 6 ein Verfahrensschema für im Porthandler ablaufende Schritte einer Kommunikation mit Rufrichtung von einem UTC zu einem Client,

Fig. 7 ein Ablaufdiagramm für die Darstellung einer "n zu 1 "-Zuordnung für eine Rufweiterschaltung,

Fig. 8 ein Ablaufdiagramm für die Darstellung einer "n zu 1 "-Zuordnung für eine Anrufübernahme,

Fig. 9 eine schematische Darstellung einer Vernetzung mittels der Nutzung von Port- handlern,

Fig. 10 eine schematische Darstellung eines Porthandlers als Rufinstanz-basierte Einheit für einen ankommenden Ruf,

Fig. 1 1 eine schematische Darstellung eines Porthandlers als Rufinstanz-basierte Einheit für das Auflegen bei einem ankommenden Ruf, Fig. 12 eine schematische Darstellung eines Porthandlers als Rufinstanz-basierte Einheit für einen abgehenden Ruf und

Fig. 13 eine schematische Darstellung eines Porthandlers als Rufinstanz-basierte Einheit bei einem abgehenden Ruf.

In Fig. 1 ist eine Ausführungsform eines erfindungsgemäßen Porthandlers 20 dargestellt, mit dem insbesondere das erfindungsgemäße Verfahren in der nachfolgend beschriebenen Weise ausgeführt wird. Der Porthandler 20 umfasst eine (zentrale) Logikeinheit L1 , mehrere Trunk-

Empfangseinheiten ET1 , ET2, mehrere Trunk-Sendeinheiten ST1 , ST2, eine Benutzer- Sendeinheit SU1 , eine Benutzer-Empfangseinheit EU1 , und eine Zuordnungstabelle (Speichereinheit) Z1 für die Zuordnung der vorgenannten Komponenten relativ zueinander. Der Porthandler 20 steht in Verbindung mit einer Datenbank DB1 für die Speicherung von Identifikationen ID und Benutzern, einem CKS-Client CI1 und einem dem Benutzer einer TK-Plattform zugeordneten Telefonie-Endpunkt 30.

Der Porthandler 20 enthält eine Steuervorrichtung 42, welche das der Erfindung zugrundeliegende Verfahren unter Verwendung eines schematisch dargestellten Computerpro- gramms 92 (gespeichert auf einer CD-ROM 90 als Beispiel für einen Datenträger) ausführt. Hierzu übergibt die Logikeinheit L1 des Porthandlers 20 einen ersten Ruf C1 über die einen ersten Trunk T1 repräsentierende erste Trunk-Empfangseinheit ET1 an die dem Benutzer U1 zugeordnete erste Sendeeinheit SU1 . Die Logikeinheit L1 ordnet durch Verarbeitung einer über die erste Trunk-Empfangseinheit ET1 empfangenen ersten Identifika- tion ID1 die erste Trunk-Empfangseinheit ET1 und den ersten Ruf C1 dem Benutzer U1 mit Hilfe der (geeignet strukturierten) Datenbasis DB1 und der Zuordnungstabelle Z1 zu. Die Logikeinheit L1 übergibt dann über die zumindest einen zweiten Trunk T2 repräsentierende zweite Trunk-Empfangseinheit ET2 zumindest einen zweiten Ruf C2 ebenfalls an die dem Benutzer U1 zugeordnete Sendeinheit SU1 , und die Logikeinheit L1 ordnet durch Verarbeitung einer über die zweite Trunk-Empfangseinheit ET2 empfangenen zweiten Identifikation ID2 die zweite Trunk-Empfangseinheit ET2 und den zumindest zweiten Ruf C2 ebenfalls dem Benutzer U1 mit Hilfe der Datenbasis DB1 und der Zuordnungstabelle Z1 zu. Schließlich führen die dem Benutzer U1 zugeordnete vermittlungstechnische Sendeeinheit SU1 und die dem Benutzer U1 zugeordnete vermittlungstechnische Empfangs- einheit EU1 mittels des Clients CI eine Anrufsteuerung von dem ersten Ruf C1 und dem zumindest einen zweiten Ruf C2 für das den Benutzer U1 repräsentierenden Telefonie- Endpunkt 30 durch. Fig. 2 stellt eine "n zu 1 "-Zuordnung für Leistungsmerkmale dar. Die Anzahl der Telefonleitungen (Call Legs) zwischen dem Client und UTC ist durch die Implementierung und/oder den Möglichkeiten von WebRTC bestimmt und unabhängig von der Systemim- plementierung. Damit ist es nicht erfindungswesentlich, ob ein CKS-Client n Verbindungen aufbaut oder n CKS-Clients je eine Verbindung zum UTC aufbauen. Der dem Benutzer einer TK-Plattform zugeordnete Endpunkt kann hierbei in den Betriebsarten "Stimulus" oder "funktional" betrieben werden. Dieses Vorgehen ermöglicht nun dem Benutzer mittels seines CKS-Clients, verschiedene Leistungsmerkmale über den letztendlich am UTC registrierten Endpunkt des Call Processings einer integrierenden TK-Plattform auszuführen.

Mittels des Porthandlers 20 wird die "normale" Benutzerinstanz im Call Processing (CP) adressiert. Damit brauchen die Kernkomponenten in CP über kein Wissen der benutzten SIP-T runks zu verfügen, es wird somit eine Trunk-Schnittstelle in eine Benutzer- Schnittstelle gewandelt.

Die Gesprächspartner 1 und 2 können wiederum einen anderen CKS-Client repräsentie- ren.

In Fig. 3 ist ein Beispiel für eine Ausführung des erfindungsgemäßen Verfahrens für die Rückfrage mit einer entsprechenden "n zu 1 "-Zuordnung für eine Rückfrage dargestellt. Eine Rufanforderung Call 1 eines CKS-Clients - repräsentiert in der TK-Plattform durch einen Benutzer (Telefonie-Endpunkt) - wurde von einem Ziel bzw. Gesprächspartner 1 der TK-Plattform angenommen. Daraufhin leitet der CKS-Client eine Rückfrage über Call 2 zu einem Ziel bzw. Gesprächspartner 2 der TK-Plattform. Optional ermöglicht eine geeignete Implementierung im Call Processing, Mitteilungen über den Zustand der Anrufverarbeitung an eine beispielweise dem CKS-Client zugeordnete Applikation zu senden.

Die Aufgabe des Porthandlers 20 beim Rufen von CKS-Clients zur TK-Plattform ist es, die assoziierte Benutzer-Instanz (Telefonie-Endpunkt) bzw. den initiierenden CKS-Client zu bestimmen bzw. zu ermitteln. Konzeptbedingt kann der Porthandler 20 als Komponente der TK-Plattform (a) oder als Komponente des UTC (b) realisiert werden. Hierzu ist fol- gendes Verfahren gem. Fig. 4 vorgesehen: In Schritt S2 empfängt der Porthandler 20 eine Meldung zur Rufanforderung für eine erste Rufanforderung Call 1 gem. Fig. 3 und Fig. 1 mit einem neuen Verbindungswunsch, wonach in Schritt S4 eine ID (bzw. eine Identifika- tion) zur Adressierung des CKS-Clients bestimmt bzw. ermittelt wird. Bei der ID kann es sich beispielsweise für Konzept (a) um die dem CKS-Client in der TK-Plattform zugeordnete eigene Rufnummer und für Konzept (b) um die der TK-Plattform des CKS-Clients zugeordnete Socket-Verbindung handeln. Danach wird in Schritt S6 die ID in der Daten- basis DB1 gesucht. Falls nach Prüfung in Schritt S8 die ID nicht gefunden wird, ist das Verfahren beendet. Anderenfalls schickt der Porthandler 20 in Schritt S10 mittels der Logikeinheit gem. Fig.1 einen Befehl an die TK-Plattform, die Benutzer-Instanz zu adressieren (a), oder einen Befehl an den UTC, einen neuen Trunk zu belegen (b). Anschließend wird in Schritt S12 in der Zuordnungstabelle Z1 die Zuordnung zwischen Trunk und Benutzer (a) oder zwischen Socket und Trunk (b) abgespeichert, womit das Verfahren beendet ist.

In Fig. 5 ist ein Beispiel für eine Ausführung des erfindungsgemäßen Verfahrens für das Anklopfen mit einer entsprechenden "n zu 1 "-Zuordnung für das Anklopfen dargestellt. Eine Rufanforderung Call 1 eines CKS-Clients - repräsentiert in der TK-Plattform durch den Benutzer (Telefonie-Endpunkt) - wurde von einem Gesprächspartner 1 der PBX angenommen. Daraufhin ruft ein Gesprächspartner 2 der TK-Plattform bei dem CKS- Client an. Der Call 2 klopft somit beim Benutzer (Telefonie-Endpunkt) an, der CKS-Client nimmt das anklopfende Gespräch entgegen. Call 1 ist weiter aktiv und im Call Processing als belegt markiert. Optional ermöglicht eine geeignete Implementierung im Call Processing, Mitteilungen über den Zustand der Anrufverarbeitung an eine beispielweise dem CKS-Client zugeordnete Applikation zu senden.

Die Aufgabe des Porthandlers 20 bei Rufen zur TK-Plattform ist es auch, die assoziierte Benutzer-Instanz bzw. die passenden Socket-Verbindung zu bestimmen und zu adressieren. Hierzu ist folgendes Verfahren gem. Fig. 6 vorgesehen: In Schritt S22 empfängt der Porthandler 20 eine Meldung zur Rufanforderung - dem Aufbau einer neuen Verbindung - wonach in Schritt S24 eine ID (bzw. ein Identifikation) zur Adressierung des CKS-Clients bestimmt bzw. ermittelt wird. Bei der ID kann es sich beispielsweise für Konzept (a) um die dem CKS-Client in der TK-Plattform zugeordnete eigene Rufnummer und für Konzept (b) um die der TK-Plattform des CKS-Clients zugeordnete Socket Verbindung handeln. Danach wird in Schritt S26 die ID in der Datenbasis DB1 gesucht. Falls nach Prüfung in Schritt S28 die ID nicht gefunden wird, ist das Verfahren beendet. Anderenfalls fügt der Porthandler 20 in Schritt S30 Adressierungsinformation gemäß Datenbasis DB1 in eine ausgehende Meldung zum CKS-Client ein. Bei der Adressierungsinformation kann es sich beispielsweise um die URL des CKS-Clients handeln. Anschließend wird in Schritt S32 in der Zuordnungstabelle Z1 die Zuordnung zwischen Benutzer und Trunk (a) oder zwischen Trunk und Socket (b) abgespeichert, womit das Verfahren beendet ist.

In Fig. 7 ist ein Beispiel für eine Ausführung des erfindungsgemäßen Verfahrens für die Rufweiterschaltung mit einer entsprechenden "n zu 1 "-Zuordnung für Rufweiterschaltung und in Fig. 8 entsprechend für die Anrufübernahme dargestellt. Jeweils eine Rufanforderung Call 1 eines CKS-Clients - repräsentiert in der TK-Plattform durch den Benutzer (Telefonie-Endpunkt) - wurde von einem Gesprächspartner 2 der PBX angenommen und ist entsprechend im Call Processing als belegt markiert.

Im Falle der Rufweiterschaltung leitet das Call Processing aufgrund eines Timers, einer Aktion einer beispielweise dem CKS-Client zugeordneten Applikation oder eines anderen vergleichbaren Ereignisses den Call 2 an ein Ziel 3 bzw. einen Gesprächspartner 3 weiter. Nimmt der Gesprächspartner 3 den Ruf an, so wird der Call 2 zum CKS-Client abgebaut.

Im Falle der Anrufübernahme signalisiert das Call Processing oder eine Applikation den Call 2 bei einem Gesprächspartner 3. Übernimmt nun Gesprächspartner 3 den Anruf aufgrund einer Aktion am Endgerät, einer Aktion einer beispielweise dem Gesprächspartner 3 zugeordneten Applikation oder eines vergleichbaren anderen Ereignisses, so wird der Call 2 zum CKS-Client abgebaut.

Die in den vorherigen Figuren dargestellten Gesprächspartner 1 , 2 und 3 können ebenfalls Repräsentanten je eines anderen CKS-Clients darstellen. Während der Ausführung von erweiterten Anrufsteuerung-Leistungsmerkmalen kann die Steuerung der Payload in der Hoheit der CKS-Clients liegen. D.h. die Payload von Call 1 kann unabhängig zu Payload von Call 2 geschaltet werden. Andererseits ist die Payload Verwaltung auch in der TK-Plattform möglich. Das beschriebene Verfahren lässt sich auch bei der Vernetzung von TK-Plattformen über native SIP verwenden (wenn ggf. keine Vernetzung mittels SIP-Q möglich ist) und ermöglicht so z.B. auch die knotenübergreifende Presence-Steuerung bzw. auch die Nutzung von Gruppen-Leistungsmerkmalen. Diese Vernetzung via Porthandler-Nutzung ist in Fig. 9 dargestellt.

Ein Mitarbeiter arbeitet gemäß einem Anwendungsbeispiel abwechselnd an den Standorten PBX1 und PBX2. Wird für ihn jetzt eine Gruppe aus jeweils einem Teilnehmer in TK- Plattform PBX1 (Telefon und Benutzer) und TK-Plattform PBX2 (Telefon und Benutzer) eingerichtet, kann sichergestellt werden, dass die Statusführung (z.B. Besetztsignalisie- rung) in beiden TK-Plattformen bei allen anderen Benutzern jeweils korrekt geführt werden kann.

Fig. 10 zeigt beispielsweise die Ausführungsform eines Porthandlers 20 als Verbindungselement zwischen einem CKS-Client (externes Interface) und einer Anrufverarbeitungseinheit (internes Interface), hier für einen ankommenden Ruf (incoming Call). Hierbei ordnet der Porthandler 20 eine über eine Trunk-Empfangseinheit ET1 (vgl. z.B. Fig. 1 ) empfangene ID eines zumindest ersten ankommenden Rufs (incoming Call) eines SIP- Trunks (SIP: Invite) dem Benutzer mit Hilfe einer Logikeinheit L1 und geeignet strukturierten Datenbasis DB1 und Zuordnungstabelle Z1 zu. Nach erfolgreicher Zuordnung wird der incoming Call über das interne Interface der Sendeeinheit SU1 an die Anrufverarbeitungseinheit und somit an das den Benutzer bzw. dessen Rufnummer repräsentierende Telefon 30 weitergeleitet (TK-Plattform intern: MakeCall / Setup). Beantwortet der Benutzer den Anruf, so empfängt der Porthandler 20 über das interne Interface der Benutzer- Empfangseinheit EU1 eine Connect -Indikation, welche über die Trunk-Sendeeinheit ST1 an den Client weitergeleitet wird (SIP: OK). Eine Rückfrage gemäß Fig. 3 und Zuordnung zur der Sende- und Empfangseinheit des internen Interfaces erfolgt nun über die Instan- zen der Empfangs- und Sendeeinheit des externen Interfaces.

Gemäß den Fig. 10 bis 13 können jeweils mehrere Instanzen von Einheiten vorgesehen sein:

Instanz der Trunk-Empfangseinheit: ETn (n=1... N) entsprechend der Call-Instanz Cn (n=1 ...N)

Instanz der Trunk-Sendeeinheit: STn (n=1... N) entsprechend der Call-Instanz Cn

(n=1 ...N)

Ähnlich wie Fig. 10 zeigen die Fig. 1 1 bis 13 Ausführungsformen eines Porthandlers 20 als Verbindungselement zwischen einem Client (externes Interface) und einer Anrufverarbeitungseinheit (internes Interface), und zwar für das Auflegen bei einem ankommenden Ruf (incoming Release), für einen abgehenden Ruf (outgoing Call) bzw. bei einem abgehenden Ruf (outgoing Release). Es versteht sich, dass bei der vorliegenden Erfindung ein Zusammenhang zwischen einerseits Merkmalen besteht, die im Zusammenhang mit Verfahrensschritten beschrieben wurden, sowie andererseits Merkmalen, die im Zusammenhang mit entsprechenden Vor- richtungen beschrieben wurden. Somit sind beschriebene Verfahrensmerkmale auch als zur Erfindung gehörige Vorrichtungsmerkmale - und umgekehrt - anzusehen, selbst wenn dies nicht explizit erwähnt wurde. Es ist festzuhalten, dass die unter Bezug auf die dargestellten Ausführungsformen beschriebenen Merkmale der Erfindung, wie beispielsweise die Art und Ausgestaltung der einzelnen Komponenten der Telekommunikationsanordnung, einzelner Nachrichten, Signale und Parameter, auch bei anderen Ausführungsformen vorhanden sein können, außer wenn es anders angegeben ist oder sich aus technischen Gründen von selbst verbietet. Von derartigen, in Kombination beschriebenen, Merkmalen einzelner Ausführungsformen müssen außerdem nicht notwendigerweise immer alle Merkmale in einer betreffenden Ausführungsform realisiert sein.

Bezugszeichenliste

20 = Porthandler

30 = Telefonie-Endpunkt

42 = Steuereinrichtung

90 = maschinenlesbarer Datenträger 92 = Computerprogramm

C1 = Ruf 1/Call 1

C2 = Ruf 2/Call 2

CI1 = Client

DB1 = Datenbasis

ET1/2 = Trunk-Empfangseinheit 1/2

EU 1/2 = Empfangseinheit

ID1/2 = ldentifikation1/2

L1 = Logikeinheit

ST1/2 = Trunk-Sendeeinheit 1/2

SU1 = Sendeeinheit

T1/2 = Trunk 1/2

U1 = Benutzer

Z1 = Zuordnungstabelle