Internet DRAFT - draft-haerens-sip-in

draft-haerens-sip-in





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 <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.

   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