EP1396157A1 - Programmierschnittstellen zu einer vermittlungsstelle - Google Patents

Programmierschnittstellen zu einer vermittlungsstelle

Info

Publication number
EP1396157A1
EP1396157A1 EP02740391A EP02740391A EP1396157A1 EP 1396157 A1 EP1396157 A1 EP 1396157A1 EP 02740391 A EP02740391 A EP 02740391A EP 02740391 A EP02740391 A EP 02740391A EP 1396157 A1 EP1396157 A1 EP 1396157A1
Authority
EP
European Patent Office
Prior art keywords
applications
functions
exchange
apis
platform
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02740391A
Other languages
English (en)
French (fr)
Inventor
Renate Zygan-Maus
Stefan Unger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Nokia Siemens Networks GmbH and Co KG, Siemens Corp filed Critical Siemens AG
Publication of EP1396157A1 publication Critical patent/EP1396157A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42314—Systems providing special services or facilities to subscribers in private branch exchanges
    • H04M3/42323—PBX's with CTI arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/0012—Details of application programming interfaces [API] for telephone networks; Arrangements which combine a telephonic communication equipment and a computer, i.e. computer telephony integration [CPI] arrangements
    • H04M7/0021—Details of Application Programming Interfaces

Definitions

  • Switching centers in telephone networks are typically closed systems, i.e. both the implementation of the supported functions, such as Structure of calls, charging, statistics, as well as the hardware basis are manufacturer-specific.
  • Network operator of the supported functions such as Structure of calls, charging, statistics, as well as the hardware basis are manufacturer-specific.
  • Telecommunications networks must therefore coordinate their specific requirements for switching center functions with the manufacturers, who then implement these on behalf of the network operators.
  • APIs Application Programming Interfaces
  • PARLAY PARLAY
  • JAIN JAIN
  • ITU-T International Telecommunication Union
  • 3GPP Third Generation Partnership Project
  • ETSI ETSI
  • ITU-T International Telecommunication Union
  • a classic switching center with an additional platform based on commercial hardware (HW) and software (SW), e.g. the standard operating system UNIX, on which special modules (application blocks) are implemented, whose functions can be controlled externally via open APIs.
  • This platform allows the network operator to develop their own telephone value-added services in a commercial software environment based on application programming interfaces (API) for switching center functions.
  • API application programming interfaces
  • the exchange and the commercial platform communicate via an internal interface, which is not standardized and whose functionality depends on the requirements of the software modules to be supported on the commercial platform.
  • Different applications can be implemented on the commercial platform: protocol conversion applications that can offer the standardized APIs and other applications that can offer non-standardized APIs.
  • a difference and advantage of the method according to the invention compared to existing IN SCEs and other systems that only have standardized protocol interfaces to switching centers is the possibility of basically having free access to all switching center functions via the internal interface between the commercial platform and switching center to be able to use for the implementation of the applications according to the invention on the commercial platform.
  • a second difference between the method according to the invention and existing IN SCEs and other systems that only provide standardized APIs lies in the idea of non-standardized APIs for higher-quality service functionality
  • Each of these service application blocks has access to the call processing functions of the exchange via the internal interface.
  • the basic function of a service application block is fixed, e.g. Establishing a connection in the PSTN between two subscribers that can be reached via an E.164 address, including creating a greeting or initializing fee tickets for each subscriber in the exchange.
  • open APIs enable the activation of the respective service functions as well as the control of individual performance features.
  • the service application block "Automatic establishment of a connection between two PSTN subscribers" which of the two subscribers takes over the fees, whether a standard announcement or a personal announcement is to be played as a greeting (requires transmission of the address and identification of the personal announcement ) or whether status information about the connection should be reported back via the API (e.g. subscriber busy)
  • the method according to the invention therefore includes the approach of not opening the call processing functions of a switching center directly to the outside via APIs, but first of all to define service application blocks on the commercial platform belonging to the switching center, in which the service-specific interworking with the existing network functions and their functions are solved can be controlled via open APIs.
  • Network operators can activate and combine these service application blocks as desired and thus create new value-added services.
  • the actual service logic of the one created by the network operator Value-added service on any server in the network.
  • the service application blocks with their defined APIs serve the network operator as building blocks for implementing their own value-added services (see exemplary embodiment under 5.)
  • the interworking of the service application blocks with each other is supported by a so-called session manager application block. All application blocks that process active service requests via their API make a registration for every active service user in Session Manager.
  • the Session Manager offers an internal API for this. If a service request is ended, a deregistration takes place.
  • the session manager thus always has a current image of all active service requests. Its data can be read by any application and thus support interworking between different service application blocks.
  • a major advantage of this method is that the user of the APIs for service application blocks does not have to have detailed knowledge of existing network functions. In particular, all details of the respective signaling system of the basic network are completely transparent at the level of the API user, and the internal interaction between the switching center and application block covers all possible interworking cases.
  • This method allows the definition of robust and easy-to-use APIs, since the defined scope of each service application block or API limits possible errors and can be tested by the manufacturer.
  • the standardized APIs PARLAY, JAIN, 3GPP, etc.
  • These APIs are very complex and require the transfer or control of a great deal of control information.
  • the figure shows the basic division of functions between the switching center with an integrated commercial platform that offers open APIs (backend server) and the external application servers that use these APIs (front end server).
  • the commercial platform contains several application blocks with a defined range of functions that can be controlled using open APIs.
  • the functions of the application blocks use the core call control functions of the underlying exchange via an internal interface.
  • the network operator's value-added services are implemented on separate application servers in the network. They use the open APIs of the commercial platform to initiate actions in the basic network (eg establishing a connection between two participants) or via events in the basic network to be informed (e.g. subscriber busy, incoming call).
  • the open APIs are used on the basis of CORBA - this means that the implementation of the software on the application server and its hardware is independent of the software and hardware of the commercial platform.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Exchange Systems With Centralized Control (AREA)

Abstract

Gemäss der Erfindung wird eine klassische Vermittlungsstelle mit einer zusätzlichen Plattform auf Basis kommerzieller Hardware und Software ergänzt, auf der spezielle Module implementiert werden, deren Funktionen extern über offene Application Programming Interfaces (API) gesteuert werden können. Diese Plattform erlaubt so dem Netzbetreiber die Entwicklung eigener Telefonmehrwertdienste in einer kommerziellen Software Umgebung auf der Basis von APIs zu Vermittlungsstellenfunktionen.

Description

Beschreibung
Programmierschittstellen zu einer Vermittlungsstelle
1. Welches technische Problem wird durch die Erfindung gelöst ?
Vermittlungsstellen in Telefonnetzen sind typischerweise geschlossene Systeme, d.h. sowohl die Realisierung der unterstützten Funktionen, wie z.B. Aufbau von Rufen, Vergebührung, Statistik, als auch die Hardwarebasis sind herstellerspezifisch. Netzbetreiber von
Telekommunikationsnetzen müssen daher ihre spezifischen Anforderungen an Vermittlungsstellenfunktionen mit den Herstellern absprechen, die diese dann im Auftrag der Netzbetreiber realisieren.
In zunehmendem Maße fordern daher die Netzbetreiber, daß die Telekommunikationsausrüster sowohl als Basis Ihrer Vermittlungsstellen kommerzielle Plattformen verwenden als auch die Funktionen auf diesen Plattformen für eine Steuerung von "außen" öffnen, d.h. der Netzbetreiber selbst oder von ihm beauftragte Programmierer sollen über geeignete Schnittstellen selbst die Funktionen der Plattformen steuern oder erweitern können.
Einer der Hauptgründe für diese Forderung nach Offenheit, ist der Konkurrenzdruck der Netzbetreiber in liberalisierten Netzen. Die Netzbetreiber versuchen sich daher primär durch neue attraktive Mehrwertdienste voneinander zu differenzieren. Dabei ist es wichtig, Betreiberspezifische neue Mehrwertdienste schnell einführen zu können. Die Netzbetreiber fordern daher offene Schnittstellen, damit sie selbst Mehrwertdienste implementieren können. 2. Wie wurde das genannte Problem bisher gelöst ?
Wie oben erwähnt, waren bisher Vermittlungsstellen geschlossene Systeme, d.h. offene APIs sind nicht vorhanden. Neue Dienste der Vermittlungsstellen haben die Telekommunikationsausrüster entwickelt und kundenspezifische Entwicklungen im Auftrag eines Netzbetreibers waren aus wirtschaftlichen Gründen nur in begrenztem Maße möglich. Daneben wird von vielen Vermittlungsstellen eine für Dienstesteuerung standardisierte SS7- Protokollschnittstelle zu externen IN-Systemen unterstützt (INAP - Intelligent Network Application Protocol) . Von vielen IN-Herstellern wird für diese IN-Systeme ein Service Creation Environment angeboten, das eine IN-Dienst-Programmerstellung durch den Netzbetreiber selbst oder eine von ihm beauftragte SW-Firma ermöglicht. IN Service Creation Systeme haben sich am Markt nicht durchgesetzt. Als ein wesentlicher Grund dafür wird u.a. die bei der Nutzung dieser Systeme erfahrene Komplexität der Diensteprogrammierung angesehen. Seit kurzer Zeit gibt es Bemühungen, zusätzlich zu dem standardisierten INAP - Protokoll und anderen standardisierten Protokollen in öffentlichen
Telekommunikationsnetzen auch Programmierschnittstellen
(Application Programming Interfaces, APIs) für Telekommunikationsanwendungen zu standardisieren. Zunächst in Interessengruppen der Industrie, z.B. PARLAY, JAIN, und nun auch in internationalen Standardisierungsgremien wie 3GPP, ETSI und ITU-T. Diese standardisierten APIs bilden die Funktionalität der unterliegenden Protokolle als Programmierschnittstelle ab. Inwieweit sich die Nutzung dieser APIs am Markt durchsetzen wird, ist offen. 3. In welcher Weise löst Ihre Erfindung das angegebene technische Problem ?
Gemäß der Erfindung wird eine klassische Vermittlungsstelle mit einer zusätzlichen Plattform auf Basis kommerzieller Hardware (HW) und Software (SW) , z.B. das Standard Operating System UNIX, ergänzt, auf der spezielle Module (Applikationsblöcke) implementiert werden, deren Funktionen extern über offene APIs gesteuert werden können. Diese Plattform erlaubt so dem Netzbetreiber die Entwicklung eigener Telefonmehrwertdienste in einer kommerziellen SW Umgebung auf der Basis von Application Programming Interfaces (API) zu Vermittlungsstellenfunktionen. Vermittlungsstelle und kommerzielle Plattform kommunizieren über eine interne Schnittstelle, die nicht standardisiert ist und deren Funktionalität sich nach den Anforderungen der zu unterstützenden SW-Module auf der kommerziellen Plattform richtet. Auf der kommerziellen Plattform können unterschiedliche Applikationen implementiert werden: Protokollumsetzungs-Applikationen, die die standardisierten APIs anbieten können und andere Applikationen, die nich - standardisierte APIs anbieten können.
Ein Unterschied und Vorteil des erfindungsgemäßen Verfahrens gegenüber existierenden IN SCEs und anderen Systemen, die nur über standardisierte Protokoll-Schnittstellen zu Vermittlungsstellen verfügen, liegt in der Möglichkeit, über die interne Schnittstelle zwischen kommerzieller Plattform und Vermittlungsstelle grundsätzlich freien Zugang zu allen Vermittlungsstellenfunktionen zu haben und diese für die Implementierung der erfindungsgemäßen Applikationen auf der kommerziellen Plattform nutzen zu können.
Ein zweiter Unterschied des erfindungsgemäßen Verfahrens gegenüber existierenden IN SCEs und anderen Systemen, die nur standardisierte APIs bereitstellen, liegt in der Idee, nicht- standardisierte APIs zu höherwertiger Dienstefunktionalität zur Verfügung zu stellen, wie z.B. den automatischen Aufbau einer Verbindung zwischen zwei PSTN-Teilnehmern, den automatischen Aufbau einer Telefonkonferenz zwischen mehreren Teilnehmen, das Buchen einer automatischen Telefonkonferenz für einen bestimmten Zeitpunkt.
Jeder dieser Dienstapplikationsblöcke hat über die interne Schnittstelle Zugriff zu den Call Processing Funktionen der Vermittlungsstelle. Die Grundfunktion eines Dienstapplikationsblocks ist fest definiert, wie z.B. Aufbau einer Verbindung im PSTN zwischen zwei Teilnehmern die über eine E.164 Adresse erreicht werden können inklusive dem Anlegen einer Begrüßungsansage oder Initialisierung von Gebührentickets für jeden Teilnehmer in der Vermittlungsstelle . Je Dienstapplikationsblock ermöglichen offene APIs das Aktivieren der jeweiligen Dienstfunktionen sowie die Steuerung einzelner Leistungsmerkmale. Beispielsweise könnte für den Dienstapplikationsblock "Automatischer Aufbau einer Verbindung zwischen zwei PSTN-Teilnehmern" explizit steuerbar sein, welcher der beiden Verbindungsteilnehmer die Gebühren übernimmt, ob zur Begrüßung eine Standardansage oder eine persönliche Ansage gespielt werden soll (erfordert Übertragung der Adresse und Identifikation der persönlichen Ansage) oder ob über das API Statusinformationen der Verbindung zurückgemeldet werden sollen (z.B. Teilnehmer besetzt)
Das erfindungsgemäßen Verfahren beinhaltet also den Ansatz, die Call Processing Funktionen einer Vermittlungsstelle nicht direkt über APIs nach außen zu öffnen, sondern zunächst Dienstapplikationsblδcke auf der zur Vermittlungsstelle gehörenden kommerziellen Plattform zu definieren, in denen das dienstspezifische Interworking mit den existierenden Netzfunktionen gelöst wird und deren Funktionen über offene APIs gesteuert werden können. Netzbetreiber können diese Dienstapplikationsblδcke beliebig aktivieren und kombinieren und so neue Mehrwertdienste kreieren. Dabei kann die eigentliche Dienstlogik des vom Netzbetreiber erstellten Mehrwertdienstes auf einem beliebigen Server im Netz liegen. Die Dienstapplikationsblöcke mit ihren definierten APIs dienen dem Netzbetreiber dabei als Bausteine zur Implementierung eigener Mehrwertdienste (siehe Ausführungsbeispiel unter 5. )
Das Interworking der Dienstapplikationsblöcke untereinander wird durch einen sogenannten Session Manager Applikationsblock unterstützt. Alle Applikationsblöcke, die über ihr API aktive Dienstanfragen bearbeiten, nehmen eine Registrierung für jeden aktiven Dienstnutzer im Session Manager vor. Der Session Manager bietet dafür ein internes API an. Wird eine Dienstanfrage beendet, erfolgt eine Deregistrierung. Der Session Manager hat somit jeweils ein aktuelles Abbild aller aktiven Diensteanfragen. Seine Daten können von jeder Applikation gelesen werden, und unterstützen so das Interworking zwischen verschiedenen Dienstapplikationsblöcken .
Ein wesentlicher Vorteil dieses Verfahrens ist, daß der Anwender der APIs zu Dienstapplikationsblöcken keine Detailkenntnisse über existierende Netzfunktionen haben muß. Insbesondere sind auch alle Details des jeweiligen Signalisierungssystems des Basisnetzes auf der Ebene des API Nutzers vollständig transparent und das interne Zusammenspiel zwischen Vermittlungsstelle und Applikationsblock deckt alle möglichen Interworkingfälle ab. Dieses Verfahren erlaubt die Definition von robusten und leicht handhabbaren APIs, da der festgelegte Umfang jedes Dienstapplikationsblocks bzw. APIs mögliche Fehlerfälle einschränkt und vom Hersteller ausgetestet werden kann. Im Gegensatz zu den erfindungsgemäßen APIs zu höherwertigen Dienstapplikationsblöcken basieren die standardisierten APIs (PARLAY, JAIN, 3GPP, u.a.) auf dem Ansatz, Protokollfunktionen abzubilden. Diese APIs sind sehr komplex und erfordern die Übertragung bzw. Steuerung von sehr vielen Steuerinformationen. Die Realisierung von Mehrwertdiensten auf Basis dieser APIs erfordert Telekommunikationsnetz- Expertenwissen. Durch die Ergänzung einer klassischen Vermittlungsstellenarchitektur mit einer kommerziellen Plattform, über die APIs zu den Vermittlungsstellenfunktionen zur Verfügung gestellt werden, ist es leichter möglich, die APIs auf Basis der state-of-the Art objektorientierten SW- Technologien wie CORBA, JAVA RMI oder DCOM zu realisieren. Bisherige Vermittlungsstellen basieren oft auf älteren SW- Technologien (z.B. CHILL, ASSEMBLER) die eine Öffnung über objektorientierte basierte APIs erschweren.
Durch die Konzeption von nicht-standardisierten, offenen APIs zu höherwertigen Dienstapplikationsblöcken auf dieser kommerziellen Plattform wird der Kreis der potentiellen Anwender von Telekommunikations-APIs erweitert auf Personen ohne Detailkenntnisse über Telekommunikationsnetzfunktionen.
Im folgenden wird die Erfindung nochmals anhand der Zeichnung erläutert, die eine Figur umfaßt.
Die Figur zeigt die prinzipielle Funktionsaufteilung zwischen der Vermittlungsstelle mit integrierter kommerzieller Plattform, die offene APIs anbietet (Backend Server) und und den externen Applikationsservern, die diese APIs nutzen (Frontend Server) .
Die kommerzielle Plattform enthält mehrere Applikationsblöcke mit fest definiertem Funktionsumfang, die mittels offenen APIs gesteuert werden können. Die Funktionen der Applikationsblöcke verwenden über eine interne Schnittstelle die Core Call Control Funktionen der unterliegenden Vermittlungsstelle .
Die Mehrwertdienste des Netzbetreibers werden auf separaten Applikationsservern im Netz realisiert. Dabei verwenden sie die offe'nen APIs der kommerziellen Plattform um Aktionen im Basisnetz zu initiieren (z.B. Aufbau einer Verbindung zwischen zwei Teilnehmern) oder über Ereignisse im Basisnetz informiert zu werden (z.B. Teilnehmer besetzt, ankommender Ruf) . Die offenen APIs werden auf Basis von CORBA genutzt - damit ist die Realisierung der SW auf den ApplikationsServern als auch dessen HW unabhängig von SW und HW der kommerziellen Plattform.
Abkürzungen/Referenzen:
API Application Programming Interface
CORBA Common Object Request Broker Architecture DCOM Distributed Component Object Model
IN Intelligent Networks
INAP Intelligent Network Application Protocol (standardisiert bei ETSI und ITU-T)
JAIN Industriekonsortium (von der Firma SUN geleitet) : www. java . sun . com/products/jain/
PARLAY Industriekonsortium: www.parlay. org
PSTN Public Switching Telecommunication Network
RMI Remote Message Invocation
SCE Service Creation Environment

Claims

Patentansprüche
1. Vermittlungsstelle, mit einer zusätzlichen Plattform, die auf kommerzieller HW und SW basiert und ein oder mehrere SW-Module enthält, die externen Rechnern über offene Schnittstellen (API) Applikationen mit bestimmten Funktionen zur Verfügung stellen, wobei die genannten SW-Module zur Durchführung der genannten Funktionen interne Schnittstellen zu den Call-Control-Funktionen der Vermittlungsstelle benutzen.
2. Vermittlungsstelle nach Anspruch 1, dadurch ge e nzeic net, daß die genannten offenen Schnittstellen auf der Basis einer objektorientierten SW-Technologie realisiert sind.
3. Vermittlungsstelle nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die genannten offenen Schnittstellen auch lokal auf der kommerziellen Plattform von Applikationen verwendet werden können um Funktionen anderer Applikationen zu nutzen.
4. Vermittlungsstelle nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß ein dediziertes SW-Modul auf der kommerziellen Plattform das Interworking der genannten Applikationen unterstützt. Das Interworking SW-Modul stellt dafür eine Plattform-interne Schnittstelle zur Verfügung.
5. Vermittlungsstelle nach einem der Ansprüche 1 bis 4, dadurch geken zeichnet, daß es sich bei den genannten Applikationen um
Protokollumsetzungs-Applikationen handelt .
6. Vermittlungsstelle nach einem der Ansprüche 1 bis 4, dadurch geke nzeichnet, daß es sich bei den genannten Applikationen um Applikationen für eine hoherwertige Dienstfunktionalität handelt.
EP02740391A 2001-06-13 2002-06-11 Programmierschnittstellen zu einer vermittlungsstelle Withdrawn EP1396157A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10128726 2001-06-13
DE10128726 2001-06-13
PCT/DE2002/002130 WO2002102092A1 (de) 2001-06-13 2002-06-11 Programmierschnittstellen zu einer vermittlungsstelle

Publications (1)

Publication Number Publication Date
EP1396157A1 true EP1396157A1 (de) 2004-03-10

Family

ID=7688176

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02740391A Withdrawn EP1396157A1 (de) 2001-06-13 2002-06-11 Programmierschnittstellen zu einer vermittlungsstelle

Country Status (3)

Country Link
US (1) US20040123307A1 (de)
EP (1) EP1396157A1 (de)
WO (1) WO2002102092A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12412568B1 (en) * 2023-05-23 2025-09-09 Zoom Communications, Inc. Integrating an application programming interface with a contact center

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6418146B1 (en) * 1999-12-10 2002-07-09 Genesys Telecommunications Laboratories, Inc. Integrated communication center functionality for WAP devices
EP1123614B1 (de) * 1998-10-19 2011-03-09 Nokia Siemens Networks GmbH & Co. KG Netzarchitektur für kommunikations- und/oder datennetze
US6697858B1 (en) * 2000-08-14 2004-02-24 Telephony@Work Call center

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO02102092A1 *

Also Published As

Publication number Publication date
US20040123307A1 (en) 2004-06-24
WO2002102092A1 (de) 2002-12-19

Similar Documents

Publication Publication Date Title
DE69733543T2 (de) Verfahren zum Anbieten von wenigstens einem Dienst an Fernmeldenetzbenutzern
DE60031788T2 (de) System zur bereitstellung vor diensten
DE69516155T2 (de) Ein intelligentes telekommunikationsnetzwerk
DE69022354T2 (de) Technik zur automatischen Integration von Sprach-/Daten- Signalen, welche durch einen Teilnehmer programmiert werden können, für Kommunikationssysteme.
DE69807456T2 (de) Vermittlungsdienststeuerpunkt in einem intelligenten netz
DE69732221T2 (de) Verfahren zum Anbieten von einem Dienst an Fernmeldenetzbenutzern
DE19919976B4 (de) Verfahren und Vorrichtung zum Übertragen eines eingebetteten Nebenstellensystems auf einen Personalcomputer
DE69836169T2 (de) Verfahren und System zur Implementierung intelligenter Telekommunikations-Dienstleistungen
DE19626131A1 (de) Verfahren zum Einbringen eines Telekommunikations-Dienstes sowie Dienst-Einheit, Dienstrechner, Endgerät und Kommunikationsnetz
DE69733893T2 (de) System und verfahren zur kontrollierten medienumstezung in einem intelligenten netzwerk
EP0762784B1 (de) Verfahren zur Bereitstellung von Nachrichten zur Teilnehmerinformation für Dienste in einem Kommunikationsnetz
EP0813330A2 (de) Verbindungsaufbauverfahren sowie Vermittlungsstelle, Dienstrechner und Kommunikationsnetz
WO2002102092A1 (de) Programmierschnittstellen zu einer vermittlungsstelle
DE69920912T2 (de) Telekommunikationssystem zum bereitstellen von in- und nicht-in-diensten
EP0878972B1 (de) Teilnehmeranschlussnetz, Vermittlungsstelle, Dienststeuereinrichtung und Verbindungsaufbauverfahren
EP0734186A2 (de) Verfahren zum Steuern eines Zugangsnetzes sowie Zugangsnetze und Vermittlungsstelle dafür
DE10106914A1 (de) Automatisiertes R-Gespräch
DE202011003225U1 (de) Telefonanlage mit einer Anrufverarbeitungseinheit
EP1123614B1 (de) Netzarchitektur für kommunikations- und/oder datennetze
DE10145987B4 (de) Verfahren zur Auswahl eines Leistungsmerkmals und zugehörige Einheiten
DE69333465T2 (de) Intelligente Netz-Architektur
DE10001417A1 (de) Verfahren, Vermittlungsstelle, Diensterechner, Programm-Modul und Schnittstelleneinrichtung zur Übermittlung von Telekommunikationsdienst-Daten zwischen einer Vermittlungsstelle und einem Diensterechner
DE19953221A1 (de) Verfahren, Netzwerkeinrichtung und Vermittlungsstelle zur Übermittlung einer individuellen, einen Anrufer identifizierenden Nachricht an einen angerufenen Teilnehmer
EP1077003B1 (de) Verfahren zur steuerung von telekommunikationsdiensten
EP1232656B1 (de) Verfahren zur ansteuerung von servern

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20031114

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20040611

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

APAM Information on closure of appeal procedure modified

Free format text: ORIGINAL CODE: EPIDOSCNOA9E

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20080208