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" From: ;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: ;tag=1234567 To: 411 Contact: 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: ;tag=1234567 To: 411 Contact: P-Asserted-Identity: "732758123" 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: ;tag=1234567 To: 411 Contact: P-Asserted-Identity: "732758123" 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]