Internet DRAFT - draft-buller-spirits-ccib
draft-buller-spirits-ccib
PINT Working Group J. Buller
INTERNET-DRAFT Unisphere Solutions
Category: Informational
Expires: December 2000
A proposal for the provisioning of Call
Completion Internet Busy using PINT and SPIRITS
<draft-buller-spirits-ccib-00.txt>
Status of this Memo
This is an Internet-Draft and is in full conformance with all the
provisions of section 10 of RFC2026.
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.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Copyright Notice
Copyright (c) The Internet Society (1999). All rights reserved.
Abstract
This Internet Draft has arisen out of work concentrating on the
interconnection of IP and the Public Switched Telephone Network
(PSTN) undertaken within the PINT and SPIRITS working group.
This Internet Draft describes an implementation architecture for
co-operative services initiated from either the PSTN or Internet
domains. It further describes how this architecture may be used in
provision of a Call Completion Internet Busy (CCIB) aka Internet Call
Waiting (ICW) service.
Buller [Page 1]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
This Internet Draft deliberately does not define the protocols for
these kinds of services, although descriptions contained within it do
use Session Initiation Protocol (SIP) terminology.
Contents
The contents of the rest of this document is as follows:
Section 2
Acts as an introduction providing a high level description of the ICW/
CCIB service and the difference between PINT and SPIRITS.
Section 3
Specifies the general requirements for implementations of the service
identified in Section 2.
Section 4
Identifies and discusses the general architectural considerations in
provisioning enhanced co-operative services such as CCIB/ ICW. It then
proposes the architectural elements required to perform the CCIB/ ICW
service, described in the remainder of this Internet Draft.
Section 5
Describes the implementation scenario of an CCIB/ ICW service using
these architectural elements.
Section 6
Discusses initially identified security considerations which relate to
this implementation of the CCIB/ ICW service.
Section 7
Conclusions.
Section 8
References and Glossary.
Section 9
Acknowledges individuals providing assistance in the creation of this
Internet Draft.
Section 10
Author's address.
2. Introduction
The primary considered service to date, with regard to the efforts of
the SPIRITS working group, is that of Internet Call Waiting ICW (aka
Call Completion Internet Busy, or CCIB).
The CCIB service allows users who are logged onto the Internet (using
for example, a dial up account) to determine the completion actions
for telephony calls attempted to the telephone number that they are
presently using for this connection. Examples of these 'completion
actions' might be :
Buller [Page 2]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
o Refuse the call.
o Forward the call to Voice Mail.
o Forward the call to another number.
o Drop the Internet connection and take the telephony call over the
same line.
o Establish VoIP connection on terminating side to take the call.
o Take details of the callee for later connection.
o Take a voice message which can then be relayed to the terminating
end device.
This document briefly describes how implementation of such a service
could be undertaken using both PINT and some other protocol (possibly
aligned with the SPIRITS architecture).
Both PINT and SPIRITS are intended to provide mechanisms for requests
(or initiation) of service between the Internet and PSTN domains, and
vice versa. Requests (initiations) from the Internet to the PSTN and
responses to these requests is the PINT case. Requests from the PSTN
to the Internet domain and responses to these requests is the SPIRITS
case. This is shown more clearly in Figure 1.
................................
: IETF PINT/SPIRITS WG Domain :
: :
: +----------+ :+----------+
: | Internet | :| PSTN |
: | Domain |+--------------+:| Domain |
: | Services || PINT |:| Services |
: | || |:| |
: | A || request |:| P |
: | P |>>>>>>>>>>>>>>>>:| S |
: | P || |:| T |
: | L || response |:| N |
: | I |<<<<<<<<<<<<<<<<:| |
: | C || |:| |
: | A |+--------------+:| S |
: | T | :| E |
: | I | :| R |
: | O |+--------------+:| V |
: | N || SPIRITS |:| I |
: | || |:| C |
: | S || request |:| E |
: | E |<<<<<<<<<<<<<<<<:| S |
: | R || |:| |
: | V || response |:| e.g. |
: | E |>>>>>>>>>>>>>>>>:| IN or |
: | R || |:| Soft |
: | S |+--------------+:| Switch |
: | | :| |
: +----------+ :+----------+
................................
Figure 1.
PINT and SPIRITS bridging the
PSTN/ Internet domains
Buller [Page 3]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
3. General Requirements
This section attempts to specify an initial set of requirements and
service characteristics for an implementation of CCIB using the PINT
and SPIRITS paradigms:
o Use of the service MUST be capable of being undertaken in a
secure manner.
o Use of this service should be non repudiable.
o The described implementation should not be dependent in ANY way
on specific technology being deployed outside of the Internet
domain.
4. Proposed Architecture
This section initially discusses the CCIB service and architectural
considerations and implications. Next, the proposed architecture for
the CCIB service which uses PINT and SPIRITS is outlined.
4.1. General architectural and service considerations and implications
The implementation detailed in this Internet Draft allows subscibers
to register for this service. This registration could be forwarded to
the PSTN domain using the PINT protocol. Such a registration may be
undertaken each time a subscriber connects to the Internet and wishes
to receive (SPIRITS like) requests. Specific details of what and how
the PSTN domain may implement certain aspects of this service are
considered outside the scope of this Internet Draft. As such, only
generalised functional descriptions are provided and no specific
recommendation or suggestions are proffered.
Possible implementations might be that the PSTN domain could :
o Dynamically set flags (service marks) in the switch relating to
the subscribers line. This could indicate that call attempts to
this number (for the duration of the current call) will result
in the initiation of a SPIRITS service.
o An IN system could be used to handle call attempts to busy lines
over which a subscriber is engaged in an Internet session.
Indeed, it is entirely possible in some implementations (say, a Soft
Switch providing Internet Offload) that no registration phase will be
required. This scenario is not discussed further as this paper deals
with the co-operation of PINT/ SPIRITS to provide enhanced services.
In implementatations where explicit subscriber registration is deemed
to be required (such as the one detailed in section 5) registration
storage can be undertaken in several locations in either the Internet
or PSTN domains. This data can either be :
o located in the Internet domain and referenced directly by a ICW/
CCIB SPIRITS client (also in the Internet domain) once it has
Buller [Page 4]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
received a request from the PSTN (see note below).
or
o located in the PSTN domain and referenced by some entity within
this domain that then issues the request to the CCIB/ICW SPIRITS
client in the Internet domain (see note below). In some impleme-
ntations this request may require some form of resolution within
the Internet domain to map the request to the current IP address
of the subscriber.
Note! the request initiated within the PSTN domain is itself NOT a
SPIRITS request. This interface/ invocation mechanism is considered
(by the author) to be out of scope, very likely to be implementation
specific and most probably proprietary in nature. Differentiation of
this interface from that provided by the SPIRITS protocol has been
the source of some apparent confusion. However, if we take a closer
look at the PSTN interface identified in Figure 1. and add some of
the functional components, originally specified in the PINT protocol,
and then apply a similar paradigm to SPIRITS the situation becomes
clearer.
........................................
: IETF PINT/SPIRITS WG's Domain :
: +-------------+ +----------------------------+
: | Internet | : PSTN/IN/Soft Switch |
: | Services | +-------:--------+ Services |
: | | PINT | PINT : | |
: | | | G/W : | +-----------+ |
: | +-----------| request |-------:-------+| | | |
: | | |>>>>>>>>>>>>>| : |>>>>>>| | |
: | | PINT | | PINT : SoP || SoP | Executive | |
: | | CLIENT | response |SERVER : CLIENT|| 1 | System | |
: | | |<<<<<<<<<<<<<| : |<<<<<<| | |
: | +-----------| |-------:-------+| +-----------+ |
: | /\ | +-------:--------+ /\ |
: | Co-operation| : Co-operation |
: | to provide | +-------:--------+ to provide |
: | services | SPIRITS |SPIRITS: | services |
: | \/ | |G/W : | \/ |
: | +-----------| request |-------:-------+| +-----------+ |
: | | |<<<<<<<<<<<<<| : |<<<<<<| | |
: | | SPIRITS | |SPIRITS: SoP || SoP | Initiative| |
: | | SERVER | response |CLIENT : SERVER|| 2 | System | |
: | | |>>>>>>>>>>>>>| : |>>>>>>| | |
: | +------.----| |-------:-------+| +-----------+ |
: | ^ . | +-------:--------+ |
: | . . | : |
: +-------------+ :+---------------------------+
: : G/W - Gateway
........................................ SoPx - Some other Protocol
Figure 2.
Architectectural differentiation between the
PINT and SPIRITS protocols and PSTN/IN interface
So taking the above PSTN interface architecture into account and
referencing back to where registration information may be stored; it
Buller [Page 5]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
can be seen that the SoP interface itself will vary dependent on the
implemenation decisions made. However, as previously stated, the SoP
interface is considered to be out of scope of this Internet Draft.
Upon receipt of an initiation request from some entity in the PSTN
domain, the request is passed to the SPIRITS client in the SPIRITS
gateway for formulation of SPIRITS message(s). These messages may be
used to gain further information from entities in the Internet domain
or to initiate/ request SPIRITS services directly.
4.2. Proposed Architecture
This section identifies and describes the architectural entities
identified in Figure 1 and how these relate to the provision of 'one'
possible implementation of a CCIB service discussed in more detail in
section 5 of this document. Various implementations may locate this
functionality in different places or domains (PSTN or Internet). Some
entities may not be required in other possible implementations. The
entities within this proposed implementation are :
PSTN
An entity in the PSTN domain (e.g. IN or Soft Switch) initiates a
request for service from this domain to the Internet domain. As
previously discussed (in Section 4.1.) this does not mean that it
directly passes SPIRITS requests. Instead requests are issued to
the SPIRITS gateway where the SPIRITS client constructs and issues
SPIRITS requests.
User equipment
In the implementation detailed in this document the user connects
to Internet using a dial up account from equipment suitable for
such connectivity. User equipment will have a small SPIRITS server
for receiving SPIRITS requests and 'possibly' a PINT Client for
registration and initiation of PINT services. These entities may
have been previously downloaded or may be downloaded each time a
subscriber registers that they are connected and wish to be able
to use PINT and SPIRITS services.
Web Server
Provides a mechanism for subscribers to register for receipt of
SPIRITS messages.
SPIRITS client
Contained within the SPIRITS gateway (see Figure 2), it receives
initiating requests from the PSTN and formulates them into SPIRITS
requests.
SPIRITS server
Receives and handles SPIRITS requests. As previously stated, this
server could either be initially downloaded and used after each
subsequent registration, or, downloaded each time as part of the
registration process.
Buller [Page 6]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
Subscriber data store
Maintains subscriber details and registration requests.
5. Implementation Scenario
Figures 3 and 4 briefly detail an implementation for provisioning the
Call Completion Internet Busy (CCIB) service. These figures identify
the objects and the sequence of flows required and are split into two
for clarity. The first provides details of how registration for use
of the service is made. The second details how the user is contacted
after a call attempt has been made, and how their choice, as to how
to handle the call, is then relayed to the initiative system.
5.1 Service Registration Phase
There are at least two mechanisms (excluding the Soft Switch Internet
Handoff scenario indentified in Section 4.1), each with a variety of
flavours, in which the registration and setup for this service may
occur. Each of these depends on the various business models which
different vendors might wish to implement:
1) The service may be implemented by use of an explicit binding to
a telephony subscriber's known (billable) number. The customer
may then either register or subscribe to the service when they
connect to the Internet. This registration could be held in the
PSTN domain where receipt of a call attempt to a busy telephone
number may directly result in a service request, or result in a
check of a data store of current registrands in the PSTN domain
before the service is requested.
Alternatively, the registration information may be held in the
Internet domain, and the PSTN system may query this store, and
activate the service, when the line is found to be engaged.
This type of implementation is inherently more secure than the
next option due to the explicit binding to a telephone number.
Mechanisms can more easily be provided to require registrations
from this line for the subscriber.
2) The second scenario could allow a subscriber to register at
whatever telephone number they happen to be using for their dial
up connection. Once on-line they would register to the service.
This registration could contain the currently used telephone
number though this provides further security risks (e.g. wrong
number specification by fault or design).
This proposal could allow subscribers to register in a portable
fashion from any number.
This might be less satisfactory than 1 (above) in terms of phone
number security i.e. in tying such service provision to a number
by what an ISP clients 'says'. However, some implementation of
Calling Line Identitity (CLI) could be used by the ISP to obtain
this number directly. It is most likely that there would be
Buller [Page 7]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
a requirement for interworking and/ or Service Level Agreements
(SLA) between the ISP and telephony operator in order to secure
such a service. Such interworking is outside the scope of this
Internet Draft.
The maintenance of the subscribers registration could follow the
same lines as those discussed in 1) above.
This option is inherently less secure than that suggested in 1)
above.
+----------------+
| User Equipment |
| |
| +-------+ |
| | Modem | | ()-()
| +-------+ |--- /^\
+----------------+ ---
| | ^
| | |
1| 2| 7|
| | |
v | |
+----+ | |
|ISP/| | |
|RAS | v |
+----+.......
...../ \.....
....../ \......
/ \
| Internet |
\...... ....../
| ^ \..... ...../ | ^
| | \........../ | |
| | ^ | | |
| | | | | |
2| 7| 3| 5| 3| 5|
v | | v v |
+--------+ 6 +---------+ +-----------+
| Web |<----| PINT | | PINT |
| Server |---->| Client | | Server |
+--------+ 2 +---------+ +-----------+
^ |
| v
+-----------+
| Registrar |
+-----------+
|
| 4
v
+-------+
| Data |
| Store |
+-------+
Figure 3.
Buller [Page 8]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
The description of the flows shown above is as follows :
1. The user connects.
2. The user (or their ISP) submits Registration details containing
CSeq, IP address, telephone number and keys to a web server.
3. The PINT registration message is constructed and sent to PINT
server
4. The user details provided are then checked against subscription
details and possibly CLI. These details are then stored.
5. The response message is constructed and returned to PINT client.
6. The PINT client informs the Web Server of the status.
7. If the response message to the registration indicates that it
was accepted, a 'thin' SPIRITS server applet is sent to the
users machine. Only a thin SPIRITS server would be required to
handle requests as the exact format of possible SPIRITS requests
would be known for this service.
5.1.2. Call Attempt Phase
The description of the flows shown below (in figure 4) is as follows :
1. The call attempt is made. The PSTN/ IN detects call in progress
and busy SPIRITS subscriber line. It then plays an announcement
to the calling party. Next, the PSTN/ IN initiates a request to
the SPIRITS client, using some other protocol (which could be
INAP).
2. The SPIRITS client issues the SPIRITS invitation request.
3. Presently registered details are looked up.
4. The final SPIRITS invitation request is constructed and sent.
Then one of two things can occur detailed in 4a and 4b.
4a. The invitation request is received by the called party. Continue
to flow 5.
4b. The invitation request does not reach the intended recipient or
times out. A failure message is returned to the SPIRITS client
on the initiative system.
5. The 'thin' SPIRITS server applet on the called party's machine
receives the invitation request and allows the user to decide
how this call should be handled. Possible options here could be :
a) Drop the Internet connection and take the call over the PSTN
/IN system.
Buller [Page 9]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
b) Accept the connection via a VoIP gateway in the PSTN/ IN.
c) Pass the call on to a Voice Mail system.
d) Play Announcements.
e) Refuse the call.
6. The called party's wishes are contained in this response which is
passed back to the initiative system.
+----------------+
| User Equipment |
| +----------+ |
| | SPIRITS | | 5
| | Server | |
| +----------+ |
| +-------+ |
| | Modem | | ()-()
| +-------+ |--- /^\
+----------------+ ---
^ |
4a| 6|
| |
| v
..........
...../ \.....
....../ \......
/ \
| Internet |
\...... ....../
\..... ...../
\........../
^ |
4| |4b/6
| | +------------------+
| v |Initiative System |
+-----------+ 4b/6 +--------+ |
| SPIRITS |----->| SPIRITS| |
| Server |<-----| Client | |
+-----------+ 2 +--------+ |
^ | | |
| v +------------------+
+-----------+ ^
| Registrar | |
+-----------+ |
| ^ |
| | 1|
3| 3| |
v | |
+-------+ ()-()
| Data | /^\
| Store | ---
+-------+
Figure 4.
Buller [Page 10]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
Note! Due to the fact that registration is issued by the subscriber,
not hand crafted or permanently pinned-up by the service provider,
this inherently provides the possibility of service mobility. A
subscriber 'may' register themselves on any number. There are obvious
security concerns with this and these are discussed in other sections
of this Internet Draft.
6. Security Implications
It is acknowledged that there are some serious security implications
which arise in consideration of such an implementation. These issues
are primarily related the registration and de-registration phases.
6.1. Registration
A user may attempt to Register for this service on another's number
(by accident or design) in order to claim notification on a line they
have no right to.
In a 'real world' implementation of this service this security issue
will need to be resolved. As well as the use of standard security
mechanisms such as passwords and keys, more secure implementations
could undertake to :
1) Only allow this kind of access from the user's own phone.
2) Provide functionality to check the actual CLI from which the user
issued their Registration (as highlighted early).
3) Only provide two possibilities on 'untrusted' (e.g. "roaming" or
"non home") numbers, that is drop the current Internet connection
and establish a POTS call, or ignore the SPIRITS message.
4) Maintain good accounting in order to track offenders down.
6.2. De-registration
The de-registration problem would arise if a user did not de-register
themselves before they finished using the Internet. This likely to
be a common occurrence e.g. users turning off their machines/ modems
without de-registering. It is expected that any implementation should
build in a mechanism to handle this scenario. Authenticators could be
passed in responses to the registration messages sent to the SPIRITS
service on the user's machine. Alternatively, these authenticators
could be placed directly in the SPIRITS server when it is initially
downloaded.
When the user logs off the Internet, without de-registering, there
are three scenarios which could happen when an attempt is made to
place a call to the number the user specified as their location :
1) The line is not busy, therefore place the call and remove any
previously held registrations.
Buller [Page 11]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
2) The line is busy on a voice call. An attempt to send a INVITE
message fails (as there would be no receiving SPIRITS server).
Any previously held registration for this number could then be
removed.
3) Another user (or the same user on a different Internet session)
has registered for receipt of calls on this number. There are
two solution possibilities :
a) When the new registration is made the old is replaced
immediately.
or
b) The new registration is kept until an Authenticator fails
on the SPIRITS server of the new registrand when a call
attempt is made. When the Authenticator fails the INVITE
fails and the original registration can be removed and
replaced with the new. The INVITE is then resent to the new
registrand.
7. Conclusions
This Internet Draft has initially provided an overview description of
how the PINT and SPIRITS paradigms differ. However, it has also shown
how they may be used together in the provision of services.
Various required entities, mechanisms and their location required in
the provision of an ICW/ CCIB service have also been discussed.
This Internet draft has detailed an implementation of CCIB which uses
PINT and SPIRITS 'like' functionality in provision of two aspects of
the one service.
Buller [Page 12]
<draft-ietf-spirits-ccib-01.txt> CCIB (PINT & SPIRITS) December, 2000
8. References
[1] Postel, J., "Instruction to RFC Authors", RFC 1543, October 1993.
[2] Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J.,
"SIP Session Initiation Protocol", RFC 2543, March 1999.
[3] Handley, M., Jacobson, V., "SDP Session Description Protocol"
RFC 2327, April 1998.
[4] Petrack, S., Conroy, L., "The PINT Service Protocol: Extensions
to SIP and SDP for IP access to Telephone Call Services",
RFC 2848, June 2000.
Glossary
CCIB Call Completion Internet Busy
ICW Internet Call Waiting
IN Intelligent Network
PINT PSTN Internet working
POTS Plain Old Telephone Service
PSTN Public Switched Telephone Network
SDP Session Description Protocol
SIP Session Initiation Protocol
SoP Some other Protocol (used within the PSTN)
VoIP Voice over IP (Internet Protocol)
9. Acknowledgments
The author would like to acknowledge the following people.
Lawrence Conroy for proof reading this document.
10. Author's Address
Jim Buller
Unisphere Solutions,
900 Broken Sound Parkway, B12S
Boca Raton,
FL 33487
USA
Telephone: +1 561 923 3132
E-mail: jbuller@unispheresolutions.com
Buller [Page 13]
