INTERNET-DRAFT Vijay K. Gurbani
June 2002 Lucent Technologies, Inc.
Expires: December 2002 Frans Haerens
Alcatel Bell
Vidhi Rastogi
Wipro Technologies
Document: draft-gurbani-sin-02.txt
Category: Informational
Interworking SIP and Intelligent Network (IN) Applications
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Public Switched Telephone Network (PSTN) services such as 800 number
routing (freephone), time-and-day routing, credit-card calling,
virtual private network (mapping a private network number into a
public number) are realized by the Intelligent Network (IN). This
draft 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
draft-gurbani-sin-02.txt [Page 1]
Interworking SIP and Intelligent Network (IN) Applications June 2002
endpoints, this draft describes the mechanism for interworking SIP
and Intelligent Network Application Part (INAP).
Table of Contents
1 INTRODUCTION.................................................. 3
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.... 8
3.3 SIP REGISTER and IN services............................. 8
3.4 Support of announcements and mid-call signaling.......... 8
4 THE SIN ARCHITECTURE.......................................... 9
4.1 Definitions.............................................. 9
4.2 IN Service control based on the SIN approach.............10
5 MAPPING OF THE SIP STATE MACHINE TO THE IN STATE MODEL........11
5.1 Mapping SIP protocol state machine to O_BCSM.............12
5.2 Mapping SIP protocol state machine to T_BCSM.............17
6 EXAMPLE CALL FLOWS............................................22
7 SECURITY CONSIDERATIONS.......................................23
Appendix A.......................................................23
Normative References.............................................24
Informative References...........................................24
Acknowledgments..................................................25
Changes from previous drafts.....................................25
Author's addresses...............................................26
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
draft-gurbani-sin-02.txt [Page 2]
Interworking SIP and Intelligent Network (IN) Applications June 2002
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
1 Introduction
PSTN services such as 800 number routing (freephone), time-and-day
routing, credit-card calling, 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 draft, we describe the means to leverage this
decoupling to provide IN services from SIP-based entities.
We first 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 where a call can be interrupted
are standardized within the Basic Call State Model (BCSM) [1, 2].
The BCSM models contains two processes, one each for the originating
and terminating part of a call.
When the SCP gets an request for instructions, it can reply with a
single response, such a simple number translation augmented by
criteria like time of day or day of week, or, in turn, get into a
complex dialog with the switch. The situation is further complicated
by the necessity to engage other specialized devices, which collect
digits, play recorded announcement, perform text-to-speech or
speech-to-text conversion, 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, have been
standardized.
draft-gurbani-sin-02.txt [Page 3]
Interworking SIP and Intelligent Network (IN) Applications June 2002
+-----------+
| |
| 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 connect
to present or future networks, simplifies service evolution from
present to future, and leads to more rapid implementation.
The rest of this draft 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 draft 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
which allows for 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
draft. Finally, section 7 covers security aspects of SIN.
2 Access to IN-services from a SIP entity
The intent of this draft is to provide means to support existing IN-
based applications in a SIP [3] environment. One way to gain access
to IN services transparently (i.e., through the same detection points
(DPs) and point-in-call (PIC) used by traditional switches) from SIP
is to map the SIP protocol state machine to the IN call models [1].
From the viewpoint of IN elements like the SCP, the fact that the
request originated from a SIP entity versus a call processing
function on a traditional switch is immaterial. Thus, it is
draft-gurbani-sin-02.txt [Page 4]
Interworking SIP and Intelligent Network (IN) Applications June 2002
important that the SIP entity be able to provide features normally
provided by the traditional switch, including operating as a SSP for
IN features. The SIP entity should also maintain call state and
trigger queries to IN-based services, just as traditional switches
do.
It is not the intent of this draft to specify which SIP entity shall
operate as a 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 instead of the SIP end points
themselves. To that extent, SIP entities like proxy servers and
Back-to-Back UAs (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 much as
possible. The logical point in SIP to tap into for accessing
existing IN services is either the UAs or one of the proxy located
physically closest to the UA (and presumably in the same
administrative domain as the UA). However SIP entities do not run an
IN call model; to transparently access IN services, the trick then,
is to overlay the state machine of the SIP entity with an IN layer
such that call acceptance and routing is performed by the native
state machine and services are accessed through the IN layer 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:
draft-gurbani-sin-02.txt [Page 5]
Interworking SIP and Intelligent Network (IN) Applications June 2002
+-------+
| 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 such a mapping between the IN layer and the SIP
protocol state machine. Essentially, a SIP entity exhibiting such a
mapping becomes a SIN-enabled SIP entity.
This draft 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 wants 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 a decision has been made on the disposition of the
call, the SIP layer is so informed and it processes the transaction
accordingly.
It should be noted that the single SIP entity as modeled in this
figure can in fact represent several different physical instances in
the network, for example with one SIP entity in charge of the
terminal or access network/domain, and another in charge of the
interface to the Switched Circuit Network (SCN).
draft-gurbani-sin-02.txt [Page 6]
Interworking SIP and Intelligent Network (IN) Applications June 2002
+-------+
| SCP |
+---o---+
|
+-----+
|
**********|***********************************
* +-------|-------------------+ *
* |+------o------+ | *
* || SSF(IP) | | *
* |+-------------+ | *
* || CCF(IP) | | *
* |+------o------+ | *
* +-------|-------------------+ *
* | SIN-enabled *
* +-------o-------------------+ SIP *
* | SIP Layer | Entity *
* +---------------------------+ *
**********************************************
Figure 3: Functional architecture of an 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 (e.g.
that of an exchange).
3 Additional SIN considerations
When interworking 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. either during
call setup, teardown, or in the middle of a call. SIP entities
such as proxies, where some of these services may be realized,
typically run in transaction- stateful (or stateless) mode. In
such a mode, a SIP proxy that proxied the initial INVITE is not
draft-gurbani-sin-02.txt [Page 7]
Interworking SIP and Intelligent Network (IN) Applications June 2002
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 UAC and UAS to create a "route set" which consists of all
intervening proxies through which subsequent request 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 where IN services can be realized.
Since 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 architecture model proposed in this draft, 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 draft
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 draft is only applicable when SIP-controlled Internet
telephony devices are to inter-operate with PSTN devices. The SIP
UAs using this interface would typically appear together with a
media gateway. It is *not* applicable in an all-IP network and is
not needed 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 which provide VoIP based services
can directly leverage this information. However, this draft neither
endorses or 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
draft-gurbani-sin-02.txt [Page 8]
Interworking SIP and Intelligent Network (IN) Applications June 2002
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.
While the SIP specification [3] allows for end points to be put on
hold during a call, or a change of media streams to take place, it
does not have any primitives to transport other 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: The SIP functional entity that initiates a
request.
- User agent server: 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 User Agent Server (UAS) and a User Agent Client (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 them-selves 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: An 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.
draft-gurbani-sin-02.txt [Page 9]
Interworking SIP and Intelligent Network (IN) Applications June 2002
- Outbound proxy: An SIP proxy that is 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): An SIP entity that receives a request
and processes it as a UAS. It also acts as a UAC and
generates requests in order to determine how the incoming
request is to be answered. A B2BUA maintains complete dialog
state and must participate in all request sent within the
dialog.
4.2 IN Service control based on the SIN approach
Figure 4 depicts the possibility of IN service control based on the
SIN approach. On both, the originating and terminating ends, a SIN-
capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O
SIP" entity is required for outgoing calls that require support for
existing IN services. Likewise, on the callee's side (or terminating
side), an equally configured entity ("T SIP") will be required to
provide terminating side services. Note that the "O SIP" and "T SIP"
entities correspond, respectively, to the IN O_BCSM and T_BCSM halves
of the IN call model.
+---+ +---+
| S | (~~~~~~~~~~~~~) | S |
| C |<--+ ( ) +-->| C |
| P | | ( ) | | P |
+---+ | ( Switched ) | +---+
| ( Circuit ) |
V ( Network ) V
+-------+ ( ) +-------+
| SIN | +---------+ +---------+ | SIN |
+-------+----| Gateway | ... | Gateway |------+-------+
| O SIP | +---------+ +---------+ | T SIP |
+-------+ ( ) +-------+
( )
(.............)
O SIP: Originating SIP entity
T SIP: Terminating SIP entity
Figure 4: Overall SIN architecture.
draft-gurbani-sin-02.txt [Page 10]
Interworking SIP and Intelligent Network (IN) Applications June 2002
5 Mapping of the SIP state machine to the IN state model
This section establishes the mapping of the SIP protocol state
machine to the IN generic basic call state model (BCSM) [2],
independent of any capability sets [8, 9]. The BCSM is divided into
two halves - an originating call model (O_BCSM) and a terminating
call model (T_BCSM). There are a total of 19 PICs and 35 DPs between
both the halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for
T_BCSM) [1]. The SSPs, SCPs and other IN elements track a call's
progress in terms of the basic call model. The basic call model
provides a common context for communication about a call.
O_BCSM has 11 PICs. These are:
O_NULL: starting state; call does not exist yet.
AUTH_ORIG_ATTEMPT: switch detects a call setup request.
COLLECT_INFO: switch collects the dial string from the calling
party.
ANALYZE_INFO: complete dial string is translated into a routing
address.
SELECT_ROUTE: physical route is selected, based on the routing
address.
AUTH_CALL_SETUP: switch ensures the calling party is authorize to
place call.
CALL_SENT: control of call send to terminating side.
O_ALERTING: switch waits for the called party to answer.
O_ACTIVE: connection established; communication ensue.
O_DISCONNECT: connection torn down.
O_EXCEPTION: switch detected an exceptional condition.
T_BCSM has 8 PICS. These are:
T_NULL: starting state; call does not exist yet.
AUTH_TERM_ATT: switch verifies whether call can be send to
terminating party.
SELECT_FACILITY: switch picks a terminating resource to send the
call on.
PRESENT_CALL: call is being presented to the called party.
T_ALERTING: switch alerts the called party, e.g. ringing the line.
T_ACTIVE: connection established; communications ensue.
T_DISCONNECT: connection torn down.
T_EXCEPTION: switch detected an exceptional condition.
The state machine for O_BCSM and T_BCSM is provided in [1] page 98
and 103 respectively. This state machine will be used for subsequent
discussion when the IN call states are mapped into SIP.
The next two sections contain the mapping of the SIP protocol state
draft-gurbani-sin-02.txt [Page 11]
Interworking SIP and Intelligent Network (IN) Applications June 2002
machine to the IN BCSMs. It is beyond the scope of this draft to
explain all PICs and DPs in an IN call model. It is assumed that the
reader has some familiarity with the PICs and DPs of the IN call
model. More information can be found in [1]. For a quick reference,
Appendix A contains a mapping of the DPs to the SIP response codes as
discussed in the next two sections.
5.1 Mapping SIP protocol state machine to O_BCSM
The 11 PICs of O_BCSM come into play when a call request (SIP INVITE
message) arrives from an upstream SIP client to an originating SIN-
enabled SIP entity running the IN call model. This entity will
create a O_BCSM object and initialize it in the O_NULL PIC. The next
seven IN PICs -- O_NULL, AUTH_ORIG_ATT, COLLECT_INFO, ANALYZE_INFO,
SELECT_ROUTE, AUTH_CALL_SETUP, and CALL_SENT -- can all be mapped to
the SIP "Calling" state.
Figure 5 below provides a visual mapping from the SIP protocol state
machine to the originating half of the IN call model. Note that
control of the call shuttles between the SIP protocol machine and the
IN O_BCSM call model while it is being serviced.
draft-gurbani-sin-02.txt [Page 12]
Interworking SIP and Intelligent Network (IN) Applications June 2002
SIP O_BCSM
| INVITE
V
+---------+ +---------------+
| Calling +=======================>+ O_NULL +<----+
+--+---/\-+ +-/\---+--------+ |
| | || +-------------+ | | |
| | ||<===+O_Exception +---------+ +--V-+ +--+-+
| | || +--/\---------+ |DP 1| |DP21|
| | || | +----+ +-----+----+------+ +--+-+
| | || +<---+DP 2|<-----+ Auth_Orig._Att +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 3| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 4|<-----+ Collect_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 5| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 6|<-----+ Analyze_Info +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 7| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP 8|<-----+ Select_Route +---->+
| | || | +----+ +--------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP 9| |
| | || | +----+ +-----+----+------+ |
| | || +<---+DP10|<-----+ Auth._Call_Setup+---->+
| | || +----+ +--------+--------+
+----+ | || |
| | || +--V-+
| | || |DP11|
| 1xx | || +-----+----+------+
| | ++========================+ Call_Sent |
| | +----/\----+------+
| | On 100,180,2xx process DP14 || |
| | On 3xx, process DP12 || |
| V On 486, process DP13 || |
| +--+-------+ On 5xx, 6xx and 4xx || |
| |Proceeding| (except 486) process DP21|| |
draft-gurbani-sin-02.txt [Page 13]
Interworking SIP and Intelligent Network (IN) Applications June 2002
| +-+-+------+<=========================++ |
| | | |
| | | |
| | | |
| | +--200------------------+ |
| +----4xx to 6xx--------+ | |
| | | +--V-+
| On DPs 21, 2, 4, 6, 8, 10 | | |DP14|
| send 4xx-6xx final response | | +--------+----+--+
+-------+ | | | O_Alerting |
| | | +---------+------+
+--V-------+ | | |
|Completed |<------------+ | +--V-+
+--+-------+ | |DP16|
| | +------+----+----+
+--V-------+ | +-+ O_Active |
|Terminated|<---------------+ | +-------------+--+
+----------+ | |
+-----+ +--V-+
| |DP19|
+--V-+ +--------+----+
|DP17| | O_Disconnect|
+--+-+ +-------------+
|
V
To O_EXCEPTION
Legend:
| Communication between
| states in the same
V protocol
======> Communication between IN layer and SIP protocol
state machine to transfer call state
Figure 5: Mapping from SIP to O_BCSM
The SIP "Calling" protocol state has enough functionality to absorb
the seven PICs as described below:
O_NULL - This PIC is basically a fall through state to the next
PIC, AUTHORIZE_ORIGINATION_ATTEMPT.
AUTHORIZE_ORIGINATION_ATTEMPT - In this PIC, the IN layer has
detected that someone wishes to make a call. Under some
circumstances (e.g. the user is not allowed to make calls during
certain hours), such a call cannot be placed. SIP has the ability
draft-gurbani-sin-02.txt [Page 14]
Interworking SIP and Intelligent Network (IN) Applications June 2002
to authorize the calling party using a set of policy directives
configured by the SIP administrator. If the called party is
authorized to place the call, the IN layer is instructed to enter
the next PIC, COLLECT_INFO through DP 3
(Origination_Attempt_Authorized). If for some reason, the call
cannot be authorized, DP 2 (Origination_Denied) is processed and
control transfers to the SIP state machine. The SIP state machine
must format and send a non-2xx final response (possibly 403) to the
upstream entity.
COLLECT_INFO - This PIC is responsible for collecting a dial string
from the calling party and verifying the format of the string. If
overlap dialing is being used, this PIC can invoke DP 4
(Collect_Timeout) and transfer control to the SIP state machine,
which will format and send a non-2xx final response (possibly a
484). If the dial string is valid, DP 5 (Collected_Info) is
processed and the IN layer is instructed to enter the next PIC,
ANALYZE_INFO.
ANALYZE_INFO - This PIC is responsible for translating the dial
string to a routing number. Many IN service such as freephone, LNP
(Local Number Portability), OCS (Originating Call Screening), etc.
occur during this PIC. The IN layer can use the R-URI of the SIP
INVITE request for analysis. If the analysis succeeds, the IN layer
is instructed to enter the next PIC, SELECT_ROUTE. If the analysis
failed, DP 6 (Invalid_Info) is processed and the control transfers
to the SIP state machine, which will generate a non-2xx final
response (possibly one of 400, 401, 403, 404, 405, 406, 410, 414,
415, 416, 485, or 488) and send it to the upstream entity.
SELECT_ROUTE - In the circuit-switched network, the actual physical
route has to be selected at this point. The SIP analogue of this
would be to determine the next hop SIP server. The next hop SIP
server could be chosen by a variety of means. For instance, if the
Request URI in the incoming INVITE request is an E.164 number, the
SIP entity can use a protocol like TRIP [10] to find the best
gateway to egress the request onto the PSTN. If a successful route
is selected, the IN call model moves to PIC AUTH_CALL_SETUP via DP
9 (Route_Selected). Otherwise, the control transfers to the SIP
state machine via DP 8 (Route_Select_Failure), which will generate
a non-2xx final response (possibly 488) and send it to the upstream
entity.
AUTH_CALL_SETUP - Certain service features restrict the type of
call that may originate on a given line or trunk. This PIC is the
point at which relevant restrictions are examined. If no such
restrictions are encountered, the IN call model moves to PIC
CALL_SENT via DP 11 (Origination_Authorized). If a restriction is
draft-gurbani-sin-02.txt [Page 15]
Interworking SIP and Intelligent Network (IN) Applications June 2002
encountered that prohibits further processing of the call, DP 10
(Authorization_Failure) is processed and control is transferred to
the SIP state machine, which will generate a non-2xx final response
(possibly 404, 488, 502). Otherwise, DP 11
(Origination_Authorized) is processed and the IN layer is
instructed to enter the next PIC, CALL_SENT.
CALL_SENT - At this point, the request needs to be sent to the
downstream entity; and the IN layer waits for a signal confirming
that either the call has been presented to the called party or that
a called party cannot be reached for a particular reason. The
control is transferred to the SIP state machine. The SIP state
machine should now sent the call to the next downstream server
determined in PIC SELECT_ROUTE. The IN call model now blocks until
unblocked by the SIP state machine.
If the above seven PICs have been successfully negotiated, the
SIN-enabled SIP entity now sends the SIP INVITE message to the next
hop server. Further processing now depends on the provisional
responses (if any) and the final response received by the SIP
protocol state machine. The core SIP specification does not
guarantee the delivery of 1xx responses, thus special processing is
needed at the IN layer to transition to the next PIC (O_ALERTING)
from the CALL_SENT PIC. The special processing needed for
responses while the SIP state machine is in the "Proceeding" state
and the IN layer is in the "CALL_SENT" state is described next.
A 100 response received at the SIP state machine elicits no
special behavior in the IN layer.
A 180 response received at the SIP entity enables the processing
of DP 14 (O_Term_Seized), however, a state transition to
O_ALERTING is not undertaken yet. Instead, the IN layer is
instructed to remain in the CALL_SENT PIC until a final response
is received.
A 2xx response received at the SIP entity enables the processing
of DP 14 (O_Term_Seized), and the immediate transition to the
next state, O_ALERTING (processing in O_ALERTING is described
later).
A 3xx response received at the SIP entity enables the processing
of DP 12 (Route_Failure). The IN call model from this point
goes back to the SELECT_ROUTE PIC to select a new route for the
contacts in the 3xx final response (not shown in Figure 5 for
brevity).
A 486 (Busy Here) response received at the SIP entity enables
draft-gurbani-sin-02.txt [Page 16]
Interworking SIP and Intelligent Network (IN) Applications June 2002
the processing of DP 13 (O_Called_Party_Busy) and resources for
the call are released at the IN call model.
If the SIN-enabled SIP entity gets a 4xx (except 486), 5xx, or
6xx final response, DP 21 (O_Calling_Party_Disconnect &
O_Abandon) is processed and control passes to the SIP state
machine. Since a call was not successfully established, both
the IN layer and the SIP state machine can release resources for
the call.
O_ALERTING - This PIC will be entered as a result of receiving a
200-class response. Since a 200-class response to an INVITE
indicates acceptance, this PIC is mostly a fall through to the next
PIC, O_ACTIVE via DP 16 (O_Answer).
O_ACTIVE - At this point, the call is active. Once in this state,
the call may get disconnected only when one of the following three
events occur: (1) the network connection fails, (2) the called
party disconnects the call, or (3) the calling party disconnects
the call. If event (1) occurs, DP 17 (O_Connection_Failure) is
processed and call control is transferred to the SIP protocol state
machine. Since the network failed, there is not much sense in
attempting to send a BYE request; thus both the SIP protocol state
machine and the IN call layer should release all resources
associated with the call and initialize themselves to the null
state. The occurrence of event (2) results in the processing of DP
19 (O_DISCONNECT) and a move to the last PIC, O_DISCONNECT. Event
(3) would be caused by the calling party proactively terminating
the call. In this case, DP 21 (O_Abandon &
O_Calling_Party_Disconnect) will be processed and control passed to
the SIP protocol state machine. The SIP protocol state machine
must send a BYE request and wait for a final response. The IN
layer releases all its resources and initializes itself to the null
state.
O_DISCONNECT - When the SIP entity gets a BYE request, the IN layer
is instructed to move to the last PIC, O_DISCONNECT via DP19. A
final response for the BYE is generated and transmitted by the SIP
entity and the call resources are freed by both the SIP protocol
state machine as well as the IN layer.
5.2 Mapping SIP protocol state machine to T_BCSM
The T_BCSM object is created when a SIP INVITE message makes its way
to the terminating SIN-enabled SIP entity. This entity creates the
T_BCSM object and initializes it to the T_NULL PIC.
draft-gurbani-sin-02.txt [Page 17]
Interworking SIP and Intelligent Network (IN) Applications June 2002
Figure 6 below provides a visual mapping from the SIP protocol state
machine to the terminating half of the IN call model:
draft-gurbani-sin-02.txt [Page 18]
Interworking SIP and Intelligent Network (IN) Applications June 2002
SIP T_BCSM
| INVITE
V
+----------+ +------------+
|Proceeding+=========================>+ T_Null +<-------+
+-+--+--/\-+ +/\----+-----+ |
| | || +-----------+ | | |
| | ||<=======+T_Exception+--------+ +--V-+ +--+-+
| | || +-/\--------+ |DP22| |DP35|
| | || | +----+ +---+----+------+ +--+-+
| | || +<---+DP23|<------+Auth._Term._Att+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP24| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP25|<------+Select_Facility+---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP26| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP27|<------+ Present_Call +---->+
| | || | +----+ +------+--------+ |
| | || | | |
| | || | +--V-+ |
| | || | |DP28| |
| | || | +----+ +---+----+------+ |
| | || +<---+DP29|<------+ T_Alerting +---->+
| | || | +----+ +-/\--+---------+ |
| | || +<--------------+ || | |
| | || | || | |
| | ++==========================|===++ | |
| | /\ +-------+ +--V-+ |
| | || | +DP30| |
| | || +-+--+ +---+----+------+ |
| | || |DP31+<-----| T_Active +---->+
| | || +----+ +-/\-----+------+
| | || || |
| | || || |
2xx | | ++==============================++ |
sent | | |
+----+ | 3xx - 6xx response +--V-+
| | sent |DP33|
| +----V-----+ +------+----+----+
| |Completed | | T_Disconnect |
| +----+-----+ +----------------+
draft-gurbani-sin-02.txt [Page 19]
Interworking SIP and Intelligent Network (IN) Applications June 2002
| |
| | ACK received
| |
| +----V-----+
| |Confirmed |
| +----+-----+
| |
+------>|
|
+----V-----+
|Terminated|
+----------+
Legend:
| Communication between
| states in the same
V protocol
======> Communication between IN call model and SIP
protocol state machine to transfer call state
Figure 6: Mapping from SIP to T_BCSM
The SIP "Proceeding" state has enough functionality to absorb the
first five PICS -- T_Null, Authorize_Termination_Attempt,
Select_Facility, Present_Call, T_Alerting -- as described below:
T_NULL - At this PIC, the terminating end creates the call at the
IN layer. The incoming call results in the processing of DP 22,
Termination_Attempt, and a transition to the next PIC,
AUTHORIZE_TERMINATION_ATTEMPT, takes place.
AUTHORIZE_TERMINATION_ATTEMPT - In this PIC, the fact that the
called party wishes to receive the call is ascertained and that the
facilities of the called party are compatible with that of the
calling party. If any of these conditions is not met, DP 23
(Termination_Denied) is invoked and the call control is transferred
to the SIP protocol state machine. The SIP protocol state machine
can format and send a non-2xx final response (possibly 403, 405,
415, or 480). If the conditions of the PIC are met, processing of
DP 24 (Termination_Authorized) is invoked and a transition to the
next PIC, SELECT_FACILITY, takes place.
SELECT_FACILITY - The intent of this PIC in circuit switched
networks is to select a line or trunk to reach the called party.
Since lines or trunks are not applicable in an IP network, a SIN-
enabled SIP entity can use this PIC to interface with a PSTN
draft-gurbani-sin-02.txt [Page 20]
Interworking SIP and Intelligent Network (IN) Applications June 2002
gateway and select a line/trunk to route the call. If the called
party is busy, or a line/trunk can not be thus seized, the
processing of DP 25 (T_Called_Party_Busy) is invoked, followed by a
transition of the call to the SIP protocol state machine. The SIP
protocol state machine must format and send a non-2xx final
response (possibly 486 or 600). If a line/trunk was successfully
seized, the processing of DP 26 (Terminating_Resource_Available) is
invoked and a transition to the next PIC, PRESENT_CALL, takes
place.
PRESENT_CALL - At this point, the call is being presented (via the
ISUP ACM message, or Q.931 Alerting message, or simply by ringing a
POTS phone). If there was an error presenting the call, the
processing of DP 27 (Presentation_Failure) is invoked and the call
control is transferred to the SIP protocol state machine. The SIP
protocol state machine must format and send a non-2xx final
response (possibly 480). If the call was successfully presented,
the processing of DP 28 (T_Term_Seized) is invoked and a transition
to the next PIC, T_ALERTING, takes place.
T_ALERTING - At this point, the called party is being "alerted".
Control now passed momentarily to the SIP protocol state machine,
so it can generate and send a "180 Ringing" response to its peer.
Furthermore, since network resources have been allocated for the
call, timers are set to prevent indefinite holding of such
resources. The expiration of the relevant timers result in the
processing of DP 29 (T_No_Answer) and the call control is
transferred to the SIP protocol state machine. The SIP protocol
state machine must format and send a non-2xx final response
(possibly 408). If the called party answers, then DP 30 (T_Answer)
is processed, followed by a transition to the next PIC, T_ACTIVE.
The rest of the PICs after the above five have been negotiated are
mapped as follows:
T_ACTIVE - The call is now active. Once this state is reached, the
call may become inactive only under one of the following three
conditions: (1) the network fails the connection, (2) the called
party disconnects the call, or (3) the calling party disconnects the
call. Event (1) results in the processing of DP 31
(T_Connection_Failure) and call control is transferred to the SIP
protocol state machine. Since the network failed, there is not much
sense in attempting to send a BYE request; thus both the SIP protocol
state machine and the IN call layer should release all resources
associated with the call and initialize themselves to the null state.
Event (2) results in the processing of DP 33 (T_Disconnect) and a
transition to the next PIC, T_DISCONNECT. Event (3) would be caused
by the receipt of a BYE request at the SIP protocol state machine
draft-gurbani-sin-02.txt [Page 21]
Interworking SIP and Intelligent Network (IN) Applications June 2002
(not shown in Figure 6). Resources for the call should be
deallocated and the SIP protocol state machine must send a 200 OK for
the BYE request (not shown in Figure 6).
T_DISCONNECT - In this PIC, the disconnect treatment associated with
the called party's having disconnected the call is performed at the
IN layer. The SIP protocol state machine sends out a BYE and awaits
a final response for the BYE (not shown in Figure 6).
6 Example call flows
Two examples are provided here to understand how SIP protocol state
machine and the IN call model work synchronously with each other.
In the first example, a SIP UAC originates a call request destined to
a 800 freephone number:
INVITE sip:18005551212@lucent.com SIP/2.0
From: sip:16309795218@il0015vkg1.ih.lucent.com;tag=991-7as-66ff
To: sip:18005551212@lucent.com
Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
Call-ID: 67188121@lucent.com
CSeq: 1 INVITE
The request makes its way to the originating SIP network server
running an IN call model. The SIP network server hands, at the very
least, the To: field and the From: field to the IN layer for
freephone number translation. The IN layer proceeds through its PICs
and in the ANALYSE_INFO PIC consults the SCP for freephone
translation. The translated number is returned to the SIP network
server, which forwards the message to the next hop SIP proxy, with
the freephone number replaced by the translated number:
INVITE sip:16302240216@lucent.com SIP/2.0
From: sip:16309795218@il0015vkg1.ih.lucent.com;tag=991-7as-66ff
Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
Via: SIP/2.0/UDP sip-in1.ih.lucent.com
To: sip:18005551212@lucent.com
Call-ID: 67188121@lucent.com
CSeq: 1 INVITE
In the next example, a SIP UAC originates a call request destined to
a 900 number:
INVITE sip:19005551212@lucent.com SIP/2.0
From: sip:16302240216@lucent.com;tag=991-7as-66dd
To: sip:19005551212@lucent.com
Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
draft-gurbani-sin-02.txt [Page 22]
Interworking SIP and Intelligent Network (IN) Applications June 2002
Call-ID: 88112@lucent.com
CSeq: 1 INVITE
The request makes its way to the originating SIP network server
running an IN call model. The SIP network server hands, at the very
least, the To: field and the From: field to the IN layer for 900
number translation. The IN layer proceeds through its PICs and in
the ANALYSE_INFO PIC consults the SCP for the translation. During
the translation, the SCP detects that the originating party is not
allowed to make 900 calls. It passes this information to the
originating SIP network server, which informs the SIP UAC using SIP
"403 Forbidden" response status code:
SIP/2.0 403 Forbidden
From: sip:16302240216@lucent.com;tag=991-7as-66dd
To: sip:19005551212@lucent.com;tag=78K-909II
Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
Call-ID: 88112@lucent.com
CSeq: 1 INVITE
7 Security considerations
Security considerations for SIN services span both the networks being
used, namely, the PSTN and the Internet. SIN uses the security
measures in place for both the networks. With reference to Figure 2,
the INAP messages between the SCP and the SIN-enabled SIP entity must
be secured by the signaling transport used between the SCP and the
SIN-enabled entity. Likewise, the requests coming into the SIN-
enabled SIP entity must first be authenticated, and if the need be,
encrypted as well using the means and procedures defined in [3] for
SIP requests.
Appendix A: Mapping of 4xx-6xx responses in SIP to IN Detections Points
The mapping of error codes 4xx- 6xx responses in SIP to the possible
Detection Points in PIC Originating and Terminating Call Handling is
indicated in the table below. The reason phrase in the 4xx-6xx
response is reproduced from [3].
draft-gurbani-sin-02.txt [Page 23]
Interworking SIP and Intelligent Network (IN) Applications June 2002
SIP response code DP mapping to IN
----------------- ----------------------
200 OK DP 14
3xx DP 12
403 Forbidden DP 2, DP 21
484 Address Incomplete DP 4, DP 21
400 Bad Request DP 6, DP 21
401 Unauthorized DP 6, DP 21
403 Forbidden DP 6, DP 21, DP 23
404 Not Found DP 6, DP 21
405 Method Not Allowed DP 6, DP 21, DP 23
406 Not Acceptable DP 6, DP 21
408 Request Timeout DP 29
410 Gone DP 6, DP 21
414 Request-URI Too Long DP 6, DP 21
415 Unsupported Media Type DP 6, DP 21, DP 23
416 Unsupported URI Scheme DP 6, DP 21
480 Temporarily Unavailable DP 23, DP 27
485 Ambiguous DP 6, DP 21
486 Busy Here DP 13, DP 21, DP 25
488 Not Acceptable Here DP 6, DP 21
488 Not Acceptable Here DP 8,
404 Not Found DP 10, DP 21
488 Not Acceptable Here DP 10, DP 21
502 Bad Gateway DP 10, DP 21
600 Busy Everywhere DP 21, DP 25
Normative References
1 I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The
Intelligent Network Standards: Their Application to
Services," McGraw-Hill, 1997.
2 ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network
Distributed Functional Plane Architecture," International
Telecommunications Union Standardization Section, Geneva.
3 Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo,
Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley,
and Eve Schooler, "SIP: Session Initiation Protocol",
IETF I-D, Work in Progress, expires August 2002.
<http://www.ietf.org/internet-drafts/draft-ietf-sip-
rfc2543bis-09.txt>
Informative References
4 ITU-T Q.1208: "General aspects of the Intelligent Network
Application protocol"
draft-gurbani-sin-02.txt [Page 24]
Interworking SIP and Intelligent Network (IN) Applications June 2002
5 S. Donovan, "The SIP INFO Method" IETF RFC 2976, October
2000. <http://www.ietf.org/rfc/rfc2976.txt>
6 Adam Roach, "SIP-Specific Event Notification", IETF I-D, Work
in Progress, expires August 2002. <http://www.ietf.org/
internet-drafts/draft-ietf-sip-events-05.txt>
7 H. Schulzrinne, S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", IETF RFC 2833, May
2000. <http://www.ietf.org/rfc/rfc2833.txt?number=2833>
8 ITU-T Q.1218: "Interface Recommendation for Intelligent
Network Capability Set 1"
9 ITU-T Q.1228: "Interface Recommendation for Intelligent
Network Capability Set 2"
10 Jonathan Rosenberg, Hussein Salama, and Matt Squire,
"Telephony Routing over IP (TRIP)", IETF RFC 3219, January,
2002. <http://www.ietf.org/rfc/rfc3219.txt>
Acknowledgments
Special acknowledgement to Hui-Lan Lu for acting as the chair of the
SIN DT and ensuring the focus of the DT did not veer too far. The
authors would also like to thank specially Mr Ray C. Forbes from
Marconi Communications Limited for his valuable contribution on the
system and network architectural aspects as Co-chair in the ETSI
SPAN. Thanks also to Doris Lebovits, Kamlesh Tewani, Janusz
Dobrowloski, Jack Kozik, Warren Montgomery, Lev Slutsman, Henning
Schulzrinne and Jonathan Rosenberg who all contributed to the
discussions on the relationship of IN and SIP call models.
Changes from previous drafts
Changes in draft-gurbani-sin-02.txt
. Incorporated comments from RFC Editor.
. As per the comments from RFC Ed., changed name of draft.
Changes to draft-gurbani-sin-01.txt
. Added list of acronyms.
. Took out table on "Cause value mappings" -- lot of this mapping is
specified in SIP/ISUP the mapping draft.
. Added Applicability Statement.
Changes since draft-ietf-sin-manyfolks-01.txt
. Renamed to <draft-gurbani-sin-00.txt>; reverted back to -00.
. Incorporates DT Last Call comments.
. Massive modifications of Figure 5 and 6 -- reflects more of an
en event driven view.
. Updated references.
. Added TOC.
draft-gurbani-sin-02.txt [Page 25]
Interworking SIP and Intelligent Network (IN) Applications June 2002
Changes since -01
. Renamed to <draft-ietf-sin-manyfolks-00.txt>; reverted back to -00.
. Major re-write of the original F. Haerens I-D.
Changes since -00
. Included SIP/IN Call Model mapping as described in a now expired I-D
("Accessing IN Services from SIP networks
<draft-gurbani-iptel-sip-to-in-04.txt>).
. Included comments from ETSI obtained by Frans Haerens.
. Not all changes discussed on the SIN DT email list have been
included - stay tuned for -02 coming up after 51st IETF.
Author's addresses
Vijay K. Gurbani
Lucent Technologies, Inc.
2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566
USA
Phone: +1 630 224 0216
Email: vkg@lucent.com
Frans Haerens
Alcatel Bell
Francis Welles Plein,1
Belgium
Phone: +32 3 240 9034
Email: frans.haerens@alcatel.be
Vidhi Rastogi
Wipro Technologies
271, Sri Ganesha Complex
Hosur Main Road, Madiwala
Bangalore - 560 068, INDIA
Phone: +91 80 5539701
Email: vidhi.rastogi@wipro.com
Full Copyright Statement:
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
draft-gurbani-sin-02.txt [Page 26]
Interworking SIP and Intelligent Network (IN) Applications June 2002
as required to translate it into
draft-gurbani-sin-02.txt [Page 27]