HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:33:24 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 23 Feb 2000 14:59:00 GMT ETag: "361cfb-3191-38b3f5b4" Accept-Ranges: bytes Content-Length: 12689 Connection: close Content-Type: text/plain SPIRITS Working Group S. Nyckelgard INTERNET-DRAFT Telia Research J. Yoakum, L. Robart Nortel Networks Expires: August 2000 22 February 2000 Telia/Nortel Pre-SPIRITS Implementation Status of This Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. 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. To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes services, architectures, and protocols for existing pre-SPIRITS implementations of arrangements through which PSTN services can request Internet applications. The services and architecture presented was outlined by Telia and then evolved and implemented by Telia in co-operation with Nortel Networks. 1. Introduction This document presents an architecture that enables SIP Redirect Servers (see [1]) to manage calls in a wide range of networks. SIP- based service logic can provide services to multiple networks, including Circuit Switched Networks (CSN), without requiring any changes to existing protocols and network nodes, except for simple re- configurations. 1 Internet Draft Telia/Nortel Pre-SPIRITS Implementation Feb 2000 The scope includes services that execute before any media sessions are established, e.g. Call Routing, conventional 800-services, and similar services involving called and calling party numbers. These services are made fully distributive via IP and without any vendor or system- specific interfaces. This architecture was outlined by Telia and then evolved and implemented by Telia in co-operation with Nortel Networks. The trigger for defining this new concept was the regulatory mandate for Number Portability. The necessity to invest in systems that potentially could make Telia loose customers made Telia target a solution that had the potential to add attractive revenue generating features to the network, in a "" way, in addition to solving the Number Portability requirement. "Future-proof" implied to Telia that the solution had to be based on IP, use only standard protocols, and be scalable, distributive and extensible. There should be no complex platform functions and no vendor or system-specific interfaces. This document describes the architecture and the main principles behind it. 2. Services The architecture was not designed to support a few pinpointed services. The designers defined a more generic approach. The scoop includes services that execute before any end-to-end media sessions are established. It typically includes services that: - redirect calls: Call Transfer, Number Portability, etc. - announce a pending call: Call Offering, Call Waiting, etc. - filter incoming calls: Call Screening, Don't Disturb, etc. - select termination point: Automatic Call Distribution, 800- services, etc. The services run on top of SIP Redirect Servers. The native distributivity of SIP enables these servers to be hosted e.g. by an enterprise server, a Service Provider's server cluster, a user's desktop PC or even by a hand-held cordless device. The SIP Redirect Server receives a SIP INVITE message for each call regardless of which network the call is being set up in. The server MAY apply any kind of service logic in order to decide on how to respond to the invitation. Valid responses from a SIP Redirect Server are defined in the SIP specification [1]. 2 Internet Draft Telia/Nortel Pre-SPIRITS Implementation Feb 2000 Service logic MAY interact with the user e.g. allow the user to accept or redirect the call, e.g. via a PC pop-up window, a designated number/address display or an application in a cellular phone. The logic of services and the means for user interaction are, however, not covered by this document. 3. Architectures and Protocols The general idea behind the architecture is to create services as if all communication was based on IP and all clients and servers were SIP enabled. This of cause isnot true in existing telecommunications networks. Hence, a new type of network element, the Service Control Gateways (SCG) hides the true situation from the services. SCGs convert network-specific call control signaling to SIP messages and vice versa. A SCG behaves as a regular SIP User Agent (UA) towards the services and as a network-specific service control node in the network where the call is being set up. For example, when interfacing a GSM network the SCG can behave either as a SCP or as a MAP or ISUP- proxy. The way to behave depends on what service triggers are being used in the GSM network. SCGs handle protocol conversions but address translation, such as telephone number to SIP URL, are handled by a regular SIP Servers in order to keep the SCG as simple as possible. Example 1: A conventional Number Portability implementation in a mobile Circuit Switched Network(CSN) uses INAP messages to carry number queries to a network-internal database application. Here, a SCG and a high- performance SIP Redirect Server, referred to as the Number Server (NS), have replaced the network-internal database application typically housed in a SCP. +-----------+ INAP +-----+ SIP +--------------------------+ | CSN node |--------| SCG |-------| NS (SIP Redirect Server) | +-----------+ +-----+ +--------------------------+ The INAP IDP message that carries the number query is converted to a SIP INVITE message by the SCG and is then forwarded to the NS (SIP Redirect Server). 3 Internet Draft Telia/Nortel Pre-SPIRITS Implementation Feb 2000 If the called number is not registered, then the NS will return "404 Not Found". The SCG interprets this as "non ported number" and returns a CON message to the CSN network, making it connect the call to the called number. If the number is ported and hence registered, then the NS will return "301 Moved Permanently" with a TEL URL (routing number) in the contact field. The SCG then returns a CON message to the CSN network, making it connect the call to the number that was conveyed in the contact field. The solution above enables the same Number Server to provide Number Portability to multiple networks by means of using multiple SCGs. Example 2: If we make the SIP server in the previous example operate in proxy mode for selected numbers, then it will become a kind of service router, able to proxy number queries to any SIP Redirect Server based service anywhere, provided there is an IP connection to the host in concern. Suppose, for example, that we wish to connect a value-added service, such as a Personal Call Filtering service hosted by a user's desktop PC, to a certain telephone number. +------+ INAP +-----+ SIP +----------------+ SIP +----------+ | CSN |------| SCG |-----| NS |-----| Service | | node | | | |(redirect/proxy)| |(redirect)| +------+ +-----+ +----------------+ +----------+ The INAP IDP message is converted to a SIP INVITE message by the SCG and is then forwarded to the NS, just as in the previous example. However, in this case, the number is registered with a reference to a SIP URL. This makes the Number Server proxy the SIP INVITE message to the registered URL, which is the address of the service. The service responds as a SIP Redirect Server and the Personal Call Filtering service logic determines the response. The NS proxies the response back to the SCG which converts the response to an appropriate INAP message. The response from the service is typically "302 Moved Temporarily" with a telephone number in the Contact field. If the response is 301 or 302, as the examples above suggest, then a telephone number is carried in the contact field. If the user can be reached via several different addresses, then all of them SHOULD be added to the response by means of multiple contact fields. The SCG then selects an address that is valid for the node or application that issued the number query. 4 Internet Draft Telia/Nortel Pre-SPIRITS Implementation Feb 2000 4. Conclusion What has been achieved is a method to create multi-network services without requiring multi-protocol support. The services hence operate in the same way regardless of in which network the call is made. +-----------+ +-------+ SIP +----+ ...... SIP +-----------+ | Network 1 |---| SCG 1 |-----| |---: :-----| Service A | +-----------+ +-------+ | | : : +-----------+ | | : : +-----------+ +-------+ SIP | | : : SIP +-----------+ | Network 2 |---| SCG 2 |-----| NS |---: :-----| Service B | +-----------+ +-------+ | | : Any : +-----------+ | | : IP : +-----------+ +-------+ SIP | | : net- : SIP +-----------+ | Network n |---| SCG n |-----| |---: work :-----| Service C | +-----------+ +-------+ +----+ : : +-----------+ : : +--------+ SIP : : SIP +-----------+ | SIP UA |-----------------------------: :-----| Service x | +--------+ '......' +-----------+ The network independence designed into this model provides a solid base for Personal Mobility, Service Mobility and Number Portability, all within and between any kinds of networks. This model allows unified networks to share common IP centric services, unaware of the unique aspects of each network. The architecture is future-proof since "next generation communication" is expected to be based on IP and use SIP for session initiation. The architecture hence enables "next generation services" to serve users in "current generation networks". 5.0 Security The architecture described in this document uses security mechanisms available to ordinary SIP services, implemented as they would be in a pure SIP network. The architecture described here does not impose any additional security considerations. General security issues that must be considered include interconnection of two different networks. SCGs must therefore include mechanisms that prevent destructive service control signaling from one network to the other, e.g. a firewall-type mechanism that can block a denial-of- service attack from an Internet user towards a PSTN. 5 Internet Draft Telia/Nortel Pre-SPIRITS Implementation Feb 2000 6.0 References [1] Handley, et al, "SIP: Session Initiation Protocol", RFC 2543, March 1999 7.0 Author's Addresses Soren Nyckelgard Telia Research Chalmers Teknikpark 41288 Gothenburg Sweden soren.m.nyckelgard@telia.se John Yoakum Nortel Networks 507 Airport Blvd, Suite 115, Morrisville, NC, USA 27560 yoakum@nortelnetworks.com Lewis Robart Nortel Networks P.O. Box 402 Ogdensburg, NY, USA 13669 robart@nortelnetworks.com This draft expires August 2000. 6