Internet Engineering Task Force SPIRITS WG INTERNET DRAFT draft-unmehopa-spirits-parameters-00.txt July 12, 2001 Expires: Januari 2002 Authors: Musa Unmehopa Kumar Vemuri Lucent Technologies On selection of IN parameters to be carried by the SPIRITS Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Parlay parameters (appropriately encoded Parlay Events, generated by the PSTN) which the SPIRITS protocol can transport from the PSTN into the IP network, and vice versa. These parameters are PARLAY equivalents of INAP parameters described in [1]. 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 (IN Triggers) 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"). The proposal to support the encoding of Parlay events within the SPIRITS context enables Parlay compliant applications to interact with SPIRITS elements within the IP network, and thereby provide SPIRITS services. This also simultaneously facilitates the development of SPIRITS services by third-party application programmers who build to well-defined Parlay interfaces. M.Unmehopa, K.Vemuri [Page 1] Internet Draft SPIRITS parameters July 11, 2001 TABLE OF CONTENTS (sub-sections not listed). Subject Page No. Abstract..................................................1 1.0 Introduction..............................................2 2.0 Introduction to the Parlay Call Control (CC) API..........6 3.0 Parlay and SPIRITS........................................7 4.0 Details of the Parlay CC API..............................7 5.0 Sample Message Flows.....................................13 6.0 Terminology..............................................14 7.0 Use of XML...............................................14 8.0 Protocol Operations......................................15 9.0 Common Element Definitions...............................16 10.0 Protocol Procedures......................................28 11.0 Security Considerations..................................30 12.0 Unresolved Issues/Items to be Done.......................30 13.0 Acknowledgments..........................................31 14.0 References...............................................31 15.0 Acronyms.................................................32 16.0 Authors' Addresses.......................................32 M.Unmehopa, K.Vemuri [Page 2] Internet Draft SPIRITS parameters July 11, 2001 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 [2] 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 easily read and interpreted by Internet elements that support Parlay interfaces. 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 [2] where the SCP is the element that hosts the SPIRITS client. Furthermore, in addition to performing the INAP to Parlay translation at the SPIRITS client, as presented in this document, the translation may also be done at the SPIRITS gateway. 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 in a Parlay format, so that Parlay-compliant applications can more easily provide SPIRITS services. INAP is used as an example protocol from the PSTN to clarify the SPIRITS message encoding process. M.Unmehopa, K.Vemuri [Page 3] Internet Draft SPIRITS parameters July 11, 2001 +--------------+ | 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 Telephone Figure 1: SPIRITS Architecture The SPIRITS protocol defines the activities on the interfaces labeled 'B' and 'C' in the SPIRITS architecture, depicted in figure 1 above. The protocol is designed for secure transport of IN trigger information (requests for actions, as well as plain event notifications, including parameters) from PSTN/IN to the IP network, and optional responses from the IP network back to the PSTN/IN. 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 draft, we focus on the set of events supported by the Parlay call control API as they are directly relevant to the SPIRITS context. M.Unmehopa, K.Vemuri [Page 4] Internet Draft SPIRITS parameters July 11, 2001 Figure 2 depicts how third-party SPIRITS applications may be supported via Parlay. +--------------+ |3rd Party ASP | | IP Host | | | +--------------+ |+-----------+ | | +----------+ | || 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 2: 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]. M.Unmehopa, K.Vemuri [Page 5] Internet Draft SPIRITS parameters July 11, 2001 This draft is organized as follows: Section 2 presents a brief introduction to the Parlay Call Control API. Section 3 talks about the Parlay standards specification how it may relate to the SPIRITS protocol. Section 4 presents some more details of the Parlay CC API. Section 5 addresses basic message flow issues, while section 6 presents the terminology relevant to this context. The next few sections (7 through 9) in this document are dedicated to XML encoding considerations. Section 10 discusses protocol procedures. Section 11 provides some security considerations. The draft ends with Acknowledgments, References, Acronyms, and Author's Addresses. 1.1 Changes from previous version: As this is version 00 of this document, there are no changes to report here at this time. 2.0 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 specifications includes interfaces for the following [5]: 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. M.Unmehopa, K.Vemuri [Page 6] Internet Draft SPIRITS parameters July 11, 2001 For the remainder of this draft the focus will be on the MultiParty Call Control (MP CC) interface. Section 4.0 will elaborate on this interface and study its functionality in greater detail. 3.0 Parlay and SPIRITS Draft [1] 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. This document builds 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. Note that while this draft selects 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. 4.0 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 the Appendix). 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. 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. M.Unmehopa, K.Vemuri [Page 7] Internet Draft SPIRITS parameters July 11, 2001 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 [5]. 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. 4.1.1 Parlay Call Model for Originating Call Legs In the INITIATING state a new call leg obect 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 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. M.Unmehopa, K.Vemuri [Page 8] Internet Draft SPIRITS parameters July 11, 2001 +-------+ | Start | +-------+ OriginatingCallAttemptAuthorized | +------+ | | | | NetworkRelease +--+------v--+ OriginatingCallAttempt | +---------->-----| Initiating |--<----------------------------+ | +------------+ Orig.CallAttemptAuthorized | | | | | v AddressCollected | | | | | NetworkRelease +-----------+ AddressCollected | +---------->-----| Analysing |--<-----------------------------+ | +-----------+ | | | | | v AddressAnalysed | | +-------+ | | v | | | | | MidCall | +-v------+ AddressAnalysed | | | | Active |---->-----------------------------+ | | +-+------+ | | | | | | | +-------+ | | | | | +--------->-------+ v NetworkRelease | | | | Release +-v---------+ Release | +---->----| Releasing |---<-----------------------------+ | +-----------+ +------------+ | All States | +------------+ | | +------+ +---->------------------------| Stop | "call leg object deassigned" +------+ Figure 3: The Parlay Originating Call Leg Model 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. M.Unmehopa, K.Vemuri [Page 9] Internet Draft SPIRITS parameters July 11, 2001 +-------+ | Start | +-------+ +------+ "call leg object created" | | Idle |-----<--------------------------------+ +------+ | | Answer | v Alerting | | TerminatingCallAttemptAuthorised | +-------+ | Answer | | | | Alerting | MidCall | +-v------+ TerminatingCallAttempt | | | Active |----<--------------------------------+ | +-+------+ TerminatingCallAttemptAuthorised | | | | | +-------+ | | v NetworkRelease | | | Release +-----------+ Release | +--->----| Releasing |--<--------------------------------+ | +-----------+ +------------+ | All States | +------------+ | | +------+ +--->--------------------------| Stop | "call leg object deassigned" +------+ Figure 4: The Parlay Terminating Call Leg Model 4.1.3 Mapping of CM events to event data types The following table shows the specific values of the Parlay CALL_EVENT_TYPE data type and how they map to the events that are reported in the call leg call models. +-------------------------------------------------------------+ | Call Model Events and Parlay Event Data Types | +--------------------------------+----------------------------+ | P_CALL_EVENT_CALL_ATTEMPT | OriginatingCallAttempt | | | TerminatingCallAttempt | | P_CALL_EVENT_ADDRESS_COLLECTED | AddressCollected | | | Orig.CallAttemptAuthorized | | | Term.CallAttemptAuthorized | | P_CALL_EVENT_ADDRESS_ANALYZED | AddressAnalysed | | P_CALL_EVENT_ALERTING | Alerting | | P_CALL_EVENT_ANSWER | Answer | | P_CALL_EVENT_SERVICE_CODE | MidCall | | P_CALL_EVENT_RELEASE | Release | | | NetworkRelease | +--------------------------------+----------------------------+ Table 1: Map of Call Model Events to Parlay Data Types M.Unmehopa, K.Vemuri [Page 10] Internet Draft SPIRITS parameters July 11, 2001 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. 4.2 Details of Event Arming and Reporting in the MP CC API 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. 4.2.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". 4.2.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 4.2.1 M.Unmehopa, K.Vemuri [Page 11] Internet Draft SPIRITS parameters July 11, 2001 CallMonitorMode For description see section 4.2.1 CallEventTime The date and time when the reported event occurred in the network. AdditionalCallEventInfo For description see section 4.2.1 4.2.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. 4.2.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. 4.3 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 UTI-T [6]. In [7] 3GPP have provided mappings for the CAMEL Originating BCSM states to the Parlay events. These CAMEL mappings are provided here for illustrative purposes. M.Unmehopa, K.Vemuri [Page 12] Internet Draft SPIRITS parameters July 11, 2001 +--------------------------------------------------------------------+ | Originating BCSM States and corresponding Parlay Events | +-----------------------------+--------------------------------------+ | O_Called_Party_Busy | P_CALL_EVENT_RELEASE (P_BUSY) | | O_Disconnect | P_CALL_EVENT_RELEASE (P_DISCONNECT) | | Collected_Information | P_CALL_EVENT_ADDRESS_COLLECTED | | Orig._Attempt_Authorized | P_CALL_EVENT_ADDRESS_ANALYZED | | O_No_Answer | P_CALL_EVENT_RELEASE (P_NO_ANSWER) | | O_MidCall | P_CALL_EVENT_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_RELEASE | | | (P_ROUTING_FAILURE) | +-----------------------------+--------------------------------------+ Table 2: Map of O-BCSM States to Parlay events +--------------------------------------------------------------------+ | Terminating BCSM States and corresponding Parlay Events | +-------------------------------+------------------------------------+ | Termination_Attempt_Authorized| P_CALL_EVENT_ADDRESS_COLLECTED | | T_Abandon | P_CALL_EVENT_RELEASE | | | (P_PREMATURE_DISCONNECT) | | T_Busy | P_CALL_EVENT_RELEASE (P_BUSY) | | T_No_Answer | P_CALL_EVENT_RELEASE (P_NO_ANSWER) | | T_Answer | P_CALL_EVENT_ANSWER | | T_MidCall | P_CALL_EVENT_SERVICE_CODE | | | (P_CALL_SERVICE_CODE_[?]) | | T_Disconnect | P_CALL_EVENT_RELEASE (P_DISCONNECT)| +-------------------------------+------------------------------------+ Table 3: Map of T-BCSM States to Parlay events The distinction between originating and terminating triggers (e.g. T_Answer and O_Answer) in the Parlay mapping can be made based on the callLegSessionID parameter value [7]. 5.0 Sample Message Flows As described in [1] (the SPIRITS/XML 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 [8] sequence are used to support static triggers, while the SUBSCRIBE-NOTIFY-200 OK [9] sequence is exchanged to support dynamic triggers. A more elaborate description of the usage of SIP for the SPIRITS protocol can be found in [10]. Note that in either case, where a Parlay-compliant solution is deployed, these messages are exchanged between the SPIRITS Client and the SPIRITS M.Unmehopa, K.Vemuri [Page 13] Internet Draft SPIRITS parameters July 11, 2001 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 section 10. 6.0 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. 7.0 Use of XML As discussed in [1], 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. 7.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 [11]. 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. 7.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" M.Unmehopa, K.Vemuri [Page 14] Internet Draft SPIRITS parameters July 11, 2001 8. Protocol Operations 8.1 Event Report Request ************************* %spirits_cet.dtd; %spirits_cmm.dtd; %spirits_aci.dtd *************************** 8.1.1 Example of an Event Report Request 8.2 Event Report Result ************************* M.Unmehopa, K.Vemuri [Page 15] Internet Draft SPIRITS parameters July 11, 2001 %spirits_cet.dtd; %spirits_cmm.dtd; %spirits_ctm.dtd; %spirits_aci.dtd *************************** 8.2.1 Example of an Event Report Result 1998-12-04 10:30 8.3 Event Report Error ************************* %spirits_etm.dtd; %spirits_etp.dtd; %spirits_aei.dtd *************************** 8.3.1 Example of an Event Report Error 1998-12-04 10:30 M.Unmehopa, K.Vemuri [Page 16] Internet Draft SPIRITS parameters July 11, 2001 8.4 Report Notification ************************* %spirits_nif.dtd *************************** 8.4.1 Example of a Report Notification 31356871684 1800PIZZA 1998-12-04 10:30 M.Unmehopa, K.Vemuri [Page 17] Internet Draft SPIRITS parameters July 11, 2001 9 Common Element Definitions 9.1 CallEventType ************************* *************************** 9.2 CallMonitorMode ************************* *************************** 9.3 AdditionalCallEventInfo ************************* M.Unmehopa, K.Vemuri [Page 18] Internet Draft SPIRITS parameters July 11, 2001 *************************** 9.4 CallEventTime ************************* *************************** 9.5 ErrorTime ************************* *************************** M.Unmehopa, K.Vemuri [Page 20] Internet Draft SPIRITS parameters July 11, 2001 9.6 ErrorType ************************* *************************** 9.7 AdditionalErrorInfo ************************* M.Unmehopa, K.Vemuri [Page 21] Internet Draft SPIRITS parameters July 11, 2001 *************************** 9.8 Notification Info ************************* M.Unmehopa, K.Vemuri [Page 24] Internet Draft SPIRITS parameters July 11, 2001 *************************** 9.9 ADDRESS ************************* M.Unmehopa, K.Vemuri [Page 25] Internet Draft SPIRITS parameters July 11, 2001 *************************** 9.10 The #PCDATA elements The #PCDATA elements for 'time' elements are described below: M.Unmehopa, K.Vemuri [Page 26] Internet Draft SPIRITS parameters July 11, 2001 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: M.Unmehopa, K.Vemuri [Page 27] Internet Draft SPIRITS parameters July 11, 2001 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. 10. Protocol Procedures This section describes the SPIRITS protocol procedures. The SPIRITS protocol defines the activities on the interfaces labeled 'C' in the SPIRITS architecture, depicted in figure 1. 10.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 M.Unmehopa, K.Vemuri [Page 28] Internet Draft SPIRITS parameters July 11, 2001 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 10.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 | | |-----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. M.Unmehopa, K.Vemuri [Page 29] Internet Draft SPIRITS parameters July 11, 2001 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 11. Security Considerations 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 [1] are applicable for security along interface 'C'." 12.0 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. 12.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. M.Unmehopa, K.Vemuri [Page 30] Internet Draft SPIRITS parameters July 11, 2001 12.2 XML DTD Generation The ETSI organization publishes and maintains a UML source model for all of the OSA and Parlay API interfaces [13]. 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. 13. Acknowledgments The authors would like to thank Alec Brusilovsky, Igor Faynberg and John Stanaway for their valuable comments and input. 14. References [1] Brusilovsky, A., E. Dacloush, F. Haerens, M. Unmehopa, K. Vemuri, A. Zaki, "INAP parameters for the SPIRITS protocol", draft-ietf-spirits-IN-00.txt, work in progress, expires November 2001. [2] Slutsman, L (Ed.) et al, The Spirits Architecture, , Work in Progress. February 2001. [3] The Parlay Specifications, http://www.parlay.org/specs/index.asp [4] 3G TS 23.127 version 4.0.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Virtual Home Environment" (Release 4) [5] 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) [6] Distributed functional plane for intelligent network Capability Set 2. ITU-T, Recommendation Q.1224, 09/97. [7] 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) [8] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [9] A. Roach, "Event Notification in SIP", , work in progress. October 2000. [10] Faynberg, I., J. Gato, H. Lu, L. Slutsman, "SPIRITS Protocol Requirements" , work in progress, expires November 2001. M.Unmehopa, K.Vemuri [Page 31] Internet Draft SPIRITS parameters July 11, 2001 [11] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation: REC-xml-20001006, http://www.w3.org/TR/REC-xml [12] ISO 8601-1997, "Data elements and interchange formats - Information interchange - Representation of dates and times". [13] ETSI DocBox, SPAN 12 OPEN SERVICE ACCESS API, http://docbox.etsi.org/tech-org/span/Open/Span12/Overview.html 15. Acronyms 3GPP Third Generation Partnership Project API Application Programming Interface ASP Application Service Provider BCSM Basic Call State Model CAMEL Customised Applications for Mobile network Enhanced Logic CC Call Control CM Call Model CS Capability Set DTD Document Type Definition EDP Event Detection Point GSTN General Switched Telephone Network IDL Interface Definition Language INAP Intelligent Network Application Part IN Intelligent Network IP Internet Protocol MP CC MultiParty Call Control PINT PSTN/Internet Interworking PSTN Public Switched Telephone Network SCP Service Control Point SPIRITS Services in the PSTN/IN Requesting InTernet Services SSP Service Switching Point STD State Transition Diagram TDP Trigger Detection Point XML Extensible Markup Language 16. Authors' Addresses Musa Unmehopa, Kumar Vemuri, Lucent Technologies, Lucent Technologies, Larenseweg 50. 263 Shuman Blvd. P.O.Box 1168 Naperville, IL 60566 1200 BD Hilversum USA. The Netherlands. vvkumar@lucent.com unmehopa@lucent.com Full Copyright Statement Copyright (C) The Internet Society (1998). 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 M.Unmehopa, K.Vemuri [Page 32] Internet Draft SPIRITS parameters July 11, 2001 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 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. M.Unmehopa, K.Vemuri [Page 33]