Network Working Group J. Haluska Internet Draft R. Berkowitz Expires: August 2007 P. Roder W. Downum Telcordia Technologies, Inc. R. Ahern AT&T Customer Information Services P. Lum Lung Qwest Communications International N. Costantino Soleo Communications, Inc. C. Blackwell J. Mellinger Verizon D. Scott VoltDelta February 15, 2007 Considerations for Information Services and Operator Services Using SIP draft-haluska-sipping-directory-assistance-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Haluska, et al. Expires August 15, 2007 [Page 1] Internet-Draft Information Services Using SIP February 2007 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 15, 2007. Abstract Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. This document aims to identify how such services can be implemented using existing or currently proposed SIP mechanisms, and to provide a set of Best Current Practices to facilitate interoperability. Table of Contents 1. Introduction..................................................3 2. Terminology...................................................4 3. High Level Requirements.......................................7 4. Service Description..........................................11 5. OISP Internal Architecture...................................15 6. General Approach.............................................16 7. Signaling Mechanisms.........................................18 7.1. Calling Party's Identity................................18 7.2. Provider Identification.................................20 7.2.1. Home Provider......................................20 7.2.2. Last Hop Provider..................................21 7.2.3. Arbitrary Traversed Provider.......................22 7.3. Originating Station Type................................24 7.4. Trunk Group Identifier..................................25 7.5. Dialed Digits...........................................26 7.6. Retargeting to Identify the Desired Service.............27 7.7. Charge Number...........................................27 7.8. Passing Whisper.........................................28 Haluska, et al. Expires August 15, 2007 [Page 2] Internet-Draft Information Services Using SIP February 2007 7.9. Calling Equipment Capabilities and Characteristics......31 7.10. Media Server Returning Data to the Application Server..32 7.11. Service Discovery......................................32 8. Call Flow....................................................33 9. VoIP Information Services - Summary and Next Steps...........42 10. Security Considerations.....................................42 11. IANA Considerations.........................................43 12. References..................................................44 12.1. Normative References...................................44 12.2. Informative References.................................44 Author's Addresses..............................................46 1. Introduction Information Services are services whereby information is provided in response to user requests. This may include involvement of a human or automated agent. Information Services may include call completion to a requested telephone number and other extensions 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 August 15, 2007 [Page 3] Internet-Draft Information Services Using SIP February 2007 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. It is intended to provide a Best Current Practices document to facilitate interoperability. 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. This document aims to identify how such services can be implemented using existing or currently proposed SIP mechanisms, and to provide a set of Best Current Practices to facilitate interoperability. 2. Terminology This section defines terms that will be used to discuss Information Services. Application Server (AS) - An Application Server is a server providing value added services. It may influence and impact SIP sessions on behalf of the services supported by the service provider's network. Back End Automation - Back End Automation refers to automation of the function that provides listing information to the caller. This includes playing a verbal announcement with the listing information, and may also include prompting the user for call completion service. Branding - Branding is a service where customized announcements are provided to the caller to identify the service provider. For example, if the service is provided to a Home Provider's subscribers by a third party provider, branded service might include a message thanking them for using that Home Provider. Thus Haluska, et al. Expires August 15, 2007 [Page 4] Internet-Draft Information Services Using SIP February 2007 the user experience is that the service is provided by their Home Provider rather than some third party. Branding can be influenced by a number of factors, including but not limited to the identity of the caller's Home Provider, or of other providers involved in the call. Call Completion - Call Completion is a service where a call is initiated by the provider on behalf of the user. For example, in the DA service, once the DA provider has identified the requested listing, it may offer to complete the call for the caller, usually for some additional fee. This relieves the user from having to remember the number and then dial it. DA Provider -The DA provider is the provider of DA services to end users. Since DA services are a subset of IS services, a DA provider is also an IS provider, and the definition of IS provider holds true for DA provider, except that the scope of services is limited to DA services. Front End Automation - Front End Automation refers to automation of the initial customer contact, whereby a branded announcement may be played, a prompt is played to the user, and the user's spoken request is recorded. Speech recognition and querying for the listing information are performed as part of front end automation. Home Provider - The service provider who is responsible for providing voice services to the calling customer. This is the service provider that has the business relationship with the calling customer. The identity of the home provider influences call processing treatment, such as branding and operator queue selection. HSS - Home Subscriber Server. The Home Subscriber Server is an IMS network element similar to a Home Location Register. It is a database containing information about the subscriber, user equipment, filter criteria for call processing triggers, etc. Information Services (IS) Provider - The IS provider is the provider of Information Services to end users. The Information Services provider provides retail services directly to end users, and provides wholesale services to other service providers. ISC - IP multimedia Subsystem Service Control Interface. AThe IP multimedia Subsystem Service Control Interface is 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. Haluska, et al. Expires August 15, 2007 [Page 5] Internet-Draft Information Services Using SIP February 2007 Last Hop Provider - In this document, the term "last hop provider" 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 some other provider. "Last hop" is with respect to the OISP - it is the last provider the request traverses before arriving at the OISP. This term implies only a topological relationship. Layer 3 connectivity - This refers to IP connectivity, for example as provided by an Internet Service Provider or Managed IP service provider. If one entity has Layer 3 connectivity to another entity, then it can route packets to that entity. This does not imply anything about any physical path between the entities. Nor does it imply any application layer connectivity between the entities. Media Server: A Media Server is a general-purpose platform for executing real-time media processing tasks. Examples of typical functions performed by media servers include playing announcements, collecting speech and/or DTMF digits, and performing conferencing functions. OISP - Operator and Information Services Provider (OISP) - In this document, this term refers to an Information Services Provider, Directory Assistance Provider, or Operator Services Provider, depending on the context. This term is used for brevity. We are also defining this to be an adjective, thus "OISP services" is a convenient, intuitive way to say "Operator and Information Services". Retail DA service - A retail DA service is a DA service that is provided to a user by the user's Home Provider. SIP Layer connectivity - When one entity has SIP level connectivity to another entity, this implies that the second entity will accept, process, and route SIP requests from the first entity. This would usually involve business agreements as well. Time Division Multiplexed (TDM) Local Exchange Carriers (LECs) - ATDM LEC provides local exchange service to end users utilizing TDM-based switching systems. Transit Provider - A provider acts as a Transit Provider when it facilitates session setup between other providers. It can perform this role irrespective of whether it hosts subscribers. 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 Haluska, et al. Expires August 15, 2007 [Page 6] Internet-Draft Information Services Using SIP February 2007 provider. VSPs, and IS or DA providers may or may not share the same TSP for access to each other. Further, each of these providers may have multiple TSPs. In this case, the decision as to which is used is determined by the policy of the entity sending the traffic; the Border Gateway Protocol (BGP) is often used. It is entirely possible that the traffic from each entity towards the other takes separate paths; i.e. it should not be assumed that the incoming and outgoing paths are symmetric. Though the TSP is transparent at the application layer, knowledge of its identity may play a role in influencing the service logic 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. Voice Services Provider (VSP) - An entity that provides transport of SIP signaling to its customers. It may also provide media streams to its customers. Such a service provider may additionally be interconnected with other service providers; that is, it may "peer" with other service providers. A VSP may also interconnect with the PSTN. Whisper - During front end automation, the OIS-MS will record and may time compress the caller's perhaps meandering speech into what is known as the "whisper". This is intended to be played into a human operator's ear, should the call be referred to an operator, to avoid the operator from having to prompt the caller again. The whisper is obtained during the front end automation, and saved as an audio file. Wholesale DA service -A wholesale DA service is a DA service that is provided to a user by a Service Provider other than the user's Home Provider. 3. High Level Requirements In addition to all-IP scenarios, it must be possible to support interworking with existing PSTN and wireless based providers, via both SS7 and MF interconnections. Haluska, et al. Expires August 15, 2007 [Page 7] Internet-Draft Information Services Using SIP February 2007 It must be possible to support accounting. This includes both online and offline accounting. It must be possible to perform accounting for all actions associated with a particular call, and further to be able to correlate actions across multiple provider elements and across providers. It must be possible to support multiple Operator and Information Services Providers (OISPs) per originating provider. The choice as to which OISP to be used could be on a per subscriber basis, or on other criteria. It must be possible to support multiple OISP providers per call. For example, one provider might be used for front end automation, and another used for operator assistance. It must be possible to provide an automated announcement to the user, and prompt the user for the type of query and query information. It must be possible to pass a "whisper" to the operator workstation. It must be possible to connect the user to a human operator. It must be possible to provide an automated announcement of the requested information. It must be possible to prompt the user for call completion. It must be possible to perform call completion. It must be possible to support the case where OIS services are provided by the caller's Home Provider. This scenario is known in the OIS industry as the Retail scenario. In this case, the caller's Home Provider is also an OISP, and provides OIS service to its own subscribers. This is illustrated in the following figure: +--------+ +--------------------+ | Caller |----| Home +------+ | | | | Provider | OISP | | | | | +------+ | +--------+ +--------------------+ Figure 1 Services Provider by Home Provider Haluska, et al. Expires August 15, 2007 [Page 8] Internet-Draft Information Services Using SIP February 2007 It must be possible to support the case where OIS services are provided by a direct third party provider. In this scenario, the OISP is a third party service provider, and there is direct SIP layer connectivity as well as business relationships between the calling user's provider and the OISP. This is illustrated in the following figure: +--------+ +----------+ +------+ | Caller |----| Home |---| OISP | | | | Provider | | | +--------+ +----------+ +------| Figure 2 Services Provider by a Direct Third Party Provider It must be possible to support the case where services are provided by an indirect third party provider. In this scenario, the OISP is a third party provider, but the caller's Home Provider does not have direct SIP connectivity to the OISP. Further, it's possible that it has no business relationship with the OISP. The caller's provider routes the call to a provider with whom it does have a relationship, and this provider in turn routes either to the OISP, with which it has a relationship, or there could be multiple intermediate networks. 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. This is illustrated in the following figure: Haluska, et al. Expires August 15, 2007 [Page 9] Internet-Draft Information Services Using SIP February 2007 +--------+ +--------+ +---------+ +------+ | Caller | |Home | | Inter- | | OISP | | |----|Provider|---| mediate |---| | | | | | | Provider| | | | | | (A) | | (B) | | (C) | +--------+ +--------+ +---------+ +------+ Figure 3 Services Provided by an Indirect Third Party Provider The following are potential future requirements. Operation via the general internet, not specific to any particular SDO's architecture, and not depending on any protocol extensions specific to those architectures, should be supported. In addition to the basic DA functionality, the architecture will need to support additional technical capabilities. These capabilities are currently under investigation. The following are some business needs which drive these capabilities. It must be possible to support multiple Information Services providers per originating provider. For instance, a Home Provider must be able to select an appropriate Information Services provider from among several Information Services providers based on criteria 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. Haluska, et al. Expires August 15, 2007 [Page 10] Internet-Draft Information Services Using SIP February 2007 It must be possible to support Purchase services and Concierge services. Such services facilitate the Information Services operator providing assistance to the caller after the listing has been announced and perhaps call completion performed. The call is routed to an Information Services operator who interacts with the customer, offering to help make a purchase. Concierge service is similar; the Information Services operator offers to make e.g. restaurant reservations for the caller. It must be possible to provide an application interface to other types of systems. An example could be a web based API, so that once some online search engine has located some business listing, the services of the Information Services provider could be invoked by the user from the web page. It must be possible to support IPTV interactive services. As multiple services such as IM and telephony are integrated with IPTV, it must be possible to initiate Information Services requests in this context as well. 4. Service Description Information Services (IS) are services whereby information is provided in response to user requests. This may include involvement of a human or automated agent. Usually, the user accesses the Information Service by placing a voice call to the automated Information Service and verbally requests the information, such as phone number, movie listings, weather, etc. Frequently, a live operator is attached to recognize the user's verbal request. Sometimes, the user can utilize other access methods, such as SMS, IM, or HTTP-initiated requests. These additional methods are not currently covered in this document. Information Services are often provided on a wholesale basis to Home Providers, and include features such as branded announcements. Directory Assistance (DA) is a specific type of Information Service whereby end users request a telephone number for an entity. The following represents a list of representative steps taken during the course of a typical DA request. Haluska, et al. Expires August 15, 2007 [Page 11] Internet-Draft Information Services Using SIP February 2007 1. Initial recognition of an OIS call. At some point, the call needs to be identified as an OIS call, and appropriate routing or other logic must be invoked in order to fulfill the request. This could be based on any number of criteria, including but not limited to analysis of the "address information" - e.g. the digits or Request-URI emitted by the caller's UA. This could occur at any number of places - e.g. in the caller's UA, in a proxy in the home provider, or in some downstream element. 2. Identification of the requested service. There are many possible OIS services, and the number of these is only expected to increase as providers respond to customer needs. At some point during call processing it is necessary to identify exactly which service is desired. For example "directory assistance with call completion" is a service where after the listing information is provided to the caller, the option is provided for the call to be placed automatically, so the customer need not hang up, remember the digits, and dial the number. Another example is "directory assistance only", where call completion is not offered. There are multiple factors which could affect the service which is to be offered, and the logic deciding this could be located anywhere along the path to the OIS provider. Some of the information required to make such decisions could include: o The digits dialed by the caller. o The Request-URI emitted by the caller's UA. o The identity of the calling party, for instance the calling party number. o The charge number associated with the caller's account. o The identity of the calling party's home provider. o The identity of the provider which directly hands off the call to the OISP. o The identity of other provider which the request might traverse o The Originating Station Type, in case the call was originated in the PSTN. o Trunk group information, in case the call was originated in the PSTN. Haluska, et al. Expires August 15, 2007 [Page 12] Internet-Draft Information Services Using SIP February 2007 o Capabilities and characteristics of the caller's user equipment. 3. Routing of the OIS call. The call must be routed towards an entity which can provide the requested service. Each entity or network handling the call routes it based on the logic located in that provider, and the information currently available. For instance, the home provider may know very little about OIS services, having farmed that service out to another provider. Consequently it might simply route all such calls towards the OIS provider, which decides which service is to be offered. 4. Authentication. When one provider passes a call to another provider, there is a need for the providers involved to be sure of each other's identity. This might be through explicit security mechanisms such as mutual TLS or security gateways using IPSec tunnel mode, it might be through reliance on a closed set of trusted interconnected providers, or some other policy set by the providers involved. 5. Receipt of the OIS call. The OIS provider needs to be able to receive such calls. 6. Querying upstream providers for information. The OISP, or an intermediate provider may require information from an upstream provider. For instance, the capabilities and characteristics of the caller's equipment may be needed in order to influence call processing. 7. Connection of caller to automated voice platform. The OISP must be able to connect the caller to an appropriate automated voice platform. 8. Provision of branded announcements. The OISP must be capable of providing custom announcements to the caller based on a number of criteria. For example, it might greet the caller, thanking them for using their Home Provider's service. Though the service is actually provided by the OISP, business arrangements would dictate such branded announcements. 9. 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." Haluska, et al. Expires August 15, 2007 [Page 13] Internet-Draft Information Services Using SIP February 2007 10. Recording a spoken request. The OISP must be capable of recording the caller's spoken request. This both for speech recognition, and also for playing back the "whisper" to a human operator should one be required, to prevent having to ask the customer to repeat the request. 11. Speech recognition. The OISP must be able to pass the caller's spoken request to speech recognition system, suitable for querying a listing database. 12. Listing database query. The OISP must be capable of querying one or more listings databases using the request. 13. 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. 14. Selection of appropriate operator. When it has been determined that the call must be routed to a human operator, there are a number of factors to be taken into account to determine the appropriate operator for the call. It must be possible to determine the appropriate human operator to which the call should be routed. 15. Routing of call to operator workstation. Once the appropriate operator has been identified, the call must be routed to that operator's workstation. 16. 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. 17. 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. 18. 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. 19. 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. 20. Call completion. If the caller requests call completion, the call should be automatically initiated for the caller. Haluska, et al. Expires August 15, 2007 [Page 14] Internet-Draft Information Services Using SIP February 2007 5. OISP Internal Architecture This section describes an initial view of the elements internal to the OISP architecture. The following types of elements may be present within the OISP infrastructure: Automatic Call Distributor (ACD) server - The ACD provides queuing and call distribution functions for human operators. Specifically, it is the component that tracks the availability of the human operators and selects an available operator utilizing complex algorithms based on operator skills, type of call, type of request, calling party information, etc. The ACD server is modeled as an Application Server. Customer Profile Database - The Customer Profile Database is a per subscriber database maintained by an OISP about its customers. Some of this information might be statically provisioned, other information such as customer preferences or session information might be populated dynamically as a result of customer interactions. Messaging Gateways - Messaging Gateways provide access and data via E-mail, SMS, MMS, WAP. Operator and Information Services Application Server (OIS-AS) - The OIS-AS contains AS functions specifically for directory assistance and information services as well as other Operator Services. This may coordinate multiple call legs, connecting the caller in sequence to one or more OIS-MS and/or operator workstations according to the logic contained within. The OIS-AS may need to communicate with elements of other providers, for instance to query information about the capabilities and characteristics of the caller's equipment, or to access another provider's operator resources. Operator and Information Services Media Server (OIS-MS) - The OIS- MS provides the media resources for playing announcements, performing voice recognition, performing listing database queries, generating whisper from the user's verbal request, etc. Operator Workstations - Operator Workstations provide an interface to the human operator. It may receive the customer's recorded request (e.g. name and city of requested listing), information from Haluska, et al. Expires August 15, 2007 [Page 15] Internet-Draft Information Services Using SIP February 2007 listing or other databases, and also terminate a multimedia session with the customer. These are modeled as SIP UAs. Service Databases - Service Databases store service specific information (e.g. listing information such as name, address, and phone number, etc.) These may be located in the OISP's network and/or in other networks, and more than one may be used. SIP Proxy - One or more SIP proxies may be present in the OISP network, to facilitate SIP communications with other providers as well as to perform call processing functions between OISP components. The following figure shows a simplified view of an OISP internal architecture. The lines show logical connectivity; elements communicate via the proxy. A single OIS-AS is shown, along with up to "k" OIS-MS and up to "m" Operator Work Stations, and an ACD server. +--------+ +---------+ +--| OIS-AS |-+-| OIS-MS1 | | +--+-----+ | +---------+ +-------+ | | | | Proxy |-| | | +---------+ +-------+ | | +-| OIS-MSk | | +--+--+ +---------+ +--| ACD |---------+---------+ +-----+ | | +--+---+ +--+---+ | OWS1 | | OWSm | +------+ +------+ Figure 4 Simplified view of OISP Internal Architecture 6. General Approach This section describes one possible way to implement DA using SIP. Other ways may be possible. Haluska, et al. Expires August 15, 2007 [Page 16] Internet-Draft Information Services Using SIP February 2007 The general approach involves having the OIS-AS host most of the processing logic, and to control the call in general. The OIS-AS implements a third party call control (3PCC) functionality. It terminates the signaling dialog from the caller, and originates dialogs towards other components as necessary. There may be multiple sequential sessions set up during the course of a DA call. For example, the OIS-AS would initiate a new dialog towards a MS for front-end automation. When it gets the 200 OK from the MS with SDP, it passes that SDP back toward the caller. When the front end automation has completed, the OIS-MS sends a BYE containing message bodies conveying the success of the operation (i.e., was it able to obtain the listing) as well as any data related to the operation. In case of success, the body might carry the listing information, or a URI pointing to it. In case of failure, it might carry a URI pointing to the whisper file. In case of failure, the OIS-AS would determine that the call needs to be routed to a human operator. The OIS-AS first needs to identify a suitable operator to handle this request. The ACD server has this responsibility, and could be implemented as a redirect server facing the OIS-AS, redirecting towards the best suited available operator. Facing the operator workstations, the ACD server could be implemented as a presence server, maintaining availability of each operator, as well as the associated information for each (e.g. languages, skill level, cost, etc). The OIS-AS would then send an INVITE toward the identified operator workstation. This INVITE includes the caller's SDP as well as a URI pointing to the whisper file. The workstation could play the whisper to the operator as the call is answered. The operator workstation's SDP would be passed back to the caller via a re- INVITE or UPDATE request. If the operator is successful in locating the desired listing, the workstation would send a BYE containing message bodies with an indication of success, and either the listing information of a pointer to the same. The OIS-AS would then initiate a call leg towards an OIS-MS for back end automation. The INVITE would include the same body with the listing information that was sent by the operator workstation. The OIS-MS returns its SDP, which the OIS-AS would propagate back over the originating leg via a re-INVITE or UPDATE request. The back end automation process includes audibly playing out the listing information, and possibly offering call completion service. Haluska, et al. Expires August 15, 2007 [Page 17] Internet-Draft Information Services Using SIP February 2007 The OIS-MS sends a BYE with a message body indicating whether call completion is desired. If call completion is desired, the OIS-AS sends a REFER back over the originating call leg to the caller, and clears the call. These examples describe simple voice scenarios. Other media types may be possible. For example, it may be desirable to send the listing information via text message to the caller's terminal, or to show a video clip. Such features require knowledge of the calling terminal's capabilities and characteristics. The mechanism described in RFC 3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)can be used for this. The capabilities might have been signaled in the initial INVITE request. Otherwise, the OIS-AS can query for capabilities using an OPTIONS request. Additionally, some non SIP mechanism might be used, such as querying a database (e.g. IMS HSS) in the caller's network. References to a whisper file can be passed using the mechanism described in RFC 4483 A Mechanism For Content Indirection in the Session Initiation Protocol (SIP). Other information signaled via message bodies includes the success or failure status of operations (such as identifying the requested listing), or other data (such as the listing information). Context information may be maintained on a per call basis. It could include such information as the caller's preferred language, etc. A URI pointing to the context information could be passed between elements in the OISP infrastructure. 7. Signaling Mechanisms This section discusses the signaling mechanisms required to provide OIS services. 7.1. Calling Party's Identity In many cases, downstream providers may need to know the calling party's identity. This might be needed to influence call processing, or for accounting purposes. Also, the calling party's identity in the Haluska, et al. Expires August 15, 2007 [Page 18] Internet-Draft Information Services Using SIP February 2007 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 between trusted providers. Note that some networks may allow their users to hide their identity. In the current North American PSTN, for such cases the caller id information is often transported through the network, marked with a privacy indication such that it will not be presented to the called party. Bilateral agreements between VOIP providers determine whether providers are within the same "trust domain" as defined in [RFC3324], and what information, including network-asserted identities, may be exchanged between providers. Depending on such agreements, it is possible that the caller identity information is obscured or completely absent. As indicated in [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." 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. The following shows an example of an INVITE message contain a P- Asserted-Identity header. Haluska, et al. Expires August 15, 2007 [Page 19] Internet-Draft Information Services Using SIP February 2007 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" Content-Type: application/sdp Content-Length: ... [SDP not shown] 7.2. Provider Identification As discussed, in some deployment scenarios, the OISP makes use of the identities of other providers involved in the call. This section discusses how those identities can be conveyed using SIP. 7.2.1. Home Provider In many cases, the OISP needs to identify the caller's Home Provider. This may be needed for branding purposes as well as to potentially influence treatment in other ways. The basic mechanism for determining the home 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 Haluska, et al. Expires August 15, 2007 [Page 20] Internet-Draft Information Services Using SIP February 2007 use of such standardized mechanisms for reaching its users. It also becomes 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 with a hostname. Very simply, the RHS of the hostname in the SIP URI is extracted and used as the basis to influence call processing. In cases where the caller's identity is not available, as discussed in the "Calling Party's Identity" section, then the home network's identity is consequently also not available, and call processing logic based on such information (such as branding) cannot take place. 7.2.2. Last Hop Provider In many cases, the OISP needs to identify the last hop provider; that is, the provider which sent the call to the OISP. This may be 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. 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. Haluska, et al. Expires August 15, 2007 [Page 21] Internet-Draft Information Services Using SIP February 2007 In the absence of mutual TLS, the "host" field of the "sent-by" field of the topmost mandatory Via header can 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. 7.2.3. Arbitrary Traversed Provider In some cases, the OISP may need to know the identity of some provider involved in the call which is neither the Home Provider nor the last- hop provider. This may be needed to influence treatment. The use of the SIP History-Info mechanism defined in RFC 4244, An Extension to SIP for Request History Information, can be used for this. As the call moves from one provider to the next and is retargeted, corresponding entries are added to the SIP History-Info header. If the domain name format is used for the retargeted entities, then the History-Info header now includes a list of traversed SIP domains or providers, which can be consulted by the OISP. According to RFC 4244, entries should be added to the History-Info header whenever the Request-URI is modified. Cases may exist where the call is sent to another provider but the URI is not modified. In such cases, the provider is not captured by the History-Info header. The following figure illustrates the use of the History-Info header for this purpose. Haluska, et al. Expires August 15, 2007 [Page 22] Internet-Draft Information Services Using SIP February 2007 Caller Provider-A Provider-B Provider-C | | | | | | | | | | | | |(1) INVITE tel:+411 | | |------------->| | | | | | | | | | | | |(2) INVITE sip:da@prov-b.net | | |------------->| | | | | | | | | | | | |(3) INVITE sip:da@prov-c.net | | |------------->| | | | | | | | | Figure 5 Use of History-Info header to identity traversed providers 1. The user dials "411", and the resulting INVITE to its home proxy is for "tel: +411". No History-Info header is included yet. INVITE tel:+411 SIP/2.0 (other message content omitted) 2. The home proxy retargets this to "sip:da@prov-b.net", and adds a History-Info header which includes the targeted-from URI: INVITE sip:DA@prov-b.net SIP/2.0 History-Info: ; index=1 (other message content omitted) 3. Proxy-B retargets this to "SIP: da@prov-c.net", and appends another entry to the History-Info header: INVITE sip:DA@prov-b.net SIP/2.0 History-Info: ; index=1, ; index=2 (other message content omitted) Haluska, et al. Expires August 15, 2007 [Page 23] Internet-Draft Information Services Using SIP February 2007 When this request arrives a Proxy-C in Provider C (OISP), it conveys the following: oThe Request-URI (SIP: da@prov-c.net) indicates this as a DA call oThe History-Info header conveys the history of the request: oIt started as a tel URI for digits "411" oIt was then targeted to provider B oIt is now targeted to provider C 7.3. Originating Station Type In the current PSTN in North America, OIS providers have the ability to tailor treatment based on the type of originating station. For instance, calls from prison phones are restricted from accessing DA services. Example values include POTS, coin, hospital, prison/inmate, cellular, etc. In the PSTN in North America, this information is signaled for SS7 calls using the Originating Line Information (OLI) information element, and in MF calls using the ANI II digits. To support interworking with the PSTN, it must be possible to convey the Originating Station Type value. 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. oThe 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 Haluska, et al. Expires August 15, 2007 [Page 24] Internet-Draft Information Services Using SIP February 2007 oConveying 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. 7.4. Trunk Group Identifier The incoming trunk group number provides information which could be used to influence call processing, thus this information is needed. Trunks are point to point circuits and as such, their remote termination point is unambiguously known. As such, knowledge of the incoming trunk group conveys the identity of the provider offering the call. For PSTN interworking, the incoming trunk group identifier is a key piece of information and must be known. Thus, at a PSTN to IP 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-10.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. The following example shows an INVITE containing a trunk group identification in the Contact header: Haluska, et al. Expires August 15, 2007 [Page 25] Internet-Draft Information Services Using SIP February 2007 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: < sip:7327581234@provider-b.com;tgrp=101; trunk- context=provider-b.com@proxy-b.provider-b.com;user=phone> P-Asserted-Identity: "7327581234" Content-Type: application/sdp Content-Length: ... 7.5. Dialed Digits Currently in the North American PSTN, the OIS provider may take into account the digits dialed by the user. In that scenario the dialed digits are frequently forwarded to the OIS provider. Using SIP, the dialed digits would typically be sent by the user's equipment in the form of a tel URI or SIP URI in the Request-URI of a SIP INVITE. It is possible that retargeting could take place, in which case the dialed digits would be lost. The SIP History-Info mechanism defined in RFC 4244 provides a mechanism for solving exactly this type of problem. It defines a new optional SIP header, History-Info, to provide a standard mechanism for capturing the request history information. Whenever a node which supports this mechanism modifies the Request-URI of a request, it captures this in the History-Info header. The following example shows an INVITE containing a History-Info header, which conveys the original dialed digits, after having been retargeted. INVITE sip:DA@prov-b.net SIP/2.0 (other message content omitted) History-Info: ; index=1, ; index=2 Please see the section titled "Arbitrary Involved Provider" for an example of a flow where the History-Info mechanism delivers the dialed digits to the OISP when retargeting has occurred. Haluska, et al. Expires August 15, 2007 [Page 26] Internet-Draft Information Services Using SIP February 2007 7.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]. [CSI], a work in progress, discusses explicit service identifiers for using in IMS based networks. 7.7. Charge Number There is a need to convey a charge number, which may differ from the calling party's identity. The charge number usually identifies the customer or account with which the caller is associated, e.g. the main number for a business which has many individual calling numbers. This might be needed for accounting, but it also could influence call processing, especially when a particular type of service applies for any caller associated with a particular charge number. The ability to convey charge number information is currently lacking in SIP. It has been suggested in Analysis of TISPAN requirements for Connected Identity in the Session Initiation Protocol (SIP) - draft-elwell-sip-tispan-connected-identity-01.txt that the P-Asserted-Identity header can be used to convey this information, with the caller's identity in the From header. However, using the P-Asserted-Identity header and From header to convey separate information is seen as controversial and has not been accepted by the IETF. Haluska, et al. Expires August 15, 2007 [Page 27] Internet-Draft Information Services Using SIP February 2007 7.8. Passing Whisper During front end automation, the OIS-MS will record and may time compress the caller's perhaps meandering speech into what is known as the "whisper". This is intended to be played into a human operator's ear, should the call be referred to an operator, to avoid the operator from having to prompt the caller again. The whisper is obtained during the front end automation, and saved to an audio file. If the call needs to be transferred to a human operator, the whisper will need to be played to the operator at the same time or slightly prior to connecting the caller to the operator. Thus, the operator workstation needs to be able to access the whisper file. When the OIS-MS performs front end automation, it generates the whisper and saves it as an audio file. The location, storage type, and format are out of the scope of this document. What is needed is a way for the OIS-MS to convey the whisper information to the OIS- AS, so it could potentially be used for later processing, such as passing to a human operator. Due to size constraints, it may not be feasible or desirable to pass the actual audio file containing the whisper. This document will discuss the most general case of passing a pointer, in the form of a URI, to the audio content. Since the whisper is an output of the front end automation process, it makes sense to return this upon completion of that process. The most reasonable time to do this is when the OIS-MS sends the BYE. Any SIP request, including BYE, can contain a message body. RFC 4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for SIP. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. This is illustrated in the following figure. Note that the proxy has been omitted for clarity, as have some messages not crucial to illustrating the use of this mechanism. All SIP signaling traverses the proxy. Haluska, et al. Expires August 15, 2007 [Page 28] Internet-Draft Information Services Using SIP February 2007 AS MS Operator | | | | | | | | | |(1) INVITE | | |------------->| | | | | | | | |(2) 200 OK | | |<-------------| | | | | | | | |MS prompts user, collects whisper | | | | | | | | | |(3) BYE, body w. status, whisper URI |<-------------| | | | | | | | |(4) 200 OK | | |------------->| | | | | | | | |(5) INVITE w. whisper URI | |---------------------------->| | | | | | | |(6) 200 OK SDP| | |<----------------------------| | | | | | | | | | | | | Figure 6 Call flow illustrating passing of whisper 1. INVITE AS->MS INVITE sip:da@ms-1.oisp-c.net SIP/2.0 [remainder of message omitted] Haluska, et al. Expires August 15, 2007 [Page 29] Internet-Draft Information Services Using SIP February 2007 2. 200 OK MS->AS SIP/2.0 200 OK [remainder of message omitted] 3. BYE MS->AS BYE sip:as-1@as-1.oisp-c.net SIP/2.0 [non relevant portions of message omitted] Content-Type: message/external-body; access-type="URL"; URL="http://ms1.oisp-c.net/whisper/20070206092700-0001.wav" expiration="Tues, 06 Feb 2007 09:30:00 GMT"; Content-Type: audio/x-wav Content-Disposition: render 4. 200 OK AS->MS SIP/2.0 200 OK [remainder of message omitted] 5. INVITE AS->Operator Workstation INVITE sip:operator@operator-123.oisp-c.net SIP/2.0 [non relevant portions of message omitted] Content-Type: message/external-body; access-type="URL"; URL="http://ms1.oisp-c.net/whisper/20070206092700-0001.wav" expiration="Tues, 06 Feb 2007 09:30:00 GMT"; Content-Type: audio/x-wav Content-Disposition: render 6. 200 OK Operator->AS SIP/2.0 200 OK [remainder of message omitted] Note that this same mechanism also supports the case where front end automation is performed by one provider, and another provider provides the operator assistance. In this type of scenario, provisions need to made such that the second provider can access the resources referenced by the URI. Haluska, et al. Expires August 15, 2007 [Page 30] Internet-Draft Information Services Using SIP February 2007 7.9. Calling Equipment Capabilities and Characteristics It may be necessary for the OIS provider to learn the capabilities and characteristics of the caller's equipment. This would be useful when the OIS provider wishes to provide content to the caller other than that which was used on the call to the OISP. For example, the OIS provider might wish to send listing information via text message, or play a video clip about a particular venue about which he has requested information. RFC 3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP), defines mechanisms by which a UA can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. This information might be included in the incoming INVITE to the OISP, if the caller's UA supports this mechanism and is configured to do so. Otherwise, the OISP could query the caller's UA by sending a SIP OPTIONS request, and the UA, if it supports this mechanism, would include its capability feature tags in the response to the OISP. The following is an example of an INVITE containing capability feature tags, as it arrives at the OISP. In this case, the UA supports audio, video, and text. Other included tags provide additional information. INVITE sip:da@provider-c.com SIP/2.0 Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9 Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9 Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9 From: ;tag=1234567 To: 411 Contact: ;audio;video;text ;actor="principle";automata;mobility="fixed" ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" P-Asserted-Identity: "7327581234" P-Asserted-Identity: tel:+7327581234 Content-Type: application/sdp Content-Length: ... [SDP not shown] Haluska, et al. Expires August 15, 2007 [Page 31] Internet-Draft Information Services Using SIP February 2007 If the OISP wishes to query the UA, it can send an OPTIONS request to the UA, and the UA, if it supports this mechanism, would include the feature capability tags in the Contact header, as show above, in the 200 OK response. 7.10. Media Server Returning Data to the Application Server The OIS-AS needs to know the outcome of the operations performed by the OIS-MS, e.g. success/failure of front end automation, etc. Some mechanism is needed to convey this information. This could be conveyed using non SIP mechanisms. Any SIP message, including BYE, can carry message bodies. The simplest way for a OIS-MS to return data to an OIS-AS is to encapsulate the data in a MIME body. This requires agreement between both sides on the format and semantics of these bodies. Another approach is to use the content indirection mechanism to point to the data, however this may be rather cumbersome if only a small amount of data is to be returned. Some OIS service may make use of VoiceXML, whereby the OIS-AS invokes VoiceXML scripts on the OIS-MS, and the OIS-MS returns data to the OIS-AS. SIP Interface to VoiceXML Media Services - draft- burke-vxml-02.txt (work in progress) describes a SIP interface to VoiceXML media services, which is commonly employed between application servers and media servers offering VoiceXML processing capabilities. This may be found useful for OIS services. This information can also be conveyed using non SIP mechanisms. Describing such mechanisms is out of the scope of this document. 7.11. Service Discovery An OISP might desire that its service be discoverable on the internet, instead of or in addition to static provisioning into provider networks. The Service URN concept discussed in the work in 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 Haluska, et al. Expires August 15, 2007 [Page 32] Internet-Draft Information Services Using SIP February 2007 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. 8. Call Flow The following call flow provides examples of how a DA service could be implemented using the mechanisms described in this document. It is intended to illustrate the intended use of the proposed signaling mechanism. Some messages not crucial to this may be omitted for clarity. Haluska, et al. Expires August 15, 2007 [Page 33] Internet-Draft Information Services Using SIP February 2007 Caller Proxy A Proxy B Proxy C OIS-AS OIS-MS1 | | | | | | | | | | | | | | | | | | |(1) INVITE tel:411 | | | | |-------->| | | | | | | | | | | | |(2) INVITE sip:da@prov-b.com | | | |-------->| | | | | | | | | | | | |(3) INVITE sip:da@prov-c.com | | | |-------->| | | | | | | | | | | | |(4) INVITE sip:da-cc@prov-c.com | | | |-------->| | | | | | | | | | | | |(5) INVITE prompt & collect | | | | |-------->| | | | | | | | | | | |(6) 200 OK w.SDP | | | | |<--------| | | | | | | | | | |(7) 200 OK w.SDP | | | | |<--------| | | | | | | | | | |(8) 200 OK w.sdp | | | | |<--------| | | | | | | | | | |(9) 200 OK w.sdp | | | | |<--------| | | | | | | | | | |(10) 200 OK w.sdp | | | | |<--------| | | | | | | | | | | | | | | | | | | | | | | Figure 7 Call flow, part 1 For brevity, only relevant SIP headers will be shown. The following test refers to Figure 7. Haluska, et al. Expires August 15, 2007 [Page 34] Internet-Draft Information Services Using SIP February 2007 The user, homed in provider A, initiates a request for an OIS service, for instance by dialing "411". The user's UA sends a SIP INVITE. It might contain a "tel" URI. 1. INVITE UE -> Home Proxy INVITE tel:+411 SIP/2.0 Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9 From: ;tag=1234567 To: 411 Contact: Content-Type: application/sdp Content-Length: ... The home network knows nothing of OISP services, for instance it might be a rather small scale provider. It is essentially set up to forward all calls of this type to Provider B. It translates the Request-URI to a SIP URI and sends the call on to provider B. Because of this retargeting, it adds a History-Info header to capture the dialed digits. The caller's identity is verified in a manner consistent with this provider's policies, and the proxy adds two P-Asserted-Identity headers: one with a SIP URI, and another with a "tel" URI. Haluska, et al. Expires August 15, 2007 [Page 35] Internet-Draft Information Services Using SIP February 2007 2. INVITE proxy-a -> proxy-b INVITE sip:411@provider-b.com SIP/2.0 Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9 Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9 From: ;tag=1234567 To: 411 Contact: P-Asserted-Identity: "732758123" P-Asserted-Identity: tel:+7327581234 History-Info: ; index=1 Content-Type: application/sdp Content-Length: ... Proxy-b in provider-b's network receives the request. This is a larger network, and it has business relationships with several OIS providers, as well as with several providers which serve subscribers. This provider has logic which requires it to query the Home Provider's network to find some information related to the caller. This is not likely to be a SIP related function, and is thus out of scope for this document. The logic executes, taking the result of this query into account. It is determined that the call is for directory assistance, and that the call should be routed to provider C for handling. So, proxy-b retargets the Request-URI to reflect this, and routes the call to provider C (the OISP). It adds another entry to the History-Info header to capture this retargeting. Haluska, et al. Expires August 15, 2007 [Page 36] Internet-Draft Information Services Using SIP February 2007 3. INVITE proxy-b -> proxy-c INVITE sip:da@provider-c.com SIP/2.0 Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9 Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9 Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9 From: ;tag=1234567 To: 411 Contact: P-Asserted-Identity: "732758123" P-Asserted-Identity: tel:+7327581234 History-Info: ; index=1, ; index=2 Content-Type: application/sdp Content-Length: ... Proxy-c in provider C's network receives the request. The source of the request is authenticated via mechanisms not described here. It needs to know how to bill this call, and thus needs to know which provider it came from. It looks at the topmost Via header, and sees that the call came from provider B. It examines the History-Info header, and is able to identity the dialed digits. It can also determine from the SIP URI which domains have been traversed, as long as each has retargeted and appended an entry in the header. The proxy determines that the call needs to go the OIS-AS for handling, so it retargets if necessary and forwards the INVITE. The OIS-AS performs 3PCC. It determines that the call needs a branded announcement based on the identity of the home network, which it derives from the P-Asserted-Identity header. It initiates a new call leg toward OIS-MS1 for front end automation. Per RFC 4240, the "dialog" portion of the Request-URI indicates the "prompt & collect" service. The URI identifies the VoiceXML script to be executed. The SDP is the caller's SDP. Haluska, et al. Expires August 15, 2007 [Page 37] Internet-Draft Information Services Using SIP February 2007 5. INVITE OIS-AS -> MS1 INVITE sip:dialog@ois-as.prov-c.com; \ voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml \ SIP/2.0 Via: SIP/2.0/UDP ois-as.prov-c.com:5060 ;branch=z9hG4bK74bf9 From: ;tag=1234567 To: sip:dialog@ois-as.prov-c.com; \ voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml Contact: Content-Type: application/sdp Content-Length: ... The OIS-MS responds with a 200 OK, with its own SDP. The OIS-AS now sends a 200 OK response back toward the caller, with the MS's SDP. Note that the OIS-AS could first have sent non final response back toward the user. Haluska, et al. Expires August 15, 2007 [Page 38] Internet-Draft Information Services Using SIP February 2007 Caller OIS-AS OIS-MS1 ACD Operator | | | | | | | | | | | | | | | |(11) RTP session | | | |...................| | | | | | | | | |(12)BYE w.URI, body| | | |<--------| | | | | | | | | |(13)INVITE | | | |------------------>| | | | | | | | |(14)3xx | | | | |<------------------| | | | | | | | |(15)INVITE w.URI | | | |---------------------------->| | | | | | | |(16)200 OK | | | |<----------------------------| | | | | | |(17) re INVITE | | | |<--------| | | | | | | | | |(18) 200 OK | | | |-------->| | | | | | | | | |(19) RTP session | | | |.......................................| | | | | | | |(20) BYE | | | | |<----------------------------| | | | | | | | | | | | | | | | Figure 8 Call flow, part 2 The following text refers to Figure 8. The user is now connected (11) to the MS, which plays a branded announcement, and prompts for the listing information. When the user speaks his request, the MS processes the audio to obtain a Haluska, et al. Expires August 15, 2007 [Page 39] Internet-Draft Information Services Using SIP February 2007 "whisper" file, or condensed version of the request. In this example, the MS is unable to successfully perform the query, so it terminates the call be sending a BYE (12) to the OIS-AS. This BYE also contains a URI which points to the whisper file, and also contains a message body (not shown) containing the output of the VoiceXML script. The OIS-AS decides based on the failure indication that it needs to route the call to a human operator. It sends an INVITE (13) to the ACD server. One possible way an ACD could be implemented is as a presence server, such that it keeps track of the availability of all the operators. In this example, the ACD server is implemented as a redirect server - it sends a 3XX response (14) which identifies the operator the OIS-AS should contact. Alternately, the ACD server could have proxied the request to the operator. The OIS-AS now sends an INVITE (15) containing the URI to the whisper, as well as the caller's SDP, to the indicated operator workstation. The operator workstation sends a 200 OK (16) with the operator's SDP, which the OIS-AS sends toward the caller in a re- INVITE (17). The caller is now connected to the operator (19), and the operator helps the caller with the listing. The operator workstation launches a query, and a response is received. The operator signals a BYE (20) toward the OIS-AS, which may contain the listing information in a message body, a pointer (URI) to the listing information, or it may pass this information to the OIS-AS using some other, non SIP mechanism. Haluska, et al. Expires August 15, 2007 [Page 40] Internet-Draft Information Services Using SIP February 2007 Caller OIS-AS OIS-MS2 | | | | | | | | | | |(21) INVITE | |-------->| | | | | |(22) 200 OK | |<--------| | | | |(23) re INVITE | |<--------| | | | | |(24) 200 OK | |-------->| | | | | |(25) RTP session | |...................| | | | | |(26) BYE w.body | |<--------| | | | |(27) REFER | |<--------| | | | | | | | | | | Figure 9 Call flow, part 3 Haluska, et al. Expires August 15, 2007 [Page 41] Internet-Draft Information Services Using SIP February 2007 The following text refers to Figure 9. The OIS-AS sends an INVITE (21) to another OIS-MS, MS2, for back end automation. When it receives MS2's SDP in the 200 OK (22), it sends a re INVITE (23) toward the user to update the SDP. At this point an audio session is in place between the caller and the back end automation MS (25). The MS plays the listing information, and offers call completion service. The caller accepts, so OIS-MS2 sends a BYE (26) with a message body containing the result of the call completion offer. Since call completion was requested, the OIS-AS sends a REFER (27) to the caller, to cause it to place a call to the listed party. The OIS-AS may or may not care about subsequent NOTIFY from the caller, and drops out of the call. 9. VoIP Information Services - Summary and Next Steps A list of information which needs to be conveyed has been developed, and candidate proposals identified for each of these. The desired next steps include soliciting feedback from the IETF community on the choices and intended usages of the proposed mechanisms. Future revisions of this document will need to include security considerations as well as IANA considerations. Example messages and message flows will be more complete. The References section will also need to be complete. 10. Security Considerations This revision of this document does not yet address security considerations. A subsequent revision will do so, and will likely include the following among items it considers: Usage of headers such as P-Asserted-Identity which are intended to use between trusted providers. Potentially revealing information about subscribers or service provider infrastructure via signaling messages. Haluska, et al. Expires August 15, 2007 [Page 42] Internet-Draft Information Services Using SIP February 2007 Security of signaling and bearer. Implications of inter provider signaling. 11. IANA Considerations This revision of this document does not yet address IANA considerations. It is not anticipated that this document will define any new protocol extensions or other values requiring action of IANA. Haluska, et al. Expires August 15, 2007 [Page 43] Internet-Draft Information Services Using SIP February 2007 12. References 12.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) 12.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) Haluska, et al. Expires August 15, 2007 [Page 44] Internet-Draft Information Services Using SIP February 2007 [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 August 15, 2007 [Page 45] Internet-Draft Information Services Using SIP February 2007 Author's Addresses John Haluska Telcordia Technologies, Inc. 331 Newman Springs Road Room 2Z-323 Red Bank, NJ 07701-5699 USA Phone: +1 732 758 5735 Email: jhaluska@telcordia.com Renee Berkowitz Telcordia Technologies, Inc. One Telcordia Drive Piscataway, NJ 08854-4157 USA Phone: +1 732 699 4784 Email: rberkowi@telcordia.com Paul Roder Telcordia Technologies, Inc. One Telcordia Drive Room RRC-4A619 Piscataway, NJ 08854-4157 USA Phone: +1 732 699 6191 Email: proder2@telcordia.com Wesley Downum Telcordia Technologies, Inc. One Telcordia Drive Piscataway, NJ 08854-4157 USA Phone: +1 732 699 6201 Email: wdownum@telcordia.com Richard Ahern AT&T Customer Information Services 1876 Data Drive Room 314 Haluska, et al. Expires August 15, 2007 [Page 46] Internet-Draft Information Services Using SIP February 2007 Hoover, AL 35244 USA Email: Richard.Ahern@bellsouth.com Paul Lum Lung Qwest Communications International 1801 California Street Suite 1210 Denver, CO 80202 USA Email: paul.lumlung@qwest.com Nicholas S. Costantino Soleo Communications, Inc. 300 Willowbrook Drive Fairport, NY 14450 Email: ncostantino@soleocommunications.com Chris Blackwell Verizon 1000 Century Tel Dr Room 115 Wentzville, MO 63385 Email: chris.blackwell@verizon.com Jim Mellinger Verizon 7979 N Beltline Rd Irving, TX 75063 Email: james.j.mellinger@verizon.com D. E. Scott VoltDelta 2401 N. Glassell St. Orange, CA 92865-2705 Email: dscott@voltdelta.com Intellectual Property Statement Haluska, et al. Expires August 15, 2007 [Page 47] Internet-Draft Information Services Using SIP February 2007 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Haluska, et al. Expires August 15, 2007 [Page 48]