SIP Working Group F.Haerens Internet Draft Alcatel Bell Vijay K. Gurbani Lucent Technologies Vidhi Rastogi Wipro Technologies Document: draft-haerens-sip-in-01.txt Expires: January 2002 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 SIP-IN Interworking Protocol Expires: Jan 2002 the informational draft that will be the major output of the design team. 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 (v) OA&M functions 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 | |SCF|<------------+ |Transport | |Proxy/Redirect...| +-+-+<-----+ | |Gateway | | Server | SIP-IN Interworking Protocol Expires: Jan 2002 | | | | | | | and | | +-+-+ | | | | |Bearer Controller| +-+-+ |SRF| | | | | | +----+ | |SSF| +->| |<-+ | | | | | |SSF | | | | | +-+-+ | +---|---|------|-----|->|(IP)| | +---+---- | | | | | | +----+----+ | | |<----+ | | | | | | | | |CCF|<--------------|-----|---|------|-----|------>|CCF | | ==| |===============|=====|==========|=====|=======|(IP)|====|== +---+<-------+ | | | | +---|------>+--o-+ | | | +---|------+ | +----------|------+ | | | | | Call/Bearer | | +---|------+ | | Layer | | | +--+ | | +----o---+ | +-----|->|MG|<---|-+ RTP | | +------------|->| |<---|---------->| SIP | | +--+ | | TE UA | | Media | | | | Gateway | +--------+ +---|------+ | A MRF box need to be added having a Megaco interface to the CCF and a RTP media stream. 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. SIP-IN Interworking Protocol Expires: Jan 2002 SRF should be added 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: (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. 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) A sub-function of 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 ii) 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). iii) 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 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 SIP-IN Interworking Protocol Expires: Jan 2002 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. 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. 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. SIP-IN Interworking Protocol Expires: Jan 2002 (iii) CCF(IP)-to-Media Manager (MG) interface 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 SIP-IN Interworking Protocol Expires: Jan 2002 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 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 the following functional elements defined in [4]: - User agent client: The SIP functional entity that initiates a request. - User agent server: The SIP functional entity that terminates a request by sending 0 or more provisional SIP responses and one final SIP response. - Proxy server: An intermediary SIP entity that can act as both a UAS and a UAC. Acting as a UAS, it accepts requests from UACs, re- writes the R-URI,and,acting as a UAC, proxies the request to a downstream UAS. Proxies may retain significant call control state by inserting them-selves in future SIP transactions beyond the initial INVITE. SIP-IN Interworking Protocol Expires: Jan 2002 - Redirect server: An intermediary SIP entity that redirects callers to alternate locations, after possibly consulting a location server to determine the exact location of the callee (as specified in the R-URI) - Registrar: An SIP entity that accepts SIP REGISTER requests and maintains a binding from a high-level URL to the exact location for a user. This information is saved in some data-store that is also accessible to a SIP Proxy and a SIP Redirect server. A Registrar is usually co-located with a SIP Proxy or a SIP Redirect server. - Outbound proxy: An SIP proxy that is located near the originator of requests. It receives all outgoing requests from a particular UAC, including those requests whose Request-URLs identify a host other than the outbound proxy. The outbound proxy sends these requests, after any local processing, to the address indicated in the Request-URI. 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 organized 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-----+ | | SIP-IN Interworking Protocol Expires: Jan 2002 | | | | | | |+-----o-----+ | | | ||CCF(IP) | | | | Intelligent |+-----o-----+ | | | Network | | | | | Protocol | | | | | +------|-------+ | +--------------------|---------+ | +------o----+ | SIP/SDP | +-----------+ / \ +-------+ +---------+ | TCP | | UDP | +-------+ +---------+ / \ +----------------------+ | 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| SIP-IN Interworking Protocol Expires: Jan 2002 (......) (....+--------+ Figure 3: Proposed functional protocol Architecture for SIP-IN interaction. 5.3 Basic concepts for In service triggering The following assumptions 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. 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 SIP-IN Interworking Protocol Expires: Jan 2002 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. The users who 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. 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 SIP Proxy 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. {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. SIP-IN Interworking Protocol Expires: Jan 2002 (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--------+ | | | | | | [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 | SIP-IN Interworking Protocol Expires: Jan 2002 | | | +--------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 will be sent during 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. +-----------+ +--------+ +-----------+ |Originating| |Extended| |Terminating| | UAC | |Proxy | UAS | +-----------+ +--------+ +-----------+ | | | | INVITE [1] [2] | +-----------------+ o--------------->o-------------------------| T_Null | | | | +--------o--------+ | | | | | 100 Trying | | +--------o--------+ |<---------------o | | Authorize_ | | | | | Termination_ | | | | | Attempt | SIP-IN Interworking Protocol Expires: Jan 2002 | | | +--------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 5: 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: {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. SIP-IN Interworking Protocol Expires: Jan 2002 +-----------+ +--------+ +-----------+ |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 NOTE: This section is based on the information contained in [3] and has been extended as follows: 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. SIP-IN Interworking Protocol Expires: Jan 2002 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 between IN call states and SIP states. 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 proxy will create a O_BCSM object and initialize it into the O_NULL PIC. In the AUTH_ORIG_ATT PIC, a SIP proxy 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 calling party is authorized to place the call, the BCSM transits to the next PIC, COLLECT_INFO. This COLLECT_INFO PIC is responsible for collecting a dial string from the calling party. The SIP proxy can detect an incomplete address (e.g. by inter digit timeout or by digit analysis) 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 a subsequent 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 INVITE represents a different transaction than the initial INVITE; consequently, there is no relationship between the CSeq values in the two INVITE messages. Once it has obtained a valid dial string, the BCSM transits to the next PIC, ANALYZE_INFO. The ANALYZE_INFO PIC can either generate the 100 TRYING if the analyzed information function has been performed successfully, or like the COLLECT_INFO PIC, it may also cause the SIP proxy to send a _484 Address Incomplete_ response (e.g. by inter digit timeout or by digit analysis) and remain in this state until a valid "dial string' is received via a subsequent INVITE method. This PIC is ultimately responsible for translating the dial string to a routing number. Many IN services such as freephone, LNP, OCS, etc. are triggered from DP's associated with this PIC. The SIP proxy can send the SIP URI in the To: field to the IN layer to have it analyzed. If the analysis succeeds, the BCSM transits to the next PIC, SELECT_ROUTE. The next PIC encountered is SELECT_ROUTE. In the circuit-switched network, the actual physical route has to be selected at this point. SIP-IN Interworking Protocol Expires: Jan 2002 The SIP analogue of this would be to determine the next hop SIP server. The next hop SIP server could be chosen by a variety of means. For instance, if the Request URI in the incoming INVITE request is an E.164 number, the SIP proxy can use a protocol like TRIP to find the best gateway to egress the request onto the GSTN. 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 proxy 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 at 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_, a _183 Session Progress_, or a _100 Trying_ message is received, control stays in this PIC. When the SIP proxy running the IN call layer gets back a "180 Ringing" for the call, it instructs the BCSM to transit to 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 proxy running the IN layer receives a "200 OK". The receipt of this message is followed by the SIP proxy instructing the BCSM to transit to the next PIC, O_ACTIVE. The call is now active. When either of the party hangs up, the SIP proxy 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 BCSM to transit to 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--------+ SIP-IN Interworking Protocol Expires: Jan 2002 (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) ===============>| | (12) ===============>| | +-o------o--+----++ (16) <=================|======|==| | O_Re-AnswerDP | | +---+ +--------+ | | ^ (13) ===>|O_Discon|<---+ | | (14) <===|nectDP |<---+ | | +---- ---+ | +-V--+ | (15) <=================|====| | | O_SuspendDP +-o--- +----+-o---+ (8) <===============| O_SUSPENDED PIC | (9) ===============>| | (12) ===============>| | +-----------------+ SIP-IN Interworking Protocol Expires: Jan 2002 Legend: | Communication between | states V ======> Communication between IN layer and SIP Figure 7: Mapping of the SIP methods to O_BCSM Note: ABANDON should be included 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. 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) SIP-IN Interworking Protocol Expires: Jan 2002 (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 proxy initializes T_BCSM object it to the T_NULL PIC. The T BCSM transits to 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 BCSM transits to the next PIC, SELECT_FACILITY. The intent of this PIC, in traditional circuit networks, is to select a line or a trunk to reach the called party. In a hybrid (GSTN/IP) network, where the callee resides on the GSTN, a SIP proxy can use SELECT_FACILITY PIC to interface with a gateway and select a line/trunk to route the call. If a facility was thus successfully seized, the SIP INVITE request is deemed to be successful and control enters the next PIC, PRESENT_CALL. In a traditional circuit-switched network, PRESENT_CALL presents (via ISUP IAM or Q.931 Setup messages) the call to the called party. When the SIP proxy sends out the INVITE to the UAS, it instructs the BCSM to transit to this state. The BCSM will remain in this state until the SIP proxy gets back a "180 Ringing", whereupon it instructs the BCSM to enter the next state, T_ALERTING. SIP-IN Interworking Protocol Expires: Jan 2002 T_ALERTING "alerts" the called party by ringing the phone. When the SIP proxy receives a "200 OK", it instructs the BCSM to enter the next PIC, T_ACTIVE. The call is now active. When either of the party hangs up, the SIP proxy 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 proxy instructs the BCSM to transit to the next PIC, T_DISCONNECT and perform cleanup. Subsequently, the state of the call in the SIP proxy 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) | | +--------o--------+ +---------+ | +--------V--------+ | T_ACTIVE PIC |================> (8) | |================> (11) | |--------+ ++---+---o--------+ | T_Re-AnswerDP | | |<================|======== (9) +---+ | | ^ | | |<====|========================== (10) | | | | +-V--+ | SIP-IN Interworking Protocol Expires: Jan 2002 | | | 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 T-Abandon should be included 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 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) An indication is sent from the T_BCSM to forward 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 SIP-IN Interworking Protocol Expires: Jan 2002 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 CANCEL specifically addressed to the rest of UAS's (Record-Route, Contact and tag in the To field). The server typically SHOULD choose the UAS that returned the provisional response to the INVITE that contained more digits (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 SIP-IN Interworking Protocol Expires: Jan 2002 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 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 SIP-IN Interworking Protocol Expires: Jan 2002 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.) (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). SIP-IN Interworking Protocol Expires: Jan 2002 (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. ********************************* * 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. SIP-IN Interworking Protocol Expires: Jan 2002 Response received from SIP DP mapping to IN ----------------- ---------------------- 400 Bad request Route_Select_Failure or T_Exception 401 Unauthorized Origination_Attempt_Denied or Termination_Attempt_Denied 402 Payment required Route_Select_Failure or T_Exception 403 Forbidden Route_Select_Failure or T_Exception 404 Not found Route_Select_Failure or T_Exception 405 Method not allowed Route_Select_Failure or T_Exception 406 Not acceptable Route_Select_Failure or T_Exception 407 Proxy authentication Origination_Attempt_Denied or required Termination_Attempt_Denied 408 Request timeout O_Exeption or T_Exception 409 Conflict Route_Select_Failure or T_Exception 410 Gone Route_Select_Failure or T_Exception 411 Length required Route_Select_Failure or T_Exception 413 Request Entity too long Route_Select_Failure or T_Exception 414 Request-URI too long Route_Select_Failure or T_Exception 415 Unsupported media type Route_Select_Failure or T_Exception 420 Bad extension Route_Select_Failure or T_Exception 480 Temporarily unavailable O_No_Answer or T_No_Answer 481 Call leg/transaction doesn't exist Route_Select_Failure or T_Exception 482 Loop detected Route_Select_Failure or T_Exception 483 Too many hoops Route_Select_Failure or T_Exception 484 Address incomplete see Section 7 485 Ambiguous Route_Select_Failure or T_Exception 486 Busy here O_Called_Party_Busy or T_Busy 500 Server internal error Route_Select_Failure or T_Exception 501 Not implemented Route_Select_Failure or T_Exception 502 Bad gateway Route_Select_Failure or T_Exception 503 Service unavailable Route_Select_Failure or T_Exception 504 Gateway time-out O_Exception or T_Exception 505 Version not supported Route_Select_Failure or T_Exception 600 Busy everywhere O_Called_Party_Busy or T_Busy 603 Decline Route_Select_Failure or T_Exception 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 Route_Select_Failure or T_Exception 606 Not acceptable Route_Select_Failure or T_Exception The mapping of the error response received from SIP to the cause values of IN based on the ITU-T Q.850 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 63 Service/option SIP-IN Interworking Protocol Expires: Jan 2002 unavailable 406 Not acceptable 79 Service/option not implemented 407 Proxy authentication required 21 Call rejected 408 Request timeout 102 Recovery on timer expiry 409 Conflict 48 Temporary failure 410 Gone 22 Number changed 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 480 Temporarily unavailable 20 Subscriber absent 481 Call leg/transaction doesn't exist 127 Interworking 482 Loop detected 127 Interworking 483 Too many hoops 25 Exchange-routing error 484 Address incomplete 28 Invalid Number Format 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 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) SIP-IN Interworking Protocol Expires: Jan 2002 * 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 . Integrity may then be considered as a property which ensures that operations occur as they are expected to. 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. SIP-IN Interworking Protocol Expires: Jan 2002 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 3 Gurbani, V., Rastogi, V., "Accessing IN Services from SIP Networks", IETF I-D, Work in Progress, http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip- to-in-04.txt, expires August 2001 4 M. Handley, H. Schulzrinne, J. Rosenberg, E. Schooler, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 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. 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. Changes Changes since -00 . Included SIP/IN Call Model mapping as described in [3]. . Included comments from ETSI obtained by Frans Haerens. SIP-IN Interworking Protocol Expires: Jan 2002 . Not all changes discussed on the SIN DT email list have been included - stay tuned for -02 coming up after 51st IETF. E. Author's Addresses Frans Haerens Alcatel Bell Francis Welles Plein,1 Belgium Phone: +32 3 240 9034 Email: frans.haerens@alcatel.be Vijay K. Gurbani Lucent Technologies, Inc. 263 Shuman Blvd, Rm 1A-413 Naperville, Illinois 60532 USA Phone: +1 630 224 0216 Email: vkg@lucent.com Vidhi Rastogi Wipro Technologies 271, Sri Ganesha Complex Hosur Main Road, Madiwala Bangalore - 560 068, INDIA Phone: +91 80 5539701 Email: vidhi.rastogi@wipro.com SIP-IN Interworking Protocol Expires: Jan 2002 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