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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 Draft is active
In: IS-auth-wait
Network Working Group                                       J. Haluska
Internet Draft                                            R. Berkowitz
Intended Status: Informational                                P. Roder
Expires: May 2008                                            W. Downum
                                          Telcordia Technologies, Inc.
                                                              R. Ahern
                                    AT&T Customer Information Services
                                                           P. Lum Lung
                                    Qwest Communications International
                                                         N. Costantino
                                            Soleo Communications, Inc.
                                                          C. Blackwell
                                                          J. Mellinger
                                                               Verizon
                                                              D. Scott
                                                            Volt Delta
                                                     November 18, 2007



   Considerations for Information Services and Operator Services Using
                                   SIP


            draft-haluska-sipping-directory-assistance-04.txt




Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.



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



Haluska, et al.          Expires May 18, 2008                  [Page 1]


Internet-Draft      Information Services Using SIP        November 2007


   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

   This Internet-Draft will expire on May 18, 2008.

Abstract

   Information Services are services whereby information is provided
   in response to user requests, and may include involvement of a
   human or automated agent. A popular existing Information Service is
   Directory Assistance (DA). Moving ahead, Information Services
   providers envision exciting multimedia services that support
   simultaneous voice and data interactions with full operator backup
   at any time during the call. Information Services providers are
   planning to migrate to SIP based platforms, which will enable such
   advanced services, while continuing to support traditional DA
   services. Operator Services are traditional PSTN services which
   often involve providing human or automated assistance to a caller,
   and often require the specialized capabilities traditionally
   provided by an operator services switch. Market and/or regulatory
   factors in some jurisdictions dictate that some subset of Operator
   Services continue to be provided going forward. This document aims
   to identify how Operator and Information Services can be
   implemented using existing or currently proposed SIP mechanisms, to
   identity existing protocol gaps, and to provide a set of Best
   Current Practices to facilitate interoperability. For Operator
   Services, the intention is to reproduce the current PSTN behaviour.



Table of Contents


   1. Introduction..................................................3
   2. Terminology...................................................5
   3. High Level Requirements.......................................9
   4. Information Services.........................................12
   5. Operator Services............................................16
      5.1. Inter Provider Capabilities.............................19
      5.2. Inter OISP Capabilities.................................19
      5.3. Intra OISP Capabilities.................................19
      5.4. Capabilities Required for Specific Services.............21
   6. OISP Internal Architecture...................................21
   7. General Approach.............................................24


Haluska, et al.          Expires May 18, 2008                  [Page 2]


Internet-Draft      Information Services Using SIP        November 2007


   8. Signaling Mechanisms.........................................26
      8.1. Calling Party's Identity................................26
      8.2. Provider Identification.................................27
         8.2.1. Home Provider......................................27
         8.2.2. Intermediate Provider..............................28
      8.3. Originating Station Type................................30
      8.4. Trunk Group Identifier..................................31
      8.5. Dialed Digits...........................................32
      8.6. Retargeting to Identify the Desired Service.............33
      8.7. Charge Number...........................................33
      8.8. Passing Whisper.........................................34
      8.9. Calling Equipment Capabilities and Characteristics......38
      8.10. Media Server Returning Data to the Application Server..39
      8.11. Service Discovery......................................39
   9. Example Call Flow - Directory Assistance.....................40
      9.1. Basic Flow..............................................40
      9.2. OISP Drops Out at Call Completion Setup.................49
      9.3. OISP Drops Out After Call Completion Call is Answered...50
      9.4. OISP Drops Out After Interaction with Called Party......53
      9.5. OISP Remains in Path....................................55
      9.6. Return of Call to OISP..................................58
   10. Operator Services Example Call Flows........................59
      10.1. Network Controlled Coin Calls..........................59
      10.2. Busy Line Verification and Interrupt...................67
         10.2.1. PSTN Target.......................................67
         10.2.2. SIP Target........................................70
      10.3. Inward Calls...........................................72
      10.4. Intercept..............................................73
         10.4.1. Intercept Request Via SIP.........................73
         10.4.2. Intercept Request Via PSTN........................76
      10.5. Operator Assisted Collect Call.........................78
   11. VoIP Information Services - Summary and Next Steps..........85
   12. Security Considerations.....................................85
   13. IANA Considerations.........................................86
   14. References..................................................87
      14.1. Normative References...................................87
      14.2. Informative References.................................87
   Author's Addresses..............................................89



1. Introduction

   Information Services are services whereby information is provided
   in response to user requests. This may include involvement of a
   human or automated agent. Information Services may include call
   completion to a requested telephone number and other extensions


Haluska, et al.          Expires May 18, 2008                  [Page 3]


Internet-Draft      Information Services Using SIP        November 2007


   provided on behalf of the owner of the information, such as
   assistance with purchases. The users normally access the
   Information Services by dialing a Directory Assistance (DA) dialing
   sequence and verbally requesting an operator or automated system
   for the information. The users may also request information through
   other access methods, such as chat (IM), email, Web (HTTP) or SMS
   initiated requests. The Information may be delivered to the user
   via any mode, such as verbal announcements, chat (IM), email, Web
   (HTTP), MMS, or SMS.

   A popular existing Information Service is Directory Assistance
   (DA).  DA is a well known service in today's PSTN, and is generally
   identified with "411" or "NPA-555-1212" type services in North
   America.  Today's DA services provide a user with telephone number
   associated with a name and locality provided by the user, can
   complete the call for the user, and can send SMS with the listing
   to the user's wireless phone. Other Information Services provide
   the user with a wide range of information, such as movie listings
   and the weather.

   Moving ahead, Information Services providers envision exciting
   multimedia services that support simultaneous voice and data
   interactions with full operator backup at any time during the call.
   For instance, a directions Information Service may announce and
   display directions to the requested listing, with the option for
   the caller to request transfer to an operator with the latest call
   context information.

   Operator Services are traditional PSTN services which often involve
   providing human or automated assistance to a caller, and often
   require the specialized capabilities traditionally provided by an
   operator services switch. Market and/or regulatory factors in some
   jurisdictions dictate that some subset of Operator Services
   continue to be provided going forward.  Some examples of such
   services include collect calls, third party billed calls, and busy
   line verification.

   Operator and Information Services providers are planning to migrate
   to SIP based platforms, which will enable such advanced services,
   while continuing to support traditional DA services.

   Implementing Operator and Information Services with SIP will
   require the exchange of certain information, and possibly the use
   of specialized capabilities which are not normally required for
   other types of calls. This document aims to identify such
   information, and stimulate discussion about how this information
   could be exchanged. Existing mechanisms will be used where


Haluska, et al.          Expires May 18, 2008                  [Page 4]


Internet-Draft      Information Services Using SIP        November 2007


   appropriate, and currently existing proposals will be favored over
   new extensions. It is intended to provide a Best Current Practices
   document to facilitate interoperability.

   It is assumed that appropriate business relationships are in place
   between involved providers, and that the providers involved have
   trust relationships as described in [RFC3325]. In other words, this
   document does not assume general operation on the open internet,
   but rather between sets of providers with appropriate business and
   trust relationships. Individual providers may decide to provide
   handling for other requests, but this is beyond the scope of this
   document.







2. Terminology

   This section defines terms that will be used to discuss Information
   and Operator Services.

   Application Server (AS) - An Application Server is a server
   providing value added services. It may influence and impact SIP
   sessions on behalf of the services supported by the service
   provider's network.

   Back End Automation - Back End Automation refers to automation of
   the function that provides listing information to the caller. This
   includes playing a verbal announcement with the listing
   information, and may also include prompting the user for call
   completion service.

   Branding - Branding is a service where customized announcements are
   provided to the caller to identify the service provider. For
   example, if the service is provided to a Home Provider's
   subscribers by a third party provider, branded service might
   include a message thanking them for using that Home Provider. Thus
   the user experience is that the service is provided by their Home
   Provider rather than some third party. Branding can be influenced
   by a number of factors, including but not limited to the identity
   of the caller's Home Provider, or of other providers involved in
   the call.




Haluska, et al.          Expires May 18, 2008                  [Page 5]


Internet-Draft      Information Services Using SIP        November 2007


   Call Completion - Call Completion is a service where a call is
   initiated by the provider on behalf of the user. For example, in
   the DA service, once the DA provider has identified the requested
   listing, it may offer to complete the call for the caller, usually
   for some additional fee. This relieves the user from having to
   remember the number and then dial it.

   DA Provider -The DA provider is the provider of DA services to end
   users. Since DA services are a subset of IS services, a DA provider
   is also an IS provider, and the definition of IS provider holds
   true for DA provider, except that the scope of services is limited
   to DA services.

   Front End Automation - Front End Automation refers to automation of
   the initial customer contact, whereby a branded announcement may be
   played, a prompt is played to the user, and the user's spoken
   request is recorded. Speech recognition and querying for the
   listing information are performed as part of front end automation.

   Home Provider - The service provider who is responsible for
   providing voice services to the calling customer. This is the
   service provider that has the business relationship with the
   calling customer. The identity of the home provider influences call
   processing treatment, such as branding and operator queue
   selection.

   HSS - Home Subscriber Server. The Home Subscriber Server is an IMS
   network element similar to a Home Location Register. It is a
   database containing information about the subscriber, user
   equipment, filter criteria for call processing triggers, etc.

   Information Services (IS) Provider - The IS provider is the
   provider of Information Services to end users. The Information
   Services provider provides retail services directly to end users,
   and provides wholesale services to other service providers.

   Intermediate Provider - In the context of this document, an
   Intermediate Provider is a provider which has agreements with home
   providers to handle OIS requests, and with OISPs which actually
   provide the requested services. Note that some home providers will
   have direct relationships with OISPs, rather than using an
   Intermediate Provider. Intermediate Providers are the targets of
   SIP requests from home providers since they are involved when a
   home provider does not have a direct relationship with an OISP.
   Intermediate Providers perform retargeting of received SIP requests
   toward the OISP.



Haluska, et al.          Expires May 18, 2008                  [Page 6]


Internet-Draft      Information Services Using SIP        November 2007


   Layer 3 connectivity - This refers to IP connectivity, for example
   as provided by an Internet Service Provider or Managed IP service
   provider. If one entity has Layer 3 connectivity to another entity,
   then it can route packets to that entity. This does not imply
   anything about any physical path between the entities. Nor does it
   imply any application layer connectivity between the entities.

   Media Server - A Media Server is a general-purpose platform for
   executing real-time media processing tasks. Examples of typical
   functions performed by media servers include playing announcements,
   collecting speech and/or DTMF digits, and performing conferencing
   functions.

   Operator and Information Services Provider (OISP) - In this
   document, this term refers to an Information Services Provider,
   Directory Assistance Provider, or Operator Services Provider,
   depending on the context. This term is used for brevity. We are
   also defining this to be an adjective, thus "OISP services" is a
   convenient, intuitive way to say "Operator and Information
   Services".

   Operator Services - Traditional PSTN services which often involve
   providing human or automated assistance to a caller, and often
   require the specialized capabilities traditionally provided by an
   operator services switch. Some examples of such services include
   collect calls, third party billed calls, and busy line
   verification.



   Retail OIS service - A retail OIS service is one which is provided
   to a user by the user's Home Provider.

   SIP Layer connectivity - When one entity has SIP level connectivity
   to another entity, this implies that the second entity will accept,
   process, and route SIP requests from the first entity. This would
   usually involve business agreements as well.

   Time Division Multiplexed (TDM) Local Exchange Carriers (LECs) -
   ATDM LEC provides local exchange service to end users utilizing
   TDM-based switching systems.

   Transit Provider - In the context of this document, a transit
   provider simply "moves calls", and has no concept of OIS services.
   It may perform SIP rerouting of the request, but does not perform
   SIP retargeting. Such a provider is used when a provider cannot
   directly route calls to another provider. For example, an


Haluska, et al.          Expires May 18, 2008                  [Page 7]


Internet-Draft      Information Services Using SIP        November 2007


   Intermediate Provider might use a Transit Provider if for some
   reason (e.g. error condition) it cannot route a call directly to an
   OISP.

   Transport Services Provider (TSP) - The TSP provides access at
   Layer 3 or below to other providers. The most obvious case of TSP
   is that of an internet service provider or managed IP services
   provider. VSPs, and IS or DA providers may or may not share the
   same TSP for access to each other. Further, each of these providers
   may have multiple TSPs. In this case, the decision as to which is
   used is determined by the policy of the entity sending the traffic;
   the Border Gateway Protocol (BGP) is often used. It is entirely
   possible that the traffic from each entity towards the other takes
   separate paths; i.e. it should not be assumed that the incoming and
   outgoing paths are symmetric.

   Voice Services Provider (VSP) - An entity that provides transport
   of SIP signaling to its customers. It may also provide media
   streams to its customers. Such a service provider may additionally
   be interconnected with other service providers; that is, it may
   "peer" with other service providers. A VSP may also interconnect
   with the PSTN.

   Whisper - During front end automation, the OIS-MS will record and
   may time compress the caller's perhaps meandering speech into what
   is known as the "whisper". This is intended to be played into a
   human operator's ear, should the call be referred to an operator,
   to avoid the operator from having to prompt the caller again. The
   whisper is obtained during the front end automation, and saved as
   an audio file.

   Wholesale OIS service -A wholesale OIS service is one which is
   provided to a user by a Service Provider other than the user's Home
   Provider.

   Zero Minus ("0-") Dialing - Invocation of Operator Services by
   dialing "0" with no further digits.

   Zero Plus ("0+") Dialing - Invocation of Operator Services by
   dialing "0" followed by a phone number.









Haluska, et al.          Expires May 18, 2008                  [Page 8]


Internet-Draft      Information Services Using SIP        November 2007


3. High Level Requirements



   In addition to all-IP scenarios, it must be possible to support
   interworking with existing PSTN and wireless based providers, via
   both SS7 and MF interconnections.

   It must be possible to support accounting. This includes both
   online and offline accounting. It must be possible to perform
   accounting for all actions associated with a particular call, and
   further to be able to correlate actions across multiple provider
   elements and across providers.

   It must be possible to support multiple Operator and Information
   Services Providers (OISPs) per originating provider. The choice as
   to which OISP to be used could be on a per subscriber basis, or on
   other criteria.

   It must be possible to support multiple OISP providers per call.
   For example, one provider might be used for front end automation,
   and another used for operator assistance.

   It must be possible to provide an automated announcement to the
   user, and prompt the user for the type of query and query
   information.

   It must be possible to pass a "whisper" to the operator
   workstation.

   It must be possible to connect the user to a human operator.

   It must be possible to provide an automated announcement of the
   requested information.

   It must be possible to prompt the user for call completion.

   It must be possible to perform call completion.



   It must be possible to support the case where OIS services are
   provided by the caller's Home Provider. This scenario is known in
   the OIS industry as the Retail scenario. In this case, the caller's
   Home Provider is also an OISP, and provides OIS service to its own
   subscribers. This is illustrated in the following figure:



Haluska, et al.          Expires May 18, 2008                  [Page 9]


Internet-Draft      Information Services Using SIP        November 2007


   +--------+    +--------------------+
   | Caller |----| Home      +------+ |
   |        |    | Provider  | OISP | |
   |        |    |           +------+ |
   +--------+    +--------------------+

               Figure 1 Services Provider by Home Provider





   It must be possible to support the case where OIS services are
   provided by a direct third party provider. In this scenario, the
   OISP is a third party service provider, and there is direct SIP
   layer connectivity as well as business relationships between the
   calling user's provider and the OISP. This is illustrated in the
   following figure:

   +--------+    +----------+   +------+
   | Caller |----| Home     |---| OISP |
   |        |    | Provider |   |      |
   +--------+    +----------+   +------|


       Figure 2 Services Provider by a Direct Third Party Provider



   It must be possible to support the case where services are provided
   by an indirect third party provider. In this scenario, the OISP is
   a third party provider, but the caller's Home Provider does not
   have direct SIP connectivity to the OISP. Further, it's possible
   that it has no business relationship with the OISP. The caller's
   provider routes the call to a provider with whom it does have a
   relationship, referred to in this document as an "intermediate
   provider", and this intermediate provider in turn routes either to
   the OISP, with which it has a relationship, or there could be
   multiple intermediate providers. This is illustrated in the
   following figure:









Haluska, et al.          Expires May 18, 2008                 [Page 10]


Internet-Draft      Information Services Using SIP        November 2007


   +--------+    +--------+   +---------+   +------+
   | Caller |    |Home    |   | Inter-  |   | OISP |
   |        |----|Provider|---| mediate |---|      |
   |        |    |        |   | Provider|   |      |
   |        |    |  (A)   |   |   (B)   |   |  (C) |
   +--------+    +--------+   +---------+   +------+

      Figure 3 Services Provided by an Indirect Third Party Provider



   It must be possible to support the case where transit providers are
   included between any other providers involved in the call. The
   transit provider only "moves calls" between other providers, and is
   involved in no other way with OIS services. This is illustrated in
   the following figure:

   +--------+    +--------+   +--------+   +---------+   +------+
   | Caller |    |Home    |   |Transit |   | Inter-  |   | OISP |
   |        |----|Provider|---|Provider|---| mediate |---|      |
   |        |    |        |   |        |   | Provider|   |      |
   |        |    |  (A)   |   |  (B)   |   |   (C)   |   |  (D) |
   +--------+    +--------+   +--------+   +---------+   +------+

                Figure 4 Involvement of a Transit Provider







   The following are potential future requirements.

   Operation via the general internet, not specific to any particular
   SDO's architecture, and not depending on any protocol extensions
   specific to those architectures, should be supported.

   In addition to the basic DA functionality, the architecture will
   need to support additional technical capabilities. These
   capabilities are currently under investigation. The following are
   some business needs which drive these capabilities.

   It must be possible to support multiple Information Services
   providers per originating provider. For instance, a Home Provider
   must be able to select an appropriate Information Services provider
   from among several Information Services providers based on criteria


Haluska, et al.          Expires May 18, 2008                 [Page 11]


Internet-Draft      Information Services Using SIP        November 2007


   including but not limited to the identity of the calling
   subscriber.  It must also be possible to support multiple
   Information Services providers per call. For example, once the
   initial request has been satisfied, the user may make another
   Information Services request without hanging up, and it must be
   possible in this case to select the appropriate Information
   Services provider for the next request. In such cases the
   Information Services provider may be involved in selecting a
   different Information Services provider.

   It must be possible to support non voice initiated Information
   Services requests. Possible examples include chat (IM), email, Web
   (HTTP) or SMS initiated requests. In the case that the subscriber
   makes a purchase via some online auction service, that subscriber
   can via IM or email request the assistance of an operator.

   It must be possible to support both Information Services as well as
   Operator Services. Examples of Operator services include Operator
   Intercept, Busy Line Verification, Call Restrictions, etc.

   It must be possible to support Purchase services and Concierge
   services. Such services facilitate the Information Services
   operator providing assistance to the caller after the listing has
   been announced and perhaps call completion performed. The call is
   routed to an Information Services operator who interacts with the
   customer, offering to help make a purchase. Concierge service is
   similar; the Information Services operator offers to make e.g.
   restaurant reservations for the caller.

   It must be possible to provide an application interface to other
   types of systems. An example could be a web based API, so that once
   some online search engine has located some business listing, the
   services of the Information Services provider could be invoked by
   the user from the web page.

   It must be possible to support IPTV interactive services. As
   multiple services such as IM and telephony are integrated with
   IPTV, it must be possible to initiate Information Services requests
   in this context as well.



4. Information Services

   Information Services (IS) are services whereby information is
   provided in response to user requests. This may include involvement
   of a human or automated agent. Usually, the user accesses the


Haluska, et al.          Expires May 18, 2008                 [Page 12]


Internet-Draft      Information Services Using SIP        November 2007


   Information Service by placing a voice call to the automated
   Information Service and verbally requests the information, such as
   phone number, movie listings, weather, etc. Frequently, a live
   operator is attached to recognize the user's verbal request.
   Sometimes, the user can utilize other access methods, such as SMS,
   IM, or HTTP-initiated requests. These additional methods are not
   currently covered in this document.

   Information Services are often provided on a wholesale basis to
   Home Providers, and include features such as branded announcements.

   Directory Assistance (DA) is a specific type of Information Service
   whereby end users request a telephone number for an entity.

   The following represents a list of representative steps taken
   during the course of a typical DA request and identifies a set of
   required high level capabilities.

   1. Initial recognition of an OIS call. At some point, the call
   needs to be identified as an OIS call, and appropriate routing or
   other logic must be invoked in order to fulfill the request. This
   could be based on any number of criteria, including but not limited
   to analysis of the "address information" - e.g. the digits or
   Request-URI emitted by the caller's UA. This could occur at any
   number of places - e.g. in the caller's UA, in a proxy in the home
   provider, or in some downstream element.

   2. Identification of the requested service. There are many possible
   OIS services, and the number of these is only expected to increase
   as providers respond to customer needs. At some point during call
   processing it is necessary to identify exactly which service is
   desired. For example "directory assistance with call completion" is
   a service where after the listing information is provided to the
   caller, the option is provided for the call to be placed
   automatically, so the customer need not hang up, remember the
   digits, and dial the number. Another example is "directory
   assistance only", where call completion is not offered. There are
   multiple factors which could affect the service which is to be
   offered, and the logic deciding this could be located anywhere
   along the path to the OIS provider. Some of the information
   required to make such decisions could include:

     o The digits dialed by the caller.

     o The Request-URI emitted by the caller's UA.




Haluska, et al.          Expires May 18, 2008                 [Page 13]


Internet-Draft      Information Services Using SIP        November 2007


     o The identity of the calling party, for instance the calling
        party number.

     o The charge number associated with the caller's account.

     o The identity of the calling party's home provider.

     o The identity of the provider which directly hands off the call
        to the OISP.

     o The identity of other provider which the request might traverse

     o The Originating Station Type, in case the call was originated
        in the PSTN.

     o Trunk group information, in case the call was originated in the
        PSTN.

     o Capabilities and characteristics of the caller's user
        equipment.



   3. Routing of the OIS call. The call must be routed towards an
   entity which can provide the requested service. Each entity or
   network handling the call routes it based on the logic located in
   that provider, and the information currently available. For
   instance, the home provider may know very little about OIS
   services, having farmed that service out to another provider.
   Consequently it might simply route all such calls towards the OIS
   provider, which decides which service is to be offered.

   4. Authentication. When one provider passes a call to another
   provider, there is a need for the providers involved to be sure of
   each other's identity. This might be through explicit security
   mechanisms such as mutual TLS or security gateways using IPSec
   tunnel mode, it might be through reliance on a closed set of
   trusted interconnected providers, or some other policy set by the
   providers involved.

   5. Receipt of the OIS call. The OIS provider needs to be able to
   receive such calls.

   6. Querying upstream providers for information. The OISP, or an
   intermediate provider may require information from an upstream
   provider. For instance, the capabilities and characteristics of the



Haluska, et al.          Expires May 18, 2008                 [Page 14]


Internet-Draft      Information Services Using SIP        November 2007


   caller's equipment may be needed in order to influence call
   processing.

   7. Selection of automated voice platform. When it has been
   determined that the call must be routed to an automated voice
   platform, there are a number of factors to be taken into account to
   determine an appropriate, available platform for the call. It must
   be possible to determine an appropriate, available automated voice
   platform to which the call should be routed.

   8. Connection of caller to automated voice platform. The OISP must
   be able to connect the caller to an appropriate automated voice
   platform.

   9. Provision of branded announcements. The OISP must be capable of
   providing custom announcements to the caller based on a number of
   criteria. For example, it might greet the caller, thanking them for
   using their Home Provider's service. Though the service is actually
   provided by the OISP, business arrangements would dictate such
   branded announcements.

   10. Query the caller. The OISP must be capable of playing a voice
   request to the customer asking them for the listing. For example
   "Name and city, please."

   11. Recording a spoken request. The OISP must be capable of
   recording the caller's spoken request. This both for speech
   recognition, and also for playing back the "whisper" to a human
   operator should one be required, to prevent having to ask the
   customer to repeat the request.

   12. Speech recognition. The OISP must be able to pass the caller's
   spoken request to speech recognition system, suitable for querying
   a listing database.

   13. Listing database query. The OISP must be capable of querying
   one or more listings databases using the request.

   14. Decide to use human operator if listing query fails. If the
   listing query fails, or the speech recognition fails, the OISP must
   be able to decide to send the call to a human operator.

   15. Selection of appropriate operator. When it has been determined
   that the call must be routed to a human operator, there are a
   number of factors to be taken into account to determine the
   appropriate operator for the call. It must be possible to determine



Haluska, et al.          Expires May 18, 2008                 [Page 15]


Internet-Draft      Information Services Using SIP        November 2007


   an available, appropriate human operator to which the call should
   be routed.

   16. Routing of call to operator workstation. Once the appropriate
   operator has been identified, the call must be routed to that
   operator's workstation.

   17. Whisper. Once the operator answers the call, the previously
   recorded request should be played to the operator as a "whisper",
   prior to connecting the caller to the operator.

   18. Connection of caller to operator. Once the operator has heard
   the whisper, the caller can be connected to the human operator. The
   operator queries the caller for the request, and initiates a query
   to the listing database.

   19. Playing listing information. Once the listing information is
   returned from the database, the caller must be connected to a media
   resource which speaks the listing information to the caller.

   20. Prompting for call completion. If the identified service
   includes call completion, the caller should be prompted for this
   service, for example by pressing some DTMF key.

   21. Call completion. If the caller requests call completion, the
   call should be automatically initiated for the caller.



5. Operator Services

   Operator Services are traditional PSTN services which often involve
   providing human or automated assistance to a caller, and often
   require the specialized capabilities traditionally provided by an
   operator services switch. Market and/or regulatory factors in some
   jurisdictions dictate that some subset of Operator Services
   continue to be provided going forward.

   This document assumes an architecture with SIP based OISPs, SIP
   based home providers, and SIP based end users. Since it is
   necessary to maintain backward compatibility with traditional TDM
   based providers and end users, these are also considered. It may
   not be necessary, desirable, or technically feasible to support
   every existing Operator Service using SIP, or to support both SIP
   and TDM based end users for all Operator Services. This is the
   subject of ongoing investigation, and the current iteration of this
   document assumes that both SIP and TDM based home providers and end


Haluska, et al.          Expires May 18, 2008                 [Page 16]


Internet-Draft      Information Services Using SIP        November 2007


   users are in scope for these services, unless specifically
   indicated to the contrary. A future revision may update this
   assumption based on the findings of the investigation.

   With respect to Operator Services, this iteration of this document
   intends to provide an introduction to and descriptions of some of
   these services, as well as provide some high level requirements. It
   is intended that the subsequent iteration will build upon this,
   providing more detailed requirements, suggested SIP mechanisms, and
   more call flows.

   Operator Services are typically provided by the requesting party's
   OISP. In some cases, such as Busy Line Verification, the target or
   called party's OISP may be involved as well.

   Next, several traditional Operator Services will be described. As
   indicated above, the current iteration of this document is silent
   regarding which of these may or may not be candidates for
   implementation with SIP, or towards SIP end users. Note that unless
   specifically indicated, most of these services are traditionally
   provided by the caller's OISP.

   Operator Assistance. This allows the caller to perform either "zero
   minus" or "zero plus" dialing to be connected to a human or
   automated system for assistance with the call.

   Collect calls. This allows the caller to request that the called
   party accept the charges for the call. Typically an OISP utilizes a
   human operator or automated system to provide this service.

   Rate Quotes. This allows the caller to request a quote for the cost
   or rate for specific calls.

   Third party billed calls. This allows the caller to request that a
   third party (different than the calling or called party) be
   contacted and requested to accept charges for the call (although in
   some limited cases, contacting the third party is not necessary).

   Busy Line Verification and Interrupt. This allows a caller to have
   the OISP determine whether a target line is in use, and if so, to
   "barge in" to the conversation and request whether the target party
   is willing to accept a call from the caller. This service is
   initially handled by the caller's OISP, which then contacts the
   target party's OISP, which is able to perform the verification and
   interrupt on the target party.




Haluska, et al.          Expires May 18, 2008                 [Page 17]


Internet-Draft      Information Services Using SIP        November 2007


   Coin Calls. Operator services systems must be able to control TDM-
   based network controlled coin stations (payphones). This includes
   monitoring of coin deposit tones (to verify payment) sent from the
   coin station, as well as sending supervision (control) signals to
   the coin station. Network controlled coin stations are connected to
   TDM based end offices via specialized phone lines which support the
   required signaling. These end offices, in turn, connect to TDM
   based OISPs using specialized trunks capable of conveying the coin
   signaling. The OISP monitors and controls the coin station via
   these trunks. "Smart" coin stations perform coin detection locally
   and do not require network control, and are not discussed here.
   This service is provided by the OISP associated with the coin
   station.

   Emergency Calls. Sometimes a caller dials "0" instead of the
   standard emergency dialstring, resulting in placement of an
   emergency call to the OISP. The OISP must properly route such a
   call toward the PSAP. This service is provided by the caller's
   OISP.

   Calling Card Billing Service. This enables a calling party to bill
   a call to a calling card number.

   Commercial Credit Card Billing Service. This enables a calling
   party to bill a call to a commercial credit card.

   Directory Assistance (DA). In some contexts, DA is considered as an
   Operator Service. Within the context of this document, we consider
   DA as an Information Service, which is related to but distinct from
   Operator Services.



   The following sections describe an initial set of basic high level
   capabilities required for supporting Operator Services. The
   capabilities for Information Services generally apply for Operator
   Services as well. This work is currently under study, and a
   complete set of required capabilities is expected to be identified
   in the near future. Similarly to the required capabilities for
   Information Services, the use of existing SIP mechanisms will be
   investigated for providing these capabilities.








Haluska, et al.          Expires May 18, 2008                 [Page 18]


Internet-Draft      Information Services Using SIP        November 2007


5.1. Inter Provider Capabilities

   Ability to accept requests from other providers. This is the
   ability to accept incoming OIS requests from other providers,
   including home providers, intermediate providers, and transit
   providers.

   Ability to terminate calls to other providers. This applies to call
   completion services, as well as other services such as third party
   billing.



5.2. Inter OISP Capabilities

   These are capabilities between OISPs.

   Inward connection. This is a call from one OISP to another, e.g. so
   that the originating OISP may request services from the terminating
   OISP. One example of this is Busy Line Verification, where the
   caller calls their own OISP, and this OISP places an "inward" call
   to the target party's OISP, which would have the capability to
   perform the verification of the target party.

   Transfer between OISPs. In this case, one OISP transfers the call
   to another OISP, to be handled by that OISP.

   Moving connection from one OISP to another. An example of this case
   is where one OISP farms out a specific service to another OISP. The
   first OISP performs initial handling of the call, to determine the
   desired service. The call is sent to a different OISP with which
   the first has a relationship. The first OISP remains in the
   signaling path, and when the provided service is complete, the
   first OISP determines what if any additional processing may be
   necessary. This is similar to a third party call control type
   arrangement.



5.3. Intra OISP Capabilities

   Note that some of the following capabilities may be required for
   inter OISP scenarios as well; this is the subject of ongoing
   analysis and is not covered in the current iteration of this
   document.




Haluska, et al.          Expires May 18, 2008                 [Page 19]


Internet-Draft      Information Services Using SIP        November 2007


   Placing a caller on hold, possibly with announcements. This is used
   in many services, including Information Services.

   Exchanging information between Application Server and Operator
   Workstations/Automated Platforms. This capability is required
   whenever an operator workstation or automated platform is used.
   Because an Operator Workstation interacts with a human user, it is
   expected that additional information, beyond that which an
   automated system would exchange with an application server, will be
   required. Further, several modes of application server control are
   currently under investigation. The first is where the workstation
   or automated platform is more or less autonomous, and is capable of
   initiating calls and directly impacting call processing. The other
   is more of a master-slave relationship, where the AS is in complete
   control. The master-slave model requires that more information be
   exchanged with the AS than does the autonomous model.

   Queuing and call distribution. Resources including human operators
   and automated platforms need to be tracked and managed, and the
   appropriate resource of the appropriate type needs to be selected
   on a per invocation basis. What is needed is that for a particular
   call, that a set of criteria be provided and the best match
   resource be selected. This is the job of the ACD server. Some means
   is needed to communicate the selection criteria for human operators
   and automated platforms to the ACD server.

   Operator Registration and Location. Human operators may not be
   interchangeable, and have specific attributes such as skillsets
   which can be used to identify the best human operator to service a
   particular call. Operators log in at workstations at the beginning
   of a shift, and log out during breaks and at the end of a shift. It
   is important to associate each available operator with the
   workstation at which they are logged in, so that requests can be
   sent to the appropriate human operator. This is needed because the
   selection process described above identifies a particular human
   operator; it is then necessary to identify the workstation at which
   that operator can be reached.

   Bridging and removal of operator or automated system. Many operator
   services require that either a human operator or automated system
   be "bridged" onto a call, and to be removed at some point.








Haluska, et al.          Expires May 18, 2008                 [Page 20]


Internet-Draft      Information Services Using SIP        November 2007


5.4. Capabilities Required for Specific Services.

   Connection Hold and Ringback. This capability involves having the
   OISP "hold" the connection, such that the originating caller
   remains connected, even if they attempt to hang up. This is mainly
   used in relation to emergency services. Ringback is the ability for
   the OISP to call back the calling party after they have hung up.
   This too is often used in conjunction with emergency calls.

   Coin Station Control. This is the ability of the OISP to determine
   the coinage deposited into a TDM based network controlled coin
   station (as opposed to an "intelligent" coin station which performs
   such functions locally). This involves interpretation of the coin
   control signals sent via specialized trunks from the end office to
   which the TDM based coin station is connected via a specialized
   phone line. Additionally, the need to signal toward the coin
   station needs to be supported as well, for example to instruct the
   station to return coins to the caller. This capability is intended
   to interact with the specialized coin trunk.

   Network Service Recall. After a call resulting from Operator
   Services is completed, the caller may signal the desire to return
   back to the OISP, without placing another call. In the traditional
   PSTN, this is typically accomplished by the user signaling a hook
   flash or other distinctive stimulus.

   Verification and Interrupt. This is used in the Busy Line
   Verification and Interrupt service, and allows the OISP to
   determine if the target number is in use, to listen to a scrambled
   representation of the conversation, and to interrupt the target
   party's conversation to ask if they would accept a call from the
   caller.

   Transfer of emergency services call to selective router. Sometimes
   a caller places an emergency call using a dial string which invokes
   operator assistance (such as "0" in North America), rather than an
   emergency call dial string. In such cases, the OISP must be able to
   pass the emergency call to the appropriate PSAP. Handling of these
   types of calls is outside the scope of this document. Standards for
   emergency calling with SIP are still in development.



6. OISP Internal Architecture

   This section describes an initial view of the elements internal to
   the OISP architecture.


Haluska, et al.          Expires May 18, 2008                 [Page 21]


Internet-Draft      Information Services Using SIP        November 2007


   The following types of elements may be present within the OISP
   infrastructure:

   Automatic Call Distributor (ACD) server - The ACD provides queuing
   and call distribution functions for human operators. Specifically,
   it is the component that tracks the availability of the human
   operators and selects an available operator utilizing complex
   algorithms based on operator skills, type of call, type of request,
   calling party information, etc. Similar functionality is required
   with respect to automated platforms. The ACD server is modeled as
   an Application Server. There is currently work in the MEDIACTL
   working group regarding Media Resource Brokers (MRBs) which may be
   relevant to this.

   Customer Profile Database - The Customer Profile Database is a per
   subscriber database maintained by an OISP about its customers. Some
   of this information might be statically provisioned, other
   information such as customer preferences or session information
   might be populated dynamically as a result of customer
   interactions.

   Messaging Gateways - Messaging Gateways provide access and data via
   E-mail, SMS, MMS, WAP.

   Operator and Information Services Application Server (OIS-AS) - The
   OIS-AS contains AS functions specifically for directory assistance
   and information services as well as other Operator Services. This
   may coordinate multiple call legs, connecting the caller in
   sequence to one or more OIS-MS and/or operator workstations
   according to the logic contained within. The OIS-AS may need to
   communicate with elements of other providers, for instance to query
   information about the capabilities and characteristics of the
   caller's equipment, or to access another provider's operator
   resources.

   Operator and Information Services Media Server (OIS-MS) - The OIS-
   MS provides the media resources for playing announcements,
   performing voice recognition, performing listing database queries,
   generating whisper from the user's verbal request, etc.

   Operator Workstations - Operator Workstations provide an interface
   to the human operator. They may receive the customer's recorded
   request (e.g. name and city of requested listing), information from
   listing or other databases, and also terminate a multimedia session
   with the customer.  Operator workstations are specialized SIP
   endpoints, and may be modeled in various ways, such as UAs or media
   servers.


Haluska, et al.          Expires May 18, 2008                 [Page 22]


Internet-Draft      Information Services Using SIP        November 2007


   PSTN Gateways - OISPs need to interface with the PSTN. Thus,
   gateways are needed to interface between the OISP and both
   signaling and bearer. The bearer is handled by trunk gateways,
   which interface RTP streams on the OISP side to TDM trunks on the
   PSTN side. The signaling may be handled by signaling gateways which
   interface SS7 on the PSTN side and SIP on the OISP side. Currently
   in North America, inband signaling on MF trunks is common for
   interfacing to OISPs, and trunk gateways need to be able to
   interpret and report as well as generate the appropriate MF
   signaling.

   Service Databases - Service Databases store service specific
   information (e.g. listing information such as name, address, and
   phone number, etc.) These may be located in the OISP's network
   and/or in other networks, and more than one may be used.

   SIP Proxy - One or more SIP proxies may be present in the OISP
   network, to facilitate SIP communications with other providers as
   well as to perform call processing functions between OISP
   components.

   The following figure shows a simplified view of an OISP internal
   architecture. The lines show logical connectivity; elements
   communicate via the proxy. A single OIS-AS is shown, along with up
   to "k" OIS-MS and up to "m" Operator Work Stations, and an ACD
   server. Communications between elements are assumed to traverse a
   proxy, which has been omitted from the figure for brevity.





                +--------+   +---------+   +---------+
                | OIS-AS |-+-| OIS-MS1 |...| OIS-MSk |
                +--+-----+ | +---------+   +---------+
                   |
                   |       | +---------+   +---------+
                   |       +-| OWS1    |...| OWSk    |
                +--+--+    | +---------+   +---------+
                | ACD |    |
                +-----+    | +--+---+
                           +-|PSTNGW|
                             +------+

          Figure 5 Simplified view of OISP Internal Architecture




Haluska, et al.          Expires May 18, 2008                 [Page 23]


Internet-Draft      Information Services Using SIP        November 2007




7. General Approach

   This section describes one possible way to implement DA using SIP.
   Other ways may be possible.

   The general approach involves having the OIS-AS host most of the
   processing logic, and to control the call in general. The OIS-AS
   implements a third party call control (3PCC) functionality, as
   described in [RFC3725]. It terminates the signaling dialog from the
   caller, and originates dialogs towards other components as
   necessary. There may be multiple sequential sessions set up during
   the course of a DA call.

   For example, the OIS-AS would initiate a new dialog towards a MS
   for front-end automation. When it gets the 200 OK from the MS with
   SDP, it passes that SDP back toward the caller. When the front end
   automation has completed, the OIS-MS sends a BYE containing message
   bodies conveying the success of the operation (i.e., was it able to
   obtain the listing) as well as any data related to the operation.
   In case of success, the body might carry the listing information,
   or a URI pointing to it. In case of failure, it might carry a URI
   pointing to the whisper file.

   In case of failure, the OIS-AS would determine that the call needs
   to be routed to a human operator. The OIS-AS first needs to
   identify a suitable operator to handle this request. The ACD server
   has this responsibility, and could be implemented as a redirect
   server facing the OIS-AS, redirecting towards the best suited
   available operator. Facing the operator workstations, the ACD
   server could be implemented as a presence server, maintaining
   availability of each operator, as well as the associated
   information for each (e.g. languages, skill level, cost, etc).

   The OIS-AS would then send an INVITE toward the identified operator
   workstation. This INVITE includes the caller's SDP as well as a URI
   pointing to the whisper file. The workstation could play the
   whisper to the operator as the call is answered. The operator
   workstation's SDP would be passed back to the caller via a re-
   INVITE or UPDATE request.

   If the operator is successful in locating the desired listing, the
   workstation would send a BYE containing message bodies with an
   indication of success, and either the listing information of a
   pointer to the same.



Haluska, et al.          Expires May 18, 2008                 [Page 24]


Internet-Draft      Information Services Using SIP        November 2007


   The OIS-AS would then initiate a call leg towards an OIS-MS for
   back end automation. The INVITE would include the same body with
   the listing information that was sent by the operator workstation.
   The OIS-MS returns its SDP, which the OIS-AS would propagate back
   over the originating leg via a re-INVITE or UPDATE request. The
   back end automation process includes audibly playing out the
   listing information, and possibly offering call completion service.
   The OIS-MS sends a BYE with a message body indicating whether call
   completion is desired.

   If call completion is desired, the OIS-AS sends a REFER back over
   the originating call leg to the caller, and clears the call.

   These examples describe simple voice scenarios. Other media types
   may be possible. For example, it may be desirable to send the
   listing information via text message to the caller's terminal, or
   to show a video clip. Such features require knowledge of the
   calling terminal's capabilities and characteristics. The mechanism
   described in RFC 3840 Indicating User Agent Capabilities in the
   Session Initiation Protocol (SIP)can be used for this. The
   capabilities might have been signaled in the initial INVITE
   request. Otherwise, the OIS-AS can query for capabilities using an
   OPTIONS request. Additionally, some non SIP mechanism might be
   used, such as querying a database (e.g. IMS HSS) in the caller's
   network.

   References to a whisper file can be passed using the mechanism
   described in RFC 4483 A Mechanism For Content Indirection in the
   Session Initiation Protocol (SIP).

   Other information signaled via message bodies includes the success
   or failure status of operations (such as identifying the requested
   listing), or other data (such as the listing information).

   Context information may be maintained on a per call basis. It could
   include such information as the caller's preferred language, etc. A
   URI pointing to the context information could be passed between
   elements in the OISP infrastructure.

   Note that the IETF MEDIACTRL working group is currently developing
   mechanisms for control of SIP based MSs by ASs; this work may be
   applicable for OIS as well.







Haluska, et al.          Expires May 18, 2008                 [Page 25]


Internet-Draft      Information Services Using SIP        November 2007


8. Signaling Mechanisms

   This section discusses the signaling mechanisms required to provide
   OIS services.

8.1. Calling Party's Identity

In many cases, downstream providers may need to know the calling
party's identity. This might be needed to influence call processing,
or for accounting purposes. Also, the calling party's identity in the
form of a SIP URI might be needed so that the identity of the home
provider can be determined.

The calling party's equipment populates the From header in SIP
messages. This is not trusted. There are several methods for providing
"network-asserted identities", which under the appropriate conditions
can be trusted.

The SIP Identity mechanism defined in [RFC4474] provides a
standardized, architecture agnostic SIP mechanism for
cryptographically assuring the user's identity.

The P-Asserted-Identity header [RFC3325] is a private extension which
can be used to carry a network asserted identity of the caller between
trusted providers.

Note that some networks may allow their users to hide their identity.
In the current North American PSTN, for such cases the caller id
information is often transported through the network, marked with a
privacy indication such that it will not be presented to the called
party.

Bilateral agreements between VOIP providers determine whether
providers are within the same "trust domain" as defined in [RFC3324],
and what information, including network-asserted identities, may be
exchanged between providers. Depending on such agreements, it is
possible that the caller identity information is obscured or
completely absent. As indicated in [RFC3325], "Masking identity
information at the originating user agent will prevent certain
services, e.g., call trace, from working in the Public Switched
Telephone Network (PSTN) or being performed at intermediaries not
privy to the authenticated identity of the user."

When an OISP is outside any trust domain with the caller's home
provider, or is not otherwise privy based on bilateral agreements to
network asserted identity information from the calling network when



Haluska, et al.          Expires May 18, 2008                 [Page 26]


Internet-Draft      Information Services Using SIP        November 2007


the caller has requested privacy, it is unable to implement any call
processing logic based on such information.

If the OISP desires to reject anonymous calls, a mechanism is proposed
in "Rejecting Anonymous Requests in the Session Initiation Protocol
(SIP) - draft-ietf-sip-acr-code-03", which defines a specific response
code for this.

The following shows an example of an INVITE message contain a P-
Asserted-Identity header.



   INVITE sip:da@provider-c.example SIP/2.0
   Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9
   Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
   Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9
   From: <sip:7327581234@provider-a.com>;tag=1234567
   To: 411 <tel:+411>
   Contact: <sip:7327581234@provider-a.com>
   P-Asserted-Identity: "732758123" <sip:73237581234@provider-a.com>
   Content-Type: application/sdp
   Content-Length: ...
   [SDP not shown]




8.2. Provider Identification

   As discussed, in some deployment scenarios, the OISP makes use of
   the identities of other providers involved in the call. This
   section discusses how those identities can be conveyed using SIP.



8.2.1. Home Provider

In many cases, the OISP needs to identify the caller's Home Provider.
This may be needed for branding purposes as well as to potentially
influence treatment in other ways.

The basic mechanism for determining the home provider is to derive it
from the right hand side (RHS) of the network asserted identity.

In SIP, identities are expressed as URIs. These can be SIP (or SIPS)
URIs, or "tel" URIs.


Haluska, et al.          Expires May 18, 2008                 [Page 27]


Internet-Draft      Information Services Using SIP        November 2007


[1] defines the SIP URI, which is used for identifying SIP resources.
The RHS can be expressed as a DNS domain name or as an IPv4 or IPv6
address. The hostname format is most suitable for providing an
identity to reach the calling party. For instance the mechanisms
defined in [RFC3263] for locating SIP servers depends on the use of
domain names for the various types of DNS lookups such as NAPTR, SRV,
and A.

If a provider decides to provide network asserted identities expressed
as SIP URIs using IP addresses instead of hostnames, it forfeits the
use of such standardized mechanisms for reaching its users. It also
becomes difficult to derive the home provider identity from the
network asserted identity.

RFC3966 defines the "tel" URI, which is used for describing resources
identified by phone numbers. The "tel" URI format does not include a
hostname. Thus, if the network asserted identity includes only a "tel"
URI, no direct information about the home provider is provided.

The SIP Identity mechanism is intended for use with SIP URIs. The PAI
mechanism can use either a SIP URI, a "tel" URI, or both.

This document depends on the home provider providing a network
asserted identity containing a hostname. This includes the SIP
identity where the SIP URI contains a hostname, or a PAI header
containing at least a SIP URI with a hostname.

Very simply, the RHS of the hostname in the SIP URI is extracted and
used as the basis to influence call processing. In cases where the
caller's identity is not available, as discussed in the  "Calling
Party's Identity" section, then the home provider's identity is
consequently also not available, and call processing logic based on
such information (such as branding) cannot take place.









8.2.2. Intermediate Provider

In some cases, the OISP may need to know the identity of an
intermediate provider which the call has traversed. Recall that for
our purposes, we define "intermediate provider" as having a business


Haluska, et al.          Expires May 18, 2008                 [Page 28]


Internet-Draft      Information Services Using SIP        November 2007


relationship with both the home provider (to handle OIS requests) and
with an OISP (which will actually provide the requested service.) This
may be needed to influence treatment.

The use of the SIP History-Info mechanism defined in RFC 4244, An
Extension to SIP for Request History Information, can be used for
this. As the call moves from one provider to the next and is
retargeted, corresponding entries are added to the SIP History-Info
header. If the domain name format is used for the retargeted entities,
then the History-Info header now includes a list of traversed SIP
domains or providers, which can be consulted by the OISP.

According to RFC 4244, entries should be added to the History-Info
header whenever the Request-URI is modified. Cases may exist where the
call is sent to another provider but the URI is not modified. In such
cases, the provider is not captured by the History-Info header.

The following figure illustrates the use of the History-Info header
for this purpose.



    Caller        Provider-A     Provider-B     Provider-C
      |              |              |              |
      |              |              |              |
      |              |              |              |
      |(1) INVITE tel:+411          |              |
      |------------->|              |              |
      |              |              |              |
      |              |              |              |
      |              |(2) INVITE sip:da@prov-b.net |
      |              |------------->|              |
      |              |              |              |
      |              |              |              |
      |              |              |(3) INVITE sip:da@prov-c.net
      |              |              |------------->|
      |              |              |              |
      |              |              |              |

   Figure 6 Use of History-Info header to identity traversed providers




1. The user dials ''411", and the resulting INVITE to its home proxy is
for "tel: +411". No History-Info header is included yet.



Haluska, et al.          Expires May 18, 2008                 [Page 29]


Internet-Draft      Information Services Using SIP        November 2007


   INVITE tel:+411 SIP/2.0
   (other message content omitted)




2. The home proxy retargets this to ''sip:da@prov-b.net'', and adds a
History-Info header which includes the targeted-from URI:

   INVITE sip:DA@prov-b.net SIP/2.0
   History-Info: <tel: +411>; index=1
   (other message content omitted)


3. Proxy-B retargets this to "SIP: da@prov-c.net", and appends another
entry to the History-Info header:

   INVITE sip:DA@prov-b.net SIP/2.0
   History-Info: <tel: +411>; index=1, <sip:da@prov-b.net>; index=2
   (other message content omitted)


When this request arrives a Proxy-C in Provider C (OISP), it conveys
the following:

     oThe Request-URI (SIP: da@prov-c.net) indicates this as a DA call

     oThe History-Info header conveys the history of the request:

     oIt started as a tel URI for digits ''411''

     oIt was then targeted to provider B

     oIt is now targeted to provider C

Please note that if a transit provider were encountered, the transit
provider would simply route the request toward Provider C, and would
not perform retargeting. It would not modify the Request-URI nor the
SIP History-Info header contents.



8.3. Originating Station Type

In the current PSTN in North America, OIS providers have the ability
to tailor treatment based on the type of originating station. For
instance, calls from prison phones are restricted from accessing DA


Haluska, et al.          Expires May 18, 2008                 [Page 30]


Internet-Draft      Information Services Using SIP        November 2007


services. Example values include POTS, coin, hospital, prison/inmate,
cellular, etc. In the PSTN in North America, this information is
signaled for SS7 calls using the Originating Line Information (OLI)
information element, and in MF calls using the ANI II digits. To
support interworking with the PSTN, it must be possible to convey the
Originating Station Type value. The ability to convey this information
natively with SIP is currently lacking.

It is also desirable to characterize certain types of originating SIP
based callers using these same values, e.g. prison, police, etc.



This problem is one example of a more general problem where the OISP
interworks with the PSTN, but the AS needs only a small subset of the
PSTN parameters. While SIP-T [RFC3372] has been developed to allow
full ISUP messages to be carried in SIP message, Narrowband Signaling
Syntax (NSS) [NSS] allows individual ISUP parameters to be conveyed.

When the PSTN GW receives an ISUP message containing the Charge Number
parameter, it can form an NSS body per [NSS] and include this
parameter. Other ISUP parameters of relevance can also be included.
The appropriate SIP message is formed and sent to the AS.

A separate issue is the ability to convey Charge Number information
for SIP originations. This may make not make sense in all
environments. In some environments, it is necessary to convey this
information between service provider elements. In these cases, NSS
bodies as described above can be inserted by the appropriate
intermediaries with the originating provider. These would be the same
elements which would insert network asserted identities, such as the
P-Asserted-Identity header, and the information would be subject to
the same restrictions.



8.4. Trunk Group Identifier

The incoming trunk group number provides information which could be
used to influence call processing, thus this information is needed.
Trunks are point to point circuits and as such, their remote
termination point is unambiguously known. As such, knowledge of the
incoming trunk group conveys the identity of the provider offering the
call.

For PSTN interworking, the incoming trunk group identifier is a key
piece of information and must be known. Thus, at a PSTN to IP


Haluska, et al.          Expires May 18, 2008                 [Page 31]


Internet-Draft      Information Services Using SIP        November 2007


interworking point, the trunk group information must be kept and
signaled forward. This holds for OISP's accepting incoming calls from
the PSTN as well as upstream providers accepting calls from the PSTN.

[RFC4904], "Representing trunk groups in tel/sip Uniform Resource
Identifiers (URIs)" defines a way to signal incoming and/or outgoing
trunk group information as a parameter in SIP URIs and tel URIs.

To represent incoming trunk groups, the trunk group parameter is
included in the Contact header of the SIP message. The "trunk-context"
parameter should also be included, to ensure that the trunk group is
unambiguously identified, since trunk group numbers are not globally
unique.

The following example shows an INVITE containing a trunk group
identification in the Contact header:



   INVITE sip:da@provider-c.com SIP/2.0
   Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9
   Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
   Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9
   From: <sip:7327581234@provider-a.com>;tag=1234567
   To: 411 <tel:+411>
   Contact: < sip:7327581234@provider-b.com;tgrp=101; trunk-
   context=provider-b.com@proxy-b.provider-b.com;user=phone>
   P-Asserted-Identity: "7327581234" <sip:73237581234@provider-a.com>
   Content-Type: application/sdp
   Content-Length: ...




8.5. Dialed Digits

Currently in the North American PSTN, the OIS provider may take into
account the digits dialed by the user. In that scenario the dialed
digits are frequently forwarded to the OIS provider.

Using SIP, the dialed digits would typically be sent by the user's
equipment in the form of a tel URI or SIP URI in the Request-URI of a
SIP INVITE. It is possible that retargeting could take place, in which
case the dialed digits would be lost.

The SIP History-Info mechanism defined in RFC 4244 provides a
mechanism for solving exactly this type of problem. It defines a new


Haluska, et al.          Expires May 18, 2008                 [Page 32]


Internet-Draft      Information Services Using SIP        November 2007


optional SIP header, History-Info, to provide a standard mechanism for
capturing the request history information. Whenever a node which
supports this mechanism modifies the Request-URI of a request, it
captures this in the History-Info header.

The following example shows an INVITE containing a History-Info
header, which conveys the original dialed digits, after having been
retargeted.

   INVITE sip:DA@prov-b.net SIP/2.0
   (other message content omitted)
   History-Info: <tel: +411>; index=1, <sip:da@prov-b.net>; index=2


Please see the section titled "Arbitrary Involved Provider" for an
example of a flow where the History-Info mechanism delivers the dialed
digits to the OISP when retargeting has occurred.



8.6. Retargeting to Identify the Desired Service

It is necessary to identify the service being requested. Such services
might include directory assistance with or without call completion.
The logic to determine this might reside in one or more points in the
network. Additionally, the identification of the service might be
refined as the request traverses potentially multiple networks,
depending on the availability of additional information.

It is proposed here to retarget the Request-URI of the SIP request to
specify the desired service. While the initial Request-URI might
specify "SIP:411@provider-a.net", a downstream element might invoke
service logic and determine that this call should be sent to OISP C's
network for directory assistance with call completion, and change the
Request-URI to "SIP:da-with-call-completion@oisp-c.net".

A similar approach is taken for identifying resources in [RFC4240].

[CSI], a work in progress, discusses explicit service identifiers for
using in IMS [IMS] based networks.



8.7. Charge Number

   There is a need to convey a charge number, which may differ from
   the calling party's identity. The charge number usually identifies


Haluska, et al.          Expires May 18, 2008                 [Page 33]


Internet-Draft      Information Services Using SIP        November 2007


   the customer or account with which the caller is associated, e.g.
   the main number for a business which has many individual calling
   numbers. This might be needed for accounting, but it also could
   influence call processing, especially when a particular type of
   service applies for any caller associated with a particular charge
   number.

   There is currently no IETF standardized mechanism to convey the
   Charge Number in SIP. The need to convey equivalent information for
   SIP based callers is also under investigation.

   The Charge Number information is very similar to the Originating
   Station Type, and can be conveyed for both PSTN and SIP
   originations using the same mechanisms discussed above for that
   information.











8.8. Passing Whisper

   During front end automation, the OIS-MS will record and may time
   compress the caller's perhaps meandering speech into what is known
   as the "whisper". This is intended to be played into a human
   operator's ear, should the call be referred to an operator, to
   avoid the operator from having to prompt the caller again. The
   whisper is obtained during the front end automation, and saved to
   an audio file.

   If the call needs to be transferred to a human operator, the
   whisper will need to be played to the operator at the same time or
   slightly prior to connecting the caller to the operator. Thus, the
   operator workstation needs to be able to access the whisper file.

   When the OIS-MS performs front end automation, it generates the
   whisper and saves it as an audio file. The location, storage type,
   and format are out of the scope of this document. What is needed is
   a way for the OIS-MS to convey the whisper information to the OIS-
   AS, so it could potentially be used for later processing, such as
   passing to a human operator.


Haluska, et al.          Expires May 18, 2008                 [Page 34]


Internet-Draft      Information Services Using SIP        November 2007


   Due to size constraints, it may not be feasible or desirable to
   pass the actual audio file containing the whisper. This document
   will discuss the most general case of passing a pointer, in the
   form of a URI, to the audio content. What follows is a description
   of one possible way to implement this. The work of the recently
   formed IETF MEDIACTRL working group may provide alternatives.

   Since the whisper is an output of the front end automation process,
   it makes sense to return this upon completion of that process. The
   most reasonable time to do this is when the OIS-MS sends the BYE.

   Any SIP request, including BYE, can contain a message body. RFC
   4483 A Mechanism for Content Indirection in Session Initiation
   Protocol (SIP) Messages defines an extension to the URL MIME
   External-Body Access-Type to satisfy the content indirection
   requirements for SIP. These extensions are aimed at allowing any
   MIME part in a SIP message to be referred to indirectly via a URI.

   This is illustrated in the following figure. Note that the proxy
   has been omitted for clarity, as have some messages not crucial to
   illustrating the use of this mechanism. All SIP signaling traverses
   the proxy.



























Haluska, et al.          Expires May 18, 2008                 [Page 35]


Internet-Draft      Information Services Using SIP        November 2007



            AS             MS          Operator
             |              |              |
             |              |              |
             |              |              |
             |(1) INVITE    |              |
             |------------->|              |
             |              |              |
             |              |              |
             |(2) 200 OK    |              |
             |<-------------|              |
             |              |              |
             |              |              |
             |MS prompts user, collects whisper
             |              |              |
             |              |              |
             |              |              |
             |(3) BYE, body w. status, whisper URI
             |<-------------|              |
             |              |              |
             |              |              |
             |(4) 200 OK    |              |
             |------------->|              |
             |              |              |
             |              |              |
             |(5) INVITE w. whisper URI    |
             |---------------------------->|
             |              |              |
             |              |              |
             |(6) 200 OK SDP|              |
             |<----------------------------|
             |              |              |
             |              |              |
             |              |              |
             |              |              |

            Figure 7 Call flow illustrating passing of whisper





   1. INVITE AS->MS
   INVITE sip:da@ms-1.oisp-c.net SIP/2.0
   [remainder of message omitted]




Haluska, et al.          Expires May 18, 2008                 [Page 36]


Internet-Draft      Information Services Using SIP        November 2007


   2. 200 OK MS->AS
   SIP/2.0 200 OK
   [remainder of message omitted]


   3. BYE MS->AS
   BYE sip:as-1@as-1.oisp-c.net SIP/2.0
   [non relevant portions of message omitted]
   Content-Type: message/external-body; access-type="URL";
       URL="http://ms1.oisp-c.net/whisper/20070206092700-0001.wav"
       expiration="Tues, 06 Feb 2007 09:30:00 GMT";
   <CRLF>
   Content-Type: audio/x-wav
   Content-Disposition: render
   <CRLF>



   4. 200 OK AS->MS
   SIP/2.0 200 OK
   [remainder of message omitted]


   5. INVITE AS->Operator Workstation
   INVITE sip:operator@operator-123.oisp-c.net SIP/2.0
   [non relevant portions of message omitted]
   Content-Type: message/external-body; access-type="URL";
       URL="http://ms1.oisp-c.net/whisper/20070206092700-0001.wav"
       expiration="Tues, 06 Feb 2007 09:30:00 GMT";
   <CRLF>
   Content-Type: audio/x-wav
   Content-Disposition: render
   <CRLF>


   6. 200 OK Operator->AS
   SIP/2.0 200 OK
   [remainder of message omitted]


   Note that this same mechanism also supports the case where front
   end automation is performed by one provider, and another provider
   provides the operator assistance. In this type of scenario,
   provisions need to made such that the second provider can access
   the resources referenced by the URI.




Haluska, et al.          Expires May 18, 2008                 [Page 37]


Internet-Draft      Information Services Using SIP        November 2007


8.9. Calling Equipment Capabilities and Characteristics



   It may be necessary for the OIS provider to learn the capabilities
   and characteristics of the caller's equipment. This would be useful
   when the OIS provider wishes to provide content to the caller other
   than that which was used on the call to the OISP. For example, the
   OIS provider might wish to send listing information via text
   message, or play a video clip about a particular venue about which
   he has requested information.

   RFC 3840 Indicating User Agent Capabilities in the Session
   Initiation Protocol (SIP), defines mechanisms by which a UA can
   convey its capabilities and characteristics to other user agents
   and to the registrar for its domain. This information is conveyed
   as parameters of the Contact header field.

   This information might be included in the incoming INVITE to the
   OISP, if the caller's UA supports this mechanism and is configured
   to do so. Otherwise, the OISP could query the caller's UA by
   sending a SIP OPTIONS request, and the UA, if it supports this
   mechanism, would include its capability feature tags in the
   response to the OISP.

   The following is an example of an INVITE containing capability
   feature tags, as it arrives at the OISP. In this case, the UA
   supports audio, video, and text. Other included tags provide
   additional information.



   INVITE sip:da@provider-c.com SIP/2.0
   Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9
   Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
   Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9
   From: <sip:7327581234@provider-a.com>;tag=1234567
   To: 411 <tel:+411>
   Contact: <sip:7327581234@provider-a.com>;audio;video;text
        ;actor="principle";automata;mobility="fixed"
        ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
   P-Asserted-Identity: "7327581234" <sip:73237581234@provider-a.com>
   P-Asserted-Identity: tel:+7327581234
   Content-Type: application/sdp
   Content-Length: ...
   [SDP not shown]



Haluska, et al.          Expires May 18, 2008                 [Page 38]


Internet-Draft      Information Services Using SIP        November 2007


   If the OISP wishes to query the UA, it can send an OPTIONS request
   to the UA, and the UA, if it supports this mechanism, would include
   the feature capability tags in the Contact header, as show above,
   in the 200 OK response.





8.10. Media Server Returning Data to the Application Server

   The OIS-AS needs to know the outcome of the operations performed by
   the OIS-MS, e.g. success/failure of front end automation, etc. Some
   mechanism is needed to convey this information. This could be
   conveyed using non SIP mechanisms.

   Any SIP message, including BYE, can carry message bodies. The
   simplest way for a OIS-MS to return data to an OIS-AS is to
   encapsulate the data in a MIME body. This requires agreement
   between both sides on the format and semantics of these bodies.

   Another approach is to use the content indirection mechanism to
   point to the data, however this may be rather cumbersome if only a
   small amount of data is to be returned.

   Some OIS service may make use of VoiceXML, whereby the OIS-AS
   invokes VoiceXML scripts on the OIS-MS, and the OIS-MS returns data
   to the OIS-AS. SIP Interface to VoiceXML Media Services - draft-
   burke-vxml-03.txt (work in progress) describes a SIP interface to
   VoiceXML media services, which is commonly employed between
   application servers and media servers offering VoiceXML processing
   capabilities. This may be found useful for OIS services.

   The topic of application server control of media services is
   currently under study, and is the subject of the IETF MEDIACTRL
   working group's efforts.

   This information can also be conveyed using non SIP mechanisms.
   Describing such mechanisms is out of the scope of this document.



8.11. Service Discovery

   An OISP might desire that its service be discoverable on the
   internet, instead of or in addition to static provisioning into
   provider networks. The Service URN concept discussed in the work in


Haluska, et al.          Expires May 18, 2008                 [Page 39]


Internet-Draft      Information Services Using SIP        November 2007


   progress "A Uniform Resource Name (URN) for Services - draft-ietf-
   ecrit-service-urn-05" can be used to facilitate this. This allows
   for discovery of the service in a context dependent manner, where
   context could include for example the user's location. Thus a user
   agent could send a SIP request to "urn: service: info", and this
   very generic URI could be resolved to a point to a specific network
   element belonging to a specific provider. If some other context
   information such as the user's location is available, this could be
   used to refine the resolution to e.g. an element best suited for
   that particular location.



9. Example Call Flow - Directory Assistance



9.1. Basic Flow

   The following call flow provides examples of how a DA service could
   be implemented using the mechanisms described in this document. It
   is intended to illustrate the intended use of the proposed
   signaling mechanism. Some messages not crucial to this may be
   omitted for clarity.

























Haluska, et al.          Expires May 18, 2008                 [Page 40]


Internet-Draft      Information Services Using SIP        November 2007


   Caller    Proxy A   Proxy B   Proxy C   OIS-AS    OIS-MS1
      |         |         |         |         |         |
      |         |         |         |         |         |
      |         |         |         |         |         |
      |(1) INVITE tel:411 |         |         |         |
      |-------->|         |         |         |         |
      |         |         |         |         |         |
      |         |(2) INVITE sip:da@prov-b.com |         |
      |         |-------->|         |         |         |
      |         |         |         |         |         |
      |         |         |(3) INVITE sip:da@prov-c.com |
      |         |         |-------->|         |         |
      |         |         |         |         |         |
      |         |         |         |(4) INVITE sip:da-cc@prov-c.com
      |         |         |         |-------->|         |
      |         |         |         |         |         |
      |         |         |         |         |(5) INVITE prompt &
   collect
      |         |         |         |         |-------->|
      |         |         |         |         |         |
      |         |         |         |         |(6) 200 OK w.SDP
      |         |         |         |         |<--------|
      |         |         |         |         |         |
      |         |         |         |(7) 200 OK w.SDP   |
      |         |         |         |<--------|         |
      |         |         |         |         |         |
      |         |         |(8) 200 OK w.sdp   |         |
      |         |         |<--------|         |         |
      |         |         |         |         |         |
      |         |(9) 200 OK w.sdp   |         |         |
      |         |<--------|         |         |         |
      |         |         |         |         |         |
      |(10) 200 OK w.sdp  |         |         |         |
      |<--------|         |         |         |         |
      |         |         |         |         |         |
      |         |         |         |         |         |
      |         |         |         |         |         |


                      Figure 8 DA Call flow, part 1





   For brevity, only relevant SIP headers will be shown. The following
   test refers to Figure 8.


Haluska, et al.          Expires May 18, 2008                 [Page 41]


Internet-Draft      Information Services Using SIP        November 2007


   The user, homed in provider A, initiates a request for an OIS
   service, for instance by dialing "411". The user's UA sends a SIP
   INVITE. It might contain a "tel" URI.

   1. INVITE UE -> Home Proxy

   INVITE tel:+411 SIP/2.0
   Via: SIP/2.0/UDP client.provider-a.com:5060
   ;branch=z9hG4bK74bf9
   From: <sip:7327581234@provider-a.com>;tag=1234567
   To: 411 <tel:+411>
   Contact: <sip:7327581234@provider-a.com>
   Content-Type: application/sdp
   Content-Length: ...




   The home provider knows nothing of OISP services, for instance it
   might be a rather small scale provider. It is essentially set up to
   forward all calls of this type to Provider B. It translates the
   Request-URI to a SIP URI and sends the call on to provider B.
   Because of this retargeting, it adds a History-Info header to
   capture the dialed digits.



   The caller's identity is verified in a manner consistent with this
   provider's policies, and the proxy adds two P-Asserted-Identity
   headers: one with a SIP URI, and another with a "tel" URI.



















Haluska, et al.          Expires May 18, 2008                 [Page 42]


Internet-Draft      Information Services Using SIP        November 2007




   2. INVITE proxy-a -> proxy-b

   INVITE sip:411@provider-b.com SIP/2.0
   Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
   Via: SIP/2.0/UDP client.provider-a.com:5060
   ;branch=z9hG4bK74bf9
   From: <sip:7327581234@provider-a.com>;tag=1234567
   To: 411 <tel:+411>
   Contact: <sip:7327581234@provider-a.com>
   P-Asserted-Identity: "7327581234" <sip:73237581234@provider-a.com>
   P-Asserted-Identity: tel:+7327581234
   History-Info: <tel: +411>; index=1
   Content-Type: application/sdp
   Content-Length: ...



   Proxy-b in provider-b's network receives the request. This is a
   larger network, and it has business relationships with several OIS
   providers, as well as with several providers which serve
   subscribers. This provider has logic which requires it to query the
   Home Provider's network to find some information related to the
   caller. This is not likely to be a SIP related function, and is
   thus out of scope for this document. The logic executes, taking the
   result of this query into account. It is determined that the call
   is for directory assistance, and that the call should be routed to
   provider C for handling.



   So, proxy-b retargets the Request-URI to reflect this, and routes
   the call to provider C (the OISP). It adds another entry to the
   History-Info header to capture this retargeting.














Haluska, et al.          Expires May 18, 2008                 [Page 43]


Internet-Draft      Information Services Using SIP        November 2007



   3. INVITE proxy-b -> proxy-c

   INVITE sip:da@provider-c.com SIP/2.0
   Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9
   Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
   Via: SIP/2.0/UDP client.provider-a.com:5060
   ;branch=z9hG4bK74bf9
   From: <sip:7327581234@provider-a.com>;tag=1234567
   To: 411 <tel:+411>
   Contact: <sip:7327581234@provider-a.com>
   P-Asserted-Identity: "732758123" <sip:73237581234@provider-a.com>
   P-Asserted-Identity: tel:+7327581234
   History-Info: <tel: +411>; index=1, <sip:da@provider-a.com>;
   index=2
   Content-Type: application/sdp
   Content-Length: ...



   Proxy-c in provider C's network receives the request. The source of
   the request is authenticated via mechanisms not described here. It
   needs to know how to bill this call, and thus needs to know which
   provider it came from. It looks at the topmost Via header, and sees
   that the call came from provider B.

   It examines the History-Info header, and is able to identity the
   dialed digits. It can also determine from the SIP URI which domains
   have been traversed, as long as each has retargeted and appended an
   entry in the header.

   The proxy determines that the call needs to go the OIS-AS for
   handling, so it retargets if necessary and forwards the INVITE.

   The OIS-AS performs 3PCC. It determines that the call needs a
   branded announcement based on the identity of the home provider,
   which it derives from the P-Asserted-Identity header. It initiates
   a new call leg toward OIS-MS1 for front end automation. Per
   [RFC4240], the "dialog" portion of the Request-URI indicates the
   "prompt & collect" service. The URI identifies the VoiceXML script
   to be executed. The SDP is the caller's SDP.








Haluska, et al.          Expires May 18, 2008                 [Page 44]


Internet-Draft      Information Services Using SIP        November 2007



   5. INVITE OIS-AS -> MS1

   INVITE sip:dialog@ois-as.prov-c.com; \
          voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml \
   SIP/2.0
   Via: SIP/2.0/UDP ois-as.prov-c.com:5060
   ;branch=z9hG4bK74bf9
   From: <sip:ois-as@ois-as.prov-c.com>;tag=1234567
   To: sip:dialog@ois-as.prov-c.com; \
          voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
   Contact: <sip:ois-as@ois-as.prov-c.com>
   Content-Type: application/sdp
   Content-Length: ...



   The OIS-MS responds with a 200 OK, with its own SDP. The OIS-AS now
   sends a 200 OK response back toward the caller, with the MS's SDP.
   Note that the OIS-AS could first have sent non final response back
   toward the user.




























Haluska, et al.          Expires May 18, 2008                 [Page 45]


Internet-Draft      Information Services Using SIP        November 2007




   Caller    OIS-AS    OIS-MS1     ACD       OWS
      |         |         |         |         |
      |         |         |         |         |
      |         |         |         |         |
      |(11) RTP session   |         |         |
      |...................|         |         |
      |         |         |         |         |
      |         |(12) INFO w.URI, body        |
      |         |<--------|         |         |
      |         |         |         |         |
      |         |(13) INVITE        |         |
      |         |------------------>|         |
      |         |         |         |         |
      |         |(14) 3xx |         |         |
      |         |<------------------|         |
      |         |         |         |         |
      |         |(15) INVITE        |         |
      |         |---------------------------->|
      |         |         |         |         |
      |         |(16) 200 OK        |         |
      |         |<----------------------------|
      |         |         |         |         |
      |         |(17) BYE |         |         |
      |         |-------->|         |         |
      |         |         |         |         |
      |         |(18) 200 OK        |         |
      |         |<--------|         |         |
      |         |         |         |         |
      |(19) re INVITE     |         |         |
      |<--------|         |         |         |
      |         |         |         |         |
      |(20) 200 OK        |         |         |
      |-------->|         |         |         |
      |         |         |         |         |
      |(21) RTP session   |         |         |
      |.......................................|
      |         |         |         |         |
      |         |(22) BYE |         |         |
      |         |<----------------------------|
      |         |         |         |         |
      |         |(23) 200 OK        |         |
      |         |---------------------------->|
      |         |         |         |         |
      |         |         |         |         |
      |         |         |         |         |


Haluska, et al.          Expires May 18, 2008                 [Page 46]


Internet-Draft      Information Services Using SIP        November 2007


                      Figure 9 DA Call flow, part 2



   The following text refers to Figure 9.

   The user is now connected (11) to the MS, which plays a branded
   announcement, and prompts for the listing information. When the
   user speaks his request, the MS processes the audio to obtain a
   "whisper" file, or condensed version of the request. In this
   example, the MS is unable to successfully perform the query, so it
   sends an indication of this to the AS. In this example, the
   indication is sent using an as yet unspecified protocol message
   carried in a message body in a SIP INFO message, which also carries
   a URI which points to the whisper file. Other mechanisms, including
   non SIP mechanisms, could also be used to this end (this is the
   subject of further study). The AS allows the caller to remain
   connected to the MS while it sets up a call to an operator
   workstation (OWS), allowing for the possibility to play custom
   announcements to the caller.

   The OIS-AS decides based on the failure indication that it needs to
   route the call to a human operator. It sends an INVITE (13) to the
   ACD server. This INVITE carries information about the required
   characteristics, such as language and skill set, of the operator
   which should be selected for this call. The means by which this
   information is carried has yet to be defined. One possible way an
   ACD could be implemented is as a presence server, such that it
   keeps track of the availability of all the operators. The Media
   Resource Broker being discussed in the IETF MEDIACTRL working group
   also represents an approach to ACD.

   In this example, the ACD server is implemented as a redirect server
   - it sends a 3XX response (14) which identifies the operator the
   OIS-AS should contact. Alternately, the ACD server could have
   proxied the request to the operator.

   The OIS-AS now sends an INVITE (15) containing the URI to the
   whisper, as well as the caller's SDP, to the indicated operator
   workstation. The operator workstation sends a 200 OK (16) with its
   SDP, which the OIS-AS sends toward the caller in a re-INVITE (19).
   Only when the workstation has sent a final response to the INVITE,
   the AS sends a BYE (17) to the MS.

   The caller is now connected to the operator (21), and the operator
   helps the caller with the listing. The operator workstation
   launches a query, and a response is received. The operator signals


Haluska, et al.          Expires May 18, 2008                 [Page 47]


Internet-Draft      Information Services Using SIP        November 2007


   a BYE (22) toward the OIS-AS, which may contain the listing
   information in a message body, a pointer (URI) to the listing
   information, or it may pass this information to the OIS-AS using
   some other, non SIP mechanism.









          Caller    OIS-AS    OIS-MS2
             |         |         |
             |         |         |
             |         |         |
             |         |(24) INVITE
             |         |-------->|
             |         |         |
             |         |(25) 200 OK
             |         |<--------|
             |         |         |
             |(26) re INVITE     |
             |<--------|         |
             |         |         |
             |(27) 200 OK        |
             |-------->|         |
             |         |         |
             |(28) RTP session   |
             |...................|
             |         |         |
             |         |(29) BYE w.body
             |         |<--------|
             |         |         |
             |(30) REFER         |
             |<--------|         |
             |         |         |
             |         |         |
             |         |         |
                      Figure 10DA Call flow, part 3








Haluska, et al.          Expires May 18, 2008                 [Page 48]


Internet-Draft      Information Services Using SIP        November 2007




   The following text refers to Figure 10.

   The OIS-AS sends an INVITE (24) to another OIS-MS, MS2, for back
   end automation. (Note that though MS2 is shown as a separate
   element, the functionality it provides may or may not require a
   separate element.) When it receives MS2's SDP in the 200 OK (25),
   it sends a re INVITE (26) toward the user to update the SDP. At
   this point an audio session is in place between the caller and the
   back end automation MS (28). The MS plays the listing information,
   and offers call completion service. The caller accepts, so OIS-MS2
   sends a BYE (29) with a message body containing the result of the
   call completion offer. Since call completion was requested, the
   OIS-AS sends a REFER (30) to the caller, to cause it to place a
   call to the listed party. The OIS-AS may or may not care about
   subsequent NOTIFYs from the caller, and drops out of the call.


9.2. OISP Drops Out at Call Completion Setup

   The OISP may want to support different call flow options with
   respect to call completion. Reasons for this may include the desire
   to free up resources quickly, provide additional functionality,
   etc. When the OISP wants to provide the listing information and
   free resources as soon as possible, a simple flow based on REFER
   can be used, as illustrated below.

   In this flow, the caller is already connected to an OISP resource
   such as an MS, and requests call completion. In (2), the OISP sends
   a REFER to initiate the call completion call. This simply causes
   the caller's UA to initiate the call(10), so the OISP drops the
   call by sending BYE in (6) toward the caller, as well as internally
   toward the MS. The various notifications sent by the caller to the
   OISP can be used to monitor progress of the call, or may simply be
   ignored from an application standpoints (from a protocol standpoint
   they must be acknowledged).












Haluska, et al.          Expires May 18, 2008                 [Page 49]


Internet-Draft      Information Services Using SIP        November 2007



          Caller           AS             MS        Called Party
             |              |              |              |
             |(1) Caller connected to e.g., MS            |
             |.............................|              |
             |              |              |              |
             |(2) REFER (Called)           |              |
             |<-------------|              |              |
             |              |              |              |
             |(3) 202 Accepted             |              |
             |------------->|              |              |
             |              |(4) BYE       |              |
             |              |------------->|              |
             |              |(5) 200 OK    |              |
             |              |<-------------|              |
             |              |              |              |
             |(6) BYE       |              |              |
             |<-------------|              |              |
             |(7) 200 OK    |              |              |
             |------------->|              |              |
             |              |              |              |
             |(8) NOTIFY    |              |              |
             |------------->|              |              |
             |(9) 200 OK    |              |              |
             |<-------------|              |              |
             |              |              |              |
             |(10) INVITE   |              |              |
             |------------------------------------------->|
             |(11) 200 OK   |              |              |
             |<-------------------------------------------|
             |              |              |              |
             |(12) NOTIFY (200 OK)         |              |
             |------------->|              |              |
             |(13) 200 OK   |              |              |
             |<-------------|              |              |


9.3. OISP Drops Out After Call Completion Call is Answered

   The OISP may need to remain in the signaling path until the call
   completion call is answered. One way to implement this is to use
   the REFER method with the Replaces header, as described in [RFC
   3891]. In this case, once the call completion call is answered (5),
   the OISP's AS sends a REFER (6) toward the caller with a Replaces
   header identifying the current dialog between the AS and called
   party, and Referred-by header identifying the AS. This causes an
   INVITE (10) to be sent toward the called party, also with Replaces


Haluska, et al.          Expires May 18, 2008                 [Page 50]


Internet-Draft      Information Services Using SIP        November 2007


   and Referred-by headers. As described in [RFC  3891], this causes a
   new session to be set up with the called party, replacing the
   existing sessions. As part of this, the original session is torn
   down (16). Thus, the OISP's resources are removed from the call.













































Haluska, et al.          Expires May 18, 2008                 [Page 51]


Internet-Draft      Information Services Using SIP        November 2007



   Caller           AS             MS        Called Party
     |              |              |              |
     |              |              |              |
     |              |              |              |
     |(1) Caller listening to announcements, etc  |
     |.............................|              |
     |              |              |              |
     |              |(2) INVITE    |              |
     |              |---------------------------->|
     |              |              |              |
     |              |(3) 183 Ringing              |
     |              |<----------------------------|
     |              |              |              |
     |              |(4) 200 OK    |              |
     |              |<----------------------------|
     |              |              |              |
     |              |(5) ACK       |              |
     |              |---------------------------->|
     |              |              |              |
     |[Called party has answered]  |              |
     |              |              |              |
     |(6) REFER (Called Party, Replaces:AS, Referred-by:AS)
     |<-------------|              |              |
     |              |              |              |
     |(7) 202 Accepted             |              |
     |------------->|              |              |
     |              |              |              |
     |(8) NOTIFY (100 Trying)      |              |
     |------------->|              |              |
     |              |              |              |
     |(9) 200 OK    |              |              |
     |<-------------|              |              |
     |              |              |              |
     |(10) INVITE (Replaces:AS, Referred-by:AS)   |
     |------------------------------------------->|
     |              |              |              |
     |(11) 200 OK   |              |              |
     |<-------------------------------------------|
     |              |              |              |
     |(12) ACK      |              |              |
     |------------------------------------------->|
     |              |              |              |
     |[Called Party replaces existing dialog from Step 2 with new one]
     |              |              |              |
     |              |              |              |
     |(13) RTP [Called and Calling Party are now connected ]


Haluska, et al.          Expires May 18, 2008                 [Page 52]


Internet-Draft      Information Services Using SIP        November 2007


     |............................................|
     |              |              |              |
     |              |              |              |
     |[ Remainder of steps cleanup dialogs between Caller-AS and AS-
   Called ]
     |              |              |              |
     |(14) NOTIFY (200 OK)         |              |
     |------------->|              |              |
     |              |              |              |
     |(15) 200 OK   |              |              |
     |<-------------|              |              |
     |              |              |              |
     |              |(16) BYE (as a result of receiving Replaces)
     |              |<----------------------------|
     |              |              |              |
     |              |(17) 200 OK   |              |
     |              |---------------------------->|
     |              |              |              |
     |(18) BYE      |              |              |
     |<-------------|              |              |
     |              |              |              |
     |(19) 200 OK   |              |              |
     |------------->|              |              |
     |              |              |              |


9.4. OISP Drops Out After Interaction with Called Party

   In this scenario, the OISP needs to interact with the called party,
   then desired to remove its resources from the call. Collect calls
   are one example where this might be used. This also uses REFER with
   Replaces. The OISP places a call to the called party, and
   interactions between OISP resources (automated or human) occur. The
   OISP then sends a REFER with Replaces and Referred-by to the
   calling party, which then sends an INVITE as described for the
   previous scenario.

   In this scenario, the OISP has one media session (1) with the
   caller and another (2) with the called party. After interactions
   have been completed, the OISP initiates the transfer by sending a
   REFER (3) with Replaces and Referred-by headers. This causes the
   caller's UA to send a corresponding INVITE (7) containing those
   headers. As with the previous scenario, this causes initiation of a
   new session replacing the existing session, as well as teardown
   (10) of the existing session.




Haluska, et al.          Expires May 18, 2008                 [Page 53]


Internet-Draft      Information Services Using SIP        November 2007



   Caller                AS                  MS                Called
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |[ Calling party has some RTP session with MS ]             |
     |                   |                   |                   |
     |                   |                   |                   |
     |(1) RTP            |                   |                   |
     |.......................................|                   |
     |                   |                   |                   |
     |[ Called party has different RTP session with MS ]         |
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |                   |(2) RTP            |
     |                   |                   |...................|
     |                   |                   |                   |
     |[ AS initiates transfer with REFER ]   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |(3) REFER (to called, Replaces:AS, Referred-by:AS)         |
     |<------------------|                   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |(4) 202 Accepted   |                   |                   |
     |------------------>|                   |                   |
     |                   |                   |                   |
     |(5) NOTIFY (trying)|                   |                   |
     |------------------>|                   |                   |
     |                   |                   |                   |
     |(6) 200 OK         |                   |                   |
     |<------------------|                   |                   |
     |                   |                   |                   |
     |[ Replaces header causes Called to replace old call with new ]
     |                   |                   |                   |
     |                   |                   |                   |
     |(7) INVITE (Replaces:AS, Referred-by:AS)                   |
     |---------------------------------------------------------->|
     |                   |                   |                   |
     |                   |                   |                   |
     |(8) 200 OK (SDP-called)                |                   |
     |<----------------------------------------------------------|
     |                   |                   |                   |
     |(9) ACK            |                   |                   |
     |---------------------------------------------------------->|
     |                   |                   |                   |
     |[ Calling and Called are now talking directly ]            |


Haluska, et al.          Expires May 18, 2008                 [Page 54]


Internet-Draft      Information Services Using SIP        November 2007


     |                   |                   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
   |[As a result of Replaces operation, called ends session with MS]
     |                   |                   |                   |
     |                   |(10) BYE (as a result of processing
   Replaces)
     |                   |<--------------------------------------|
     |                   |                   |                   |
     |                   |(11) 200 OK        |                   |
     |                   |-------------------------------------->|
     |                   |                   |                   |
     |[AS ends session with Calling]         |                   |
     |                   |                   |                   |
     |(12) BYE           |                   |                   |
     |<------------------|                   |                   |
     |(13) 200 OK        |                   |                   |
     |------------------>|                   |                   |
     |                   |                   |                   |
     |(14) NOTIFY (200 OK)                   |                   |
     |------------------>|                   |                   |
     |(15) 200 OK        |                   |                   |
     |<------------------|                   |                   |
     |                   |                   |                   |


9.5. OISP Remains in Path

   In some cases, the OISP desires to maintain its elements in the
   signaling path and possibly in the path as well for the duration of
   the call completion call. One possible reason for doing this is so
   that the caller can request to be returned to the OISP for
   additional services after the call has completed.

   The figure below begins with the caller already connected to OISP
   resources. The AS initiates call completion in steps 2 through 5 by
   sending an INVITE toward the called party. The AS then sends a re-
   INVITE toward the caller to update the SDP, and step 9 shows the
   media session established between the caller and the called party,
   and in step 10 clears the previous session with the MS. When the
   called party hangs up in step 12, the AS responds. In step 14, the
   AS has the opportunity to redirect the caller to a MS or other
   resource to offer additional services, but in this case simply
   clears the dialog with the caller.





Haluska, et al.          Expires May 18, 2008                 [Page 55]


Internet-Draft      Information Services Using SIP        November 2007



















































Haluska, et al.          Expires May 18, 2008                 [Page 56]


Internet-Draft      Information Services Using SIP        November 2007


   Caller           AS             MS        Called Party
      |              |              |              |
      |              |              |              |
      |              |              |              |
      |(1) Caller has media session with MS        |
      |.............................|              |
      |              |              |              |
      |AS initiates call completion |              |
      |              |              |              |
      |              |              |              |
      |              |(2) INVITE    |              |
      |              |---------------------------->|
      |              |              |              |
      |              |(3) 180 Ringing              |
      |              |<----------------------------|
      |              |              |              |
      |              |(4) 200 OK    |              |
      |              |<----------------------------|
      |              |              |              |
      |              |(5) ACK       |              |
      |              |---------------------------->|
      |              |              |              |
      |Called party has answered    |              |
      |              |              |              |
      |              |              |              |
      |(6) re-INVITE |              |              |
      |<-------------|              |              |
      |              |              |              |
      |(7) 200 OK    |              |              |
      |------------->|              |              |
      |              |              |              |
      |(8) ACK       |              |              |
      |<-------------|              |              |
      |              |              |              |
      |(9) Media Session            |              |
      |............................................|
      |              |              |              |
      |              |(10) BYE      |              |
      |              |------------->|              |
      |              |              |              |
      |              |(11) 200 OK   |              |
      |              |<-------------|              |
      |              |              |              |
      |Called party hangs up        |              |
      |              |              |              |
      |              |              |              |
      |              |(12) BYE      |              |


Haluska, et al.          Expires May 18, 2008                 [Page 57]


Internet-Draft      Information Services Using SIP        November 2007


      |              |<----------------------------|
      |              |              |              |
      |              |(13) 200 OK   |              |
      |              |---------------------------->|
      |              |              |              |
      |AS clears call back to Caller|              |
      |              |              |              |
      |              |              |              |
      |(14) BYE      |              |              |
      |<-------------|              |              |
      |              |              |              |
      |(15) 200 OK   |              |              |
      |------------->|              |              |
      |              |              |              |
      |              |              |              |



9.6. Return of Call to OISP

   In some cases, it is desirable that the caller be able to request,
   typically via keypad stimulus such as the octothorpe or pound sign,
   to be returned to the OISP operator (human or automated). One way
   this can be accomplished is for the OISP to use KPML [RFC4730] to
   subscribe to the desired keypress. The flow presented here assumes
   that the calling UA, or an intermediary acting on its behalf,
   supports this event package, and is able to detect the desired
   keypress. Examples of such intermediaries include back to back user
   agents (B2BUAs) and Session Border Controllers (SBCs). Another
   option is for the OISP to insert some element such as a MS into the
   media stream, which is capable of detecting and notifying the
   desired keypress.

   In (1) the caller has already been connected to called party via
   the AS. In (2), the AS subscribes to KPML events from the caller's
   UA. Note that in some environments, this could be intercepted and
   acted upon by intermediaries such as B2BUAs or SBCs. As long as
   this does not interfere with notification, this is transparent to
   the OISP. When the caller presses the specified keypress to request
   return to the OISP, a NOTIFY (6) is sent to the AS. At this time,
   the OISP can perform whatever actions are necessary, such as
   perhaps sending a re-INVITE or UPDATE to move the media session to
   an OISP resource.






Haluska, et al.          Expires May 18, 2008                 [Page 58]


Internet-Draft      Information Services Using SIP        November 2007


   Caller           AS             MS        Called Party
       |              |              |              |
       |(1) Caller connected to called via 3PCC     |
       |............................................|
       |              |              |              |
       |(2) SUBSCRIBE (KPML body specifying "#")    |
       |<-------------|              |              |
       |(3) 200 OK    |              |              |
       |------------->|              |              |
       |              |              |              |
       |(4) NOTIFY (result of subscription)         |
       |------------->|              |              |
       |(5) 200 OK    |              |              |
       |<-------------|              |              |
       |              |              |              |
       |[ Some time passes ]         |              |
       |              |              |              |
       |[ Caller wants back to OISP, hits "#" ]     |
       |              |              |              |
       |              |              |              |
       |(6) NOTIFY (KPML body specifying "#")       |
       |------------->|              |              |
       |(7) 200 OK    |              |              |
       |<-------------|              |              |







10. Operator Services Example Call Flows

   The following call flows provide examples of how specific operator
   services could be implemented using the mechanisms described in
   this document. The purpose is to illustrate one way to implement
   these services using the proposed signaling mechanisms.

10.1. Network Controlled Coin Calls

   This flow depicts a SIP based OISP handling calls from a network
   controlled coin station. The OISP needs to determine the coinage
   deposited by the station. Note that ''smart'' coin stations do not
   require interaction with the OISP. This discussion only addresses
   control of TDM based network controlled coin stations.




Haluska, et al.          Expires May 18, 2008                 [Page 59]


Internet-Draft      Information Services Using SIP        November 2007


   The configuration is as follows. Network controlled coin stations
   are connected to TDM based end offices (EOs) using special access
   lines, the characteristics of which are not important to this
   discussion. The EO exchanges signaling with the station over this
   access line, but does not perform the coin control. Operator
   Services switches historically provide the control for these types
   of calls, and the EO connects to the Operator Switch via special
   coin control trunks. The EO translates between coin access and coin
   trunk signaling.

   The signaling includes coin station control and coin deposit
   indications. The OISP uses coin station control signaling to
   instruct the station to collect coins, return coins, etc. The coin
   deposit signaling indicates the coinage inserted by the user.

   Coin deposit signaling is sent as tones on the access line and on
   the trunk. The values of these tones are described elsewhere. In
   order to convey these tones, either a new event package would need
   to be defined, or extensions to an existing event package, such as
   KPML [RFC4730].

   Coin trunks can be SS7 or MF trunks. Both of these have native
   signaling formats for conveying coin control events. PSTN gateways
   interwork between PSTN and SIP signaling. There is no currently
   defined mechanism for conveying coin control events using SIP.

   One way to address this is to standardize a new event package (or
   extend an existing package), so that SIP notification mechanisms
   can be used. This is subject to the level of IETF community
   interest and support.

   A signaling mechanism known as Narrowband Signaling Syntax (NSS),
   as described in [NSS], allows individual SS7 ISDN User Part (ISUP)
   message parameters to be carried in message bodies in SIP messages.
   This contrasts with other mechanism such as SIP-T [RFC3372] where
   the entire ISUP message is carried in the SIP message. NSS can be
   used to carry the relevant ISUP parameters required for conveying
   coin control signaling between the AS and the PSTN gateway. When
   dealing with MF trunks, the GW would be required to perform an
   internal mapping between MF and ISUP.

   The main idea of the scheme presented here is that the OIS AS
   exchanges coin control signaling with the coin station via the PSTN
   GW, which speaks either MF or ISUP toward the end office serving
   the coin station, and speaks SIP to the AS. The PSTN GW and AS use
   NSS to carry an ISUP SAP parameter in SIP message bodies, and the
   PSTN GW uses either ISUP or MF to communicate with the end office.


Haluska, et al.          Expires May 18, 2008                 [Page 60]


Internet-Draft      Information Services Using SIP        November 2007


   The coin deposit signals are detected on the voice path by the PSTN
   GW, and conveyed to the AS using either extensions to KPML or a new
   SIP event package.

   In the following flow, the EO is the end office service the coin
   station, the PSTN GW is the GW terminating the voice trunks and
   signaling from the EO, the AS is the OIS AS, the MS is a media
   server in the OIS provider, and the called party is self
   explanatory.

   In step 1, the coin station (not shown) has signaled a call request
   to the EO, which in turn selects a coin trunk toward the OISP PSTN
   GW, and initiates the corresponding signaling. In steps 2 through
   4, the PSTN GW sends an INVITE to the AS, which accepts the call.

   In steps 5 through 7, the AS sends a SIP INFO message containing an
   NSS body, which contains an ISUP SAP parameter with the Feature
   Code Indicator (FCI) indicating ''Network Service Attached'', which
   is an instruction to the coin station that an Operator Services
   System has been connected. The GW sends the corresponding PSTN
   signaling back toward the coin station.

   In steps 8 through 10, the AS using the same procedures sends a SAP
   parameter with the FCI indicating ''Coin Collect'' which instructs
   the coin station to collect and report on coin deposits.

   The coin deposits will be signaled as tones over the trunk, so the
   AS in steps 11 through 14 subscribes to these events at the GW.
   This example assumes an extension to KPML to support these tones,
   but the mechanism is the same even if a new event package were
   defined.

   In 15, the user deposits coins into the station, and these events
   are signaled by the EO to the GW. In step 16, the GW sends SIP
   NOTIFY messages to the AS for each such event.

   When the AS determines that adequate payment has been collected, it
   routes the call, as depicted in steps 18 through 24.

   In this example, the caller exceeds his credit, and hangs up the
   phone. This is represented by steps 25 through 27.

   Using similar signaling, the OISP sends an Operator Hold and
   Ringback request toward the station, to ''keep the line open'' and to
   ring the station so that the user can be prompted to pay the
   exceeded credit. This is represented in steps 28 through 36. In
   this case, the honest user inserts the required coins, and this is


Haluska, et al.          Expires May 18, 2008                 [Page 61]


Internet-Draft      Information Services Using SIP        November 2007


   signaled to the OISP in steps 39 through 41. From steps 42 on, the
   line is ''released''.















































Haluska, et al.          Expires May 18, 2008                 [Page 62]


Internet-Draft      Information Services Using SIP        November 2007


            EO        GW        AS        MS   Called Party
             |         |         |         |         |
             |         |         |         |         |
             |         |         |         |         |
             |(1) Call Request Indication  |         |
             |-------->|         |         |         |
             |         |         |         |         |
             |         |(2) INVITE         |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |         |(3) 200 OK         |         |
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(4) ACK  |         |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |         |(5) INFO (NSS,SAP FCI=Network Service Attach)
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(6) 200 OK         |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |(7) corresponding MF or ISUP signaling |
             |<--------|         |         |         |
             |         |         |         |         |
             |         |(8) INFO (NSS,SAP FCI=Coin Collect)
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(9) 200 OK         |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |(10) corresponding MF or ISUP signaling|
             |<--------|         |         |         |
             |         |         |         |         |
             |(11) SUBSCRIBE (KPML body specifying coin deposit tones)
             |<------------------|         |         |
             |         |         |         |         |
             |(12) 200 OK        |         |         |
             |------------------>|         |         |
             |         |         |         |         |
             |(13) NOTIFY (result of subscription)   |
             |------------------>|         |         |
             |         |         |         |         |
             |(14) 200 OK        |         |         |
             |<------------------|         |         |
             |         |         |         |         |
             |[ User inserts coins ]       |         |


Haluska, et al.          Expires May 18, 2008                 [Page 63]


Internet-Draft      Information Services Using SIP        November 2007


             |         |         |         |         |
             |         |         |         |         |
             |(15) Coin deposit signals    |         |
             |-------->|         |         |         |
             |         |         |         |         |
             |         |(16) NOTIFY (KPML body specifying coin deposit
   tones)
             |         |-------->|         |         |
             |         |         |         |         |
             |         |(17) 200 OK        |         |
             |         |<--------|         |         |
             |         |         |         |         |
             |[ AS determines adequate coinage, routes call ]
             |         |         |         |         |
             |         |         |         |         |
             |         |         |(18) INVITE        |
             |         |         |------------------>|
             |         |         |         |         |
             |         |         |(19) 180 Ringing   |
             |         |         |<------------------|
             |         |         |         |         |
             |         |         |(20) 200 OK        |
             |         |         |<------------------|
             |         |         |         |         |
             |         |         |(21) ACK |         |
             |         |         |------------------>|
             |         |         |         |         |
             |         |(22) re-INVITE (Called SDP)  |
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(23) 200 OK        |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |         |(24) RTP |         |         |
             |         |.............................|
             |         |         |         |         |
             |[ Conversation, exceeds credit ]       |
             |         |         |         |         |
             |         |         |         |         |
             |[ Caller hangs up, tries to run ]      |
             |         |         |         |         |
             |         |         |         |         |
             |(25) Disconnect Request      |         |
             |-------->|         |         |         |
             |         |         |         |         |
             |         |(26) INFO (NSS,SAP FCI=Disconnect Request)
             |         |-------->|         |         |


Haluska, et al.          Expires May 18, 2008                 [Page 64]


Internet-Draft      Information Services Using SIP        November 2007


             |         |         |         |         |
             |         |(27) 200 OK        |         |
             |         |<--------|         |         |
             |         |         |         |         |
             |[ AS requests Connection Hold and Ringback ]
             |         |         |         |         |
             |         |         |         |         |
             |         |(28) INFO (NSS,SAP FCI=Hold Request)
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(29) 200 OK        |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |(30) corresponding MF or ISUP signaling|
             |<--------|         |         |         |
             |         |         |         |         |
             |(31) Hold Acknowledge        |         |
             |-------->|         |         |         |
             |         |         |         |         |
             |         |(32) INFO (NSS,SAP FCI=Hold Acknowledge)
             |         |-------->|         |         |
             |         |         |         |         |
             |         |(33) 200 OK        |         |
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(34) INFO (NSS,SAP FCI=Ringback Request)
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(35) 200 OK        |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |(36) corresponding MF or ISUP signaling|
             |<--------|         |         |         |
             |         |         |         |         |
             |[ User inserts coins ]       |         |
             |         |         |         |         |
             |         |         |         |         |
             |(37) NOTIFY (KPML body specifying coin deposit tones)
             |------------------>|         |         |
             |         |         |         |         |
             |(38) 200 OK        |         |         |
             |<------------------|         |         |
             |         |         |         |         |
             |[ Billing satisfied ]        |         |
             |         |         |         |         |
             |         |         |         |         |
             |         |(39) INFO (NSS,SAP FCI=Hold Release Request)


Haluska, et al.          Expires May 18, 2008                 [Page 65]


Internet-Draft      Information Services Using SIP        November 2007


             |         |<--------|         |         |
             |         |         |         |         |
             |         |(40) 200 OK        |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |(41) corresponding MF or ISUP signaling|
             |<--------|         |         |         |
             |         |         |         |         |
             |[ User hangs up ]  |         |         |
             |         |         |         |         |
             |         |         |         |         |
             |(42) Disconnect Request      |         |
             |-------->|         |         |         |
             |         |         |         |         |
             |         |(43) INFO (NSS,SAP FCI=Disconnect Request)
             |         |-------->|         |         |
             |         |         |         |         |
             |         |(44) 200 OK        |         |
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(45) BYE |         |         |
             |         |<--------|         |         |
             |         |         |         |         |
             |         |(46) 200 OK        |         |
             |         |-------->|         |         |
             |         |         |         |         |
             |(47) corresponding MF or ISUP signaling|
             |<--------|         |         |         |
             |         |         |         |         |
             |         |         |(48) BYE |         |
             |         |         |------------------>|
             |         |         |         |         |
             |         |         |(49) 200 OK        |
             |         |         |<------------------|
             |         |         |         |         |
             |         |         |         |         |
             |         |         |         |         |












Haluska, et al.          Expires May 18, 2008                 [Page 66]


Internet-Draft      Information Services Using SIP        November 2007






10.2. Busy Line Verification and Interrupt

   An existing PTSN service is Busy Line Verification and Interrupt.
   In the Busy Line Verification (BLV) Service, a customer obtains
   operator assistance to determine if a called line is in use. In
   Operator Interrupt Service, the operator provides a BLV Service
   and, if requested by the caller, interrupts a conversation in
   progress and relays a message. If the interrupted party is willing
   to hang up, the call can be reoriginated by the caller to the
   called party. At the caller's request, the connection between the
   caller and the called party can be reinitiated and handled by the
   operator as a Call Completion Service.

10.2.1. PSTN Target

   Currently, BLV/I is handled by the Operator Services System placing
   calls via special BLV/I trunk toward the target. Use of this type
   of trunk results in the Operator Services System being able to
   monitor a scrambled version of the target's conversation, and being
   able to barge in to speak to the target. In this document, the
   focus of BLV/I toward a PSTN target is on having the OIS components
   such as OWS and AS be able to communicate with the EO via BLV/I
   trunks. For IP targets, SIP capabilities are used.

   The following figure depicts a BLV/I call to a PSTN target. In
   steps (1) through (8) the caller is routed to an AS which performs
   3PCC to connect this caller to an operator workstation.

   The operator determines the user's request, and initiates (9) a
   call toward the target via a BLV/I trunk. Ensuring that the call is
   routed via the correct type of trunk can be handled the same using
   SIP as in the PSTN; that is, by prepending specified routing digits
   to the target number. The operator is bridged by the EO onto the
   target's line, during which time no voice is sent toward the
   caller. A one way connection can be explicitly signaled, or the
   operator workstation can simply not send RTP at this time. The
   operator workstation or GW implements a scrambler so that only the
   presence or absence of speech can be determined, and the operator
   then reports to the caller on the status. If there is speech, then
   the operator reports that the line is busy, and may offer to
   interrupt the caller.




Haluska, et al.          Expires May 18, 2008                 [Page 67]


Internet-Draft      Information Services Using SIP        November 2007


   If this is desired, the operator removes the scrambler, and
   indicates to the target of the caller's desire to call them, and
   drops off. The operator informs the caller of the result, and drops
   the caller, who may then re attempt the call. The option where the
   OISP offers the call as a call completion service is not shown
   here, but this poses no unique requirements with respect to call
   completion.










































Haluska, et al.          Expires May 18, 2008                 [Page 68]


Internet-Draft      Information Services Using SIP        November 2007



          Caller      AS        WS        gw
             |[ Caller dials 0+ or 0- ]    |
             |(1) INVITE         |         |
             |-------->|         |         |
             |(2) 180 Ringing    |         |
             |<--------|         |         |
             |         |(3) INVITE         |
             |         |-------->|         |
             |         |(4) 200 OK         |
             |         |<--------|         |
             |         |(5) ACK  |         |
             |         |-------->|         |
             |(6) 200 OK         |         |
             |<--------|         |         |
             |(7) ACK  |         |         |
             |-------->|         |         |
             |(8) RTP  |         |         |
             |...................|         |
             |[ Caller is now connected to operator ]
             |         |         |(9) INVITE
             |         |         |-------->|
             |         |         |(10) 200 OK
             |         |         |<--------|
             |         |         |(11) ACK |
             |         |         |-------->|
             |         |         |(12) RTP |
             |         |         |.........|
             |[ Operator is now connected to BLV trunk ]
             |         |         |(13) BYE |
             |         |         |-------->|
             |         |         |(14) 200 OK
             |         |         |<--------|
             |[ Operator drops caller ]
             |(15) BYE |         |         |
             |<------------------|         |
             |(16) 200 OK        |         |
             |------------------>|         |
             |[ Caller may or may not place call, OISP uninvolved ]


                      Figure 11 BLV/I to PSTN Target







Haluska, et al.          Expires May 18, 2008                 [Page 69]


Internet-Draft      Information Services Using SIP        November 2007


10.2.2. SIP Target

   The following depicts a BLV/I call to a SIP target. The approach
   detailed here is based on that described in the PacketCable
   Residential SIP Telephony Feature Specification, [RST].

   The main aspects of this approach include using the Event dialog
   package [RFC4235] to determine whether the device has an active
   call, and using the Join header in order to bridge onto the current
   conversation for monitoring and interrupting the user. Additional
   aspects include the operator workstation performing the scrambling
   function, and the use of a preconfigured network asserted
   workstation identity from which the user device must accept and
   process the BLV/I related requests.

   Steps 1 through 8 represent an incoming call to the OISP being
   connected to an operator workstation. The operator interacts with
   the caller and determines the BLV/I request.

   In steps 9 through 12, the operator workstation subscribes to the
   Dialog event package at the target party's UA, and receives a
   NOTIFY identifying any active dialogs.

   In 13 through 16, the workstation sends an INVITE with a Join
   header [RFC3911] to bridge onto the active call. The INVITE
   includes a P-Asserted-Identity value corresponding to the value
   prearranged between the OISP and the target's home provider. The
   user devices are configured to accept SUBSCRIBEs for Dialog event
   package and INVITEs with the Join header when the P-Asserted-
   Identity contains this value. Thus, the user device accepts the
   Join header. Initially, the workstation acts in a receive only
   mode, and further, implements an audio scrambler such that speech
   is distinguishable as such, but is non intelligible. Thus the
   operator can determine whether the person at the target device is
   in active conversation. During this time, the workstation does not
   exchange media with the caller, who may be put on hold (not show
   here).

   The operator can then report the status to the caller, and offer
   the Interrupt service. If accepted, the scrambling function is
   removed from the voice path between operator and target, and the
   operator ''barges in'' on the conversation, informs the target party
   of the caller's request, and asks whether the target would like to
   accept the call. The operator can then drop the session with the
   target and inform the caller about the target's response. There is
   of course no guarantee of the target's or caller's subsequent
   actions.


Haluska, et al.          Expires May 18, 2008                 [Page 70]


Internet-Draft      Information Services Using SIP        November 2007



          Caller      AS        WS      Target
             |[ Caller dials 0+ or 0- ]    |
             |(1) INVITE         |         |
             |-------->|         |         |
             |(2) 180 Ringing    |         |
             |<--------|         |         |
             |[ Simplified flow for brevity - straight to oper*
             |         |(3) INVITE         |
             |         |-------->|         |
             |         |(4) 200 OK         |
             |         |<--------|         |
             |         |(5) ACK  |         |
             |         |-------->|         |
             |(6) 200 OK         |         |
             |<--------|         |         |
             |(7) ACK  |         |         |
             |-------->|         |         |
             |(8) RTP  |         |         |
             |...................|         |
             |[ Caller is now connected to operator ]
             |         |         |(9) SUBSCRIBE (Dialog)
             |         |         |-------->|
             |         |         |(10) 200 OK
             |         |         |<--------|
             |         |         |(11) NOTIFY (Dialog state)
             |         |         |<--------|
             |         |         |(12) 200 OK
             |         |         |-------->|
             |         |         |(13) INVITE (Join, dialog id)
             |         |         |-------->|
             |         |         |(14) 200 OK
             |         |         |<--------|
             |         |         |(15) ACK |
             |         |         |-------->|
             |         |         |(16) RTP |
             |         |         |.........|
             |         |         |(17) BYE |
             |         |         |-------->|
             |         |         |(18) 200 OK
             |         |         |<--------|
             |[ Operator informs caller of target's disposition ]
             |(19) BYE |         |         |
             |<------------------|         |
             |(20) 200 OK        |         |
             |------------------>|         |



Haluska, et al.          Expires May 18, 2008                 [Page 71]


Internet-Draft      Information Services Using SIP        November 2007




10.3. Inward Calls

   Typically, operator services are provided by the OISP serving a
   user's originating provider. In some cases, another OISP must be
   involved. One example is BLV/I, where an OISP can only invoke BLV/I
   for targets served by providers that the OISP serves.  In the case
   of a caller desiring to invoke BLV/I to a target served by a
   different provider, the caller's request would be routed to the
   same OISP as usual. That OISP would identify the OISP serving the
   target, and initiate an ''inward'' call to an operator in that OISP,
   and request that operator to perform the BLV/I. For this feature,
   the initiating OISP acts as the caller to the OISP serving the
   target. Currently, Inward calls are originated by operators at
   operator workstations, and terminated to operators at operator
   workstations.

   Inward calls need to be distinguishable from calls from subscribers
   that are routed to operators. Further, inward calls should be
   accepted only from other OISPs, never from subscribers, and only
   from those OISPs with appropriate business relationships.

   The request should be screened based on the identity of originator.
   Since the From header can easily be spoofed, a network-asserted
   identity should be used for this. Within trust domains that use the
   P-Asserted-Identity [RFC3325] header as a network asserted
   identity, this header should be used for this purpose.
   Alternatively, the SIP Identity mechanism [RFC4474] can be used in
   domains where this is used for network asserted identity. Rather
   than maintain lists of every possible URI for which Inward requests
   are allowed, the decision can be based on the domain in the SIP
   URI. Requests from domains corresponding only to OISPs which are
   authorized to make Inward requests would be accepted.

   In the current North American PSTN, the digits dialed by the
   operator placing Inward call can be used to identify the type of
   service being requested, so that the destination OISP can properly
   handle the request. These digits are known as Operator Special
   Dialed Code (OSDC) digits. Thus, the Request-URI should include the
   OSDC digits, and the AS should populate the Request-URI as a SIP
   URI which includes the SIP domain of the destination OISP as well
   as the OSDC code.

   For Inward calls to PSTN based OISPs, the call should be placed via
   a PSTN gateway, and should appear to the destination OISP the same
   as any other Inward call.


Haluska, et al.          Expires May 18, 2008                 [Page 72]


Internet-Draft      Information Services Using SIP        November 2007




10.4. Intercept

   Intercept service provides the capability for a customer to be
   informed that a working number is no longer in service or why a
   working number is no longer in service. Basically, it provides
   announcements to the caller, which may be fixed or dynamic.
   Currently in the North American PSTN, Intercept may be handled by
   individual end offices, or may be sent to Operator Services
   Systems, which have specialized resources for handling such
   requests. When a call reaches a PSTN switch for a number which
   requires Intercept treatment, that switch, known as the
   ''intercepted switch'', initiates an Intercept request for that
   ''intercepted number''. The request to an OISP specifies the
   intercepted number, and an ''intercept type'', which provides an
   indication of the general reason for intercept. Often, the OISP
   needs to consult an ''intercept database'' to determine specific
   processing for a particular intercepted number.

   Currently, with MF, dedicated Intercept trunk groups are typically
   used, so the call is implicitly identified as such. The ANI digits
   identify the intercepted number, and the II digits identify the
   intercept type. For ISUP, dedicated trunk groups may or may not be
   used, but the SAP parameter identifies the intercept type, and the
   Called Party Number parameter identifies the intercepted number. In
   both cases, the key information conveyed include identification of
   the request as intercept, intercept type, and intercepted number.

10.4.1. Intercept Request Via SIP

   Intercept requests to a SIP based OISP need to convey the same
   information currently conveyed. Such requests can be treated as a
   call forwarded to an Intercept service. Thus, the Request-URI
   should identify the request as Intercept, as well as conveying the
   intercept type. The currently defined values for intercept type
   include regular, blank, and trouble. Prepending these with
   ''intercept-'' in the left hand side of the Request-URI unambiguously
   identifies the request as intercept and conveys the intercept type.
   Treating this as a redirection, the SIP History-Info header can be
   used to convey the intercepted number. An example of such an INVITE
   (relevant fields only) follows:







Haluska, et al.          Expires May 18, 2008                 [Page 73]


Internet-Draft      Information Services Using SIP        November 2007


   INVITE sip:intercept-trouble@oisp-c.net SIP/2.0
   From: <sip:7327581111@provider-a.net>;tag=1234567
   To: <sip:7327582222@provider-b.net>
   History-Info: <sip:7327582222@provider-b.net>; index=1
   Content-Type: application/sdp
   Content-Length: ...


   Upon receiving such a request, the AS would typically perform any
   required processing, including database lookups, and generate a
   request to a MS to play the specified announcement. The conventions
   described in [RFC4240] can be used for this.

   An example high level message flow follows:



































Haluska, et al.          Expires May 18, 2008                 [Page 74]


Internet-Draft      Information Services Using SIP        November 2007


     Intercepted domain    AS             MS
             |              |              |
             |              |              |
             |              |              |
   [ Receives a call requiring Intercept service ]
             |              |              |
             |              |              |
             |(1) INVITE ( r-URI->intercept type, Hist-
                           Info=intercepted number )
             |------------->|              |
             |              |              |
             |              |(2) INVITE (r-URI->RFC 4240 annc)
             |              |------------->|
             |              |              |
             |              |(3) 200 OK    |
             |              |<-------------|
             |              |              |
             |              |(4) ACK       |
             |              |------------->|
             |              |              |
             |(5) 183 Session Progress     |
             |<-------------|              |
             |              |              |
             |(6) RTP (announcements)      |
             |.............................|
             |              |              |
             |Caller hangs up              |
             |              |              |
             |              |              |
             |(7) BYE       |              |
             |------------->|              |
             |              |              |
             |(8) 200 OK    |              |
             |<-------------|              |
             |              |              |
             |              |(9) BYE       |
             |              |------------->|
             |              |              |
             |              |(10) 200 OK   |
             |              |<-------------|
             |              |              |
             |              |              |







Haluska, et al.          Expires May 18, 2008                 [Page 75]


Internet-Draft      Information Services Using SIP        November 2007


10.4.2. Intercept Request Via PSTN

   When intercept requests are received from PSTN interfaces, the PSTN
   gateway needs to translate the incoming signaling to SIP. The
   preferred approach is to have the PSTN gateway construct an INVITE
   request of the form described above for requests received via SIP.
   This method requires additional functionality on the part of the
   gateway, but the AS only needs to recognize one type of INVITE
   request for Intercept.

   Alternatively, the gateway could construct an INVITE containing an
   NSS body, which contains the Called Party Number and SAP fields
   from the IAM. Also, the Request-URI should contain the Called Party
   Number. With this method, the PSTN gateway treats the INVITE the
   same as other INVITEs, but requires the AS to recognize this as an
   Intercept request by examining the NSS body contents.

































Haluska, et al.          Expires May 18, 2008                 [Page 76]


Internet-Draft      Information Services Using SIP        November 2007


   Intercepted
    Switch         PSTN GW          AS             MS
      |              |              |              |
      |              |              |              |
      |              |              |              |
      |[ Receives a call requiring Intercept service ]
      |              |              |              |
      |              |              |              |
      |(1) IAM ( CdPN digits=intcptd number, CdPN NOA=op req,
                 SAP=intcpt type )
      |------------->|              |              |
      |              |              |              |
      |              |(2) INVITE (see above)
      |              |------------->|              |
      |              |              |              |
      |              |              |(3) INVITE (r-URI->RFC 4240 annc)
      |              |              |------------->|
      |              |              |              |
      |              |              |(4) 200 OK    |
      |              |              |<-------------|
      |              |              |              |
      |              |              |(5) ACK       |
      |              |              |------------->|
      |              |              |              |
      |              |(6) 183 Session Progress     |
      |              |<-------------|              |
      |              |              |              |
      |(7) ACM       |              |              |
      |<-------------|              |              |
      |              |              |              |
      |              |(8) RTP (announcements)      |
      |              |.............................|
      |              |              |              |
      |(9) TDM (announcements)      |              |
      |..............|              |              |
      |              |              |              |
      |Caller hangs up              |              |
      |              |              |              |
      |              |              |              |
      |(10) REL      |              |              |
      |------------->|              |              |
      |              |              |              |
      |              |(11) BYE      |              |
      |              |------------->|              |
      |              |              |              |
      |              |(12) 200 OK   |              |
      |              |<-------------|              |


Haluska, et al.          Expires May 18, 2008                 [Page 77]


Internet-Draft      Information Services Using SIP        November 2007


      |              |              |              |
      |(13) RLC      |              |              |
      |<-------------|              |              |
      |              |              |              |
      |              |              |(14) BYE      |
      |              |              |------------->|
      |              |              |              |
      |              |              |(15) 200 OK   |
      |              |              |<-------------|
      |              |              |              |


















10.5. Operator Assisted Collect Call

   The following call flow provides examples of how a specific
   operator service, Operator Assisted Collect Call, could be
   implemented using the mechanisms described in this document. The
   purpose is to illustrate one way to implement this service using
   the proposed signaling mechanisms. In practice, this particular
   service could be implemented in an automated fashion without human
   intervention.












Haluska, et al.          Expires May 18, 2008                 [Page 78]


Internet-Draft      Information Services Using SIP        November 2007



   Caller     Proxy       AS        WS      Called      MS        ACD
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |[ Caller dials 0+ or 0- ]    |         |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |(1) INVITE         |         |         |         |         |
      |------------------>|         |         |         |         |
      |         |         |         |         |         |         |
      |(2) 100 Trying     |         |         |         |         |
      |<------------------|         |         |         |         |
      |         |         |         |         |         |         |
      |[ AS determines operator is needed, performs 3PCC ]        |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(3) INVITE         |         |         |
      |         |         |-------------------------------------->|
      |         |         |         |         |         |         |
      |         |         |(4) 3xx redirect to WS where selected
   operator registered
      |         |         |<--------------------------------------|
      |         |         |         |         |         |         |
      |         |         |(5) INVITE         |         |         |
      |         |         |-------->|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(6) 200 OK         |         |         |
      |         |         |<--------|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(7) ACK  |         |         |         |
      |         |         |-------->|         |         |         |
      |         |         |         |         |         |         |
      |(8) 200 OK         |         |         |         |         |
      |<------------------|         |         |         |         |
      |         |         |         |         |         |         |
      |(9) ACK  |         |         |         |         |         |
      |------------------>|         |         |         |         |
      |         |         |         |         |         |         |
      |[ Caller is now connected to operator ]|         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |(10) RTP |         |         |         |         |         |
      |.............................|         |         |         |
      |         |         |         |         |         |         |
      |[ Operator determines calling's request and places on hold]|
      |         |         |         |         |         |         |


Haluska, et al.          Expires May 18, 2008                 [Page 79]


Internet-Draft      Information Services Using SIP        November 2007


      |         |         |         |         |         |         |
      |         |         |(11) re-INVITE (HOLD)        |         |
      |         |         |<--------|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(12) 200 OK        |         |         |
      |         |         |-------->|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(13) ACK |         |         |         |
      |         |         |<--------|         |         |         |
      |         |         |         |         |         |         |
      |[ AS logic determines announcements should be played instead ]
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(14) INVITE (play announcements)       |
      |         |         |---------------------------->|         |
      |         |         |         |         |         |         |
      |         |         |(15) 200 OK (SDP-MS)         |         |
      |         |         |<----------------------------|         |
      |         |         |         |         |         |         |
      |         |         |(16) ACK |         |         |         |
      |         |         |---------------------------->|         |
      |         |         |         |         |         |         |
      |(17) reINVITE (SDP-MS)       |         |         |         |
      |<------------------|         |         |         |         |
      |         |         |         |         |         |         |
      |(18) 200 OK (SDP-calling)    |         |         |         |
      |------------------>|         |         |         |         |
      |         |         |         |         |         |         |
      |(19) ACK |         |         |         |         |         |
      |<------------------|         |         |         |         |
      |         |         |         |         |         |         |
      |(20) RTP (MS plays announcements to calling)     |         |
      |.................................................|         |
      |         |         |         |         |         |         |
      |[ Operator calls called party ]        |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |         |(21) INVITE        |         |
      |         |         |         |-------->|         |         |
      |         |         |         |         |         |         |
      |         |         |         |(22) 200 OK        |         |
      |         |         |         |<--------|         |         |
      |         |         |         |         |         |         |
      |         |         |         |(23) ACK |         |         |
      |         |         |         |-------->|         |         |
      |         |         |         |         |         |         |
      |         |         |         |(24) RTP |         |         |


Haluska, et al.          Expires May 18, 2008                 [Page 80]


Internet-Draft      Information Services Using SIP        November 2007


      |         |         |         |.........|         |         |
      |         |         |         |         |         |         |
      |[ Called agrees to accept charges ]    |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |[ Operator takes Calling off hold ]    |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(25) re-INVITE (un-HOLD)     |         |
      |         |         |<--------|         |         |         |
      |         |         |         |         |         |         |
      |[ AS logic directs Calling from MS back to WS ]  |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |(26) re-INVITE (SDP-ws)      |         |         |         |
      |<------------------|         |         |         |         |
      |         |         |         |         |         |         |
      |(27) 200 OK        |         |         |         |         |
      |------------------>|         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(28) 200 OK        |         |         |
      |         |         |-------->|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(29) ACK |         |         |         |
      |         |         |<--------|         |         |         |
      |         |         |         |         |         |         |
      |(30) ACK |         |         |         |         |         |
      |<------------------|         |         |         |         |
      |         |         |         |         |         |         |
      |(31) RTP |         |         |         |         |         |
      |.............................|         |         |         |
      |         |         |         |         |         |         |
      |[ AS releases MS ] |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(32) BYE |         |         |         |
      |         |         |---------------------------->|         |
      |         |         |         |         |         |         |
      |         |         |(33) 200 OK        |         |         |
      |         |         |<----------------------------|         |
      |         |         |         |         |         |         |
      |[ Calling and Called both have RTP session with WS ]       |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |[ WS bridges conversations together internally ] |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |


Haluska, et al.          Expires May 18, 2008                 [Page 81]


Internet-Draft      Information Services Using SIP        November 2007


      |[ After brief interlude WS transfers Calling directly to Called
   ]
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |[ then drops out ] |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(34) REFER (to called)       |         |
      |         |         |<--------|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(35) 202 Accepted  |         |         |
      |         |         |-------->|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(36) NOTIFY (trying)         |         |
      |         |         |-------->|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(37) 200 OK        |         |         |
      |         |         |<--------|         |         |         |
      |         |         |         |         |         |         |
      |[ Replaces header causes Called to replace old call with new ]
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(38) INVITE (replaces: WS )  |         |
      |         |         |------------------>|         |         |
      |         |         |         |         |         |         |
      |         |         |(39) 200 OK (SDP-called)     |         |
      |         |         |<------------------|         |         |
      |         |         |         |         |         |         |
      |         |         |(40) ACK |         |         |         |
      |         |         |------------------>|         |         |
      |         |         |         |         |         |         |
      |         |         |         |(41) BYE |         |         |
      |         |         |         |<--------|         |         |
      |         |         |         |         |         |         |
      |         |         |         |(42) 200 OK        |         |
      |         |         |         |-------->|         |         |
      |         |         |         |         |         |         |
      |[ The following interactions synch up SDP - optimization
   possible ]
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |(43) re-INVITE (SDP-called)  |         |         |         |
      |<------------------|         |         |         |         |
      |         |         |         |         |         |         |
      |(44) 200 OK (SDP-calling)    |         |         |         |
      |------------------>|         |         |         |         |
      |         |         |         |         |         |         |


Haluska, et al.          Expires May 18, 2008                 [Page 82]


Internet-Draft      Information Services Using SIP        November 2007


      |(45) ACK |         |         |         |         |         |
      |<------------------|         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(46) re-INVITE (SDP-calling) |         |
      |         |         |------------------>|         |         |
      |         |         |         |         |         |         |
      |         |         |(47) 200 OK        |         |         |
      |         |         |<------------------|         |         |
      |         |         |         |         |         |         |
      |         |         |(48) ACK |         |         |         |
      |         |         |------------------>|         |         |
      |         |         |         |         |         |         |
      |(49) RTP |         |         |         |         |         |
      |.......................................|         |         |
      |         |         |         |         |         |         |
      |[ Calling and Called are now talking directly ]  |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(50) NOTIFY (Call completed) |         |
      |         |         |-------->|         |         |         |
      |         |         |         |         |         |         |
      |         |         |(51) 200 OK        |         |         |
      |         |         |<--------|         |         |         |
      |         |         |         |         |         |         |
      |[ Operator now drops out ]   |         |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |         |(52) BYE |         |         |
      |         |         |         |-------->|         |         |
      |         |         |         |         |         |         |
      |         |         |         |(53) 200 OK        |         |
      |         |         |         |<--------|         |         |
      |         |         |         |         |         |         |
      |[ AS remains in signaling path until call ends ] |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |(54) BYE |         |         |         |         |         |
      |------------------>|         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |(55) BYE |         |         |         |
      |         |         |------------------>|         |         |
      |         |         |         |         |         |         |
      |         |         |(56) 200 OK        |         |         |
      |         |         |<------------------|         |         |
      |         |         |         |         |         |         |
      |(57) 200 OK        |         |         |         |         |
      |<------------------|         |         |         |         |


Haluska, et al.          Expires May 18, 2008                 [Page 83]


Internet-Draft      Information Services Using SIP        November 2007


      |         |         |         |         |         |         |
      |         |         |         |         |         |         |
      |         |         |         |         |         |         |


    Figure 12   Operator Service Call flow (Operator Assisted Collect
                                  Call)



   The caller initiates the call by dialing 0+ or 0-.

   The call is routed to the AS. The AS examines the calling party
   number and calling party's home provider, which are derived from
   the P-Asserted-Identity header. The charge number is also needed,
   in case the caller's service is determined by agreements with
   another party, such as the caller's employer. The employer may have
   a large number of calling identities representing its employees,
   which are covered under its agreement with the OISP. Rather than
   provision every possible calling number/identity with the OISP (and
   this may be constantly changing), the ability to pass a charge
   number would allow the OISP to determine whether this charge number
   has any associated treatment on a per charge number basis.

   In any case, in our example, the AS examines the request and
   determines that the call is for an operator assisted collect call.
   Typically a MS could be initially connected to prompt the user for
   the type of call. This step is omitted in this example.

   The AS performs third party call control (3PCC). It sends a 18x
   response towards the caller. It needs to initiate a call leg to an
   operator workstation. It populates the selection criteria in an
   INVITE message (the exact mechanism for this is under study) which
   it sends to the ACD server in (3). The ACD server identifies the
   best match available operator and returns the contact information
   for the workstation where that operator is currently registered in
   a 3xx redirection response.

   In (5) the AS sets up a call to the workstation identified by the
   ACD server, and using 3PCC connects the caller to the WS, resulting
   in an RTP session in (10).

   The operator determines the caller's requested number, and sends an
   INVITE toward the AS to put the caller on hold. The logic in the AS
   determines that instead the caller should be connected to custom
   announcements, and in (14) through (20) creates a session between
   the caller and a MS.


Haluska, et al.          Expires May 18, 2008                 [Page 84]


Internet-Draft      Information Services Using SIP        November 2007


   Meanwhile, in (21) the WS places a call to the called party, and
   asks whether the called party would accept the charges for a
   collect call. In this example, the called party agrees to the
   request.

   In (25), the operator takes the caller off hold (recall that it
   believes it has placed the caller on hold). The AS, in (26) through
   (33), performs 3PCC, and removes the caller from the MS which is
   playing custom announcements, and reconnects the caller back to the
   WS. The WS uses its own internal bridging functionality to
   conference the operator, calling, and called parties.

   After a brief interlude, the operator initiates a transfer of the
   calling and called parties directly together using a REFER in (34)
   through (37). The AS, performing 3PCC, utilizes the SIP Replaces
   mechanism beginning in (38) to complete the transfer. When the
   transfer is complete, the operator drops out completely. Note that
   the AS, performing 3PCC, remains in the signaling path until the
   call is torn down in (54) through (57).



11. VoIP Information Services - Summary and Next Steps

A list of information which needs to be conveyed has been developed,
and candidate proposals identified for each of these.

The desired next steps include soliciting feedback from the IETF
community on the choices and intended usages of the proposed
mechanisms.

Future revisions of this document will need to include security
considerations as well as IANA considerations. Example messages and
message flows will be more complete. The References section will also
need to be complete.



12. Security Considerations

This revision of this document does not yet address security
considerations. A subsequent revision will do so, and will likely
include the following among items it considers:

Usage of headers such as P-Asserted-Identity which are intended to use
between trusted providers.



Haluska, et al.          Expires May 18, 2008                 [Page 85]


Internet-Draft      Information Services Using SIP        November 2007


Potentially revealing information about subscribers or service
provider infrastructure via signaling messages.

Security of signaling and bearer.

Implications of inter provider signaling.



13. IANA Considerations

This revision of this document does not yet address IANA
considerations. It is not anticipated that this document will define
any new protocol extensions or other values requiring action of IANA.



































Haluska, et al.          Expires May 18, 2008                 [Page 86]


Internet-Draft      Information Services Using SIP        November 2007


14. References



14.1. Normative References

   [1]   Rosenberg, et al, J., "SIP: Session Initiation Protocol", RFC
         3261, June 2002.

   [RFC4474] Peterson, Jennings, "Enhancements for Authenticated
             Identity Management in the Session Initiation Protocol
             (SIP)", RFC 4474, August 2006.

   [RFC3325] Jennings, et al, "Private Extensions to the Session
             Initiation Protocol (SIP) for Asserted Identity within
             Trusted Networks", RFC 3325, November 2002.



14.2. Informative References



   [CSI]    Loreto, Terril, "Input 3rd-Generation Partnership Project
             (3GPP) Communications Service Identifiers Requirements on
             the Session Initiation Protocol (SIP)", draft-loreto-
             sipping-3gpp-ics-requirements-00.txt, June 2006. (work in
             progress)

   [RFC3324] Watson, "Short Term Requirements for Network Asserted
             Identity", RFC 3324, November 2004.

   [RFC3263] Rosenberg, Schulzrinne, "Session Initiation Protocol
             (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [RFC4240] Burger, et al, "Basic Network Media Services with SIP",
             RFC 4240, December 2005.

   [RFC3725] Rosenberg, et al, "Best Current Practices for Third Party
             Call Control (3pcc) in the Session Initiation Protocol
             (SIP)", RFC 3725, April 2004.

   [IMS] 3GPP TS 23.228 V7.4.0 (2006-06) - 3rd Generation Partnership
             Project; Technical Specification Group Services and
             System Aspects; IP Multimedia Subsystem (IMS); Stage 2
             (Release 7)



Haluska, et al.          Expires May 18, 2008                 [Page 87]


Internet-Draft      Information Services Using SIP        November 2007


    [NSS] American National Standards Institute, Inc., "ANSI
             Extensions to the Narrowband Signaling Syntax (NSS) -
             Syntax Definition", ATIS-1000008.2006, January 2006.

    [RFC4904] Gurbani, et al, "Representing Trunk Groups in tel/sip
             Uniform Resource Identifiers (URIs)", RFC 4904, June
             2007.

   [RFC3372] Vemuri, et al, "Session Initiation Protocol for
             Telephones (SIP-T): Context and Architectures", RFC 3372,
             September 2002.

   [RFC4730] Burger, Dolly, "A Session Initiation Protocol (SIP) Event
             Package for Key Press Stimulus (KPML)", RFC 4730,
             November 2006.

   [RST]     PacketCable, " Residential SIP Telephony Feature
             Specification", PKT-SP-RSTF-I01-060927, September 2006.

   [RFC4235] Rosenberg, et al, "An INVITE-Initiated Dialog Event
             Package for the Session Initiation Protocol (SIP)", RFC
             4235, November 2005.

   [RFC3911] Mahy, et al, "The Session Initiation Protocol (SIP)
             "Join" Header", RFC 3911, October 2004.
























Haluska, et al.          Expires May 18, 2008                 [Page 88]


Internet-Draft      Information Services Using SIP        November 2007


Author's Addresses

      John Haluska
      Telcordia Technologies, Inc.
      331 Newman Springs Road
      Room 2Z-323
      Red Bank, NJ  07701-5699
      USA

      Phone: +1 732 758 5735
      Email: jhaluska@telcordia.com


      Renee Berkowitz
      Telcordia Technologies, Inc.
      One Telcordia Drive
      Piscataway, NJ  08854-4157
      USA

      Phone: +1 732 699 4784
      Email: rberkowi@telcordia.com


      Paul Roder
      Telcordia Technologies, Inc.
      One Telcordia Drive
      Room RRC-4A619
      Piscataway, NJ  08854-4157
      USA

      Phone: +1 732 699 6191
      Email: proder2@telcordia.com

      Wesley Downum
      Telcordia Technologies, Inc.
      One Telcordia Drive
      Piscataway, NJ  08854-4157
      USA

      Phone: +1 732 699 6201
      Email: wdownum@telcordia.com


      Richard Ahern
      AT&T Customer Information Services
      1876 Data Drive
      Room 314


Haluska, et al.          Expires May 18, 2008                 [Page 89]


Internet-Draft      Information Services Using SIP        November 2007


      Hoover, AL  35244
      USA

      Email: Richard.Ahern@bellsouth.com


      Paul Lum Lung
      Qwest Communications International
      1801 California Street
      Suite 1210
      Denver, CO  80202
      USA

      Email: paul.lumlung@qwest.com


     Nicholas S. Costantino
     Soleo Communications, Inc.
     300 Willowbrook Drive
     Fairport, NY 14450

     Email: ncostantino@soleocommunications.com


     Chris Blackwell
     Verizon
     1000 Century Tel Dr
     Room 115
     Wentzville, MO 63385

     Email: chris.blackwell@verizon.com

     Jim Mellinger
     Verizon
     7979 N Beltline Rd
     Irving, TX 75063

     Email: james.j.mellinger@verizon.com


     D. E. Scott
     VoltDelta
     2401 N. Glassell St.
     Orange, CA  92865-2705

     Email: dscott@voltdelta.com



Haluska, et al.          Expires May 18, 2008                 [Page 90]


Internet-Draft      Information Services Using SIP        November 2007


   Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be 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 patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

   Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST 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.

   Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   Acknowledgment

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


Haluska, et al.          Expires May 18, 2008                 [Page 91]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/