Internet Draft Network Working Group D. Lebovits Internet Draft AT&T draft-lebovits-sip-in-00.txt Expires December 2000 SIP/IN Interworking Status of this Memo This document is an Internet-Draft and is in full conformance with 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 obsolete 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 The goal of this document is to identify and propose a new work item for the IETF. This document describes the PSTN Intelligent Network (IN) Architecture support of Session Initiation Protocol (SIP) networks. The concept of the 'Soft-SSF' is introduced which acts as an overlay between the IP telephony call control and the Intelligent Network layer provided by the IN Service Switching Function (SSF) and the IN Service Control Function (SCF). This 'Soft-SSF' provides the necessary mapping between the SIP protocol state machine and the IN Basic Call State Model (BCSM). Also introduced is the Call Manager Function (CMF) which acts as a Mediation Node. The CMF entity is responsible for passing service related information to and from IN service layer, namely the SCF, and managing the service control relationship. As such, the CMF may contain a SSF-like functionality or subset thereof, to model the pre and post conditions that are required to interact with an SCF. The document specifically deals with the proposed standardized interfaces between the functional entities identified in the IN Network with associated functional entities represented in the SIP network. A mapping of parameters of the SIP protocol to the Intelligent Network Application Part Protocol(INAP) may be required for the support of the SIP Proxy Server call control protocol, states and events. Thereby enabling the Mediation Node (CMF) to model a SIP Proxy server. It is the proposal of this document to define the Mediation Node(CMF)to Soft SSF interface as a work item in the IETF as it is presently not a subject for standardization. SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 2] Prior drafts discussed in the IETF have dealt with some of these aspects. This Internet draft also covers the relationship to the existing IETF working groups that deal with the protocols for PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN) and ITU-T. 2. Introduction This document describes the PSTN Intelligent Network (IN) Architecture support of Session Initiation Protocol (SIP) networks. The concept of the 'Soft-SSF' is introduced which acts as an overlay between the IP telephony call control and the Intelligent Network layer provided by the IN Service Switching Function (SSF) and the IN Service Control Function (SCF). This 'Soft-SSF' provides the necessary mapping between the SIP protocol state machine and the IN Basic Call State Model (BCSM). Also introduced is the Call Manager Function (CMF) which acts as a Mediation Node. The CMF entity is responsible for passing service related information to and from IN service layer, namely the SCF, and managing the service control relationship. As such, the CMF may contain a SSF-like functionality or subset thereof, to model the pre and post conditions that are required to interact with an SCF. The document specifically deals with the proposed standardized interfaces between the functional entities identified in the IN Network with associated functional entities represented in the SIP network. A mapping of parameters of the SIP protocol to the Intelligent Network Application Part Protocol(INAP) may be required for the support of the SIP Proxy Server call control protocol, states and events. Thereby enabling the Mediation Node (CMF) to model a SIP Proxy server. It is the proposal of this document to define the Mediation Node (CMF)to Soft SSF interface as a work item in the IETF as it is presently not a subject for standardization. Prior drafts discussed in the IETF have dealt with some of these aspects. This Internet draft also covers the relationship to the existing IETF working groups that deal with the protocols for PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN) and ITU-T. 2.1 Acronyms and definitions Basic Call State Model (BCSM) - IN modeling technique used to represent call related stages. Call Manager Function (CMF)- functional entity that is IP representation of the Call Control Function. Intelligent Network Application Part Protocol(INAP)- IN protocol Service Control Function (SCF) - IN functional entity that contains the IN service logic and handles service related processing activity. Service Switching Function (SSF) - IN functional entity that interacts with call control functions. Call Control Agent Function (CCAF) - IN functional entity that provides the user access to the network. Call Control Function (CCF) - IN functional entity that refers to call and connection handling in the classical sense (e.g. that of an exchange). 3. ITU-T IN/IP Architecture in support of SIP-IN Interworking The following is extracted from the latest version of draft Q.1244 IN Capability Set 4 Recommendation related to IN-IP support of SIP Networks. SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 3] 3.1 Call Manager Function (CMF) CMF is a functional entity, responsible for handling call signaling on either network. It appears to the IN side CCF as being another CCF. This functionality includes handling the management of the call processing, and call signaling. This entity is responsible for passing service related information to and from IN service layer, namely the (define) SCF, and managing the service control relationship. As such, the CMF may contain a SSF-like functionality or subset thereof, to model the pre and post conditions that are required to interact with an SCF. A Call Manager function could be seen as a logical switch (CCF). A Call Manager Function can require SCF assistance for these routing decisions, e.g. for 1-800 numbers, number portability, user profile consultation, VPN support. The functions related to the Call Manager Function are: - Inter-working for: - Number Portability; - Freephone Translations; - VPN support; - O.A.&M. The Call Manager Function also contains Session Management responsible for managing the IP network services. On the IP side it exposes the Registration interface, but one cannot assume that service interactions are only based on Registration flows. The session manager may initiate activities caused by call control signaling events, in case of collocated session manager and call manager. The session manager shall participate in domain/zone management and call signaling. General functions that need to be supported by this session manager - Data filtering/parsing/mapping - Security/Authentication - Real Time data collection (billing/parsing) Triggering of services (in the IN domain or in the IP-network domain) - Configuration/dimensioning - Flow control This entity is responsible for passing registration and admission related information to and from IN service layer, namely the SCF. As such, the session manager may contain a SSF-like functionality or subset thereof, to model the pre and post conditions that are required to interact with an SCF. 3.2 Soft Service Switching Function (Soft-SSF) The Soft SSF interacts with the IN Service Control Function (SCF) and the IP representation of the Call Control Manager (CMF), mapping the Call Control Protocol into the INAP events trigger points and procedures, where applicable. The relation of the Soft SSF to the classical SSF is as follows: Many processes, such as call control, database and billing are retained or enhanced. Circuit switching and ancillary processes are removed. The SIP server inter-working functions are added. The interface between the SIP Server and the 'Soft-SSF' call control processes must: SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 4] Carry sufficient call data for the SSF to function correctly and to deliver the necessary information to the SCF so that service logic decisions can be made. Allow the SCF (in combination with SSF and CCF Emulator) to control VoIP calls (e.g. change 'B' party address) and manipulate call information (such as presentation number). The CMF to Soft SSF interface is presently not a subject for standardization. 3.3 Functional Model The following figure shows the functional model involving IN and SIP inter- working. As indicated above, possible groupings in Intelligent SIP Proxy are depicted. It should be noted that: - The example is by no means exhaustive. For instance, the SIP Proxy may contain a MG function. - The single Intelligent SIP Proxy as modeled in these figures can in fact represent several different physical instances in the network, for example with one Intelligent SIP Proxy in charge of the terminal or access network/domain, and another in charge of the interface to the Switched Circuit Network. Intelligent Network | IP Network | | Service/Application | Layer _____|_____ +---+ |Signaling | +SCP+ |Transport | _________________ +---+ |Gateway | |Intelligent | | | | | |SIP Proxy and | | | | | |Bearer Controller| +---+ | | | | +----+ | +SSF+ | | | | +SOFT+ | +===+ | | | | + SSF+ +---+ | ===========================+CCF+==========|=====|=====|===|==+----+=+CMF+ | +---+ | | | | +---+ | | | | | | |_____|_____| | | | |_________________| Call/Bearer Layer _____|_______ | +--+ | | +MG+ | | +--+ | |Media|Gateway| |_____|_______| Figure 1: A SIP based call control configuration using an intelligent SIP Proxy and Bearer Control Function SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 5] 3.4 Requirements for IN-Interaction with SIP based systems Functional requirements for the IN Interaction with SIP based systems are listed below (initial list for further study): - Relationship of SSF and CCF to the new functional entities introduced in Q.1244 (Distributed Functional Plane for IN CS-4) to decompose the SIP Proxy (i.e. Call Manager Function (CMF)). - Mapping of SIP Registration and Call Signaling messages to INAP operations. - Exact set of SIP Registration functionality which needs to be visible to IN (i.e. need to be monitored or manipulated), if any. This includes the considerations on the kind of modeling required. - Possible Separation of the SSF/CCF into different physical entities. The use of multiple SSFs, where one SSF may model the SIP Registration protocols and another SSF model the SIP Call Control procedures requires consideration. These SSFs may be physically distributed. The configuration of trigger conditions in the soft SSF, manage trigger data from an SCP in the IN domain. - The same CCF/SSF triggering mechanism applies to processing SIP based IN- based call. SSF is located at Intelligent SIP Proxy to interact with SCP in IN domain. - Mapping of the SM to the SSF (like IN FE) and mapping the CMF to the CCF. - For a GW originated IN-based call, the SIP registration server and the Soft-SSF may be distributed in different Intelligent SIP Proxy entities. In this case, dynamic DP arming should be supported at MGC under the control of Intelligent SIP Proxy SM; - The Definition of State Driven Events in the SIP Registration and SIP Call Control Protocols in, there relationship to the SM/CM functions. How these states map into the current IN BCSM models; all require consideration. - The SCF will be able to select one or more appropriate SSF/ Intelligent SIP Proxies dependant on different parameters (class of service requested by the user, placement of gateways, tariff, etc.). The SC-GF will be able to perform correct lower layer protocol and address translation functions. User Interaction requirements for the IN Interaction with SIP Based systems are listed below (initial list for further study): - Intelligent SIP Proxy enhancements for user interaction (e.g.: does it provide control of speech path connection and information on tones and announcements). - The user interaction with SIP User Agent at the terminal may be realized through a SIP Registration interface. The user interaction with PSTN user is realized using MGC relay mode. The information exchange path is Intelligent SIP Proxy to GW interface SIP - The SIP Registration interface may be modified to support user interaction information exchange. A SIP Registration interface between Intelligent SIP Proxy and SIP terminal could be upgraded to support call-unrelated user access service. SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 6] 3.5 The SIP architecture The SIP architecture has 5 functional elements defined in [16]: - User agent client: The user agent client is the functional entity that may initiate a SIP request. - User agent server: The user agent server is the functional entity that may initiate a SIP response. - Proxy server: This functional element is functionally similar to the user agent server, except it is not expected to retain significant call control state. In essence the proxy server is comprised of both a SIP client and a SIP server. - Redirect server: The redirect server is not responsible for call control but will simply respond to SIP requests with a new address. - Registrar server: The registrar server simply responds to registrar requests. Typically this is co-located with either the proxy or the redirect server, and may be adapted to perform location-based services. 3.5.1 SIP Call Models To provide a better understanding of the applicable SIP based call control network architecture, the SIP based call control functional entities are introduced, which may be contained within SIP entities as defined in the standard. This is an attempt to accommodate the new concept of a decomposed SIP Call Control Proxy, and the applicable bearer control Configurations. The functional names have been chosen with the intent of minimizing confusion. They do not intend to imply a specific implementation. In SIP based systems a SIP proxy with call control intelligence is defined. This intelligence will enable nominated SIP proxies to location retain significant call control state. This will enable standards to be developed to synchronize the SIP Call State model with the IN Basic Call State model as defined in Q.1224 and Q.1238. In essence the proxy server is comprised of both a SIP client and a SIP server. It is required to analyze which BCSM states have meaning in a SIP based service context, and how bearer and multimedia support can be added to both this SIP call model and understood in the extension of the IN call control model. 3.5.2 SIP assumptions, architecture and implementation issues The Figure below specifies the IP/IN proposed architecture based on the IETF IP architecture. SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 7] ______________________________ | _______________ | | +-------+ |+---+ | | | +SCF/SDF+ |+SSF+ | | | +-------+ |+-|-+ | | | | | | | | |+-----------+ | | | |+Mapping/CCF+ | | | Intelligent |+-----------+ | | | Network | SoftSSF + | | | Protocol |+-----------+ | | | |______________| | |______________________________| / ______/____ | SIP/SDP | |___________| / \ ______/_ __\______ | TCP | | UDP | |_______| |_________| / \ __________/________\__ | IP v4, IP v6 | |______________________| Figure 2: IETF IP/IN proposed Architecture 3.6 Functional Architecture The proposed functional architecture is provided here for completeness. Figure 3 outlines the proposed functional architecture at the network level. SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 8] +----+ +---+ + SDF+ +SCF+ +-\--+ +-|-+ \INAP | -----------------\----|------------------------------------ | |----\---|-----------------| | | +------+ | | | + SSF + | Extended | | +------+ | Proxy server | | +-----------+ | | | +CCF Mapping+ | | | +----|------+ | | | | 'soft SSF' | | | | | | +---|-------------------+ | +SIP Proxy Server + | +---/-----|-----------\-+ |-----------------------/------|------------\---------------- +---/---+ +|-------+ +\---------+ +Gateway+ + SIP + +Packet Data + +-------+ +Terminal+ + Network + +--------------+ +--------+ +------------+ + PSTN + +-------------+ +--------------+ +Terminal(SIP)+ +-------------+ Figure 3: Functional Architecture to support IN call control of VoIP based on SIP call control Utilizing figure 3, 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 Soft-SSF by the SDF in the subscriber's 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. SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 9] 3.8 Assumptions - All the call flows show that the SIP Proxy Server and the Soft-SSF have been co-located in order to avoid showing an information flows between the two entities. Standardization of the messages for this interface is for further study. - Originating and terminating SIP Proxy servers must operate in a call-state aware mode. - 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 a subscriber places an incoming call. 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). 4. Work item for standardization. It is the proposal of this document to define the Mediation Node (CMF) to the Soft SSF interface as a work item in the IETF as it is presently not a subject for standardization. 5. The Relation of the Proposal to the Existing Work in the IETF IETF WGs that deal with similar issues are IPTEL, MEGACO, PINT, SIP, SPIRITS, and SIGTRAN. This proposal focuses on the groups that deal with PSTN/Internet Interworking. IPTEL: This WG deals with Service Models and Gateway Attribute Distribution Protocol. Since this proposal utilizes already defined service models, this proposal is not targeted to this WG. MEGACO: This WG develops the Media Gateway Control Protocol. Since this proposal utilizes already defined Media Gateway Control Protocol, this proposal is not targeted to this WG. PINT and SPIRITS: These WGs evaluate IN network implementations. Since this proposal is not modifying PINT/SPIRITS interactions, this proposal is not targeted to these WGs. SIP: This WG develops the SIP Protocol. Since SIP expertise is needed for this proposal, it is targeted to this WG. SIGTRAN: This WG specifies the transport layer protocol for carrying SS7. Since this proposal is not modifying SIGTRAN defined interactions, this proposal is not targeted to this WG. 6. The Relation of the Proposal to the Work of Other Standards Bodies The previous sections of this document describe ITU-T Interworking of SIP and IN work presently being developed in ITU-T in the Intelligent Network area, known as draft recommendation Q.1244. Q.1244 includes the IN functional model, a description of the SIP functional model and an architecture describing interworking between IN network and IP network through the specification of SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 10] functional entities. The definition of interfaces between IN functional entities and the IP network is part of draft recommendation Q.1244. It is the proposal of this document to define the Mediation Node (CMF) to the Soft SSF interface as a work item in the IETF as it is presently not a subject for standardization. It is also proposed to work this item jointly with ITU-T. 7. Security Considerations Security issues for the proposed item will need to be examined. 8. Conclusion This document describes the PSTN Intelligent Network (IN) Architecture support of Session Initiation Protocol (SIP) networks. The concept of the 'Soft-SSF' is introduced which acts as an overlay between the IP telephony call control and the Intelligent Network layer provided by the IN Service Switching Function (SSF) and the IN Service Control Function (SCF). This 'Soft-SSF' provides the necessary mapping between the SIP protocol state machine and the IN Basic Call State Model (BCSM). Also introduced is the Call Manager Function (CMF) which acts as a Mediation Node. The CMF entity is responsible for passing service related information to and from IN service layer, namely the SCF, and managing the service control relationship. As such, the CMF may contain a SSF-like functionality or subset thereof, to model the pre and post conditions that are required to interact with an SCF. The document specifically deals with the proposed standardized interfaces between the functional entities identified in the IN Network with associated functional entities represented in the SIP network. A mapping of parameters of the SIP protocol to the Intelligent Network Application Part Protocol(INAP) may be required for the support of the SIP Proxy Server call control protocol, states and events. Thereby enabling the Mediation Node (CMF) to model a SIP Proxy server. It is the proposal of this document to define the Mediation Node (CMF) to the Soft SSF interface as a work item in the IETF as it is presently not a subject for standardization. Prior drafts discussed in the IETF have dealt with some of these aspects. This Internet draft also covers the relationship to the existing IETF working groups that deal with the protocols for PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN) and ITU-T. 9. References [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", Request for Comments (Proposed Standard) RFC 2543, Internet Engineering Task Force, March 1999. [2] V. Gurbani, "Accessing IN Services from SIP Networks," Internet Draft, Internet Engineering Task Force, December 1999, work in progress. [3] V. Gurbani, "SIP enabled IN Services - an implementation report", Internet Draft , Internet Engineering Task Force, November 2000, work in progress. SIP-IN-Lebovits June 2000 <draft-lebovits-sip-in-00.txt> [Page 11] [3] F. Haerens, "Intelligent Network Application Support of the SIP/SDP Architecture", Internet Draft , November 1999, work in progress. [4] L. Slutsman, "Framework and Requirements for the Internet Intelligent Networks (IIN)", Draft , Internet Engineering Task Force, September 2000, work in progress. [5] ITU-T Q.1224 Recommendation, "Distributed functional plane for Intelligent Network Capability Set 2", approved 1997. [6] ITU-T Q.1238 Recommendation, "Interface Recommendation for Intelligent Network Capability Set 3", approved 2000. [7] ITU-T Draft Recommendation Q.1244, "Distributed functional plane for Intelligent Network Capability Set 4", June 2000, work in progress. 10. Author's Addresses Doris Lebovits AT&T 180 Park Ave. Florham Park, New Jersey, 07932 Phone: (973) 236-6776 Email: dlebovits@att.com 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 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 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.