Internet DRAFT - draft-haerens-sip-inap
draft-haerens-sip-inap
SIP Working Group F. Haerens
Internet Draft Alcatel Bell
<draft-haerens-sip-inap-00.txt> October 1999
Expires: April 2000
Intelligent Network Application Part (INAP) Support of the SIP/SDP
Architecture
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
This document considers the Intelligent Network Application Part
(INAP) Support for the SIP/SDP architecture.
The overall objective of this document is to demonstrate that INAP
control of IP services (e.g. VoIP) 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 aim to use Intelligent Networks to support various network
architectures is that:
* The IN infrastructure shall be independent of the IP telephony
signalling protocol (SIP, H323,…).
* The call control and consequently IN control shall be at least at
the edge of the network i.e. nearest to the user in a Local Exchange
and between two operators in an Inter-operator Gateway.
Haerens page [1]
Internet-Draft INAP support for SIP October, 1999
2. Session Establishment
Sessions may be established using direct point-to-point
communication or by using a SIP Server for personal mobility. A SIP
server may be a Redirect Server or a Proxy Server. To establish a
session using a SIP server the originator sends an INVITE message to
the server. The server communicates with a Location Server to
retrieve the contact address of the terminating party. When a
Redirect Server is employed (Figure 1) the address is passed to the
originator. The originator sends a new INVITE message and a session
is established with the terminating party. When a Proxy Server is
employed (Figure 2) the address of the terminating party is not
passed to the originator. A signalling session is established
between the originating and terminating party via the Proxy Server.
One or more intermediate Proxy Servers may take part in the session.
It is envisaged that a Proxy Server may be a network entity where
INAP service control could be applied. This possibility is
investigated further in this draft.
+-----------+
+--------[2]---->| Location |
| +---[3]-----o Server |
| | +-------o---+
| V ^ |
+--o--------+ | |
+-------[1]----->| Redirect | Registration via
| +--[4]------o Server | SIP Registrar
| | +--------o--+ | |
| V | V
+--o--------+ +--o--------+
|Originating|<------------[5]----------->|Terminating|
|Party | Session established | Party |
+-----------+ +-----------+
[1] Terminating Party Address: dsmith@anynet.com
[2] Terminating Party Address: dmsith
[3] Terminating Party Address: dsmith@temp.com
[4] Terminating Party Address: dsmith@temp.com
[5] Terminating Party Address: dsmith@temp.com
Figure 1: Session Establishment using a Redirect Server
Haerens page [2]
Internet-Draft INAP support for SIP October, 1999
+-----------+
+--------[2]---->| Location |
| +---[3]-----o Server |
| | +-------o---+
| V ^ |
+--o--------+ | |
+-------[1]----->| Proxy | Registration via
| +--[5]------o Server | SIP Registrar
| | +--------o--+ | |
| V ^ | | V
+--o--------+ | | +--o--------+
|Originating| | +---[4]---->|Terminating|
|Party | +---------[5]-----o Party |
+-----------+ +-----------+
[1] Terminating Party Address: dsmith@anynet.com
[2] Terminating Party Address: dmsith
[3] Terminating Party Address: dsmith@temp.com
[4] Terminating Party Address: dsmith@temp.com
[5] Terminating Party Address: dsmith@anynet.com
Figure 2: Session Establishment using a Proxy Server
3. Architecture
3.1 Introduction
This section of the document provides information flows that
illustrate the possible interaction of INAP and SIP. In particular
it provides a proposal for the triggering of INAP services as well
as a mapping between the INAP call states and the call states of the
Session Initiation Protocol (SIP).
An overall objective is to demonstrate that INAP control of 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. This section investigates the possibility of INAP
service control based on the SIP Proxy Server approach. This means
that a locally configured Proxy Server is required for outgoing
calls that require legacy service support based on existing INAP
services.
The section is organised as follows: Section 3.2 outlines the
proposed functional architecture for the support of INAP/SIP
interaction. Section 3.3 briefly describes the concepts for IN
service triggering based on INAP Subscription Information. Section
4.1 describes a registration process, section 4.2 deals with the
detail of triggering services for originating calls, section 4.3
deals with the details for triggering terminating calls.
Haerens page [3]
Internet-Draft INAP support for SIP October, 1999
3.2 Functional Architecture
The proposed functional architecture is provided here for
completeness. The concept of the ‘softSSF’ is introduced which acts
as an overlay between the IP telephony call control and the
Intelligent Network layer provided by the INAP Service Switching
Function (SSF) and the Service Control Function (SCF). This
‘softSSF’ provides the necessary mapping between the SIP protocol
state machine and the INAP Basic Call State Model (BCSM). Figure 3
outlines the proposed functional architecture at the network level.
+-------+ +-------+
| SCF | | SDF |
+---o---+ +---o---+
| |
+-----+-----------+
|
**********|***********************************
* +-------|-------------------+ *
* |+------o------+ | *
* || SSF | | *
* |+-------------+ | *
* || CCF Mapping | | *
* |+------o------+ Soft SSF | *
* +-------|-------------------+ *
* | Extended *
* +-------o-------------------+ SIP Proxy *
* |SIP Proxy Server | Server *
* +---o---------o---------o---+ *
******|*********|*********|*******************
| | |
(^^^^) +---+ +----o----+ +---+ (^^^^)
( ) | | SIP | | ( )
( +-----o-+ |UserAgent| (^^^^ )
( |Gateway| +---------+ ( Packet )
( +-------+ ( Network )
( ) ( +--------+
( SCN ) ( |Terminal|
(......) (....+--------+
Figure 3: Proposed functional Architecture to support INAP control
of VoIP based on SIP call control
3.3 Basic Concept of the Proposal
Subscribers may register in the SIP network allowing the subscriber
to receive incoming calls. A subscriber may use an additional
identifier (e.g. MSISDN) in the registration process. Upon
registration with the server, the subscription information for the
subscriber is sent to the softSSF by the SDF in the subscriber’s
Haerens page [4]
Internet-Draft INAP support for SIP October, 1999
home network. As incoming calls made to the subscriber terminate at
the server the subscriber is registered with, the terminating
subscription information may be examined and if necessary the SCF
may be invoked on a per incoming call basis. Similarly, calls made
by a subscriber already registered with a Proxy Server allow the
originating subscription information to be examined and potentially
allow the SCF to be invoked. Callers not registered will not have
any subscription information in the Proxy Server they are using to
place the call. The proposal here is as follows: when the initial
call request message (or the INVITE method) is received by the SIP
Proxy Server, the soft SSF establishes a dialogue with the SDF of
the home subscribers network to allow the subscription information
to sent. The originating subscription data may then be examined and
if necessary the SCF may be invoked.
3.4 Assumptions
a. All the call flows show that the SIP Proxy Server and the softSSF
have been co-located in order to avoid showing information flows
between the two entities. Standardisation of the messages for this
interface is for further study.
b. Originating and terminating SIP Proxy Servers must operate in a
stateful mode.
c. As registration with a SIP Proxy Server is not mandatory, it
shall be possible to determine whether a registration exists for
that particular subscriber when an incoming call is placed by a
subscriber. This allows the subscriber data information to be
fetched from the home SDF if the subscriber is not registered.
(Note: Absence of the originating subscriber data does not
necessarily mean that the user is not registered, merely that the
originating subscriber data may not exist for that subscriber).
d. The information flows make no consideration for interworking with
other networks (e.g. PSTN via gateways)
4. Message Flows
4.1 Proposed Registration Process
This section outlines a possible registration process based on the
SIP REGISTER method, which allows subscription information to be
stored in the SIP Proxy Server/softSSF. IETF RFC 2543 defines the
term Registrar for registration purposes and it is the SIP registrar
that accepts the REGISTER method. In this section it is assumed that
the SIP Proxy Server and the SIP registrar are co-located. With the
SIP REGISTER method, it is assumed that registration with a location
server takes place.
Haerens page [5]
Internet-Draft INAP support for SIP October, 1999
Unlike H.323, registration with a server is not mandatory. Only
users that wish to receive incoming calls need to register with a
SIP Registrar. Callers placing calls are not required to register.
The information flows for the registration procedure are shown in
Figure 4 and elaborated in the following text:
{1} The Endpoint sends a REGISTER method to the SIP Proxy Server.
{2} The SIP Proxy Server notifies the softSSF of the registration
attempt. The softSSF in turn notifies the SCF/SDF. The SDF responds
with an “InsertSubscriberData” message which contains the
Originating and terminating subscription Information.
{3} The SIP Proxy Server acknowledges that the registration process
has been completed by a 200 OK response message.
<--------------Local-Network---------------><--INAP-Network-->
+--------+ +--------+ +--------+ +--------+
|Endpoint| |Extended| | SCF | | SDF |
| UAC(*) | |Proxy | | | | |
+--------+ +--------+ +--------+ +--------+
| | | |
| REGISTER | InitialRegDP | |
1 o--------------->o--------------->| |
| | | |
| RequestReportUTSI| |
| |<---------------o |
| | | |
| | ReportUTSI | UpdateLocation |
| o--------------->o--------------->| --+
| | | | |
| | SendSTUI | InsertSubData | |
| |<---------------o<---------------o |
| | | | |
| | ReportUTSI |InsertSubDataAck| +- 2
| o--------------->o--------------->| |
| | | | |
| | | UpdateLocation | |
| 200 OK | SendSTUI | Ack | |
3 |<---------------o<---------------o<---------------o --+
| | | |
(*) UAC = User Agent Client
Figure 4: Proposed registration procedure
Haerens page [6]
Internet-Draft INAP support for SIP October, 1999
4.2 Originating Call with INAP Interaction
This section deals with the originating calls that require
interaction with INAP.
The call flows are shown in Figure 5 and are further explained
below:
{1} The User Agent Client in the endpoint initiates a SIP request
by issuing an INVITE method to the SIP Proxy Server.
{2} The SDF functionality in the softSSF is checked to determine if
the calling party has previously registered. If no registration is
found, then step {3} follows. If the softSSF determines that the
calling user has a valid registration then step {4} is followed.
{3} The softSSF establishes a dialogue with the SDF of the
subscriber’s network. An UpdateLocation message is sent to the SDF.
The SDF responds by sending an InsertSubscribersData message, which
may contain the Originating, Terminating and Supplementary
Subscription Information.
{4} The originating subscriber data is analyzed and if the
necessary triggering criteria are met, the SCF is invoked via an
InitialDP message.
{5} The SIP Proxy Server will route the call based on the
instructions received by the service logic in the SCF. The remainder
of the information flows will vary according to the service logic
and are not shown.
Haerens page [7]
Internet-Draft INAP support for SIP October, 1999
+--------+ +--------+ +--------+ +--------+
|Endpoint| |Extended| | SCF | | SDF |
| UAC | |Proxy | | | | |
+--------+ +--------+ +--------+ +--------+
| | | |
| INVITE [2] InitialRegDP | |
1 o--------------->o--------------->| |
| | | |
| RequestReportUTSI| |
| |<---------------o |
| | | |
| | ReportUTSI | UpdateLocation |
| o--------------->o--------------->| --+
| | | | |
| | SendSTUI | InsertSubData | |
| |<---------------o<---------------o |
| | | | |
| | ReportUTSI |InsertSubDataAck| +- 3
| o--------------->o--------------->| |
| | | | |
| | | UpdateLocation | |
| | SendSTUI | Ack | |
| |<---------------o<---------------o --+
| |[4] | |
| | | |
| | Initial DP | |
| o--------------->| |
| | | ********* |
| | | * * |
| | INAP | * Ser * |
| | <===========* vice * |
| | | * Logic * |
| | | * * |
| | | ********* |
| | | |
| | | To next hop |
| | INVITE | (SIP Server,|
| o--------------------> Terminal, |
| | 5 | Gateway) |
Figure 5: Originating Call with INAP Interaction
4.3 Terminating Call with INAP Interaction
This section deals with the INAP interaction for terminating calls.
An INAP service is triggered if the triggering criteria held in the
called subscriber’s data matches the characteristics of the incoming
call. The information flows are shown in Figure 6 and further
explained below:
Haerens page [8]
Internet-Draft INAP support for SIP October, 1999
{1} The terminating SIP Proxy Server receives an INVITE method.
{2} The terminating subscriber data is analysed and the triggering
criteria are checked against the particulars of the incoming call. A
terminal must register with a server to be able to receive incoming
calls via this Proxy Server. Since it has been assumed that this
registration has taken place, the terminating subscriber data is
available at the server.
{3} If the necessary triggering criteria are met, the SCF is
invoked and an INAP dialogue established between the softSSF and the
SCF.
{4} Instructions are received from the SCF on how the call is to be
routed.
{5} The SIP Proxy Server will route the call based on the
instructions received by the service logic in the SCF. As the rest
of the information flows will vary according to the service logic,
the remainder of the information flows are not shown.
+--------+ +--------+ +--------+ +--------+
| SDF | | SCF | |Extended| |Endpoint|
| | | | |Proxy | | UAC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
| INVITE | | |
------------------------------------->|[1] |
| From SIP Server / User Agent| |
| | | |
| | [2] |
| | | |
| | InitialDP | |
| |<---------------o[3] |
| | | |
| ********* | | |
| * * | | |
| * Ser * |INAP instructions |
| * vice *===================>|[4] |
| * Logic * | | |
| * * | | |
| ********* | | INVITE |
| | [5]o--------------->|
| | | |
Figure 6: Terminating Call with INAP Interaction
Haerens page [9]
Internet-Draft INAP support for SIP October, 1999
5. Security Considerations
As this is an initial proposal, security considerations are for
further study.
6. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
7. Author's Addresses
Haerens Frans
Alcatel Bell
F. Wellesplein 1
B-2000 Antwerpen
Belgium
Email: frans.haerens@alcatel.be
Haerens page [10]
Internet-Draft INAP support for SIP October, 1999
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 implmentation 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
Haerens page [11]
