One document matched: draft-schulzrinne-sin-00.txt
H. Schulzrinne
Columbia University
L. Slutsman
AT&T Labs
Individual Contribution I. Faynberg
July 2000 H. Lu
Lucent Technologies
Interworking between SIP and INAP
<draft-schulzrinne-sin-00.txt>
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.
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. The document mechanism for
interworking of the Session Initiation Protocol (SIP) and Intelligent
Network Application Part Protocol (INAP).
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 2]
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 explicitly demonstrates the role of the soft switch in IP
telephony. The document then narrows, for p 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). The so defined
mechanism can be implemented as an application layer protocol, when
architectural entities reside in different machines, or inter-process
communications protocol, if they reside in the same machine. It is
the proposal of this document to define at least a meta-protocol
(from which particular implementations can be derived) a work item
in the IETF. 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
network 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), Virtual Private Network
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 3]
(VPN) and other services.
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.
As depicted in Figure 2, 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, we are only concerned about
the interaction of SIP and INAP, not the remaining aspects of a
softswitch. In addition to the softswitch scenario, we can also have
a SIP call-stateful proxy server, presumably associated with a
softswitch, interact with an SCP. In that configuration, the SCP
effectively acts as a SIP location server (Figure 3).
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 4]
We do not intend to consider the issue of how the softswitch "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), 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, as that corresponds more closely to the BCSM. Initial
work on mapping between the SIP and IN call models has been done in
the IPTEL group [3,4,5]; 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 softswitch acts as a SIP UA,
so this is of no concern.
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 5]
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 familiar with IN service creation.
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., in different administrative
domains, may communicate with different SCP servers, so that there is
no single SCP server responsible for all SIP servers.
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 6]
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.
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 draft-ietf-sip-183 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
(draft-sparks-sip-cc-transfer) 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 accomodated 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 softswitch or VoIP-PSTN gateways and,
consequently, the proposal.
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 7]
SIGTRAN: This WG specifies a transport protocol for carrying SS7
messages, which is orthogonal to service interworking.
5. Security Considerations
Since the softswitch 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
softswitches with SCPs speaking INAP.
7. References
[1] I, Faynberg, "Intelligent Network Standards", 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.
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 8]
[3]. L. Slutsman, G. Ash, F. Haerens, Vijay K. 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.
[4] 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.
[5] F. Haerens, "Intelligent Network Application Support of the
SIP/SDP Architecture", Internet Draft
<draft-haerens-sip-inap-00.txt>, November 1999, work in progress.
[6] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming
Internet Telephony Services," Technical Report CUCS-010-99,
Columbia University, New York, New York, March 1999.
[7] J. Lennox, J. Rosenberg, H. Schulzrinne, "Common Gateway
Interface for SIP", Internet Draft, <draft-lennox-sip-cgi-04.txt>,
June 5, 2000.
8. Acknowledgments
Janusz Dobrowloski, Vijay Gurbani, Frans Haerens, Jack Kozik, Warren
Montgomery, and Jonathan Rosenberg contributed to discussion 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
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
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 9]
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.
11. Appendix
Figure 1. Simplified IN Architecture
+-----------+
| |
| SCP |
| |
+-----------+
|
|
/ \
/ \
/ INAP \
/ \
/ \
+--------+ ISUP +--------+
| SSP |*********| SSP |
+--------+ +--------+
<draft-schulzrinne-sin-00> July 2000
Interworking between SIP and INAP [Page 9]
Figure 2. Simplified softswitch architecture
+-------------+
| |
| SCP |
| |
+-------------+
|
| INAP
|
+--------+ +-----------+ +---------+
| |Megaco| SIN | ISUP| SSP |
| MG |------| SoftSwitch|-----| |
| | | SIP | +---------+
+--------+ +-----------+
Figure 3. SIP proxy using INAP as a location server
+-------------+
| |
| SCP |
| |
+-------------+
|
| INAP
|
+------------+ +-----------+
| | | [SIN] |
| | |...........|
| | SIP | SIP | SIP
| softswitch |------| proxy |-----
| | | server |
+------------+ +-----------+
<draft-schulzrinne-sin-00> July 2000
| PAFTECH AB 2003-2026 | 2026-04-23 03:52:36 |