[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 3976

INTERNET-DRAFT                                     Vijay K. Gurbani
April 2002                                Lucent Technologies, Inc.
Expires: November 2002                                Frans Haerens
                                                       Alcatel Bell
                                                      Vidhi Rastogi
                                                 Wipro Technologies

Document: draft-gurbani-sin-01.txt
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.

   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.

Abstract

   The aim of the SIP/IN Interworking (SIN) IETF design team 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.

   The design team work items are:

         o Interpreting IN Call Models for the SIP environment
         o Mapping IN messages into (sequences of) SIP messages and vice
           versa
         o Mapping IN parameters into SIP parameters and vice versa
         o Defining SIP extensions, if necessary



draft-gurbani-sin-01.txt                                       [Page 1]

SIN Protocol Architecture and Procedures                        May 2002


   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
   one or more Informational RFCs that will be the major output of the
   design team. This draft is the first output of the IETF SIN design
   team and addresses the first work item.  It outlines the architecture
   and procedures of SIP-IN (SIN) Internetworking as well as establishes
   the call model mapping between the IN Call Model and the SIP protocol
   state machine.

   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.

Applicability Statement

   The mechanism described in this draft provides a transparent manner
   for accessing (Intelligent Network) IN services in the PSTN from SIP
   endpoints.  It does not represent a general model for providing of
   services within SIP.  The mechanism described in this draft is
   applicable when:

     1. The request for an IN service is initiated from a SIP endpoint.

     2. Data pertaining to an IN service resides on the the PSTN.

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 [1].

   Table of Contents
   1   Architectural Model........................................... 3
   2   Requirements for IN-interaction with SIP-based systems........ 6
   2.1 The concept of state in SIP................................... 6
   2.2 SIN issues.................................................... 6
   2.3 SIP REGISTER and IN services.................................. 7
   3   The SIP-IN Protocol Architecture.............................. 7
   3.1 Introduction.................................................. 7
   3.2 IN Service control based on the SIN approach.................. 8
   4   Mapping examples of SIP message to the IN State Models........ 8
   4.1 Mapping SIP protocol state machine to O_BCSM..................10
   4.2 Mapping SIP protocol state machine to T_BCSM..................15
   5   Support for mid-call signaling................................20
   6   Example call flows............................................20



draft-gurbani-sin-01.txt                                       [Page 2]

SIN Protocol Architecture and Procedures                        May 2002


   7   Security considerations.......................................21
   Appendix A........................................................21
   List of Acronyms..................................................22
   Normative references..............................................23
   Informative references............................................23
   Acknowledgements..................................................23
   Changes from previous drafts......................................23

1. Architecture Model

   The intent of this draft is to provide means to support existing IN-
   based applications in a SIP-based IP environment.  One way to gain
   access to IN services transparently (i.e., through the same detection
   points (DPs) and point-in-call (PIC) used by traditional switches)
   from SIP is to map the SIP protocol state machine to the IN call
   models.

   We first explain the basics of IN.  Figure 1 shows a simplified IN
   architecture, in which telephone switches, called Service Switching
   Points (SSPs), are connected via a packet network called Signaling
   System No. 7 (SS7) to Service Control Points (SCPs), which are
   general purpose computers.  At certain points in a call, a switch can
   interrupt a call and request instructions from an SCP. The points
   where a call can be interrupted are standardized within the Basic
   Call State Model (BCSM) [3].  The BCSM models contains two processes,
   one each for the originating and terminating part of a call.  When
   the SCP gets an request for instructions, it can reply with a single
   response, such a simple number translation augmented by criteria like
   time of day or day of week, or, in turn, get into a complex dialog
   with the switch.  The situation is further complicated by the
   necessity to engage other specialized devices, which collect digits,
   play recorded announcement, perform text-to-speech or speech-to-text
   conversion, etc.  (These devices are not discussed here.) The related
   protocol as well as the BCSM is standardized by the ITU-T and known
   as the Intelligent Network Application Part Protocol (INAP).  Only
   the protocol, but not an SCP API, have been standardized.

                                +-----------+
                                |           |
                                |    SCP    |
                                |           |
                                +-----------+
                                      |
                                      |
                                     / \
                                   /     \
                                 /  INAP   \
                                /           \



draft-gurbani-sin-01.txt                                       [Page 3]

SIN Protocol Architecture and Procedures                        May 2002


                               /             \
                        +--------+  ISUP   +--------+
                        |  SSP   |*********|  SSP   |
                        +--------+         +--------+

                        Figure 1. Simplified IN Architecture

   From the viewpoint of IN elements like the SCP, the fact that the
   request originated from a SIP entity versus a call processing
   function on a traditional switch is immaterial.  Thus, it is
   important that the SIP entity be able to provide features normally
   provided by the traditional switch, including operating as a SSP for
   IN features.  The SIP entity should also maintain call state and
   trigger queries to IN-based services, just as traditional switches
   do.

   It is not the intent of this draft to specify which SIP entity shall
   operate as a SSP; however, for the sake of completeness it should be
   mentioned that this job can be performed by SIP entities at (or near
   the) core of the network instead of the SIP end points themselves.
   To that extent, SIP entities like proxy servers and Back-to-Back UAs
   (B2BUAs) may be employed.  Generally speaking, proxy servers can be
   used for IN services that occur during a call setup or teardown.  For
   IN services requiring media handling (DTMF), B2BUAs or proxies that
   actively control media gateways will be needed.

   The most expeditious manner for providing existing IN services in the
   IP domain would be to use the deployed IN infrastructure as much as
   possible.  The logical point in SIP to tap into for accessing
   existing IN services is either the UAs or one of the proxy located
   physically closest to the UA (and presumably in the same
   administrative domain as the UA).  However SIP entities do not run an
   IN call model; to transparently access IN services, the trick then,
   is to overlay the state machine of the SIP entity with an IN layer
   such that call acceptance and routing is performed by the native
   state machine and services are accessed through the IN layer using an
   IN call model. This document proposes such a mapping.  Such an IN-
   enabled SIP entity, operating in synchrony with the events occurring
   at the SIP transaction level and interacting with the IN elements
   (SCP) is depicted in Figure 2:

                        +-------+
                        | SCP   |
                        +---+---+
                            |
                            | INAP
                            |
                        +--------+



draft-gurbani-sin-01.txt                                       [Page 4]

SIN Protocol Architecture and Procedures                        May 2002


                        | SIN    |
                        +........+
                        |  SIP   |
             ---------->| Entity |--------->
             Requests   |        | Requests out
             in         +--------+ (after applying IN
                                    services)

            Figure 2: SIP Entity accessing IN services

   Figure 3 expands the SIP entity depicted in Figure 2 and further
   shows the architecture model involving IN and SIP interworking. The
   architecture model for accessing IN from SIP entities should have a
   minimal support for implementing services that require explicit
   handling of the call configuration. The following capabilities are
   considered:


        (1) Number translation services including the storage of related
            information (time of day) for e.g. portability and free
            phone based services

        (2) Redirection services

        (3) Virtual Private Network services


   It should be noted that the single SIP entity as modeled in this
   figure can in fact represent several different physical instances in
   the network, for example with one SIP entity in charge of the
   terminal or access network/domain, and another in charge of the
   interface to the Switched Circuit Network (SCN).

                   +-------+
                   |  SCP  |
                   +---o---+
                       |
                       +-----+
                             |
                   **********|***********************************
                   * +-------|-------------------+              *
                   * |+------o------+            |              *
                   * ||  SSF(IP)    |            |              *
                   * |+-------------+            |              *
                   * ||  CCF(IP)    |            |              *
                   * |+------o------+            |              *
                   * +-------|-------------------+              *
                   *         |                      SIN-enabled *



draft-gurbani-sin-01.txt                                       [Page 5]

SIN Protocol Architecture and Procedures                        May 2002


                   * +-------o-------------------+  SIP         *
                   * |      SIP Layer            |  Entity      *
                   * +---------------------------+              *
                   **********************************************


      Figure 3: Functional architecture of an SIN-enabled SIP entity

   The following architecture entities, used in Figure 3, are defined in
   the Intelligent Network standards:

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

2.  Requirements for IN-interaction with SIP-based systems.

   When interworking between Internet Telephony and IN-PSTN networks,
   the main issue is to translate between the states produced by the
   Internet Telephony signaling and those used in traditional IN
   environments.

     2.1 The concept of state in SIP

     In a SIP call, UAs (including B2BUAs) maintain call state.  If IN-
     services are provided from SIP proxies, the Record-Route mechanism
     can be used to put these SIP entities in call-stateful mode.

     2.2 SIN issues

     When interworking between Internet Telephony and IN, it is useful
     to have a common understanding of how to translate from the states
     produced by SIP signaling to those produced by IN signaling.

     In this model, each SIP entity is pre-configured to communicate
     with one logical SCP server, using whatever communication mechanism
     is appropriate.  As Figures 1 and 2 depict, the IN-portion of the
     SIN-enabled SIP entity will communicate with the SCP.  This
     interface between the IN call handling layer and the SCP is not
     specified by this draft and indeed, can be any one of the following
     depending on the interfaces supported by the SCP: INAP over IP,
     INAP over SIGTRAN, INAP over TALI or INAP over SS7.

     This draft is only applicable when SIP-controlled Internet
     telephony devices are to interoperate with PSTN devices.  The SIP



draft-gurbani-sin-01.txt                                       [Page 6]

SIN Protocol Architecture and Procedures                        May 2002


     UAs using this interface would typically appear together with a
     media gateway.  It is *not* applicable in an all-IP network and is
     not needed where PSTN media gateways (not speaking SIP) need to
     communicate with SCPs.

     2.3 SIP REGISTER and IN services

     SIP REGISTER provisions a SIP Proxy or SIP Registration server. The
     process is similar to the provisioning of an SCP/HLR in the
     switched circuit network. SCPs which provide VoIP based services
     can directly leverage this information. However, this draft neither
     endorses or prohibits such an architecture, and in fact, considers
     it an implementation decision.

3. The SIP-IN Protocol Architecture.

   3.1 Introduction

   The SIP architecture has the following functional elements defined in
   [2]:
        - 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, rewrites 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.

        - 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



draft-gurbani-sin-01.txt                                       [Page 7]

SIN Protocol Architecture and Procedures                        May 2002


          from a particular UAC, including those requests whose Request-
          URIs 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.

        - Back-to-Back UA (B2BUA): An SIP entity that receives a request
          and processes it as a UAS.  It also acts as a UAC and
          generates requests in order to determine how the incoming
          request is to be answered.  A B2BUA maintains complete dialog
          state and must participate in all request sent within the
          dialog.

   3.2 IN Service control based on the SIN approach

   Figure 4 depicts the possibility of IN service control based on the
   SIN approach. On both, the originating and terminating ends, a SIN-
   capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O
   SIP" entity is required for outgoing calls that require legacy
   service support based on existing IN services.  Likewise, on the
   callee's side (or terminating side), an equally configured entity ("T
   SIP") will be required to provide terminating side services.  Note
   that the "O SIP" and "T SIP" entities correspond, respectively, to
   the IN O_BCSM and T_BCSM halves of the IN call model.


     +---+                                                       +---+
     | S |                    (~~~~~~~~~~~~~)                    | S |
     | C |<--+               (               )               +-->| C |
     | P |   |              (                 )              |   | P |
     +---+   |             (   Switched        )             |   +---+
             |             (   Circuit         )             |
             V             (   Network         )             V
      +-------+            (                   )          +-------+
      | SIN   |    +---------+           +---------+      | SIN   |
      +-------+----| Gateway |    ...    | Gateway |------+-------+
      | O SIP |    +---------+           +---------+      | T SIP |
      +-------+             (                 )           +-------+
                             (               )
                              (.............)

     O SIP: Originating SIP entity
     T SIP: Terminating SIP entity

     Figure 4: Overall SIN architecture.



4. Mapping examples of SIP message to the IN State Models



draft-gurbani-sin-01.txt                                       [Page 8]

SIN Protocol Architecture and Procedures                        May 2002


   This section establishes the mapping of the SIP protocol state
   machine to the IN generic basic call state model (BCSM), independent
   of any capability sets [4].  The BCSM is divided into two halves - an
   originating call model (O_BCSM) and a terminating call model
   (T_BCSM).  There are a total of 19 PICs and 35 DPs between both the
   halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for T_BCSM)
   [3].  The SSPs, SCPs and other IN elements track a call's progress in
   terms of the basic call model.  The basic call model provides a
   common context for communication about a call.

   O_BCSM has 11 PICs.  These are:

     O_NULL: starting state; call does not exist yet.
     AUTH_ORIG_ATTEMPT: switch detects a call setup request.
     COLLECT_INFO: switch collects the dial string from the calling
     party.
     ANALYZE_INFO: complete dial string is translated into a routing
     address.
     SELECT_ROUTE: physical route is selected, based on the routing
     address.
     AUTH_CALL_SETUP: switch ensures the calling party is authorize to
     place call.
     CALL_SENT: control of call send to terminating side.
     O_ALERTING: switch waits for the called party to answer.
     O_ACTIVE: connection established; communication ensue.
     O_DISCONNECT: connection torn down.
     O_EXCEPTION: switch detected an exceptional condition.

   T_BCSM has 8 PICS.  These are:

     T_NULL: starting state; call does not exist yet.
     AUTH_TERM_ATT: switch verifies whether call can be send to
     terminating party.
     SELECT_FACILITY: switch picks a terminating resource to send the
     call on.
     PRESENT_CALL: call is being presented to the called party.
     T_ALERTING: switch alerts the called party, e.g. ringing the line.
     T_ACTIVE: connection established; communications ensue.
     T_DISCONNECT: connection torn down.
     T_EXCEPTION: switch detected an exceptional condition.

   The state machine for O_BCSM and T_BCSM is provided in [3] page 98
   and 103 respectively.  This state machine will be used for subsequent
   discussion when the IN call states are mapped into SIP.

   The next two sections contain the mapping of the SIP protocol state
   machine to the IN BCSMs.  It is beyond the scope of this document to
   explain all PICs and DPs in an IN call model.  It is assumed that the



draft-gurbani-sin-01.txt                                       [Page 9]

SIN Protocol Architecture and Procedures                        May 2002


   reader has some familiarity with the PICs and DPs of the IN call
   model.  More information can be found in [3].  For a quick reference,
   Appendix A contains a mapping of the DPs to the SIP response codes as
   discussed in the next two sections.

   4.1 Mapping SIP protocol state machine to O_BCSM

   The 11 PICs of O_BCSM come into play when a call request (SIP INVITE
   message) arrives from an upstream SIP client to an originating SIN-
   enabled SIP entity running the IN call model.  This entity will
   create a O_BCSM object and initialize it in the O_NULL PIC.  The next
   seven IN PICs -- O_NULL, AUTH_ORIG_ATT, COLLECT_INFO, ANALYZE_INFO,
   SELECT_ROUTE, AUTH_CALL_SETUP, and CALL_SENT -- can all be mapped to
   the SIP "Calling" state.

   Figure 5 below provides a visual mapping from the SIP protocol state
   machine to the originating half of the IN call model.  Note that
   control of the call shuttles between the SIP protocol machine and the
   IN O_BCSM call model while it is being serviced.
































draft-gurbani-sin-01.txt                                      [Page 10]

SIN Protocol Architecture and Procedures                        May 2002


                 SIP                                      O_BCSM

                | INVITE
                V
           +---------+                        +---------------+
           | Calling +=======================>+ O_NULL        +<----+
           +--+---/\-+                        +-/\---+--------+     |
           |  |   ||    +-------------+         |    |              |
           |  |   ||<===+O_Exception  +---------+ +--V-+         +--+-+
           |  |   ||    +--/\---------+           |DP 1|         |DP21|
           |  |   ||       |    +----+      +-----+----+------+  +--+-+
           |  |   ||       +<---+DP 2|<-----+ Auth_Orig._Att  +---->+
           |  |   ||       |    +----+      +--------+--------+     |
           |  |   ||       |                         |              |
           |  |   ||       |                      +--V-+            |
           |  |   ||       |                      |DP 3|            |
           |  |   ||       |    +----+      +-----+----+------+     |
           |  |   ||       +<---+DP 4|<-----+ Collect_Info    +---->+
           |  |   ||       |    +----+      +--------+--------+     |
           |  |   ||       |                         |              |
           |  |   ||       |                      +--V-+            |
           |  |   ||       |                      |DP 5|            |
           |  |   ||       |    +----+      +-----+----+------+     |
           |  |   ||       +<---+DP 6|<-----+ Analyze_Info    +---->+
           |  |   ||       |    +----+      +--------+--------+     |
           |  |   ||       |                         |              |
           |  |   ||       |                      +--V-+            |
           |  |   ||       |                      |DP 7|            |
           |  |   ||       |    +----+      +-----+----+------+     |
           |  |   ||       +<---+DP 8|<-----+ Select_Route    +---->+
           |  |   ||       |    +----+      +--------+--------+     |
           |  |   ||       |                         |              |
           |  |   ||       |                      +--V-+            |
           |  |   ||       |                      |DP 9|            |
           |  |   ||       |    +----+      +-----+----+------+     |
           |  |   ||       +<---+DP10|<-----+ Auth._Call_Setup+---->+
           |  |   ||            +----+      +--------+--------+
      +----+  |   ||                                 |
      |       |   ||                              +--V-+
      |       |   ||                              |DP11|
      |   1xx |   ||                        +-----+----+------+
      |       |   ++========================+ Call_Sent       |
      |       |                             +----/\----+------+
      |       |     On 100,180,2xx process DP14  ||      |
      |       |     On 3xx, process DP12         ||      |
      |       V     On 486, process DP13         ||      |
      |    +--+-------+ On 5xx, 6xx and 4xx      ||      |
      |    |Proceeding| (except 486) process DP21||      |



draft-gurbani-sin-01.txt                                      [Page 11]

SIN Protocol Architecture and Procedures                        May 2002


      |    +-+-+------+<=========================++      |
      |      | |                                         |
      |      | |                                         |
      |      | |                                         |
      |      | +--200------------------+                 |
      |      +----4xx to 6xx--------+  |                 |
      |                             |  |              +--V-+
      | On DPs 21, 2, 4, 6, 8, 10   |  |              |DP14|
      | send 4xx-6xx final response |  |     +--------+----+--+
      +-------+                     |  |     | O_Alerting     |
              |                     |  |     +---------+------+
           +--V-------+             |  |               |
           |Completed |<------------+  |            +--V-+
           +--+-------+                |            |DP16|
              |                        |     +------+----+----+
           +--V-------+                |   +-+ O_Active       |
           |Terminated|<---------------+   | +-------------+--+
           +----------+                    |               |
                                     +-----+            +--V-+
                                     |                  |DP19|
                                  +--V-+       +--------+----+
                                  |DP17|       | O_Disconnect|
                                  +--+-+       +-------------+
                                     |
                                     V
                                To O_EXCEPTION
           Legend:

           | Communication between
           | states in the same
           V protocol

           ======> Communication between IN layer and SIP protocol
                   state machine to transfer call state

           Figure 5: Mapping from SIP to O_BCSM


   The SIP "Calling" protocol state has enough functionality to absorb
   the seven PICs as described below:

     O_NULL - This PIC is basically a fall through state to the next
     PIC, AUTHORIZE_ORIGINATION_ATTEMPT.

     AUTHORIZE_ORIGINATION_ATTEMPT - In this PIC, the IN layer  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



draft-gurbani-sin-01.txt                                      [Page 12]

SIN Protocol Architecture and Procedures                        May 2002


     to authorize the calling party using a set of policy directives
     configured by the SIP administrator. If the called party is
     authorized to place the call, the IN layer is instructed to enter
     the next PIC, COLLECT_INFO through DP 3
     (Origination_Attempt_Authorized).  If for some reaon, the call
     cannot be authorized, DP 2 (Origination_Denied) is processed and
     control transfers to the SIP state machine.  The SIP state machine
     must format and send a non-2xx final response (possibly 403) to the
     upstream entity.

     COLLECT_INFO - This PIC is responsible for collecting a dial string
     from the calling party and verifying the format of the string.  If
     overlap dialing is being used, this PIC can invoke DP 4
     (Collect_Timeout) and transfer control to the SIP state machine,
     which will format and send a non-2xx final response (possibly a
     484).  If the dial string is valid, DP 5 (Collected_Info) is
     processed and the IN layer is instructed to enter the next PIC,
     ANALYZE_INFO.

     ANALYZE_INFO - This PIC is responsible for translating the dial
     string to a routing number.  Many IN service such as freephone, LNP
     (Local Number Portability), OCS (Originating Call Screening), etc.
     occur during this PIC. The IN layer can use the Request-URI of the
     SIP INVITE request for analysis. If the analysis succeeds, the IN
     layer is instructed to enter the next PIC, SELECT_ROUTE.  If the
     analysis failed, DP 6 (Invalid_Info) is processed and the control
     transfers to the SIP state machine, which will generate a non-2xx
     final response (possibly one of 400, 401, 403, 404, 405, 406, 410,
     414, 415, 416, 485, or 488) and send it to the upstream entity.

     SELECT_ROUTE - In the circuit-switched network, the actual physical
     route has to be selected at this point.  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 entity can use a protocol like TRIP [5] to find the best
     gateway to egress the request onto the PSTN.  If a successful route
     is selected, the IN call model moves to PIC AUTH_CALL_SETUP via DP
     9 (Route_Selected).  Otherwise, the control transfers to the SIP
     state machine via DP 8 (Route_Select_Failure), which will generate
     a non-2xx final response (possibly 488) and send it to the upstream
     entity.

     AUTH_CALL_SETUP - Certain service features 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 no such
     restrictions are encountered, the IN call model moves to PIC
     CALL_SENT via DP 11 (Origination_Authorized).  If a restriction is



draft-gurbani-sin-01.txt                                      [Page 13]

SIN Protocol Architecture and Procedures                        May 2002


     encountered that prohibits further processing of the call, DP 10
     (Authorization_Failure) is processed and control is transferred to
     the SIP state machine, which will generate a non-2xx final response
     (possibly 404, 488, 502).  Otherwise, DP 11
     (Origination_Authorized) is processed and the IN layer is
     instructed to enter the next PIC, CALL_SENT.

     CALL_SENT - At this point, the request needs to be sent to the
     downstream entity; and the IN layer waits for a signal confirming
     that either the call has been presented to the called party or that
     a called party cannot be reached for a particular reason.  The
     control is transferred to the SIP state machine. The SIP state
     machine should now sent the call to the next downstream server
     determined in PIC SELECT_ROUTE.  The IN call model now blocks until
     unblocked by the SIP state machine.

     If the above seven PICs have been successfully negotiated, the
     SIN-enabled SIP entity now sends the SIP INVITE message to the next
     hop server.  Further processing now depends on the provisional
     responses (if any) and the final response received by the SIP
     protocol state machine.  The core SIP specification does not
     guarantee the delivery of 1xx responses, thus special processing is
     needed at the IN layer to transition to the next PIC (O_ALERTING)
     from the CALL_SENT PIC.  The special processing needed for
     responses while the SIP state machine is in the "Proceeding" state
     and the IN layer is in the "CALL_SENT" state is described next.

        A 100 response received at the SIP state machine elicits no
        special behavior in the IN layer.

        A 180 response received at the SIP entity enables the processing
        of DP 14 (O_Term_Seized), however, a state transition to
        O_ALERTING is not undertaken yet.  Instead, the IN layer is
        instructed to remain in the CALL_SENT PIC until a final response
        is received.

        A 2xx response received at the SIP entity enables the processing
        of DP 14 (O_Term_Seized), and the immediate transition to the
        next state, O_ALERTING (processing in O_ALERTING is described
        later).

        A 3xx response received at the SIP entity enables the processing
        of DP 12 (Route_Failure).  The IN call model from this point
        goes back to the SELECT_ROUTE PIC to select a new route for the
        contacts in the 3xx final response (not shown in Figure 5 for
        brevity).

        A 486 (Busy Here) response received at the SIP entity enables



draft-gurbani-sin-01.txt                                      [Page 14]

SIN Protocol Architecture and Procedures                        May 2002


        the processing of DP 13 (O_Called_Party_Busy) and resources for
        the call are released at the IN call model.

        If the SIN-enabled SIP entity gets a 4xx (except 486), 5xx, or
        6xx final response, DP 21 (O_Calling_Party_Disconnect &
        O_Abandon) is processed and control passes to the SIP state
        machine.  Since a call was not successfully established, both
        the IN layer and the SIP state machine can release resources for
        the call.

     O_ALERTING - This PIC will be entered as a result of receiving a
     200-class response.  Since a 200-class response to an INVITE
     indicates acceptance, this PIC is mostly a fall through to the next
     PIC, O_ACTIVE via DP 16 (O_Answer).

     O_ACTIVE - At this point, the call is active.  Once in this state,
     the call may get disconnected only when one of the following three
     events occur: (1) the network connection fails, (2) the called
     party disconnects the call, or (3) the calling party disconnects
     the call.  If event (1) occurs, DP 17 (O_Connection_Failure) is
     processed and call control is transferred to the SIP protocol state
     machine.  Since the network failed, there is not much sense in
     attempting to send a BYE request; thus both the SIP protocol state
     machine and the IN call layer should release all resources
     associated with the call and initialize themselves to the null
     state.  The occurrence of event (2) results in the processing of DP
     19 (O_DISCONNECT) and a move to the last PIC, O_DISCONNECT.  Event
     (3) would be caused by the calling party proactively terminating
     the call.  In this case, DP 21 (O_Abandon &
     O_Calling_Party_Disconnect) will be processed and control passed to
     the SIP protocol state machine.  The SIP protocol state machine
     must send a BYE request and wait for a final response.  The IN
     layer releases all its resources and initializes itself to the null
     state.

     O_DISCONNECT - When the SIP entity gets a BYE request, the IN layer
     is instructed to move to the last PIC, O_DISCONNECT via DP19.  A
     final response for the BYE is generated and transmitted by the SIP
     entity and the call resources are freed by both the SIP protocol
     state machine as well as the IN layer.


   4.2 Mapping SIP protocol state machine to T_BCSM

   The T_BCSM object is created when a SIP INVITE message makes its way
   to the terminating SIN-enabled SIP entity.  This entity creates the
   T_BCSM object and initializes it to the T_NULL PIC.




draft-gurbani-sin-01.txt                                      [Page 15]

SIN Protocol Architecture and Procedures                        May 2002


   Figure 6 below provides a visual mapping from the SIP protocol state
   machine to the terminating half of the IN call model:

















































draft-gurbani-sin-01.txt                                      [Page 16]

SIN Protocol Architecture and Procedures                        May 2002


                 SIP                                      T_BCSM

              | INVITE
              V
         +----------+                          +------------+
         |Proceeding+=========================>+ T_Null     +<-------+
         +-+--+--/\-+                          +/\----+-----+        |
           |  |  ||        +-----------+        |     |              |
           |  |  ||<=======+T_Exception+--------+  +--V-+         +--+-+
           |  |  ||        +-/\--------+           |DP22|         |DP35|
           |  |  ||          |    +----+       +---+----+------+  +--+-+
           |  |  ||          +<---+DP23|<------+Auth._Term._Att+---->+
           |  |  ||          |    +----+       +------+--------+     |
           |  |  ||          |                        |              |
           |  |  ||          |                     +--V-+            |
           |  |  ||          |                     |DP24|            |
           |  |  ||          |    +----+       +---+----+------+     |
           |  |  ||          +<---+DP25|<------+Select_Facility+---->+
           |  |  ||          |    +----+       +------+--------+     |
           |  |  ||          |                        |              |
           |  |  ||          |                     +--V-+            |
           |  |  ||          |                     |DP26|            |
           |  |  ||          |    +----+       +---+----+------+     |
           |  |  ||          +<---+DP27|<------+ Present_Call  +---->+
           |  |  ||          |    +----+       +------+--------+     |
           |  |  ||          |                        |              |
           |  |  ||          |                     +--V-+            |
           |  |  ||          |                     |DP28|            |
           |  |  ||          |    +----+       +---+----+------+     |
           |  |  ||          +<---+DP29|<------+ T_Alerting    +---->+
           |  |  ||          |    +----+       +-/\--+---------+     |
           |  |  ||          +<--------------+   ||   |              |
           |  |  ||                          |   ||   |              |
           |  |  ++==========================|===++   |              |
           |  |  /\                  +-------+     +--V-+            |
           |  |  ||                  |             +DP30|            |
           |  |  ||                +-+--+      +---+----+------+     |
           |  |  ||                |DP31+<-----| T_Active      +---->+
           |  |  ||                +----+      +-/\-----+------+
           |  |  ||                              ||      |
           |  |  ||                              ||      |
      2xx  |  |  ++==============================++      |
      sent |  |                                          |
      +----+  | 3xx - 6xx response                    +--V-+
      |       | sent                                  |DP33|
      |  +----V-----+                          +------+----+----+
      |  |Completed |                          | T_Disconnect   |
      |  +----+-----+                          +----------------+



draft-gurbani-sin-01.txt                                      [Page 17]

SIN Protocol Architecture and Procedures                        May 2002


      |       |
      |       | ACK received
      |       |
      |  +----V-----+
      |  |Confirmed |
      |  +----+-----+
      |       |
      +------>|
              |
         +----V-----+
         |Terminated|
         +----------+

           Legend:

           | Communication between
           | states in the same
           V protocol
           ======> Communication between IN call model and SIP
                   protocol state machine to transfer call state

           Figure 6: Mapping from SIP to T_BCSM

   The SIP "Proceeding" state has enough functionality to absorb the
   first five PICS -- T_Null, Authorize_Termination_Attempt,
   Select_Facility, Present_Call, T_Alerting -- as described below:


     T_NULL - At this PIC, the terminating end creates the call at the
     IN layer.  The incoming call results in the processing of DP 22,
     Termination_Attempt, and a transition to the next PIC,
     AUTHORIZE_TERMINATION_ATTEMPT, takes place.

     AUTHORIZE_TERMINATION_ATTEMPT - In this PIC, the fact that the
     called party wishes to receive the call is ascertained and that the
     facilities of the called party are compatible with that of the
     calling party.  If any of these conditions is not met, DP 23
     (Termination_Denied) is invoked and the call control is transferred
     to the SIP protocol state machine.  The SIP protocol state machine
     can format and send a non-2xx final response (possibly 403, 405,
     415, or 480).  If the conditions of the PIC are met, processing of
     DP 24 (Termination_Authorized) is invoked anda transition to the
     next PIC, SELECT_FACILITY, takes place.

     SELECT_FACILITY - The intent of this PIC in circuit switched
     networks is to select a line or trunk to reach the called party.
     Since lines or trunks are not applicable in an IP network, a SIN-
     enabled SIP entity can use this PIC to interface with a PSTN



draft-gurbani-sin-01.txt                                      [Page 18]

SIN Protocol Architecture and Procedures                        May 2002


     gateway and select a line/trunk to route the call.  If the called
     party is busy, or a line/trunk can not be thus seized, the
     processing of DP 25 (T_Called_Party_Busy) is invoked, followed by a
     transition of the call to the SIP protocol state machine.  The SIP
     protocol state machine must format and send a non-2xx final
     response (possibly 486 or 600).  If a line/trunk was successfully
     seized, the processing of DP 26 (Terminating_Resource_Available) is
     invoked and a transition to the next PIC, PRESENT_CALL, takes
     place.

     PRESENT_CALL - At this point, the call is being presented (via the
     ISUP ACM message, or Q.931 Alerting message, or simply by ringing a
     POTS phone).  If there was an error presenting the call, the
     processing of DP 27 (Presentation_Failure) is invoked and the call
     control is transferred to the SIP protocol state machine.  The SIP
     protocol state machine must format and send a non-2xx final
     response (possibly 480).  If the call was successfully presented,
     the processing of DP 28 (T_Term_Seized) is invoked and a transition
     to the next PIC, T_ALERTING, takes place.

     T_ALERTING - At this point, the called party is being "alerted".
     Control now passed momentarily to the SIP protocol state machine,
     so it can generate and send a "180 Ringing" response to its peer.
     Furthermore, since network resources have been allocated for the
     call, timers are set to prevent indefinite holding of such
     resources.  The expiration of the relevant timers result in the
     processing of DP 29 (T_No_Answer) and the call control is
     transferred to the SIP protocol state machine.  The SIP protocol
     state machine must format and send a non-2xx final response
     (possibly 408).  If the called party answers, then DP 30 (T_Answer)
     is processed, followed by a transition to the next PIC, T_ACTIVE.

   The rest of the PICs after the above five have been negotiated are
   mapped as follows:

   T_ACTIVE - The call is now active.  Once this state is reached, the
   call may become inactive only under one of the following three
   conditions: (1) the network fails the connection, (2) the called
   party disconnects the call, or (3) the calling party disconnects the
   call.  Event (1) results in the processing of DP 31
   (T_Connection_Failure) and call control is transferred to the SIP
   protocol state machine.  Since the network failed, there is not much
   sense in attempting to send a BYE request; thus both the SIP protocol
   state machine and the IN call layer should release all resources
   associated with the call and initialize themselves to the null state.
   Event (2) results in the processing of DP 33 (T_Disconnect) and a
   transition to the next PIC, T_DISCONNECT.  Event (3) would be caused
   by the receipt of a BYE request at the SIP protocol state machine



draft-gurbani-sin-01.txt                                      [Page 19]

SIN Protocol Architecture and Procedures                        May 2002


   (not shown in Figure 6).  Resources for the call should be
   deallocated and the SIP protocol state machine must send a 200 OK for
   the BYE request (not shown in Figure 6).

   T_DISCONNECT - In this PIC, the disconnect treatment associated with
   the called party's having disconnected the call is performed at the
   IN layer.  The SIP protocol state machine sends out a BYE and awaits
   a final response for the BYE (not shown in Figure 6).

5. Support of mid-call signaling

   The core SIP specification does not have any provision for carrying
   mid-call control information that may be generated. The INFO method
   SIP extension or the SUBSCRIBE/NOTIFY SIP extensions can be
   considered for services requiring mid-call signaling.

6. Example call flows

   Two examples are provided here to understand how SIP protocol state
   machine and the IN call model work synchronously with each other.

   In the first example, a SIP UAC originates a call request destined to
   a 800 freephone number:

      INVITE sip:18005551212@lucent.com SIP/2.0
      From: sip:16309795218@il0015vkg1.ih.lucent.com;tag=991-7as-66ff
      To: sip:18005551212@lucent.com
      Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
      Call-ID: 67188121@lucent.com
      CSeq: 1 INVITE

   The request makes its way to the originating SIP network server
   running an IN call model.  The SIP network server hands, at the very
   least, the To: field and the From: field to the IN layer for
   freephone number translation.  The IN layer proceeds through its PICs
   and in the ANALYSE_INFO PIC consults the SCP for freephone
   translation.  The translated number is returned to the SIP network
   server, which forwards the message to the next hop SIP proxy, with
   the freephone number replaced by the translated number:

      INVITE sip:16302240216@lucent.com SIP/2.0
      From: sip:16309795218@il0015vkg1.ih.lucent.com;tag=991-7as-66ff
      Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
      Via: SIP/2.0/UDP sip-in1.ih.lucent.com
      To: sip:18005551212@lucent.com
      Call-ID: 67188121@lucent.com
      CSeq: 1 INVITE




draft-gurbani-sin-01.txt                                      [Page 20]

SIN Protocol Architecture and Procedures                        May 2002


   In the next example, a SIP UAC originates a call request destined to
   a 900 number:

      INVITE sip:19005551212@lucent.com SIP/2.0
      From: sip:16302240216@lucent.com;tag=991-7as-66dd
      To: sip:19005551212@lucent.com
      Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
      Call-ID: 88112@lucent.com
      CSeq: 1 INVITE

   The request makes its way to the originating SIP network server
   running an IN call model.  The SIP network server hands, at the very
   least, the To: field and the From: field to the IN layer for 900
   number translation.  The IN layer proceeds through its PICs and in
   the ANALYSE_INFO PIC consults the SCP for the translation.  During
   the translation, the SCP detects that the originating party is not
   allowed to make 900 calls.  It passes this information to the
   originating SIP network server, which informs the SIP UAC using SIP
   "403 Forbidden" response status code:

      SIP/2.0 403 Forbidden
      From: sip:16302240216@lucent.com;tag=991-7as-66dd
      To: sip:19005551212@lucent.com;tag=78K-909II
      Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com
      Call-ID: 88112@lucent.com
      CSeq: 1 INVITE

7. Security Considerations

   Security considerations for SIN services span both the networks being
   used, namely, the PSTN and the Internet.  SIN uses the security
   measures in place for both the networks.  With reference to Figure 2,
   the INAP messages between the SCP and the SIN-enabled SIP entity must
   be secured by the signaling transport used between the SCP and the
   SIN-enabled entity.  Likewise, the requests coming into the SIN-
   enabled SIP entity must first be authenticated, and if the need be,
   encrypted as well using the means and procedures defined in [2] for
   SIP requests.

Appendix A: 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.  The reason phrase in the 4xx-6xx
   response is reproduced from [2].






draft-gurbani-sin-01.txt                                      [Page 21]

SIN Protocol Architecture and Procedures                        May 2002



           SIP response code             DP mapping to IN
           -----------------             ----------------------
           200 OK                        DP 14
           3xx                           DP 12
           403 Forbidden                 DP 2,  DP 21
           484 Address Incomplete        DP 4,  DP 21
           400 Bad Request               DP 6,  DP 21
           401 Unauthorized              DP 6,  DP 21
           403 Forbidden                 DP 6,  DP 21, DP 23
           404 Not Found                 DP 6,  DP 21
           405 Method Not Allowed        DP 6,  DP 21, DP 23
           406 Not Acceptable            DP 6,  DP 21
           408 Request Timeout           DP 29
           410 Gone                      DP 6,  DP 21
           414 Request-URI Too Long      DP 6,  DP 21
           415 Unsupported Media Type    DP 6,  DP 21, DP 23
           416 Unsupported URI Scheme    DP 6,  DP 21
           480 Temporarily Unavailable   DP 23, DP 27
           485 Ambiguous                 DP 6,  DP 21
           486 Busy Here                 DP 13, DP 21, DP 25
           488 Not Acceptable Here       DP 6,  DP 21
           488 Not Acceptable Here       DP 8,
           404 Not Found                 DP 10, DP 21
           488 Not Acceptable Here       DP 10, DP 21
           502 Bad Gateway               DP 10, DP 21
           600 Busy Everywhere           DP 21, DP 25


List of Acronyms

   B2BUA       Back-to-Back User Agent
   BCSM        Basic Call State Machine
   CCF         Call Control Function
   DP          Detection Point
   DTMF        Dual Tone Modulated Frequency
   IN          Intelligent Network
   INAP        Intelligent Network Access Protocol
   IP          Internet Protocol
   ITU-T       International Telecommunications Union - Telephony
   O_BCSM      Originating Basic Call State Machine
   PSTN        Public Switched Telephone Network
   SCF         Service Control Function
   SCP         Service Control Point
   SIN         SIP/IN Interworking
   SIP         Session Initiation Protocol
   SS7         Signaling System 7
   SSF         Service Switching Function



draft-gurbani-sin-01.txt                                      [Page 22]

SIN Protocol Architecture and Procedures                        May 2002


   SSP         Service Switching Point
   T_BCSM      Terminating Basic Call State Machine
   UA          User Agent

Normative References

   1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997
   2  Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo,
      Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley,
      and Eve Schooler, "SIP: Session Initiation Protocol",
      Internet I-D, Work in Progress, expires August 2002.
      <http://www.ietf.org/internet-drafts/draft-ietf-sip-
      rfc2543bis-09.txt>

Informative References

   3  I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The
      Intelligent Network Standards: Their Application to
      Services," McGraw-Hill, 1997.
   4  ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network
      Distributed Functional Plane Architecture," International
      Telecommunications Union Standardization Section, Geneva.
   5  Jonathan Rosenberg, Hussein Salama, and Matt Squire,
      "Telephony Routing over IP (TRIP)", IETF RFC 3219, January,
      2002 <http://www.ietf.org/rfc/rfc3219.txt>

Acknowledgments

   The authors would like to 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.  Special
   thanks to Hui-Lan Lu for acting as the chair of the SIN DT and ensuring
   the focus of the DT did not veer too far.  Thanks also to Doris Lebovits,
   Kamlesh Tewani, Janusz Dobrowloski, 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.

Changes from previous drafts

      Changes to draft-gurbani-sin-01.txt
      . Added list of acronyms
      . Took out table on "Cause value mappings" -- lot of this mapping is
        specified in SIP/ISUP the mapping draft.
      . Added Applicability Statement.

      Changes since draft-ietf-sin-manyfolks-01.txt



draft-gurbani-sin-01.txt                                      [Page 23]

SIN Protocol Architecture and Procedures                        May 2002


      . Renamed to <draft-gurbani-sin-00.txt>; reverted back to -00
      . Incorporates DT Last Call comments
      . Massive modifications of Figure 5 and 6 -- reflects more of an
        en event driven view
      . Updated references
      . Added TOC

      Changes since -01
      . Renamed to <draft-ietf-sin-manyfolks-00.txt>; reverted back to -00.
      . Major re-write of the original F. Haerens I-D.

      Changes since -00
      . Included SIP/IN Call Model mapping as described in a now expired I-D
        ("Accessing IN Services from SIP networks
        <draft-gurbani-iptel-sip-to-in-04.txt>)
      . Included comments from ETSI obtained by Frans Haerens.
      . Not all changes discussed on the SIN DT email list have been
        included - stay tuned for -02 coming up after 51st IETF.

Author's Addresses

   Vijay K. Gurbani
   Lucent Technologies, Inc.
   2000 Lucent Lane, Rm 6G-440
   Naperville, Illinois 60566
   USA
   Phone: +1 630 224 0216
   Email: vkg@lucent.com

   Frans Haerens
   Alcatel Bell
   Francis Welles Plein,1
   Belgium
   Phone: +32 3 240 9034
   Email: frans.haerens@alcatel.be

   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

   Full Copyright Statement:
   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



draft-gurbani-sin-01.txt                                      [Page 24]

SIN Protocol Architecture and Procedures                        May 2002


   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











































draft-gurbani-sin-01.txt                                      [Page 25]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/