On selection of IN parameters for the SPIRITS Protocol [Page 1] Internet Engineering Task Force SPIRITS WG Internet Draft draft-ietf-spirits-in-02.txt November 2001 Expires: May 2002 Authors: Alec Brusilovsky Elias Dacloush Musa Unmehopa (ed.) Kumar Vemuri (ed.) Ahmed Zaki Lucent Technologies Frans Haerens Alcatel Bell On selection of IN parameters to be carried by the SPIRITS Protocol draft-ietf-spirits-in-02.txt 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 INAP parameters (IN information and its encoding) which the SPIRITS protocol can transport from the PSTN into the IP network. The SPIRITS protocol is a protocol through which PSTN can request actions (services) to be carried out in the IP network in response to events occurring within the PSTN/IN. These services include, but are not limited to: Incoming Call Notification (Internet Call Waiting), Internet Caller-Id Delivery, and Internet Call Forwarding ("Follow Me"). This Internet-Draft has been written in response to the SPIRITS WG chairs' call for SPIRITS Protocol proposals. It may be viewed as being a direct November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 2] contribution to the RFC on the SPIRITS protocol. Among other contributions, this I-D is based on: o Informational RFC2995, "Pre-SPIRITS implementations" o SPIRITS Architecture, presented in draft-ietf-spirits-architecture-02, current candidate for Informational RFC o SPIRITS Protocol Requirements, presented in draft-ietf-spirits-reqs-01, current candidate for Informational RFC. 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 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 document describes how the SCP -based SPIRITS client may encode parameters from within the IN message into a format that may be readable by Internet elements that support the SPIRITS architecture. The authors wish to point out that in practice, the SPIRITS client may be hosted on the SCP, on an SSP, a Service Node, an Intelligent Peripheral, or some other such element. This document however looks specifically at the architecture described in [1] where the SCP is the element that hosts the SPIRITS client. IN messages are traditionally encoded in a protocol called INAP. This draft outlines, what INAP parameters are of immediate interest to SPIRITS, how they may be extracted and encoded for use within the SPIRITS domain. INAP is used as an example protocol to clarify the SPIRITS message encoding process. This draft is organized as follows: Section 2.0 presents a brief discussion of the Intelligent Network call model components of interest. In Section 3.0 we discuss briefly how the SIP [2] protocol may be employed in the Internet domain to encode and carry SPIRITS -related data elements. In other sections that follow, we present more IN and INAP specific details, common parameters with descriptions, and then templates for each detection point and related information. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 3] 1.1 Changes from previous version: 1. in version 01, we merged the old version of the document draft-ietf-spirits-in-00.txt with the draft draft-unmehopa-spirits-parameters-00.txt. Appendices C-F addressing Parlay support for the SPIRITS protocol were added. 2. in version 02 of the draft, we have made modifications to sections C.4.1.1, C.4.1.2 and D2 to better reflect the evolving nature of the various API standards referred to in the text, and to more clearly explain some of the Parlay/ OSA aspects. 1.2 Table Of Contents: Subject Page No. Main Sections: Abstract........................................... 1 1.0 Introduction....................................... 2 1.1 Changes from previous version...................... 3 1.2 Table of Contents.................................. 3 2.0 Brief description of working....................... 4 3.0 Brief SIP call flow overview for SPIRITS........... 6 4.0 IN-specific details................................ 8 4.1 Approaches for Encoding DP Information............. 9 4.2 Template Description and Procedure................. 9 4.3 SPIRITS Data and Encoding.......................... 10 5.0 Unresolved Issues.................................. 11 6.0 Security Considerations............................ 12 7.0 Future Work........................................ 12 8.0 Acknowledgements................................... 12 9.0 References......................................... 12 10.0 Authors' Addresses................................. 88 11.0 Acronyms........................................... 89 12.0 Full Copyright Statement........................... 90 Appendices: A INAP Parameters and Data Types..................... 13 A.1 Information Elements............................... 13 A.2 Commonly Used Parameters........................... 15 A.3 Error Codes........................................ 17 A.4 Detection Points, Triggers, Related Information.... 18 A.4.1 Originating Detection Points....................... 18 A.4.2 Terminating Detection Points....................... 23 A.5 SCF to SSF IFs..................................... 25 B XML DTD for IFs, Examples of use................... 28 B.1 Conventions........................................ 28 B.2 General DTD Syntax................................. 29 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 4] B.3 XML DTDs for INAP Information Elements............. 29 B.4 XML DTDs for INAP Originating Detection Points..... 45 B.5 XML DTD's for INAP Terminating Detection Points.... 51 B.6 XML encoding for IFs from the SCF to the SSF....... 54 B.7 Examples........................................... 60 C Supporting Parlay Interfaces....................... 60 C.1 Introduction....................................... 60 C.2 Introduction to the Parlay Call Control (CC) API... 61 C.3 Parlay and SPIRITS................................. 62 C.4 Details of the Parlay CC API....................... 63 C.4.1 Parlay MultiParty Call Leg Models.................. 63 D Parlay Methods and Data Types...................... 66 D.1 Details of Event Arming and Reporting in the MP CC API........................................... 66 D.2 Relation between Parlay and CAMEL.................. 68 D.3 Sample Message Flows............................... 70 E XML definitions for Parlay Encoding of SPIRITS Data............................................... 70 E.1 Terminology........................................ 70 E.2 Use of XML......................................... 70 E.3 Protocol Operations................................ 71 E.4 Common Element Definitions......................... 74 F Miscellaneous Parlay/SPIRITS Issues................ 86 F.1 Protocol Procedures................................ 86 F.2 Dynamic Events..................................... 86 F.3 Security Considerations for Parlay................. 87 F.4 Parlay-related Unresolved Issues/Items to be Done.. 88 2.0 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 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 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 5] 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. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 6] +--------------+ | 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. 3.0 Brief SIP call flow overview for SPIRITS A typical SPIRITS call flow proceeds as follows. As previously November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 7] described, when an SSF trigger fires during call processing, it formulates an INAP message and forwards it to the SCF. If the SCF is SPIRITS-capable, it then converts the contents of the INAP message into a semantically equivalent SPIRITS payload carried within the body of a SIP message. This SIP message is then forwarded via the SPIRITS gateway to other SPIRITS capable nodes in the IP domain. There are multiple ways in which this SIP-based interaction may proceed, depending on the kind of trigger supported and the service scenario. We refer to [4] for a simple example flow for Internet Call Waiting, a SPIRITS service. SPIRITS-capable IP nodes may use a SIP REGISTER message to specify a long-term binding and interest in messages from the PSTN domain. For instance, the dialup SIP end-point registers its IP address to DN binding with the SCF. Now, if a call comes in on the line being used by the dialup end-point, when the Termination Attempt Trigger fires and the SCF is so notified, the SCF may send a SIP INVITE to the SIP client on the dialup connection notifying the user of the call. The user may then choose to accept the call by generating the appropriate SIP response, in which case the dialup connection may be dropped and the call is put through. A similar call flow may be set up for other SPIRITS services where SIP events [5] mechanisms including SUBSCRIBE and NOTIFY messages are used instead for analogous functionality. In such scenarios, a SPIRITS-capable IP node would subscribe to a certain well-defined set of events with the SPIRITS-client co-located with the SCF, and subsequently NOTIFY messages encoded with call-related information would be sent to them. Response information may be encoded in 200 OK bodies. The REGISTER and INVITE messages may be used to support SPIRITS services which are invoked by TDPs, whereas the SUBSCRIBE and NOTIFY messages may be used to support services invoked at EDPs in PSTN call models. To understand why this is so, recall that TDPs are pre-provisioned, and statically armed, so the REGISTER and INVITE primitives are convenient signaling primitives to support those SPIRITS interactions, whereas EDPs being more dynamic in operation and how they are provisioned are better addressed through support for primitives that comprise the SIP Events infrastructure. This is generally recommended use of these primitive only, particular call flows may use one or the other sets of primitives to their advantage. Details are presented in [6] to be written. Using SIP is just one means of carrying SPIRITS information from the SCP (SCF in the Architecture diagram in figure 1) nodes to other SPIRITS-capable nodes. Other means may be employed for this as well, including using pure XML/HTTP (as opposed to XML-encoded content in SIP messages). SIP however, does seem an appealing option, given that a. most pre-SPIRITS implementations utilize SIP [7], and November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 8] b. PINT [8] already specifies SIP as the protocol of choice (and compatibility with PINT is one of the main requirements for the SPIRITS protocol). Several means were investigated for encoding SPIRITS information in SIP messages including: 1. encoding this information in a newly defined MIME type [9,10], 2. encoding this information with newly defined SDP [11] headers or SDP extensions, and 3. defining and using a new kind of description format (to be used in lieu of SDP). Some of these options are admittedly fairly inelegant. The first option suggested above seems to be a reasonable way to proceed. Further, since XML provides a convenient means of specifying and encoding this information, we assume that this data is XML-encoded, and specify a new MIME type "application/spxml". If this approach is accepted, this becomes an IANA consideration. (True, alternatively, one may carry INAP-related data in its original form in a manner analogous to how SIP-T carries ISUP parameters, but that is outside the scope of this current discussion). These and other SIP-related details as they pertain to the SPIRITS protocol will be addressed in [6], to be published. 4.0 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. In Appendices C-F, we present another means of encoding SPIRITS information, by making use of Parlay parameters. Parlay is a family of APIs defined by an industry consortium seeking to standardize a set of abstract high-level interfaces for use by third-party programmers so they may build November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 9] applications that leverage services and functionality exposed by networks of telecommunication elements. Parlay supports APIs for diverse areas such as call control, user location, user interaction, messaging etc., In Appendices C-F, we focus on the set of events supported by the Parlay call control API as they are directly relevant to the SPIRITS context. 4.1 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: a. 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. b. 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 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. 4.2 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 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 10] 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. 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 [12]. 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 [13] to determine the structure and content of the parameters in each of the messages. Look up Q.763 [14] and Q.931 [15] for more related information on data-types. Collect and collate this information into the above template. 4.3 SPIRITS Data and Encoding: In the Appendices that follow, as previously explained, 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: a. process the request locally (as is traditionally done today, no SPIRITS involvement), November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 11] b. 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, and c. 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 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 [16], section 3 page 5 for more. Note that [16] uses the term "persistent" to refer to call-related DP arming and associated inter- actions. 5.0 Unresolved Issues This section is meant to be a catch-all for any unresolved issues. Issues addressed in later versions of this draft will be marked as such. 5.1 Information pertaining to Wireless Specific (CAMEL) Standards, their encoding for transmission as SPIRITS parameters etc., may also have to be addressed. This draft is focused on INAP, if such a representation is required for CAMEL, it may be generated using procedures similar to those outlined above. 5.2 Mailing list discussions, rough technical consensus at the last two meetings, as well as SPIRITS Protocol Requirements document [16] name SIP as a choice for SPIRITS transport protocol. As their next step this group of authors will produce another I-D, focusing on SIP call flows for the SPIRITS context. 5.3 The authors were unable to find the parameters for the "Hold Call In Network", "Trigger Data Status Request", and "Continue" IFs used in the example presented in Appendix A, section A.5, items 5, 7 and 12. 5.4 Some nits and discrepancies between the XML format and the presented TCAP format, and within the TCAP format description sections may have November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 12] slipped through and will be addressed in future versions of this document. 6.0 Security Considerations The SPIRITS Architecture draft addresses security issues with the SPIRITS architecture (such as security requirements along interfaces B and C). This draft is primarily concerned with protocol conversions or translations for encoding of protocol parameters from the PSTN into a format that can be carried by SIP messages, and vice-versa. Since the PSTN network is assumed to be closed and therefore a well- controlled environment, and since this translation process is carried out on a PSTN network element, we assume that the protocol encoding process is not vulnerable to external attack, especially so if the SPIRITS client and the Service Control Function are co-located as depicted in figure 1. If said functional elements were not co-located, one would have to support security mechanisms for authentication, authorization, access control logging, and confidentiality, using any one of the well-defined, well- understood and tested techniques in wide-spread use today. 7.0 Future Work: a. May need to extend the example presented in Appendices A and B with IFs that would be useful for other SPIRITS services. b. Support for other protocols such as CAMEL etc., may need to be addressed. If so, procedure similar to those described in this document may be used. 8.0 Acknowledgements The authors are grateful to all participants in the SPIRITS WG for the discussion that has been shaping this work. We would also like to thank Hui-Lan Lu, Igor Faynberg, John Stanaway and Warren Montgomery for their time and insightful comments during the preparation of this I-D. 9.0 References [1] Slutsman, L (Ed.) et al, The Spirits Architecture, , Work in Progress. February 2001. [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. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 13] [4] A. Brusilovsky et al, A Proposal for Internet Call Waiting Service using SIP, An Implementation Report, Expired IETF Internet Draft. [5] A. Roach, Event Notification in SIP, , Work in Progress. October 2000. [6] A. Brusilovsky et al, The SPIRITS Protocol: SIP Aspects, IETF Internet Draft, To be written. [7] Lu, H. (Editor), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN- Initiated Services." RFC 2995, November 2000. [8] S. Petrack, and L. Conroy, The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services, Proposed Standard. RFC 2848, June 2000. [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [11] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998. [12] Intelligent Network Capability Set 2. ITU-T, Recommendation Q.1228 [13] Distributed functional plane for intelligent network capability Set 2. ITU-T, Recommendation Q.1224, 09/97. [14] Recommendation Q.763 (12/99) - Signalling System No. 7 - ISDN user part formats and codes [15] Recommendation Q.931 (05/98) - ISDN user-network interface layer 3 specification for basic call control [16] I.Faynberg, et al, "SPIRITS Protocol Requirements", draft-ietf-spirits-reqs-03.txt, work in progress, February, 2001. [17] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation: REC-xml-20001006, http://www.w3.org/TR/REC-xml [18] The Parlay Specifications, http://www.parlay.org/specs/index.asp [19] 3G TS 23.127 version 4.0.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Virtual November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 14] Home Environment" (Release 4) [20] 3G TS 29.198-04 version 4.0.0, "3rd Generation Partnership Project; Technical Specification Group Core Network; Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control" (Release 4) [21] 3G TR 29.998 v3.2.0 "3rd Generation Partnership Project; Technical Specification Group Core Network; Open Services Architecture; Application Programming Interface - Part 2" (Release 1999) [22] ISO 8601-1997, "Data elements and interchange formats - Information interchange - Representation of dates and times". [23] ETSI DocBox, SPAN 12 OPEN SERVICE ACCESS API, http://docbox.etsi.org/tech-org/span/Open/Span12/Overview.html 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. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 15] 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?). 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: November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 16] 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 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 call. 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 called party number in the November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 17] 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). 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). November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 18] 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. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 19] +--------->-----------+ | | | +-------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 | | +---+ | | | +---+ _Call | +-----+ O_Called_Party | | | +-V-+ | _Busy | November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 20] | | 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 3. O_Disconnect This operation signals a disconnect indication from the originating party, after a call was set up. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 21] 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 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 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 22] 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 Original Called Party ID originalCalledPartyID O Prefix - O Redirecting Party ID redirectingPartyID O Redirection Information redirectionInformation O DpSpecificCommonParameters CalledPartyNumber November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 23] 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 | | | | | | +---+ | | | | +-V-+ | | | +------->|30 | T_Answer | | | +---+ +-----+---+-----------+ | | +<---------|31 |<-----| 17. T_Active |------->+ | +---+ +---------------------+---+ | T_Conn.Failure | |32 | ^ | +---+ | +-V-+ | November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 24] |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 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 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 25] 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 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 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 26] 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 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. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 27] 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 Characterisics 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 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. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 28] 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 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. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 29] 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 ****** ******** B.3.2 AllCallSegments ****** ******** B.3.3 AssociatedCallSegment ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 30] ******** B.3.4 BCSMEvent ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 31] November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 32] November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 33] ( MidCallInfoType, MidCallReportType ) + > ******** B.3.5 BillingChargingCharacteristics ****** ******** B.3.6 BusyCause ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 34] ******** B.3.7 CalledPartyNumber ****** ******** B.3.8 CalledPartySubaddress ****** ******** B.3.9 CallID ****** ******** many-folks Expires January 2002 [Page 31] Internet-Draft INAP parameters for the SPIRITS protocol July, 2001 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 35] B.3.10 CallingPartyNumber ****** ******** B.3.11 CallingPartySubaddress ****** ******** B.3.12 CallSegmentID ****** ******** B.3.13 Carrier ****** ******** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 36] B.3.14 ChargeNumber ****** ******** B.3.15 ChargingEvent ****** %sp_inap_mon.dtd ******** B.3.16 ConnectTime ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 37] ******** B.3.17 DestinationRoutingAddress ****** many-folks Expires January 2002 [Page 33] Internet-Draft INAP parameters for the SPIRITS protocol July, 2001 %sp_inap_cdn.dtd ******** B.3.18 DialedDigits ****** ******** B.3.19 FailureCause ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 38] ******** B.3.20 DisplayInformation ****** ******** B.3.21 FeatureCode ****** ******** B.3.22 FeatureRequestIndicator ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 39] ******** B.3.23 ForwardingCondition ****** ******** B.3.24 InitiateCallSegment ****** ******** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 40] B.3.25 LegID ****** ******** B.3.26 LegToBeCreated ****** ******** B.3.27 MonitorMode ****** ******** B.3.28 NewCallSegment ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 41] ******** B.3.29 OriginalCalledPartyID ****** ******** B.3.30 Prefix ****** ******** B.3.31 RedirectingPartyID ****** ******** B.3.32 RedirectionInformation ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 42] ******** B.3.33 ReleaseCause ****** ******** B.3.34 ServiceAddressInformation ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 43] November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 44] ******** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 45] 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 ****** %sp_inap_csi.dtd; %sp_inap_rcs.dtd ******** B.4.2 O_Called_Party_Busy ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 46] %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 ******** 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 ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 47] RedirectingPartyID ?, RedirectionInformation ? ) > %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 ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 48] %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 ******** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 49] B.4.8 O_Answer ****** %sp_inap_cgp.dtd; %sp_inap_ocp.dtd; %sp_inap_rpi.dtd; %sp_inap_rin.dtd ******** B.4.9 Analyzed_Information ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 50] %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.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 ******** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 51] B.5 XML DTD's for INAP Terminating Detection Points 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 ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 52] %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 ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 53] RedirectionInformation ? ) > %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 ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 54] %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 ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 55] %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 ******** B.6.3 Collect_Information ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 56] ( CallID, CallingPartyNumber ?, CalledPartyNumber ?, OriginalCalledPartyID ?) > %sp_inap_cid.dtd; %sp_inap_cgn.dtd; %sp_inap_cdn.dtd; %sp_inap_ocp.dtd ******** B.6.4 Connect ****** %sp_inap_cid.dtd; %sp_inap_dra.dtd; %sp_inap_fwc.dtd; %sp_inap_car.dtd; November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 57] %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 ******** B.6.7 Hold_Call_In_Network ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 58] ******** 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 ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 59] %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 ****** %sp_inap_cid.dtd; %sp_inap_evt.dtd ******** B.6.12 Trigger_Data_Status_Request ****** November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 60] ******** B.7 Examples B.7.1 XML encoded T_No_Answer 5 1 0 25 31356871684 31356872387 31356871424 Appendix C: Supporting Parlay Interfaces C.1 Introduction: As previously stated, Parlay is a family of APIs defined by an industry consortium seeking to standardize a set of abstract high- level interfaces for use by third-party programmers so they may build applications that leverage services and functionality exposed by networks of telecommunication elements. Parlay supports APIs for diverse areas such as call control, user location, user interaction, messaging etc., In this appendix, we study issues related to Parlay encoding of IN parameters. Figure 4 depicts how third-party SPIRITS applications may be supported via Parlay. +--------------+ |3rd Party ASP | | IP Host | | | +--------------+ November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 61] |+-----------+ | | +----------+ | || Parlay | | B | | SPIRITS | | ||Application+<------/-------->+ Gateway | | |+-----------+ | Parlay API | +--------+-+ | +--------------+ +----------^---+ | IP Network | -----------------------------------------|---- PSTN / C | SIP {Parlay or INAP} v +----+------+ | SPIRITS | | Client | +-------------------+ +---+-----D-----+--+ | Service Switching |INAP/SS7 | Service Control | | Function +---------+ Function | +-------------------+ +------------------+ Figure 4: Supporting Parlay-based SPIRITS services. One debate that continues to rage in the industry today is that of protocols vs. APIs. In this section, we study how each of these approaches may be beneficial to the SPIRITS context if appropriately used. The Parlay API is a convenient means available to expose network hosted service capabilities to third party programmers. As depicted in figure 2, this API may be used to provide a means to more effectively program an application that uses SIP message capabilities to communicate with the SPIRITS client colocated with the SCP entity. Security aspects from the Parlay standpoint are covered by a third-party application's interaction with the Parlay framework component, which may be colocated with the SPIRITS gateway. The third-party application must first successfully complete a Parlay handshake involving aspects of mutual authentication, access control and service discovery before being permitted to gain access to network hosted services. The interested reader is referred to [3] for details. Although this document specifically uses Parlay as a base for the selection of INAP parameters to be carried by the SPIRITS Protocol, the ideas presented here are equally applicable to the Open Service Access (OSA) architecture and API as defined by the Third Generation Partnership Project (3GPP) [4]. C.2 Introduction to the Parlay Call Control (CC) API Parlay defines several interfaces for call control, each with its own specific set of functionality. More specifically, the set of Parlay November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 62] specifications includes interfaces for the following [20]: o Generic Call Control This interface provides simple means for controlling a call that only involves one originating and one terminating party. o MultiParty Call Control The MultiParty Call Control interface specifies an API that provides the ability to control and manage calls or sessions that involve two or more parties. Call leg manipulation functionality is offered by this interface and call events can be reported to the application for each specific call leg. o Multimedia Call Control Multimedia Call Control is a specialization of MultiParty Call Control in that it includes the concept of media channels associated with the legs in a call. o Conferencing Call Control This interface in turn is a specialization of the Multimedia Call Control interface. The interface provides functionality for bridging, splitting off parties from a multiparty call to form sub-conferences, etc. For each of these call control interfaces, the Parlay specification includes a Call Model (CM) in the form of a State Transition Diagram (STD). The STD represents the application view of the call, i.e. only call states observable by the application through the interface methods that are being invoked, are modelled by the CM. That implies that certain network call states are not visible to the application. For the remainder of this draft the focus will be on the MultiParty Call Control (MP CC) interface. Section C.4 will elaborate on this interface and study its functionality in greater detail. C.3 Parlay and SPIRITS The main body of this draft, along with material in appendices A and B describes how the SPIRITS protocol may be used to encode INAP parameters into the contents of a SIP message so that SPIRITS-capable elements may provide services to end-points in the PSTN. Appendices C-F build upon the discussion presented there, by describing how one might support Parlay-encoding of said parameters so that: a. applications providing SPIRITS services may conveniently be built to Parlay interfaces, and b. a common network protocol independent encoding of parameters may be exposed to SPIRITS applications via a widely supported third- party API such as Parlay. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 63] Note that while this appendix presents Parlay as the open API of choice, a similar mapping may be done to any other API of interest that gains in popularity. Specifically OSA as defined by 3GPP [4] is applicable here due to its similarities with Parlay. C.4 Details of the Parlay CC API In this section we study the MP CC API in greater detail, look at the method calls in each interface (as relevant), and the datatypes that are used (where we focus on the subset that is used in the XML Encoding that can be found in Appendices D and E). The MP CC API is made up of three interfaces, being the Call Control Manager interface, the Call interface, and the Call Leg interface. The Call Control Manager interface allows the application programmer to provide overload control functionality, create call objects and to request the enabling or disabling of call-related event notifications from the network. The Call interface provides the means for an application to control the routing of a specific call, to request information from the network for this call, control the charging of the call, to release the call and to perform time-based supervision for the call. Call leg manipulation is performed through the Call interface. The Call Leg interface represents a specific party in the call that is modeled by the Call interface. The application can use the Call Leg interface to request the network to be notified of leg specific events, such as for instance the fact that the originating party has disconnected from the call. C.4.1 Parlay MultiParty Call Leg Models Parlay has defined two call models, one for originating call legs and one for terminating call legs. The START and STOP state represent the instantiation and destruction of a call leg object. No events are reported in these states and no Parlay API methods can be invoked. For a more elaborate discussion on the call leg models the reader is referred to [20]. In the event a call leg object is relased by the Parlay application, the transition in the call mode is labelled "Release". In the event a call leg object is released by the SPIRITS gateway, the transition is labelled "NetworkRelease". In both cases the data value P_CALL_EVENT_RELEASE is used, see section 4.1.3. C.4.1.1 Parlay Call Model for Originating Call Legs In the INITIATING state a new call leg object has been created and the address of the originating party has been collected by the network. In the ANALYSING state additional digits to those already received November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 64] can be collected. Address analysis can commence upon completion of address collection. The ACTIVE state is entered when the address gas been analyzed. Mid call events can be received in the ACTIVE state. In the RELEASING state all the requested reports have been processed and sent to the application that had requested them. The eventReportReq method of the MultiParty Call Control interface can be invoked in any state, except for the RELEASING state. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 65] +-------+ | Start | +-------+ OriginatingCallAttemptAuthorized | +------+ | | | | NetworkRelease +--+------v--+ OriginatingCallAttempt | +-----------<-----| Initiating |--<---------------------------+ | +------------+ Orig.CallAttemptAuthorized | | | | | | | | v AddressCollected | | | | | AddressCollected | | | +-----+ | | | | | | | | | +--v--+-----+ | | +--+ | AddressCollected | +-----------<-----| Analysing |--<----------------------------+ | NetworkRelease | | | | +-----------+ | | | | | v AddressAnalysed | | +-----+ | | v | | | | | Originating | +-v------+ AddressAnalysed | | Service | | Active |----<----------------------------+ | Code | +-+------+ | | | | | | | +-----+ | | | | | +---------->-------+ v NetworkRelease | | | | Release +-v---------+ Originating Release | +---->----| Releasing |---<----------------------------+ | +-----------+ +------------+ | All States | +------------+ | | +------+ +---->------------------------| Stop | "call leg object deassigned" +------+ Figure 5: The Parlay Originating Call Leg Model November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 66] C.4.1.2 Parlay Call Model for Terminating Call Legs In the IDLE state the call object is created. In this state the call leg can be routed to a specified target address. For a description of the RELEASING state, the reader is referred to section 4.1.1. +-------+ | Start | +-------+ +------+ "call leg object created" | | Idle |-----<---------------------------+ +------+ | | | | | "call leg object routed" v | | | | | | TerminatingCallAttempt | | TerminatingCallAttemptAuthorised | | Alerting v | Answer | Term.CallAttemptAuthorised | TerminatingServiceCode | TerminatingServiceCode | Redirected | Answer +-------+ | Queued | Alerting | | | | Redirected | +-v------+ | Queued | | Active |----<---------------------------+ | +-+------+ | | | | | +-------+ | | v NetworkRelease | | | Release +-----------+ TerminatingRelease | +--->----| Releasing |--<---------------------------+ | +-----------+ +------------+ | All States | +------------+ | | +------+ +--->--------------------------| Stop | "call leg object deassigned" +------+ Figure 6: The Parlay Terminating Call Leg Model Appendix D: Parlay Methods and Data Types. D.1 Details of Event Arming and Reporting in the MP CC API November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 67] For the purpose of this internet draft the event enabling and reporting functionality is of specific interest. The functionality for static trigger arming and reporting is provided by the Call Control Manager interface of the MP CC API. The Call Leg interface includes the capabilities for the arming and reporting of the dynamic triggers. The means to arm static triggers is considered to be out of the scope of this SPIRITS draft. D.1.1 EventReportReq This Parlay method is used by the Parlay Application to set, clear or change the specific criteria for a dynamic event for a specific call leg. Only events that meet these criteria are reported. The parameter that is passed in this method to specify the set of requested events is defined as a sequence that consists of the following data types: CallEventType Defines a specific call, or call leg event report type. Examples include "address analyzed", "answer", and "release". CallMonitorMode Defines the mode that the call or call leg will monitor for events, or the mode that the call or call leg is in following a detected event. The supported monitor modes are "interrupt", "notify", and "do not monitor". AdditionalCallEventInfo Specifies additional call event information for certain types of events. For instance, for the "release" event, the specific release cause is specified, such as for instance "disconnect" or "routing failure". D.1.2 EventReportRes This Parlay method reports to the Parlay Application that an event has occurred that was requested to be reported. Depending on the type of the reported event, outstanding requests for events are discarded. For instance if the "answer" event is reported, the "routing failure" event can be disarmed. The parameters that are passed specify the reported event along with additional information regarding this reported event. These are the same parameters as specified for the EventReportReq method, with the addition of the time when the event occurred. CallEventType For description see section D.1 CallMonitorMode For description see section D.1 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 68] CallEventTime The date and time when the reported event occurred in the network. AdditionalCallEventInfo For description see section D.1 D.1.3 EventReportErr This Parlay method indicates to the Parlay Application that the request to manage call leg event reports was unsuccessful. The reason for the error is passed as a parameter, as well as the time when the error occurred. ErrorType Specifies the specific error that caused the request for call leg event reports to fail. E.g. when the request was issued for an invalid address. ErrorTime The date and time when the error occurred in the network. AdditionalErrorInfo Specifies additional error information for certain error types. For instance if the error was caused by an invalid address, the additional error information may specify the reason why this particular address was invalid. E.g. an incomplete address or an address out of range. D.1.4 ReportNotification This Parlay method notifies the Parlay Application of the arrival of a call-related or call leg-related static event. The event and the data associated with it are passed as a parameter. NotificationInfo Specifies the data associated with this static event. E.g. the originating or terminating leg which reports the notification. D.2 Relation between Parlay and CAMEL The Third Generation Partnership Project (3GPP) develops Intelligent Networking standards applicable to wireless networks. These wireless network IN standard specifications are known as Customised Applications for Mobile network Enhanced Logic, or CAMEL. The Call Models for CAMEL, although based on IN CS-1 and CS-2, are slightly different than the Basic Call State Models (BCSMs) for IN as specified by the ITU-T [13]. In [21] 3GPP have provided mappings for the CAMEL Originating BCSM states to the Parlay events. These CAMEL mappings are November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 69] provided here for illustrative purposes. +------------------------------------------------------------------+ | Originating BCSM States and corresponding Parlay Events | +--------------------------+---------------------------------------+ | O_Called_Party_Busy | P_CALL_EVENT_ORIGINATING_RELEASE | | | (P_BUSY) | | O_Disconnect | P_CALL_EVENT_ORIGINATING_RELEASE | | | (P_DISCONNECT) | | Collected_Information | P_CALL_EVENT_ADDRESS_COLLECTED | | Orig._Attempt_Authorized | P_CALL_EVENT_ORIG_CALL_ATTEMPT_AUTH * | | O_No_Answer | P_CALL_EVENT_ORIGINATING_RELEASE | | | (P_NO_ANSWER) | | O_MidCall | P_CALL_EVENT_ORIGINATING_SERVICE_CODE | | | (P_CALL_SERVICE_CODE_[?]) | | O_Answer | P_CALL_EVENT_ANSWER | | Analyzed_Information | P_CALL_EVENT_ADDRESS_ANALYZED | | Route_Select_Failure | P_CALL_EVENT_ORIGINATING_RELEASE | | | (P_ROUTING_FAILURE) | +--------------------------+---------------------------------------+ * full name is P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED Table 2: Map of O-BCSM States to Parlay events +--------------------------------------------------------------------+ | Terminating BCSM States and corresponding Parlay Events | +-------------------------------+------------------------------------+ | Termination_Attempt_Authorized| P_CALL_EVENT_TERM_CALL_ATMPT_AUTH *| | T_Abandon | P_CALL_EVENT_TERMINATING_RELEASE | | | (P_PREMATURE_DISCONNECT) | | T_Busy | P_CALL_EVENT_TERMINATING_RELEASE | | | (P_BUSY) | | T_No_Answer | P_CALL_EVENT_TERMINATING_RELEASE | | | (P_NO_ANSWER) | | T_Answer | P_CALL_EVENT_ANSWER | | T_MidCall | P_CALL_EVENT_TERM_SERVICE_CODE ^ | | | (P_CALL_SERVICE_CODE_[?]) | | T_Disconnect | P_CALL_EVENT_TERMINATING_RELEASE | | | (P_DISCONNECT) | +-------------------------------+------------------------------------+ * full name is P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED ^ full name is P_CALL_EVENT_TERMINATING_SERVICE_CODE Table 3: Map of T-BCSM States to Parlay events This map may be utilized by the SPIRITS client in converting any received INAP messages into the corresponding Parlay events for encoding into a SPIRITS-compliant format. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 70] D.3 Sample Message Flows As described in the main body of this draft, trigger detection points or TDPs associated with static triggers will be armed through the Service Management System, while event detection points or EDPs associated with dynamic triggers are armed through interactions between the SCF and the call processing element. In recommended SPIRITS operation, SIP messages such as the REGISTER-INVITE-200 OK [2] sequence are used to support static triggers, while the SUBSCRIBE-NOTIFY-200 OK [5] sequence is exchanged to support dynamic triggers. A more elaborate description of the usage of SIP for the SPIRITS protocol can be found in [16]. Note that in either case, where a Parlay-compliant solution is deployed, these messages are exchanged between the SPIRITS Client and the SPIRITS Gateway, with Parlay API methods being received at the Gateway, or call-back methods being invoked by the Gateway on the application (IpApp... interface) as necessary. Some more details of the call flows are presented in Appendix F. Appendix E: XML definitions for Parlay Encoding of SPIRITS Data E.1 Terminology Protocol Element - The XML DTD root element definition for a SPIRITS protocol operation. Common Element - The XML DTD element definition for common data types that are being used in the protocol element definitions. E.2 Use of XML As discussed in the main body of the draft, XML is a convenient means of encoding data relevant to the SPIRITS context. In the sections that follow, we show how XML may be used to encode Parlay parameters. E.2.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 protocol element DTD. The strings "******" and "******" denote the boundaries of an XML DTD. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 71] E.2.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" E.3 Protocol Operations E.3.1 Event Report Request ************************* %spirits_cet.dtd; %spirits_cmm.dtd; %spirits_aci.dtd *************************** E.3.1.1 Example of an Event Report Request E.3.2 Event Report Result ************************* November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 72] %spirits_cet.dtd; %spirits_cmm.dtd; %spirits_ctm.dtd; %spirits_aci.dtd *************************** E.3.2.1 Example of an Event Report Result 1998-12-04 10:30 E.3.3 Event Report Error ************************* November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 73] %spirits_etm.dtd; %spirits_etp.dtd; %spirits_aei.dtd *************************** E.3.3.1 Example of an Event Report Error 1998-12-04 10:30 E.3.4 Report Notification ************************* %spirits_nif.dtd *************************** E.3.4.1 Example of a Report Notification 31356871684 1800PIZZA November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 74] 1998-12-04 10:30 E.4 Common Element Definitions E.4.1 CallEventType ************************* November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 75] *************************** E.4.2 CallMonitorMode ************************* *************************** E.4.3 AdditionalCallEventInfo ************************* November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 76] November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 77] *************************** E.4.4 CallEventTime ************************* *************************** E.4.5 ErrorTime ************************* *************************** E.4.6 ErrorType ************************* *************************** E.4.7 AdditionalErrorInfo November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 78] ************************* *************************** E.4.8 Notification Info ************************* November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 79] November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 80] P_CALL_TELE_SERVICE_VIDEOTEX_SYN | P_CALL_TELE_SERVICE_VIDEOTEX_INT | P_CALL_TELE_SERVICE_TELEX | P_CALL_TELE_SERVICE_MHS | P_CALL_TELE_SERVICE_OSI | P_CALL_TELE_SERVICE_FTAM | P_CALL_TELE_SERVICE_VIDEO | P_CALL_TELE_SERVICE_VIDEO_CONF | P_CALL_TELE_SERVICE_AUDIOGRAPH_CONF | P_CALL_TELE_SERVICE_MULTIMEDIA | P_CALL_TELE_SERVICE_CS_INI_H221 | P_CALL_TELE_SERVICE_CS_SUB_H221 | P_CALL_TELE_SERVICE_CS_INI_CALL | P_CALL_TELE_SERVICE_DATATRAFFIC | P_CALL_TELE_SERVICE_EMERGENCY_CALLS | P_CALL_TELE_SERVICE_SMS_MT_PP | P_CALL_TELE_SERVICE_SMS_MO_PP | P_CALL_TELE_SERVICE_CELL_BROADCAST | P_CALL_TELE_SERVICE_ALT_SPEECH_FAX_3 | P_CALL_TELE_SERVICE_AUTOMATIC_FAX_3 | P_CALL_TELE_SERVICE_VOICE_GROUP_CALL | P_CALL_TELE_SERVICE_VOICE_BROADCAST ) > November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 81] November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 82] *************************** E.4.9 ADDRESS ************************* November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 83] *************************** E.4.10 The #PCDATA elements The #PCDATA elements for 'time' elements are described below: November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 84] The #PCDATA element for CALL_ALERTING_MECHANISM is described below: The #PCDATA element for CALL_APP_GENERIC_INFO is described below: The #PCDATA element for ADDRESS_STRING is described below: November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 85] The #PCDATA element for ADDRESS_NAME is described below: The #PCDATA element for SUB_ADDRESS_STRING is described below: The following table gives an overview of the format of the ADDRESS_STRING for the different values of ADDRESS_PLAN. Appendix F: Miscellaneous Parlay/SPIRITS Issues F.1 Protocol Procedures This section describes the SPIRITS protocol procedures. The SPIRITS November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 86] protocol defines the activities on the interfaces labeled 'C' in the SPIRITS architecture, depicted in figure 1. F.1.1 Static Events Static events are statically armed through service provisioning. It is outside the scope of the SPIRITS protocol how the provisioning takes place. A statically armed event remains armed until explicitly disarmed. The static event defined for the SPIRITS protocol is: + P_CALL_EVENT_CALL_ATTEMPT The Report Notification procedure is used when a static event is met to indicate to the SPIRITS server a request for instructions on how to complete the call. SPIRITS GATEWAY SPIRITS CLIENT | | |<----INVITE (REPORT_NOTIFICATION-)-------| | | | | | | |-----200 OK----------------------------->| | | Figure 5: Report Notification F.2 Dynamic Events An event is dynamically armed within the context of a call-associated IN service control relationship. This is achieved when suitable instructions are received by the switching element from the Service Control entity. The dynamic events defined for the SPIRITS protocol are: + P_CALL_EVENT_ADDRESS_COLLECTED + P_CALL_EVENT_ADDRESS_ANALYZED + P_CALL_EVENT_PROGRESS + P_CALL_EVENT_ALERTING + P_CALL_EVENT_ANSWER + P_CALL_EVENT_RELEASE + P_CALL_EVENT_REDIRECTED + P_CALL_EVENT_SERVICE_CODE The Event Report Request procedure is used to request the Service Switching Function, through the SPIRITS Gateway, to monitor for a call-related event. SPIRITS GATEWAY SPIRITS CLIENT November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 87] | | |-----SUBSCRIBE(EVENT_REPORT_REQUEST)---->| | | | | | | |<----200 OK------------------------------| | | Figure 6: Event Report Request The Event Report Result is used to notify the SPIRITS Server via the SPIRITS Gateway, that the requested call-related event has been detected. SPIRITS GATEWAY SPIRITS CLIENT | | |<----NOTIFY (EVENT_REPORT_RESULT)--------| | | | | | | |-----200 OK----------------------------->| | | Figure 7: Event Report Result The Event Report Error is used to indicate to the SPIRITS Server via the SPIRITS Gateway that the request to monitor for call-related events was unsuccessful. SPIRITS GATEWAY SPIRITS CLIENT | | |<----NOTIFY (EVENT_REPORT_ERROR)---------| | | | | | | |-----200 OK----------------------------->| | | Figure 8: Event Report Error F.3 Security Considerations for Parlay The Parlay Framework as described in the main body of the text, provides mutual authentication and application authorization support to third-party applications in this architecture. Note that this applies only to interface 'B' depicted in figures 1 and 2. Considerations similar to those discussed in the security considerations section in the main body of this draft are still applicable for security November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 88] along interface 'C'." F.4 Parlay-related Unresolved Issues/Items to be Done This section is intended to be a general clause for any unresolved issues and items that can be considered for inclusion in later versions. F.4.1 XML DTDs for Call Routing The current document presents XML DTDs for the encoding of Parlay parameters for dynamic event reporting and static event notification. Currently no XML DTDs have been included for the IN operations that can be executed as a result of event notifications. The Parlay equivalent for these IN operations include the routeReq method. A subsequent version of this document will include XML DTD definitions for these operations as well. F.4.2 XML DTD Generation The ETSI organization publishes and maintains a UML source model for all of the OSA and Parlay API interfaces [23]. This source is used to extract documentation and to generate the API specification in the form of Interface Definition Language (IDL) files. A similar exercise should be considered for the generation of the XML DTDs presented in this document. 10.0 Authors' Addresses Alec Brusilovsky, Elias Dacloush Lucent Technologies, Lucent Technologies, 263 Shuman Blvd. 1960 Lucent Lane Naperville, IL 60566 Naperville, IL 60566 USA. USA. abrusilovsky@lucent.com elias@lucent.com Frans Haerens Musa Unmehopa Alcatel Bell Lucent Technologies, Francis Welles Plein, Larenseweg 50, B-2080 Antwerp Postbus 1168 Belgium 1200 BD, Hilversum, frans.haerens@alcatel.be The Netherlands unmehopa@lucent.com Kumar Vemuri, Ahmed Zaki Lucent Technologies, Lucent Technologies, 263 Shuman Blvd. 1960 Lucent Lane Naperville, IL 60566 Naperville, IL 60566 USA. USA. November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 89] vvkumar@lucent.com ahmedzaki@lucent.com 11.0 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) 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 November 2001 Expires May 2002 On selection of IN parameters for the SPIRITS Protocol [Page 90] TDP-N Trigger Detection Point "Notification" TDP-R Trigger Detection Point "Request" XML Extensible Markup Language 12.0 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. November 2001 Expires May 2002