[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
Expires: April 2007                                            P. Roder
                                                              W. Downum
                                           Telcordia Technologies, Inc.
                                                                R. Ahern
                                                   BellSouth Corporation
                                                             P. Lum Lung
                                      Qwest Communications International
                                                  Nicholas S. Costantino
                                              Soleo Communications, Inc.
                                                         Chris Blackwell
                                                           Jim Mellinger
                                                                 Verizon
                                                       October 27, 2006



    Considerations for Information Services and Operator Services Using
                                    SIP


             draft-haluska-sipping-directory-assistance-01.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.







Haluska, et al.         Expires April 27, 2007                 [Page 1]


Internet-Draft      Information Services Using SIP         October 2006


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

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

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

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

   This Internet-Draft will expire on April 27, 2007.

Abstract

   Information Services are services whereby information is provided by
   the network 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. This
   document aims to identify how such services can be implemented using
   existing or currently proposed SIP mechanisms.







Haluska, et al.         Expires April 27, 2007                 [Page 2]


Internet-Draft      Information Services Using SIP         October 2006


Table of Contents


   1. Introduction...................................................4
   2. Scope..........................................................6
   3. High Level Requirements........................................7
   4. Terminology....................................................9
   5. Service Description...........................................14
   6. OISP Internal Architecture....................................19
   7. Network Scenarios.............................................21
      7.1. Services Provided by the Caller's Home Provider..........21
      7.2. Services Provided by a Direct Third Party Provider.......24
      7.3. Services Provided by an Indirect Third Party Provider....27
   8. Signaling Requirements........................................30
      8.1. Calling Party's Identity.................................31
      8.2. Home Network.............................................32
      8.3. Last Hop Provider........................................33
      8.4. Originating Station Type.................................34
      8.5. Trunk Group Identifier...................................35
      8.6. Retargeting to Identify the Desired Service..............36
      8.7. Charge Number............................................37
      8.8. Service Discovery........................................37
   9. Detailed Call Flow............................................38
   10. VoIP Information Services - Summary and Next Steps...........42
   11. Security Considerations......................................43
   12. IANA Considerations..........................................43
   13. References...................................................44
      13.1. Normative References....................................44
      13.2. Informative References..................................45
   Author's Addresses...............................................46
   Intellectual Property Statement..................................48
   Disclaimer of Validity...........................................49
   Copyright Statement..............................................49
   Acknowledgment...................................................49




Haluska, et al.         Expires April 27, 2007                 [Page 3]


Internet-Draft      Information Services Using SIP         October 2006


1. Introduction

   Information Services are services whereby information is provided by
   the network 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 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.





Haluska, et al.         Expires April 27, 2007                 [Page 4]


Internet-Draft      Information Services Using SIP         October 2006


   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 Information Services with SIP will require the exchange
   of certain information which is not normally exchanged 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 appropriate, and currently
   existing proposals would be favored over new extensions.

   In the current North American PSTN, Operator Services use signaling
   similar to current Directory Assistance services. Thus mechanisms
   developed for Information Services, which include Directory
   Assistance services, are expected to be useful in implementing
   Operator Services as well.

   The goals of this document are as follows:

   o  To introduce the concept of Information Services, which can be
      thought of as a superset of Directory Assistance services.

   o  To define requirements for a framework or architecture for
      implementing Information Services and Operator Services using SIP.

   o  To define a framework or architecture for Information Services and
      Operator Services using SIP, based on the above mentioned
      requirements, once they are defined. This would support current
      Directory Assistance services as well as current and future IS
      services and Operator Services. This document will provide the
      Information Services related requirements, and in doing so is
      likely to provide requirements applicable to Operator Services as
      well. It is not expected to provide a full set of requirements for
      Operator Services.




Haluska, et al.         Expires April 27, 2007                 [Page 5]


Internet-Draft      Information Services Using SIP         October 2006


   o  To investigate the conveyance of information which is needed to
      implement Directory Assistance services, and define mechanisms for
      to doing this. These are also expected to be applicable to other
      Information Services and to Operator Services.

   o  To further define how Directory Assistance services could be
      implemented within the defined framework or architecture and using
      the defined mechanisms. This would include call flows for at least
      one DA scenario.

2. Scope

   This document will provide requirements and a definition for an
   architecture or framework which will support Information Services and
   Operator Services. These will be included in a future version of this
   document.

   This document will provide signaling mechanisms and a call flow for
   one type of Information Service, i.e., basic Directory Assistance
   with call completion. Future work may investigate more complex
   service capabilities.

   In the current PSTN in North America, operator services and directory
   assistance use similar signaling, and the objective of the authors is
   to define signaling which will be applicable to both these categories
   of services.

   The details of implementing Operator Services using the framework or
   architecture and mechanisms defined in this document is out of scope.
   If these are desired it is envisioned that separate documents could
   address these, and make references as appropriate.







Haluska, et al.         Expires April 27, 2007                 [Page 6]


Internet-Draft      Information Services Using SIP         October 2006


   To clarify the relationship between Information Services and
   Directory Assistance Services, DA can be considered as a subset of
   IS.

   The term "Operator and Information Services" (OIS) is used to refer
   to the combined set of services. An OIS Provider (OISP) provides OIS
   services, which might include any subset of either Operator Services
   or Information Services, such as Directory Assistance.



3. High Level Requirements

   As mentioned above, this document will provide high level
   requirements for supporting Information Service and Operator
   Services. This is currently under study. The following represents a
   current view of some preliminary requirements.

   In addition to all-IP scenarios, an architecture for Information
   Services must 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 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.

   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.



Haluska, et al.         Expires April 27, 2007                 [Page 7]


Internet-Draft      Information Services Using SIP         October 2006


   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, VSP or ASP must be
   able to select an appropriate Information Services provider from
   among several Information Services providers based on criteria
   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.


Haluska, et al.         Expires April 27, 2007                 [Page 8]


Internet-Draft      Information Services Using SIP         October 2006


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

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

   Branding - A service where customized announcements are provider to
   the caller to identify the service provider. If the DA service is
   provided to a VSP's subscribers by a third party provider, branded
   service might include a message thanking them for using that VSP.
   Thus the user experience is that the service is provided by their VSP
   rather than some third party.

   Call Completion - A service where a call is initiated by the provider
   on behalf of the user. For example, 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 prevents the
   user from having to remember the number and then dial it.

   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.



Haluska, et al.         Expires April 27, 2007                 [Page 9]


Internet-Draft      Information Services Using SIP         October 2006


   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.

   Retail DA service - A retail DA service is a DA service that is
   provided to a user served by the Service Provider that provides the
   DA service.  In this case, the same company is the Information
   Services provider and the VSP.

   Wholesale DA service -A wholesale DA service is a DA service that is
   provided to a user service by a Service Provider that provides the
   user's voice service, but does not provide the DA service.  In this
   case, the company that is the VSP is not the Information Services
   Provider.

   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 Local Services Providers, such as the VSPs.
   Specifically, the IS providers provide IS services to the end users
   that are served by other Local Services Providers, such as VSPs.

   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.

   Voice Services Provider (VSP) - This is a calling customer's home
   provider. It is a role played by a provider in DA/IS/OS calls.

   Aggregation Services Provider (ASP) - The ASP is the provider that
   routes DA calls from multiple VSPs to a IS or DA provider. The ASP
   may be a VSP and/or a TSP. Also, VSPs may send their traffic to the
   DA provider using multiple ASPs. ASP is a role played by an entity in


Haluska, et al.         Expires April 27, 2007                [Page 10]


Internet-Draft      Information Services Using SIP         October 2006


   environment where multiple VSPs are involved in multiple bilateral
   peering agreements or are members of multiple "peering clubs" or
   "federations". When one VSP needs to reach a subscriber in a VSP with
   which it has no such relationship, but has such agreements with a
   third VSP which has such arrangements with the destination VSP (or
   some such extended path to that destination VSP), then this third VSP
   can play an ASP role by routing the traffic towards the destination.
   Such routing may be based on E.164 prefixes or other criteria such as
   domain.

   In the Information Services environment, the above relationship still
   holds, but may be based on agreements to provide Information Service
   rather than routing towards particular prefixes or domains. Thus a
   provider playing the role of ASP would have business arrangements
   with an Information Services provider, and also business arrangements
   with VSPs to provide access to Information Services.

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

   Though the TSP is transparent at the application layer, it does play
   a role because in some cases the incoming facility can be used to
   identify the provider, for instance in cases where there is only one
   provider connected via that TSP.





Haluska, et al.         Expires April 27, 2007                [Page 11]


Internet-Draft      Information Services Using SIP         October 2006


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

   Application Server (AS) - 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. This is part of the 3GPP
   IMS architecture.

   Call Session Control Function (CSCF) - A SIP proxy in an IMS network.
   From 3GPP TS 23.002: "The CSCF can act as Proxy CSCF (P-CSCF),
   Serving CSCF (S-CSCF) or Interrogating CSCF (I-CSCF). The P-CSCF is
   the first contact point for the UE within the IM subsystem (IMS); the
   S-CSCF actually handles the session states in the network; the I-CSCF
   is mainly the contact point within an operator's network for all IMS
   connections destined to a subscriber of that network operator, or a
   roaming subscriber currently located within that network operator's
   service area."

   Open Services Architecture Service Capability Server (OSA-SCS) - An
   IMS network element which communicates with the S-CSCF via the ISC
   interface, and an external AS via the OSA/Parlay API.

   OISP - Operator and Information Services Provider (OISP) - In this
   document, a term which 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".

   Transit Provider - A Transit provider does not host any subscribers,
   but rather routes session requests to other providers with which it
   has business relationships. Such routing might occur based on various
   criteria, such as least cost routing.




Haluska, et al.         Expires April 27, 2007                [Page 12]


Internet-Draft      Information Services Using SIP         October 2006


   Last Hop Provider - In this document, the term "last hop provider" or
   "last hop network" refers to the provider which passes session
   requests directly to the OISP. It may be the same as the caller's
   home provider, or it may be an ASP, transit provider, or other
   provider. "Last hop" is with respect to the OISP - it is the last
   provider the request traverses before arriving at the OISP.

   HSS - Home Subscriber Server. 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.

   ISC - IP multimedia Subsystem Service Control Interface. An interface
   point in the IMS architecture between an S-CSCF and a service
   platform such as a SIP AS or an OSA SCS. SIP is the protocol used
   over this interface.

   OSA SCS - Open Services Architecture Services Control Server - A
   service platform which provides an authenticated OSA/Parlay API
   interface to third party service platforms. Whereas a SIP AS within a
   network can directly access that network's elements, third party
   application servers must communicate via an OSA SCS.

   ATIS - Alliance for Telecommunications Industry Solutions - "A U.S.-
   based organization that is committed to rapidly developing and
   promoting technical and operations standards for the communications
   and related information technologies industry worldwide using a
   "pragmatic, flexible and open approach."

   PTSC - Packet Technologies and Systems Committee of ATIS. Formerly
   T1S1. "PTSC develops and recommends standards and technical reports
   related to services, architectures, and signaling, in addition to
   related subjects under consideration in other North American and
   international standards bodies."




Haluska, et al.         Expires April 27, 2007                [Page 13]


Internet-Draft      Information Services Using SIP         October 2006


   PTSC-SAC - Signalling, Architecture and Control subcommittee of PTSC.
   Formerly T1S1.7. "PTSC SAC advances the interoperability of
   telecommunication systems and services through the development of
   service and application descriptions and their supporting protocols
   related to network architectures for, access signaling for, and
   application of circuit mode, frame mode, packet mode, and cell mode
   networks via existing and emerging transport (e.g. IP) technology to
   enable multimedia services."



5. Service Description

   Information Services (IS) are services whereby information is
   provided by the network in response to user requests. This may
   include involvement of a human or automated agent. Usually, the user
   accesses the Information Service by placing a telephone call to the
   automated Information Service and verbally requests the information,
   such as movie listings, weather, or a listing.  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.  Like DA, Information Services are
   often provided on a wholesale basis to VSPS, and include features,
   such as branded announcements.  Some advanced Information Services,
   such as directions or SMS to the caller's cellphone are already
   available.  With migration to VOIP based platforms, much more
   advanced services are envisioned. Information Services includes
   Directory Assistance services.

   Directory Assistance (DA) is a specific type of Information Service
   whereby end users request a telephone number about an entity.
   Currently, the user places a telephone call to an automated DA
   service, verbally requests the phone number for a name and locality,
   and an automation system performs speech recognition, looks up the
   listing, and announces the phone number. Frequently, a live operator
   is attached to recognize the request and find the listing. DA


Haluska, et al.         Expires April 27, 2007                [Page 14]


Internet-Draft      Information Services Using SIP         October 2006


   services are often provided on a wholesale basis to Voice Services
   Providers (VSPs), and include features such as branded announcements.
   Some advanced services such as sending listings via SMS to the
   caller's cellphone are already available. With migration to VOIP
   based platforms, much more advanced services are envisioned.

   There are many variations on these services. Some common requirements
   include

   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.

   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
   includes:

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

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

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



Haluska, et al.         Expires April 27, 2007                [Page 15]


Internet-Draft      Information Services Using SIP         October 2006


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

   o  Possibly, the digits dialed by the caller.

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

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

   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
   network, and the information currently available. For instance, the
   home network may very little about OIS services, having farmed that
   service to another provider. Consequently it might simply route all
   such calls towards the OIS provider, which decides which service is
   to be offered.

   Authentication. When one network passes a call to another network,
   there is a need for the networks 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 networks,
   or some other policy set by the networks involved.

   Receipt of the OIS call. The OISP network needs to be able to receive
   such calls.

   Querying upstream networks for information. The OISP, or an
   intermediate provider may require information from an upstream
   provider. For instance, the capabilities and characteristics of the
   caller's equipment may be needed in order to influence call
   processing.




Haluska, et al.         Expires April 27, 2007                [Page 16]


Internet-Draft      Information Services Using SIP         October 2006


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

   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 VSP's service. Though the service is actually provided by
   the OISP, business arrangements would dictate such branded
   announcements.

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

   Recording the request. The OISP must be capable of recording the
   caller's 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.

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

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

   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.

   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



Haluska, et al.         Expires April 27, 2007                [Page 17]


Internet-Draft      Information Services Using SIP         October 2006


   operator for the call. It must be possible to determine the
   appropriate human operator to which the call should be routed.

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

   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.

   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.

   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.

   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.

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

   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 network elements and across
   providers. In order to perform accounting, a charge number or other
   such identifier is needed. Also, the identity of the network which
   directly hands off the call to the OISP may need to be known, since
   this is likely to be the provider with a business relationship with
   the OISP.



Haluska, et al.         Expires April 27, 2007                [Page 18]


Internet-Draft      Information Services Using SIP         October 2006


   There are several network scenarios which must be supported:

   Services are provided by the caller's home provider.

   Services are provided a third party provider which has direct SIP
   layer connectivity as well as business relationships with the
   caller's home provider.

   Services are provided a third party provider which has no direct SIP
   layer connectivity and no business relationships with the caller's
   home provider.



6. OISP Internal Architecture

   This section describes an initial view of the elements internal to
   the OISP architecture. The current list may be incomplete. This is
   expected to be further developed in a subsequent revision of this
   document.

   The following types of elements are present within the OISP network:

   Directory and Information Services Automated (DISA) System - This
   contains both AS and MS functions specifically for directory
   assistance and information services as well as other Operator
   Services. Includes ability to perform call control and speech
   recognition, text-to-speech, etc. and is the main component of a DA
   system. It is modeled as a SIP AS. The possibility of additional
   media servers, external to the DISA, is not ruled out. Within the
   OISP network, the DISA supports SIP interfaces to the SIP proxy, and
   sometimes with other internal elements, some of which it might
   communicate with through the SIP proxy. The DISA may need to
   communicate with upstream networks for instance to query information
   about the capabilities and characteristics of the caller's equipment.



Haluska, et al.         Expires April 27, 2007                [Page 19]


Internet-Draft      Information Services Using SIP         October 2006


   Automatic Call Distributor (ACD) server - 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.  The ACD server is modeled as an Application
   Server.

   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.

   Customer Profile Database - 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 - These gateways provide access and data via E-
   mail, SMS, MMS, WAP.

   Operator Workstations - Provides interface to the human operator. 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. These are
   modeled as SIP UAs.

   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.







Haluska, et al.         Expires April 27, 2007                [Page 20]


Internet-Draft      Information Services Using SIP         October 2006


7. Network Scenarios

   This section describes the network scenarios supported for OIS.



7.1. Services Provided by the Caller's Home Provider

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

                Figure 1 Services Provider by 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 providers
   OIS service to its own subscribers.

   1. The caller initiates an OIS call.

   In this case, the call is recognized as a DA call, and the caller's
   provider is also the OISP. The SIP proxy handling the call can
   retarget the INVITE by setting the Request-URI to the correct value,
   e.g. SIP: da-with-call-completion@my-provider.net.

   2. The SIP INVITE is sent to the DISA, which accepts the INVITE.

   The DISA needs to know the identity of the caller, and of the
   caller's home network, if it does not already know that information.
   The SIP From: header carries the identity information, but the
   problem is that it cannot necessarily be trusted. The SIP Identity
   mechanism as described in RFC 4744 Enhancements for Authenticated
   Identity Management in the Session Initiation Protocol (SIP) is a


Haluska, et al.         Expires April 27, 2007                [Page 21]


Internet-Draft      Information Services Using SIP         October 2006


   standardized SIP mechanism for cryptographically assuring the user's
   identity. If this has been applied, this provides the caller's
   identity to the DISA. In IMS based networks, the P-Asserted-Identity
   header defined in RFC 3325 Private Extensions to the Session
   Initiation Protocol (SIP) for Asserted Identity within Trusted
   Networks carries the network asserted identity of the caller. In
   either case, the caller's identity is provided.

   It is assumed that the right-hand side of the caller's SIP URI
   unambiguously defines the caller's home provider.

   The DISA may need to consult any available customer data to determine
   treatment for the call. Some of the data might not be present on the
   OISP infrastructure, but might rather be available in other parts of
   the provider's network. In an IMS based network, the DISA, being an
   AS, can request such information from the S-CSCF via the ISC
   interface, or from the HSS using the Sh interface.

   The DISA may need to know the capabilities and characteristics of the
   equipment being used by the calling user. In IMS based networks, this
   information is available to an AS from the S-CSCF via the ISC
   interface.

   The DISA connects the call to an internal media server and plays a
   customized announcement. It then prompts the user for the required
   information, for example the requested listing name and locality.
   When the caller speaks that information, the DISA records the audio.
   Speech recognition is performed on the audio, and a lookup is made
   against the listing databases. If the speech recognition or the
   lookup fails, the caller needs to be sent to a human operator.

   The DISA consults the ACD server to locate a suitable available human
   operator, and routes the call to the appropriate operator
   workstation. When the human operator answers, the audio clip is
   played as a "whisper" to the operator, and all available information
   is displayed on the workstation's display.


Haluska, et al.         Expires April 27, 2007                [Page 22]


Internet-Draft      Information Services Using SIP         October 2006


   The caller is connected to the operator, who interacts with the
   caller and queries the listing database to get the requested
   information. This information is either provided by the operator or
   connected back to the DISA which uses text to speech to speak the
   information to the caller.

   At this point the DISA may play an announcement offering call
   completion services to the caller, whereby the OISP completes the
   call, saving the user from having to remember the digits and dial the
   number. If accepted, call completion service is initiated.

   3., 4. Call completion could be implemented using third party call
   control (3PCC) as discussed in [3PCC]. Another way is to transfer the
   call using the SIP REFER methods described in [REFER]. It is
   preferable not to keep the DISA in the signaling path once call
   completion is performed; thus the REFER mechanism is preferred. The
   use of REFER also does not suffer the same problems of potential
   audio clipping which could exist using 3PCC.

   One area which is still under investigation is return of the call to
   the DISA after the completed call terminates. This requires some
   network element to remain in the signaling path or to otherwise have
   knowledge about the progress of the call. 3PCC inherently leaves the
   DISA in the signaling path. Using the REFER method, the associated
   signaling needs to pass through the caller's proxy (S-CSCF in IMS
   based networks), and it is this proxy which will decide when the
   completed call is over, and whether the caller should be returned to
   the DISA.

   For calls which come into the OISP via a PSTN gateway, the calls are
   often routed in on trunk groups related to the desired service,
   though calls for multiple services could use the same trunk group.
   The incoming trunk group number, along with other information (e.g.,
   dialed digits, II digits/OLI) which is signaled in via the PSTN GW,
   is used to influence treatment for the call.



Haluska, et al.         Expires April 27, 2007                [Page 23]


Internet-Draft      Information Services Using SIP         October 2006


   In such cases, the DISA needs the trunk group number in order to
   process the call. The work in progress "Representing trunk groups in
   tel/sip Uniform Resource Identifiers (URIs) - draft-ietf-iptel-trunk-
   group-08.txt" [TRKGRP] describes a standardized mechanism to convey
   trunk group parameters in sip and tel Uniform Resource Identifiers
   (URIs).



7.2. Services Provided by a Direct Third Party Provider



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


        Figure 2 Services Provider 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.

Since the OISP is a third party, it may not have direct access to some
of information required to process the call. Also, the OISP may not be
able to rely on the home provider's call control entity (S-CSCF for IMS
based networks) for return of the caller to the DISA after the completed
call.

IMS based networks have well defined interfaces and thus we can consider
multiple specific possibilities for this scenario in such networks.



Haluska, et al.         Expires April 27, 2007                [Page 24]


Internet-Draft      Information Services Using SIP         October 2006


Two implementation choices are explored here for IMS based networks.
First, the call could be routed directly to a third party's Application
Server. Second, the call could simply be routed to another provider.

The first choice is very similar to the previous scenario, except that
the call is routed directly to a third party AS, rather than to a home
network AS. Note that for IMS based networks, the use of SIP to
interface directly to third party ASs is not supported. With special
business arrangements, such an implementation might be possible.

Without such special arrangements, the standardized way to connect to
third party ASs in IMS based networks is using the OSA/Parlay API to an
OSA SCS in the provider's network, which in turn connects via SIP to the
S-CSCF. This document does not go into details of OSA/Parlay. Further,
the PTSC-SAC NGN Architecture does not allow third party AS's to perform
any call completion functionality, relegating them instead to DB lookup
type functionality. So, the OSA/Parlay API for third party application
servers will not be applicable in this scenario.

The second choice is to route the call to the OISP network. This is the
general case, and is what is covered here.

Since many of the details of the call flow are identical to the previous
scenario, this discussion will focus on the differences.

In this case, the call is recognized as a DA call, and the local call
control entity decides to route the call to the proper OISP. It can
retarget the INVITE by setting the Request-URI to the correct value,
e.g. SIP: da-with-call-completion@another-provider.net.

The call is routed out the home provider's network to the OISP provider.
In IMS based networks, in order to accept incoming calls, the provider
needs to provide a CSCF interface to other networks. Either an
Interrogating CSCF (I-CSCF) or an Interconnection Border Control
Function (IBCF) could accept the incoming call. S-CSCF functionality may



Haluska, et al.         Expires April 27, 2007                [Page 25]


Internet-Draft      Information Services Using SIP         October 2006


be desired as well. The main point is that the OISP needs a CSCF in
order to act as a third party provider.

The same mechanisms for identifying the caller's identity and network
can be used here as for the previous case: SIP Identity or P-Asserted-
Identity.

As in the previous scenario, the OISP might require equipment
capabilities and characteristics, or other customer data. How the OISP
can access customer and equipment data in the home network is an open
issue. The most promising appears to be use of OSA/Parlay to talk to an
OSA SCS in the home network, which would have access to the HSS via the
Sh interface and to the S-CSCF via the ISC interface. Note that this is
different from routing the call via the third party AS, which as
mentioned above, is restricted in the PTSC-SAC architecture; rather, the
third party AS is requesting information from the home network.

In the absence of specific customer and equipment data from the home
network, customized service may not be possible, and a more generic
service may be provided.

The next steps are the same as for the previous scenario, up to the
point where call completion is offered.

If call completion is to be performed, then as above the REFER should
pass through the caller's call control element. This allows that element
to know that call completion is being performed as a result of the DA
service, and also facilitates returning the caller to the OISP after the
call is over. Further, the caller's call control entity is likely to be
in a better position to know how (i.e. via which provider when there may
be more than one choice) the call should be routed.

How accounting is performed is not addressed in the current version of
this document, but it is likely to be different in this case than for
the previous case, due to the fact that multiple providers are involved.



Haluska, et al.         Expires April 27, 2007                [Page 26]


Internet-Draft      Information Services Using SIP         October 2006


7.3. Services Provided by an Indirect Third Party Provider



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

      Figure 3 Services Provided by an Indirect Third Party Provider

   In this scenario, the OISP is a third party provider, but the
   caller's 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, and this provider in turn routes either
   to the OISP, with which it has a relationship, or there could be
   multiple intermediate networks. One example of this would be where
   the caller's provider (A) has a relationship with some other provider
   (B), and B has a relationship with the OISP (C). This is seen when
   providers have membership in multiple, potentially overlapping sets
   of "peering clubs" or "federations" - when a provider does not have a
   peering with the desired provider, some other provider with which it
   does have a peering might be able to get the call to the destination
   provider. Another example would be a VOIP aggregator, for example
   providing terminations for multiple providers, and might also
   provider services such as DA for those providers as well.

   In this case, the call control entity analyzes the dialed digits or
   other signaled address information from the calling user as normal.
   There are several possible steps at this point.

   1. Provider A could recognize the call as a DA call, select an OISP,
   retarget the Request-URI based on the desired DA service, and route


Haluska, et al.         Expires April 27, 2007                [Page 27]


Internet-Draft      Information Services Using SIP         October 2006


   the call toward the OISP via some routing decision that it knows will
   get it to the desired  OISP. It is explicitly routing the call toward
   a specific OISP, but must do so via an intermediate network (provider
   B) because it has no direct path to the OISP.

   Provider B receives the call, which has already been recognized as a
   DA call, and for which the destination provider has already been
   selected. Provider B may or may not implement additional logic based
   on additional information to refine the treatment. Such logic could
   be based on information provider B already has, or provider B might
   possibly require more information from provider A. If such data is
   required, then there must be a means to obtain it. In IMS based
   networks, the most promising means to obtain this information is by
   having the DISA or other AS in provider B request this information
   from an OSA SCS in provider A using the OSA/Parlay API.

   In any case, provider B makes a decision and sends the call to the
   OISP as a DA call.

   2. Provider A could recognize the call as a DA call, and have no
   knowledge of any OISP because it does not have any relationship with
   an OISP. Rather it has one or more providers to which it could route
   the call. It could retarget the Request-URI based on the desired DA
   service, and route the call to provider B.

   Provider B receives the call, which has been retargeted as a DA call.
   While in the above scenario provider B could optionally implement
   additional logic, in this case provider B must implement the logic to
   select the destination OISP and possibly further refine the requested
   service. The same issues apply here as for the previous scenario if
   it needs to obtain information from provider A. Finally it selects
   the destination OISP, and potentially retargets the SIP-Request URI
   based on any refined information, and sends the call to the OISP.

   3. Provider A might not specifically recognize the call as a DA call,
   but rather treat the call as any other call routed on address


Haluska, et al.         Expires April 27, 2007                [Page 28]


Internet-Draft      Information Services Using SIP         October 2006


   information, such as dialed digits. In this case it routes to
   provider B because this is where it routes such calls. The SIP
   Request-URI is not retargeted for a specific service because the
   provider does not have any concept of DA calls. It simply routes such
   calls to a specific provider.

   Provider B receives the call. It must recognize the call as a DA
   call, make a decision about specific services, select an OISP, and
   retarget the SIP Request-URI towards the specific DA service in the
   specific OISP. In this scenario, provider A only needs to route the
   call based on address information; Provider B is recognizing it as a
   DA call, selecting and retargeting for specific DA services,
   selecting the appropriate OISP, and routing the call to that OISP. As
   in the previous cases, provider B may require information from
   provider A to aid in executing whatever logic is necessary to
   influence processing, and the same interfaces would again be
   applicable.

   At this point, the OISP receives the call.

   The OISP needs to know the caller's home network, so it can brand the
   call, and perhaps further influence treatment. This is accomplished
   as described above, using the SIP Identity mechanism for
   standardized, generic applications, or using the P-Asserted-Identity
   in IMS based deployments.

   For accounting purposes, and potentially to further refine treatment,
   the OISP needs to know the provider from which it received the call.
   In this example, that is provider B. In peering and other inter
   domain deployments, mutual TLS authentication is often used by the
   peers to authenticate each other.

   Authentication by definition means that the identity of the other
   party is unambiguously verified. One assumption is that the right
   hand side of SIP entities represents the provider, either directly or
   by some defined transform. Using mutual TLS, the right hand side of


Haluska, et al.         Expires April 27, 2007                [Page 29]


Internet-Draft      Information Services Using SIP         October 2006


   the SubjectAltName field in the X.509 certificate would identify the
   previous provider.

   Other methods of identifying the previous network's identity include
   the use of HTTP challenge authentication, where a cryptographic
   challenge verifies the asserted identity. The transport and/or
   network layer address of the peer could also be used, though this
   presents significant security risks.

   As in the previous scenario, equipment and customer data may be
   needed in order to influence call processing. The same issues apply
   as in the previous case. One potential complication is that the OISP
   might have no relationship with the home network, this area needs
   further study. It is also conceivable that the OISP might need to
   access similar data from the previous provider, in this case there is
   a relationship with the provider, so it could be handled the same as
   where in the previous case the OISP needed data from the home
   provider, with which it has a relationship.

   If and when call completion is requested, the  REFER should be routed
   back via the same route the initial INVITE came, in order to keep
   each provider on the signaling path. This is to accommodate whatever
   agreements are in place between the home provider and any
   intermediate providers regarding handling of call completion
   originations. As long as the REFER passes back through each provider,
   the OISP need not be concerned with whether the completion call is
   originated by provider B, by the caller's hone provider, or by the
   caller's UA itself.

   For PSTN originated calls, this scenario is the same as for "Services
   Provided by a Third Party Provider".

8. Signaling Requirements





Haluska, et al.         Expires April 27, 2007                [Page 30]


Internet-Draft      Information Services Using SIP         October 2006


8.1. Calling Party's Identity

For OIS applications, downstream networks 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 network
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 [SIP-IDENT] provides a
standardized, architecture agnostic SIP mechanism for cryptographically
assuring the user's identity.

The P-Asserted-Identity header [PAI] is a private extension which can be
used to carry a network asserted identity of the caller in IMS based
networks.

Note that some networks may allow their users to hide their identity,
usually at the user's request. 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 [PAI], "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."


Haluska, et al.         Expires April 27, 2007                [Page 31]


Internet-Draft      Information Services Using SIP         October 2006


When an OISP is outside any trust domain with the caller's home network,
or is not otherwise privy based on bilateral agreements to network
asserted identity information from the calling network when 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.



8.2. Home Network

The OISP needs to identify the home network or home provider of the
caller. This is needed for branding purposes as well as to potentially
influence treatment in other ways.

The basic mechanism for determining the home network 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.

[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



Haluska, et al.         Expires April 27, 2007                [Page 32]


Internet-Draft      Information Services Using SIP         October 2006


difficult to derive the home network 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 network 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 network 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 containing 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 network's identity is
consequently also not available, and call processing logic based on such
information (such as branding) cannot take place.

8.3. Last Hop Provider

The OISP needs to identify the last hop provider; that is, the provider
which sent the call to the OISP. This is needed for accounting purposes,
and also to potentially influence treatment in other ways.

Mutual TLS authentication is often used by SIP peers to authenticate
each other. Authentication by definition means that the identity of the
other party is unambiguously verified. Using mutual TLS, the right hand
side of the SubjectAltName field in the X.509 certificate would identify
the previous provider.




Haluska, et al.         Expires April 27, 2007                [Page 33]


Internet-Draft      Information Services Using SIP         October 2006


Other methods of identifying the previous network's identity include the
use of HTTP challenge authentication, where a cryptographic challenge
verifies the asserted identity. The transport and/or network layer
address of the peer could also be used, though this presents significant
security risks.

The use of TLS is not mandated In IMS based networks. This does not
prevent the use of mutual TLS, and if it is used, it can be used to
determine the last hop network.

In the absence of mutual TLS, the "host" field of the "sent-by" field of
the topmost mandatory Via header should be used to identify the last hop
network.

The Via header could be populated with a DNS hostname or an IP address.
If populated with a hostname, it is possible to derive the identity of
the last hop network directly from the domain portion of the hostname.
If it is populated with an IP address, this step may not be possible.
Configuration data may need to include both domain names and lists of IP
addresses associated with last hop networks.



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

Ways to represent this information in SIP need to be explored. There are
currently two proposals being considered in the IETF which might
potentially satisfy this requirement.


Haluska, et al.         Expires April 27, 2007                [Page 34]


Internet-Draft      Information Services Using SIP         October 2006


   o  The Calling Party's Category tel URI Parameter - draft-mahy-iptel-
      cpc-04.txt (work in progress) [IPTEL-CPC]

This defines a new parameter "cpc" which is applied to the SIP or tel
URI of the calling user. It allows for values such as "ordinary",
"prison", "police", "test", "operator", "payphone", "unknown",
"hospital", "cellular", "cellular-roaming". An example from the internet
draft:

   INVITE sip:bob@biloxi.example.com SIP/2.0
   To: "Bob" <sip:bob@biloxi.example.com>
   From: <tel:+17005554141;cpc=payphone>;tag=1928301774


   o  Conveying Calling Party Category (CPC) and Originating Line
      Information (OLI) using the Security Assertion Markup Language
      (SAML) - draft-schubert-sipping-saml-cphc-02.txt [CPC-SAML]

While [IPTEL-CPC] is simple to implement, [CPC-SAML] provides a
cryptographically verifiable assertion. Both are currently works in
progress, and any document with normative dependencies to such works
cannot be published until the works in progress are published. Further,
there is an open question as to whether [IPTEL-CPC] can carry OLI
information as well as CPC or ANI II information.



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




Haluska, et al.         Expires April 27, 2007                [Page 35]


Internet-Draft      Information Services Using SIP         October 2006


For PSTN interworking, the incoming trunk group identifier is a key
piece of information and must be known. Thus, at a PSTN to IP
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.

"Representing trunk groups in tel/sip Uniform Resource Identifiers
(URIs)" - draft-ietf-iptel-trunk-group-08.txt 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.



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


Haluska, et al.         Expires April 27, 2007                [Page 36]


Internet-Draft      Information Services Using SIP         October 2006


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



8.7. Charge Number

It is desirable to signal a charge number from the VSP towards the
Information Services provider, to assist in billing.

"Analysis of TISPAN requirements for Connected Identity in the Session
Initiation Protocol(SIP)" - draft-elwell-sip-tispan-connected-identity-
01.txt [CONNECTED-ID] proposes a method for doing this. This will be
analyzed and the results of this analysis presented in a future version
of this document.



8.8. Service Discovery

   An OISP might desire that their 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
   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.





Haluska, et al.         Expires April 27, 2007                [Page 37]


Internet-Draft      Information Services Using SIP         October 2006


9. Detailed Call Flow

   For this detailed call flow, the network scenario "Services provided
   by an indirect third party provider" is used.

   For brevity, only relevant SIP headers will be described.

   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.




























Haluska, et al.         Expires April 27, 2007                [Page 38]


Internet-Draft      Information Services Using SIP         October 2006


   F1 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 network knows nothing of OISP services, as it is 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. As usual, it adds a Via
   header with its own information to the message. The caller's identity
   is verified in a manner consistent with its policies, and the proxy
   adds two P-Asserted-Identity headers: one with a SIP URI, and another
   with a "tel" URI.

   F2 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: "732758123" <sip:73237581234@provider-a.com>
   P-Asserted-Identity: tel:+7327581234
   Content-Type: application/sdp
   Content-Length: ...




Haluska, et al.         Expires April 27, 2007                [Page 39]


Internet-Draft      Information Services Using SIP         October 2006


   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. As an example, if this were an IMS based
   network, an application server in provider B's network might query an
   OSA/SCS element in provider A's network using Parlay or Parlay-X to
   get this information. 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. As usual, it adds a Via header with its own information to
   the message.

   So, proxy-b retargets the Request-URI to reflect this, and routes the
   call to provider C (the OISP).

   F3 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
   Content-Type: application/sdp
   Content-Length: ...






Haluska, et al.         Expires April 27, 2007                [Page 40]


Internet-Draft      Information Services Using SIP         October 2006


   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.

   The proxy routes the call to the DISA. The DISA answers the call,
   establishing an audio session with the caller. While in this version
   of this document the MS is included as part of the DISA, the actual
   signaling to the MS might use the mechanism described in RFC 4240,
   populating the Request-URI to request a prompt-and-collect type
   service.

   The DISA needs to play a branded announcement to the caller, e.g.
   "thank you for using provider a". In order to do this, it needs to
   determine the caller's home provider. It examines the INVITE, and
   parses the PAI header containing the SIP URI.  The right hand side of
   the value is contains a domain name "provider-a.com", which it looks
   up in its configuration tables, from which it determines the proper
   announcement to play.

   The automated system prompts the user for the desired city, state,
   and listing, and records the caller's request, for later playback to
   a human operator if required. This might be needed for example if the
   subsequent voice recognition fails.

   The caller's request is processed by the voice recognition system,
   and in this case the listing is found, and played to the user. The
   DISA can use mechanisms similar to that employed by provider B to
   query provide A's network, in this case for the capabilities and
   characteristics of the caller's user equipment, as well as
   information about any additional services the caller subscribes to.
   If applicable, the DISA might initiate sending the listing to the
   caller's user equipment using one of the supported protocols, for
   example MMS, SMS, or SIP IM.



Haluska, et al.         Expires April 27, 2007                [Page 41]


Internet-Draft      Information Services Using SIP         October 2006


   Next, it is determined that call completion service should be
   offered. The DISA causes the user to be prompted whether he would
   like to have the call automatically initiated, and the user indicates
   such a desire.

   The DISA uses the SIP REFER mechanism to request that the proxy
   initiate the call. The proxy uses the third party call control
   mechanism to do so; in the meantime it may remain in control of any
   audio streams such as announcements etc. being played toward the
   user.

   When the call is answered, the OISP is no longer involved in the
   call. Logic in the home provider's network or in any other involved
   network can cause the OISP to be reconnected when this call is over.


10. VoIP Information Services - Summary and Next Steps

This document has defined some preliminary requirements for a framework
or architecture for IS and OS using SIP. These are primarily business
drivers. Next steps will include developing a more complete list of
requirements.

This document has a goal to define a framework or architecture based on
the above mentioned requirements. Once the requirements are completed,
the definition can begin.

A list of information which needs to be conveyed has been developed, and
candidate proposals identified for each of these. Next steps will
include analysis of these proposals, and presenting the results.

Call flows will not be developed until mechanisms are selected and the
architecture or framework is defined.





Haluska, et al.         Expires April 27, 2007                [Page 42]


Internet-Draft      Information Services Using SIP         October 2006


11. Security Considerations

This document is an early version and at this point security
considerations have not yet been developed.

12. IANA Considerations

This document is an early version and at this point IANA considerations
have not yet been developed.





























Haluska, et al.         Expires April 27, 2007                [Page 43]


Internet-Draft      Information Services Using SIP         October 2006


13. References



13.1. Normative References

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

   [TRKGRP] Gurbani, Jennings, "Representing trunk groups in tel/sip
             Uniform Resource Identifiers (URIs)", draft-ietf-iptel-
             trunk-group-08.txt, October 2006. (work in progress)

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

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

   [IPTEL-CPC]  Mahy, "The Calling Party's Category tel URI Parameter",
             draft-mahy-iptel-cpc-04.txt, October 2006. (work in
             progress)

   [CPC-SAML]  Schubert, et al, "Conveying Calling Party Category (CPC)
             and Originating Line Information (OLI) using the Security
             Assertion Markup Language (SAML)", draft-schubert-sipping-
             saml-cpc-02.txt, July 2006. (work in progress)

    [CONNECTED-ID] Elwell, et al, "Analysis of TISPAN requirements for
             Connected Identity in the Session Initiation Protocol
             SIP)", draft-elwell-sip-tispan-connected-identity-01.txt,
             June 2006. (work in progress)




Haluska, et al.         Expires April 27, 2007                [Page 44]


Internet-Draft      Information Services Using SIP         October 2006


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

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

   [REFER] Sparks, "The Session Initiation Protocol (SIP) Refer Method",
             RFC 3515, April 2003.

   [3PCC]    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 April 27, 2007                [Page 45]


Internet-Draft      Information Services Using SIP         October 2006


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


Haluska, et al.         Expires April 27, 2007                [Page 46]


Internet-Draft      Information Services Using SIP         October 2006


      Piscataway, NJ  08854-4157
      USA

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


      Richard Ahern
      BellSouth Corporation
      1876 Data Drive
      Room 314
      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


Haluska, et al.         Expires April 27, 2007                [Page 47]


Internet-Draft      Information Services Using SIP         October 2006


     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


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


Haluska, et al.         Expires April 27, 2007                [Page 48]


Internet-Draft      Information Services Using SIP         October 2006


   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 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 Internet Society (2006).

   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 April 27, 2007                [Page 49]


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