draft-gurbani-sin-02.txt  -->   rfc3976.txt

view Side-By-Side changes






INTERNET-DRAFT                                     Vijay





Network Working Group                                      V. K. Gurbani
June 2002
Request for Comments: 3976                     Lucent Technologies, Inc.
Expires: December 2002                                Frans
Category: Informational                                       F. Haerens
                                                            Alcatel Bell
                                                      Vidhi
                                                              V. Rastogi
                                                      Wipro Technologies

Document: draft-gurbani-sin-02.txt
Category: Informational
                                                            January 2005


       Interworking SIP and Intelligent Network (IN) Applications


Status of this This Memo

   This document is memo provides information for the Internet community.  It does
   not specify an Internet-Draft and is in full conformance with
   all provisions of Section 10 Internet standard of RFC2026.

   Internet-Drafts are working documents any kind.  Distribution of the this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Engineering
   Task Force (IETF), its areas, and its working groups. Society (2005).

IESG Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for

   This RFC is not a maximum candidate for any level of six months
   and may be updated, replaced, or obsoleted by other documents at Internet Standard.  The
   IETF disclaims any
   time.  It is inappropriate knowledge of the fitness of this RFC for any
   purpose, and in particular notes that the decision to use Internet-Drafts publish is not
   based on IETF review for such things as reference
   material security, congestion control,
   or to cite them other than as "work in progress." inappropriate interaction with deployed protocols.  The list of current Internet-Drafts can be accessed RFC Editor
   has chosen to publish this document at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list its discretion.  Readers of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.
   this document should exercise caution in evaluating its value for
   implementation and deployment.  See RFC 3932 for more information.

Abstract

   Public Switched Telephone Network (PSTN) services such as 800 number 800-number
   routing (freephone), time-and-day routing, credit-card calling, and
   virtual private network (mapping a private network number into a
   public number) are realized by the Intelligent Network (IN).  This
   draft
   document addresses means to support existing IN services from Session
   Initiation Protocol (SIP) endpoints for an IP-host-to-phone call.
   The call request is originated on a SIP endpoint, but the services to
   the call are provided by the data and procedures resident in the
   PSTN/IN.  To provide IN services in a transparent manner to SIP



draft-gurbani-sin-02.txt                                       [Page 1]

Interworking SIP and Intelligent Network (IN) Applications     June 2002
   endpoints, this draft document describes the mechanism for interworking SIP
   and Intelligent Network Application Part (INAP).





Gurbani, et al.              Informational                      [Page 1]

RFC 3976                 Interworking SIP & IN              January 2005


Table of Contents
   1  INTRODUCTION.................................................. 3

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2  ACCESS TO IN-SERVICES FROM A
   2.  Access to IN-Services from a SIP ENTITY....................... Entity. . . . . . . . . . . .  4
   3  ADDITIONAL
   3.  Additional SIN CONSIDERATIONS................................. Considerations  . . . . . . . . . . . . . . . .  7
       3.1
       3.1.  The concept Concept of state State in SIP.............................. SIP. . . . . . . . . . . . . . .  7
       3.2
       3.2.  Relationship between SCP and a SIN-enabled SIP entity.... 8
       3.3 SIN-Enabled SIP entity. .  7
       3.3.  SIP REGISTER and IN services............................. services . . . . . . . . . . . . . .  8
       3.4
       3.4.  Support of announcements Announcements and mid-call signaling.......... Mid-Call Signaling. . . . .  8
   4  THE
   4.  The SIN ARCHITECTURE.......................................... 9
       4.1 Definitions.............................................. 9
       4.2 Architecture . . . . . . . . . . . . . . . . . . . . .  8
       4.1.  Definitions. . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.  IN Service control based Control Based on the SIN approach.............10
   5  MAPPING OF THE SIP STATE MACHINE TO THE IN STATE MODEL........11
       5.1 Mapping SIP protocol state machine to O_BCSM.............12
       5.2 Approach . . . . . .  9
   5.  Mapping SIP protocol state machine to T_BCSM.............17
   6  EXAMPLE CALL FLOWS............................................22
   7  SECURITY CONSIDERATIONS.......................................23
   Appendix A.......................................................23
   Normative References.............................................24
   Informative References...........................................24
   Acknowledgments..................................................25
   Changes from previous drafts.....................................25
   Author's addresses...............................................26

List of Acronyms

   B2BUA       Back-to-Back User Agent
   BCSM        Basic Call the SIP State Model
   CCF         Call Control Function
   DP          Detection Point
   DTMF        Dual Tone Multi-Frequency Machine to the IN          Intelligent Network
   INAP        Intelligent Network Application Part
   IP          Internet Protocol
   ITU-T       International Telecommunications Union - Telecommunications
               Standardization Sector
   O_BCSM      Originating Basic Call State Model
   PIC         Point in Call
   PSTN        Public Switched Telephone Network
   RTP         Real Time Protocol
   R-URI       Request URI
   SCF         Service Control Function
   SCP         Service Control Point
   SIGTRAN     Signal Transport Working Group in IETF
   SIN         SIP/IN Interworking . . . . 10
       5.1.  Mapping SIP         Session Initiation Protocol



draft-gurbani-sin-02.txt                                       [Page 2]

Interworking State Machine to O_BCSM . . . . . . 11
       5.2.  Mapping SIP and Intelligent Network (IN) Applications     June 2002


   SS7         Signaling System  No. 7
   SSF         Service Switching Function
   SSP         Service Switching Point Protocol State Machine to T_BCSM      Terminating Basic . . . . . . 16
   6.  Example Call State Model
   UA          User Agent
   UAC         User Agent Client
   UAS         User Agent Server
   VoIP        Voice over IP
   VPN         Virtual Private Network

1 Flows . . . . . . . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 21
       8.2.  Informative References . . . . . . . . . . . . . . . . . 22
       Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
       Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 24
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25

1.  Introduction

   PSTN services such as 800 number 800-number routing (freephone), time-and-day
   routing, credit-card calling, and virtual private network (mapping a
   private network number into a public number) are realized by the
   Intelligent Network.  IN is an architectural concept for the real-
   time execution of network services and customer applications [1].  IN
   is, by design, de-coupled from the call processing component of the
   PSTN.  In this draft, document, we describe the means to leverage this
   decoupling to provide IN services from SIP-based entities.

   We first

   First, we will explain the basics of IN.  Figure 1 shows a simplified
   IN architecture, in which telephone switches, switches called Service Switching
   Points (SSPs), (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 on how to
   proceed with the call.  The points where at which a call can be interrupted
   are standardized within the Basic Call State Model (BCSM) [1, 2].
   The BCSM models contains contain two processes, one each for the originating
   and terminating part of a call.





Gurbani, et al.              Informational                      [Page 2]

RFC 3976                 Interworking SIP & IN              January 2005


   When the SCP gets an receives a request for instructions, it can reply with a
   single response, such as a simple number translation augmented by
   criteria like time of day or day of week, or, in turn, get into initiate a
   complex dialog with the switch.  The situation is further complicated
   by the necessity to engage other specialized devices, which devices that collect
   digits, play recorded announcement, announcements, perform text-to-speech or
   speech-to-text conversion, conversions, etc.  (These devices are not discussed
   here.)  The related protocol protocol, as well as the BCSM BCSM, is standardized by
   the ITU-T and known as the Intelligent Network Application Part
   protocol (INAP) [4].  Only the protocol, not an SCP API, have has been
   standardized.








draft-gurbani-sin-02.txt                                       [Page 3]

Interworking SIP and Intelligent Network (IN) Applications     June 2002

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

                  Figure 1.  Simplified IN Architecture

   The overall objective is to ensure that IN control of Voice over IP
   (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
   connects to present or future networks, simplifies service evolution
   from present to future, and leads to more rapid implementation.

   The rest of this draft document is organized as follows: Section 2 contains
   the architectural model of an IN aware SIP entity.  Section 3
   provides some issues to be taken into account when performing SIP/IN
   interworking (SIN).  Section 4 discusses the IN service control based
   on the SIN approach.  The technique outlined in this draft document focuses
   on the call models of IN and the SIP protocol state machine; section 5, Section
   5 thus establishes a complete mapping between the two state machines
   which
   that allows for access to IN services from SIP endpoints.  Section 6
   includes call flows of IN services executing on SIP endpoints.  These
   services are readily enabled by the technique described in this
   draft.  Finally, section this
   document.  Finally, Section 7 covers security aspects of SIN.



Gurbani, et al.              Informational                      [Page 3]

RFC 3976                 Interworking SIP & IN              January 2005


List of Acronyms

   B2BUA       Back-to-Back User Agent
   BCSM        Basic Call State Model
   CCF         Call Control Function
   DP          Detection Point
   DTMF        Dual Tone Multi-Frequency
   IN          Intelligent Network
   INAP        Intelligent Network Application Part
   IP          Internet Protocol
   ITU-T       International Telecommunications Union -
               Telecommunications Standardization Sector
   O_BCSM      Originating Basic Call State Model
   PIC         Point in Call
   PSTN        Public Switched Telephone Network
   RTP         Real Time Protocol
   R-URI       Request URI
   SCF         Service Control Function
   SCP         Service Control Point
   SIGTRAN     Signal Transport Working Group in IETF
   SIN         SIP/IN Interworking
   SIP         Session Initiation Protocol
   SS7         Signaling System  No. 7 covers security aspects of SIN.

2
   SSF         Service Switching Function
   SSP         Service Switching Point
   T_BCSM      Terminating Basic Call State Model
   UA          User Agent
   UAC         User Agent Client
   UAS         User Agent Server
   VoIP        Voice over IP
   VPN         Virtual Private Network

2.  Access to IN-services IN-Services from a SIP entity Entity

   The intent of this draft document is to provide the means to support
   existing IN-
   based IN-based applications in a SIP [3] environment.  One way to
   gain access to IN services transparently (i.e., from SIP (e.g., 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 [1].

   From the viewpoint of IN elements like such as the SCP, the fact that the
   request originated request's
   origin from a SIP entity versus rather than a call processing function on a
   traditional switch is immaterial.  Thus, it is



draft-gurbani-sin-02.txt                                       [Page 4]

Interworking SIP and Intelligent Network (IN) Applications     June 2002 important that the SIP
   entity be able to provide the same features normally
   provided by as the traditional
   switch, including operating as a an SSP for IN features.  The SIP
   entity should also maintain call state and trigger queries to IN-based IN-
   based services, just as do traditional switches
   do.

   It is switches.



Gurbani, et al.              Informational                      [Page 4]

RFC 3976                 Interworking SIP & IN              January 2005


   This document does not the intent of this draft intend to specify which SIP entity shall
   operate as a an SSP; however, for the sake of completeness completeness, it should
   be mentioned that this task should be performed by SIP entities at
   (or
   near the) near) the core of the network instead of rather than at the SIP end points
   themselves.  To that extent, SIP entities like such as proxy servers and
   Back-to-Back UAs user agents (B2BUAs) may be employed.  Generally
   speaking, proxy servers can be used for IN services that occur during
   a call setup and teardown.  For IN services requiring specialized
   media handling (such as DTMF detection), detection) or specialized call control
   (such as placing parties on hold), hold) B2BUAs will be required.

   The most expeditious manner for providing existing IN services in the
   IP domain is to use the deployed IN infrastructure as much often as
   possible.  The  In SIP, the logical point in SIP to tap into for accessing
   existing IN services is either the UAs user agents or one of the proxy located proxies
   physically closest to the UA user agent (and presumably in the same
   administrative domain as the UA).  However domain).  However, SIP entities do not run an IN call
   model; to transparently access IN services, services transparently, the trick then, then is to
   overlay the state machine of the SIP entity with an IN layer
   such so that
   call acceptance and routing is performed by the native state machine
   and so that services are accessed through the IN layer by using an IN
   call model.  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) (SCP), is depicted in Figure 2:





















draft-gurbani-sin-02.txt                                       [Page 5]

Interworking SIP and Intelligent Network (IN) Applications     June 2002

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

            SIN: SIP/IN Interworking layer

            Figure 2: 2.  SIP Entity accessing Accessing IN services Services

   Section 5 proposes such a this mapping between the IN layer and the SIP
   protocol state machine.  Essentially, a SIP entity exhibiting such a this
   mapping becomes a SIN-enabled SIP entity.




Gurbani, et al.              Informational                      [Page 5]

RFC 3976                 Interworking SIP & IN              January 2005


   This draft document does not propose any extensions to SIP.

   Figure 3 expands the SIP entity depicted in Figure 2 and further
   details the architecture model involving IN and SIP interworking.
   Events occurring at the SIP layer will be passed to the IN layer for
   service application.  More specifically, since IN services deal with
   E.164 numbers, it is reasonable to assume that a SIN-enabled SIP
   entity that wants seeks to provide services on such a number will consult
   the IN layer for further processing, thus acting as a SIP-based SSP.
   The IN layer will proceed through its BCSM states, and states and, at appropriate
   points in the call, will send queries to the SCP for call
   disposition.  Once a decision has been made on the disposition of the
   call, call has been determined,
   the SIP layer is so informed and it processes the transaction accordingly.

   It should be noted

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








draft-gurbani-sin-02.txt                                       [Page 6]

Interworking SIP and Intelligent Network (IN) Applications     June 2002

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

     Figure 3: 3.  Functional architecture Architecture of an SIN-enabled a SIN-Enabled SIP entity 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.




Gurbani, et al.              Informational                      [Page 6]

RFC 3976                 Interworking SIP & IN              January 2005


         Call Control Function (CCF): IN functional entity that refers
         to call and connection handling in the classical sense (e.g. (i.e.,
         that of an exchange).

3

3.  Additional SIN considerations

   When interworking Considerations

   In working 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.
   Such a translation entails attention to the considerations listed
   below.

     3.1

3.1.  The concept Concept of state State in SIP

   IN services occur within the context of a call; i.e. either call, i.e., during call
   setup, call teardown, or in the middle of a call.  SIP entities such
   as proxies, where with which some of these services may be realized,
   typically run in transaction- stateful transaction-stateful (or stateless) mode.  In
     such a this
   mode, a SIP proxy that proxied the initial INVITE is not



draft-gurbani-sin-02.txt                                       [Page 7]

Interworking SIP and Intelligent Network (IN) Applications     June 2002 guaranteed
   to receive a subsequent request, such as a BYE.  Fortunately, SIP has
   primitives to force proxies to run in a call-
     stateful call-stateful mode; namely,
   the Record-Route header.  This header forces the UAC user agent client
   (UAC) and UAS user agent server (UAS) to create a "route set" which that
   consists of all intervening proxies through which subsequent request requests
   must traverse.  Thus SIP proxies must run in call- stateful call-stateful mode in
   order to provide IN services on behalf of the UAs.

   A B2BUA is another SIP element where in which IN services can be realized.
     Since
   As a B2BUA is a true SIP UA, it maintains complete call state and is
   thus capable of providing IN services.

     3.2

3.2.  Relationship between SCP and a SIN-enabled SIN-Enabled SIP entity Entity

   In the architecture model proposed in this draft, document, each SIN-enabled
   SIP entity is pre-configured to communicate with one logical SCP
   server, using whatever communication mechanism is appropriate.
   Different SIP servers (e.g., those in different administrative
   domains) may communicate with different SCP servers, so that there is
   no single SCP server responsible for all SIP servers.

   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 document
   and, indeed, can be any one of the following following, depending on the
   interfaces supported by the SCP: INAP over IP, INAP over SIGTRAN, or
   INAP over SS7.





Gurbani, et al.              Informational                      [Page 7]

RFC 3976                 Interworking SIP & IN              January 2005


   This draft document is only applicable when SIP-controlled Internet
   telephony devices are seek to inter-operate operate with PSTN devices.  The SIP UAs
   using this interface would typically appear together with a media
   gateway.  It  This document is *not* applicable in an all-IP network and
   is not needed in cases where PSTN media gateways (not speaking SIP)
   need to communicate with SCPs.

     3.3

3.3.  SIP REGISTER and IN services 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 that provide VoIP based services can directly leverage
   this information. information directly.  However, this draft document neither endorses or
   nor prohibits such an architecture, and architecture and, in fact, considers it an
   implementation decision.

     3.4

3.4.  Support of announcements Announcements and mid-call signaling Mid-Call Signaling

   Services in the IN such as credit-card calling typically play
   announcements and collect digits from the caller before a call is



draft-gurbani-sin-02.txt                                       [Page 8]

Interworking SIP and Intelligent Network (IN) Applications     June 2002 set
   up.  Playing announcements and collecting digits require the
   manipulation of media streams.  In SIP, proxies do not have access to
   the media data path.  Thus  Thus, such services should be executed in a
   B2BUA.

     While

   Although the SIP specification [3] allows for end points to be put on
   hold during a call, call or for a change of media streams to take place, it
   does not have any primitives to transport other than mid-call control
   information.  This may include transporting DTMF digits, for example.
   Extensions to SIP, such as the INFO method [5] or the SIP event
   notification extension [6] [6], can be considered for services requiring
   mid-call signaling.  Alternatively, DTMF can be transported in RTP
   itself [7].


4

4.  The SIN Architecture

   4.1

4.1.  Definitions

   The SIP architecture has the following functional elements defined in
   [3]:

      -  User agent client: client (UAC): The SIP functional entity that
         initiates a request.

      -  User agent server: server (UAS): The SIP functional entity that
         terminates a request by sending 0 or more provisional SIP
         responses and one final SIP response.




Gurbani, et al.              Informational                      [Page 8]

RFC 3976                 Interworking SIP & IN              January 2005


      -  Proxy server: An intermediary SIP entity that can act as both a User Agent Server (UAS)
         UAS and a User Agent Client (UAC). UAC.  Acting as a UAS, it accepts requests from UACs,
         rewrites the Request-URI (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 themselves 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) R-URI).

      -  Registrar: An A 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 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.




draft-gurbani-sin-02.txt                                       [Page 9]

Interworking SIP and Intelligent Network (IN) Applications     June 2002

      -  Outbound proxy: An A SIP proxy that is located near the originator of
         requests.  It receives all outgoing requests from a particular
         UAC, including those requests whose R-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 R-URI.

      -  Back-to-Back UA (B2BUA): An A 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 requests sent within the dialog.

   4.2

4.2.  IN Service control based Control Based on the SIN approach Approach

   Figure 4 depicts the possibility of IN service control based on the
   SIN approach.  On both, 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 support for
   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.








Gurbani, et al.              Informational                      [Page 9]

RFC 3976                 Interworking SIP & IN              January 2005


     +---+                                                       +---+
     | 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: 4.  Overall SIN architecture.





draft-gurbani-sin-02.txt                                      [Page 10]

Interworking SIP and Intelligent Network (IN) Applications     June 2002


5 Architecture

5.  Mapping of the SIP state machine State Machine to the IN state model State Model

   This section establishes the mapping of the SIP protocol state
   machine to the IN generic basic call state model (BCSM) [2],
   independent of any capability sets [8, 9].  The BCSM is divided into
   two halves - 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) [1].  The SSPs, SCPs 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: PICs:

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



Gurbani, et al.              Informational                     [Page 10]

RFC 3976                 Interworking SIP & IN              January 2005


   T_BCSM has 8 PICS.  These are: PICS:

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

   The state machine for O_BCSM and T_BCSM is provided in [1] page on pages
   98 and 103 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



draft-gurbani-sin-02.txt                                      [Page 11]

Interworking SIP and Intelligent Network (IN) Applications     June 2002


   machine to the IN BCSMs.  It is beyond the scope of this draft state
   machine to
   explain the IN BCSMs.  Explaining all PICs and DPs in an IN call model.
   model is beyond the scope of this document.  It is assumed that the
   reader has some familiarity with the PICs and DPs of the IN call
   model.  More information can be found in [1].  For a quick reference,
   Appendix A contains a mapping of the DPs to the SIP response codes as
   discussed in the next two sections.

   5.1

5.1.  Mapping SIP protocol state machine 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 an 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 map 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-02.txt











Gurbani, et al.              Informational                     [Page 12] 11]

RFC 3976                 Interworking SIP and Intelligent Network (IN) Applications     June 2002 & IN              January 2005


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



Gurbani, et al.              Informational                     [Page 13] 12]

RFC 3976                 Interworking SIP and Intelligent Network (IN) Applications     June 2002 & IN              January 2005


 |    +-+-+------+<=========================++      |
 |      | |                                         |
 |      | |                                         |
 |      | |                                         |
 |      | +--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 Layer and SIP protocol
                   state Protocol
              State machine to transfer call state

         Figure 5: 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 -

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

     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. (e.g., if the user is not allowed to make calls
      during certain hours), such a call cannot be placed.  SIP has the ability



draft-gurbani-sin-02.txt                                      [Page 14]

Interworking SIP and Intelligent Network (IN) Applications     June 2002


     to can
      authorize the calling party by using a set of policy directives



Gurbani, et al.              Informational                     [Page 13]

RFC 3976                 Interworking SIP & IN              January 2005


      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 reason, reason the call
      cannot be authorized, DP 2 (Origination_Denied) is processed 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 -

      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
      processed, and the IN layer is instructed to enter the next PIC,
      ANALYZE_INFO.

     ANALYZE_INFO -

      ANALYZE_INFO: This PIC is responsible for translating the dial
      string to a routing number.  Many IN service services, such as freephone,
      LNP (Local Number Portability), and OCS (Originating Call Screening), etc.
      Screening) occur during this PIC.  The IN layer can use the R-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, fails, DP 6 (Invalid_Info) is processed 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 -

      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  This 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 [10] 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 -

      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-02.txt                                      [Page 15]

Interworking SIP and Intelligent Network (IN) Applications     June 2002
      encountered that prohibits further processing of the call, DP 10



Gurbani, et al.              Informational                     [Page 14]

RFC 3976                 Interworking SIP & IN              January 2005


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

     CALL_SENT -

      CALL_SENT: At this point, the request needs to be sent to the
      downstream entity; and the entity.  The IN layer waits for a signal confirming
     that
      either that 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 send 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, 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).





Gurbani, et al.              Informational                     [Page 15]

RFC 3976                 Interworking SIP & IN              January 2005


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



draft-gurbani-sin-02.txt                                      [Page 16]

Interworking SIP and Intelligent Network (IN) Applications     June 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 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  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 occurs if the calling party proactively terminating deliberately terminated the call.
      In this case, DP 21 (O_Abandon & O_Calling_Party_Disconnect) will
      be processed processed, and control will be 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 of its
      resources and initializes itself to the null state.

     O_DISCONNECT -

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


   5.2

5.2.  Mapping SIP protocol state machine 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-02.txt





Gurbani, et al.              Informational                     [Page 17] 16]

RFC 3976                 Interworking SIP and Intelligent Network (IN) Applications     June 2002 & IN              January 2005


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

















































draft-gurbani-sin-02.txt                                      [Page 18]

Interworking SIP and Intelligent Network (IN) Applications     June 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|



Gurbani, et al.              Informational                     [Page 17]

RFC 3976                 Interworking SIP & IN              January 2005


|  +----V-----+                          +------+----+----+
|  |Completed |                          | T_Disconnect   |
|  +----+-----+                          +----------------+



draft-gurbani-sin-02.txt                                      [Page 19]

Interworking SIP and Intelligent Network (IN) Applications     June 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: 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 -

      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

      AUTHORIZE_TERMINATION_ATTEMPT: At this PIC, the fact it is ascertained that
      the called party wishes to receive the call is ascertained and that the
      facilities of the called party are compatible with that those of the
      calling party.  If any of these conditions is not met, DP 23
      (Termination_Denied) is invoked 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 invoked,
      and a transition to the next PIC, SELECT_FACILITY, takes place.

     SELECT_FACILITY - The intent of this PIC in






Gurbani, et al.              Informational                     [Page 18]

RFC 3976                 Interworking SIP & IN              January 2005


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



draft-gurbani-sin-02.txt                                      [Page 20]

Interworking SIP and Intelligent Network (IN) Applications     June 2002 gateway and
      select a line/trunk to route the call.  If the called party is
      busy, or if a line/trunk can not cannot be thus seized, the processing of DP 25
      (T_Called_Party_Busy) is invoked, followed by a
     transition of and the call goes 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 invoked, and a transition to
      the next PIC, PRESENT_CALL, takes place.

     PRESENT_CALL -

      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 invoked, and the
      call control is transferred to the SIP protocol state machine.  The SIP
     protocol state machine machine,
      which 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 invoked, and a transition to the next
      PIC, T_ALERTING, takes place.

     T_ALERTING -

      T_ALERTING: At this point, the called party is being "alerted".
      Control now passed passes momentarily to the SIP protocol state machine, machine
      so that 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 results in the
      processing of DP 29 (T_No_Answer) (T_No_Answer), and the call control is
      transferred to the SIP protocol state machine.  The SIP protocol
     state machine machine, which 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

   After the above five PICs have been negotiated negotiated, the rest are mapped
   as follows:

   T_ACTIVE -

      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 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)
      (T_Connection_Failure), and call control is transferred to the SIP
      protocol state machine.  Since the network failed, there is not much little
      sense in attempting to send a BYE request; thus thus, both the SIP
      protocol state machine and the IN call layer should release all
      resources associated with the call and initialize themselves to



Gurbani, et al.              Informational                     [Page 19]

RFC 3976                 Interworking SIP & IN              January 2005


      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 occurs at the receipt of a BYE request at the SIP
      protocol state machine



draft-gurbani-sin-02.txt                                      [Page 21]

Interworking SIP and Intelligent Network (IN) Applications     June 2002 (not shown in Figure 6).  Resources for the
      call should be
   deallocated deallocated, and the SIP protocol state machine
      must send a 200 OK for the BYE request (not shown in Figure 6).

   T_DISCONNECT -

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

6  Example call flows

6.  Examples of Call Flows

   Two examples are provided here to understand show 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
   an 800 freephone number:

      INVITE sip:18005551212@lucent.com sip:18005551212@example.com SIP/2.0
      From: sip:16309795218@il0015vkg1.ih.lucent.com;tag=991-7as-66ff sip:16305551212@example.net;tag=991-7as-66ff
      To: sip:18005551212@lucent.com sip:18005551212@example.com
      Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com stn1.example.net
      Call-ID: 67188121@lucent.com 67188121@example.net
      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 at 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:18475551212@example.com SIP/2.0
      From: sip:16309795218@il0015vkg1.ih.lucent.com;tag=991-7as-66ff sip:16305551212@example.net;tag=991-7as-66ff
      To: sip:18005551212@example.com
      Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com ext-stn2.example.net
      Via: SIP/2.0/UDP sip-in1.ih.lucent.com
      To: sip:18005551212@lucent.com stn1.example.net
      Call-ID: 67188121@lucent.com 67188121@example.net
      CSeq: 1 INVITE








Gurbani, et al.              Informational                     [Page 20]

RFC 3976                 Interworking SIP & IN              January 2005


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

      INVITE sip:19005551212@lucent.com sip:19005551212@example.com SIP/2.0
      From: sip:16302240216@lucent.com;tag=991-7as-66dd sip:16305551212@example.net;tag=991-7as-66dd
      To: sip:19005551212@lucent.com sip:19005551212@example.com
      Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com



draft-gurbani-sin-02.txt                                      [Page 22]

Interworking SIP and Intelligent Network (IN) Applications     June 2002 stn1.example.net
      Call-ID: 88112@lucent.com 88112@example.net
      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 at
   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 by using a
   SIP "403 Forbidden" response status code:

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

7

7.  Security considerations Considerations

   Security considerations for SIN services span cover 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, entity must first be authenticated and, if need be,
   encrypted as well, using the means and procedures defined in [3] for
   SIP requests.

8.  References

8.1.  Normative References

   [1]   I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The
         Intelligent Network Standards: Their Application to Services,"
         McGraw-Hill, 1997.





Gurbani, et al.              Informational                     [Page 21]

RFC 3976                 Interworking SIP & IN              January 2005


   [2]   ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network
         Distributed Functional Plane Architecture," International
         Telecommunications Union Standardization Section, Geneva.

   [3]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

8.2.  Informative References

   [4]   ITU-T Q.1208: "General aspects of the Intelligent Network
         Application protocol"

   [5]   Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.

   [6]   Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [7]   Schulzrinne, H. and if the need be,
   encrypted as well using the means S. Petrack, "RTP Payload for DTMF Digits,
         Telephony Tones and procedures defined in [3] Telephony Signals", RFC 2833, May 2000.

   [8]   ITU-T Q.1218: "Interface Recommendation for Intelligent Network
         Capability Set 1".

   [9]   ITU-T Q.1228: "Interface Recommendation for Intelligent Network
         Capability Set 2".

   [10]  Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
         over IP (TRIP)", RFC 3219, January 2002.






















Gurbani, et al.              Informational                     [Page 22]

RFC 3976                 Interworking SIP requests. & IN              January 2005


Appendix A: Mapping of 4xx-6xx responses Responses in SIP to IN Detections Points

   The mapping of error codes 4xx- 6xx 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 [3].













draft-gurbani-sin-02.txt                                      [Page 23]

Interworking SIP and Intelligent Network (IN) Applications     June 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


Normative References

   1  I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The
      Intelligent Network Standards: Their Application to
      Services," McGraw-Hill, 1997.
   2  ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network
      Distributed Functional Plane Architecture," International
      Telecommunications Union Standardization Section, Geneva.
   3  Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo,
      Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley,
      and Eve Schooler, "SIP: Session Initiation Protocol",
      IETF I-D, Work in Progress, expires August 2002.
      <http://www.ietf.org/internet-drafts/draft-ietf-sip-
      rfc2543bis-09.txt>

Informative References

   4  ITU-T Q.1208: "General aspects of the Intelligent Network
      Application protocol"



draft-gurbani-sin-02.txt  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























Gurbani, et al.              Informational                     [Page 24] 23]

RFC 3976                 Interworking SIP and Intelligent Network (IN) Applications     June 2002


   5  S. Donovan, "The SIP INFO Method" IETF RFC 2976, October
      2000.  <http://www.ietf.org/rfc/rfc2976.txt>
   6  Adam Roach, "SIP-Specific Event Notification", IETF I-D, Work
      in Progress, expires August 2002.  <http://www.ietf.org/
      internet-drafts/draft-ietf-sip-events-05.txt>
   7  H. Schulzrinne, S. Petrack, "RTP Payload for DTMF Digits,
      Telephony Tones and Telephony Signals", IETF RFC 2833, May
      2000.  <http://www.ietf.org/rfc/rfc2833.txt?number=2833>
   8  ITU-T Q.1218: "Interface Recommendation for Intelligent
      Network Capability Set 1"
   9  ITU-T Q.1228: "Interface Recommendation for Intelligent
      Network Capability Set 2"
   10 Jonathan Rosenberg, Hussein Salama, and Matt Squire,
      "Telephony Routing over IP (TRIP)", IETF RFC 3219, January,
      2002. <http://www.ietf.org/rfc/rfc3219.txt> & IN              January 2005


Acknowledgments

   Special acknowledgement acknowledgment is due to Hui-Lan Lu for acting as the chair
   of the SIN DT and ensuring that the focus of the DT did not veer too
   far.  The authors would also like to thank specially Mr give special thanks to Mr. Ray
   C. Forbes from Marconi Communications Limited for his valuable
   contribution on the system and network architectural aspects as Co-chair co-
   chair in the ETSI SPAN.   Thanks also to Doris Lebovits, Kamlesh
   Tewani, Janusz Dobrowloski, Jack Kozik, Warren Montgomery, Lev Slutsman, 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 in draft-gurbani-sin-02.txt
      . Incorporated comments from RFC Editor.
      . As per the comments from RFC Ed., changed name of draft.

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




draft-gurbani-sin-02.txt                                      [Page 25]

Interworking SIP and Intelligent Network (IN) Applications     June 2002


      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 Warren Montgomery, Lev
   Slutsman, Henning Schulzrinne, and Jonathan Rosenberg, who all changes discussed
   contributed to the discussions on the SIN DT email list have been
        included - stay tuned for -02 coming up after 51st IETF. relationship of IN and SIP call
   models.

Author's addresses Addresses

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

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

   Vidhi Rastogi
   Wipro Technologies
   271, Sri Ganesha Complex
   Plot No.72, Keonics Electronics City,
   Hosur Main Road, Madiwala
   Bangalore - 226 560 068, INDIA 100
   Phone: +91 80 5539701
   Email: 51381869
   EMail: vidhi.rastogi@wipro.com














Gurbani, et al.              Informational                     [Page 24]

RFC 3976                 Interworking SIP & IN              January 2005


Full Copyright Statement: Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and translations of it may be copied restrictions
   contained in BCP 78 and furnished to others, at www.rfc-editor.org, and derivative works that comment except as set
   forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on or otherwise explain it or assist in
   its implementation may be prepared, copied, published an
   "AS IS" basis and distributed, in
   whole THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or in part, without restriction scope of any kind, provided
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the above
   copyright notice and this paragraph are included on all such copies and
   derivative works.  However, implementation or use of the technology described in
   this document itself may or the extent to which any license under such rights
   might or might not be modified in available; nor does it represent that it has
   made any independent effort to identify any way, such as by removing rights.  Information
   on the copyright notice or references ISOC's procedures with respect to rights in ISOC Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the
   Internet Society IETF Secretariat and any
   assurances of licenses to be made available, or other Internet organizations, except as needed for the
   purpose result of developing Internet standards in which case the procedures an
   attempt made to obtain a general license or permission for
   copyrights defined in the Internet Standards process MUST use of
   such proprietary rights by implementers or users of this
   specification can be followed, obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or



draft-gurbani-sin-02.txt                                      [Page 26]

Interworking SIP and Intelligent Network (IN) Applications     June 2002


   as patent applications, or other proprietary
   rights that may cover technology that may be required to translate it into


















































draft-gurbani-sin-02.txt implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Gurbani, et al.              Informational                     [Page 27] 25]

----