SIP Working Group F. Haerens Internet Draft Alcatel Bell 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]