[Docs] [txt|pdf] [Tracker] [Email] [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: December 18, 2006                                      P. Roder
                                            Telcordia Technologies, Inc.
                                                                R. Ahern
                                                   BellSouth Corporation
                                                             P. Lum Lung
                                      Qwest Communications International
                                                           June 16, 2006


       Considerations for Directory Assistance Services Using SIP
           draft-haluska-sipping-directory-assistance-00.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."

   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 December 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Directory Assistance (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 are already becoming



Haluska, et al.         Expires December 18, 2006               [Page 1]


Internet-Draft       Directory Assistance Using SIP            June 2006


   more advanced.  Currently the DA service can complete the call for
   the user, can send SMS with the listing to the user's wireless phone,
   and can provide the user with a wide range of information, such as
   movie listings and the weather.

   Moving ahead, DA 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 DA directions
   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.

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

   Implementing DA 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.
   Should it be decided that extensions to SIP are required, it is the
   authors' intention to use the SIP change process documented in [BCP
   67] to attain standardization.




























Haluska, et al.         Expires December 18, 2006               [Page 2]


Internet-Draft       Directory Assistance Using SIP            June 2006


1.  Introduction

   Directory Assistance (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 are already becoming
   more advanced.  Currently the DA service can complete the call for
   the user, can send SMS with the listing to the user's wireless phone,
   and can provide the user with a wide range of information, such as
   movie listings and the weather.

   Moving ahead, DA 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 DA directions
   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.

   DA providers are planning to migrate to SIP [1] based platforms,
   which will enable such advanced services, while continuing to support
   traditional DA services.

   Implementing DA 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.
   Should it be decided that extensions to SIP are required, it is the
   authors' intention to use the SIP change process documented in [BCP
   67] to attain standardization.























Haluska, et al.         Expires December 18, 2006               [Page 3]


Internet-Draft       Directory Assistance Using SIP            June 2006


2.  Terminology

   This section defines terms that will be used to discuss DA services.

   Directory Assistance (DA) - a service whereby end users request
   information such as 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 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.

   DA Provider - The DA provider is the provider of DA services to end
   users.  The DA provider provides retail services directly to end
   users, and provides wholesale services to Local Services Providers,
   such as the VSPs.  Specifically, the DA providers provide DA services
   to the end users that are served by other Local Services Providers,
   such as VSPs.  The DA provider needs to identify the VSP in order to
   provide such services as customized announcements, and may also need
   to know the identity of other intermediate entities for billing
   purposes.

   Voice Services Provider (VSP) - The VSP is the provider of voice
   services to end users.  The VSP may be directly connected to the DA
   provider or they may communicate with the DA provider via an
   Aggregation Services Provider (ASP) and/or Transport Services
   Provider (TSP).  The VSP may also be an ASP and/or TSP.

   Aggregation Services Provider (ASP) - The ASP is the provider that
   routes DA calls from multiple VSPs to a 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.

   Transport Services Provider (TSP) - The TSP is the provider of the
   transport network elements between the VSP's network and the DA
   provider, and between the ASP's network and the DA provider.  The TSP
   transports the VoIP signaling and media streams (e.g., Session
   Initiation Protocol for signaling and Real-time Transport Protocol
   from media) from the VSPs and ASPs to the DA providers.  The TSP may
   support the physical layer (e.g., SONET), link layer (e.g.,
   Ethernet), and network layer (IP) of the Open Systems Interconnection
   (OSI) protocol model.  This document assumes that the VSP, the ASP,
   and the DA provider all use SIP for VoIP signaling and that the TSP



Haluska, et al.         Expires December 18, 2006               [Page 4]


Internet-Draft       Directory Assistance Using SIP            June 2006


   transparently passes the SIP signaling from the VSP to the DA
   provider or from the ASP to the DA provider.  The TSP may also be a
   VSP and/or ASP.

   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.

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







































Haluska, et al.         Expires December 18, 2006               [Page 5]


Internet-Draft       Directory Assistance Using SIP            June 2006


3.  The Need to Identify Service Providers

   Because DA providers provide branded service on a wholesale basis,
   and may need to route a call back through the originating VSP's
   network, it is necessary to know which providers are involved in a
   call.  This section illustrates several potential deployment
   scenarios for IP-based DA providers, serving both VOIP end users as
   well as PSTN end users.  These examples will identify the various
   type of providers which could be involved in a DA call, and will show
   that while in some cases provider identities are known implicitly,
   that this is not the case in general and thus some means of signaling
   this information explicitly will be needed.

   1.  VSP and DA provider

   2.  VSP, TSP, and DA provider

   3.  VSP, ASP, and DA provider

   4.  VSP, ASP, TSP and DA provider

   5.  TDM CLEC and DA provider

   6.  TDM CLEC, ASP, TSP and DA provider

3.1.  Scenarios

3.1.1.  Scenario 1: VSP and DA provider

   In Scenario 1, the VoIP provider has a dedicated connection to the DA
   provider that carries both SIP and IP traffic.  This connection may
   be a direct physical connection between the VSP's network and the DA
   provider's network.  Alternatively, this connection may be a
   dedicated data link (like a Frame Relay link) over a shared physical
   medium (like a SONET Ring) between the VSP's network and the DA
   provider's network.  The VoIP provider routes all DA calls to the DA
   provider via this dedicated connection by exchanging SIP messages and
   RTP media streams with the DA provider.

   The DA provider needs to know the identity of the VSP in order to
   brand and bill DA calls from the VSP, route these calls back to the
   VSP when call completion is needed, and perform additional call
   processing functions, such as operator queue selection.  Since there
   is a dedicated connection from the VSP to the DA provider, the DA
   provider implicitly knows the VSP's identity.






Haluska, et al.         Expires December 18, 2006               [Page 6]


Internet-Draft       Directory Assistance Using SIP            June 2006


3.1.2.  Scenario 2: VSP, TSP and DA provider

   In Scenario 2, the VoIP provider communicates with the DA provider
   via a TSP's network.  In this scenario, the TSP's network may either
   be a physical layer network (e.g., a SONET ring), a link layer
   network (e.g.  Frame Relay links carried over a SONET ring), or a
   network layer network (e.g. an IP network that contains IP routers,
   and that carries IP packets over Frame Relay links over a SONET
   ring).  The VoIP provider routes all DA calls to the DA provider via
   the TSP's network.  The VoIP provider logically exchanges SIP
   messages and RTP media streams with the DA provider, since the TSP
   transparently passes the SIP messages and RTP media streams.

   The DA provider needs to know the identity of the VSP in order to
   brand and bill DA calls from the VSP, route these calls back to the
   VSP when call completion is needed, and perform additional call
   processing functions, such as operator queue selection.  Since there
   may be multiple VSPs served via the TSP, the DA provider does not
   implicitly know the VSP's identity.  Thus the DA provider needs some
   way to identify the VSP.  This could be done either via explicit
   signaling or via a database lookup based on the caller's Directory
   Number (DN).  In the latter case, the VSP needs the caller's DN from
   the VSP.

3.1.3.  Scenario 3: VSP, ASP and DA provider

   In Scenario 3, the VoIP provider communicates with the ASP and the
   ASP communicates with the DA provider directly.  In this scenario,
   the ASP has a dedicated connection to the DA provider.  The VoIP
   provider routes all DA calls to the ASP, and the ASP routes all DA
   calls to the DA provider via this dedicated connection.

   The DA provider needs to know the identity of the VSP for branding,
   and needs to know the identity of the ASP for billing.  Additionally,
   the DA provider may use the identity of the ASP to determine the
   appropriate route (e.g., to route the call back to the ASP for call
   completion).  The DA provider may use the VSP and/or ASP identities
   for additional call processing functions, such as operator queue
   selection.  The ASP identity is implicitly known because it is served
   by a dedicated connection, much as the VSP is implicitly known in
   Scenario 1.  As in Scenario 2, the VSP's identity is not implicitly
   known, so it must be explicitly signaled, or derived from the
   caller's DN.

3.1.4.  Scenario 4: VSP, ASP, TSP, and DA provider

   In Scenario 4, the VoIP provider communicates with the ASP and the
   ASP communicates with the DA provider via the TSP.  In this scenario,



Haluska, et al.         Expires December 18, 2006               [Page 7]


Internet-Draft       Directory Assistance Using SIP            June 2006


   as in the previous one, the TSP's network may either be a physical
   layer network a link layer network, or a network layer IP network.
   The VoIP provider routes all DA calls to the ASP, and the ASP routes
   the DA calls to the DA provider via the TSP.  The VoIP provider
   exchanges SIP messages and RTP media streams with the ASP, and the
   ASP logically exchanges SIP messages and RTP media streams with the
   DA provider via the TSP, since the TSP transparently passes the SIP
   messages and RTP media streams.

   In this scenario, neither the VSP nor the ASP identities are
   implicitly known.  Again, the VSP identity could either be explicitly
   signaled or derived from the caller's DN.  The ASP identity, however,
   needs to be explicitly signaled.

3.1.5.  Scenario 5: TDM CLEC or Wireless Carrier and DA provider

   In Scenario 5, the TDM CLEC or Wireless Carrier routes the DA calls
   to the VoIP Gateway via a TDM trunk.  The Gateway then translates the
   TDM call to a VoIP call and sends SIP messages to the DA provider to
   set up the VoIP call.

   In this scenario, the DA provider needs the identity of the TDM CLEC
   / Wireless Carrier for branding, billing, routing, and additional
   call processing functions.  The incoming trunk group at the VoIP
   Gateway uniquely identifies the TDM CLEC.  As a result, consideration
   should be given to signaling the TDM CLEC/Wireless Carrier's identity
   (e.g., as an incoming trunk group identifier or an Operating Company
   Number) from the VoIP Gateway to the DA provider via a SIP message.

3.1.6.  Scenario 6: TDM CLEC or Wireless Carrier, ASP, TSP, and DA
        provider

   In Scenario 6, the TDM CLEC or Wireless Carrier routes the DA calls
   to the VoIP Gateway via a TDM trunk.  The Gateway then translates the
   TDM call to a VoIP call and sends SIP messages to the ASP to set up
   the VoIP call.  The ASP then routes the call to the DA provider via
   the TSP.

   In this scenario, the DA provider needs the identity of the TDM CLEC
   or Wireless Carrier for branding and the identity of the ASP for
   billing and routing.  The identity of the TDM CLEC or Wireless
   Carrier or the ASP identity may be used for additional call
   processing functions, such as operator queue selection.  The incoming
   trunk group at the VoIP Gateway uniquely identifies the TDM CLEC/
   Wireless Carrier.  As a result, consideration should be given to
   signaling the TDM CLEC/Wireless Carrier's identity (e.g., as an
   incoming trunk group identifier or an Operating Company Number) from
   the VoIP Gateway to the ASP using a SIP message.  If the ASP receives



Haluska, et al.         Expires December 18, 2006               [Page 8]


Internet-Draft       Directory Assistance Using SIP            June 2006


   the TDM CLEC/Wireless Carrier's identity, it should send it to the DA
   provider via the TSP using a SIP message.

3.2.  Potential Provider Identifiers

   The following are several possible ways to identify the providers
   (VSPs, ASPs, TDM CLECs, and TDM Wireless Carriers) which are involved
   in a call.  All the options are not applicable to all types of
   providers.

   1.  A unique identity for each provider, such as the National
       Exchange Carrier Association (NECA) Operating Company Number
       (OCN), which comprises 4 alphanumeric characters.  The OCN may be
       delivered to the DA provider in the SIP INVITE message, if a
       standardized field is defined in the SIP message to carry it (for
       example: OCN: VSP1).

   2.  The right hand side of the values in "Via" headers inserted by
       the providers.  The first Via would presumably be inserted by the
       serving VSP, while additional Via headers are inserted by ASPs.
       E.g. (irrelevant headers omitted):

          INVITE sip:411@VSP1.net SIP/2.0

          From: Alice <sip:alice@VSP1.net>;tag=1234567

          To: sip:411@VSP1.net

          Via: proxy1@VSP1.net

          Via: proxy2@ASP1.net

   3.  If the calling party's DN is signaled to the DA provider, then
       the VSP identity could be derived from the calling DN.  Since
       this option requires VSPs to provide their end users' DNs to the
       DA providers, the use of this option depends on VSP business
       arrangements.  This option is not expected to be used by all
       VSPs.

   4.  Implicit knowledge of the provider when it is served via a
       dedicated connection.










Haluska, et al.         Expires December 18, 2006               [Page 9]


Internet-Draft       Directory Assistance Using SIP            June 2006


4.  Other Required Information

   In addition to utilizing VoIP Network identifiers for branding,
   billing, routing, and additional call processing functions, DA
   providers use other information associated with the calling end
   user's equipment to influence call processing.  Specifically, the DA
   provider needs the following additional signaling information:

   o  Originating Station Type

   o  SS7 versus MF indication

   o  Network Type Identifier

   o  Codecs

   o  Dialed Digits

4.1.  Originating Station Type

   In the current PSTN in North America, DA 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.

4.2.  SS7 Versus MF Indication

   DA providers need to know whether the call came in via an SS7 or MF
   connection.

   Ways to represent this information in SIP need to be explored.

4.3.  Network Type Identifier

   Today, DA providers perform call processing functions based on the
   type of network.  For example, a unique operator queue can be
   selected if the call is wireless.  Plus, the DA Automation (DAA)
   recognition rates can be improved with the knowledge of the type of
   network.  One way DA providers can benefit from receiving an
   indicator that the type of network is VoIP is by setting up operator
   teams that are especially suited to handle calls from VoIP providers.




Haluska, et al.         Expires December 18, 2006              [Page 10]


Internet-Draft       Directory Assistance Using SIP            June 2006


   Ways to represent this information in SIP need to be explored.

4.4.  Codec

   By knowing the codec, the success rate for automated speech
   recognition can be improved.

   This is currently signaled in the SDP

4.5.  Dialed Digits

   For DA, the dialed digits continue to be important to differentiate
   411 calls from 555 calls and direct dialed calls from 0+ dialed
   calls.

   This information is carried in the initial INVITE, but due to
   retargeting or other reasons, it may be modified.  It will be
   important to maintain this information along the entire path.  There
   may be existing mechanisms in SIP to handle this, further study is
   needed.































Haluska, et al.         Expires December 18, 2006              [Page 11]


Internet-Draft       Directory Assistance Using SIP            June 2006


5.  VoIP DA - Summary and Next Steps

   Directory Assistance is a service seen as useful by end users and is
   revenue-generating for providers.  DA providers wish to migrate to
   SIP based platforms.  In doing so, they need to continue to support
   existing PSTN service.  In order to support both existing PSTN
   services as well as move ahead with IP based services, certain
   information needs to be exchanged.  It is expected that currently SIP
   will not support the exchange of all of this information, and that
   extensions will be needed.

   This document has laid out some of the information required for IP
   based DA services.  The intended next steps would be to stimulate
   discussion with the SIPPING working group on how this information
   could be exchanged, and to pursue standardization of any identified
   required extensions per the SIP change process.



































Haluska, et al.         Expires December 18, 2006              [Page 12]


Internet-Draft       Directory Assistance Using SIP            June 2006


6.  Security Considerations

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















































Haluska, et al.         Expires December 18, 2006              [Page 13]


Internet-Draft       Directory Assistance Using SIP            June 2006


7.  IANA Considerations

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

8.  References

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










































Haluska, et al.         Expires December 18, 2006              [Page 14]


Internet-Draft       Directory Assistance Using SIP            June 2006


Authors' 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


   Richard Ahern
   BellSouth Corporation
   1876 Data Drive
   Room 314
   Hoover, AL  35244
   USA

   Email: Richard.Ahern@bellsouth.com









Haluska, et al.         Expires December 18, 2006              [Page 15]


Internet-Draft       Directory Assistance Using SIP            June 2006


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

   Email: paul.lumlung@qwest.com











































Haluska, et al.         Expires December 18, 2006              [Page 16]


Internet-Draft       Directory Assistance Using SIP            June 2006


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 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 December 18, 2006              [Page 17]


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