INTERNET-DRAFT Vijay K. Gurbani (Editor) February 2002 Alec Brusilovsky Expires: August 2002 Igor Faynberg Hui-Lan Lu Musa Unmehopa Kumar Vemuri Lucent Technologies, Inc. Jorge Gato Vodafone Document: draft-gurbani-spirits-protocol-01.txt Category: Standards The SPIRITS Protocol STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes SPIRITS protocol. The purpose of the SPIRITS protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built. On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities. The earlier draft-gurbani-spirits-protocol-00.txt [Page 1] The SPIRITS Protocol February 2002 IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated in the reverse direction - from the Internet to PSTN. This Internet-Draft has been written in response to the SPIRITS WG chairs call for SPIRITS Protocol proposals. Among other contributions, this I-D is based on: o Informational RFC2995, "Pre-SPIRITS implementations" o Informational RFC3136, "The SPIRITS Architecture" o SPIRITS Protocol Requirements, presented in draft-ietf- spirits-reqs-04, current candidate for Informational RFC. draft-gurbani-spirits-protocol-00.txt [Page 2] The SPIRITS Protocol February 2002 Table of Contents 1.0 Introduction .........................................3 1.1 Conventions used in this document ....................3 2.0 INAP Parameters of interest to SPIRITS clients in the PSTN ..................................3 2.1 Brief description of working .........................3 2.2 Identifying IN DPs from CS-3 .........................6 2.3 IN-specific details ..................................7 2.4 Encoding INAP parameters in SPIRITS using XML ........7 2.5 Approaches for Encoding DP Information ...............7 2.6 Template Description and Procedure ...................8 2.7 SPIRITS Data and Encoding ............................9 3.0 Using the SIP Events Package for SPIRITS hosts on IP Network ........................................10 3.1 Normative usage.......................................10 3.1.1 Event package name....................................11 3.1.2 Event package parameters..............................11 3.1.3 SUBSCRIBE bodies......................................11 3.1.4 Subscription duration.................................11 3.1.5 NOTIFY bodies.........................................12 3.1.6 Notifier processing of SUBSCRIBE requests.............12 3.1.7 Notifier generation of NOTIFY requests................12 3.1.8 Subscriber processing of NOTIFY requests..............12 3.1.9 Handling of forked requests...........................12 3.1.10 Rate of notification.s................................12 3.1.11 State agents..........................................12 3.1.12 Examples..............................................12 3.1.13 URI List handling.....................................12 4.0 Example SPIRITS service call flow.....................13 5.0 IANA Considerations ..................................20 6.0 Security Considerations ..............................20 7.0 Conclusion ...........................................21 8.0 Acknowledgements .....................................21 Changes...............................................21 Appendices: A INAP Parameters and Data Types .......................21 A.1 Information Elements..................................21 A.2 Commonly Used Parameters..............................23 A.3 Error Codes ..........................................24 A.4 Detection Points, Triggers, Related Information ......25 A.4.1 Originating Detection Points .........................25 A.4.2 Terminating Detection Points .........................30 A.5 SCF to SSF IFs .......................................33 B XML DTD for IFs, Examples of use .....................36 B.1 Conventions ..........................................36 B.2 General DTD Syntax ...................................36 draft-gurbani-spirits-protocol-00.txt [Page 3] The SPIRITS Protocol February 2002 B.3 XML DTDs for INAP Information Elements ...............36 B.4 XML DTDs for INAP Originating Detection Points .......52 B.5 XML DTD's for INAP Terminating Detection Points ......58 B.6 XML encoding for IFs from the SCF to the SSF .........62 B.7 Examples .............................................68 1.0 Introduction SPIRITS (Services in the PSTN Requesting InTernet Services) is an IETF architecture and associated protocol that enables call processing elements in the telephone network such as the PSTN/GSTN to make service requests that are then processed on Internet hosted servers. The PSTN today supports service models such as the IN (Intelligent Network), whereby some features are executed locally on switching elements (called SSPs or Service Switching Points) themselves, and other features are executed on service elements called SCPs (or Service Control Points). The SPIRITS architecture [1] permits these SCP elements to act as intelligent proxies to leverage and use Internet nodes and capabilities to further enhance the telephone end-user's experience. This draft is organized as follows: Section 2.0 describes INAP parameters of interest to SPIRITS clients in the PSTN. In Section 3.0 we discuss SIP event package for SPIRITS and its use for SPIRITS protocol. Section 4.0 contains an example call flow for a SPIRITS service. Section 5.0, 6.0, 7.0, 8.0 respectively describe IANA Considerations, Security Considerations, provide conclusion, and acknowledgements. 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2.0 INAP Parameters of interest to SPIRITS clients on PSTN 2.1 Brief description of working A call model (CM) is a finite state machine used in SSPs and other call processing elements that accurately and concisely reflects the current state of a call at any given point in time. Call models consist of states called PICs (Points In Call) and transitions between states. Inter-state transitions pass through elements called Detection Points or DPs. DPs house one or more triggers. Every trigger has a firing criteria associated with it. When a trigger is draft-gurbani-spirits-protocol-00.txt [Page 4] The SPIRITS Protocol February 2002 armed (made active), and its associated firing criteria are satisfied, it fires. The particulars of firing criteria may vary based on the call model being supported. When a trigger fires, a message is formatted with call state information and transmitted by the SSP to the SCP. The SCP then reads this call related data and generates a response which the SSP then uses in further call processing. Detection Points are of two types: TDPs (or Trigger Detection Points), and EDPs (or Event Detection Points). TDPs are provisioned with statically armed triggers (armed through Service Management Tools). EDPs are dynamically armed triggers (armed by the SCP as call processing proceeds). DPs may also be classified as "Request" or "Notification" DPs. Thus, one can have TDP-R's, TDP-N's, EDP-R's and EDP-N's.[3] The "-R" type of DPs require the SSP to suspend call processing when communication with the SCP is initiated. Call processing resumes when a response is received. The "-N" type of DPs enable the SSP to continue with call processing when the trigger fires, after it sends out the message to the SCP, notifying it that a certain event has occurred. The distinction between these two kinds of DPs is used when we present the material in Appendix A. Call models typically support different types of detection points. Note that while INAP and the IN CS-2 call model are used in this draft as examples, and for ease of explanation, other call models possess similar properties. For example, the WIN call model also supports the dynamic arming of triggers. Thus, the essence of this discussion applies not just to the wireline domain, but applies equally well to the wireless domain as well. When the SCP receives the INAP formatted message from the SSP, if the SCP supports the SPIRITS architecture, it can encode the INAP message contents into a SPIRITS protocol message which is then transmitted to SPIRITS-capable elements in the IP network. Similarly, when it receives responses back from said SPIRITS capable elements, it can reformat the response content into the INAP format and forward these messages back to SSPs. Thus the process of inter-conversion and/or encoding between the INAP parameters and the SPIRITS protocol is of primary interest. draft-gurbani-spirits-protocol-00.txt [Page 5] The SPIRITS Protocol February 2002 +--------------+ | Subscriber's | | IP Host | +--------------+ | | | | | +----------+ | | +----------+ | | | PINT | | A | | PINT | | | | Client +<-------/-------->+ Gateway +<-----+ | +----------+ | | +----------+ | | | | | | | | +----------+ | | +----------+ | | | | SPIRITS | | B | | SPIRITS | | | | | Server +<-------/-------->+ Gateway | | | | +----------+ | | +--------+-+ | | | | | ^ | | +--------------+ +----------|---+ | | | IP Network | | ------------------------------------------|--------|--- PSTN / C / E | | v | +----+------+ | | SPIRITS | | | Client | v +-------------------+ +---+-----D-----+-++ | Service Switching |INAP/SS7 | Service Control | | Function +---------+ Function | +----+--------------+ +------------------+ | |line +-+ [0] Subscriber's Figure 1: The SPIRITS Telephone Architecture. (Note: The interfaces A-E are described in detail in the SPIRITS Architecture document [1]) In other words, this draft is focused on interfaces B, C and D depicted in the above figure. An SCP is a physical manifestation of the Service Control Function. An SSP is a physical manifestation of the Service Switching Function (and the Call Control Function). To support uniformity of nomenclature between the various SPIRITS drafts, we shall use the terms SCP and SCF, and SSP and SSF interchangeably in this document. 2.2 Identifying CS-3 IN DPs draft-gurbani-spirits-protocol-00.txt [Page 6] The SPIRITS Protocol February 2002 2.3 IN-specific details In the sub-sections that follow, we shall present IN-specific details including how to extract common data types, parameters and response codes information, with their associated descriptions, for particular DPs and triggers of interest to SPIRITS and their associated data elements. An Appendix is presented with data associated with the INAP for the IN CS-2 specification defined by the ITU. We selected CS-2 as an example simply because it has the "Recommendation in Force" status, as opposed to the "Prepublished" status of CS-3. We have previously discussed how INAP parameters may be extracted from the ASN.1-encoded format and suitably text-encoded into XML to be carried as payload in SIP messages. Response codes and associated content may be similarly carried in SIP responses, or SIP-based messages (provisional and non-provisional responses as defined in RFC 2543, section 11, pp.83-93) may be used to signal responses with appropriately encoded content that could be translated to INAP at the SCP to be sent out in the response. In Appendix B, we present an example XML DTD that may be used to support the XML-encoding for SPIRITS messages. 2.4 Encoding INAP parameters in SPIRITS using XML 2.5 Approaches for encoding DP information In typical IN systems there are two methods used to encode parameters into the messages used to support the communication between the call processing or switching element such as the SSP, and the service processing element such as the SCP. These are: (1) The DP-generic approach Only one information flow is supported for the communication between the SSP and SCP if this technique is used, and that is the flow named "Initial DP". The same message is encoded with different information elements based on what triggered operation is being requested, with a flag in the message indicating the requested operation. (2) The DP-specific approach A different information flow is supported for each distinct kind of service request/response interaction between the SSP and the SCP, with the kind of message specifying exactly draft-gurbani-spirits-protocol-00.txt [Page 7] The SPIRITS Protocol February 2002 what the embedded contents should include. In this document, and in the appendix, we present the DP-specific way of encoding parameters. A similar document may be generated that makes use of the DP-generic approach. Communication between the SCP and SSP is supported by means of Information Flows (IFs), which carry Information Elements (IEs). IFs are well-defined for each DP in the call model, and for the associated responses. To summarize, PICs are the states in the call model state machine. DPs are the entry or exit criteria for each state, that house one or more triggers. When a trigger fires, a message is formatted using the appropriate protocol into a well-defined Information Flow, and transmitted to the SCP. Upon receiving this IF, the SCP processes the received data, and transmits a response back in another IF. The SSP then extracts the IEs in the received IFs and uses these in further call processing. 2.6 Template description and procedure This section describes the format of the presentation in appendix A that presents how and what INAP CS-2 parameters may be used in the SPIRITS context. Please note that while the appendix presents the encoding for INAP CS-2 type parameters, one may use similar procedures as those described in this section to generate a similar map from any other IN standards specification to the SPIRITS protocol. (CS-2 is simply used as a convenient example in this document). Appendix A presents the DPs and triggers of interest to SPIRITS from the IN CS-2 specification. Note that not all parameters are listed in the appendix for each operation, but that a subset of parameters useful to SPIRITS has been selected. ("usefulness" was determined by considering call flows for some sample SPIRITS services). If additional parameters are required, the procedure described below may be repeated to retrieve their associated information. The template used specifies information in the following format: - Parameters - Error Codes or Indication. draft-gurbani-spirits-protocol-00.txt [Page 8] The SPIRITS Protocol February 2002 The procedure that may be used to gather more information about other detection points is as follows: Look up information associated with the detection point of interest in ITU standard Q.1228 [6]. Determine the set of associated arguments and list of parameters for that DP, along with the supported return codes. Next, use Q.1228 along with Q.1224 [7] to determine the structure and content of the parameters in each of the messages. Look up Q.763 [8] and Q.931 [9] for more related information on data- types. Collect and collate this information into the above template. 2.7 SPIRITS data and encoding In Appendices A and B, we present a select subset of IN CS-2 detection points and IFs that we believe will be useful in the context of SPIRITS services. Admittedly, this list may not be exhaustive. Note that INAP and similar protocols support a large number of optional (O) parameters in each message. Not all such parameters may be useful in the SPIRITS context, thus, only a subset of available IEs are of direct interest. Note also, that depending on what kinds of SPIRITS services are supported, and how they are implemented, the "thickness" of the SPIRITS implementation may drive exactly what subset of parameters received by the SCP are forwarded on towards the SPIRITS server for processing. An SCP could thus function in one of three modes for every incoming request: (1) process the request locally (as is traditionally done today, no SPIRITS involvement) (2) process part of the request locally and forward some parameters to a SPIRITS-entity for further processing, and formulate a response based on both the local processing and the SPIRITS response (3) forward all the received data in a SPIRITS protocol- compliant format to a SPIRITS entity for processing, and forward back the appropriately formatted response to the entity that originated the request. We do not here preclude operation in any of the modes above. As mentioned previously, the first trigger that fires during call processing is typically a TDP (since there is no pre-existing control relationship between the SSF and the SCF prior to this). TDPs are provisioned through a management system interface on the switching draft-gurbani-spirits-protocol-00.txt [Page 9] The SPIRITS Protocol February 2002 element (SSP). In the future, other mechanisms (such as PINT) may be used to provision this data as well, but in this document we limit our discussion to pure SPIRITS implementations. Since there is no explicit "subscription" via SUBSCRIBE to the TDP, a SIP INVITE message is used to carry information between the SPIRITS client and server. Responses to the INVITE message, or subsequent SUBSCRIBE messages from the SCF to the SSF within a current call context may result in EDPs being armed. NOTIFY messages are thus a convenient means of communication in those cases when triggers housed in EDPs fire. See [10], section 3 page 5 for more. Note that [10] uses the term "persistent" to refer to call-related DP arming and associated interactions. 3.0 Using the SIP Events Package for SPIRITS clients on IP Network The SIP Events Package enables IP endpoints (or hosts) to subscribe to and receive subsequent notification of events occurring in the PSTN. With reference to Figure 1 in [1], this includes communication on the interfaces marked "B" and "C". Following the nomenclature outlined in [5], the SPIRITS server (in Figure 1, [1]) is a "Subscriber" and the SPIRITS client (in Figure 1, [1]) is a "Notifier". These terms will be used to refer to the SPIRITS server and SPIRITS clients respectively in the remaining of this section. Please refer to [5] for detailed workings of the SUBSCRIBE/NOTIFY mechanism. 3.1 Normative usage A subscriber, under the effect of the user controlling it, may issue a SUBSCRIBE request which identifies the detection points (DPs) that it is interested in getting the notification of. The SUBSCRIBE request is routed to the notifier, where it is authenticated and may be accepted. Acceptance constitutes arming the said DP until the event of interest occurs. When an event of the nature requested for in the earlier SUBSCRIBE request occurs in the notifier, the notifier will format a NOTIFY request and direct it towards the subscriber. The NOTIFY request will contain the relevant information requested by the subscriber. The subscriber can then choose to act in a manner appropriate to the notification. When an event of interest occurs, the notifier can (MUST? MAY?) reset the DP. If the subscriber is further interested in the same DP, it MUST issue a new SUBSCRIBE request. draft-gurbani-spirits-protocol-00.txt [Page 10] The SPIRITS Protocol February 2002 The remaining sections fill in the template that is needed in order to fully specify a SIP Event package for the SPIRITS protocol. 3.1.1 Event package name The name of this event package is "spirits". This package has two template- packages named "INDPs" and "user-prof". The former template-package MUST be used for events corresponding to IN detection points, and the latter MUST be used for events related to the user profile information. All entities that implement the SPIRITS protocol must set the "Event" header to one of "spirits.INDPs" or "spirits.user-prof". The "Allow-Events" header can be set to "spirits.INDPs" and "spirits.user-prof": Event: spirits.INDPs Allow-Events: spirits.INDPs, spirits.user-prof 3.1.2 Event Package Parameters Parameters are not envisioned for the SPIRITS event package. 3.1.3 SUBSCRIBE Bodies The body of the SUBSCRIBE request MUST contain a body. This body encodes three pieces of information: (1) The particular DP that is being subscribed to. (2) Because of the requirement [10] that IN be informed whether the detection point is set as the request or notification, all events in the "INDPs" template package (but not in the user-prof template package) are require to provide a "mode" parameter, whose values are "R" (for report) and "N" for notification. (3) A list of the values of the parameters associated with the Event detection point (Note: the term "Event" here refers to the IN usage -- a dynamically armed DP is called an Event Detection Point) MIME type: do we need a new MIME type (application/spirits- events) or does an existing one suffice? 3.1.4 Subscription Duration draft-gurbani-spirits-protocol-00.txt [Page 11] The SPIRITS Protocol February 2002 The purpose of the SUBSCRIBE request is to arm the DP, since as far as IN is concerned, being armed is the first essential pre-requisite. A DP maybe armed either statically (for instance, through service provisioning), or dynamically (by the SCF). A statically armed DP remains armed until it is disarmed proactively. A dynamically armed DP remains armed for the duration of a call (or more appropriately, no longer than the duration of a particular SSF-SCF relationship). Dynamically armed DPs are automatically disarmed when the event of interest occurs in the notifier. It is up to the subscriber to re- arm the DPs within the context of a call, if it so desires. Statically armed DPs are considered outside the scope of the SPIRITS protocol [10] and thus will not be considered any further. 3.1.5 NOTIFY Bodies 3.1.6 Notifier processing of SUBSCRIBE requests 3.1.7 Notifier generation of NOTIFY requests 3.1.8 Subscriber processing of NOTIFY requests 3.1.9 Handling of forked requests 3.1.10 Rate of notifications 3.1.11 State Agents 3.1.12 Examples 3.1.13 URI List handling draft-gurbani-spirits-protocol-00.txt [Page 12] The SPIRITS Protocol February 2002 4.0 Example SPIRITS service call flow One of the benchmark SPIRITS service, as described in section 2.2 of [1] is Internet Caller-ID delivery: This service allows the subscriber to see the caller's number or name or both while being connected to the Internet. If the subscriber has only one telephone line and is using the very line for the Internet connection, the service is a subset of the ICW service and follows the relevant description in Section 2.1. Otherwise, the subscriber's IP host serves as an auxiliary device of the telephone to which the call is first sent. We present an example of a SPIRITS call flow to realize this service. Note that this is an example only, not a normative description of the Internet Caller-ID service Further text and details of SIP messages below refer to the call flow provided in Figure 2. Figure 2 depicts the 4 entities that are an integral part of any SPIRITS service (the headings of the entities refer to the names established in Figure 1 in [1]) -- the SPIRITS server (also termed as a "subscriber" as per section 3.0), the SPIRITS gateway (also termed as a "notifier" as per section 3.0), the SPIRITS client, and the SCF. draft-gurbani-spirits-protocol-00.txt [Page 13] The SPIRITS Protocol February 2002 SPIRITS server SPIRITS gateway SPIRITS client SCF ("subscriber") ("notifier") S G N | | | | | F1 SUBSCRIBE | | | +--------------------->| F2 SUBSCRIBE | | | +----------------->| | | | F3 200 OK (SUBS) | | | F4 200 OK (SUBS) |<-----------------+ F5 Arm DP | |<---------------------+ +--------------->| | | F6 NOTIFY | | | F7 NOTIFY |<-----------------+ | |<---------------------+ | | | | | | | F8 200 OK (NOT) | | | +--------------------->| F9 200 OK (NOT) | | | +----------------->| | | | | | ~ ~ ~ ~ ~ ~ ~ ~ | | | F10 Evt. Not. | | | F11 NOTIFY |<---------------+ | F12 NOTIFY |<-----------------+ | |<---------------------+ | | | | | | | F13 200 OK (NOT) | | | +--------------------->| F14 200 OK (NOT) | | | +----------------->| | | | | | | | | | \|/ \|/ \|/ \|/ v v v v Figure 2: Sample call flow This call flow depicts an overall operation of a "subscriber" successfully subscribing to the IN Termination_Attempt DP (the "subscriber" is assumed to be a user, possibly at work, who is interested in knowing when he/she gets a phone call to his/her home phone number) -- this interaction is captured in messages F1 through F9 in Figure 2. The user sends (F1) a SIP SUBSCRIBE request identifying the DP it is interested in along with zero or more parameters relevant to that DP (in this example, the Termination_Attempt_DP will be employed). The SPIRITS gateway authorizes the user (F2) and propagates the request to the SPIRITS client (F2). The SPIRITS client in turns interacts with the SCF to arm the Termination_Attempt_DP for the service (F5). An immediate NOTIFY with the current state information is send to the subscriber draft-gurbani-spirits-protocol-00.txt [Page 14] The SPIRITS Protocol February 2002 (F6 through F9). At some later point in time after the above sequence of events has transpired, the PSTN gets a call to the users phone. The SSF informs the SCF of this event when it encounters an armed Termination_Attempt_DP (not shown in Figure 2). The SCF informs the SPIRITS client of this event (F10). When the SPIRITS client receives this event, it forms a SIP NOTIFY request and directs it to the SPIRITS gateway (F11). This NOTIFY will contain all the information elements necessary to identify the caller to the subscriber. The subscriber, upon receiving the notification (F12) may pop open a window with the date/time and the number of the caller. The rest of this section contains the details of the SIP messages in Figure 2. The call flow details below assume that the SPIRITS gateway is, for the purpose of this example, a SIP proxy that serves as the default outbound proxy for the notifier and an ingress host of the myprovider.com domain for the subscriber. The subscriber and notifier may be in separate administrative domains. F1: S->G SUBSCRIBE sip:myprovider.com SIP/2.0 From: ;tag=8177-afd-991 To: CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.lucent.com Contact: Via: SIP/2.0/UDP host.lucent.com Expires: 3600 Event: spirits.INDPs Allow-Events: spirits.INDPs, spirits.user-prof Accept: application/spirits-event Content-Type: application/spirits-event Content-Length: ... 6302240216 The subscriber forms a SIP SUBSCRIBE request which identifies the DP that it wants to subscribe to (in this case, the TAA DP) and the actual line it wants that DP armed for (in this case, the line draft-gurbani-spirits-protocol-00.txt [Page 15] The SPIRITS Protocol February 2002 associated with the phone number 6302240216). This request eventually arrives at the SPIRITS gateway, G, which forwards it to the SIPRITS client, N: F2: G->N SUBSCRIBE sip:notifier.myprovider.com SIP/2.0 From: ;tag=8177-afd-991 To: CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.lucent.com Contact: Via: SIP/2.0/UDP gateway.myprovider.com Via: SIP/2.0/UDP host.lucent.com Expires: 3600 Event: spirits.INDPs Accept: application/spirits-event Content-Type: application/spirits-event Content-Length: ... 6302240216 A 200 OK is sent by the notifier when it gets the SUBSCRIBE request and understands the contents in it. The notifier also interfaces with the SCF to arm the DP (F5, not shown in the SIP messages below): F3: N->G SIP/2.0 200 OK From: ;tag=8177-afd-991 To: ;tag=SPIRITS-TAA-6302240216 CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.lucent.com Contact: Via: SIP/2.0/UDP gateway.myprovider.com Via: SIP/2.0/UDP host.lucent.com Expires: 3600 Accept: application/spirits-event Content-Length: 0 The 200 OK arrives at the subscriber, thus creating a dialog between the subscriber and the notifier: draft-gurbani-spirits-protocol-00.txt [Page 16] The SPIRITS Protocol February 2002 F4: G->S SIP/2.0 200 OK From: ;tag=8177-afd-991 To: ;tag=SPIRITS-TAA-6302240216 CSeq: 18992 SUBSCRIBE Call-ID: 3329as77@host.lucent.com Contact: Via: SIP/2.0/UDP host.lucent.com Expires: 3600 Accept: application/spirits-event Content-Length: 0 The notifier also sends an immediate NOTIFY towards the subscriber informing the subscriber of the current state of the notification: F6: N->G NOTIFY sip:vkg@host.lucent.com SIP/2.0 From: ;tag=SPIRITS-TAA-6302240216 To: ;tag=8177-afd-991 Via: SIP/2.0/UDP notifier.myprovider.com Call-ID: 3329as77@host.lucent.com Contact: CSeq: 3299 NOTIFY Event: spirits.INDPs Allow-Events: spirits.INDPs, spirits.user-prof Subscription-State: active Accept: application/spirits-event Content-Length: 0 The SPIRITS gateway routes the SIP request towards the subscriber: F7: G->S NOTIFY sip:vkg@host.lucent.com SIP/2.0 From: ;tag=SPIRITS-TAA-6302240216 To: ;tag=8177-afd-991 Via: SIP/2.0/UDP gateway.myprovider.com Via: SIP/2.0/UDP notifier.myprovider.com Call-ID: 3329as77@host.lucent.com Contact: Subscription-State: active CSeq: 3299 NOTIFY Accept: application/spirits-event Content-Length: 0 And finally, the 200 OK to the NOTIFY reaches the notifier: draft-gurbani-spirits-protocol-00.txt [Page 17] The SPIRITS Protocol February 2002 F8: S->G SIP/2.0 200 OK From: ;tag=SPIRITS-TAA-6302240216 To: ;tag=8177-afd-991 Via: SIP/2.0/UDP gateway.myprovider.com Via: SIP/2.0/UDP notifier.myprovider.com Call-ID: 3329as77@host.lucent.com Contact: CSeq: 3299 NOTIFY Accept: application/spirits-event Content-Length: 0 F9: G->N SIP/2.0 200 OK From: ;tag=SPIRITS-TAA-6302240216 To: ;tag=8177-afd-991 Via: SIP/2.0/UDP notifier.myprovider.com Call-ID: 3329as77@host.lucent.com Contact: CSeq: 3299 NOTIFY Accept: application/spirits-event Content-Length: 0 At some later point in time (before the subscription established in F1 expires at the notifier), a call arrives at the number identified in XML-encoded body of F1 -- 6302240216. The SCF notifies the notifier (F10, not shown in the SIP messages below). Included in this notification is the relevant information from the PSTN, namely, the phone number of the party attempting to call 6302240216. The notifier uses this information to create a SIP NOTIFY request and sends it to the default outbound proxy. The SIP NOTIFY request has a XML-encoded body with the relevant information from the PSTN: F11: N->G NOTIFY sip:vkg@host.lucent.com SIP/2.0 From: ;tag=SPIRITS-TAA-6302240216 To: ;tag=8177-afd-991 Via: SIP/2.0/UDP notifier.myprovider.com Call-ID: 3329as77@host.lucent.com Contact: CSeq: 3300 NOTIFY Subscription-State: terminated;reason=fired Accept: application/spirits-event Event: spirits.INDPs Allow-Events: spirits.INDPs, spirits.user-prof draft-gurbani-spirits-protocol-00.txt [Page 18] The SPIRITS Protocol February 2002 Content-Type: application/spirits-event Content-Length: ... 6302240216 3125675000 The default outbound proxy delivers the SIP NOTIFY request to the subscriber: F12: G->S NOTIFY sip:vkg@host.lucent.com SIP/2.0 From: ;tag=SPIRITS-TAA-6302240216 To: ;tag=8177-afd-991 Via: SIP/2.0/UDP gateway.myprovider.com Via: SIP/2.0/UDP notifier.myprovider.com Call-ID: 3329as77@host.lucent.com Contact: CSeq: 3300 NOTIFY Subscription-State: terminated;reason=fired Accept: application/spirits-event Event: spirits.INDPs Allow-Events: spirits.INDPs, spirits.user-prof Content-Type: application/spirits-event Content-Length: ... 6302240216 3125675000 There are a couple of important issues to note in the call flows for F11 or F12: (1) The body of the NOTIFY request contains the information passed to the SPIRITS client from the SCF. In this particular example, this is the phone number of the party (3125675000) that attempted to call 6302240216. (2) Since the notification occurred, the subscription established draft-gurbani-spirits-protocol-00.txt [Page 19] The SPIRITS Protocol February 2002 in F1 terminated (as evident by the Subscription-State header). The subscription terminated normally due to the DP associated with TAA firing (hence the reason code of "fired" in the Subscription-State header). If the subscriber wants to get notified of another attempt to call the number 6302240216, he/she should send a new SUBSCRIBE request to the notifier. The subscriber can take any appropriate action upon the receipt of the NOTIFY in F12. A reasonable implementation may pop up a window populated with the information contained in the body of F12, along with a button asking the subscriber if they would like to re- subscribe to the same event. Alternatively, a re-subscription could be generated automatically by the subscriber's UA based on his/her preferences. To complete the protocol, the subscriber also sends a 200 OK message towards the notifier: F13: S->G 200 OK SIP/2.0 From: ;tag=SPIRITS-TAA-6302240216 To: ;tag=8177-afd-991 Via: SIP/2.0/UDP gateway.myprovider.com Via: SIP/2.0/UDP notifier.myprovider.com Call-ID: 3329as77@host.lucent.com CSeq: 3300 NOTIFY Content-Length: 0 F14: G->N 200 OK SIP/2.0 From: ;tag=SPIRITS-TAA-6302240216 To: ;tag=8177-afd-991 Via: SIP/2.0/UDP notifier.myprovider.com Call-ID: 3329as77@host.lucent.com CSeq: 3300 NOTIFY Content-Length: 0 5.0 IANA considerations [Note for authors: need to register the following: mime types: application/spirits-event, tokens: spirits.INDPs, spirits.user-prof] draft-gurbani-spirits-protocol-00.txt [Page 20] The SPIRITS Protocol February 2002 6.0 Security considerations Security concerns are listed here as a starting point; this list is by no means exhaustive and will be updated as this I-D progresses. As outlined in Chapter 10 of [10], the following security aspects are applicable to the SPIRITS protocol: Authentication Integrity Confidentiality Availability Non-repudiation For the most part, the SPIRITS protocol will leverage the security infrastructure defined in SIP [11] as well as XML security [12]. In addition, there are other issues of concern to SPIRITS, most of which have to do with the trust relationship between SPIRITS entities. For example, in Figure 1, interface C straddles the boundary between the two networks -- PSTN and the Internet. Thus it crosses both the administrative as well as the network domains. As such, issues like authentication, message integrity, and confidentiality take on a deeper meaning. These issues will be identified and addressed as the I-D progresses. 7.0 Conclusion 8.0 Acknowledgements The authors are grateful to all participants in the SPIRITS WG for the discussion that has contributed to this work. Special thanks to J-L. Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B.Chatras, O. Cleuziou, L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik, W. Montgomery, S. Nyckelgard, M. O'Doherty, H. Sinnreich, L. Slutsman, D. Varney, W. Zeuch CHANGES Changes since -00 draft-gurbani-spirits-protocol-00.txt [Page 21] The SPIRITS Protocol February 2002 (1) Updated section 8.0 (Acknowledgements) (2) Fleshed out the call flow in section 4.0 (Example SPIRITS service call flow) APPENDIX A: INAP Parameters and Data Types This Appendix presents Information Flows (IFs), Information Elements (IEs), commonly used data types, their corresponding structure and encoding-related details, and error codes. In other words, material presented in this section forms the basis for the XML encoding presented in the next appendix. In the sections that follow, we first present IFs from the SSP to the SCP, and then the IFs in the opposite direction. Note that the IFs from the SSP to the SCP are tied more closely to the DP where the trigger fires, and are therefore presented by DP, whereas some IFs flowing in the opposite direction may be used in response to messages received from multiple DPs and are therefore presented independently. Mandatory and Optional parameters are so indicated by the M and O tags. A.1 Information Elements (IEs): The following are some commonly used Information Elements that seen relevant in the SPIRITS context. These are described most completely in the ITU specifications Q.1224 and Q.1228. Access Code - contains information associated with an Access Code if a customized dialing plan is used to request a call origination. Busy Cause - identifies the reason a called party was busy. Calling Party Subaddress - the sub-address associated with the calling party of a call. Called Party Subaddress - the sub-address associated with the called party of a call. Called Party Number (TDP) - Identifies the called party in a call. Carrier - this consists of a carrier selection indicator that states whether the selected carrier was the subscribed carrier of the user or was selected for that call by dialing a carrier code, and a Carrier ID that indicates the carrier selected. (Q: ITU doc says presubscribed carrier - is this correct?). draft-gurbani-spirits-protocol-00.txt [Page 22] The SPIRITS Protocol February 2002 Cause - states why a specific entity was released. Connect Time - indicates the duration for which the call was active. Dialed Digits - indicates the information received by a switching element from the end-user (if it is a class 5 switch) or from another switch (if it is a class 4 switch). Failure Cause - specifies the reason why a particular route selection failed. Feature Code - encodes any special feature codes dialed by the caller. This information may be encoded for use in the Origination Attempt and Collected Info DPs. Feature Request Indicator - specifies the requested feature type. Original Called Party ID - specifies the identity of the first redirecting party. Prefix - encodes any non feature code, non access code digits that are dialed. This information may be encoded a the Origination Attempt and Collected Info DPs (it is used in the Analysed_Info DP). Redirecting Party ID - specifies the identity of the last redirecting party. Redirection Information - indicates the reason for the redirection and the number of redirections that have taken place. Release Cause - specifies why a particular resource or call party is released. Route List - represents the list of routes which could be used to route the call. Service Address Information triggerType (TDP) - when used, enables the SCP to pick the appropriate application to service the request. Also permits the SCP to validate an incoming request. A.2 Commonly used parameters The commonly used parameters described in this section each tie in with one of the information elements listed above. The base "type" of a parameter that could be used for encoding it is also listed. Some of these parameters though encoded as basic strings consist of rather draft-gurbani-spirits-protocol-00.txt [Page 23] The SPIRITS Protocol February 2002 complicated internal data-types. The complexities of these datatypes is not presented here, the interested reader is referred to ITU specifications Q.1228 and Q.760-764 for those. releaseCause An integer specifying the reason for the release of a given cause busyCause A string indicating the reason why a busy signal was received. callingPartySubaddress A string denoting the callingPartySubaddress i.e. the subaddress associated with the origin of the call. This field has a maximum length of 20 octets or 40 digits. The actual length and encoding of this parameter depend on the particulars of the dialing plan used. calledPartySubaddress A string denoting the calledPartySubaddress i.e. the subaddress associated with the called party of the call. This field has a maximum length of 20 octets or 40 digits. The actual length and encoding of this parameter depend on the particulars of the dialing plan used. originalCalledPartyID Indicates the original called party number. The actual length of this parameter depends on the particulars of the dialing plan used. redirectingPartyID A string indicating the last directory number the call was redirected from. redirectionInformation A byte[2] element that specifies any additional redirection information including why the call was diverted, what kind of call diversion mechanism/reason was used (unconditional, busy, no answer), the number of redirections (between 1 and 5), and what redirection information is available in each case. carrier A string that encodes the selected carrier and the transit network selection code. CalledPartyNumber A parameter encoded as a string that is used to identify the called party in the forward direction, Used to convey dialed digits information if the switching element has recognized the draft-gurbani-spirits-protocol-00.txt [Page 24] The SPIRITS Protocol February 2002 called party number in the digits dialed. If the switching element was unable to make this determination, the same information is conveyed in a string-encoded form as the parameter "dialed digits". OriginalCalledPartyID A string encoded parameter that carries the identity of the original called party. Used in other messages if the call gets redirected. A.3 Error codes This section presents some error codes that are sent by the SCP to the switching element to indicate an error or failure condition. The descriptions for these various error codes may be most easily obtained by looking up ITU documents Q.760-764, and Q.931. Error codes are encoded as integers (per Q.1228). missingCustomerRecord This error code indicates that either the customer record does not exist on the SCP, or that there is no service logic identified by the indicated service key. Each of these is encoded using a distinct error condition so the requesting entity can distinguish between these two error categories. Error code 6 is used to identify this error. missingParameter An expected parameter was not received by the server processing the request. Error code 7 is used to identify this error. systemFailure A system failure at the server caused the request to not be processed. (Error code 11). taskRefused A requested operation was refused (e.g. due to link congestion) by the server. (Error code 12). unexpectedComponentSequence An incorrect sequence of components was received, and/or operations requested are not permitted in the current state of the call. (Error code 14). unexpectedDataValue An incorrect data value was received, or data value received cannot be bound to the expected parameter at the server. (Error code 15). draft-gurbani-spirits-protocol-00.txt [Page 25] The SPIRITS Protocol February 2002 unexpectedParameter A parameter was received, but was not expected by the server. (Error code 16). unknownLegID A particular call-leg is not known to the server. (Error code 17). parameterOutOfRange Unexpected value for a parameter. Either (if Integer), the parameter was beyond specified ranges, or (if enumerated), was not one of the listed enumerated types. (Error code 8). A.4 Detection points, triggers, and related information In this section, we present Detection Points supported by the IN CS-2 Call Model, along with the associated information elements and parameters. Only selected parameters that are relevant to the SPIRITS context and effort are presented as examples. These have been described in preceding sections. If desired, additional parameters may also be supported. This section is divided into two sub-sections. In the first of these we present Originating DPs (associated with the calling party), and in the second, we elaborate on Terminating DPs (associated with the called party). A.4.1 Originating detection points These are defined in ITU-T Recommendation Q.1224, and are representative of the call model elements between the states defined in the Originating Call Model BCSM (O_BCSM). All the DPs in the O_BCSM support the complete list of error conditions described in section A.3. draft-gurbani-spirits-protocol-00.txt [Page 26] The SPIRITS Protocol February 2002 +--------->-----------+ | | | +-------V-------------+ +---------------------+ | +-------->| 1. O_NULL |<-----| 11. O_Exception | | | +---------------------+ +--------------+------+ | +---+ O_Abandon | | | |21 | | | | +---+ +-V-+ ^ | | | 1 | Orig.Attempt | | | +-----+---+-----------+ +---+ | | |<--------| 2. Auth_Orig_Att. |---->| 2 |---------->| | | +---------------------+ +---+ Orig. | | | | Denied. | | | | | | | +-V-+ | ^ | | 3 | Orig.Attempt.Auth | | | +-----+---+-----------+ +---+ | | |<--------| 3. Collect_Info. |---->| 4 |---------->| | | +---------------------+ +---+ Collect | | | | Timeout | | | | | | | +-V-+ | | | | 5 | Collected.Info Invalid | | | +-----+---+-----------+ +---+ Info | | |<--------| 4. Analyze_Info. |---->| 6 |---------->| | | +---------------------+ +---+ | | | | | | | | | | | Analyzed +-V-+ + -------<----------------------+ | | Info | 7 | | Route Select | | | | +-----+---+-----V-----+ +---+ Failure | | | |<--------| 5. Select_Route. |---->| 8 |---------->| | | | +---------------------+ +---+ | | ^ | | | ^ | | | | | | | Route +-V-+ | | | | Selected | 9 | Auth | | | | +-----+---+-----------+ +---+Failure | | | |<--------| 6. Auth_Call_Setup |---->|10 |---------->| | | | +---------------------+ +---+ | | | | | | | | | | Route | | | | +-V-+ Orig. +---+ Failure | | | | |11 | Auth. |12 |-------------->+ | | +-----+---+-----------+---->+---+ | | |<--------| 7. Call_Sent | +---+ | ^ | +---+-----------------+---+---->|13 |---------->| | | |18 |O_Mid | | +---+ | draft-gurbani-spirits-protocol-00.txt [Page 27] The SPIRITS Protocol February 2002 | | +---+ _Call | +-----+ O_Called_Party | | | +-V-+ | _Busy | | | O_Term_Seized |14 | | | | | +-----+---+-----------+ | +---+ | | |<--------| 8. O_Alerting |-|-->|15 |---------->| | | +---+---------------------+ | +---+ | | | |18 | | | O_No_Answer | | | +---+ | | | | | +-V-+<------------+ | | | |16 | O_Answer | | | +-----+---+-----------+ +---+ | | +---------| 9. O_Active. |---->|17 |---------->+ | +---+---------------------+ +---+ | |18 | | O_Conn_Failure | +---+ | | +-V-+ | |19 | O_Disconnect +---+ +-----+---+-----------+ |20 |<--------| 10. O_Disconnect. | +---+ +---------------------+ O_Disconnect _Complete Figure 2: The CS-2 O_BCSM [ref.] 1. O_Abandon Indicates that a call has been abandoned. Information Elements: Data Types M/O Call Segment ID callSegmentID M Release Cause cause O DpSpecificCommonParameters 2. O_Called_Party_Busy This DP is an indication from the terminating BCSM that the terminating party is busy. Information Elements: Data Types M/O Busy Cause cause O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Original Called Party ID originalCalledPartyID O Prefix - O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O DpSpecificCommonParameters Digits draft-gurbani-spirits-protocol-00.txt [Page 28] The SPIRITS Protocol February 2002 3. O_Disconnect This operation signals a disconnect indication from the originating party, after a call was set up. Information Elements: Data Types M/O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Connect Time connectTime O Release Cause releaseCause O 4. Collected Information This operation indicates that a complete string of digits was received from the originating party. Information Elements: Data Types M/O Access Code O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Dialed Digits digits O Feature Code - O Original Called Party ID originalCalledPartyID O Prefix - O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O calledPartyNumber 5. Origination Attempt Authorized This operation indicates that the originating party is permitted to make the outgoing call. Information Elements: Data Types M/O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Dialed Digits calledPartyNumber O 6. O_No_Answer This operation is an indication from the terminating BCSM that the called party has not answered the call in a specified time period. Information Elements: Data Types M/O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Original Called Party ID originalCalledPartyID O Prefix - O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O DpSpecificCommonParameters Digits draft-gurbani-spirits-protocol-00.txt [Page 29] The SPIRITS Protocol February 2002 7. O_MidCall This operation indicates a feature requested received from the originating party after the call has been set up. Information Elements: Data Types M/O Called Party Subaddress calledPartySubaddress O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Feature Request Indicator featureRequestIndicator O 8. O_Answer This operation is a signal from the terminating BCSM that the call has been answered. Information Elements: Data Types M/O Calling Party Subaddress callingPartySubaddress O Original Called Party ID originalCalledPartyID O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O DpSpecificCommonParameters 9. Analysed Information This operation indicates that a routing address and call type are available. Information Elements: Data Types M/O Access Code accessCode O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Dialed Digits Digits O Feature Code featureCode O Original Called Party ID originalCalledPartyID O Prefix - O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O DpSpecificCommonParameters CalledPartyNumber 10. Route Select Failure Indicates that a route to terminate the call cannot be selected by the SSP, or that the call cannot be presented by the terminating BCSM to the called party due to a reason such as network congestion. Information Elements: Data Types M/O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Dialed Digits Digits O Failure Cause cause O draft-gurbani-spirits-protocol-00.txt [Page 30] The SPIRITS Protocol February 2002 Original Called Party ID originalCalledPartyID O Prefix - O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O DpSpecificCommonParameters CalledPartyNumber A.4.2 Terminating detection points These are defined in ITU-T Recommendation Q.1224, and are hosted by the terminating BCSM (T_BCSM) finite state machine. All the DPs in the T_BCSM support the complete list of error indications we have previously described in section A.3. +---------------<------------+ | | +---------------------+ +-------V-------------+ | | 19. T_Exception |----->| 12. T_NULL |<-------+ | +------+--------------+ +---------------------+ | | | | T_Abandon +---+ | | +-V-+ |35 | | | |22 | Term_Attempt +---+ | | +---+ +-----+---+-----------+ | | +<--------|23 |<------| 13. Auth_Term_Att. |------->+ | | +---+ +---------------------+ | | | Term_Denied | | | | | ^ ^ | +-V-+ | | | |24 | Term_Auth. | | | +---+ +-----+---+-----------+ | | +<---------|25 |<-----| 14. Select_Fac. |------->+ | | +---+ +---------------------+ | | | T_Called_Party_Busy | | | | | | | | +-V-+ ^ ^ | |26 | Term.Res.Avail | | | +---+ +-----+---+-----------+ | | +<---------|27 |<-----| 15. Present_Call. |------->+ | | +---+ +--+------------------+ | | | Presentation | | | | | Failure +-----+ | | | | | +-V-+ ^ | | | |28 | T_Term_Seized | | | +---+ | +-----+---+-----------+ | | +<---------|29 |<--|--| 16. T_Alerting |------->+ | | +---+ | +---------------------+---+ | | | T_No_Answer | | T_Mid_Call |32 | | | draft-gurbani-spirits-protocol-00.txt [Page 31] The SPIRITS Protocol February 2002 | | | +---+ | | | | +-V-+ | | | +------->|30 | T_Answer | | | +---+ +-----+---+-----------+ | | +<---------|31 |<-----| 17. T_Active |------->+ | +---+ +---------------------+---+ | T_Conn.Failure | |32 | ^ | +---+ | +-V-+ | |33 | T_Disconnect | +-----+---+-----------+ +---+ | | 18. T_Disconnect |---->|34 |--->+ +---------------------+ +---+ T_Disconnect_Complete Figure 3: The CS-2 T_BCSM [ref.] 1. Termination Attempt Authorized Indicates that an incoming call received from the originating BCSM is authorized to be routed to the terminating end. Information Elements: Data Types M/O Called Party Subaddress calledPartySubaddress O Calling Party Subaddress callingPartySubaddress O Original Called Party ID originalCalledPartyID O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O DpSpecificCommonParameters 2. T_Abandon There is no operation for TAbandon as it cannot be armed as TDP. The T_Abandon and O_Abandon DPs refer to the event of the A-party disconnecting prior to B-party answering. The former is reported by the TBCSM while the latter is reported by the OBCSM. 3. T_Busy Indicates that the call cannot be completed because all resources to the terminating end are busy. Information Elements: Data Types M/O Busy Cause cause O Called Party Subaddress calledPartySubaddress O Original Called Party ID originalCalledPartyID O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O DpSpecificCommonParameters draft-gurbani-spirits-protocol-00.txt [Page 32] The SPIRITS Protocol February 2002 4. Facility Selected and Available Indicates that a facility to route to has been selected and is available for use. Information Elements: Data Types M/O DpSpecificCommonParameters dpSpecificCommonParameters O Called Party Subaddress calledPartySubaddress O Calling Party Number callingPartyNumber O Original Called Party ID originalCalledPartyID O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O 5. T_No_Answer A terminating BCSM indication that the terminating party did not answer in a specified duration. Information elements: Data Types M/O Service Address Information Octet String O? triggerType Called Party Number - O? Called Party Subaddress calledPartySubaddress O? Original Called Party ID originalCalledPartyID O? Redirecting Party ID redirectingPartyID O? Redirection Information redirectionInformation O? DpSpecificCommonParameters 6. T_Answer Indicates that the call has been accepted and answered by the terminating party. Information elements: Data Types M/O Service Address Information Octet String O? triggerType Called Party Number - O? Called Party Subaddress calledPartySubaddress O? DpSpecificCommonParameters 7. T_MidCall Indicates a mid-call feature request from the terminating party. Information Elements: Data Types M/O Called Party Subaddress calledPartySubaddress O Calling Party Subaddress callingPartySubaddress O Carrier carrier O Feature Request Indicator featureRequestIndicator O DpSpecificCommonParameters 8. T_Disconnect draft-gurbani-spirits-protocol-00.txt [Page 33] The SPIRITS Protocol February 2002 Indicates that a disconnect indication was received from the terminating party or from the originating BCSM to end an active call. Information Elements: Data Types M/O Called Party Subaddress calledPartySubaddress O Connect Time - O Release Cause cause O DpSpecificCommonParameters O A.5 SCF to SSF IFs This section presents the Information Flows of interest, that originate at the SCP and flow towards the SSP. These typically encode responses to SSF-originated requests. Note that different responses may be sent to a request that originated from the same DP, based on the result of service related processing at the SCP. 1. Analyse Information requests the SSF to perform digit analysis and related functions to determine how the call may be set up. Information Elements: Data Types M/O Call ID callID (Integer?) M Destination Routing Address DestinationRoutingAddress O Call Segment ID callSegmentID O Calling Party Number callingPartyNumber O Called Party Number calledPartyNumber O Carrier carrier O Charge Number chargeNumber O 2. Authorise Termination requests the SSF to perform basic call processing functions associated with the Authorize_Termination_Attempt PIC. This response may be received by the SSF when call processing is suspended in any of the following DPs: Termination_Attempt, Termination_Attempt_Authorized, T_Busy, or, T_No_Answer. Information Elements Data Types M/O Call ID callID (Integer?) M Calling Party Number callingPartyNumber O Original Called Party ID originalCalledPartyID O Leg ID legID (Integer?) O 3. Collect Information requests the SSF to prompt and collect more information (associated with a given numbering plan) from the calling party. This response is received by the SSF when call processing is suspended at any of the draft-gurbani-spirits-protocol-00.txt [Page 34] The SPIRITS Protocol February 2002 following DPs: Origination_Attempt_Authorized, Collected_Info, Analyzed_Info, Route_Select_Failure, O_Called_Party_Busy, O_No_Answer. Information Elements Data Types M/O Call ID callID (Integer?) M Original Called Party ID originalCalledPartyID O Calling Party Number callingPartyNumber O Called Party Number Digits O 4. Connect used to create a call to a defined destination, or to forward a call to a different destination. May be received by the SSF in response to a message sent out in the O_MidCall DP. Information Elements Data Types M/O Call ID callID (Integer?) M Destination Routing Address destinationRoutingAddress M Forwarding Condition forwardingCondition O Carrier carrier O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O Display Information displayInformation O Charge Number chargeNumber O Call Segment ID callSegmentID (Integer?) O SCF ID ??? O 5. Continue requests the SSF to proceed with call processing. Can be received as a response at any DP. For parameters, please see the section on unresolved issues. 6. Furnish Charging Information gives the SSF some billing information to help it generate an appropriate billing record. Information Elements Data Types M/O Call ID callID (Integer?) M Billing Charging ??? M Characteristics 7. Hold Call In Network used to provide the Call Queueing functionality. Call processing may have been suspended at any DP before the active state, on the SSF. For parameters, please see the section on unresolved issues. 8. Initiate Call Attempt draft-gurbani-spirits-protocol-00.txt [Page 35] The SPIRITS Protocol February 2002 used by the SCF to have the SSF initiate a call to one party based on information provided by the SCF. This is used to support features such as Wake-up calls. The SSF sets an EDP-R for the Answer and No_Answer conditions. There is no previous SCP-SSP context for this information flow. Information Elements Data Types M/O Call ID callID (Integer?) M Leg to be Created legID M New Call Segment callSegmentID (Integer?) M Destination Routing Address destinationRoutingAddress O 9. Release Call used to kill an existing call. Can be received by the SSF at any point in call processing, and causes a transition into O_NULL for the O_BCSM, and T_NULL for the T_BCSM. Information Elements Data Types M/O Call ID callID (Integer?) M Initiate Call Segment cause O Associated Call Segment [] { Call Segment Integer O Release Cause } cause O All Call Segments [] { Release Cause } cause O 10. Request Notification Charging Event used by the SCF to request the SSF to monitor for a charging event and send back a notification. Information Elements Data Types M/O Call ID callID (Integer?) M Charging Events [] byte array M 11. Request Report BCSM Event used by the SCF to request the SSF to monitor a call related event such as BUSY or No_Answer, and send a notification back. Information Elements Data Types M/O Call ID callID (Integer?) M BCSM Event List BCSMEvent [] M 12. Trigger Data Status Request used by the SCF to request the SSF to send back the current set of fields associated with flags. Information Elements Data Types M/O Call ID callID (Integer?) M draft-gurbani-spirits-protocol-00.txt [Page 36] The SPIRITS Protocol February 2002 Requested Field ??? M Trigger Data Identifier ??? M Support for other SCF to SSF IFs is not envisioned for SPIRITS at this time, though additions may still be made in later versions of this document. APPENDIX B: XML DTD for IFs, examples of use In this section, we present XML DTDs for the Information Flows previously described, along with examples of their use. B.1 Conventions Throughout this internet-draft the US-ASCII coded character set, defined in ANSI X3.4-1986, is used. All SPIRITS protocol elements are defined using XML DTDs [17]. The SPIRITS protocol elements, or SPIRITS protocol operations, are composed only of the definition of the root element and the inclusion of the necessary information element DTD. The strings "******" and "******" denote the boundaries of an XML DTD. B.2 General DTD syntax + One or more occurrences * Zero or more occurrences ? Optional element () A group of expressions to be matched together | OR, as in "this OR that" , Strictly ordered. Like AND, as in "this AND that" B.3 XML DTDs for INAP Information Elements These are the DTD for the commonly used elements. These DTD representations are used as building blocks in encoding the various parameters in the IFs. B.3.1 AccessCode ****** draft-gurbani-spirits-protocol-00.txt [Page 37] The SPIRITS Protocol February 2002 ******** B.3.2 AllCallSegments ****** ******** B.3.3 AssociatedCallSegment ****** ******** B.3.4 BCSMEvent ****** draft-gurbani-spirits-protocol-00.txt [Page 39] The SPIRITS Protocol February 2002 draft-gurbani-spirits-protocol-00.txt [Page 40] The SPIRITS Protocol February 2002 draft-gurbani-spirits-protocol-00.txt [Page 41] The SPIRITS Protocol February 2002 ******** B.3.5 BillingChargingCharacteristics ****** ******** B.3.6 BusyCause ****** ******** B.3.7 CalledPartyNumber ****** ******** B.3.8 CalledPartySubaddress ****** draft-gurbani-spirits-protocol-00.txt [Page 42] The SPIRITS Protocol February 2002 ******** B.3.9 CallID ****** ******** B.3.10 CallingPartyNumber ****** ******** B.3.11 CallingPartySubaddress ****** draft-gurbani-spirits-protocol-00.txt [Page 43] The SPIRITS Protocol February 2002 ******** B.3.12 CallSegmentID ****** ******** B.3.13 Carrier ****** ******** B.3.14 ChargeNumber ****** ******** B.3.15 ChargingEvent ****** %sp_inap_mon.dtd ******** B.3.16 ConnectTime ****** ******** B.3.17 DestinationRoutingAddress ****** %sp_inap_cdn.dtd ******** B.3.18 DialedDigits ****** draft-gurbani-spirits-protocol-00.txt [Page 45] The SPIRITS Protocol February 2002 ******** B.3.19 FailureCause ****** ******** B.3.20 DisplayInformation ****** ******** draft-gurbani-spirits-protocol-00.txt [Page 46] The SPIRITS Protocol February 2002 B.3.21 FeatureCode ****** ******** B.3.22 FeatureRequestIndicator ****** ******** B.3.23 ForwardingCondition ****** ******** B.3.24 InitiateCallSegment ****** ******** B.3.25 LegID ****** ******** B.3.26 LegToBeCreated ****** draft-gurbani-spirits-protocol-00.txt [Page 48] The SPIRITS Protocol February 2002 ******** B.3.27 MonitorMode ****** ******** B.3.28 NewCallSegment ****** ******** B.3.29 OriginalCalledPartyID ****** ******** B.3.30 Prefix draft-gurbani-spirits-protocol-00.txt [Page 49] The SPIRITS Protocol February 2002 ****** ******** B.3.31 RedirectingPartyID ****** ******** B.3.32 RedirectionInformation ****** ******** B.3.33 ReleaseCause ****** draft-gurbani-spirits-protocol-00.txt [Page 50] The SPIRITS Protocol February 2002 ******** B.3.34 ServiceAddressInformation ****** draft-gurbani-spirits-protocol-00.txt [Page 51] The SPIRITS Protocol February 2002 draft-gurbani-spirits-protocol-00.txt [Page 52] The SPIRITS Protocol February 2002 ******** B.4 XML DTDs for INAP Originating Detection Points This section presents the XML encoding for Information Flows (IFs) between the SSF and the SCF. The XML building blocks for common elements defined in section B.3 are used in the XML definitions here. B.4.1 O_Abandon ****** draft-gurbani-spirits-protocol-00.txt [Page 53] The SPIRITS Protocol February 2002 %sp_inap_csi.dtd; %sp_inap_rcs.dtd ******** B.4.2 O_Called_Party_Busy ****** %sp_inap_bcs.dtd; %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_ocp.dtd; %sp_inap_pfx.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd draft-gurbani-spirits-protocol-00.txt [Page 54] The SPIRITS Protocol February 2002 ******** B.4.3 O_Disconnect ****** %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_ctm.dtd; %sp_inap_rcs.dtd ******** B.4.4 Collected_Information ****** draft-gurbani-spirits-protocol-00.txt [Page 55] The SPIRITS Protocol February 2002 %sp_inap_acd.dtd; %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_dld.dtd; %sp_inap_fcd.dtd; %sp_inap_ocp.dtd; %sp_inap_pfx.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.4.5 Origination_Attempt_Authorized ****** %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_dld.dtd; ******** B.4.6 O_No_Answer ****** %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_ocp.dtd; %sp_inap_pfx.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.4.7 O_Midcall ****** %sp_inap_cdp.dtd; %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_fri.dtd ******** B.4.8 O_Answer ****** draft-gurbani-spirits-protocol-00.txt [Page 57] The SPIRITS Protocol February 2002 %sp_inap_cgp.dtd; %sp_inap_ocp.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.4.9 Analyzed_Information ****** %sp_inap_acd.dtd; draft-gurbani-spirits-protocol-00.txt [Page 58] The SPIRITS Protocol February 2002 %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_dld.dtd; %sp_inap_fcd.dtd; %sp_inap_ocp.dtd; %sp_inap_pfx.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.4.10 Route_Select_Failure ****** %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_dld.dtd; %sp_inap_fcs.dtd; %sp_inap_ocp.dtd; %sp_inap_pfx.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.5 XML DTD's for INAP Terminating Detection Points draft-gurbani-spirits-protocol-00.txt [Page 59] The SPIRITS Protocol February 2002 This section presents the XML encoding for Information Flows (IFs) between the SCF and the SSF. The XML building blocks for common elements defined in section B.3 are used in the XML definitions here. B.5.1 Termination_Attempt_Authorized ****** %sp_inap_cdp.dtd; %sp_inap_cgp.dtd; %sp_inap_ocp.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.5.2 T_Busy ****** draft-gurbani-spirits-protocol-00.txt [Page 60] The SPIRITS Protocol February 2002 %sp_inap_bcs.dtd; %sp_inap_cdp.dtd; %sp_inap_ocp.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.5.3 Facility_Selected_and_Available ****** %sp_inap_cdp.dtd; %sp_inap_cgn.dtd; %sp_inap_ocp.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.5.4 T_No_Answer ****** %sp_inap_sai.dtd; %sp_inap_cdn.dtd; %sp_inap_cdp.dtd; %sp_inap_ocp.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.5.5 T_Answer ****** %sp_inap_sai.dtd; %sp_inap_cdn.dtd; %sp_inap_cdp.dtd ******** B.5.6 T_Midcall ****** %sp_inap_cdp.dtd; %sp_inap_cgp.dtd; %sp_inap_car.dtd; %sp_inap_fri.dtd ******** B.5.7 T_Disconnect ****** %sp_inap_cdp.dtd; %sp_inap_ctm.dtd; %sp_inap_rcs.dtd ******** B.6 XML encoding for IFs from the SCF to the SSF B.6.1 Analyse_Information ****** %sp_inap_cid.dtd; %sp_inap_dra.dtd; %sp_inap_csi.dtd; %sp_inap_cgn.dtd; %sp_inap_cdn.dtd; %sp_inap_car.dtd; %sp_inap_chn.dtd ******** B.6.2 Authorise_Termination ****** %sp_inap_cid.dtd; %sp_inap_cgn.dtd; %sp_inap_ocp.dtd; %sp_inap_lid.dtd ******** draft-gurbani-spirits-protocol-00.txt [Page 64] The SPIRITS Protocol February 2002 B.6.3 Collect_Information ****** %sp_inap_cid.dtd; %sp_inap_cgn.dtd; %sp_inap_cdn.dtd; %sp_inap_ocp.dtd ******** B.6.4 Connect ****** draft-gurbani-spirits-protocol-00.txt [Page 65] The SPIRITS Protocol February 2002 %sp_inap_cid.dtd; %sp_inap_dra.dtd; %sp_inap_fwc.dtd; %sp_inap_car.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd; %sp_inap_dyi.dtd; %sp_inap_chn.dtd; %sp_inap_csi.dtd ******** B.6.5 Continue ****** ******** B.6.6 Furnish_Charging_Information ****** %sp_inap_cid.dtd; %sp_inap_bcc.dtd draft-gurbani-spirits-protocol-00.txt [Page 66] The SPIRITS Protocol February 2002 ******** B.6.7 Hold_Call_In_Network ****** ******** B.6.8 Initiate_Call_Attempt ****** %sp_inap_cid.dtd; %sp_inap_ltc.dtd; %sp_inap_ncs.dtd; %sp_inap_dra.dtd ******** B.6.9 Release_Call ****** draft-gurbani-spirits-protocol-00.txt [Page 67] The SPIRITS Protocol February 2002 %sp_inap_cid.dtd; %sp_inap_ics.dtd; %sp_inap_acs.dtd; %sp_inap_xcs.dtd ******** B.6.10 Request_Notification_Charging_Event ****** %sp_inap_cid.dtd; %sp_inap_che.dtd ******** B.6.11 Request_Report_BCSM_Event ****** draft-gurbani-spirits-protocol-00.txt [Page 68] The SPIRITS Protocol February 2002 %sp_inap_cid.dtd; %sp_inap_evt.dtd ******** B.6.12 Trigger_Data_Status_Request ****** ******** B.7 Examples - XML encoded T_No_Answer 5 1 0 25 31356871684 31356872387 31356871424 AUTHORS' ADDRESSES Alec Brusilovsky Igor Faynberg Lucent Technologies, Inc. Lucent Technologies, Inc. 2000 Naperville Rd., 101 Crawfords Corner Rd., draft-gurbani-spirits-protocol-00.txt [Page 69] The SPIRITS Protocol February 2002 Naperville, IL 60566 Holmdel, NJ 07733 USA USA abrusilovsky@lucent.com faynberg@lucent.com Jorge Gato Vijay K. Gurbani Airtel Movil, S.A. 2000 Lucent Lane Avda de Europa, 1 Rm 6G-440 28108 Alcobendas (Madrid) Naperville, IL 60566 Spain USA jgato@airtel.es vkg@lucent.com Musa Unmehopa Kumar Vemuri Lucent Technologies, Inc. Lucent Technologies, Inc. Larenseweg 50, 2000 Naperville Rd., Postbus 1168 Naperville, IL 60566 1200 BD, Hilversum, USA The Netherlands vvkumar@lucent.com unmehopa@lucent.com ACRONYMS 3GPP Third Generation Partnership Project ASN.1 Abstract Syntax Notation One ASP Application Service Provider API Application Programming Interface BCSM Basic Call State Model CAMEL Customized Applications for Mobile Network Enhanced Logic CC Call Control CM Call Model CS Capability Set DN Directory Number DP Detection Point DTD Document Type Definition EDP Event Detection Point EDP-N Event Detection Point "Notification" EDP-R Event Detection Point "Request" GSTN Global Switched Telephone Network HTTP Hypertext Transfer Protocol IANA Internet Assigned Numbers Authority ICW Internet Call Waiting IE Information Element IDL Interface Definition Language IF Information Flow IN Intelligent Network INAP Intelligent Network Application Protocol IP Internet Protocol ISUP ISDN User Part (SS7 Protocol) draft-gurbani-spirits-protocol-00.txt [Page 70] The SPIRITS Protocol February 2002 ITU International Telecommunications Union MIME Multipurpose Internet Mail Extensions MP CC MultiParty Call Control OBCSM Originating Basic Call State Model PIC Point In Call PINT PSTN/Internet Interworking PSTN Public Switched Telephone Network SCF Service Control Function SCP Service Control Point SDP Session Description Protocol SIP Session Initiation Protocol SIP-T SIP for Telephones SPIRITS Services in the PSTN/IN Requesting InTernet Services SSF Service Switching Function SSP Service Switching Point STD State Transition Diagram TBCSM Terminating Basic Call State Model TDP Trigger Detection Point TDP-N Trigger Detection Point "Notification" TDP-R Trigger Detection Point "Request" XML Extensible Markup Language REFERENCES: [1] Informational RFC3136, "The SPIRITS Architecture", Slutsman, L (Ed.) [2] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [3] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent Network Standards: Their Application to Services", McGraw-Hill, 1997. [4] A. Brusilovsky et al, A Proposal for Internet Call Waiting Service using SIP, An Implementation Report, Expired IETF Internet Draft. [5] Adam Roach, SIP-Specific Event Notification, IETF I-D, Work in Progress, Expires August 2002 [6] Intelligent Network Capability Set 2. ITU-T, Recommendation Q.1228 [7] Distributed functional plane for intelligent network capability Set 2. ITU-T, Recommendation Q.1224, 09/97. [8] Recommendation Q.763 (12/99) - Signalling System No. 7 - ISDN draft-gurbani-spirits-protocol-00.txt [Page 71] The SPIRITS Protocol February 2002 user part formats and codes [9] Recommendation Q.931 (05/98) - ISDN user-network interface layer 3 specification for basic call control [10] I.Faynberg, et al, "SPIRITS Protocol Requirements", draft- ietf-spirits-reqs-04.txt, work in progress, February, 2001. [11] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", [12] Donald Eastlake, Joseph Reagle, David Solo at al., "XML- Signature Syntax and Processing", W3C Recommendation 12 February 2002, FULL COPYRIGHT STATEMENT "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. draft-gurbani-spirits-protocol-00.txt [Page 72]