Internet Draft Abdul Akram, Sprint Expiration: 06 January 1998 Anastasius Gavras, Deutsche Telekom AG 06 July 1998 Gilles Lecorgne, France Telecom draft-lecorgne-pint-tina-00.txt A TINA service architecture experiment in Internet / PSTN interworking Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' Abstract Nowadays, Internet offers different information and communication services (web pages, email, file transfer, IP telephony, ...). The use of those services increases significantly. Internet trends to become the major multimedia and communication application support. On the other side, PSTN (Public Switched Telephone Network) services are commonly used with high quality, performance and security , and they evolve with a lot of value added services (free call, call waiting, vocal mail, ...). But today, there are few interactions between Internet services and PSTN services. In that way, it is very interesting to develop new services which offer synergy as defined by the PSTN / Internet Inter-Networking (PINT) working group. Internet and PSTN are considered to be two different business domains. So, it is necessary to identify the interfaces for the interworking. The TINA (Telecommunication Information Networking Architecture) architecture is a common software architecture for information and telecommunication services, defined by the TINA consortium. The architecture is applicable to different services (telephony, video on demand, Web, ...) and different transport networks (IP, PSTN, ATM, ...). This internet draft is about the use of TINA architecture in the development of a common control platform for the Internet / PSTN interworking. Our aim is to apply TINA service architecture for both internet and PSTN service platforms in order to allow interactions. The TINA architecture is first introduced. The architecture of our experiment is described ; and the relevant contributions for PINT are identified. Table of contents 1. Introduction 2. TINA service architecture 3. Internet / PSTN architecture experiment 4. Services components interfaces 5. Conclusion 6. References 7. Authors' Information 1 Introduction The objective of the PINT WG is to define an architecture and a protocol, considering security issues, to offer services like click- to-dial, click-to-fax. In reference to the figure 1, The PINT protocol (1) is independent of the underlying network functions (2) which could be IN, with INAP (Intelligent Network Application Protocol) interface, or PBX (Private Automatic Branch eXchange), with CTI (Computer Telephony Integration) interface. In the context of the PINT charter, this draft consists in identifying how the TINA service architecture can be used to offer a protocol to control the public switched telephone network services from the internet. _____ _______________ ________________ |____| | | | | /++++/ ---(1)---| PINT Platform |+++(2)++| CSN* functions | PINT client |_______________| |________________| CSN : Circuit Switching Network Figure 1. General Architecture The TINA architecture has been specified by the TINA-C consortium. Its main objectives were to define a common software architecture to increase the development of new telecommunication and information services, along with service synergy. Three architectures are defined : the service architecture, the network architecture and the DPE (Distributed Processing Environment) architecture. In the PINT context, the service architecture [1] is more precisely described. In our experiment, two different gateways were developed in order to interact with an IN equipment and with a PBX equipment. The interface between the internet client and the TINA platform, which is needed for the PINT protocol, is highlighted. 2. TINA architecture Architecture TINA business model defines the different domains related to information and communication services, and particularly : consumer, retailer, connectivity provider and third party service provider. _________ ________ ___________________________ |Consumer | |Retailer| |3rd party service provider | --------- ---------- --------------------------- ______________________ |Connectivity Provider | ---------------------- In addition, it identifies and specifies reference points between domains. The protocol between the internet client and the PINT platform relates to the Consumer/Retailer reference point in order to establish a secure access and to initiate the usage of service ; and a usage relationship between Consumer and 3rd party service provider is used for the service logic execution. The TINA service architecture defines the concept of access and usage. The access part includes the messages to initiate a session as a secure and authenticated relationship. Then, the access session controls the context of the access and the relative consumer profile in order to request services. One example is the access to an Internet Access Provider. The usage part concerns the way to control the usage of a service and to support management capabilities like accounting. It is included in a service session. It is split in generic interfaces which are common for different types of services (multi-parties control, accounting, ...) and in service logic specific interfaces. One example is the request of a Video-conference service. If the service execution needs explicit usage of network resources, in order to exchange information flows, then it sets up a communication session. The communication session manages the logical link with network resources, independently of the underlying network. One example is the setup of an ISDN link for video and audio transport. The TINA service architecture defines the service components for the above functions. They are specified with the language IDL/OMG (Interface Definition Language of the Object Management Group). It allows to define the architecture independently of the different technologies for the implementation (operating system, language, network, ...). 3. Internet / PSTN architecture experiment The TINA service architecture is applicable to the domains of Internet and PSTN/IN. The experiment has been completed for the Tina Test Trial. The TINA Test Trial is a project involving Global One partners (DT, FT, Sprint and Global One) and aiming at validating the TINA concepts and architecture through a large-scale prototype (France, Germany and USA). This project started at the beginning of 1997. A prototype is available now. One of the advantages of TINA architecture is that service components are deployed on a same control network and they can interact as their interfaces are open. In the context of the PINT services, the interaction consists in giving access to the PSTN / IN services through the internet. The architecture is as below : PS : Programmable Switch VP : Voice Peripheral (1) IIOP (2) HTTP (3) VP API / Corba gateway (4) INAP-like / Corba gateway (5) CTI / Corba gateway user terminal _____ __________________________________________ |____| | --------------- TINA Control Platform | /++++/ --(1)-------|| Authentication | (over Corba DPE) | | | ---------------- ---------------- | (2) __ | | User Profile | | |_ | |(1)| ---------------- | |_| | -------------------- | web server | | Service Session Mgr| ---------------- | | -------------------- |..TINA component| | | ---------------- | |__________________________________________| /(3)\ /(4)\ /(5)\ \___/ \___/ \___/ | | | | | | [VP] [PS] [PBX] | | | |___________ | ______| o^o | | / o^o /__\=============== [CO]=============/__\ Figure 2. Experiment Architecture The access is under the control of a TINA platform which identifies and authenticates the user. Depending on the access terminal (PC, phone, ...) and on the user profile and authorization, services are made available : electronic mail, web service, call completion, voice mail, ... The platform allows the use of services like click-to-dial and voice-access-to-content. And in order to control the different network equipments, a gateway between IIOP and a programmable switch with INAP-like protocol (4) and a gateway between IIOP and a pbx with CTI protocol (5) are deployed. Infrastructure TINA service components are deployed on a DPE (Distributed Processing Environment) platform. The DPE is Corba 2.0 (Common Object Request Broker Architecture) compliant. In addition, the use of CORBA2.0 interoperability architecture, namely GIOP (Generic Inter-ORB Protocol) specialized as IIOP (Internet Inter-ORB Protocol) over TCP/IP, offers universal signaling protocol for all component interactions and provides transparent distribution depending on traffic, load balancing or users locations, ... Indeed, if the user's terminal is 'intelligent' (i.e. off-the- shelves terminals with 'Java/Corba' capabilities) then it can execute some service components and interact directly with the control platform. The use of a protocol like Corba2.0 allows to offer secure and transactional features as the session persists while the link between a client and an object server is still active. This is difficult to achieve with a protocol like HTTP which is a native stateless protocol for the request of hypertext document and which has not been designed to specify interactions for controlling the access to networks and services. In the case of a dump terminal, gateways can be deployed in the network and be used on its behalf. For the internet access, the application protocol between the terminal and the TINA platform are IIOP (1) or HTTP (2). In the case of HTTP, a gateway is used to translate HTTP messages into IIOP messages and to maintain the access session context. Scenario Click-to-Dial scenario An example of service is a web-based phone directory. The user is connected to the platform and consulting a directory in order to find the callee reference. He can click a button to request a call completion. The service request is sent to the TINA platform. It checks the authorization and a service session is created. Then the service identifies the user phone number with his profile and requests the call setup with the callee, from a communication session manager. As the control platform is distributed (DT, FT, Sprint control points), and depending on call parties locations, the communication session manager can control network functions in an optimized way. In addition, the call status can be delivered to the client and information can be managed, such as the billing party, date/time to complete the call, ... Voice access to web content scenario As in the previous scenario, the user is connected to the platform and consults a web page. A specific request can establish a phone call with the user and send the voice translation of the HTML page. The service request is sent to the TINA platform which checks the authorization and starts a service session. The service identifies the user phone number with his profile and requests the call setup, with a voice peripheral, from a communication session manager. The communication session manager controls the network functions. When the call is set up, the service session requests the translation of the page content, that is played by the voice peripheral. 4. Service components of the experiment Access : The interfaces of the access part are the ones defined in the Ret reference point [2]. It concerns the interactions between the consumer domain and the retailer domain : secure access initialization, identification & authentication, request of service session and authorization checking, ... usage : The usage of a service is under the control of a service session. The interfaces defined for the PINT services are specific to our experiment. But the goal is not to define a new protocol. PINT protocol will be defined from the SIP/SDP (Session Initiation Protocol / Session Description Protocol). In fact, our view is to contribute to define those service usage interfaces based on SIP for example, ie to define the IDL interfaces which correspond to the SIP messages. The difference is not so important since the service invitation interfaces in the Ret reference point are defined according to the SIP standard. The figure below summarizes the interfaces for the PINT context. ______ |User| ------ ********** ********** * Access * * Usage * * Ret RP * * SIP/IDL* ********** ********** ____________________ | | | PINT | | | | functions | | | -------------------- *************** * IN protocol * *************** ____________________ | | | IN functions | | (SCF, SRF, ...) | -------------------- Figure 3. Interfaces 5. Conclusion The aims of our experiment were to develop a platform prototype of TINA service architecture for Internet and PSTN access and to identify its interest to offer synergy between Internet and PSTN services. One output of the experiment is that a common architecture, TINA, can be used for different domains : Internet and IN. Also, the conformity to reference points allows different control platforms (DT, FT, Sprint) to cooperate. In addition, the use of the Corba architecture allows to define a service component by their interfaces and then to offer their access through a common communication protocol which is independent of its location and the underlying infrastructure. It enables an easy interworking between Internet and PSTN services. Then, our contributions are about security, interface and protocol issues. The access part interfaces are defined by the Ret reference point. The usage part interfaces could be defined by IDL interfaces from SIP/SDP messages. The security concerns first a secure identification and authentication relative to the access session, and secondly, the authorization for the service usage. In the experiment, the IIOP protocol is used to offer a common service interaction protocol. 6. References [1] TINA-C consortium, " Service Architecture - Version 5.0 ", June 1997. [2] TINA-C consortium, " Ret Reference Point Specifications - Version 1.0 ", January 1998 7. Authors Information Abdul Akram E-mail : Abdul.Akram@mail.sprint.com Telephone : +1-913-534-5586 Fax : +1-913-534-2526 Anastasius Gavras E-mail : gravras@tzd.telekom.de Telephone : +49 6151 83-1369 Fax : +49 6151 83-4484 Gilles Lecorgne E-mail : Gilles.Lecorgne@cnet.francetelecom.fr Telephone : +33 2 96 06 35 38 Fax : +33 2 96 05 37 84 Internet Draft TINA architecture and PSTN/Internet Interworking