matching on the basis of the Call Back DN.
12. The CSN notifies the SCP (SIP 180 Ringing) of status and
references the Call Back DN so that the SCP can reuse it for
other calls.
13. If the central office supports that two B-channel transfer
(Lucent, Nortel, and perhaps other central office vender's do),
an optimization is possible. The CSN can have the central office
rearrange the topology of the newly connected call in such a way
that it flows only through the central office and no longer
through the CSN.
5. NEC's Implementation
5.1. Overview
The NEC implementation of the ICW service is based on IN. Via a
SPIRITS server and an ICW client, incoming calls will be presented to
the user via a pop-up screen dialogue box. This dialogue box informs
the user of the call arrival time and the calling party's number and
name (if available). The arrival of the call is also indicated with
an accompanied audible indication.
The pop-up dialogue box offers the user various call management
options. Selecting a call management option allows the user to
answer the call, forward it to another destination or to voice mail,
or ignore it.
The user will be able to customize their service through various
service set-up options. All calls presented to the user during an
Internet session will be recorded in a call log.
Other features include Multiple call arrival management with which
each new call arrival will generate its own pop-up dialogue box and
audible indication.
5.2. Architecture and Overall Call Flow
Figure 10 depicts the NEC ICW system.
====================================
|| I n t e r n e t ||
|| ||
====================================
/ | \
: (p1) : : (p2)
/ | \
+-------+ +------------+ +-----+
|SPIRITS| | ISP | | W3S |
|Server | | ISP | | W3S |
+-------+ +------------+ +-----+
: :
Internet | :
PSTN/IN |(p0) :
: :
| ============:======
+------+ (p3) || +-----+ : ||
| SCP |-..-..-..-| SSP | : ||
+------+ || +-----+ : ||
|| (p4)| : ||
+-------+ || : : ||
| ICW | (p1)+-----+ || | : ||
|Client |.....| M/D |............+------+ ||
+-------+ (p2)+-----+ || | CO | ||
--------------------| |-------
/ || +------+ || \
/--\ / || P S T N || \ /--\
()/\() / =================== \ ()/\()
_/__\___/ \______/__\_
ICW Subscriber Calling Party
Legend:
ISP : Internet Service Provider
W3S : WWW Server
SCP : Service Control Point(acts as SPIRITS Client)
SSP : Service Switching Point
CO : Central Office
M/D : Modem
Traffic:
--- : PSTN Voice Traffic
... : PPP(IP traffic)
-..-: Signaling Traffic
Interfaces:
p0 : SPIRITS Server-SCP(SPIRITS Client) interface
p1 : SPIRITS Server-ICW Client interface
p2 : ICW Client-W3S interface
(Web access through HTTP)
p3 : SCP-SSP interface(INAP)
p4 : SSP-CO interface(ISUP)
Figure 10: the NEC ICW system
The description below provides the necessary steps to initiate the
ICW service on a CO line, and how the ICW service is applied to an
incoming call based on the above architecture:
1. The CO line is primed for the ICW service when the customer
connects to their ISP by inserting a special activation code
(e.g., *54) prefix in front of the ISP Directory Number.
2. The ICW service is activated when the user opens a secured
session from an ICW client to the SPIRITS server. Once a session
is open, the SPIRITS server will know the relationship between the
line and the PC (i.e., it will know the Directory Number of the
user's Internet line and the user's IP Address).
3. When a call arrives at a busy Internet line, the SSP will trigger
the ICW service. The SCP which acts as the SPIRITS client will
inform the SPIRITS server that a call is terminating to a busy
Internet line. The message will include the Caller ID and Calling
Line Identify Restriction (CLIR) Status of the calling party, and
DN of the busy line.
4. The SPIRITS server will verify that if an ICW session has been
established for the busy line. If so, the SPIRITS server will
communicate with the user's ICW client application. The user will
receive a real-time pop-up dialogue box including the Calling Name
and Number of the Calling Party if available. The user will then
select one of the following call management options:
- Answer the call (the Internet connection will be automatically
dropped and the phone will ring)
- Send the call to Voice Mail
- Forward the call to another destination
- Ignore the call
5. When the Internet user has made a selection, the ICW client
application will transmit this to the SPIRITS server. The SPIRITS
server will instruct the PSTN via the SCP how to handle the call.
5.3. Interfaces and Protocols
5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface
5.3.1.1. Connecting to SPIRITS Services
The physical connection between the SCP and the SPIRITS server will
be via a LAN/WAN. The logical connection will use the UDP/IP
communications as defined in RFC768 and RFC1122.
If a socket connection is not currently established, the SCP will
periodically try to open a connection. The SCP routing tables will
be configured so that all available connections to a SPIRITS server
are used.
5.3.1.2. Message Types
Two different types of message are used between the SCP and the
SPIRITS server: "Connection Management Message Type" and the "Data
Message Type". These messages will carry the remote operation
messages which are based on ITU-T Q.1228 SCF-SCF interface with some
NEC proprietary extensions.
NEC also has a plan to support SIP/SDP-based protocols for the SPIR-
ITS client-server interface in the near future.
5.3.1.2.1 Connection Management Message Type
Connection management messages are to support functions related to
the opening and closing of connections and monitoring connections to
ensure reliable communications are maintained between the SCP and a
SPIRITS server. The SCP is responsible for establishing a connection
to a SPIRITS server. A connection can be closed by either the SCP or
the SPIRITS server.
The "Connection Management Message Type" includes the following
operations:
- scfBind - scfUnbind - activitytest
Opening a Connection
If a connection is not open to an SPIRITS server, the SCP will
periodically try to open a connection until it is opened. If after a
pre-determined number of attempts the connection is not opened, the
socket connection will be released and then re-established and then
the attempt to open the connection will be repeated.
The sequence for opening a connection is:
1. SCP will transmit a scfBind invokation message to the SPIRITS
server. This message also carries the version information and
activity test interval.
2. The SPIRITS server, upon receiving an invokation of the scfBind
from a particular SCP, will reset all the data concerning the
connection and then responds with either a return result containing
the Web Server Identification number or a return error with a reason.
3. When the SCP receives a return result, if the ID number does not
match the number configured in the SCP, then a scfUnbind will be sent
indicating the wrong ID number. If the SCP receives nothing or a
return error is received, then the scfBind will be retried after a
pre-determined period of time.
4. Once the SCP has received a return result, the SCP will send
Handling Information Request or Activity Test.
Upon receiving an invokation of activityTest, the SPIRITS server
should reply with a return result of activityTest. If the SPIRITS
server does not receive any invokation messages of Handling
Information Request or Activity Test from the SCP for four times the
Activity Test Interval value in milliseconds, the SPIRITS server
should then close the connection.
To close a connection an invokation of the scfUnbind is sent by
either the SCP or SPIRITS server to the remote end. When an
invokation message of the scfUnbind is received, the receiving end
should terminate the connection.
scfBind
The scfBind operation is used to open the connection between the SCP
and the SPIRITS server. The SCP will send the SPIRITS server an
invokation of the scfBind to establish an association. If the
SPIRITS server is ready to handle the request then it should respond
with a return result.
The return result of scfBind contains the identifier of the SPIRITS
server. If the SCP receives the return result where the
identification of the SPIRITS server does not match that registered
against the SPIRITS server, then the SCP will send an invokation of
the scfUnbind indicating an incorrect identifier was received.
If the SPIRITS server is not ready to handle the request or cannot
handle the version, then it should respond with a return error.
scfUnbind
The scfUnbind operation is used to close the connection between the
SCP and the SPIRITS server. Either the SCP or the SPIRITS server can
invoke this operation.
Upon receiving an invokation message the receiving end should
terminate the connection.
activityTest
If the SCP has not sent a Data Message for the time period specified
by the "Activity Test Interval", it will send an invokation message
of activityTest. When the SPIRITS server receives such an
invokation, it will reply with a return result message of
activityTest.
Its contents should be retained by the SPIRITS server. They are to
be echoed back in the return result so that the message reply time
can be calculated.
5.3.1.2.2. Data Message Type
SCPs use the following operations, which are sent to the SPIRITS
server via a Data-Message-Type message, to request execution of some
service procedure or notification of an event that takes place at the
SCPs:
o handlingInformationRequest
The handlingInformationRequest message will request a SPIRITS
server the execution of some service procedure.
o handlingInformationResult
The handlingInformationResult message will show the SCP the result
of the execution, which was carried out by the SPIRITS server.
o confirmedNotificationProvided
The confirmedNotificationProvided message will indicate to the
SPIRITS server of an event, which takes place at the SCP. If the
confirmedNotificationProvided indicating 'caller abandon' is
received, the SPIRITS server will inform the client of the caller
abandon and send the SCP a return result for the
confirmedNotificationProvided.
The invoked operation has always a response which is either a
return result of the operation or an invokation of another
operation.
If a Data Message is not replied to within a pre-determined time
out period then the message will be resent a number of specified
times. Once the number of times has been exceeded, if another node
exists, the message will be sent to another node if it is
available. If all available SPIRITS servers have been queried then
Message Time out will be returned to the calling process.
If an invokation of the handlingInformationResult is received with
the cause=63 (Service not available), the
handlingInformationRequest will be sent to another node if it is
available. If all available SPIRITS severs have been queried then
cause=63 will be returned to the calling process.
5.3.2. SPIRITS Server-ICW Client Application Interface
The following is a list of the application messages that are sent via
the secure protocol (refer to section 5.3.3):
o VersionInfo (ICW client -> SPIRITS server)
Indicate the current version of ICW client software. The SPIRITS
server uses this information to determine if the client software is
out of date.
o VersionInfoAck (SPIRITS server -> ICW client)
If the VersionInfo message from an ICW client indicates to a
SPIRITS server that it is an out of date version, the URL
information is returned within the VersionInfoAck message for use
in downloading the newer version. If the client software is up to
date, the message simply indicates so and does not include any URL
information.
o CallArrival (SPIRITS server -> ICW client)
Sent by the server to tell the client someone has called the DN.
o CallID
An identifier for this call. Unique in the domain of this
client/server session.
o CallingNumber
o CallingName
The name of the calling party is sent to the Client Application
from the SPIRITS server. When available, the name is sent as a
15-character string. If the name is unavailable it is sent as
"Name Unavailable". If the calling party has CLIR set, it is sent
as empty (" ").
o CallConnect (ICW client -> SPIRITS server)
If a corresponding CallConnect is not received within a certain
period after sending a CallArrival, the SPIRITS server will behave
as though a CallConnect, Handling=Ignore had been received.
o CallLost (SPIRITS server -> ICW client)
Sent by server to cancel a CallArrival before a CallConnect is
received by the server.
5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use
Between ICW Client Application and SPIRITS Server
5.3.3.1. Overview
In principle the solution involves session initiation over SSL
(meeting requirements for standards based security) after which the
SSL session is closed, thereby reducing the number of simultaneous
TCP/IP sessions. The rest of the session is communicated over
UDP/IP, secured using keys and other parameters exchanged securely
during the SSL session.
5.3.3.2. Session Initiation
The ICW client initiates an SRHDSP session, by reserving a UDP/IP
port, and opening an SSL session with the service (e.g., ICW) on the
service's well known SSL/TCP port. After establishing the SSL
Session, the ICW client sends the server its IP address, the reserved
UDP port number, and the set of supported symmetric key algorithms.
The server responds with a symmetric key algorithm chosen from the
set, the server's UDP port for further communication, heartbeat
period, and the value to use for the sequencing window.
The client then generates a symmetric key using the selected
algorithm and transmits this to the server. The SSL session is then
closed and the SRHDSP session is considered open.
5.3.3.3. Secure Reliable Datagram Transport
Application, and subsequent session management messages use symmetric
signaling. That is, the signaling is the same whether the client is
sending a message or the server is sending a message.
The message packets are transmitted securely. The protocol corrects
for lost, duplicated and out of sequence packets.
5.3.3.4. Session closure
The client or server may close the session.
A session is closed using a Close message including the next sequence
number, and encrypted with the agreed key.
The receiver, on processing (as opposed to receiving) a Close
message, should set a timer, when the timer expires all details of
the session should be forgotten. The timer is to allow for
retransmission of the close if the Ack gets lost, we still need to be
able to decrypt the subsequent retransmission and re-acknowledgment.
If any message other than a close is received after a close is
processed, it is ignored.
6. Telia/Nortel's Implementation
6.1. Overview
The system implemented by Telia in cooperation with Nortel Networks
is designed to support services that execute before the end-to-end
media sessions are established. These services include, for example:
- call transfer and number portability for redirecting calls
- call waiting and call offering for announcing a pending call
- call screening and don't disturb for filtering incoming calls
- automatic call distribution and 800-services for selecting
termination point
The Telia/Nortel system aims to allow service providers to develop
the services mentioned above. Presently, prototypes for online
incoming call disposition and automatic incoming call disposition
(described in Section 2) have been developed to prove the concept.
In the Telia/Nortel architecture, services run on top of SIP Redirect
Servers. The distributed nature of SIP enables these servers to be
hosted, for example, by an enterprise server, a Service Provider's
server cluster, a user's desktop PC, or even by a hand-held cordless
device.
The SIP Redirect Server receives a SIP INVITE message for each call
regardless of which network the call is being set up in. The server
MAY apply any kind of service logic in order to decide on how to
respond to the invitation. Service logic may interact with the user
to allow the user to specify how to handle a call such as described
in Section 2. This, however, is not the focus of the Telia/Nortel
system.
6.2. Architecture and Protocols
The general idea behind the architecture is to create services as if
all communication was based on IP and all clients and servers were
SIP enabled. This of cause is not true in existing
telecommunications networks. Hence, a new type of network element,
the Service Control Gateways (SCG) hides the true situation from the
services.
SCGs convert network-specific call control signaling to SIP messages
and vice versa. A SCG behaves as a regular SIP User Agent (UA)
towards the services and as a network-specific service control node
in the network where the call is being set up. For example, when
connecting to a GSM network, the SCG can play the role of an SCP or a
MAP or an ISUP proxy. The specific role depends on what service
triggers are being used in the GSM network.
SCGs handle protocol conversions but not address translation, such as
telephone number to SIP URL, which is handled by a regular SIP Server
to keep the SCG as simple as possible.
Consider a service example of number portability. A conventional
number portability implementation in a mobile Circuit Switched
Network (CSN) uses INAP messages to carry number queries to a
network-internal data base application. Here, a SCG and a high-
performance SIP Redirect Server, referred to as the Number Server
(NS), have replaced the data base typically located in an SCP. (See
Figure 11.)
+-----------+ INAP +-----+ SIP +--------------------------+
| CSN node |--------| SCG |-------| NS (SIP Redirect Server) |
+-----------+ +-----+ +--------------------------+
Figure 11: An Architecture for Number Portability
The INAP IDP message that carries the number query is converted to a
SIP INVITE message by the SCG and is then forwarded to the NS (SIP
Redirect Server).
If the called number is not registered, then the NS will return "404
Not Found". The SCG interprets this as "non ported number" and
returns a CON message to the CSN network, making it connect the call
to the called number.
If the number is ported and hence registered, then the NS will return
"301 Moved Permanently" with a TEL URL (routing number) in the
contact field. The SCG then returns a CON message to the CSN
network, making it connect the call to the number that was conveyed
in the contact field.
The solution above enables the same Number Server to provide Number
Portability to multiple networks by means of using multiple SCGs.
If we make the SIP server in the number portability example operate
in proxy mode for selected numbers, then it will become a kind of
service router, able to relay number queries to any SIP-Redirect-
Server-based service anywhere, provided there is an IP connection to
the host in concern. Figure 12 shows the arrangement.
+------+ INAP +-----+ SIP +----------------+ SIP +----------+
| CSN |------| SCG |-----| NS |-----| Service |
| node | | | |(redirect/proxy)| |(redirect)|
+------+ +-----+ +----------------+ +----------+
Figure 12: SIP-Based Service Router
Suppose that we connect a value-added service, such as a Personal
Call Filtering service hosted by a user's desktop PC, to a certain
telephone number. The INAP IDP message is converted to a SIP INVITE
message by the SCG and is then forwarded to the NS, just as in the
previous example. However, in this case, the number is registered
with a reference to a SIP URL. This makes the Number Server proxy
the SIP INVITE message to the registered URL, which is the address of
the service.
The service responds as a SIP Redirect Server and the Personal Call
Filtering service logic determines the response. The NS sends the
response back to the SCG which converts the response to an
appropriate INAP message. The response from the service is typically
"302 Moved Temporarily" with a telephone number in the Contact field.
If the response is 301 or 302, as the examples above suggest, then a
telephone number is carried in the contact field. If the user can be
reached via several different addresses, then all of them SHOULD be
added to the response by means of multiple contact fields. The SCG
then selects an address that is valid for the node or application
that issued the number query.
As illustrated by the service examples, the Telia/Nortel system aims
to allow the introduction of multi-network services without requiring
multi-protocol support. The services hence operate in the same way
regardless of in which network the call is made and common IP
services can be shared across heterogeneous networks.
+-----------+ +-------+ SIP +----+ ...... SIP +-----------+
| Network 1 |---| SCG 1 |-----| |---: :-----| Service A |
+-----------+ +-------+ | | : : +-----------+
| | : :
+-----------+ +-------+ SIP | | : : SIP +-----------+
| Network 2 |---| SCG 2 |-----| NS |---: :-----| Service B |
+-----------+ +-------+ | | : Any : +-----------+
| | : IP :
+-----------+ +-------+ SIP | | : net- : SIP +-----------+
| Network n |---| SCG n |-----| |---: work :-----| Service C |
+-----------+ +-------+ +----+ : : +-----------+
: :
+--------+ SIP : : SIP +-----------+
| SIP UA |-----------------------------: :-----| Service x |
+--------+ '......' +-----------+
Figure 13: Interconnecting Heterogeneous Networks via SIP
6.3. Security
The Telia/Nortel architecture uses security mechanisms available to
ordinary SIP services, implemented as they would be in a pure SIP
network. The architecture described here does not impose any
additional security considerations.
General security issues that must be considered include
interconnection of two different networks. SCGs must therefore
include mechanisms that prevent destructive service control signaling
from one network to the other. For example, a firewall-type
mechanism that can block a denial-of- service attack from an Internet
user toward the PSTN.
7. Security Considerations
Overall, the SPIRITS security requirements are essentially the same
as those for PINT [3, 4], which include, for example:
+ Protection of the PSTN from attacks from the Internet.
+ Peer entity authentication to allow a communicating entity to
prove its identity to another in the network.
+ Authorization and access control to verify if a network entity
is allowed to use a network resource.
+ Confidentiality to avoid disclosure of information (e.g., the
end user profile information and data) without the permission of
its owner.
+ Non-repudiation to account for all operations in case of doubt
or dispute.
As seen in the previous sections, most implementations examined in
this document have employed means (e.g., firewalls and encryption) to
meet these requirements. The means are, however, different from
implementation to implementation.
8. Conclusion
This document has provided information relevant to the development of
inter-networking interfaces between the PSTN and Internet for
supporting SPIRITS services. Specifically, it described four
existing implementations of SPIRITS-like services. Surveying these
implementations, we can make the following observations:
o The ICW service plays the role of a benchmark service. All four
implementations can support ICW, with three specifically designed
for it.
o SIP is used in most of the implementations as the based
communications protocol between the PSTN and Internet. (NEC's
implementation is the only exception that uses a proprietary
protocol. Nevertheless, NEC has a plan to support SIP together
with the extensions for SPIRITS services.)
o All implementations use IN-based solutions for the PSTN part.
It is clear that not all pre-SPIRITS implementations inter-operate
with each other. It is also clear that not all SIP-based
implementations inter-operate with each other given that they do not
support the same version of SIP. It is a task of the SPIRITS Working
Group to define the inter-networking interfaces that will support
inter-operation of the future implementations of SPIRITS services.
9. References
[1] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions
to SIP and SDP for IP Access to Telephone Call Services", RFC
2848, June 2000.
[2] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC2543, March 1999.
[3] Lu, H. (Ed.), Krishnaswamy, M., Conroy, L., Bellovin, S., Burg,
F., DeSimone, A., Tewani, F., Davidson, D., Schulzrinne, H. and
K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking--
Pre-PINT Implementations", RFC2458, November 1998.
10. Authors' Addresses
Igor Faynberg
Lucent Technologies
Room 4L-334
101 Crawfords Corner Road
Holmdel, NJ, USA 07733-3030
Phone: +1 732 949 0137
EMail: faynberg@lucent.com
Hui-Lan Lu
Lucent Technologies
Room 4L-317
101 Crawfords Corner Road
Holmdel, NJ, USA 07733-3030
Phone: +1 732 949 0321
EMail: huilanlu@lucent.com
John Voelker
Lucent Technologies
Room 1A-417
263 Shuman Blvd PO Box 3050
Naperville, IL, USA 60566-7050
Phone: +1 630 713 5538
EMail: jvoelker@lucent.com
Mark Weissman
Lucent Technologies
Room NE406B
200 Lucent Lane
Cary, NC, USA 27511-6035
Phone: +1 919 463 3258
EMail: maw1@lucent.com
Weizhong Zhang
Lucent Technologies
Room 01-A5-17
2000 Regency Parkway
Cary, NC, USA 27511-8506
Phone: +1 919 380-6638
EMail: wzz@lucent.com
Sung-Yurn Rhim
Korea Telecom
17 Woomyun-dong
Seocho-gu, Seoul, Korea
Phone: +82 2 526 6172
EMail: syrhim@kt.co.kr
Jinkyung Hwang
Korea Telecom
17 Woomyun-dong
Seocho-gu, Seoul, Korea
Phone: +82 2 526 6830
EMail: jkhwang@kt.co.kr
Shinji. Ago
NEC Corporation
1131, Hinode, Abiko,
Chiba, 270-1198, Japan
Phone: +81 471 85 7412
EMail: ago@ssf.abk.nec.co.jp
S. Moeenuddin
NEC America, Inc
1525 Walnut Hill Lane,
Irving, TX, USA 75038
Phone: +1 972 518 5102
EMail: moeen@asl.dl.nec.com
S. Hadvani
NEC America, Inc
1525 Walnut Hill Lane,
Irving, TX, USA 75038
Phone: +1 972 518 3628
EMail: hadvani@asl.dl.nec.com
Soren Nyckelgard
Telia Research
Chalmers Teknikpark
41288 Gothenburg
Sweden
EMail: soren.m.nyckelgard@telia.se
John Yoakum
Nortel Networks
507 Airport Blvd, Suite 115,
Morrisville, NC, USA 27560
EMail: yoakum@nortelnetworks.com
Lewis Robart
Nortel Networks
P.O. Box 402
Ogdensburg, NY, USA 13669
EMail: robart@nortelnetworks.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.