Subject: [SPIRITS] Request for SPIRITS introduction

From: "Marat Nourmiev" <[email-masked]>
Date: Tue, 11 Jul 2000 17:54:13 +0400

Hi all,

You have very interesting subject for me. I am beginner in PSTN/IN - IP
interworking and I am missing some of basic knowledge of it.  Could you
provide me a reference for introduction?

Regards and thanks,
Marat Nourmiev

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: Alec Brusilovsky <[email-masked]>
Date: Tue, 11 Jul 2000 10:10:50 -0500

The best place to start would be the PINT pages at:
http://www.ietf.org/html.charters/pint-charter.html
and
http://www.bell-labs.com/mailing-lists/pint/

As well as SPIRITS page at:
http://www.ietf.org/html.charters/spirits-charter.html

You will be able to get to the mailing lists and archives of PINT and
SPIRITS from there.

Glad to help,
Alec

P.S. Other IETF WGs like SIGTRAN, MEGACO, SIP, IPTEL, ENUM might be of
interest too. Look for them at:
http://www.ietf.org/html.charters/wg-dir.html

---

From: Alec Brusilovsky <[email-masked]>
Date: Wed, 12 Jul 2000 15:04:08 -0500

Another good resource of information/ideas on PSTN/IN Interworking might be
the book:
Converged Networks and Services: Internetworking IP and the PSTN by
IgorFaynberg, Hui-Lan Lu and Larry Gabuzda:
http://www.amazon.com/exec/obidos/ASIN/0471356441/qid%3D963414149/sr%3D1-2/102-3093969-4344961

Regards,
Alec

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 12 Jul 2000 16:47:56 -0400

Spasibo, tovarishch...

Igor6

---

From: Jörgen Björkner <[email-masked]>
Date: Thu, 13 Jul 2000 18:58:03 +0200

Hi,

Here is a draft showing our ideas of how it is possible to realize a SPIRITS
solution. Note that it might go a few steps in advance, since a forma
protocol decision has not been made yet, but I think it reflects how some of
the pre-spirits implementations were built.

I have submitted it to [email-masked], but it might take a while
until it is available.

I think it was not allowed to have attachments to this list, so it I paste
it into the mail below.

Thanks
/Jörgen

---------------------- Cut Here---------------------

Internet Engineering Task Force                             J.Bjorkner,
                                                           S.Nyckelgard
Internet Draft                                                  Hotsip,
                                                                  Telia
Document: draft-bjorkner-spirits-vsua-00.txt                  July 2000

          A SPIRITS solution based on virtual SIP user agents

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

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

Abstract

   This document discusses events occurring in a telephony network that
   could be useful for call related services created in an Internet
   environment. It also shows one possible implementation of a SPIRITS
   protocol based on Session Initiation Protocol (SIP) [2]. The SPIRITS
   working group has not yet done any protocol decisions, so this draft
   is written for informative purpose showing that the introduction of
   virtual SIP user agents (SIP UAs) in a SPIRITS client makes it
   possible to realize the services described in the pre-spirits
   implementations document [3].

   The advantage of introducing SIP UAs in the SPIRITS client is that a
   SPIRITS proxy and a SPIRITS server then also could be used by any
   other voice network that natively speaks SIP, for example wireless
   3G networks and voice over IP networks. This would also allow the
   PSTN network to utilize the services created for those networks.

   The document is not focused on how these services are subscribed for
   within the telephony network, since there is several appropriate
   methods to do this from an end users perspective, from calling the
   customer service to submit a web form. The action taken after this
   subscription is dependent of the voice network attached to the
   J.Bjorkner,S.Nyckelgard                                        [1]

   Internet Draft                        vsua                 July 2000
   SPIRITS client. This document has the focus on the Internet specific
   parts of the protocol, which should be voice network independent.

1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].

2. Introduction

   This document describes a solution to the problem where an event in
   a telephony network needs to trigger a service that will operate on
   a particular data within the telephony network associated with the
   event. The solution described makes it possible to distribute this
   service logic out from the telephony network to a host on an IP
   network, or in fact also to a host on the Internet.

   The solution is coherent with the architecture developed within the
   SPIRITS working group and proposes a solution based on SIP (Session
   Initiation Protocol) [2]. There are two reasons to use SIP as a
   foundation for the SPIRITS protocol: By using SIP will it be
   possible for SIP speaking voice networks to utilize the SPIRITS
   services; SIP is designed for Internet use with respect to scaling
   and security and contains necessary placeholders for information
   related to voice calls.

   The solution described fits in to the SPIRITS architecture defined
   by the SPIRITS working group shown in Figure 1. The interfaces
   defined with this solution are B and C. The interface D is not
   described in this document, since it is dependent on the signaling
   protocols used in the underlying network. The D interface only
   affects the SPIRITS client implementation according to this proposal
   and leaves the interfaces B and C unaffected.

   If one would like to use the already existing service protocols
   defined for PSTN to talk to IP based hosts, then these protocols can
   be tunneled as they are by using the protocols defined in the IETF
   SIGTRAN working group. Those protocols are however not designed for
   an Internet environment with respect to trust relations and
   transport conditions, so therefore could it be useful to map
   functionality from these protocols to something more Internet
   friendly. Another disadvantage with this method is that these
   protocols exist in different national flavors in different countries
   and even in some cases differs among the networks owned by a single
   operator. On the Internet exists no flavors of a standard, and it is
   important that a SPIRITS server could work together with several
   operators in different countries, without having to install special
   software to make it work. These problems are solved by a protocol
   mapping as described in this document.

   J.Bjorkner,S.Nyckelgard                                        [2]

   Internet Draft                        vsua                 July 2000

                                +-----------+
                                |  SPIRITS  |
                                |  Server   |
                                +-----+-----+
                                      | B
                                +-----------+
                                |  SPIRITS  |
                                |   Proxy   |
                                +-----+-----+
                                      | C
                                +-----------+
                                |  SPIRITS  |
                                |  Client   |
                                +-----+-----+
                                      | D
                                +-----------+
                                | Voice net |
                                |  service  |
                                | function  |
                                +-----------+

                                                 Figure 1.

   The basic idea with this proposal is to show that it is possible to
   create a solution which make the PSTN phones to appear as if they
   were SIP phones to the SPIRITS server. The motivation for this is
   that there will soon be a large number of innovative services that
   will be deployed for SIP networks. If a PSTN could behave as a SIP
   networks from a signaling point of view, it could easily make use of
   these services. Another rationale to use telephony services
   implemented in SIP is that SIP will be the signaling protocol used
   for the all IP 3G wireless networks.

   The functions provided by service protocols used in an IN
   environment in today's PSTN networks differs depending on which
   version and flavor of the IN protocol that is used. Instead of
   focusing on the particular functions and the naming of the functions
   within the different IN protocols, a set of general functions of
   interest for a SPIRITS service are defined and explained in the next
   section.

   The set of general functions is a subset of capabilities of the
   current IN protocols. They provide a balanced tradeoff between
   complexity and functionality. Having this signaling protocol
   agnostic view ensures that no PSTN specific behavior is built into
   the SPIRITS protocol, which is essential in order to make SPIRITS
   useful also for other voice networks than PSTN.

3. Telephony events that could trigger a SPIRITS server

   J.Bjorkner,S.Nyckelgard                                        [3]

   Internet Draft                        vsua                 July 2000

   This section lists events occurring in a voice network that could
   trigger a request from the voice network to a SPIRITS server. It
   also outlines the information that is passed between the SPIRITS
   client and the SPIRITS server. Parameters and formats are subjects
   for a follow-up draft.

   The events are divided into three different categories: call
   origination, call termination and non-call related.

   C->S: denotes information passed from the SPIRITS Client to the
   SPIRITS server. S->C: denotes information passed in the opposite
   direction.

3.1 Call origination events

3.1.1 Event O1 (Call initiation)

   C->S:  call identifier, calling party address, called party address,
         dialed address,

   S->C:  response code, call identifier, [calling party address,
         called party address, dialed address]

   This event is triggered when a user has filled out a complete
   address (i.e. dialed a number) but before a route has been selected
   for the call.

   A normal response from the SPIRITS server carries the same parameter
   fields as the query but the SPIRITS server may have changed any data
   field(s) except 'call identifier'. The returned data is used for
   routing the call in the voice network.

   An alternative response may indicate to the SPIRITS client to
   complete the call as dialed or to reject the call.

   Services possible to create with this event are e.g. Call Barring,
   Speed Dialing, VPN services, Number Portability etc.

   This event maps to a SIP Invite request.

3.2 Call termination events

3.2.1 Event T1 (Call received)

   C->S:  call identifier, calling party address, called party address,
         dialed address,

   S->C:  response code, call identifier, [calling party address,
         called party address, dialed address]

   This event is triggered when a call is received at the switch
   servicing the callee, before the phone starts ringing.
   J.Bjorkner,S.Nyckelgard                                        [4]

   Internet Draft                        vsua                 July 2000

   The response from the SPIRITS server may indicate to the SPIRITS
   client to make the callee's phone ring, to redirect the call to
   another destination or to reject the call.

   Services possible to create with this event are: Conditional
   Redirection, Call Filtering, Internet Call Waiting, Internet Caller
   Identification, etc.

   This event maps to a SIP invite request.

3.3 Call progress informative events

3.3.1 Event I1 (Call failed)

   C->S:  call identifier, calling party address, called party address,
         dialed address, reason of failure

   S->C:

   This event is sent if a call for some reason failed to be set up.

   This event maps to a SIP 503 Service Unavailable response.

3.3.2 Event I2 (Callee busy)

   C->S:  call identifier, calling party address, called party address,
         dialed address

   S->C:--

   This event is sent if the called party is busy due to an ongoing
   phone call.

   This event maps to a SIP 486 Busy Here response.

3.3.3 Event I3  (Call rejected)

   C->S:  call identifier, calling party address, called party address,
         dialed address, reason of rejection

   S->C:--

   This event is sent if the called party rejects an incoming call for
   some reason.

   This event maps to a SIP 603 Decline response.

3.3.4 Event I4  (Call terminated)

   J.Bjorkner,S.Nyckelgard                                        [5]

   Internet Draft                        vsua                 July 2000

   C->S:  call identifier, calling party address, called party address,
         dialed address

   S->C:--

   This event is sent if any of the calling parties terminates the call
   by hanging up.

   This event maps to a SIP Bye request.

3.4 Non call related events

3.4.1 Event N1 (User logged on)

   C->S:  user id

   S->C:  --

   This event is sent when a user logs on to his phone, i.e. turns on
   his cell phone.

   This information is useful for intelligent routing services.

   This event maps to a SIP Register request.

3.4.1 Event N2 (User logged off)

   C->S:  user id

   S->C:  --

   This event is sent when a user logs off from his phone, i.e. turns
   off his cell phone.

   This information is useful for intelligent routing services.

   This event maps to a SIP Register request.

   3.4.1 Event N3 (Position changed)

   C->S:  user id, spatial location

   S->C:  --

   This event is sent when a user updates his position in the network.
   His geographical coordinates for his current position are sent
   within the event.

   This information is useful for intelligent call routing services.

   Note. It is probably good to have the option to send this event
   slightly before an event that might have use of the information,
   J.Bjorkner,S.Nyckelgard                                        [6]

   Internet Draft                        vsua                 July 2000
   instead of constantly sending these messages when an user is moving
   around.

   This event maps to a SIP Register request.

4. Architecture

   Since telephony calls usually involves two ore more parties is it
   proposed that the SPIRITS client actually consists of two logical
   entities representing the calling and called party. These entities
   could be viewed as virtual phones, or virtual users.

   Those entities are called user agents (UA) throughout this document.
   The user agent representing the calling party is named user agent A
   (UAA), and the UA representing the called party is named user agent
   B (UAB). Depending on if the SPIRITS client is residing in the
   originating end of the network or terminating end of the network are
   these named originating or terminating user agents (OUA, TUA).

   The idea is that when a call is to be set up from a user subscribing
   to a SPIRITS service is a UAA corresponding to the calling party
   created within the SPIRITS client. At the same time is a UAB set up
   to represent the called party. An event is sent from the UAA to the
   SPIRITS proxy, which could modify the call setup information before
   it is sent to the UAB. The SPIRITS proxy will then remain within the
   signaling path between the UAA and the UAB throughout the call to
   receive call related events.

   The advantage with this setup is that the UAA and UAB don't have to
   reside within the same SPIRITS client for the services residing in
   the SPIRITS proxy to work. The same SPIRITS proxy could then serve
   voice networks of a more distributed nature.

   Some services, for example Internet Call Waiting, requires some end
   user interaction. In this case will the SPIRITS proxy forward the
   incoming event to the SPIRITS server for user notification. If a
   response is not received from this server within a certain amount of
   time could the proxy process the message according to some pre-
   defined logic.

   The most complex scenario is when a user who has an originating
   SPIRITS service is calling a user who has a terminating SPIRITS
   service. In this case will the call informative events pass flow
   through two SPIRITS servers as shown in Figure 2.

   J.Bjorkner,S.Nyckelgard                                        [7]

   Internet Draft                        vsua                 July 2000

         +----------------+                +----------------+
         |  SPIRITS proxy |                |  SPIRITS proxy |
         +----------------+                +----------------+
              |       |                         |       |
             /|\      |                        /|\      |
              |      \|/                        |      \|/
              |       |                         |       |
         +-+----+--+----+--                +-+----+--+----+-+
         | |OUAA|  |OUAB| |                | |TUAA|  |TUAB| |
         | +----+  +----+ |                | +----+  +----+ |
         | SPIRITS Client |                | SPIRITS client |
         +----------------+                +----------------+
                 |                                 |
   0---0   +-----------+                     +-----------+   0---0
    /_\-->-| Exec. Syst|------------->-------|Exec. Syst.|-->-/_\
           +-----------+                     +-----------+

           Orig. Side                         Term. Side

                                                     Figure 2.

5. Transport protocol

   This document proposes to use SIP as a transport protocol for the
   SPIRITS messages. One reason for this is that it designed to work in
   an environment consisting of the entities described in the SPIRTIS
   architecture. As the next section will show could SIP be used as it
   is without any new extensions to be able to create the services
   described in the pre-SPIRITS implementations document [3].

   Instead needs the behavior it the entities be specified, and the
   encoding of the necessary information to be transported from the
   SPIRITS client to the SPIRITS proxy and servers.

6. System components

   This section gives a description of the components necessary to
   create a SPIRITS service and their behavior.

6.1 Executive system

   This is the logic in the voice network responsible for setting up a
   call, in a PSTN network is this corresponding to a switch. The
   executive system is required to report all events occurring in the
   J.Bjorkner,S.Nyckelgard                                        [8]

   Internet Draft                        vsua                 July 2000
   telephony network necessary to create SPIRITS services to the
   SPIRITS client. The executive system has the knowledge that a user
   is subscribing to a SPIRITS service and is invoking a SPIRITS client
   for all inbound and outbound calls for this user.

6.2 SPIRITS Client

   The SPIRITS client is the bridge between the voice network's service
   function and the SPIRITS services created in an IP environment. The
   SPIRITS client have a default behavior on inbound calls that
   triggers it to send out requests to a SPIRITS proxy on the IP
   network. Its handling of the call is determined from the responses
   of these requests. Therefore is there no need for the SPIRITS client
   to have any knowledge of the service executed in the IP network.

   The SPIRITS client could be viewed of having two sides, one inbound
   side and one outbound. An inbound call to a user having a SPIRITS
   service is associated with the inbound side of the client and that
   UA, the UAA. Depending of the type of service could the SPIRITS
   client stay involved in the signaling path for the rest of the call.
   In this case is an outbound UA, UAB, associated with the connected
   address.

   In the case of a service that wants to stay within the signaling
   path is the invite message forwarded to the UAB, with a request URI
   containing the number to connect the inbound call leg with. The
   address of UAB is carried in the route: header of the initial Invite
   request.

6.2.1 SPIRITS Client UA Outbound Requests

   The UAA sends a SIP Invite to the SPIRITS proxy. The request URI
   contains the dialed inbound number, the from: field the calling
   party's number and the to: field the originally dialed number. The
   to: field could differ from the request URI if any redirection had
   occurred in the voice network. The UAA also inserts a route: header
   indicating the address of the UAB associated with this call.

   The UAA or UAB sends a BYE request when an active call associated to
   the client is terminated to the proxy.

6.2.2 SPIRITS Client UA Inbound Requests

   When a SIP Invite is received by the UAB makes the SPIRITS client
   the executive system to create an outbound call leg to the telephone
   number in the request URI. The progress of setting up this call leg
   is reported back to the SPIRITS proxy with appropriate provisional
   responses. When the called party on this leg answers the phone is a
   200 OK sent back through the proxy to the UAA. If the Invite
   contained a record-route header would all further requests be sent
   according to these routes. By this could a SPIRITS proxy ask to
   receive the BYE message sent when the call is terminated.

   J.Bjorkner,S.Nyckelgard                                        [9]

   Internet Draft                        vsua                 July 2000
   If the Invite message contains a replaces: header would the SPIRITS
   client tear down any ongoing call leg towards the telephone number
   and call ID indicated in this header. The replaces header is
   introduced in the SIP Call Control Services draft [4].

   When a Bye request is received by any UA is the call leg associated
   with this UA terminated by a signal from the SPIRITS client to the
   executive system.

6.2.3 SPIRITS Client responses

   A number of different SIP responses could be received to the invite
   sent by the UAA. The action to these responses is described below.

   200 OK, indicates that the SPIRITS client should signal down to the
   executive system to connect inbound call leg with the call leg
   corresponding to the UAS. The SPIRITS client will stay associated
   with the call until it ends.

   302 Moved Temporarily, the SPIRITS client tells the executive system
   to redirect the incoming call to the telephone number in the
   contact: field of the response. The SPIRITS client is released from
   the call.

   404 Not found, indicates that the SPIRITS client should signal down
   to the executive system to connect the call to the telephone number
   of the inbound call. The SPIRITS client is released from the call.

   603 Decline, tell the executive system to reject the inbound call.
   The SPIRITS client is released from the call.

6.3 SPIRITS proxy

   The SPIRITS proxy is the entity that implements the SPIRITS
   services. The behavior is similar to a SIP redirect/proxy server
   since it performs some action based on the request URI of an
   incoming request and either responds back or forwards the invite to
   the next hop server. In the case of a SPIRITS proxy would the next
   hop server always be the UAB since the UAA always inserts a route
   header containing its address.

   If there is need for user interaction would the proxy know if a user
   is online by the register messages sent from the user to the proxy.
   In this case could a request be sent to the user before the incoming
   request is forwarded or responded to.

7. Call flows

   This section shows how the services described in the pre spirits
   implementations document could be realized according to the proposed
   solution. The target services according to the SPIRITS charter are:
   Internet Call Waiting, Internet Caller Identification and Internet
   Call Forwarding. The SPIRITS protocol should not be hard wired to
   J.Bjorkner,S.Nyckelgard                                        [10]

   Internet Draft                        vsua                 July 2000
   just fit these services, the protocol is a useful tool for people
   implementing services in a SPIRITS proxy or SPIRITS server.

   These examples show the involved message transactions. It needs to
   be defined how to encode the information to be transported within
   the messages.

7.1 Internet Call Waiting

   Internet Call Waiting (ICW) is an example of a terminating service
   which is executed when the call signaling is reaching the executive
   telephone system responsible for the called party. Since ICW is just
   involved during the call setup phase is there no need for the
   SPIRITS server to be involved in the signaling path after the call
   has been established.

   The following steps are invoked in the service execution.

   1. The inbound call setup signaling is received at the receiving
   executive system. This system associates the called number with a
   SPIRITS customer and invokes a SPIRITS client. This invocation is
   out of scope for this working group, and is dependent on the
   signaling mechanisms used in the voice network.

   2. The SPIRITS client creates an UAA and UAB which will be used to
   control the call setup in the voice network.

   3. The UAC send a SIP Invite message to the SPIRITS Proxy. If a user
   is online would he have sent a SIP Register to the SPIRITS proxy
   that contained the IP host he is running his ICW software on. In
   this case would the proxy forward the Invite message to the ICW
   client (SPIRITS server). If he were not registered with the SPIRITS
   proxy would the proxy respond with a 404 Not Found message to the
   UAA. This would cause the SPIRITS client to signal back to the
   executive system to continue the call setup with the dialed number.

   4. If the user were online would he receive an Invite message. This
   invite message contains the calling party's number in the from:
   field that could be used for caller identification. The ICW software
   (SPIRITS server) would show a window telling the user that there is
   an incoming call. He could then have the option to reject, accept or
   redirect the call to another number. In the case of rejection would
   the SPIRITS server return a 603 Decline response to the proxy. This
   would cause the proxy to respond with the same message to the UAA.
   If the call is accepted is the Invite forwarded to the UAA contained
   in the route: header. This invite will contain a replaces: header to
   indicate that the ongoing call should be terminated. The call ID for
   this ongoing were fetched by the SPIRITS proxy during the call setup
   of this ongoing call. In this case would the UAB cause the executive
   system to disconnect any connected voice calls for this user and
   after that connect the inbound call that was accepted. If the user
   whishes to redirect the call to any other answering place, for
   example a soft phone on his PC or a cell phone would a 302 Moved
   Temporarily be returned with the phone number to redirect to in the
   J.Bjorkner,S.Nyckelgard                                        [11]

   Internet Draft                        vsua                 July 2000
   contact: field of the answer. This would cause the executive system
   to set up the inbound call to this telephone number.

   5. When a response is received at the UAA is action taken according
   to above. This would cause the call to be connected and make a phone
   to start ringing.

7.2 Internet Caller Identification

   The Internet Caller Identification (ICI) service is a somewhat
   simplified version of Internet Call Waiting. The message flow is the
   same as for that service, except that the UAC immediately connects
   the call. The Invite message sent out from the UAA would be received
   by the ICI software that a user have registered with the SPIRITS
   proxy. This message would cause a window to pop up which displays
   the name and number of the calling party. This information is
   fetched from the from: field of the Invite message.

7.3 Internet Call Authorization

   This is an example of a more advanced call barring service which is
   an originating service. The idea is that a user can set up rules
   which regulates which number that can be dialed or not. This set of
   rules is stored in the SPIRITS server. If a number is dialed that is
   blocked by the rule set could the SPIRITS server alert the user that
   this is the case, and ask for an authorization code. This would
   cause a software to pop up a window asking for the code. If the
   right code were entered would the call setup continue.

   The message flow for this service is as follows:

   1. All outbound calls for a user be detected by the executive
   system. The dialed number would be sent to the SPIRITS client that
   creates an UAA for this call.

   2. An Invite message is sent to the SPIRITS proxy. This proxy
   contains an access control list of the numbers that this user is
   allowed to call. If there is a granted number is a 200 OK sent back
   to the UAA. If it is a number that is not permitted to call is the
   action dependent of if the user is running his ICA application or
   not. If the user were not logged on would the proxy return a 603
   Decline to the UAA.

   3. If the user is logged on, i.e. have registered with the proxy is
   the Invite forwarded to the application. In normal SIP scenarios is
   the client authenticating himself for the server, i.e.
   authentication is necessary to send a request. In this scenario is
   the opposite necessary, authentication is necessary to send a
   response.  This could be done by inserting an WWW-authenticate
   header containing a challenge in the Invite message sent from the
   proxy. This would cause a window to pop up asking for an
   authorization code and also displaying the dialed from and to
   numbers. From this code is a response calculated and returned in a
   authentication header in a 200 OK response back to the proxy. The
   J.Bjorkner,S.Nyckelgard                                        [12]

   Internet Draft                        vsua                 July 2000
   proxy checks whether this was a valid authentication, and if it was
   the case forwards the Invite to the UAB to set up the call.
   Otherwise is a 603 Decline returned to the UAA.

7.4 Internet Call Distribution

   This is an example of how an automatic call distribution service
   could be built on top of the tools described in this document. A
   call distribution service is a service that selects a termination
   number depending on some built in logic, independent of the dialed
   number. The service is a terminating service. This service is also
   involved during the whole call setup and the call itself since it
   needs to know if a call was successfully set up and when a call
   ends. The steps involved during a call invoking such a service is
   described below.

   1. An inbound call is received by the executive system in the voice
   network. The executive system has the knowledge that this dialed
   number has an associated SPIRITS service.

   2. The executive system invokes the SPIRITS client and provides it
   with the called and calling party number.

   3. The SPIRITS client creates a UAA and UAB. The UAA is associated
   with in inbound call leg to the executive system. The UAB will be
   the entity responsible to create an outbound call leg from the
   executive system towards a recipient of the call. The recipient is
   of the call determined by the SPIRITS proxy according to some built
   in logic. These two user agents could be viewed as mirrors of the
   phones involved during the call.

   4. The UAA sends an Invite message to the SPIRITS proxy. The dialed
   number is inserted in a tel: URL in the request URI of the message.
   The proxy looks performs its logic based on the values of for
   example the request URI and the from: field. Based on this
   information is a new termination number determined which is inserted
   in the request URI of the invite message before it is forwarded.
   Since the SPIRITS client needs to get this information to the UAB,
   is a route header containing the address of the UAB inserted in the
   Invite message sent to the SPIRITS proxy. This will force the proxy
   to forward the Invite to the UAB. The proxy also inserts a record-
   route header in the Invite message before it is forwarded, to ensure
   that all further requests is sent through the proxy.

   5. The UAB receives the Invite message. The request URI contains the
   number to be called. The UAB uses this number and makes the
   executive system to contact this number. The executive system sends
   back status information to the SPIRITS client regarding the call
   setup progress. These messages are mapped to appropriate SIP
   provisional responses and are sent back from the UAB via the proxy
   to the UAA. If the call setup fails or takes too long time could the
   proxy send a Cancel to the UAB to terminate the call setup attempt,
   and send a new Invite to the UAB with a new number to try. By this
   could call forward on no answer be created.
   J.Bjorkner,S.Nyckelgard                                        [13]

   Internet Draft                        vsua                 July 2000

   6. When the executive system reports back to the SPIRITS client that
   the intended destination has been reached is a 200 OK sent back from
   the UAB through the proxy to the UAA. When this is received by the
   UAA will the SPIRITS client report down to the executive system that
   the call should be connected

   7. When the calling party hangs up will a BYE message be sent from
   either the UAs, through the proxy, to the other UA. This is useful
   if the service in the proxy needs this to free up some resources or
   create some statistics.
   From the view of the proxy is this call setup looking like any call
   setup between two SIP endpoints. This has the advantage that the
   same service proxy could be used for both a SIP network and a
   SPIRITS enabled telephony network. The SPIRITS client is performing
   basically the same task as a PINT server is doing. The PINT server
   is creating two call legs in the PSTN and ties them together. In
   this case we already have one of the legs, and creates another which
   then is tied together with the first one.

8. Security Considerations

   Since the transactions occurring between the SPIRITS client and
   SPIRITS proxy contain sensitive data is it recommended that hop-to-
   hop encryption or a secure transport layer be used for this
   communication. These mechanisms are described in section 13 of [2].

9. References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Handley, M., et al., "SIP: Session Initiation Protocol", RFC
      2543, March 1999

   3  Lu, H., et al., "Pre-Spirits Implementations of PSTN-initiated
      Services", IETF Internet Draft draft-ietf-spirits-
      implementations-00.txt, May 2000

   4  Schulzrinne,H., Rosenberg,J., "SIP Call Control Services (draft
      1)",IETF Internet Draft draft-ietf-mmusic-sip-cc-01.txt, June
      1999, www.cs.columbia.edu/~jdrosen

10. Acknowledgments

11. Author's Addresses

   J.Bjorkner,S.Nyckelgard                                        [14]

Internet Draft                        vsua                 July 2000

   Jorgen Bjorkner
   Hotsip AB
   Barnhusgatan 16
   SE-111 23 Stockholm
   Sweden
   Phone: +46 70 666 23 26
   Email: [email-masked]

   Soren Nyckelgard
   Telia Research AB
   SE-123 86 Farsta
   Sweden
   Phone: +46 31 89 77 71
   Email: [email-masked]

    J.Bjorkner,S.Nyckelgard                                        [15]

Internet Draft                        vsua                 July 2000

   Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into

    J.Bjorkner,S.Nyckelgard                                        [16]

---

From: Alec Brusilovsky <[email-masked]>
Date: Thu, 13 Jul 2000 15:27:48 -0500

Jörgen,

I think you are right here. This I-D is just a bit early for the group. I like
it though!
At our meetings we are not supposed to talk about I-D's but SPIRITS issues.
It would be interesting to hear in Pittsburgh how and which SPIRITS requirements
led you to the protocol selection.
If WG decides that these are valid requirements we would have to add them to the
Requirements Document.

Regards,
Alec
P.S. Just a procedural note: It was really unnecessary to attach you I-D to the
list message. Publishing an I-D at [email-masked] should work just
fine. However, I understand that you did that to allow WG to see your I-D
faster.