WO2003084199A1

WO2003084199A1 - Telecommunication system comprising platform for activation and control of telephony services

Info

Publication number: WO2003084199A1
Application number: PCT/EP2003/001747
Authority: WO
Inventors: Martin Remco Van Der Werff; Matthijs Raymond Vonder; Bram Dirk Van Der Waaij
Original assignee: Koninklijke Kpn N.V.
Priority date: 2002-03-29
Filing date: 2003-02-19
Publication date: 2003-10-09
Also published as: AU2003210326A1

Abstract

Services platform (3) linking a services network (1) with a telephony network (2) and providing, to components (4,5) of the services network, access to components (PSTN, GPRS, UMTS, INMARSAT etc) of the telephony network. First adapters (9) invoke telephony components using several different telephony related protocols, while second adapters (13) invoke service components (11) using different protocols. Service components (11) are fit for execution of a consistent set of actions in the telephony network (2), communicated to and/or from the telephony network via the relevant first protocol adapter or adapters (9), under control of said components (4, 5) of the services network, communicated to and/or from the services network via the relevant second protocol adapter of adapters (13). The service components preferably are implemented as Enterprise JAVA Beans (EJB): the first and-or second adapters (9) Message Driven beans, and the service components (11) Session Driven (SD) beans, exchanging data with one or more Entity beans (14).

Description

TELECOMMUNICATION SYSTEM COMPRISING PLATFORM FOR ACTIVATION AND CONTROL OF TELE PHONY SERVICES

Field of the invention

The invention refers to a telecommunication system. 5

Background

In the past years, the world of telecommunications has rapidly evolved, not in the least due to the success of services networks like the Internet and the World Wide Web. These developments have led to the widespread belief that telecom operators should place their

10 money on advanced multimedia services, content delivery networks and other service innovations. However, at this time most telecom operators still get their main revenues from what is derogatively labeled as the Plain Old Telephony Service (POTS). As predicted, the Internet is used as a huge information resource by a growing number of users. But once information is gathered and decisions need to be made most people apparently still have a

15 preference for person-to-person contact, resulting in a growing amount of telephone calls. As a result, the incumbent telecom operators have come to consider their traditional Public Switched Telephony Network (PSTN) as the proverbial goose laying golden eggs.

Notwithstanding the above, the way in which people make telephone calls is changing. Ten 20 years ago, one initiated a telephone call by dialing the phone number of another person. The phone number was already known by the calling party, retrieved from a phone book or gotten through directory assistance. In some case the call was set up by operator intervention but those were about all available flavors of telephone calls. Nowadays a fair percentage of telephone calls is initiated in another way. Examples include: 25

- 800/900 call: The calling party dials a special phone number that is routed via a value added services platform. For instance 800 CALL4PIZZA might connect the caller to the nearest pizza delivery restaurant. With 800/900 calls the calling party typically does not want to speak to a specific person but is after a service or a product. In general different tariffs apply to 800/900

30 calls. Information providers often use 900 calls as a billing solution.

- Third party call: The call is not directly initiated by one of the two parties dialing a phone number. Instead a third party that has an interest in the two parties engaging in a phone conversation initiates it. For instance, a call center application automatically dials phone

35 numbers from a database and then connects the call to a call center agent as soon as the phone is picked up.

As a result, it seems obvious that telecom operators can increase their revenues from their PSTN by offering more advanced ways of initiating and/or terminating phone calls as is traditionally offered. As such, minor investments in enhancing the existing PSTN will transform it into an even bigger cash cow.

Voice services are traditionally offered via the PSTN that in essence consists of a transmission network and a separated signaling network. The transmission network carries the actual voice data while the signaling network carries the data required for controlling telephone calls. The signaling network, known as the SS#7 network (Signaling System No.7) is packet switched and is divided into protocol layers that are somewhat similar to the protocol stacks used in generic data networks. The lower layers offer functionality similar to the IP protocol. The upper layers are divided into so called user parts that are defined for specific services. Examples of those user parts are ISUP (ISDN User Part) and MAP (Mobile Application Protocol) used for controlling telephone calls in fixed and mobile networks. These user parts are used by applications residing in switches and other network elements to exchange data and invoke procedures, such as letting the phone ring at the far end.

To offer more flexible telephony services the PSTN is enhanced over the years using so called Intelligent Network (IN) technology. IN resides on top of the SS#7 network using INAP (Intelligent Network Application Protocol) as a means of communication between the traditional network elements and more generic computing systems. In its bare essence, IN should be considered as a concept to hook up generic computing capabilities to the PSTN. So instead of merely setting up a phone call to the number dialed by the calling party, more advanced options are available. Examples are looking up the dialed number in a database to find out whether special actions are required for this phone call. The introduction of IN has led to a significant boom in value added services, such as 800/900 services, personal numbering schemes and many others. It is important to realize that IN enhances the basic call model. This means a phone call still starts with a person dialing a phone number, after which IN kicks in to optionally set up or terminate the call in a non-standard manner. In the recent years, the PSTN got competition from mobile networks such as GSM/GPRS and satellite networks and the UMTS network in the near future. To provide value added voice services, these network technologies incorporate the same IN technology as used for the PSTN.

The PSTN as well as the mobile networks are specialized telephony networks, which means they are specifically designed to support telephone calls and value added services for telephony. In the recent years, technology has come available to support telephone calls over generic data networks, the most prominent of those being IP, ATM, and xDSL. These technologies are commonly known as Voice over IP (VoIP), Voice over ATM (VoATM) and Voice over DSL (VoDSL). The main difference with traditional telephony networks is that both control and voice data is carried over the same network instead of having a separate control network. Especially VoIP has been in the public eye because of its potential to provide telephone calls over the public Internet, thus allowing users to make international phone calls at very low rates. However, the current state of the technology does not allow for good quality service over public infrastructures. Nowadays, VoIP and VoATM are used in private networks such as local area networks at office locations.

PSTN and mobile networks are only within reach of telecom operators. Significant investments and government licenses are required to install a network. Recent developments have focused on the conception that telecom operators will create more revenues if other parties can also use their networks. This has led to the definition of standards commonly known as Parlay/OSA. Parlay is an initiative to define open interfaces that allow third parties to control public networks. OSA (Open Service Access) is a similar initiative specifically defined for opening up control of the third generation of mobile networks. The specifications of the open interfaces are almost identical. Therefore both initiatives are usually mentioned in the same breath.

These standards define interfaces on top of public networks that allow the use of network features from outside the network domain. A related initiative is JAIN (JAVA APIs for Integrated Networks), started by SUN Microsystems. JAIN aims to bring the control of telephony services into the JAVA domain by specifying JAVA APIs on top of IN and other control features. However, these technologies are fairly new and not yet widespread in existing networks.

On the other side of the spectrum are those parties that add value to existing voice services. When implemented within the networks these services typically take a long time to develop. From a technological perspective, implementing a service within the network should be done with great care because adding a feature to the network might disrupt the entire network. From a business perspective, adding a service to the network is only feasible when there is a large user base. Services aimed at relatively small markets are too costly to be implemented within the network. As a result, quick service innovations can only be realized when they are implemented outside the network. Telecom operators might implement these services themselves, but there is a growing market for services implemented by third parties.

In most cases a third party has difficulty in obtaining personnel with a detailed knowledge of the telecom specific technologies used in the telephony networks. And even for telecom operators there is an economical incentive to use telecom engineers for maintaining and implementing the network infrastructures and have services implemented by engineers with a more generic programming background, simply because there are more of them. As a result, both telecom operators and third parties desire to implement services using generic computing technology for which tool support is widely available within the services network domain and programming staff can be easily found. Examples of these technologies are the widespread HTTP protocol, generic messaging solutions or the SOAP (Simple Object Access Protocol).

Summary One aspect of the present invention is to fill the gap between the service development environment, incorporated in the services network (Internet, World Wide Web), and the actual voice networks and their control features.

Another aspect of the invention is to provide access to service components that bring functionality from telephony networks to the domain of service developers by presenting a services platform linked to the telephony network at the one side and to the non-voice services domain, the services network, at the other side.

Yet another aspect of the invention is to provide a platform for linking the telephony domain and the non-voice services domain using different types of protocols, both at the telephony side and at the non-telephony services side.

The interlinking services platform brings telephony features into the domain of the (third party) service developers, residing in the services network (Internet etc.). By providing these features based on different technologies and/or protocols, the service developers can use the preferred technology and toolkit while they only need a basic understanding of the required telephony features. One more important aspect of the invention is to provide a secure shielding of the telephony network from the service developers in the services network. By such a shielding errors made by those (rather un-skilled) service developers will not disrupt the basic services of the telephony network.

The services platform preferrably has a modular design, allowing the platform to be implemented on different networks. Thus the platform hooks up to available protocols that provide network features. Preferrably a generic model of these features is used within the services platform platform. Adapters may be added to connect to newly emerging telephony network technologies. With the same ease, adapters towards the services network may be added to keep in track with emerging software engineering tools and technologies.

Preferrably, the services platform comprises first protocol adapters, fit to exchange data messages with components of the telephony , network using several different telephony related protocols, second protocol adapters, fit for the exchange of data messages with said service components of the services network using several different service protocols, and

-service omponents, eact of tiτem being fit for the execution of a dedicated, consistent set of actions in the telephony network, communicated to and/or from the telephony network via the relevant first protocol adapter or adapters, under control of said components of the services network, communicated to and/or from the services network via the relevant second protocol adapter or adapters. The services platform preferably has a "layer structure" comprising a Common Telephony Network Layer, comprising said first protocol adapters, a Common Services Network Layer, comprising said second protocol adapters and a Common Common Service Components Layer, comprising said service components.

The first protocol adapters preferably are implemented as asynchronous modules, preventing, by asynchronous input-output actions of the data messages, direct control over the telephony network by service network developers. Preferrably, also the second protocol adapters are asynchronous modules. By asynchronous message handling a (double) security shield is created between the services network and the (complex) telephony network.

The various components of the services platform preferably are implemented as Enterprise JAVA Beans (EJBs), software modules developed by Sun Microsystems, Inc. (to be discussed below).

The services platform preferably is part of some kind of telecommunication system, e.g. a services network like the Internet, and/or a telephony network, e.g. PSTN, UMTS etc.

The invention also comprises a method for linking a services network with a telephony network, comprising steps of

• converting, within first protocol adapters, relevant telephony related protocols used by components of the telephony network into a Common Telephony Network Protocol and vice versa;

• converting, within second protocol adapters, relevant services network protocols, used by service components of the services network into a Common Services Network

Protocol and vice versa, and

• executing, within service components, a set of actions in the telephony network, communicated to and/or from the telephony network via the relevant first protocol adapter or adapters, under control of said components of the services network, communicated to and/or from the services network via the relevant second protocol adapter or adapters.

Besides a system and a method, the invention also comprises a software architecture for linking a services network with a telephony network, comprising • first protocol adapter modules fit for converting relevant telephony related protocols used by components of the telephony network into a Common Telephony Network

Protocol and vice versa; • second protocol adapter modules fit for converting relevant services network protocols, used by service components of the services network into a Common Services Network Protocol and vice versa, and

• service component modules fit for executing a set of actions in the telephony network, communicated to and/or from the telephony network via the relevant first protocol adapter module or modules, under control of said components of the services network, communicated to and/or from the services network via the relevant second protocol adapter module or modules.

Brief Description of the Drawings

Figure 1 shows schematically the preferred positioning of the services platform.

Figure 2 shows an exemplary embodiment of the services platform.

Figure 3 shows a more elaborated exemplary embodiment of the architecture of the services platform.

Detailed Description of the Drawings Figure 1 shows a data based services network 1, e.g. the Internet, a public telecommunications network 2, incorporating networks like networks enabled for VoIP, VoATM, PSTN, ISDN, GSM, GPRS, UMTS, Satellite communicatiions (INMARSAT etc.), and an interlinking services platform 3, incorporated in one or more platform servers.

To the services network 1 are connected several (retail) servers 4 and end user terminals 5, which can connect to each other and to the services platform 3. Use may be made of several protocols, e.g. SOAP, messaging (e.g. email), HTTP etc. to activate several services, like click- to-dial, personal number, call screening, chat connect etc.

To the telephony network 2 may be connected several kinds of telephony terminals e.g. terminals 6 for fixed telephony or terminals 7 for mobile telephony.

The services platform 3 is enabled to communicate with control means of the telephony network 2 using several protocols, e.g. Parlay/OSA, INAP, JAIN, etc. Under control of the servers 4 and/or terminals 5, the requested services, like click-to-dial, chat connect etc. may be activated under control of services network compatible client and/or server software modules, using the services network related protocols like HTTP, SOAP etc., which are translated by the services platform 3 into telephony related protocols like Parlay, JAIN etc., which control the relevant network components of the PSTN, ISDN, GSM, GPRS etc, Figure 2 shows a exemplary embodiment of the services platform 3. The services platform preferrably has a modular design as is depicted in figure 2.

A Common Telephony Network Layer 8 comprises network adapters 9 that are defined to connect the platform 3 to the telephony network 4 or certain distinct parts of it, e.g. PSTN, GPRS, UMTS, INMARSAT etc. Each network adapter 9 is enabled to convert data using a relevant protocol into data ruled by one Common Telephony Network Protocol and vice versa, where applicable, to convert data using the Common Telephony Network Protocol into data ruled by the protocol valid for the relevant telephony network component. Different network adapters 9, e.g. software modules, can be defined, implemented and added to the platform at any stage. Any new network adapter 9 will achieve the following:

Connect another network to the WebTel platform without adding functionality. In this case, no new capabilities become available, but the existing capabilities become available in another network.

Provide new functionality to the WebTel platform. In this case, new service components may be developed once the new network adapter is finalized.

The same kind of modular design applies to a Common Service Components Layer 10 comprising service components 11 fit for different kinds of telephony related services. The service components 11 can be established at any time. Adding a new service component 11 will provide new (telephony) features to the service developers (residing in the services network domain 1). Preferred service components 11 are e.g.:

"ConnectAB", providing basic call control to a service developer. The service developer invokes the component with two parameters representing phone numbers. The service developer can now easily set up a telephone call from within an application.

"AcallsB, allowing the service developer to be notified of telephone calls being set up in the network. A service developer can implement applications that perform actions once a specific number is dialed. An example of such an application would be a call screening application.

"Rulebased routing", enabling to update a set of rules that control the actual calls in the network. This component relieves the service developer of having to implement an application with real-time needs because there is no requirement for the application to respond within the timeframe of the few seconds it would take to set up a telephone call. A Common Services Network Layer 12 comprises several service adapters 13, each of them defining the actual protocol and access method that a service developer needs to invoke a specific service component 11. Each service adapter 13 is enabled to convert data using a relevant network protocol into (data ruled by) one Common Services Network Protocol and vice versa, where applicable, to convert data using the Common ServicesNetwork Protocol into data using the protocol valid for the relevant services network component 11. Different service adapters 13, e.g. software modules, can be defined, implemented and added to the platform at any stage. Adding a new service adapter 13 does not provide new features to the service developer but does provide a new access protocol and/or access method. An example of such a service adapter is the SOAP adapter that allows service developers to invoke service components using the SOAP protocol. As SOAP is nowadays embedded in various development environments, this greatly simplifies life of a service developer.

The service components 11 running in the Common Service Components Layer 10 define the actual functionality offered by the services platform 3 to the servers 4 and user terminals 5 in the services network 1. The service components may be rather basic, such as "ConnectA-to-B" ("ConnectAB") or "A calls B" ("AcallsB") components. A fair amount of service logic is required to transform the components into a complete service. This puts some constraints on the service developers, as they need to develop a robust real-time service application. Other service components may be more of a complete service. For instance, a "Rule based Routing" component with a rule engine running on the services platform can be easily transformed into an end-user service by merely providing a simple web front-end for updating the rules in the rule engine. In this case there are no real-time requirements to the service application.

The services platform 3 is extremely flexible as it is easily extendible at three levels. It can be connected to a variety of networks and implementing new network adapters will accommodate emerging network technologies. The service components 11 define the actual service features available to service developers. Features can easily be added by defining new service components 11. The access methods and protocols are easily extendable when demanded by service developers. As such, the services platform is a future proof investment.

Currently, the services platform 3 implements a stable framework for the Common Telephony Network Layer 8, the Common Service Components Layer 10 and the Common Services Network Layer 12. Within this framework a set of network adapters 9, service components 11 and service adapters 13 is implemented. At this time, the following services may be implemented using the services platform 3:

ClickToDial

The ClickToDial service brings the call setup features into the web-domain (internet). The services platform 3 offers a (wholesale) ConnectAB component using an HTTP service adapter 13. Anyone with basic knowledge of web-development tools can subsequently set up phone calls. It allows registered users to indicate their active terminal (office phone, work phone or mobile). A user can update his phone book but also has access to the overall KPN Valley online phone book on the intranet. Subsequently, phone calls are made by clicking on a phone number and the call is set up between the active user terminal and the number of the called party.

ChatConnect

The ChatConnect service is an add-on to existing chat rooms on the Internet. The service allows two users in a chat room to set up a phone call without disclosing phone numbers. When a user wants to have a phone call with another user in a chat room, he or she invokes the ChatConnect service. The service asks the other user for approval and his or her phone number. Subsequently, the initiating user is provided with a 0900 number and a PIN code. After dialing into the number and giving the PIN code the initiating user is connected to the other user. Neither user knows the phone number of the other user.

Personal number

The Personal Number service is based on the wholesale (viz. to be offered to end users via "wholesale" servers 4) AcallsB component. A user registers with the service and indicates special actions need to be taken when the user is called. The AcallsB component notifies the service application when the user is called thus allowing the application to change the destination of this phone call. For instance, the user might set up a blacklist of people that should be directed immediately to voice mail.

Office.Phone

The Office.Phone service enriches e.g. MICROSOFT'S MS Office Suite and the like with telephony features. It allows for clickable phone numbers in MS Office documents. The service is based on the same ConnectAB component as used for ClickToDial.

The services platform 3 may preferrably be implemented by means of the EJB (Enterprise JAVA Beans) software platform and tools. EJBs are a component software architecture supplied by Sun Microsystems, Inc. that is meant to build Java applications that run in servers 4 within the services network 1. Applicant surprisingly found that EJB also can be used very well for the implementation of the services platform 3 and its components as presented and discussed above.

EJBs are software modules that contain the business logic of the application. They reside in and are executed in a runtime environment called an "EJB Container," which provides a host of common interfaces and services to the EJB, including security and transaction support. At the wire level, EJBs look like CORBA components.

There are three types of EJBs:

• Session Beans (SB), used to perform processing;

Executes on behalf of a single client Is transaction aware; Updates data in an underlying database; Does not represent data that should be stored in a database;

Is relatively short-lived (life typically is that of its client); Is destroyed when the EJB server crashes.

• Entity Beans (EB), used to represent data, e.g. a row or table in a database; Supports shared access from multiple users;

Participates in transactions; Represents data in the database; Lives as long as the data in the database; Survives EJB server crashes; Has persistent object references;

• Message Driven Beans (MDB), generated to process Java Messaging Service (JMS) messages. MD beans are fit for asynchronous data/message exchange and have no conversational state.

The term "asynchronous" (above and below) refers -in general, not exclusively for EJBs- to events that are not synchronized, or coordinated, in time. The following are considered asynchronous operations:

• The interval between transmitting A and B is not the same as between B and C. • The ability to initiate a transmission at either end.

• The ability to store and forward messages.

• Starting the next operation before the current one is completed.

EJBs inherently provide future scalability and also allow multiple user interfaces to be used. For example, both a Web browser and a Java application could be used to access EJBs, or one could be switched for the other at a later date. However, if these are not important issues, serviets, JSPs and regular Java applications can be used for business logic rather than EJBs. Figure 3 shows a elaborated exemplary embodiment of the architecture of the services platform 3, built with EJB modules. The adapters 13 preferrably have the form of Message Driven (MD) beans, those type of beans having the advantage that they are fit for asynchronous messaging and have no conversational state: messages from the servers 4 or terminals 5 in the services network 1 are "dropped" (written, stored) into the relevant MD bean and -asynchronously- readout (forwarded) at the service components side. In this way a reliant and secure separation is achieved between the services network 1 and the telephony network 2.

Preferrably the service compontents 11 are implemented as Session Driven (SD) beans which exchange data with one or more Entity beans 14, the "Call/Service Entity Bean", containing telephony and/or server related data. The data which are exchanged comprise e.g. billing related data ("call detail records", CDRs) to be used for billing calls initiated from the services network. Moreover, the (database-like) entity beans may contain parameters for call setups etc.

Although the adapters 9, at the telephony network side, may be implemented as SD beans, preferrably they are, like the adapters 13, built as (asynchronous) MD beans, resulting in a double security wall between the services network 1 and the telephony network 2.

Summarizing, the present services platform 3 provides access to control features of the telephony network 2 (incl. sub-networks like PSTN, ISDN, GSM, UMTS etc.). Its modular design makes the platform independent of actual network technologies. Network adapters 9 connect the platform 3 to an actual network 2 and can be added at a later time. Service components 11 and service adapters 13 define the actual functionality offered to a service developer. These modules can be installed at any time. The services platform can be deployed on existing networks right now and can easily migrate towards a more future proof Parlay/OSA scenario by merely adding a new network adapter. The services platform allows telecom services to be developed in a very short time using generic application development tools and technologies. From an economical perspective telecom operators can devote their sparse staff of telecom engineers to the actual maintenance and development of the telephony infrastructure. At the same time, rapid service introduction comes into reach, as no enhancements to the telephony infrastructure are required to implement new services. This approach fits better in the current Internet era of service development where services are quickly launched but as quickly dismantled if they are unsuccessful. At the same time, the presented services platform brings telephony features in reach of third parties. It hides the underlying telephony networks thus allowing third parties to use telephony features in their application without knowledge of telephony technology. It also acts as a shield, by means of application of asynchronous adapters, (either implemented or not as EJB type modules) defending the telephony infrastructure from errors made by third parties. Enabling third parties is an excellent strategy for telecom operators to generate more revenues out of the existing infrastructure.

Claims

1. A services platform (3) for linking a services network (1) with a telephony network (2), said services platform comprising access providing means (8-13) for providing, to components (4,5) of the services network, access to components (PSTN, GPRS, UMTS, INMARSAT etc.) of the telephony network.

2. Services platform according to claim 1, comprising first protocol adapters (9), fit to communicate with said components of the telephony network using several different telephony related protocols, second protocol adapters (13), fit to communicate with said service components (11) of the services network (1) using several different services network protocols, and service components (11 ), each of them being fit for the execution of a set of actions in the telephony network (2), communicated to and/or from the telephony network via the relevant first protocol adapter or adapters (9), under control of said components (4,5) of the services network, communicated to and/or from the services network via the relevant second protocol adapter or adapters (13).

3. Services platform according to claim 2, comprising a Common Telephony Network Layer (8), comprising said first protocol adapters (9), a Common Services Network Layer (12), comprising said second protocol adapters (13) and a Common Common Service Components Layer (10), comprising said service components (11).

4. Services platform according to claim 2, wherein said first protocol adapters (9) are asynchronous communication means.

5. Services platform according to claim 2, wherein said second protocol adapters (13) are asynchronous communication means.

6. Services platform according to claim 2, wherein said first protocol adapters (9) and/or said second protocol adapters and/or said service components (11) are Enterprise JAVA Beans.

7. Services platform according to claim 6, wherein the fist adapters (9) are Message Driven beans.

8. Services platform according to claim 6, wherein the second adapters (13) are Message Driven beans.

9. Services platform according to claim 6, wherein the service compontents (11) are Session Driven (SD) beans, exchanging data with one or more Entity beans (14).

10. A telecommunication system comprising a services platform according claims 1 to 7.

11. A services network (1) comprising a services platform (3) according claims 1 to 7.

12. A telephony network (2) comprising a services platform (3) according claims 1 to 7.

13. A method for linking a services network (1 ) with a telephony network (2), comprising steps of

• converting, within first protocol adapters (9), relevant telephony related protocols used by components of the telephony network into a Common Telephony Network Protocol and vice versa;

• converting, within second protocol adapters (13), relevant services network protocols, used by service components (11 ) of the services network (1 ) into a Common Services

Network Protocol and vice versa, and

• executing, within service components (11 ), a set of actions in the telephony network (2), communicated to and/or from the telephony network via the relevant first protocol adapter or adapters (9), under control of said components (4,5) of the services network, communicated to and/or from the services network via the relevant second protocol adapter or adapters (13).

14. A Software architecture for linking a services network (1 ) with a telephony network (2), comprising • first protocol adapter modules (9) fit for converting relevant telephony related protocols used by components of the telephony network into a Common Telephony Network Protocol and vice versa;

• second protocol adapter modules (13) fit for converting relevant services network protocols, used by service components (11) of the services network (1) into a Common Services Network Protocol and vice versa, and

• service component modules (11 ) fit for executing a set of actions in the telephony network (2), communicated to and/or from the telephony network via the relevant first protocol adapter module or modules (9), under control of said components (4,5) of the services network, communicated to and/or from the services network via the relevant second protocol adapter module or modules (13).