SIP Working Group F.Haerens Internet Draft Alcatel Bell Document: draft-haerens-sip-in-00.txt February 2001 Category: Informational SIP-IN Interworking Protocol Architecture and Procedures 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 draft gives a first input on the SIP-IN Interworking Protocol Architecture and Procedures for further discussion into the IETF as part of the SIP-IN Interworking (SIN design team). The aim of the SIP/IN Interworking is to consider the support of existing IN-based applications in a SIP-based IP environment for IP-Host-to-Phone calls. There are many telephony applications based on IN: 800 (freephone), PSTN VPN, credit card calling, to name a few. This interworking protocol design team work requires: - Interpreting IN Call Models for the SIP environment - Mapping IN messages into (sequences of) SIP messages and vice versa - Mapping IN parameters into SIP parameters and vice versa - Defining SIP extensions, if necessary It was agreed that the contributors on the SIN design team should first publish respective I-Ds, which are then used as the basis of the informational draft that will be the major output of the design team. Haerens Informational 1 SIP-IN Interworking Protocol Februay 2001 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Architecture Model 3.1 Introduction Figure 1 shows the architecture model involving IN and SIP inter- working. The possible groupings in the Intelligent SIP servers are depicted. The architecture model for accessing IN from SIP/SDP proxy/redirect servers SHOULD have a minimal support for implementing services that require explicit handling of the call configuration: The following capabilities are considered: (i) Number translation services including the storage of related information (time of day) for e.g. portability and free phone based services (ii) Redirection services (iii) Virtual Private Network services (iv) Charging, the charging operations presently defined need to be extended for the internet supported services including credit card calling. It should be noted that the single Intelligent SIP Proxy/Redirect Server as modeled in this figure can in fact represent several different physical instances in the network, for example with one Intelligent SIP server 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 +---+ | |SDF| +---|------+ +-+-+ | | +-----------------+ +---+<-------^ |Signaling | |Intelligent SIP | |SCP|<------------+ |Transport | |Proxy/Redirect...| +-+-+<-----+ | |Gateway | | Server | | | | | | | | and | | +-+-+ | | | | |Bearer Controller| +-+-+ |SCF| | | | | | +----+ | |SSF| +->| |<-+ | | | | | |SSF | | | | | +-+-+ | +---|---|------|-----|->|(IP)| | Haerens Informational 2 SIP-IN Interworking Protocol Februay 2001 +---+---- | | | | | | +----+----+ | | |<----+ | | | | | | | | |CCF|<--------------|-----|---|------|-----|------>|CCF | | ==| |===============|=====|==========|=====|=======|(IP)|====|== +---+<-------+ | | | | +---|------>+--o-+ | | | +---|------+ | +----------|------+ | | | | | Call/Bearer | | +---|------+ | | Layer | | | +--+ | | +----o---+ | +-----|->|MG|<---|-+ RTP | | +------------|->| |<---|---------->| SIP | | +--+ | | TE UA | | Media | | | | Gateway | +--------+ +---|------+ | Figure 1: A SIP based call control configuration using an intelligent SIP Proxy/Redirect Server and Bearer Control Function The following Architecture entities are defined in the Intelligent Network standards: 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 Function (CCF): IN functional entity that refers to call and connection handling in the classical sense (e.g. that of an exchange). Service Data Function (SDF): The SDF contains customer and network data for real-time access by the SCF in the execution of an IN provided service. The enhancements to the IN Architecture required for the IN/IP interworking to support SIP/SDP systems are defined in section 3.2 while the interfaces as identified in figure 1 are given in section 3.3. 3.2 Enhancements to the Architecture Entities required for SIP-IN interworking The enhancements to the following architecture entities are required for the IN/IP interworking to support SIP systems: Haerens Informational 3 SIP-IN Interworking Protocol Februay 2001 (i) Call Control Function: CCF(IP) (ii) Service Switching Function: SSF(IP) 3.2.1 Call Control Function CCF(IP) is an enhanced functional entity, responsible for handling call signaling on either network. To support the ISUP signalling the CCF has to implement the procedures defined by SIP-T. In that case 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 SCF, and managing the service control relationship. As such, the CCF 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 Control function could be seen as a logical switch (CCF). A Call Control 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 Control Function Entity are: i) Inter-working for: - Number Portability; - Freephone Translations; - VPN support; - O.A.&M. ii) The Call Control Function is responsible for passing registration and admission related information to and from IN service layer, namely the SCF responsible for managing the IP network services. General functions that need to be supported are: - Data filtering/parsing/mapping - Security/Authentication - Real Time data collection (billing/parsing) - Configuration/dimensioning - Flow control iii) The Call control function contains a high layer resource manager function call Media Gateway Control (MGC) function. This MGC function is responsible for controlling the lower layer resource control function referred to as Media Gateway (MG). iv) The Call Control function inter-works with and maps to the underlying call control signalling (SIP/SDP). The call control may invoke media and connection operations, for legs, media, packages independent of before or after the IN interaction. Where call Haerens Informational 4 SIP-IN Interworking Protocol Februay 2001 control protocol is encapsulated in SIP (e.g. ISUP in SIP-T), mapping to this package, or the embedded protocol may also need to be specified. v) Circuit switching and ancillary processes are removed 3.2.2 Service Switching Function:SSF(IP) The enhanced SSF(IP) interacts with the IN Service Control Function (SCF) and the IP representation of the Call Control Function (CCF), mapping the Call Control Protocol into the INAP events trigger points and procedures, where applicable. The relation of the SSF(IP) to the classical SSF is as follows: Many processes, such as call control, database and billing are retained or enhanced. The interface between the SIP Server and the SSF call control processes MUST: (i) 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. (ii) 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). 3.3. Interfaces required for SIP-IN interworking (i) CCF-to-CCF(IP) interface This interface reflects the requirement to carry an ISDN control plane signalling protocol for Multimedia services. This interface relays the IP Multimedia user plane received from the CCF (Call control Function). This interface is required for Voice over IP based services. This interface may require standardisation but is not expected to be IN specific, work is progressing on this in ETSI TIPHON, IETF, SG11 BICC and SG16 H.246 Annex C. (ii) SCFûto-SSF(IP) interface This interface reflects the requirement to carry an IN-based signalling protocol for IP and Multimedia services. This interface relays the IP Multimedia control plane triggered events to and from the SCF. This interface may require standardisation. This interface is required to trigger and control value added services from a SIP Proxy/Redirect Server function in the IP network e.g. for multimedia access from the Internet "dial-up" access. (iii) CCF(IP)-to-Media Manager (MG) interface Haerens Informational 5 SIP-IN Interworking Protocol Februay 2001 This interface reflects the requirement to carry an ISDN user plane protocol for Multimedia services. This interface relays the IP Multimedia user plane received from RTP/RTCP and is defined as the Media Gateway Control interface. This interface may require standardisation but is not expected to be IN specific, work is progressing on this interface in ETSI TIPHON, IETF, SG11 BICC and SG16. This interface is required for Voice over IP based services. 4. Requirements for In-Interaction with SIP based systems. Functional requirements for the IN Interaction with SIP based systems are listed below : - Relationship of SSF and CCF to the enhanced functional entities introduced in Distributed Functional Plane for IN to decompose the SIP Proxy/Redirect Server (i.e. Call Control Function CCF(IP)). - 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 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/Redirect Server to interact with SCP in IN domain. - Mapping of the CCF(IP) to the CCF. - For a GW originated IN-based call, the SIP registration server and the SSF may be distributed in different Intelligent SIP Proxy/Redirect Server entities. In this case, dynamic DP arming SHOULD be supported at MGC under the control of Intelligent SIP Server; - The Definition of State Driven Events in the SIP Registration and SIP Call Control Protocols in, there relationship to the CCF functions. How these states map into the current IN BCSM models; all require consideration. Haerens Informational 6 SIP-IN Interworking Protocol Februay 2001 - The SCF will be able to select one or more appropriate SSF/ Intelligent SIP Proxy/Redirect servers 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 : - Intelligent SIP Proxy/Redirect Server 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/Redirect Server 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/Redirect Server and SIP terminal could be upgraded to support call-unrelated user access service. The user interaction enhancements will be treated into a separate draft RFC. 5. The SIP-IN Protocol Architecture. 5.1 Introduction The SIP architecture has 5 functional elements defined in [4]: - 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. Haerens Informational 7 SIP-IN Interworking Protocol Februay 2001 This section provides information flows that illustrate an overview of the interaction of SIP and IN capabilities. In particular it provides a proposal for the triggering of IN services as well as a mapping between the IN call states and related Session Initiation Protocol (SIP) call states. An overall objective is to ensure that IN 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 connect to present or future networks, simplifies service evolution from present to future, and leads to more rapid implementation. This section investigates the possibility of IN 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 IN services. Subsequent sections will specify the interworking protocol based on the defined SIP-IN Protocol architecture in this section The section is organised as follows: Section 5.2 outlines the proposed functional protocol architecture for the support of SIP-IN interaction. Section 5.3 briefly describes the concepts for IN service triggering based on IN Subscription Information. 5.2. SIP-IN Functional Protocol Architecture The Figure 2 specifies the IP/IN proposed architecture based on the IETF IP architecture. +------------------------------+ | +--------------+ | | +-------+ |+-----------+ | | | |SCF/SDFo----oSSF(IP) | | | | +-------+ |+-----o-----+ | | | | | | | | |+-----o-----+ | | | ||CCF(IP) | | | | Intelligent |+-----o-----+ | | | Network | | | | | Protocol | | | | | +------|-------+ | +--------------------|---------+ | +------o----+ | SIP/SDP | +-----------+ / \ +-------+ +---------+ | TCP | | UDP | +-------+ +---------+ / \ Haerens Informational 8 SIP-IN Interworking Protocol Februay 2001 +----------------------+ | IP v4, IP v6 | +----------------------+ Figure 2: IETF IP/IN proposed Architecture The SIP-IN functional protocol architecture at the network level is given in Figure 3. +-------+ +-------+ | SCF | | SDF | +---o---+ +---o---+ | | +-----+-----------+ | **********|*********************************** * +-------|-------------------+ * * |+------o------+ | * * || SSF(IP) | | * * |+-------------+ | * * || CCF(IP) | | * * |+------o------+ | * * +-------|-------------------+ * * | Extended * * +-------o-------------------+ SIP * * | SIP Server | Server * * +---o---------o---------o---+ * ******|*********|*********|******************* | | | (^^^^) +---+ +----o----+ +---+ (^^^^) ( ) | | SIP | | ( ) ( +-----o-+ |Terminal | (^^^^ ) ( |Gateway| +---------+ ( Packet ) ( +-------+ ( Network ) ( ) ( +--------+ ( SCN ) ( |Terminal| (......) (....+--------+ Figure 3: Proposed functional protocol Architecture for SIP-IN interaction. 5.3 Basic concepts for In service triggering The process how to handle the registration process needs further study in conjunction with the API methods presently standardised and the mapping to the SIP/SDP procedures and extensions. Subscribers may register in the SIP network allowing the subscriber to receive incoming calls. A subscriber may use an additional identifier (e.g. NB-ISDN) in the registration process. Upon registration with the server, the subscription information for the subscriber is sent to the SSF by the SDF in the subscriberÆs home network. As incoming calls made to the subscriber terminate at the Haerens Informational 9 SIP-IN Interworking Protocol Februay 2001 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 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. The following assumption are made concerning the SIP-IN functional protocol architecture control flows. (i) All the call flows show that the SIP Proxy Server and the SSF 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. (ii) Originating and terminating SIP Proxy servers MUST operate in a call-state aware mode. (iii) 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). (iv) The information flows make no consideration for inter-working with other networks (e.g. PSTN via gateways) 6. Mapping examples of SIP message to the IN State Models 6.1 Mapping of SIP messages to the IN Basic Call State Models This section deals with the Registration process and how the Originating (O-BCSM) and Terminating (T-BCSM) Basic Call State Model Points in Call (PICs) and Detection Points (DPs) or dynamic events are mapped to the appropriate SIP messages. Although a mapping is possible, there is not always the same analogy between the circuit switched environment that the BCSM were designed for and the IP environment, and as a result a direct mapping is not always possible. The state models for the INAP O-BCSM and the T-BCSM are based on the INAP CS 3. Haerens Informational 10 SIP-IN Interworking Protocol Februay 2001 The mapping examples given in this section allow for an initial inside of how the detailed IN state models operate. Detailed mapping examples are provided in Annex A of this RFC draft. 6.2 Registration process This section is intended to define the registration process based on the SIP REGISTER message, which allows subscription of information to be stored in the SIP Server/SSF. IETF RFC 2543 [x}defines the term Registrar for registration purposes and it is the SIP registrar that accepts the REGISTER method.. With the SIP REGISTER method, it is assumed that registration with a location server takes place. Unlike H.323, registration with a server is not mandatory. Only users that wish to receive incoming calls need to register with a SIP Proxy server and a location server. Callers placing calls are not required to register. It is proposed that the registration process is further aligned with the API architecture presently standardized in ETSI SPAN see web page URL: http://docbox.etsi.org/tech- org/span/open/span12/index.html and that the mapping is also defined. 6.3 Mapping to Originating BCSM for Originating calls The mapping between the SIP methods and responses for O-BCSM relating to Originating Calls is shown in Figure 4. Only the successful case is described. {1} The Calling User Agent Client initiates a SIP request by issuing an INVITE method to the SIP Proxy server. {2} The INVITE message arrives at the proxy server, indicating that the subscriber has requested to set up a call. The SIP Proxy server determines if Originating subscriber exists for this user. The SDF/LDAP functionality in the SSF is checked to determine if the calling party has previously registered. If no registration is found, then step {3} is followed. If the SSF determines that the calling user has a valid registration then step {4} is followed. {3} The SSF establishes a dialogue with the SDF or LDAP of the subscriberÆs network. {4} The originating subscriber data is analyzed and if the necessary triggering criteria are met, the SCF is invoked via an InitialDP message. The SCF can be invoked at either DP Origination_Attempt or DP Origination Attempt_Authorised or DP Collected_Information or DP Analysed_Information. Haerens Informational 11 SIP-IN Interworking Protocol Februay 2001 {5} Instructions are received from the SCF on how the call is to be routed, together with which EDPs are armed. The state Send_Call entered and the INVITE method is forwarded to the destination. {6} A response æ180 RingingÆ indicates that the destination has been alerted in session invitation. State O_Aleting is entered, DP O_Term_Seized may be reported to the SCF and an æ180 RingingÆ is sent to the originating party. {7} A response æ200 OKÆ indicates that the destination has accepted in session invitation, indicating that a session has been established. State O_Active is entered, DP O_Active may be reported to the SCF and an ACK is sent to the originating party. (8) Either party may release the call with a BYE method. On receipt of the BYE, transition to the PIC O_Null takes place and the DP O_Disconnect may be reported to the SCF. +-----------+ +--------+ +-----------+ |Originating| |Extended| |Terminating| | UAC | |Proxy | UAS | +-----------+ +--------+ +-----------+ | | | | INVITE [2] [3] | 1 o--------------->o | | | [4] | +-----------------+ | o-------------------------| O_Null | | | | +--------o--------+ | | | | | | | +--------o--------+ | | | | Authorize_ | | | | | Origination_ | | | | | Attempt | | | | +--------o--------+| | | | | | | | +--------o--------+ | | | | Collect_ | | | | | Information | | | | +--------o--------+ | | | | | | | +--------o--------+ | | | | Analyse_ | | | | | Information | | | | +--------o--------+ | | | | | | | +--------o--------+ | | | | Select_Route | | | | +--------o--------+| | | | | | | | +--------o--------+ | | | | Authorise_ | | | | | Call_Setup | | | | +--------o--------+ Haerens Informational 12 SIP-IN Interworking Protocol Februay 2001 | | | | | | [5] | +-----------------+ | o-------------------------| Send_Call | | | INVITE | +--------o--------+ | |------------->| | | | 180 Ringing | | | 180 Ringing |<-------------| | |<---------------| [6] | +--------o--------+ | o-------------------------| O_Alerting | | | | +--------o--------+ | | 200 OK | | | 200 OK |<-------------| | |<---------------| [7] | +--------o--------+ | o-------------------------| O_Active | | | | +--------o--------+ | | BYE | | | BYE |<-------------| | |<---------------| [8] | +--------o--------+ | o-------------------------| O_Null | | | | +--------o--------+ Figure 4: Mapping to O-BCSM and corresponding PICs for Successful Originating calls 6.4 Mapping to Terminating BCSM for successful terminating calls The mapping between the SIP methods and responses for T-BCSM to Terminating Calls is shown in Figure 5. The information flows for the successful case are described below: {1} When the INVITE method arrives at the destination SIP Proxy server, the server SSF shall determine if a Terminating Subscriber data exists for the called user {2} If the terminating subscriber data exists it shall be analyzed and if the necessary triggering criteria are met, the SCF is invoked )by establishing a dialogue and e.g. by sending an InitialDP message between the SSF and SCF. The SCF can be invoked either at DP Termination_Attempt or DP Termination_Attempt_Authorized. Transition to state Select_Facility occurs and DP Facility_Selected_and_Available may be reported. The INVITE may either be sent during the Select_Facility PIC or the Present_Call PIC. {3} Call alerts the terminating parting. DP Call_accepted may be reported to the SCF, the state T_Alerting is entered. {4} Call answered by the terminating party. DP T_Answer may be reported to the SCF, state T_Active entered. {5} Either party may terminate the call by sending a BYE and transition to PIC T_Null takes place and the DP T_Disconnect may be reported. Haerens Informational 13 SIP-IN Interworking Protocol Februay 2001 +-----------+ +--------+ +-----------+ |Originating| |Extended| |Terminating| | UAC | |Proxy | UAS | +-----------+ +--------+ +-----------+ | | | | INVITE [1] [2] | +-----------------+ o--------------->o-------------------------| T_Null | | | | +--------o--------+ | | | | | 100 Trying | | +--------o--------+ |<---------------o | | Authorize_ | | | | | Termination_ | | | | | Attempt | | | | +--------o--------+| | | | | | | | +--------o--------+ | |[2} | | Select_ | | o-------------------------| Facility | | | | +--------o--------+ | | | | | | [2] | +-----------------+ | o-------------------------| Present_Call | | | INVITE | +--------o--------+ | |------------->| | | | 180 Ringing | | | 180 Ringing |<-------------| | |<---------------| [3] | +--------o--------+ | o-------------------------| T_Alerting | | | | +--------o--------+ | | 200 OK | | | 200 OK |<-------------| | |<---------------| [4] | +--------o--------+ | o-------------------------| T_Active | | | | +--------o--------+ | | BYE | | | BYE |<-------------| | |<---------------| [5] | +--------o--------+ | o-------------------------| T_Null | | | | +--------o--------+ Figure 4: Mapping to O-BCSM for Successful Originating calls 6.5 Mapping to Terminating BCSM for unsuccessful terminating calls This subsection explores the mapping and the reporting of the DPs that may be encountered when the call is not successfully established. The information flows are shown in Figure 6 and is further explained below: Haerens Informational 14 SIP-IN Interworking Protocol Februay 2001 {1} INVITE method arrives at the destination SIP proxy server. Server/SSF determines if the Terminating subscriber data exists for the called user. {2} Terminating subscriber data is analysed and if necessary triggering criteria are met, SCF is invoked. Transition to state Present_Call PIC and an INVITE is sent to the terminating subscriber. {3} The destination does not accept the incoming call û reason response may be any value in 4xx response range. The mapping of client error codes (4xx) to the possible Detection Points in PIC Terminating_Call_Handling is performed. For example, DP T_Busy can be mapped onto Æ 486 BusyÆ . The mapping of the various DPÆs such as T_Abandon , T_No_Answer ect. onto the error codes are specified in the section 8. +-----------+ +--------+ +-----------+ |Originating| |Extended| |Terminating| | UAC | |Proxy | UAS | +-----------+ +--------+ +-----------+ | | | | INVITE [1] | +-----------------+ o--------------->o-------------------------| T_Null | | | | +--------o--------+ | | | | | 100 Trying | | +--------o--------+ |<---------------o | | Authorize_ | | | | | Termination_ | | | | | Attempt | | | | +--------o--------+| | | | | | | | +--------o--------+ | | | | Select_ | | | | | Facility | | | | +--------o--------+ | | | | | | [2] | +-----------------+ | o-------------------------| Present_Call | | | INVITE | +--------o--------+ | |------------->| | | |4xx Error Code| | | 4xx Error Code |<-------------| | |<---------------| [3] | +--------o--------+ | o-------------------------| T_Null | | | | +--------o--------+ Figure 6: Mapping to T-BCSM for Unsuccessful Terminating calls 7. Call State Mapping Haerens Informational 15 SIP-IN Interworking Protocol Februay 2001 NOTE: This section is based on the information contained in the Internet draft <draft-gubani-iptel-sip-to-in-03.txt> from Mr. V. Gurbani and has been extended: i) the distinction between 100 Trying, 181 Call Is Being Forwarded, 182 Queued and 183 Session Progress has been handled ii) the mapping to the IN Abstract Signalling Primitive conventions has been given. iii) the IN half call concept has been applied. The mapping of the PICÆs (Points In Call)and the DP (Detection Point) of the IN call model into SIP can be easily translated for IN services that have a "query-response" like freephone, originating call screening, caller name identification. IN states will be mapped to the appropriate SIP methods or response codes. While mapping call states from SIP to IN, it is important to note that there will not be a 1-to-1 mapping. IN call states have been developed for a circuit domain, hence domain specific PICs like SELECT_ROUTE which selects an outgoing trunk facility, may not have an equivalent analogy in a packet world. 7.1 SIP and O_BCSM The PICs of O_BCSM come into play when a call request SIP INVITE message arrives from a SIP UAC to an SIP server running the IN Originating call model. This SIP server will create a O_BCSM object and initialize it into the O_NULL PIC. In the AUTH_ORIG_ATT PIC, a SIP server running the IN call model has detected that someone wishes to make a call. Under some circumstances (e.g. the user is not allowed to make calls during certain hours), such a call cannot be placed. SIP has the ability to authorize the calling party using a set of policy directives configured by the SIP administrator. If the called party is authorized to place the call, the IN layer is instructed to enter the next PIC, COLLECT_INFO. This COLLECT_INFO PIC is responsible for collecting a dial string from the calling party. The SIP server can detect a imcomplete address and may send to the calling party a "484 Address Incomplete" message and remain in this state until a valid "dial string" is received via an INVITE method. This INVITE contains the same "From" and "Call-ID" headers. The "To" field is updated to reflect the entire called number as known so far. Since the "To" field is different, this transaction represents a different call leg than the INVITE in step 1; consequently, there is no relationship between the CSeq values in the two INVITE messages. Once it has obtained a valid dial string, the IN layer is instructed to enter the next PIC, ANALYZE_INFO. Haerens Informational 16 SIP-IN Interworking Protocol Februay 2001 The ANALYZE_INFO PIC can either generate the 100 TRYING if the analysed information function has been performed successfully or may sent to the calling party a "484 Address Incomplete" message and remain in this state until a valid "dial stringÆ is received via an INVITE method if more (addressing) information is required. This PIC is responsible for translating the dial string to a routing number. Many IN service such as freephone, LNP, OCS, etc. occur during this PIC. The SIP server can send the SIP URI in the To: field to the IN layer to have it analyzed. If the analysis succeeds, the IN layer is instructed to enter the next PIC, SELECT_ROUTE. The SELECT_ROUTE is basically a fall through PIC to the next AUTH_CALL_SETUP PIC. In IN, SELECT_ROUTE selects the actual physical route. This, of course, does not have an equivalent in SIP since the SCP is expecting trunk IDs and SIP is dealing with URLs. There is no clear SIP analogue of this PIC. Selecting a route in SIP consists of determining the next hop SIP server. Current IN services on the SCP require line/trunk information to function, not the choice of a next hop SIP server. The AUTH_CALL_SETUP PIC is used for certain service features to restrict the type of call that may originate on a given line or trunk. This PIC is the point at which relevant restrictions are examined. If the above PICs have been successfully negotiated, the SIP server running the IN call model now sends the Setup.Req.Ind Abstract Signalling Primitive to the T_BCSM. This will lead to the eventual processing of the SIP INVITE message to the next hop server. The next PIC, SENT_CALL is now entered. In IN terms, the control over the establishment of the call has been transferred to the T_BCSM object, and the O_BCSM object is waiting for a signal confirming that either the call has been presented to the called party or that the called party cannot be reached for a particular reason. If in the SENT_CALL PIC a 181 Call Is Being Forwarded a 182 Queued or a 183 Session Progress message is received it will stay in this PIC. If a 100 Trying is received it stays into the SENT CALL PIC. When the SIP server running the IN call layer gets back a "180 Ringing" for the call, it now instructs the IN layer to enter the next PIC, O_ALERTING. At this point, O_BCSM is waiting for the called party to answer. Assuming the called party answers, the SIP server running the IN layer receives a "200 OK". The receipt of this message is followed by the SIP server instructing the IN layer to enter the next PIC, O_ACTIVE. The call is now active. When either of the party hangs up, the SIP server running the IN call layer receives a SIP BYE message. Since it is running in call- stateful mode, it can correlate the BYE message with the call that Haerens Informational 17 SIP-IN Interworking Protocol Februay 2001 needs to be torn down. The SIP server instructs the IN layer to enter O_DISCONNECT DP and perform cleanup. Subsequently, the state of the call in the SIP server itself is also destroyed. Figure 7 below provides a the mapping from the SIP server protocol state machine to the originating half of the IN call model. SIP O_BCSM +-----------------+ (1) ===============>| O_NULL PIC | +--------o--------+ | +--------V--------+ (2) <===============| AUTH_ORIG_ATT | | PIC | +--------o--------+ | +--------V--------+ (3) <==============>| COLLECT_INFO PIC| +--------o--------+ | +--------V--------+ (4) <===============| ANALYSE_INFO PIC| (5) <==============>| | +--------o--------+ | +--------V--------+ | SELECT_ROUTE PIC| +--------o--------+ | +--------V--------+ | AUTH_CALL_SETUP | | PIC | +--------+--------+ | +--------V--------+ (6) <===============| SENT_CALL PIC |------->+---------+ | |-----+ |O_Called_| +--------o--------+ | |Party_ | (10) <========================|==============|==|BusyDP | | +-|->+---------+ +--------V--------+ | | (7) <===============| O_ALERTING PIC |---+ +->+---------+ | |------->|O_No_ _| +--------o--------+ |AnswerDP | (11) <========================|=================| | | +---------+ +--------V--------+ (8) <===============| O_ACTIVE PIC | (9) ===============>| | Haerens Informational 18 SIP-IN Interworking Protocol Februay 2001 (12) ===============>| | +-o------o--+----++ (16) <=================|======|==| | O_Re-AnswerDP | | +---+ +--------+ | | ^ (13) ===>|O_Discon|<---+ | | (14) <===|nectDP |<---+ | | +---- ---+ | +-V--+ | (15) <=================|====| | | O_SuspendDP +-o--- +----+-o---+ (8) <===============| O_SUSPENDED PIC | (9) ===============>| | (12) ===============>| | +-----------------+ Legend: | Communication between | states V ======> Communication between IN layer and SIP Figure 7: Mapping of the SIP methods to O_BCSM The following mapping to the IN Abstract Signalling Primitive conventions and call signalling indications applies: (1) An Indication is sent from Ingress Server/User to O_BCSM to initiate call establishment (e.g. Setup.Ind Abstract Signalling Primitive mapped from a INVITE method). (2) An Indication is sent from O_BCSM to Ingress Server/User that network is unable to initiate call (e.g.Release.Req Abstract Signalling Primitive mapped to 401 Unauthorised). (3) The Ingress Server/User sends call (dialling) information to the O_BCSM (e.g. SubsequentAddress Abstract Signalling Primitive mapped from INVITE method as a result of receiving an 484 Address Imcomplete from the O_BCSM). (4) An Indication is sent from O_BCSM to the Ingress Server/User to terminate the sending of call information (e.g. CallProgress(Progress).Req Abstract Signalling Primitive mapped to 100 Trying). (5) An Indication is sent from the Ingress Server/User to the O_BCSM upon completion of call information (e.g. SubsequentAddress Abstract Signalling Primitive mapped from INVITE method as a result of receiving an 484 Address Imcomplete from the O_BCSM) (6) Ingress Server/User is informed that call has been routed to another environment of network (e.g. CallProgress(Progress).Req Abstract Signalling Primitive mapped to either: a 181 Call Is Being Forwarded; or a 182 Queued, or a 183 Session Progress message (7) An Indication is sent from the O_BCSM to the Ingress Server/User when the called party is being alerted (e.g. Haerens Informational 19 SIP-IN Interworking Protocol Februay 2001 CallProgress(Alert).Req Abstract Signalling Primitive mapped to a 180 RINGING). (8) An Indication is sent from the O_BCSM to the Ingress Server/User when the call is accepted. (e.g. Setup.Resp Abstract Signalling Primitive is mapped to 200 OK) (9) The Ingress Server/User acknowledges that the call is accepted. (receipt of the ACK method) (10) The O_BCSM sends an Indication to the Ingress Server/User that the called party is unable to accept the call, due to busy condition. (sending of the 484 Busy Here or 600 Busy Everywhere. (11) The O_BCSM sends an Indication to the Ingress Server/User since the called party is unable to accept the call, due to no answer condition. (sending of the 480 Temporarily unavailable) (12) An Indication is received by the O_BCSM from the Ingress Server/User to end the call.( receipt of CANEL or BYE method) (13) The O_BCSM indicates to the Ingress Server/User that the call is being disconnected.(sending of BYE method) (14) The Ingress Server/User acknowledges to the O_BCSM that the call is being disconnected.(receipt of ACK) (15) An Indication is sent to the Ingress Server/user when the connection towards the Called Party is suspended. In SCN networks, the user can generate a suspend (timer supervised)in order to unplug the terminal from the socket and plug it in another one. When a network suspend arrives from the SCN, the server/MGC sends an INVITE towards the calling user in order to put the media stream on hold. (16) An Indication is sent to the Ingress Server/user when the connection towards the Called Party is reconnected. A resume is sent once the terminal has been reconnected and the timer has not expired this will be seen as an network resume. The reception of a resume triggers another INVITE toward the calling user/Ingress server that resumes the media stream. For the SIP UAC/UAS the result is an interruption in the voice path until the other party picks up the phone again. 7.2. SIP and T_BCSM The T_BCSM object is created when the termination half call of the SIP server running the IN layer receives the Setup.Req.Ind Abstract Signalling Primitive from the O_BCSM. The SIP server initializes T_BCSM object it to the T_NULL PIC. The IN layer is instructed to enter the next PIC, AUTH_TERM_ATT, during which the called party wishes that the present type of call is ascertained. IN services such as Called Line Identification and Call Forwarding are normally triggered from DPs associated with this PIC. Once a positive indication is received from the AUTH_TERM_ATT PIC, the IN layer is instructed to enter the next PIC, SELECT_FACILITY. Haerens Informational 20 SIP-IN Interworking Protocol Februay 2001 This PIC does not readily map into a SIP model. The intent of this PIC, in traditional circuit networks, is to select a line or a trunk to reach the called party. This, of course, does not apply in SIP, hence this PIC is simply a fall- through to the next PIC, PRESENT_CALL. In a traditional circuit-switched network, PRESENT_CALL presents (via ISUP ACM or Q.931 Alerting messages) the call to the called party. When the SIP server sends out the INVITE to the UAS, it instructs the IN layer to enter this state. The IN layer will remain in this state until the SIP server gets back a "180 Ringing", whereupon it instructs the IN layer to enter the next state, T_ALERTING. T_ALERTING "alerts" the called party by ringing the phone. When the SIP server receives a "200 OK", it instructs the IN layer to enter the next PIC, T_ACTIVE. The call is now active. When either of the party hangs up, the SIP server running the IN call layer receives a SIP BYE message. Since it is running in call- stateful mode, it can correlate the BYE message with the call that needs to be torn down. The SIP server instructs the IN layer to enter its next PIC, T_DISCONNECT and perform cleanup. Subsequently, the state of the call in the SIP server itself is also destroyed. Figure 8 below provides a visual mapping from the SIP server protocol state machine to the terminating half of the IN call model: SIP O_BCSM +-----------------+ | T_NULL PIC | +--------o--------+ | +--------V--------+ |AUTH_TERMINATION | +---| _ATTEMPT PIC |================> (1) | +--------o--------+ | | +---------+ | +--------V--------+ | |<--+ | SELECT_FACILITY | |T_BusyDP_|<------| PIC | | |<----+ +--------o--------+ +---------+ | | | +--------V--------+ | | PRESENT_CALL PIC|<===============> (1) to (6) +--|-| | | | +--------o--------+ | | | | | | +---------+ | | +--------V--------+ |T No_ |<-+ +-| T_ALERTING PIC | |AnswerDP |<------| |<================ (7) Haerens Informational 21 SIP-IN Interworking Protocol Februay 2001 | | +--------o--------+ +---------+ | +--------V--------+ | T_ACTIVE PIC |================> (8) | |================> (11) | |--------+ ++---+---o--------+ | T_Re-AnswerDP | | |<================|======== (9) +---+ | | ^ | | |<====|========================== (10) | | | | +-V--+ | | | | T_SuspendDP | +--o-- +----+-o---+ +--V-----+ (8) <===============| T_SUSPENDED PIC | |T_Discon|<=======(13) (9) ===============>| |---->|nectDP |=======>(14) (12) ===============>| | +--------+ +-----------------+<======================(12) Legend: | Communication between | states V ======> Communication between IN layer and SIP Figure 8: Mapping of the SIP methods to T_BCSM The following mapping to the IN Abstract Signalling Primitive conventions and call signalling indications applies: (1) An Indication is sent from T_BCSM to the Egress Server/User to terminate the call to an idle facility (e.g. Setup.Req Abstract Signalling Primitive mapped to the INVITE method). (2) An Indication is sent from Egress server/user to T_BCSM indicating that the Egress server/user cannot accept the call. (e.g. Release.Req Abstract Signalling Primitive mapped to BYE method). The called number can be received in just one INVITE method(`en bloc' signalling) or in one INVITE method followed by one or several INVITEÆs (overlap signalling). In some countries there is no way for the server to know whether the called party' number is already complete. If the server relies on the inter-digit time-out to assume that the number is complete, the establishment of the connection is delayed. Alternatively, if the server sends the INVITE request immediately after receiving the INVITE method, heavy signalling traffic may be generated. Therefore, an individual server might implement a timer Haerens Informational 22 SIP-IN Interworking Protocol Februay 2001 and/or a stop digit (such as #). All the digits that arrive before this timer expires will be included in the INVITE sent. The timer can be bypassed by the user sending the stop digit. This timer SHOULD not be larger than 5 seconds. The following signalling indications (3) to (5) treat the case of overlap based on the following procedures. (3) The T_BCSM sends any remaining call information to the Egress server/user (e.g. by means of INVITE request and 484 Address Incomplete responses). Thus, after receiving the INVITE and possibly one or several INVITEÆs, the server issues an INVITE request towards the called user. The "To" field contains the digits received so far. If, after sending this INVITE request, one or more INVITEÆs are received, the server sends a new INVITE to the called user. This new INVITE has the same "From" and "Call-ID" as the previous INVITE sent. The "To" field is updated and contains all the available digits.`484 Address Incomplete' responses will be received for all the INVITEÆs sent with the incomplete called party number. Thus, all the call legs (same `Call-ID', different to) created while the digits are arriving MUST be deleted. (4) An Indication is sent from the T_BCSM to the Egress server/user upon the sending of sufficient call information. This can be done by including a stop digit into the INVITE method sent to the called user. (5) An Indication is sent from the Egress server/user to the T_BCSM upon receipt of sufficient call information (e.g. CallProgress(Progress).Ind Abstract Signalling Primitive SubsequentAddress Abstract Signalling Primitive mapped from 100 Trying). If a provisional response different than 100 Trying arrives (typically a 183 Session Progress) the server SHOULD send all its subsequent INVITEs to the server that generated the response. This avoids in SIP bridging situations sending subsequent INVITEs to different gateways. This would generate several messages in the network for just one call (rather than a one initial address message followed by one or subsequent messages). Therefore, subsequent INVITEÆs would contain an updated To field, the same Call-ID and a Route header built with the Record-route and the Contact headers received in the provisional response. If two or more provisional response are received from a different location it means that the INVITEÆs generated reached different UASÆs.The gateway SHOULD choose which UAS will handle the call and send a BYE specifically addressed to the rest of UASÆs (Record-Route, Contact and tag in the To field). CANCEL SHOULD not be used here because the whole call could be terminated. The server typically SHOULD choose the UAS that returned the provisional response to the INVITE that contained more digits Haerens Informational 23 SIP-IN Interworking Protocol Februay 2001 (6) Egress server/user sends an Indication to the T_BCSM that alerting is taking place (e.g. CallProgress(Alert).Ind Abstract Signalling Primitive mapped from 180 RINGING). (7) An Indication is sent from the Egress server/user to the T_BCSM upon acceptance of the incoming call (e.g. Setup.Conf Abstract Signalling Primitive mapped from 200 OK). (8) An Indication is sent from the T_BCSM to the Egress server/user acknowledging that the call can now be connected. (ACK) (9) An Indication is sent from the Egress server/user to the T_BCSM that the Egress server/user suspends the call.15) This is an INVITE method with a media stream put on hold (10) An Indication is sent from the Egress server/user to the T_BCSM that the Egress server/user resumes the call. This is another INVITE method in order to resume a previous media stream which was put on hold (11) The T_BCSM sends an Indication to the Egress server/user indicating that the calling party has gone on-hook. This is the BYE method sent towards the user. (12) An Indication is received by the T_BCSM from the Egress server/user to end the call. This is a BYE method received from the user. (13) The T_BCSM indicates to the Egress server/user that the call is being disconnected. (14) The Egress server/user acknowledges to the T_BCSM that the call is being disconnected. 7.3. Intra Server BCSM indications The following figure 9 illustrates the communication between two call segments in the CCF/SSF for a basic two-party call, as described in the CCF/SSF Model. It shows the indications that flow between the originating BCSM and terminating BCSM . All possible indications are shown, except for any which may occur at the O- Exception and the T-Exception PICs. Note that these indications are not intended to be mapped to explicit information flows. (1) Initiate T_BCSM after the authority to place the call has been verified. The O_BCSM is currently in the Send_Call PIC. The originating Basic Call Manager has sent the call attempt to the terminating Basic Call Manager for further processing, i.e. the Setup.Req.Ind Abstract Signalling Primitive is sent on the IBI from the O-BCSM to the T_BCSM. (2) An Indication is sent from the T_BCSM to O_BCSM that the terminating user is busy, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T-BCSM to the O_BCSM. (Causes Send_Call PIC to O_Called_Party_Busy BCSM transition in O_BCSM.) (3) An Indication is sent from the T_BCSM to O_BCSM that the terminating user is busy, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T-BCSM to the Haerens Informational 24 SIP-IN Interworking Protocol Februay 2001 O_BCSM. (Causes O_Alerting PIC to O_Called_Party_Busy DP BCSM transition in O_BCSM.) (4) An Indication is sent from the T_BCSM to O_BCSM that the call can not be presented, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T-BCSM to the O_BCSM. (Causes Send_Call PIC to Select_Route PIC, O_Called_Party_Busy DP, or O_No_Answer DP.) (5) An Indication is sent from the T_BCSM to the O_BCSM that an Called Party has signalled call acceptance with immediate BCSM transition to an answered condition,i.e. the Setup.Resp.Conf Abstract Signalling Primitive is sent on the IBI from the T-BCSM to the O_BCSM (causes Send_Call PIC to O_Answer DP BCSM transition in O_BCSM). (6) An Indication is sent from T_BCSM to O_BCSM that Called Party is being alerted i.e. the CallProgress(Alert).Req.Ind Abstract Signalling Primitive is sent on the IBI from the T-BCSM to the O_BCSM (causes O_BCSM to transit from Send_Call PIC O_Alerting PIC and prepare to send 180 RINGING response to the Calling Party). (7) An Indication is sent from T_BCSM to O_BCSM that Called Party has rejected the call, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T-BCSM to the O_BCSM (this is indicated to the O_BCSM with a busy cause and causes O_BCSM to transit from O_Alerting PIC to Select_Route PIC or O_Called_Party_Busy DP). (8) An Indication is sent from T_BCSM to O_BCSM that Called Party has not answered within a specified time period, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T_BCSM to the O_BCSM (causes O_Alerting PIC to O_No_Answer DP BCSM transition in O_BCSM). (9) An Indication is sent from the T_BCSM to the O_BCSM that called party has not answered within a specified time period, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T_BCSM to the O_BCSM. (Causes Send_Call PIC to O_No_Answer DP BCSM transition in O_BCSM.). (10) An Indication is sent from T_BCSM to O_BCSM that Called Party has accepted and answered the call attempt, i.e. the Setup.Resp.Conf Abstract Signalling Primitive is sent on the IBI from the T_BCSM to the O_BCSM (causes O_Alerting PIC to O_Answer DP BCSM transition in O_BCSM). (11) An Indication is sent from the T_BCSM to the O_BCSM that the called party has accepted and answered the call attempt, i.e. the Setup.Resp.Conf Abstract Signalling Primitive is sent on the IBI from the T-BCSM to the O_BCSM. (Causes Send_Call PIC to O_Answer DP BCSM transition in O_BCSM.) Haerens Informational 25 SIP-IN Interworking Protocol Februay 2001 (12) An Indication is sent from T_BCSM to O_BCSM that Called Party has disconnected, i.e. the NetworkSuspend.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T_BCSM to the O_BCSM (e.g. on-hook), (causes O_Active PIC to O_Suspend DP BCSM transition in O_BCSM). (13) An Indication is sent from T_BCSM to O_BCSM that Called Party re-answers is received before the timer expires , i.e. the NetworkResume.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T-BCSM to the O_BCSM (causes O_Suspended PIC to O_Re_Answer DP BCSM transition in O_BCSM). (14) An Indication is sent from O_BCSM to T_BCSM that Calling Party has disconnected, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the O_BCSM to the T_BCSM, while T_BCSM was in T_Active PIC (causes T_Active PIC to T_Disconnect DP BCSM transition in T_BCSM). (15) An Indication is sent from O_BCSM to T_BCSM that Calling Party has disconnected, , i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the O_BCSM to the T_BCSM, while T_BCSM was in T_Suspended PIC (causes T_Suspended PIC to T_Disconnect DP BCSM transition in T_BCSM). (16) An Indication is sent from T_BCSM to O_BCSM that Called Party has disconnected, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T_BCSM to the O_BCSM, (causes O_Suspended PIC to O_Disconnect DP BCSM transition in O_BCSM). (17) An Indication is sent from the T_BCSM (T_Disconnect DP) to O_BCSM that the called party has disconnected, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the T_BCSM to the O_BCSM,. (Causes O_Active PIC to O_Disconnect DP BCSM transition in O_BCSM.). (18) An Indication is sent from O_BCSM to T_BCSM that Calling Party has abandoned, i.e. the Release.Req.Ind Abstract Signalling Primitive is sent on the IBI from the O_BCSM to the T_BCSM, (causes Authorize_Termination_Attempt PIC, Select_Facility PIC, Present_Call PIC or T_Alerting PIC to T_Abandoned DP BCSM transition in T_BCSM). NOTE: i) Indications (14) and (16) are mutually exclusive: ii) All indications are for intra-switch; iii) The indications do not explicitly include the modelling of SRFs; iv) Indications which are preceded by a DP may be affected depending on whether the DP is active and the SCF response. Haerens Informational 26 SIP-IN Interworking Protocol Februay 2001 ********************************* * Figure to be provided * ********************************* Figure 9: Intra Server BCSM Indications 7.5. Mapping of 4xx û 6xx responses in SIP to IN Detections Points The mapping of error codes (4xx) û 6xx responses in SIP to the possible Detection Points in PIC Originating and Terminating Call Handling is indicated in the table below. NOTE: since Select_Route PIC is considered as a fall through the DP Select_Route_Failure does not make sense inn the mapping of received SIP responses. Response received from SIP DP mapping to IN ----------------- ---------------------- 400 Bad request O_Exeption or T_Exception 401 Unauthorized Origination_Attempt_Denied or Termination_Attempt_Denied 402 Payment required O_Exeption or T_Exception 403 Forbidden O_Exeption or T_Exception 404 Not found O_Exeption or T_Exception 405 Method not allowed O_Exeption or T_Exception 406 Not acceptable O_Exeption or T_Exception 407 Proxy authentication Origination_Attempt_Denied or required Termination_Attempt_Denied 408 Request timeout O_Exeption or T_Exception 409 Conflict O_Exeption or T_Exception 410 Gone O_Exeption or T_Exception 411 Length required O_Exeption or T_Exception 413 Request Entity too long O_Exeption or T_Exception 414 Request-URI too long O_Exeption or T_Exception 415 Unsupported media type O_Exeption or T_Exception 420 Bad extension O_Exeption or T_Exception 480 Temporarily unavailable O_No_Answer or T_No_Answer 481 Call leg/transaction doesn't exist O_Exeption or T_Exception 482 Loop detected O_Exeption or T_Exception 483 Too many hoops O_Exeption or T_Exception 484 Address incomplete see Section 7 485 Ambiguous O_Exeption or T_Exception 486 Busy here O_Called_Party_Busy or T_Busy 500 Server internal error O_Exeption or T_Exception 501 Not implemented O_Exeption or T_Exception 502 Bad gateway O_Exeption or T_Exception 503 Service unavailable O_Exeption or T_Exception 504 Gateway time-out O_Exeption or T_Exception 505 Version not supported O_Exeption or T_Exception 600 Busy everywhere O_Called_Party_Busy or T_Busy 603 Decline O_Exeption or T_Exception Haerens Informational 27 SIP-IN Interworking Protocol Februay 2001 Note: further study required on the mapping one other possibility could be to map this to O_No_Answer or T_No_Answer 604 Does not exist anywhere O_Exeption or T_Exception 606 Not acceptable O_Exeption or T_Exception The mapping of the error response received from SIP to the cause values of IN based on the ITU-T Q.860 Recommendation is as follows. Response received from SIP Cause value mapping to IN ----------------- ---------------------- 400 Bad request 127 Interworking 401 Unauthorized 21 Call rejected 402 Payment required 21 Call rejected 403 Forbidden 1 Unallocated number 404 Not found 1 Unallocated number 405 Method not allowed 38 Network out of order 406 Not acceptable 58 Bearer capability not presently available 407 Proxy authentication required 21 Call rejected 408 Request timeout 102 Recovery on timer expiry 409 Conflict 41 Temporary failure 410 Gone 1 Unallocated number 411 Length required 127 Interworking 413 Request Entity too long 127 Interworking 414 Request-URI too long 127 Interworking 415 Unsupported media type 79 Service/option not implemented 420 Bad extension 127 Interworking 480 Temporarily unavailable 18 No user responding 481 Call leg/transaction doesn't exist 127 Interworking 482 Loop detected 127 Interworking 483 Too many hoops 127 Interworking 484 Address incomplete --- 485 Ambiguous 1 Unallocated number 486 Busy here 17 User busy 500 Server internal error 41 Temporary failure 501 Not implemented 38 Network out of order 502 Bad gateway 38 Network out of order 503 Service unavailable 41 Temporary failure 504 Gateway time-out 102 Recovery on timer expiry 505 Version not supported 127 Interworking 600 Busy everywhere 17 User busy 603 Decline 21 Call rejected 604 Does not exist anywhere 1 Unallocated number 606 Not acceptable 38 Network out of order The mapping of error codes (4xx) û 6xx received in SIP to the possible Detection Points in PIC Originating and Terminating Call Handling is performed as indicated in the mapping from cause to DP section of the CS3 Core INAP specification ETSI DEN/SPAN-03063-1.2 section 6.3.5 of the SCF-SSF Interface based on the above table. 7.6. Support of mid-call signalling Haerens Informational 28 SIP-IN Interworking Protocol Februay 2001 Pure SIP does not have any provision for carrying any mid-call control information that is generated during. The INFO method SHOULD be used for this purpose. Draft-ietf-sip-info-method-04.txt. Further input will be provided on this topic. 8. Protocol Procedures Topics to be provide are: 8.1. Mapping of SIP messages containing: * Methods (how is the Sip OPTIONS method supported) * 1xx Information messages * 2xx OK * 3xx Redirection * 4xx Messages (integration of section 7.4 with further protocol details) * 5xx Messages (integration of section 7.4 with further protocol details) * 6xx Global Failures (integration of section 7.4 with further protocol details) 8.2. Mapping of SIP URLs 8.3. Mapping of media stream descriptions 8.4. SIP call Forking in Multi-Party Calls 8.5. Third Party Call Control 8.6. Call Transfer 9. Security Considerations Security is a general property which relates to safe and reliable operation. The high level requirements of a secure system are: i) Confidentiality: This is defined in ITU-T Recommendation X.800 as ½ the avoidance of the disclosure of information without the permission of its owner ©. Thus, confidentiality may be considered as a property which ensures that conversations or interactions remain private. ii) Integrity: This is defined in ITU-T Recommendation X.800 as ½the property that data has not been altered or destroyed in an unauthorised manner©. Integrity may then be considered as a property which ensures that operations occur as they are expected to. Haerens Informational 29 SIP-IN Interworking Protocol Februay 2001 iii) Availability: This may be considered as a property relating to the readiness of resources for authorized use. iv) Accountability: This may be considered as a property which ensures that any operational request can be correctly attributed in case of doubt or dispute. The components of an IN system MUST be assembled and operated in such a way as to provide a defined level of security. To assist in this, any interface within the IN functional architecture may have the need to apply security assisting functions to the information flows passing across the interface such as: i) Network access security functions : This includes user/terminal authentication (i.e. the result of a process by which a service user proves his or her identity to an IN system), user profile verification (i.e. the verification that a user is authorised to use a functionality). ii) Internetworking security functions: This includes peer entity authentication (i.e., a process which allows a communicating entity to prove its identity to another entity in the network), signalling data or TMN data integrity, non- repudiation, confidentiality, entity profile verification (i.e. the verification that an entity is authorised to use a functionality). A. Best Current Practice for SIP to IN Mapping To be provided B. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 C. Acknowledgments I thank specially Mr Ray C. Forbes from Marconi Communications Limited for his valuable contribution on the system and network architectural aspects as Co-chair in the ETSI SPAN. Haerens Informational 30 SIP-IN Interworking Protocol Februay 2001 I also thank Hui-Lan Lu, Doris Lebovits, Kamlesh Tewani, Janusz Dobrowloski, Vijay Gurbani, Jack Kozik, Warren Montgomery, Lev Slutsman, Igor Faynberg,Henning Schulzrinne and Jonathan Rosenberg who all contributed to the discussions on the relationship of IN and SIP call models D. Author's Addresses Frans Haerens Alcatel Bell Francis Welles Plein,1 Belgium Phone: +32 3 240 9034 Email: frans.haerens@alcatel.be Haerens Informational 31 SIP-IN Interworking Protocol Februay 2001 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 Informational 32