Network Working Group H. Schulzrinne
Internet Draft Columbia University
L. Slutsman
AT&T
draft-schulzrinne-sin-01.txt I. Faynberg
Expires January 2001 H. Lu
Lucent Technologies
Interworking between SIP and INAP
Status of this Memo
This document is an Internet-Draft and is in full conformance wit all
provisions of Section 10 of RFC2026.
This document outlines a proposal to the IETF for a new work item in
support of service delivery in converging networks.
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.
Abstract
The goal of this document is to identify a new IETF work item. The
document defines the term "soft switch" as a mechanism by which PSTN
Intelligent Network (IN) service control can be accessed by VoIP
gateways and associated SIP servers. Specifically, the work
item is on the mechanism for interworking of the Session Initiation
Protocol (SIP) and Intelligent Network Application Part Protocol
(INAP).
1. Introduction
This document first defines the term "soft switch" for the purposes
of describing a mechanism by which existing PSTN Intelligent Network
(IN) service control can be re-used in IP networks. IP telephony is
one application that can benefit from this mechanism, but there are
other potential applications of interest (for example, Unified
Messaging), which this draft does not address. Specifically, the
document demonstrates the role of the soft switch in IP telephony. The
Interworking between SIP and INAP" July 2000
<draft-schulzrinne-sin-01.txt> [Page 2]
document then narrows, for practical purposes, the
scope of the soft switch so as to identify an architecture and
mechanism for interworking of Session Initiation Protocol (SIP) and
Intelligent Network Application Part Protocol (INAP). Some (but not
all) parts of this work have already been
discussed in the IETF. To help delineating the proposed work item,
this Internet draft explains how it relates to the efforts of the
existing IETF working groups that deal with the protocols for
PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and
SIGTRAN) and ITU-T.
The remaining sections of this document present, in this order, the
problem statement, proposed area of standardization and service
examples, relation of the proposal to the existing work in the IETF
and other standards bodies, security considerations, acknowledgments,
conclusion, references, and an appendix with figures.
2. Problem Statement
We address the porting of services that exist today in the PSTN
to IP telephony gateways, provided by the Intelligent Network
(IN). Such services include "freephone" (known as "800 number" in
the US), Local Number Portability (LNP), and Virtual Private Network
(VPN).
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. The points
where a call can be interrupted are standardized within the Basic
Call State Model (BCSM) [1]. 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). Only
the protocol, but not an SCP API, have been standardized.
A soft switch is a process that behaves like a PSTN switch to any
PSTN entity, such as SCP or SSP, and speaks IP signaling protocols.
A soft switch can "talk" SS7 to SCPs and PSTN switches (thus acting
as an SSP), and at the same time be a Media Gateway Controller to a
Media Gateway, "speak" H.323 to a Gatekeeper and act as a SIP UA.
Here, as depicted in Figure 2, we are only concerned about
the interaction of SIP and INAP, not the remaining aspects of a
soft switch. In addition to the soft switch scenario, we can also have
Interworking between SIP and INAP" July 2000
<draft-schulzrinne-sin-01.txt> [Page 3]
a SIP call-stateful proxy server, presumably associated with a
soft switch, interact with an SCP. In that configuration, the SCP
effectively acts as a SIP location server (as shown in Figure 3).
We do not intend to consider the issue of how the soft switch "finds"
the right SCP or how it authenticates itself to the SCP. The
transport of INAP messages is outside the scope of this work as well.
SIN can be thought as something similar to the SIP Common Gateway
Interface (CGI) [3, 4], specialized for INAP interworking. Unlike
sip-cgi, which is transaction-oriented (although cross-transaction
state can be maintained with some effort), a SIN mechanism should be
call-oriented so as to correspond more closely to the BCSM. Initial
work on mapping between the SIP and IN call models has been done in
the IPTEL group [5, 6, 7]; it may be appropriate to continue this work
in an IN-focused venue such as SIN.
3. Interface between SIP servers and INAP/SCP (SIN)
When interworking between VoIP and IN-PSTN networks the main issue is
to translate between the states produced by VoIP signaling and those
used in traditional IN environment.
3.1 The concept of state in SIP
In a SIP call, only UAs have to maintain SIP call state. All other
servers can be either stateless or, in the case of proxy servers,
only maintain transaction state. (Transaction state is maintained
for a single SIP request only.) Proxy servers can choose to be
call-stateful if necessary. In that case, they generally ensure
their presence in all SIP signaling exchanges by adding their name to
the SIP Record-Route list. However, the soft switch acts as a SIP UA,
so this is of no concern.
3.2 SIN issues
When interworking between VoIP networks and IN, it is useful to have
a common understanding of how to translate from the states produced
by VoIP signaling to those produced by IN signaling.
In this model, each SIP server is pre-configured to communicate with
one logical SCP server, using whatever communication mechanism is
appropriate. (In particular, the mechanism may not use an IP
network.) 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.
This proposal is applicable only when SIP-controlled Internet
telephony devices are to interoperate with PSTN devices. The SIP UAs
using this interface would typically appear together with a media
gateway. It is *not* applicable within an all-IP network and is not
needed where PSTN media gateways (not speaking SIP) need to
communicate with SCPs.
Interworking between SIP and INAP" July 2000
<draft-schulzrinne-sin-01.txt> [Page 4]
This proposal is not a wire protocol, but rather an abstract
interface mechanism that simplifies the construction of SIP servers
that want to access IN services. (On initial inspection, it does not
seem appropriate to repackage SIP requests and responses.)
Since SIP proxy and redirect servers do not have access to the media
data path, special mechanisms need to be deployed to enable IN
services such as digit collection or announcement services.
Announcement services can use the mechanism in [8] to
deliver messages or can proxy the call to a SIP UAS that also
terminates the data stream. That UAS may then transfer the call [9]
to the final destination.
4. Related IETF efforts
The IETF IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN WGs deal with
related interworking issues. Thus, it may turn out that this work can
be accommodated within an existing working group.
IPTEL: The scope of this WG are perhaps closest to the present
proposal. In fact, the original proposes for call model mapping
have all been presented to IPTEL. Yet IPTEL deals with two
specific items, namely Call Processing Language and TRIP, which are
unrelated to the problem discussed here.
MEGACO: This WG develops the Media Gateway Control Protocol, which
operates between the MG and the MGC and does not directly intersect
with INAP and service issues.
PINT and SPIRITS: These WGs address the other side (relative to the
soft switch) of Figure 2, namely interworking of service control
with Internet-provided services. As such, neither group has
anything to do with the soft switch or VoIP-PSTN gateways and,
consequently, the proposal.
SIGTRAN: This WG specifies a transport protocol for carrying SS7
messages, which is orthogonal to service interworking.
5. Security Considerations
Since the soft switch has access to services in the PSTN network, it
needs to be secured to prevent unauthorized use. However, since no
protocol is being specified, this is primarily an operating system
access control issue.
6. Conclusion
This document has identified a new work item for the IETF to define a
mechanism that simplifies the interworking of SIP-enabled
soft switches with SCPs speaking INAP.
Interworking between SIP and INAP" July 2000
<draft-schulzrinne-sin-01.txt> [Page 5]
7. References
[1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The
Intelligent Network Standards: Their Application to Services,"
McGraw-Hill, 1997.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"SIP:Session Initiation Protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, March 1999.
[3] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming
Internet Telephony Services," Technical Report CUCS-010-99,
Columbia University, New York, New York, March 1999.
[4] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common Gateway
Interface for SIP", Internet Draft, <draft-lennox-sip-cgi-04.txt>,
June, 2000, work in progress.
[5] L. Slutsman, G. Ash, F. Haerens, and V. Gurbani, "Framework and
Requirements for the Internet Intelligent Networks (IIN)", Internet
Draft <draft-lslutsman-sip-iin-framework-00.txt>, April 2000. Task
Force, December 1999, work in progress.
[6] V. Gurbani, "Accessing IN Services from SIP Networks," Internet
Draft <draft-gurbani-iptel-sip-to-in-01.txt>, Internet Engineering
Task Force, December 1999, work in progress.
[7] F. Haerens, "Intelligent Network Application Support of the
SIP/SDP Architecture", Internet Draft
<draft-haerens-sip-inap-00.txt>, November 1999, work in progress.
[8] S. Donovan, H. Schulzrinne, J. Rosenberg, M. Cannon, and A. Roach,
"SIP 183 Session Progress Message", Internet Draft,
<draft-ietf-sip-183-00.txt>, October, 1999, work in progress.
[9] R. Sparks, " SIP Call Control Transfer", Internet Draft,
<draft-lennox-sip-cgi-04.txt>, July, 2000, work in progress.
8. Acknowledgments
Janusz Dobrowloski, Vijay Gurbani, Frans Haerens, Jack Kozik, Warren
Montgomery, and Jonathan Rosenberg contributed to the discussions on the
relationship of IN and SIP call models. (Janusz was the first to
bring the discussion to the IETF.)
9. Authors' Addresses
Henning Schulzrinne
Department of Computer Science
Columbia University
Phone: (212) 939-7042
Email: hgs@cs.columbia.edu
Interworking between SIP and INAP" July 2000
<draft-schulzrinne-sin-01.txt> [Page 6]
Lev Slutsman
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
Phone: (732) 420-3752
Email: lslutsman@att.com
Igor Faynberg
Bell Labs/Lucent Technologies
Room 4C-611A
101 Crawfords Corner Road
Holmdel, NJ 08816
Phone: (732) 949-0137
Email: faynberg@bell-labs.com
Hui-Lan Lu
Bell Labs/Lucent Technologies
Room 4C-607A
101 Crawfords Corner Road
Holmdel, NJ 08816
Phone: (732) 949 949-0321
Email: hui-lan.lu@lucent.com
10. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Interworking between SIP and INAP" July 2000
<draft-schulzrinne-sin-01.txt> [Page 7]
11. Appendix
+-----------+
| |
| SCP |
| |
+-----------+
|
|
/ \
/ / INAP / \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
Figure 1. Simplified IN Architecture
+-------------+
| SCP |
+-------------+
|
| INAP
|
+-------------+
| (SIN) |
| Soft Switch |
| (SIP) |
+-------------+
Figure 2. Simplified soft switch architecture
+-------------+
| SCP |
+-------------+
|
| INAP
|
+------------+ +-----------+
| | | [SIN] |
| | |...........|
| | SIP | SIP |
| softswitch |------| proxy |
| | | server |
+------------+ +-----------+
Figure 3. SIP proxy using INAP as a location server
Interworking between SIP and INAP" July 2000