Service Integration between Internet and PSTN

Menelaos Perdikeas, Iakovos Venieris

Introduction
It is a widely accepted thesis that telecommunication networks and the public Internet
infrastructure are converging. However, a closer inspection reveals that this convergence is – at least for
the time being – taking place mainly in the access (e.g. transport) technologies and (less so) in the
signaling layer for the particular class of telephony-like services. With the exception of the PINT
standard for ‘click-to’ services there is no other instance of service interworking between these two
networks.
In Web access, the PSTN provides the local loop to connect an Internet user to her ISP. In VoIP
the public Internet infrastructure is used to carry digitized voice across an enterprise’s intranet or
extranet. That is, the present situation is that when a service offered by one network (web access in the
first case, telephony in the second) uses the other, it does so on a very rudimentary level, essentially by
using its lowermost layers as a generic ‘get the bytes across’ facility. Even when interworking of a higher
level takes place (as is the case, for instance, when a web portal accepts text from an HTML page to send
it to a user’s mobile phone as an SMS), this is implemented by the use of proprietary gateways and
usually qualifies for little more than an arrangement suitable only for the situation at hand. A careful
examination is bound to reach the conclusion that what is being touted as convergence is little more than
a display of the encapsulating ability of layered architectures. Internet has been layered from the outset.
Public network infrastructures adhered to layering as they became more and more software oriented
(electromechanical switches being replaced by general purpose computing machines). Once this process
was completed, both networks took advantage of layering to substitute one network protocol for another.
That the two networks are only currently starting to use each others layers in a client-server fashion is not
in itself a profound event nor are its technical implications pointing to a paradigm shift. The technical
community’s current understanding and existing standards and practices are enough to cater for this and
similar ad hoc arrangements. It is when seeking to integrate the two networks at the services level that
more complex problems arise and those problems cannot be tackled simply referring to currently
available layered protocol architectures .
This paper is structured as follows. In the next section we introduce some concepts that are
critical to the formulation of the problem statement and to the ensuing discussion. We proceed by
examining signaling interworking between PSTN and the Internet. We note that in this paper the term
PSTN is used as a general term intended to comprise all public switched circuit or virtual circuit
networks (so it includes ISDN and B-ISDN when applicable). Signaling interworking is shown to be a
preamble for the support of a more thorough interworking at the service level which is covered next. <
STHN PAROUSA PROTASH H STHN EN LOGO PARAGRAFO 8A PREPEI NA ANEFER8O STO
SIGNALLING INTERWORKING KAI SAN KATI TRANSIENT>. We next describe PARLEY and
introduce a layered service architecture that aims for exactly this type of integration between PSTN and
Internet. The paper concludes with some general remarks on the patterns of service provisioning that
initiatives like Parlay and JAIN may give rise to and on how they have the potential to transform the
telecommunications landscape.

Interworking concepts
There are three main agents that are the driving force behind the current convergence between Internet
and the PSTN. These are the ubiquity of the local loop, the paramount importance of the plain old
telephony service (and of other emerging services that are paradigm-bound to it like video-telephony or
videoconferencing services) and the emergence of the web interface as the Internet’s analogue to the
phone appliance. The PSTN is a massively redundant, hierarchical, switched network with a
demonstrated record of reliability and robustness. The millions of kilometers of lines of cable that
connect customer homes to the local exchanges render them the ideal avenue to connect user PCs to the
Internet. The demand to connect to the Internet was boosted by the emergence of the e-mail and the web-
browser as Internet’s killer applications. Before that, Internet had nothing similar to the concept of a
service as that is found in the public switched networks. Essentially before the standardization of popular
application level protocols like the HTTP or the SMTP, Internet was just a generic packet switching
network used to interconnect mainframe computers. Once services became available that attracted a
critical mass of market demand, it was inevitable that demand would start to appear for two distinct
abilities: (a) to access a network’s service using the facilities of another and (b) to having discrete
services coming from different networks work together for the needs of some envisaged solution to a real
problem.

We identify the first ability as ‘service homogenization’. It can be carried out with integration at either
the transport or the signaling layers. It relates to the ability of the same service (same in the way it is
perceived by end users) to be offered seamlessly over different types of networks. The second ability is
that of ‘service interworking’. In it, services are able to find each other, interact and exploit their
capabilities. It calls for integration at the service layer. This type of integration is more demanding and
requires architectural provisions of a broader scope than those necessary to accommodate transport or
signaling interworking architectures. This is because service interworking will require some sort of
understanding between the different services that will be of a semantic nature (i.e. it will address issues
that pertain to the actual offerings of a service) while signaling and transport layer integration only
marginally (if at all) relate to semantic concepts and can in most cases be implemented by protocol
encapsulation.

Signaling interworking between PSTN and Internet

We noted that the more elementary level of integration between PSTN and the Internet is at the
transport layer. There, integration comes almost for free as all that need be done is to exploit the inherent
encapsulating and abstracting abilities of every layered protocol architecture. Signaling interworking on
the other hand is not so easy to tackle and can give rise to a wider debate.
Signaling is a widely employed concept in PSTN but almost non-existent in the Internet. PSTN
signaling can be viewed as having two components. The first one is ‘QoS or bearer control signaling’. Its
purpose is to communicate QoS information to the network so that the latter can make the necessary
arrangements and provide to the requesting application a bearer end-to-end circuit with the described
characteristics. Bearer control signaling does not traverse the network end-to-end submerged but at
certain intermediary nodes is elevated and interpreted. These intermediate nodes need therefore to
understand its content and make the necessary actions in response to it. For the second component we
will use the term ‘call control signaling’ although the terms ‘call control’ and ‘bearer control’ are used
interchangeably in the literature. Call control signaling could logically be modeled after the manner of an
end-to-end application layer protocol specifically tailored for the service at hand. Since PSTN is geared
towards providing voice grade switched circuits on demand, call control signaling is essentially dedicated
to accommodating the plain old telephony service. Despite its logical role being end-to-end, call control
signaling follows the same path as bearer signaling (is interpreted at the same intermediate nodes) and in
fact these two components are intertwined in the same protocols. This was not a poor engineering
decision to make given the single service nature of the PSTN. Appropriately, one could describe current
PSTN signaling (both components of it) as a protocol pattern in which the sub-network is not
transparently relaying protocol messages end-to-end but where those messages are interpreted and
examined by some mediating nodes that lie in between. Such an intervention is necessary for bearer
control if some QoS is to be provided but is technically unnecessary for the application-specific part of
the signaling protocol. This is exhibited by the fact that QoS signaling for the Internet (e.g. the Resource
ReserVation Protocol) will indeed by interpreted by some interposed nodes but application-specific
protocols are always transparently conveyed end-to-end. It is not the purpose of this paper to go into the
historical interpretations of why one finds these two different models. Suffice is to hint at the PSTN’s
electromechanical part and its switched nature and to note that PSTN has not for the most part adhered to
the tenets of the protocol pattern known as “end-to-end argument” as Internet undoubtedly has. This in
turn has resulted in the maintenance of call state ‘within’ the network which in turn led to the provision
of services within the network. Though the purpose of the Intelligent Network (IN) is to move services
outside the switches (but not outside the network) it is important to note that IN works simply because IN
services can be alerted by and operate on that switch-maintained call state.
Given this difference in the way PSTN and Internet treat signaling information the question that
arises is how to support integrated provision of services over both networks. It is therefore a question of
service homogenization and the services is question are the telephony service and those following its
model (the fax service and perhaps the video-telephony service for ISDN environments). The question
can be termed in the following – more suggestive – manner: which signaling layers should be terminated
at the location of a signaling gateway and – in the case where not all layers are terminated – which
intermediate entities in the Internet side should be responsible for interpreting the signaling messages and
taking the appropriate actions? For the remainder of this paper when dealing with this and similar
problems we are only concerned about the conveyance of signaling information and not of how the bearer
is used to transfer voice packets over IP or other protocols. That is, we are not concern with the actual
transmission of the encoded media but only with the exchange of signaling protocol messages that needs
to precede it.
The simplest, clearest-cut approach would be to terminate all signaling layers at the signaling
gateway. That is, at the location of a signaling gateway all signaling information is encapsulated into an
Internet application-level protocol conveyed over some transport layer protocol (UDP, TCP or other).
The encapsulated signaling message would then be pointed to a telephony application running at an end-
user personal computer where it would only once again be interpreted by an application layer process –
the telephony application (the first time having being at the signaling gateway). Figure
F_ALLLAYERSTERM depicts this concept.

V id e o T e le p h o n y
S w itc h ( s ig n a lin g e n d p o in t) S ig n a lin g T r a n s fe r P o in t S ig n a llin g G a te w a y IP r o u te r IP ro u te r a p p lic a tio n

TC AP TC AP

SSC P SSC P a p p lic a tio n a p p lic a tio n

la y e r la y e r
M T P -3 M T P -3 M T P -3 p ro to c o l p r o to c o l

M T P -2 M T P -2 M T P -2

M T P -1 M T P -1 M T P -1 IP IP IP IP

Figure F_ALLLAYERSTERM. Complete signaling encapsulation

This approach is not used in practice as in its Internet side it moves all functionality and state
information in the terminals. This is of course consistent with the Internet approach but makes it very
difficult to deliver an integrated telephony architecture. For instance if one would try to use an existing
IN infrastructure with this architecture, while every class 4 or 5 switch in the PSTN would be able to
support a Service Switching Point, similar entity would not be found in the Internet side as all call state
information is maintained in the end-user terminals (which are too many) and not in network-resident
entities.
Moreover the architecture of Figure F_ALLLAYERSTERM suffers from the disadvantage that it
requires <I HAVE TO READ THAT FROM THE TELCORDIA PRESENTATION> remote
transactions to be established with the Gateway and to have each message delivered to the end terminals
until it can be processed , acknowledged or replied – both inefficient ways. Moreover the absence of any
monitoring entity in the Internet side will make it very difficult to guarantee any level of QoS in the IP
side as terminals would be unconstrained to open as many connections as they would want to the
detriment of already established connections.
It has to be noted that these inefficiencies are not functional but revolve around considerations of
efficiency, network utilization and latency or response times. Also, it is questionable whether it is the role
of an application layer protocol to worry about QoS enforcement – that should be the task of a generic,
service-independent QoS architecture. So, from a logical point of view the architecture of Figure
F_ALLLAYERSTERM is the simplest and more straightforward solution.
In order to strike a better balance between design purity and attendance to practical
considerations (and in the absence of an accepted and widely deployed, generic QoS signaling protocol
for the Internet) the approach depicted in Figure F_SOMELAYERSTERM is almost invariably followed.

S ig n a lin g T r a n s fe r P o in t M e d ia G a te W a y
S w itc h ( s ig n a lin g e n d p o in t) S ig n a llin g G a te w a y IP r o u te r IP ro u te r C o n tr o lle r

TC AP TC AP TCAP

SSC P SSC P SSC P

M T P -3 M T P -3 M T P -3
a d a p ta tio n a d a p ta tio n
M T P -2 M T P -2 M T P -2 la y e r la y e r

M T P -1 M T P -1 M T P -1 IP IP IP IP

Figure F_SOMELAYERSTERM. A number of signaling layers terminated, the others being

reproduced in the Internet side (partial signaling encapsulation).
Here, the approach is to terminate some of the lower signaling layers and convey the upper
layers transparently. Therefore the key point of comparison between different signaling interworking
approaches is the level at which they terminate PSTN signaling. The decision of what types of Internet
signaling components should be supported and of what the overall signaling architecture would look like
largely depends on this subtle point.
As an example, there are two internet drafts proposing to adapt the Signaling System 7 stack
onto the Internet. The first provides an adaptation layer at Message Transfer Part 2 while the other at
Message Transfer Part 3. In general the main advantage of the approach to let some signaling layers pass
on to the Internet side is that as signaling information becomes available at Internet nodes (these nodes
hosting Internet Telephony components), it is possible to provide both for the applications specific
aspects of call control without needing to establish transactions all the way down to the actual terminals
and to impose some heuristic algorithm for QoS (e.g. by restricting the number of allowed connections
within a domain). Also this solution requires that in addition to the terminals some Internet nodes are
augmented and able to play the role of their PSTN counterparts. For instance the H.323 architecture for
VoIP specifies entities like Gatekeepers and Media GateWay Controllers which are equivalent in
functionality and state information maintained with the SSPs.
It is seen that signaling interworking between PSTN and Internet involves a process during
which PSTN telephone signaling messages (e.g. Q.931 or Q.2931) are terminated in a signaling gateway
component. The signaling gateway is a signaling endpoint to the PSTN and an IP node for the IP network
and takes cares of communicating necessary signaling over an IP network towards an IP telephone
endpoint (for instance an H.323 compliant telephone application running on a personal computer). It is
understood that signaling interworking could be straight-away implemented by terminating all signaling
layers and encapsulating the signaling message to be delivered directly to the IP terminal. The other
theoretically possible end is to have an integration of the two networks at the lowermost layer (transport
integration) so that none signaling layer is terminated and all continue to the Internet (expecting to
receive the necessary treatment by IP-resident entities that will then need to emulate the entire PSTN
hierarchy). More balanced approaches terminate some of the signaling layers and allow the remaining to
continue. This requires some PSTN functionality to be reproduced in IP nodes but does not go so far as to
raze everything but the lower layers. A discussion of the relative merits of terminating signaling layers
versus exposing more of them would inevitable be involved but a concise rule of thumb would hold that
the less signaling layers are terminated, the more closely integrated the signaling in the two networks
becomes but the greater is the need to provide the equivalents of PSTN signaling elements in the IP world
increasing the cost of the solution.
Regardless of the approach, it has to be borne into mind that signaling interworking applies
mostly for the specific class of telephony-like services for which signaling was invented and that it is but
one level towards the more general and demanding goal of service interworking between all classes of
services.

IN-based Service Interworking between PSTN and Internet

The fundamental principle pioneered by IN is the separation of call control from service control.
This is done through the definition of a Basic Call State Model (BCSM) to mediate between the service
switching and the call control functions. An inspection of the BCSM reveals that through its introduction
the call control functionality pertains solely to the control of a bearer connection devoid of any service
specific notion. This segregation of call control from service control although it occurred in the 80s when
Internet was almost non-existent contributed the most to the paving of the road towards service
integration between PSTN (which, with the exception of IN has remained unchanged since then) and
what was to become the present day Internet. It did so because it allowed to employ the PSTN’s network
infrastructure in a more generic way and hinted on the possibilities that would accrue to service
provisioning by an architecture that would allow services to view the ubiquitous telephone network as
one offering a mere bearer connection facility. Removing service logic from the switches attracted the
much cited gains of more expeditious service creation and reduced time to introduce new services (and
overhead to manage them). More importantly, it treated the telephone network as a generic transport
network and not as a network dedicated to the providing the telephony service. It was not immediately
possible to reap these profits largely because services were still executed within the confines of the core
network (albeit not anymore within the switches), and message-based protocols (standardized, though for
all practical purposes legacy and not interoperable) were used to communicate control between switch-
centric and service-centric functional entities. The advent of distributed object technologies allowed the
further exploitation of the benefits of the service-call control separation to take place.

Distributed Object Technologies in IN

Typical distributed object technologies define an abstract object model that is based on the
concept of networking software as a set of components exchanging messages over an open distributed
computing environment. Since such technologies are founded on notions of component-based software
development, the ability to integrate and re-use existing software comes naturally. Using the abstract
object model, uniform procedures (e.g. for creating or destroying objects, for service discovery, for error
handling) are described for all objects regardless of their actual implementation. Thus, a generic object
‘facet’ provides a potent unifying front-end that can be used to wrap all sorts of behind the scene
implementations (even procedural ones).
The second foundation of DOT (that of an open, distributed computing environment) allows it to
provide the illusion of a unified address space that spans machine, operating systems and network
boundaries as if all distributed objects resided in the same memory and were able to directly obtain
pointers and invoke methods on each other. This ability is usually referred to as “location transparency”
and as it turns out “open APIs” which is another buzzword has much to do with location transparent
access to a remote object’s interface.
Though for sure DOT by itself cannot extent the functionality of a system it provides a generic
infrastructure for conveying control. Instead of needing to negotiate a large set of objects in a mesh of
client-server relationships adhering to different protocols, a bus configuration is used whereby all objects
plug onto a distributed bus. Accessing them then needs to take into account to protocol – only to observe
a self-describing object interface (API). Naturally state information is still maintained in the remote
objects but this is reduced to information relative to the business logic the protocol is performing and the
overhead information needed to keep track of a message-based protocol is dispensed with. The important
thing is that the location where a piece of code executes has no real significance. So long as appropriate
APIs are defined applications that are outside the network can interact with code operating in the
networks innermost parts. Network functionality is therefore exposed and not shielded behind proprietary
interfaces or protocols.
Distributed object technologies offer a very natural way to complement current IN. Instead of
employing proprietary protocols to interact with the switch from a remotely located service control point,
the switch’s functionality can be exposed by a set of self-describing APIs. Remote applications can then
manipulate the switch with the same agility that they would control an object in their memory.
Appropriate mechanisms can be envisaged to secure access and not compromise the network’s integrity.
Refer to [MARINEIEEEREF] for an architecture that employed extensively CORBA and mobile agent
technologies to facilitate flexible allocation of service logic in an Intelligent Network.
Work in this direction continues through the Parlay initiatives.

The Parlay approach

The purpose of the Parlay group is to provide an open API (‘Network Application Programming
Interface’ as it is termed) that will allow secure access to core network capabilities by application
developers outside the network domain. What is different than using distributed processing technologies
to implement the IN SSP-SCP control relationship is that here, from the outset, the goal has been to allow
a telecommunication network’s control relationships to extend outside its administrative boundary. So the
application of distributed processing technologies is just the means to accomplish it and not an end to
itself. The motivation is more far reaching in scope. The rationale behind the specification of the Parley
API is elucidated in [PARLEYWPRef] where it is proposed as a way to combine the best of two worlds.
Namely, that through the use of Parlay, the economies of scale and robustness of telecommunication
networks can co-exits harmoniously with the market-orientedness, reduced times to design, develop and
test new products and the ability to leverage on a much bigger talent pool that are the factors that have set
the software industry’s boom going.
The Parlay group has recognized a convergence trend that is more subtle that the mere integration of
transport networks (which is what is currently being prematurely heralded as ‘convergence’). The point is
made that service logic in telecommunication networks is ever moving outwardly from the core of the
networks. From the switch-based supplementary services to IN SCP-based service logic programs and
from there to Gateways and Service Nodes and even Personal Digital Assistants. At the same time
applications which normally run on open IP networks (the public Internet or a company’s intranet) are
thrusting inwards. From enterprise-based services to Computer Telephony Integration (CTI) and
Telephone Application Program Interface (TAPI) APIs to Private Branch Exchange-based services and
Switch-based CTI extensions. The first (outward) move reflects the desire of telecommunication services
to take advantage of private data typically held within the corporate network in order to provide
customized services that fit the specific needs of individual customers. So, it is prompted by functional
shortcomings in the current model. The second (inward) move is grounded more on performance
grounds. Functionality is not at shortage on the IP side. What is missing are mechanisms to interact
effectively with the telecom world. And while it is generally possible to trombone calls to and from end
network devices, this is detrimental both to the resource utilization of the network and (more importantly
from the application vendor’s perspective) for the applications themselves. So edge-network functionality
requires hooks through which to handle network-centric functionality. Network operators are on the other
hand reluctant to provide too articulate interfaces to applications residing at the network’s rim for fear
that by exposing sensitive functionality the networks integrity may come at risk (the edge of network
applications being developed and tested independently of the network operator’s auditing structures).
To achieve the optimal tradeoff and to address the aforementioned concerns the Parlay API takes the
double approach of (a) emphasizing security through authentication and authorization mechanisms
before granting access to a network’s internal mechanics and (b) of exposing network functionality
bundled in more coarse-grained packages than for instance those corresponding to the IN’s SSP interface
or – even more – to call control signaling. A look at the (public) Parlay specifications reveals that call
related interfaces provide primitives which are more high-level, less powerful and featuring fewer
parameters than the corresponding INAP messages. Using Parlay an application residing on the corporate
backbone will effectively take the place of an SCP-located service logic program but the commands that
are available to its disposal are not as powerful as, for instance, are the SCP-issued INAP messages.
However, this is appropriate for at least two reasons: one is that it makes it easier to respond to security
threats that an authorized but erroneous applications might pose. The second is that since in the Parlay
approach, services are created by application developers and a higher importance is assigned to speedier
service creation it is appropriate to hand out APIs that are simple, self-explanatory and which do not
suppose of the developer an intimate knowledge of the most esoteric (and even proprietary) features of a
network’s mechanics as currently available service creation environments for the IN do.
Therefore, the Parlay API offers the only standardized method that can open the way for service
interworking between Internet and PSTN. In the following section we describe an architecture that
leverages on Parlay to accomplish just that.

Proposed Architecture
Considering an open (e.g. implemented with distributed object technologies) IN architecture as
the basis, the first landmark should be the definition of an advanced network and service architecture for
uniform and efficient creation, management, deployment and runtime provisioning of services in an
integrated, cross-network environment.
Since this is a software-centric vision, it is appropriate that to this end, state -of-the-art software
technologies, particularly Distributed Object Technology (DOT) and Mobile Agent Technology (MAT),
are adopted on a complementary basis, enabling interoperability and reusability of distributed service
components and their dynamic distribution and extensibility. Moreover the adoption of the Paralay
interfaces seems to be the best way to guarantee a uniform platform on which services operate. This
platform is at a level of abstraction somewhat higher than that of the IN service switching function but
easily mapped to it nonetheless. Less straightforward is the identification of appropriate Internet elements
that can host the equivalent of a service switching function. A number of recent papers seem to point in
the direction of Gatekeepers with signaling routed through them in the case of H.323 and SIP proxy
servers in the case of SIP. These entities are selected as they are responsible for maintaining state
information for a call. They are in that sense notification points that can trigger services on the
occurrence of events as well as enforcement points through which services can request the brought-about
of an effect (e.g. the addition or the removal of a leg in a connection). Both of these abilities accrue
simply because the said functional entities mediate in relaying the signaling messages from one endpoint
to the other (as a matter of fact signaling could be contacted end-to-end in which case no SSF-like entity
would be identified not unless they were shorn of most of their capabilities). For an IP telephony
architecture to apply IN principles it is inevitable to request that state be maintain inside the network (or,
in general, in an entity over which network-resident services can exert control) and not only at the
endpoints – unless of course an architecture’s distributed processing environment extends even to the end
terminals which are in this case not shielded beyond a User-Network Interface. This may be seen as a
very artificial constraint to impose but it is necessary given the chasm between Internet’s (i.e. IP’s)
stateless, ‘just-carry-the-bytes’ network and PSTN SCN’s network which even with service logic
extracted from it provides more coarsely grained functionality than IP does.
Once this concession has been made, service integration between the Internet and the PSTN
happens naturally at the Basic Call State Model layer. The call control of H.323 is strongly influenced by
Q.291 so both Q.2931 BCSMs and (more easily) Q.931 BCSMs can be mapped to H.323’s call model.
The SIP model although much simpler can also be mapped to the previous call models. Figure
CALLMAPPING gives an indication of possible mappings.
 ISUP MESSAGE H.323 MESSAGE SIP MESSAGE
ACM (Address Complete) Alerting 180 Ringing
ANM (Answer) Connect 200 OK
CPG (Call Progress) Call Proceeding 100 Trying
IAM (Initial Address) Setup INVITE
RLC (Release Complete) Release Complete 200 OK
REL (Release) Release Complete BYE
SAM (Subsequent Address) Information
USR (User to User Information) Facility REGISTER

Figure CALLMAPPING. Mapping between ISUP, H.323 and SIP

Integrating the two networks at this level allows the same set of services to operate over both
types of networks with no need to differentiate between the two. The notion of a service layer is thus
given rise to, in which services invariably engineered are executed perceiving only a set of similar SSF-
like entities and being completely oblivious as to whether the SSFs they interact with will effect their
actions through the issuance of ISUP, H.323 or SIP messages.
At this point the designed system is IN in principle although may in the process utilize APIs
such as those defined by Parlay (for instance, for the communication between the service logic programs
and the soft switches). The next important step is to recognize that open access to a network’s
functionality can allow for interworking between Internet and PSTN at a different, horizontal level. The
first integration (the one that becomes possible through the definition of a common Basic Call State
Model) is a homogenization of PSTN and Internet telephony, video-telephony and videoconferencing
services. Internet however has given rise to services that do not need or do not adhere to a call model nor
is it possible to describe them using operations on a BCSM. The web browsing service is one example.
Also, more specialized services, like for instance a tele-monitoring service are inconsistent with the
paradigm of services implied in a call model. Services like them can be implemented simply by defining
a remote API for the server and deriving client and server modules using this API. Since APIs are
stateless the semantics of this communication pass unnoticed as no protocol is shared by intermediate
entities. Recall that this could be the case also in SIP and H.323 and it was circumvented only by
imposing the (to an extent artificial) constraint that a mediating service-specific node takes note of all
application layer (e.g. signaling protocol) messages exchanged. The problem here is that unlike telephone
or conferencing services, it is unpractical to enforce common call control mechanisms for ad-hoc
distributed services. Moreover doing this would infringe on the notion of “openness” which is critical to
the distributed software’s success. The Parlay initiative can have a effect that is reaching further ahead
than a simple “CORBA-ization” of the SSP-SCP interface would allow. The real breakthrough in the
Parlay approach is that it is for the first time possible for a thread of control that was spawned inside a
telecommunications network to enter into processing at the public Internet. This is the fundamental
achievement. Once this is allowed, all other benefits of Parlay (e.g. those related to cross-network
creation of services) are accruing naturally and cost-freely simply by virtue of the fact that code now
executes on the Internet side and can swiftly take advantage of APIs that are made available there and
which are typically less rigidly standardized and usually destined to span a shorter life cycle. Moreover
by exporting the switch’s interface to entities that are administratively outside the scope of traditional
actors (network or service providers), service creation is made possible for end-users.
In the signaling section it was argued that signaling as it is implemented in the PSTN seems to
amalgamate two functions. The one is a generic, service-independent capability to request the setting up
of a bearer connection with given QoS characteristics. The other encompasses service-specific notions
and in particular is tied strongly with the model of a telephony service. All other services which use some
type of signaling adhere to this model (e.g. videotelephone, videoconferencing etc). It was further argued
that to have networking protocols catering to the needs of services is not in general the best approach but
it was a rational compromise to make in the case of PSTN which basically offers a voice service. This
paper argues that there is no longer any technical justification for exporting such practices to the Internet
side of a converged environment. It might be necessary to support signaling for telephony services on the
Internet through some sort of signaling interworking as explained in Section *** but even there complete
encapsulation and deference of all logic at the end-points is an as viable strategy. To make the concepts
clearer it is necessary to define two terns to identify to two practices which although distinct are often
referred to interchangeably. The first is ‘service homogenization’. This relates to the process where the
same service (same in the way it is perceived by end users) is offered seamlessly over different types of
networks. Depending on the differences between the two networks service homogenization calls for
either signaling interworking or transport layer interworking at a lower level <identify that the second
comes naturally due to protocols> . The second is that of service integration. This refers to the ability of
services to make use and exploit the facilities offered from one another. We hold that in a converged
Internet/PSTN environment there is a need for the homogenization of the telephony service and that the
Parley approach offers the necessary hooks to implement any kind of service interworking. Figure X
depicts that concept.
The Internet world is more service-rich and has little or none at all need of application-level
protocols that are understood by entities other than the end points (as call control signaling clearly is).
That a concession should be made with respect to telephony signaling is a pragmatistic approach given
the relative weight of the public switched network’s infrastructure and the ubiquity of voice terminals.
Other than that, the Internet needs signaling only for bearer control and efforts are underway to provide it
with one (though approaches differ as to how fine-grained it should be).
In the following we describe an architecture that exhibits the following properties:
· it unifies the telephony service on its Internet and PSTN segments
· it allows full interworking between the telephony service and other arbitrary Internet
services
· it allows end-user service creation.

We are seeking to define an architecture that will exhibit the following properties:
· Telephony and related services are homogenized over all network constituents
· The possibility is given to define arbitrary interworking schemes between
different network’s services
In the described architecture integration of networks does not simply take place at the
transport network as that would minimize the ability to take advantage of each network’s
individual charcteristics, niche services and trade-offs. Instead, signalling and service
layers are not homogenized but are preserved in each network so that they may be
levaraged upon. The resultant architecture consists of three layers. In the lowermost layer
each network has its native services and no interworking is possible. In the medium
layer, telephony services are integrated through the definition of a common call control
model. In the upermost layer telephony (which is integrated at layer 2) and all other yet
un-integrated services are available in the forms of APIs. Layer 3 services need not be
integrated across networks. That is, it is not – in general – possible for a layer-3 service
to execute seamlessly across all networks without taking into account the specific
protocol stacks and signalling architectures. Services for which it is impractical to
provide such a level of abstraction are those that are tied or are taking advantage of
intimate characteristics of a network technology which would be lost if any abstraction
was applied. Others are those whose call models for the time being cannot be integrated
into layer’s 2 call model. The idea should be that more and more services can migrate for
layer 3 to layer 2 as appropriate technologies evolve. For instance the web browsing
service is currently a layer-3 service. If XML is applied and becomes widespread it
would be possible to migrate the web browsing serivce to layer-2 as an instance of
navigation in a web site could be portrayed (for telehone users) as navigation through
hierechical voice menus with the help of a Specialized Resource Function. So this service
architecture facilitates evolution with the gradual sinking of newly introduced services
from layer 3 towards layer 1 as they become more mature and interworking between
them and other services more standardized. In particular the stipulation <this is not the
correct word> that layer 2 must be characterized by a single call control model is needed
in order to enforce the notion of a hub model for call control interworking. Each newly
introduced call control model will be required to interwork with the common layer 2 call
model and not with every other call model currently resident within layer 2. The latter
option would create a fully meshed graph of interworking mechanisms instead of the
simpler star topology required by a common call model. The only disadvantage of a star
interworking specification is that two abstraction phases are mediating between any two
call models (one from the source call model to the common call model and a second one
from the common call model to the destination call model). This might lose us some
possibilities which might have been possible if the less involved and more direct fully
meshed approach was used. It should be assumed however that call models that are
facilitated in layer 2 are sufficiently similar so that a generalized common call model can
be derived which will maintain most of the concepts and procedures found in the
individual call models. The following section decribes in more detail the individual
layers of our service architecture and in particular, layer 3 which is also the layer where
service creation takes place.

Layer 1
In layer 1 a variety of networking elements are available. These elements correspond
to diverge networks and no concerted interworking between them takes place. Ad-hoc
interworking schemes may apply but these are beyond the scope of the service
architecture we describe and are not observed by it.
Layer 2
In layer 2 telephony, videotelephony and videoconferencing services are converged
across networks through the definition of a generic call model that applies to the whole
of layer 2. To support a call model appropriate event notification and enforcement points
are identified in each network and for each signalling topology. For instance, in PSTN
these points are the service switching points and in the Interner (for VoIP services) theses
are the H.323 GateKeepers or the SIP servers. These elements are then represented to
layer 3 through the same interface – that corresponds to the generic call model –
irrespectively of the network elements that implement them.
Layer 3
In Layer 3 all services are represented through a set open interfaces that allow other
services to take advantage of the facilities they offer and so to allow interworking
between them to take place. Services that have been integtrated at layer 2 are represented
by a single set of interfaces which is network-independent while others which are
intrinsic to some networks or which do not lend themselves to abstraction under the
umbrella of a common generic call model are represented un-abstracted by their native
interfaces. For the remainder of this section and for reasons of consistency we are going
to use CORBA terminology in describing these interfaces although any other distributed
processing technology such as RMI or DCOM could be used in its place.
There are two categories of interfaces available in Layer 3: enforcement points and
notification (or call-back) interfaces. Eforcements points are interfaces through which
services can manipulate the resources of the underlying network. It is understood that
enforcement points are the only mechanism available to the services through which they
can have some impact on what the end-users are perceiving. To draw an analogy with the
IN paradigm, enforcement points in IN are the Service Switching Points and their
interface are the specifief SCF initiated SCF-SSF flows.
Notification points on the other hand are used to allow services to be informed on the
occurrence of events that are important to their execution. For instance, a personal
mobility notification point could be used to emit events when a monitored user changes
his location in the network. To maintain the analogy with the IN paradigm drawn earlier,
notification points coincide with the detection point in the BCSM which are armed or not
depending on the interest a given sevice has for them.
In Layer 3 service are executed in a distributed processing environment and the
notification and enforcement points on which they rely for their correct execution are
supported by network elements which may be distant from physcial node to which a
given service is executed. Figure F_DPE depicts that concept. This disentaglement of the
services from the underlying execution contexts will be shown to give great flexibility
when the service creation mechanisms are discussed in the next section.

Service Creation in a Distributed cross-network environment.

Examining the service creation environment that can be made available at the 3 rd
layer of the described service architecture we note that it can be allowed to encompass
network independent facilities in the case where those facilities are homogenized at layer
2, and network specific faciliites in the case where these facilities cannot be uniformly
treated at layer 2. In both cases network faciliities are made available through open
distributed and implementation-independent APIs. So insofar as service creation is
concerned it is really a matter of concetual simplicity that for a given facility the same
interface can be used for all underlying networks or that specifically tailored interfaces
are used in every network that supports the said facility. Other than that the functionality
that is available at the disposal of the service designer is not affected by the issue of layer
2 integration or not.
Altough the resources that services interact with may have (and indeed do have) an
object representation we hold that for the coding of the service logic itself, a procedural
notation is best applied and as such we have decided to extend the tested and proven
concept of Service Intepenend Building Blocks (SIBs) to cross-network services. The
idea is that for every action a service might need to take a “prepare” SIB is available
which – provided the runtime arguments – can make the appropriate invocation towards
the API exported by the involved enfrorcement point. Regarding notifications, we have
generalized the “waitEvent” SIB. Once control reaches a SIB of that type, service
execution is temporarily suspened until the event for which interest was registered is
triggered. As an example Figure F_SCEEXAMPLE reports the SIB graph for a service
that sends an e-mail to an address every time a call is missed on a given number. The
service itself has litlle practical utility but is indicative of the ability to write cross-
network services in the proposed service architecture.

Concluding remarks on cross-network services

The real offering of the Parlay API is not so much that it offers open APIs into a telecommunication’s
network elements nor of homogenizing handling of telephony-like services through the definition of a
generic call control model.
<EXPLAIN WHY THE FIRST TWO COULD COME MORE EASILY>
Nor is it the providing of handles into the telecommunications network and of allowing Internet
applications to use them so that to bring into effect calls, diversions etc. CTI has been doing this for
years.
It is of allowing the handling of an asynchronous telecommunications event to be carried
out in an execution context outside the confines of the network, in an area outside the
administrative or management responsibility of the network operator. Since the requests
for a telecommunication service can be serviced by applications running in the public
Internet (and connected to the inner mechanisms of the telecommunication network
through a DPE), it is possible for the latter to use any other open API that can be
developed in the Internet either by the service providers themselves or independently for
the purposes of other applications. The fact that the code governing a service is executed
on an entrprise’s application server or even on an end-user’s workstation is in itself a
capability that blurs the distincition between the role of a service provider and a general
purpose software house and will in due cource allow the migration of most service code
outside the public switched networks and into application servers offered by application
companies.
Those services that will still be executed inside a network’s service control points will be
simple, one size fits all services. All other code will run on the public Internet. This will
in effect externalize all IN code and will render the telcommunication network as a client
network dependant for its control on code that will be externally provided, managed and
executed. By making it able for the service providers to levarage on a much wider base
of software developers the cost of services provided through the telephony network will
fall.

Conclusions

References
 -----------------------------------IDEA POOL--------------------------------
<edo isos na anefr8o sthn evolutionary sxesh metaksy signalling integration kai service integration>

--------------------------WORD POOL------------------------

This paper will address some of these issues at its conclusions section but for the moment suffice is to say
that in all signaling interworking specifications (and there are a number of fora working on this topic)
spanning a shorter life, design parsimony, infringe upon

Perhaps the terms merit a delineation. Seen in the context of service provisioning signaling can
be categorized as call control signaling and bearer signaling. Call control signaling is, in essence, service
specific signaling. For instance, there are call control protocols for telephony services, call control
protocols for video-telephony or videoconferencing services and so on. Seen in context, call control
signaling should be inherent to the service and not the network. Unfortunately call control in PSTN is
interwoven with bearer control and does not pass transparently through the switches that mediate between
the two end-points. In contrast, in the Internet, H.323 signaling flowing from an end application
submerges at the gateway or gatekeeper – depending on the approach – is relayed over the Internet in the
form of UDP packets and emerges back again as H.323 signaling only at the destination Gatekeeper. If
point-to-point H.323 (or SIP) signaling is used then only at the uttermost endpoints (the workstations
running the applications themselves) will H.323 be perceived as such. Between the endpoints there are
only routers who operate on the IP layer only. There are historical reasons of course underpinning this
differentiation. The PSTN has traditionally adhered to the principle of adding functionality in the core
network in order to have terminal devices as simple and cheap as possible. While PSTN’s origins hardly
allowed for any other alternative, even when more and more functionality started migrating to software
(affording greater latitude in implementing network schemes with simpler lower layers) its protocols and
its design philosophy persisted in this orientation. It has to be recognized that PSTN sole purpose was to
provide a simple bi-directional voice circuit and that having to cater for such a simple service excussed or
even justified this approach. This being as it may, the model is no longer appropriate in an environment
where a multitude of services are offered to the customers with different call models and many of them
without the need of any call model at all.
The other type of signaling, this of bearer signaling is truly inherent in the network and is service
independent. It is this type of signaling that calls for interworking provisions when networks of different
types are adjoined forming client-server relationships (in the TINA sense of the word). Bearer signaling is
not involved in service-level functional requirements but focuses solely on the communication on behalf
of the application of acceptable QoS conditions for a requested connection and the mechanisms by which
the network will seek to provide them. As such it is clearly a layer 3 matter and can be studied and
resolved at this layer independently of other interworking issues. Internet presently lacks a QoS
architecture but work on RSVP and the IETF DiffServ group has resulted in the formulation of two such
proposals featuring different tradeoffs between efficiency, complexity and expressiveness. Both proposals
use concepts similar to those of the bearer control part of CSN signaling protocols and as such
interworking mechanisms between them are not hard to envisage. Figure 1 compares the clear separation
between bearer and call control signaling in Internet with the monolithic approach that characterizes
PSTN.
This paper suggests that the way out of this entangle mesh wish can retard the progress of any effort
promoting real integration between the two worlds is offered by IN. Not IN in itself to be sure, but by its
principles even though demonstrated through different means.