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 ;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]