[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                         Abdul Akram, Sprint
Expiration: 06 January 1998            Anastasius Gavras, Deutsche Telekom AG
06 July 1998                           Gilles Lecorgne, France Telecom

                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.''


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
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

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.

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.


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
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
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.

                ********** **********
                * 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

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
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

[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