Request for Comments: 3976 Lucent Technologies, Inc.
Category: Informational F. Haerens
Alcatel Bell
V. Rastogi
Wipro Technologies
January 2005
Interworking SIP and Intelligent Network (IN) Applications
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
IESG Note
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose, and in particular notes that the decision to publish is not
based on IETF review for such things as security, congestion control,
or inappropriate interaction with deployed protocols. The RFC Editor
has chosen to publish this document at its discretion. Readers of
this document should exercise caution in evaluating its value for
implementation and deployment. See RFC 3932 for more information.
Abstract
Public Switched Telephone Network (PSTN) services such as 800-number
routing (freephone), time-and-day routing, credit-card calling, and
virtual private network (mapping a private network number into a
public number) are realized by the Intelligent Network (IN). This
document addresses means to support existing IN services from Session
Initiation Protocol (SIP) endpoints for an IP-host-to-phone call.
The call request is originated on a SIP endpoint, but the services to
the call are provided by the data and procedures resident in the
PSTN/IN. To provide IN services in a transparent manner to SIP
endpoints, this document describes the mechanism for interworking SIP
and Intelligent Network Application Part (INAP).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Access to IN-Services from a SIP Entity. . . . . . . . . . . . 4
3. Additional SIN Considerations . . . . . . . . . . . . . . . . 7
3.1. The Concept of State in SIP. . . . . . . . . . . . . . . 7
3.2. Relationship between SCP and a SIN-Enabled SIP entity. . 7
3.3. SIP REGISTER and IN services . . . . . . . . . . . . . . 8
3.4. Support of Announcements and Mid-Call Signaling. . . . . 8
4. The SIN Architecture . . . . . . . . . . . . . . . . . . . . . 8
4.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IN Service Control Based on the SIN Approach . . . . . . 9
5. Mapping of the SIP State Machine to the IN State Model . . . . 10
5.1. Mapping SIP Protocol State Machine to O_BCSM . . . . . . 11
5.2. Mapping SIP Protocol State Machine to T_BCSM . . . . . . 16
6. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
Author’s Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Introduction
PSTN services such as 800-number routing (freephone), time-and-day
routing, credit-card calling, and virtual private network (mapping a
private network number into a public number) are realized by the
Intelligent Network. IN is an architectural concept for the real-
time execution of network services and customer applications [1]. IN
is, by design, de-coupled from the call processing component of the
PSTN. In this document, we describe the means to leverage this
decoupling to provide IN services from SIP-based entities.
First, we will explain the basics of IN. Figure 1 shows a simplified
IN architecture, in which telephone switches called Service Switching
Points (SSPs) are connected via a packet network called Signaling
System No. 7 (SS7) to Service Control Points (SCPs), which are
general purpose computers. At certain points in a call, a switch can
interrupt a call and request instructions from an SCP on how to
proceed with the call. The points at which a call can be interrupted
are standardized within the Basic Call State Model (BCSM) [1, 2].
The BCSM models contain two processes, one each for the originating
and terminating part of a call.
When the SCP receives a request for instructions, it can reply with a
single response, such as a simple number translation augmented by
criteria like time of day or day of week, or, in turn, initiate a
complex dialog with the switch. The situation is further complicated
by the necessity to engage other specialized devices that collect
digits, play recorded announcements, perform text-to-speech or
speech-to-text conversions, etc. (These devices are not discussed
here.) The related protocol, as well as the BCSM, is standardized by
the ITU-T and known as the Intelligent Network Application Part
protocol (INAP) [4]. Only the protocol, not an SCP API, has been
standardized.
+-----------+
| |
| SCP |
| |
+-----------+
||
||
/ \
/ \
/ INAP \
/ \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
Figure 1. Simplified IN Architecture
The overall objective is to ensure that IN control of Voice over IP
(VoIP) services in networks can be readily specified and implemented
by adapting standards and software used in the present networks.
This approach leads to services that function the same when a user
connects to present or future networks, simplifies service evolution
from present to future, and leads to more rapid implementation.
The rest of this document is organized as follows: Section 2 contains
the architectural model of an IN aware SIP entity. Section 3
provides some issues to be taken into account when performing SIP/IN
interworking (SIN). Section 4 discusses the IN service control based
on the SIN approach. The technique outlined in this document focuses
on the call models of IN and the SIP protocol state machine; Section
5 thus establishes a complete mapping between the two state machines
that allows access to IN services from SIP endpoints. Section 6
includes call flows of IN services executing on SIP endpoints. These
services are readily enabled by the technique described in this
document. Finally, Section 7 covers security aspects of SIN.
List of Acronyms
B2BUA Back-to-Back User Agent
BCSM Basic Call State Model
CCF Call Control Function
DP Detection Point
DTMF Dual Tone Multi-Frequency
IN Intelligent Network
INAP Intelligent Network Application Part
IP Internet Protocol
ITU-T International Telecommunications Union -
Telecommunications Standardization Sector
O_BCSM Originating Basic Call State Model
PIC Point in Call
PSTN Public Switched Telephone Network
RTP Real Time Protocol
R-URI Request URI
SCF Service Control Function
SCP Service Control Point
SIGTRAN Signal Transport Working Group in IETF
SIN SIP/IN Interworking
SIP Session Initiation Protocol
SS7 Signaling System No. 7
SSF Service Switching Function
SSP Service Switching Point
T_BCSM Terminating Basic Call State Model
UA User Agent
UAC User Agent Client
UAS User Agent Server
VoIP Voice over IP
VPN Virtual Private Network
2. Access to IN-Services from a SIP Entity
The intent of this document is to provide the means to support
existing IN-based applications in a SIP [3] environment. One way to
gain access to IN services transparently from SIP (e.g., through the
same detection points (DPs) and point-in-call (PIC) used by
traditional switches) is to map the SIP protocol state machine to the
IN call models [1].
From the viewpoint of IN elements such as the SCP, the request’s
origin from a SIP entity rather than a call processing function on a
traditional switch is immaterial. Thus, it is important that the SIP
entity be able to provide the same features as the traditional
switch, including operating as an SSP for IN features. The SIP
entity should also maintain call state and trigger queries to IN-
based services, as do traditional switches.
This document does not intend to specify which SIP entity shall
operate as an SSP; however, for the sake of completeness, it should
be mentioned that this task should be performed by SIP entities at
(or near) the core of the network rather than at the SIP end points
themselves. To that extent, SIP entities such as proxy servers and
Back-to-Back user agents (B2BUAs) may be employed. Generally
speaking, proxy servers can be used for IN services that occur during
a call setup and teardown. For IN services requiring specialized
media handling (such as DTMF detection) or specialized call control
(such as placing parties on hold) B2BUAs will be required.
The most expeditious manner for providing existing IN services in the
IP domain is to use the deployed IN infrastructure as often as
possible. In SIP, the logical point to tap into for accessing
existing IN services is either the user agents or one of the proxies
physically closest to the user agent (and presumably in the same
administrative domain). However, SIP entities do not run an IN call
model; to access IN services transparently, the trick then is to
overlay the state machine of the SIP entity with an IN layer so that
call acceptance and routing is performed by the native state machine
and so that services are accessed through the IN layer by using an IN
call model. Such an IN-enabled SIP entity, operating in synchrony
with the events occurring at the SIP transaction level and
interacting with the IN elements (SCP), is depicted in Figure 2:
+-------+
| SCP |
+---+---+
|
| INAP
|
+--------+
| SIN |
+........+
| SIP |
---------->| Entity |--------->
Requests | | Requests out
in +--------+ (after applying IN
services)
SIN: SIP/IN Interworking layer
Figure 2. SIP Entity Accessing IN Services
Section 5 proposes this mapping between the IN layer and the SIP
protocol state machine. Essentially, a SIP entity exhibiting this
mapping becomes a SIN-enabled SIP entity.
This document does not propose any extensions to SIP.
Figure 3 expands the SIP entity depicted in Figure 2 and further
details the architecture model involving IN and SIP interworking.
Events occurring at the SIP layer will be passed to the IN layer for
service application. More specifically, since IN services deal with
E.164 numbers, it is reasonable to assume that a SIN-enabled SIP
entity that seeks to provide services on such a number will consult
the IN layer for further processing, thus acting as a SIP-based SSP.
The IN layer will proceed through its BCSM states and, at appropriate
points in the call, will send queries to the SCP for call
disposition. Once the disposition of the call has been determined,
the SIP layer is informed and processes the transaction accordingly.
Note that the single SIP entity as modeled in this figure can in fact
represent several different physical instances in the network as, for
example, when one SIP entity is in charge of the terminal or access
network/domain, and another is in charge of the interface to the
Switched Circuit Network (SCN).
+-------+
| SCP |
+---o---+
|
+-----+
|
**********|***********************************
* +-------|-------------------+ *
* |+------o------+ | *
* || SSF(IP) | | *
* |+-------------+ | *
* || CCF(IP) | | *
* |+------o------+ | *
* +-------|-------------------+ *
* | SIN-enabled *
* +-------o-------------------+ SIP *
* | SIP Layer | Entity *
* +---------------------------+ *
**********************************************
Figure 3. Functional Architecture of a SIN-Enabled SIP Entity
The following architecture entities, used in Figure 3, are defined in
the Intelligent Network standards:
Service Switching Function (SSF): IN functional entity that
interacts with call control functions.
Call Control Function (CCF): IN functional entity that refers
to call and connection handling in the classical sense (i.e.,
that of an exchange).
3. Additional SIN Considerations
In working between Internet Telephony and IN-PSTN networks, the main
issue is to translate between the states produced by the Internet
Telephony signaling and those used in traditional IN environments.
Such a translation entails attention to the considerations listed
below.
3.1. The Concept of State in SIP
IN services occur within the context of a call, i.e., during call
setup, call teardown, or in the middle of a call. SIP entities such
as proxies, with which some of these services may be realized,
typically run in transaction-stateful (or stateless) mode. In this
mode, a SIP proxy that proxied the initial INVITE is not guaranteed
to receive a subsequent request, such as a BYE. Fortunately, SIP has
primitives to force proxies to run in a call-stateful mode; namely,
the Record-Route header. This header forces the user agent client
(UAC) and user agent server (UAS) to create a "route set" that
consists of all intervening proxies through which subsequent requests
must traverse. Thus SIP proxies must run in call-stateful mode in
order to provide IN services on behalf of the UAs.
A B2BUA is another SIP element in which IN services can be realized.
As a B2BUA is a true SIP UA, it maintains complete call state and is
thus capable of providing IN services.
3.2. Relationship between SCP and a SIN-Enabled SIP Entity
In the architecture model proposed in this document, each SIN-enabled
SIP entity is pre-configured to communicate with one logical SCP
server, using whatever communication mechanism is appropriate.
Different SIP servers (e.g., those in different administrative
domains) may communicate with different SCP servers, so that there is
no single SCP server responsible for all SIP servers.
As Figures 1 and 2 depict, the IN-portion of the SIN-enabled SIP
entity will communicate with the SCP. This interface between the IN
call handling layer and the SCP is not specified by this document
and, indeed, can be any one of the following, depending on the
interfaces supported by the SCP: INAP over IP, INAP over SIGTRAN, or
INAP over SS7.
This document is only applicable when SIP-controlled Internet
telephony devices seek to operate with PSTN devices. The SIP UAs
using this interface would typically appear together with a media
gateway. This document is *not* applicable in an all-IP network and
is not needed in cases where PSTN media gateways (not speaking SIP)
need to communicate with SCPs.
3.3. SIP REGISTER and IN Services
SIP REGISTER provisions a SIP Proxy or SIP Registration server. The
process is similar to the provisioning of an SCP/HLR in the switched
circuit network. SCPs that provide VoIP based services can leverage
this information directly. However, this document neither endorses
nor prohibits such an architecture and, in fact, considers it an
implementation decision.
3.4. Support of Announcements and Mid-Call Signaling
Services in the IN such as credit-card calling typically play
announcements and collect digits from the caller before a call is set
up. Playing announcements and collecting digits require the
manipulation of media streams. In SIP, proxies do not have access to
the media data path. Thus, such services should be executed in a
B2BUA.
Although the SIP specification [3] allows for end points to be put on
hold during a call or for a change of media streams to take place, it
does not have any primitives to transport other than mid-call control
information. This may include transporting DTMF digits, for example.
Extensions to SIP, such as the INFO method [5] or the SIP event
notification extension [6], can be considered for services requiring
mid-call signaling. Alternatively, DTMF can be transported in RTP
itself [7].
4. The SIN Architecture
4.1. Definitions
The SIP architecture has the following functional elements defined in
[3]:
- User agent client (UAC): The SIP functional entity that
initiates a request.
- User agent server (UAS): The SIP functional entity that
terminates a request by sending 0 or more provisional SIP
responses and one final SIP response.
- Proxy server: An intermediary SIP entity that can act as both a
UAS and a UAC. Acting as a UAS, it accepts requests from UACs,
rewrites the Request-URI (R-URI), and, acting as a UAC, proxies
the request to a downstream UAS. Proxies may retain
significant call control state by inserting themselves in
future SIP transactions beyond the initial INVITE.
- Redirect server: An intermediary SIP entity that redirects
callers to alternate locations, after possibly consulting a
location server to determine the exact location of the callee
(as specified in the R-URI).
- Registrar: A SIP entity that accepts SIP REGISTER requests and
maintains a binding from a high-level URL to the exact location
for a user. This information is saved in some data-store that
is also accessible to a SIP Proxy and a SIP Redirect server. A
Registrar is usually co-located with a SIP Proxy or a SIP
Redirect server.
- Outbound proxy: A SIP proxy located near the originator of
requests. It receives all outgoing requests from a particular
UAC, including those requests whose R-URIs identify a host
other than the outbound proxy. The outbound proxy sends these
requests, after any local processing, to the address indicated
in the R-URI.
- Back-to-Back UA (B2BUA): A SIP entity that receives a request