idnits 2.17.1 draft-ietf-spirits-in-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 150 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 275 instances of too long lines in the document, the longest one being 49 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1364 has weird spacing: '...Address des...' == Line 1404 has weird spacing: '...Address des...' == Line 4294 has weird spacing: '... mmm thr...' == Line 4471 has weird spacing: '...alidate the X...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8198 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 313, but not defined -- Looks like a reference, but probably isn't: 'REF' on line 4621 == Unused Reference: '18' is defined on line 703, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 705, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Unexpected draft version: The latest known version of draft-gurbani-spirits-protocol is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 2995 (ref. '7') ** Obsolete normative reference: RFC 2327 (ref. '11') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' == Outdated reference: A later version (-04) exists of draft-ietf-spirits-reqs-03 ** Downref: Normative reference to an Informational draft: draft-ietf-spirits-reqs (ref. '16') -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SPIRITS WG 3 Internet Draft 4 draft-ietf-spirits-in-03.txt 5 November 2001 6 Expires: January 2003 Authors: 7 Musa Unmehopa (ed.) 8 Kumar Vemuri (ed.) 9 Alec Brusilovsky 10 Elias Dacloush 11 Ahmed Zaki 12 Lucent Technologies 14 Frans Haerens 15 Alcatel Bell 17 John-Luc Bakker 18 Telcordia 20 Bruno Chatras 21 France Telecom 23 Janusz Dobrowolski 24 StateSoft 26 On selection of IN parameters to be carried by the SPIRITS Protocol 27 draft-ietf-spirits-in-03.txt 29 Status of this Memo 31 This document is an Internet-Draft and is in full conformance with all 32 provisions of Section 10 of RFC2026. 34 Internet-Drafts are working documents of the Internet Engineering Task 35 Force (IETF), its areas, and its working groups. Note that other groups 36 may also distribute working documents as Internet-Drafts. Internet 37 -Drafts are draft documents valid for a maximum of six months and may be 38 updated, replaced, or obsoleted by other documents at any time. It is 39 inappropriate to use Internet-Drafts as reference material or to cite 40 them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Abstract 50 This document describes INAP parameters (IN information and its encoding) 52 July 2002 Expires Jan 2003 54 which the SPIRITS protocol can transport from the PSTN into the IP network. 55 The SPIRITS protocol is a protocol through which PSTN can request actions 56 (services) to be carried out in the IP network in response to events 57 occurring within the PSTN/IN. These services include, but are not limited 58 to: Incoming Call Notification (Internet Call Waiting), Internet 59 Caller-Id Delivery, and Internet Call Forwarding ("Follow Me"). 61 This draft outlines, what INAP parameters are of immediate interest 62 to SPIRITS, how they may be extracted and encoded for use within 63 the SPIRITS domain. INAP is used as an example protocol to 64 clarify the SPIRITS message encoding process. 66 This Internet-Draft has been written in response to the SPIRITS WG chairs' 67 call for SPIRITS Protocol proposals. It may be viewed as being a direct 68 contribution to the Informational RFC on the SPIRITS protocol parameters. 69 Among other contributions, this I-D is based on: 71 o Informational RFC2995, "Pre-SPIRITS implementations" 72 o SPIRITS Architecture, presented in draft-ietf-spirits-architecture-02, 73 RFC 3136 74 o SPIRITS Protocol Requirements, presented in draft-ietf-spirits-reqs-04, 75 current candidate for Informational RFC. 77 1.0 Introduction: 79 SPIRITS (Services in the PSTN Requesting InTernet Services) is an 80 IETF architecture and associated protocol that enables call processing 81 elements in the telephone network such as the PSTN/GSTN to make service 82 requests that are then processed on Internet hosted servers. 84 The PSTN today supports service models such as the Intelligent Network, 85 whereby some features are executed locally on switching elements 86 (called SSPs or Service Switching Points) themselves, and other 87 features are executed on service elements called SCPs (or Service 88 Control Points). The SPIRITS architecture [1] permits these 89 SCP elements to act as intelligent proxies to leverage and use 90 Internet nodes and capabilities to further enhance the telephone 91 end-user's experience. 93 This document describes how the SCP -based SPIRITS client may 94 encode parameters from within the IN message into a format that 95 may be readable by Internet elements that support the SPIRITS 96 architecture. The authors wish to point out that in practice, the 97 SPIRITS client may be hosted on the SCP, on an SSP, a Service Node, 98 an Intelligent Peripheral, or some other such element. This document 99 however looks specifically at the architecture described in [1] where 100 the SCP is the element that hosts the SPIRITS client. 102 IN messages are traditionally encoded in a protocol called INAP. 104 July 2002 Expires Jan 2003 106 This draft outlines, what INAP parameters are of immediate interest 107 to SPIRITS, how they may be extracted and encoded for use within 108 the SPIRITS domain. INAP is used as an example protocol to 109 clarify the SPIRITS message encoding process. 111 This draft is organized as follows: Section 2.0 presents a brief 112 discussion of the Intelligent Network call model components 113 of interest. In Section 3.0 we discuss briefly how the SIP [2] protocol 114 may be employed in the Internet domain to encode and carry SPIRITS 115 -related data elements. In other sections that follow, we present 116 more IN and INAP specific details, common parameters with descriptions, 117 and then templates for each detection point and related information. 119 Finally, for those interested in Parlay/OSA interfaces, we also provide 120 a set of appendices that cover the mapping of parameters from those 121 domains onto the SPIRITS protocol. 123 1.1 Changes from previous version: 125 1. in version 01, we merged the old version of the document 126 draft-ietf-spirits-in-00.txt with the draft 127 draft-unmehopa-spirits-parameters-00.txt. Appendices C-F 128 addressing Parlay support for the SPIRITS protocol were 129 added. 131 2. in version 02 of the draft, we have made modifications to 132 sections C.4.1.1, C.4.1.2 and D2 to better reflect the 133 evolving nature of the various API standards referred to 134 in the text, and to more clearly explain some of the Parlay/ 135 OSA aspects. 137 3. in version 03 of the draft, we have added appendix F that 138 lists INAP XSD representations of the supported data types 139 and have moved the other appendices down a letter. We have 140 also updated the section on "Open Issues" in section G.4, 141 and fixed errors in earlier versions of appendices B and E. 142 John-Luc Bakker, Bruno Chatras and Janusz Dobrowolski were 143 added to the list of authors in this version. 145 1.2 Table Of Contents: 146 Subject Page No. 148 Main Sections: 149 Abstract........................................... 1 150 1.0 Introduction....................................... 2 151 1.1 Changes from previous version...................... 3 152 1.2 Table of Contents.................................. 3 153 2.0 Brief description of working....................... 5 154 3.0 Brief SIP call flow overview for SPIRITS........... 7 156 July 2002 Expires Jan 2003 158 4.0 IN-specific details................................ 9 159 4.1 Approaches for Encoding DP Information............. 10 160 4.2 Template Description and Procedure................. 10 161 4.3 SPIRITS Data and Encoding.......................... 11 162 5.0 Unresolved Issues.................................. 12 163 6.0 Security Considerations............................ 13 164 7.0 Future Work........................................ 13 165 8.0 Acknowledgements................................... 13 166 9.0 References......................................... 14 167 10.0 Authors' Addresses................................. 146 168 11.0 Acronyms........................................... 147 169 12.0 Full Copyright Statement........................... 147 171 Appendices: 172 A INAP Parameters and Data Types..................... 15 173 A.1 Information Elements............................... 15 174 A.2 Commonly Used Parameters........................... 17 175 A.3 Error Codes........................................ 18 176 A.4 Detection Points, Triggers, Related Information.... 19 177 A.4.1 Originating Detection Points....................... 19 178 A.4.2 Terminating Detection Points....................... 24 179 A.5 SCF to SSF IFs..................................... 26 180 B XML DTD for IFs, Examples of use................... 29 181 B.1 Conventions........................................ 29 182 B.2 General DTD Syntax................................. 30 183 B.3 XML DTDs for INAP Information Elements............. 30 184 B.4 XML DTDs for INAP Originating Detection Points..... 45 185 B.5 XML DTD's for INAP Terminating Detection Points.... 51 186 B.6 XML encoding for IFs from the SCF to the SSF....... 54 187 B.7 Examples........................................... 60 188 C Supporting Parlay Interfaces....................... 60 189 C.1 Introduction....................................... 60 190 C.2 Introduction to the Parlay Call Control (CC) API... 62 191 C.3 Parlay and SPIRITS................................. 62 192 C.4 Details of the Parlay CC API....................... 63 193 C.4.1 Parlay MultiParty Call Leg Models.................. 63 194 D Parlay Methods and Data Types...................... 66 195 D.1 Details of Event Arming and Reporting in the MP 196 CC API........................................... 66 197 D.2 Relation between Parlay and CAMEL.................. 68 198 D.3 Sample Message Flows............................... 70 199 E XML definitions for Parlay Encoding of SPIRITS 200 Data............................................... 70 201 E.1 Terminology........................................ 70 202 E.2 Use of XML......................................... 70 203 E.3 Protocol Operations................................ 71 204 E.4 Common Element Definitions......................... 74 205 F XSD definitions for Parlay Encoding of SPIRITS Data 206 F.1 Use of XSD......................................... 86 207 F.2 Conventions........................................ 91 209 July 2002 Expires Jan 2003 211 F.3 XML Schema's for INAP Information Elements......... 91 212 F.4 XML schema's for INAP Originating Detection Points. 109 213 F.5 XML XSD's for INAP Terminating Detection Points.... 114 214 F.6 XSD encoding for IFs from the SCF to the SSF....... 117 215 G XSD for Parlay Parameters and Data Types........... 121 216 G.1 Protocol Operations................................ 121 217 G.2 Common Element Definitions......................... 123 218 G.3 Examples for Parlay................................ 140 219 G.4 SPIRITS.XSD Includes............................... 143 220 H Miscellaneous Parlay/SPIRITS Issues................ 144 221 H.1 Protocol Procedures................................ 144 222 H.2 Dynamic Events..................................... 144 223 H.3 Security Considerations for Parlay................. 146 224 H.4 Parlay-related Unresolved Issues/Items to be Done.. 146 226 2.0 Brief description of working: 228 A call model (CM) is a finite state machine used in SSPs and other 229 call processing elements that accurately and concisely reflects the 230 current state of a call at any given point in time. Call models 231 consist of states called PICs (Points In Call) and transitions 232 between states. Inter-state transitions pass through elements called 233 Detection Points or DPs. DPs house one or more triggers. Every trigger 234 has a firing criteria associated with it. When a trigger is armed 235 (made active), and its associated firing criteria are satisfied, it 236 fires. The particulars of firing criteria may vary based on the call 237 model being supported. 239 When an active trigger is encountered, a message is formatted with call 240 state information and transmitted by the SSP to the SCP. The SCP then 241 reads this call related data and generates a response which the SSP then 242 uses in further call processing. 244 Detection Points are of two types: TDPs (or Trigger Detection Points), 245 and EDPs (or Event Detection Points). TDPs are provisioned with 246 statically armed triggers (armed through Service Management Tools). 247 EDPs are dynamically armed triggers (armed by the SCP as call 248 processing proceeds). DPs may also be classified as "Request" or 249 "Notification" DPs. Thus, one can have TDP-R's, TDP-N's, EDP-R's and 250 EDP-N's.[3] 252 The "-R" type of DPs require the SSP to suspend call processing when 253 communication with the SCP is initiated. Call processing resumes when 254 a response is received. The "-N" type of DPs enable the SSP to continue 255 with call processing when the armed trigger is encountered, after it sends 256 out the message to the SCP, notifying it that a certain event has occurred. 257 The distinction between these two kinds of DPs is used when we present 258 the material in Appendix A. 260 Call models typically support different types of detection points. Note 262 July 2002 Expires Jan 2003 264 that while INAP and the IN CS-2 call model are used in this draft as 265 examples, and for ease of explanation, other call models possess similar 266 properties. For example, the WIN call model also supports the dynamic 267 arming of triggers. Thus, the essence of this discussion applies not 268 just to the wireline domain, but applies equally well to the wireless 269 domain as well. 271 When the SCP receives the INAP formatted message from the SSP, if the 272 SCP supports the SPIRITS architecture, it can encode the INAP message 273 contents into a SPIRITS protocol message which is then transmitted to 274 SPIRITS-capable elements in the IP network. Similarly, when it receives 275 responses back from said SPIRITS capable elements, it can reformat the 276 response content into the INAP format and forward these messages back 277 to SSPs. Thus the process of inter-conversion and/or encoding between 278 the INAP parameters and the SPIRITS protocol is of primary interest. 280 July 2002 Expires Jan 2003 282 +--------------+ 283 | Subscriber's | 284 | IP Host | +--------------+ 285 | | | | 286 | +----------+ | | +----------+ | 287 | | PINT | | A | | PINT | | 288 | | Client +<-------/-------->+ Gateway +<-----+ 289 | +----------+ | | +----------+ | | 290 | | | | | 291 | +----------+ | | +----------+ | | 292 | | SPIRITS | | B | | SPIRITS | | | 293 | | Server +<-------/-------->+ Gateway | | | 294 | +----------+ | | +--------+-+ | | 295 | | | ^ | | 296 +--------------+ +----------|---+ | 297 | | 298 IP Network | | 299 ------------------------------------------|--------|--- 300 PSTN / C / E 301 | | 302 v | 303 +----+------+ | 304 | SPIRITS | | 305 | Client | v 306 +-------------------+ +---+-----D-----+-++ 307 | Service Switching |INAP/SS7 | Service Control | 308 | Function +---------+ Function | 309 +----+--------------+ +------------------+ 310 | 311 |line 312 +-+ 313 [0] Subscriber's Figure 1: The SPIRITS 314 Telephone Architecture. 316 (Note: The interfaces A-E are described in detail 317 in the SPIRITS Architecture document [1]) 319 In other words, this draft is focused on interfaces B, C and D depicted 320 in the above figure. 322 An SCP is a physical manifestation of the Service Control Function. 323 An SSP is a physical manifestation of the Service Switching Function 324 (and the Call Control Function). To support uniformity of nomenclature 325 between the various SPIRITS drafts, we shall use the terms SCP and 326 SCF, and SSP and SSF interchangeably in this document. 328 3.0 Brief SIP call flow overview for SPIRITS 330 A typical SPIRITS call flow proceeds as follows. As previously 332 July 2002 Expires Jan 2003 334 described, when an SSF trigger fires during call processing, it 335 formulates an INAP message and forwards it to the SCF. If the SCF 336 is SPIRITS-capable, it then converts the contents of the INAP message 337 into a semantically equivalent SPIRITS payload carried within the 338 body of a SIP message. This SIP message is then forwarded via the 339 SPIRITS gateway to other SPIRITS capable nodes in the IP domain. 341 There are multiple ways in which this SIP-based interaction may 342 proceed, depending on the kind of trigger supported and the service 343 scenario. 345 We refer to [6] for a simple example flow for Internet Call Waiting, 346 a SPIRITS service. SPIRITS-capable IP nodes may use a SIP REGISTER 347 message to specify a long-term binding and interest in messages from 348 the PSTN domain. For instance, the dialup SIP end-point registers its 349 IP address to DN binding with the SCF. Now, if a call comes in on the 350 line being used by the dialup end-point, when the Termination Attempt 351 Trigger is encountered and the SCF is so notified, the SCF may send a 352 SIP INVITE to the SIP client on the dialup connection notifying the user 353 of the call. The user may then choose to accept the call by generating 354 the appropriate SIP response, in which case the dialup connection may 355 be dropped and the call is put through. 357 A similar call flow may be set up for other SPIRITS services where 358 SIP events [5] mechanisms including SUBSCRIBE and NOTIFY messages 359 are used instead for analogous functionality. In such scenarios, a 360 SPIRITS-capable IP node would subscribe to a certain well-defined 361 set of events with the SPIRITS-client co-located with the SCF, 362 and subsequently NOTIFY messages encoded with call-related information 363 would be sent to them. The interested reader is referred to [6] for 364 details. 366 The REGISTER and INVITE messages may be used to support SPIRITS services 367 which are invoked by TDPs, whereas the SUBSCRIBE and NOTIFY messages may 368 be used to support services invoked at EDPs in PSTN call models. To 369 understand why this is so, recall that TDPs are pre-provisioned, and 370 statically armed, so the REGISTER and INVITE primitives are convenient 371 signaling primitives to support those SPIRITS interactions, whereas EDPs 372 being more dynamic in operation and how they are provisioned are better 373 addressed through support for primitives that comprise the SIP Events 374 infrastructure. This is generally recommended use of these primitive 375 only, particular call flows may use one or the other sets of primitives to 376 their advantage. Details are presented in [6] to be written. 378 Using SIP is just one means of carrying SPIRITS information from the 379 SCP (SCF in the Architecture diagram in figure 1) nodes to other 380 SPIRITS-capable nodes. Other means may be employed for this as well, 381 including using pure XML/HTTP (as opposed to XML-encoded content in SIP 382 messages). SIP however, does seem an appealing option, given that 383 a. most pre-SPIRITS implementations utilize SIP [7], and 385 July 2002 Expires Jan 2003 387 b. PINT [8] already specifies SIP as the protocol of choice (and 388 compatibility with PINT is one of the main requirements for the 389 SPIRITS protocol). 391 Several means were investigated for encoding SPIRITS information in 392 SIP messages including: 393 1. encoding this information in a newly defined MIME type [9,10], 394 2. encoding this information with newly defined SDP [11] headers or SDP 395 extensions, and 396 3. defining and using a new kind of description format (to be used 397 in lieu of SDP). 399 Some of these options are admittedly fairly inelegant. The first option 400 suggested above seems to be a reasonable way to proceed. Further, since 401 XML provides a convenient means of specifying and encoding this 402 information, this data may be XML-encoded, using the MIME-type 403 "application/spirits" defined in [6]. (True, alternatively, one may 404 carry INAP-related data in its original form in a manner analogous to 405 how SIP-T carries ISUP parameters, but that is outside the scope of 406 this current discussion). 408 4.0 IN-specific details 410 In the sub-sections that follow, we shall present IN-specific details 411 including how to extract common data types, parameters and response 412 codes information, with their associated descriptions, for particular 413 DPs and triggers of interest to SPIRITS and their associated data elements. 414 An Appendix is presented with data associated with the INAP for the IN 415 CS-2 specification defined by the ITU. We selected CS-2 as an example 416 simply because it has the "Recommendation in Force" status, as opposed 417 to the "Prepublished" status of CS-3. 419 We have previously discussed how INAP parameters may be extracted from 420 the ASN.1-encoded format and suitably text-encoded into XML to be carried 421 as payload in SIP messages. Response codes and associated content may be 422 similarly carried in SIP responses, or SIP-based messages (provisional 423 and non-provisional responses as defined in RFC 2543, section 11, pp.83-93) 424 may be used to signal responses with appropriately encoded content that 425 could be translated to INAP at the SCP to be sent out in the response. 427 In Appendix B, we present an example XML DTD that may be used to support 428 the XML-encoding for SPIRITS messages. 430 In Appendices C-F, we present another means of encoding SPIRITS 431 information, by making use of Parlay parameters. Parlay is a family of 432 APIs defined by an industry consortium seeking to standardize a set of 433 abstract high-level interfaces for use by third-party programmers so they 434 may build applications that leverage services and functionality exposed 435 by networks of telecommunication elements. Parlay supports APIs for 437 July 2002 Expires Jan 2003 439 diverse areas such as call control, user location, user interaction, 440 messaging etc., In Appendices C-F, we focus on the set of events 441 supported by the Parlay call control API as they are directly relevant 442 to the SPIRITS context. 444 4.1 Approaches for Encoding DP Information: 446 In typical IN systems there are two methods used to encode parameters 447 into the messages used to support the communication between the call 448 processing or switching element such as the SSP, and the service 449 processing element such as the SCP. These are: 451 a. the DP-generic approach: 452 Only one information flow is supported for the communication between 453 the SSP and SCP if this technique is used, and that is the flow named 454 "Initial DP". The same message is encoded with different information 455 elements based on what triggered operation is being requested, with 456 a flag in the message indicating the requested operation. 458 b. the DP-specific approach: 459 A different information flow is supported for each distinct kind of 460 service request/response interaction between the SSP and the SCP, 461 with the kind of message specifying exactly what the embedded contents 462 should include. 464 In this document, and in the appendix, we present the DP-specific way 465 of encoding parameters. A similar document may be generated that makes 466 use of the DP-generic approach. 468 Communication between the SCP and SSP is supported by means of Information 469 Flows (IFs), which carry Information Elements (IEs). IFs are well-defined 470 for each DP in the call model, and for the associated responses. 472 To summarize... 473 PICs are the states in the call model state machine. DPs are the entry or 474 exit criteria for each state, that house one or more triggers. When a 475 trigger is encountered, a message is formatted using the appropriate protocol 476 into a well-defined Information Flow, and transmitted to the SCP. Upon 477 receiving this IF, the SCP processes the received data, and transmits a 478 response back in another IF. The SSP then extracts the IEs in the received 479 IFs and uses these in further call processing. 481 4.2 Template Description and Procedure: 483 This section describes the format of the presentation in appendix A 484 that presents how and what INAP CS-2 parameters may be used in the 485 SPIRITS context. Please note that while the appendix presents the 486 encoding for INAP CS-2 type parameters, one may use similar procedures 488 July 2002 Expires Jan 2003 490 as those described in this section to generate a similar map from 491 any other IN standards specification to the SPIRITS protocol. (CS-2 492 is simply used as a convenient example in this document). 494 Appendix A presents the DPs and triggers of interest to SPIRITS from 495 the IN CS-2 specification. Note that not all parameters are listed in 496 the appendix for each operation, but that a subset of parameters useful 497 to SPIRITS has been selected. ("usefulness" was determined by considering 498 call flows for some sample SPIRITS services). If additional parameters 499 are required, the procedure described below may be repeated to retrieve 500 their associated information. 502 The template used specifies information in the following format: 503 504 505 506 - Parameters 507 - Error Codes or Indication. 509 The procedure that may be used to gather more information about other 510 detection points is as follows: 512 Look up information associated with the detection point of 513 interest in ITU standard Q.1228 [12]. Determine the set of associated 514 arguments and list of parameters for that DP, along with the 515 supported return codes. Next, use Q.1228 along with Q.1224 [13] to 516 determine the structure and content of the parameters in each of 517 the messages. Look up Q.763 [14] and Q.931 [15] for more related 518 information on data-types. Collect and collate this information into 519 the above template. 521 4.3 SPIRITS Data and Encoding: 523 In the Appendices that follow, as previously explained, we present a 524 select subset of IN CS-2 detection points and IFs that we believe will 525 be useful in the context of SPIRITS services. Admittedly, this list may 526 not be exhaustive. Note that INAP and similar protocols support a large 527 number of optional (O) parameters in each message. Not all such parameters 528 may be useful in the SPIRITS context, thus, only a subset of available 529 IEs are of direct interest. 531 Note also, that depending on what kinds of SPIRITS services are supported, 532 and how they are implemented, the "thickness" of the SPIRITS implementation 533 may drive exactly what subset of parameters received by the SCP are 534 forwarded on towards the SPIRITS server for processing. An SCP could thus 535 function in one of three modes for every incoming request: 536 a. process the request locally (as is traditionally done today, no SPIRITS 537 involvement), 538 b. process part of the request locally and forward some parameters to a 540 July 2002 Expires Jan 2003 542 SPIRITS-entity for further processing, and formulate a response based 543 on both the local processing and the SPIRITS response, and 544 c. forward all the received data in a SPIRITS protocol-compliant format 545 to a SPIRITS entity for processing, and forward back the appropriately 546 formatted response to the entity that originated the request. 547 We do not here preclude operation in any of the modes above. 549 As mentioned previously, the first trigger that is encountered during call 550 processing is typically a TDP (since there is no pre-existing control 551 relationship between the SSF and the SCF prior to this). TDPs are 552 provisioned through a management system interface on the switching 553 element (SSP). In the future, other mechanisms (such as PINT) may be 554 used to provision this data as well, but in this document we limit our 555 discussion to pure SPIRITS implementations. 557 Since there is no explicit "subscription" via SUBSCRIBE to the TDP, a 558 SIP INVITE message is used to carry information between the SPIRITS 559 client and server (for TDPs that result in an INVITE, the body of the 560 said INVITE will contain multi-part MIME with two MIME components: the 561 first component will be the DP information encapsulated as 562 "application/spirits" and the other component (optional) will be the 563 actual body of the INVITE (could be SDP or anything else)). Responses 564 to the INVITE message, or subsequent SUBSCRIBE messages from the SCF to 565 the SSF within a current call context may result in EDPs being armed. 566 NOTIFY messages are thus a convenient means of communication in those 567 cases when triggers housed in EDPs are encountered. See [16], section 3 568 page 5 for more. Note that [16] uses the term "persistent" to refer to 569 call-related DP arming and associated inter-actions. 571 The details of the SIP call flows used to support the operation of 572 SPIRITS services are captured in greater detail in [6]. This document 573 is focused primarily on parameter derivation and encoding from the 574 various telecommunications protocols of interest, while the companion 575 draft is more targeted towards SIP protocol encoding of said parameters 576 and related operation. 578 5.0 Unresolved Issues 579 This section is meant to be a catch-all for any unresolved issues. 580 Issues addressed in later versions of this draft will be marked as 581 such. 583 5.1 Information pertaining to Wireless Specific (CAMEL) Standards, their 584 encoding for transmission as SPIRITS parameters etc., may also have to 585 be addressed. This draft is focused on INAP, if such a representation 586 is required for CAMEL, it may be generated using procedures similar to 587 those outlined above. 589 5.2 Mailing list discussions, rough technical consensus at the last two 590 meetings, as well as SPIRITS Protocol Requirements document [16] name 592 July 2002 Expires Jan 2003 594 SIP as a choice for SPIRITS transport protocol. As their next step this 595 group of authors will produce another I-D, focusing on SIP call flows 596 for the SPIRITS context. 598 5.3 The authors were unable to find the parameters for the "Hold Call In 599 Network", "Trigger Data Status Request", and "Continue" IFs used in the 600 example presented in Appendix A, section A.5, items 5, 7 and 12. 602 5.4 Some nits and discrepancies between the XML format and the presented 603 TCAP format, and within the TCAP format description sections may have 604 slipped through and will be addressed in future versions of this 605 document. 607 6.0 Security Considerations 609 The SPIRITS Architecture draft addresses security issues with the SPIRITS 610 architecture (such as security requirements along interfaces B and C). 611 This draft is primarily concerned with protocol conversions or translations 612 for encoding of protocol parameters from the PSTN into a format that can be 613 carried by SIP messages, and vice-versa. 615 Since the PSTN network is assumed to be closed and therefore a well- 616 controlled environment, and since this translation process is carried out 617 on a PSTN network element, we assume that the protocol encoding process 618 is not vulnerable to external attack, especially so if the SPIRITS client 619 and the Service Control Function are co-located as depicted in figure 1. 620 If said functional elements were not co-located, one would have to support 621 security mechanisms for authentication, authorization, access control 622 logging, and confidentiality, using any one of the well-defined, well- 623 understood and tested techniques in wide-spread use today. 625 7.0 Future Work: 627 a. May need to extend the example presented in Appendices A and B with 628 IFs that would be useful for other SPIRITS services. 629 b. Support for other protocols such as CAMEL etc., may need to be 630 addressed. If so, procedure similar to those described in this 631 document may be used. 633 8.0 Acknowledgements 635 The authors are grateful to all participants in the SPIRITS WG for the 636 discussion that has been shaping this work. We would also like to thank 637 Hui-Lan Lu, Igor Faynberg, John Stanaway and Warren Montgomery for their 638 time and insightful comments during the preparation of this I-D. The 639 authors would also like to thank Vijay Gurbani for comments on early 640 versions of v3.0 of this draft. 642 July 2002 Expires Jan 2003 644 9.0 References 646 [1] Slutsman, L (Ed.) et al, The Spirits Architecture, , Work in Progress. February 2001. 649 [2] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, 650 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 652 [3] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent 653 Network Standards: Their Application to Services", McGraw-Hill, 1997. 655 [4] 3GPP Standards: 657 [5] A. Roach, Event Notification in SIP, , Work in Progress. October 2000. 660 [6] V. Gurbani et al, The SPIRITS Protocol: SIP Aspects, IETF 661 Internet Draft, draft-gurbani-spirits-protocol-02.txt, 662 Work in Progress. 664 [7] Lu, H. (Editor), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, 665 S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, 666 J. Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN- 667 Initiated Services." RFC 2995, November 2000. 669 [8] S. Petrack, and L. Conroy, The PINT Service Protocol: Extensions 670 to SIP and SDP for IP Access to Telephone Call Services, Proposed 671 Standard. RFC 2848, June 2000. 673 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 674 Extensions (MIME) Part One: Format of Internet Message Bodies", 675 RFC 2045, November 1996. 677 [10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 678 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 680 [11] Handley, M. and V. Jacobsen, "SDP: Session Description 681 Protocol", RFC 2327, April 1998. 683 [12] Intelligent Network Capability Set 2. ITU-T, Recommendation Q.1228 685 [13] Distributed functional plane for intelligent network capability Set 2. 686 ITU-T, Recommendation Q.1224, 09/97. 688 [14] Recommendation Q.763 (12/99) - Signalling System No. 7 - ISDN user 689 part formats and codes 691 [15] Recommendation Q.931 (05/98) - ISDN user-network interface layer 3 693 July 2002 Expires Jan 2003 695 specification for basic call control 697 [16] I.Faynberg, et al, "SPIRITS Protocol Requirements", 698 draft-ietf-spirits-reqs-03.txt, work in progress, February, 2001. 700 [17] Extensible Markup Language (XML) 1.0 (Second Edition), W3C 701 Recommendation: REC-xml-20001006, http://www.w3.org/TR/REC-xml 703 [18] The Parlay Specifications, http://www.parlay.org/specs/index.asp 705 [19] 3G TS 23.127 version 4.0.0, "3rd Generation Partnership Project; 706 Technical Specification Group Services and System Aspects; Virtual 707 Home Environment" (Release 4) 709 [20] 3G TS 29.198-04 version 4.0.0, "3rd Generation Partnership 710 Project; Technical Specification Group Core Network; Open Service 711 Access (OSA); Application Programming Interface (API); Part 4: 712 Call Control" (Release 4) 714 [21] 3G TR 29.998 v3.2.0 "3rd Generation Partnership Project; Technical 715 Specification Group Core Network; Open Services Architecture; 716 Application Programming Interface - Part 2" (Release 1999) 718 [22] ISO 8601-1997, "Data elements and interchange formats - 719 Information interchange - Representation of dates and times". 721 [23] ETSI DocBox, SPAN 12 OPEN SERVICE ACCESS API, 722 http://docbox.etsi.org/tech-org/span/Open/Span12/Overview.html 724 Appendix A: INAP Parameters and Data Types. 726 This Appendix presents Information Flows (IFs), Information Elements (IEs), 727 commonly used data types, their corresponding structure and encoding-related 728 details, and error codes. In other words, material presented in this section 729 forms the basis for the XML encoding presented in the next appendix. 731 In the sections that follow, we first present IFs from the SSP to the SCP, 732 and then the IFs in the opposite direction. Note that the IFs from the 733 SSP to the SCP are tied more closely to the DP where the trigger fires, 734 and are therefore presented by DP, whereas some IFs flowing in the opposite 735 direction may be used in response to messages received from multiple DPs 736 and are therefore presented independently. Mandatory and Optional parameters 737 are so indicated by the M and O tags. 739 A.1 Information Elements (IEs): 741 The following are some commonly used Information Elements that seen 742 relevant in the SPIRITS context. These are described most completely 743 in the ITU specifications Q.1224 and Q.1228. 745 July 2002 Expires Jan 2003 747 Access Code - contains information associated with an Access Code if a 748 customized dialing plan is used to request a call origination. 750 Busy Cause - identifies the reason a called party was busy. 752 Calling Party Subaddress - the sub-address associated with the calling 753 party of a call. 755 Called Party Subaddress - the sub-address associated with the called 756 party of a call. 758 Called Party Number (TDP) - Identifies the called party in a call. 760 Carrier - this consists of a carrier selection indicator that states 761 whether the selected carrier was the subscribed carrier of the user 762 or was selected for that call by dialing a carrier code, and a Carrier 763 ID that indicates the carrier selected. (Q: ITU doc says presubscribed 764 carrier - is this correct?). 766 Cause - states why a specific entity was released. 768 Connect Time - indicates the duration for which the call was active. 770 Dialed Digits - indicates the information received by a switching element 771 from the end-user (if it is a class 5 switch) or from another switch 772 (if it is a class 4 switch). 774 Failure Cause - specifies the reason why a particular route selection 775 failed. 777 Feature Code - encodes any special feature codes dialed by the caller. 778 This information may be encoded for use in the Origination Attempt and 779 Collected Info DPs. 781 Feature Request Indicator - specifies the requested feature type. 783 Original Called Party ID - specifies the identity of the first redirecting 784 party. 786 Prefix - encodes any non feature code, non access code digits that are 787 dialed. This information may be encoded a the Origination Attempt and 788 Collected Info DPs (it is used in the Analysed_Info DP). 790 Redirecting Party ID - specifies the identity of the last redirecting 791 party. 793 Redirection Information - indicates the reason for the redirection and 794 the number of redirections that have taken place. 796 July 2002 Expires Jan 2003 798 Release Cause - specifies why a particular resource or call party is 799 released. 801 Route List - represents the list of routes which could be used to route 802 the call. 804 Service Address Information triggerType (TDP) - when used, enables the 805 SCP to pick the appropriate application to service the request. Also 806 permits the SCP to validate an incoming request. 808 A.2 Commonly Used Parameters: 810 The commonly used parameters described in this section each tie in 811 with one of the information elements listed above. The base "type" 812 of a parameter that could be used for encoding it is also listed. 813 Some of these parameters though encoded as basic strings consist of 814 rather complicated internal data-types. The complexities of these 815 datatypes is not presented here, the interested reader is referred 816 to ITU specifications Q.1228 and Q.760-764 for those. 818 releaseCause 819 An integer specifying the reason for the release of a given call. 821 busyCause 822 A string indicating the reason why a busy signal was received. 824 callingPartySubaddress 825 A string denoting the callingPartySubaddress i.e. the subaddress 826 associated with the origin of the call. This field has a maximum 827 length of 20 octets or 40 digits. The actual length and encoding 828 of this parameter depend on the particulars of the dialing plan used. 830 calledPartySubaddress 831 A string denoting the calledPartySubaddress i.e. the subaddress 832 associated with the called party of the call. This field has a maximum 833 length of 20 octets or 40 digits. The actual length and encoding 834 of this parameter depend on the particulars of the dialing plan used. 836 originalCalledPartyID 837 Indicates the original called party number. The actual length of this 838 parameter depends on the particulars of the dialing plan used. 840 redirectingPartyID 841 A string indicating the last directory number the call was redirected 842 from. 844 redirectionInformation 845 A byte[2] element that specifies any additional redirection 846 information including why the call was diverted, what kind of call 848 July 2002 Expires Jan 2003 850 diversion mechanism/reason was used (unconditional, busy, no answer), 851 the number of redirections (between 1 and 5), and what redirection 852 information is available in each case. 854 carrier 855 A string that encodes the selected carrier and the transit network 856 selection code. 858 CalledPartyNumber 859 A parameter encoded as a string that is used to identify the called 860 party in the forward direction, Used to convey dialed digits information 861 if the switching element has recognized the called party number in the 862 digits dialed. If the switching element was unable to make this 863 determination, the same information is conveyed in a string-encoded 864 form as the parameter "dialed digits". 866 OriginalCalledPartyID 867 A string encoded parameter that carries the identity of the original 868 called party. Used in other messages if the call gets redirected. 870 A.3 Error Codes: 871 This section presents some error codes that are sent by the SCP to 872 the switching element to indicate an error or failure condition. The 873 descriptions for these various error codes may be most easily obtained 874 by looking up ITU documents Q.760-764, and Q.931. Error codes are 875 encoded as integers (per Q.1228). 877 missingCustomerRecord 878 This error code indicates that either the customer record does not 879 exist on the SCP, or that there is no service logic identified by 880 the indicated service key. Each of these is encoded using a distinct 881 error condition so the requesting entity can distinguish between 882 these two error categories. Error code 6 is used to identify this 883 error. 885 missingParameter 886 An expected parameter was not received by the server processing the 887 request. Error code 7 is used to identify this error. 889 systemFailure 890 A system failure at the server caused the request to not be processed. 891 (Error code 11). 893 taskRefused 894 A requested operation was refused (e.g. due to link congestion) by 895 the server. (Error code 12). 897 unexpectedComponentSequence 898 An incorrect sequence of components was received, and/or operations 899 requested are not permitted in the current state of the call. (Error 901 July 2002 Expires Jan 2003 903 code 14). 905 unexpectedDataValue 906 An incorrect data value was received, or data value received cannot 907 be bound to the expected parameter at the server. (Error code 15). 909 unexpectedParameter 910 A parameter was received, but was not expected by the server. (Error 911 code 16). 913 unknownLegID 914 A particular call-leg is not known to the server. (Error code 17). 916 parameterOutOfRange 917 Unexpected value for a parameter. Either (if Integer), the parameter 918 was beyond specified ranges, or (if enumerated), was not one of the 919 listed enumerated types. (Error code 8). 921 A.4 Detection Points, Triggers, and related information: 922 In this section, we present Detection Points supported by the IN 923 CS-2 Call Model, along with the associated information elements and 924 parameters. Only selected parameters that are relevant to the SPIRITS 925 context and effort are presented as examples. These have been described 926 in preceding sections. If desired, additional parameters may also be 927 supported. 929 This section is divided into two sub-sections. In the first of these 930 we present Originating DPs (associated with the calling party), and 931 in the second, we elaborate on Terminating DPs (associated with the 932 called party). 934 A.4.1 Originating Detection Points 936 These are defined in ITU-T Recommendation Q.1224, and are 937 representative of the call model elements between the states 938 defined in the Originating Call Model BCSM (O_BCSM). All the DPs 939 in the O_BCSM support the complete list of error conditions 940 described in section A.3. 942 July 2002 Expires Jan 2003 944 +--------->-----------+ 945 | | 946 | +-------V-------------+ +---------------------+ 947 | +-------->| 1. O_NULL |<-----| 11. O_Exception | 948 | | +---------------------+ +--------------+------+ 949 | +---+ O_Abandon | | 950 | |21 | | | 951 | +---+ +-V-+ ^ 952 | | | 1 | Orig.Attempt | 953 | | +-----+---+-----------+ +---+ | 954 | |<--------| 2. Auth_Orig_Att. |---->| 2 |---------->| 955 | | +---------------------+ +---+ Orig. | 956 | | | Denied. | 957 | | | | 958 | | +-V-+ | 959 ^ | | 3 | Orig.Attempt.Auth | 960 | | +-----+---+-----------+ +---+ | 961 | |<--------| 3. Collect_Info. |---->| 4 |---------->| 962 | | +---------------------+ +---+ Collect | 963 | | | Timeout | 964 | | | | 965 | | +-V-+ | 966 | | | 5 | Collected.Info Invalid | 967 | | +-----+---+-----------+ +---+ Info | 968 | |<--------| 4. Analyze_Info. |---->| 6 |---------->| 969 | | +---------------------+ +---+ | 970 | | | | 971 | | | | 972 | | Analyzed +-V-+ + -------<----------------------+ 973 | | Info | 7 | | Route Select | | 974 | | +-----+---+-----V-----+ +---+ Failure | | 975 | |<--------| 5. Select_Route. |---->| 8 |---------->| | 976 | | +---------------------+ +---+ | | 977 ^ | | | ^ 978 | | | | | 979 | | Route +-V-+ | | 980 | | Selected | 9 | Auth | | 981 | | +-----+---+-----------+ +---+Failure | | 982 | |<--------| 6. Auth_Call_Setup |---->|10 |---------->| | 983 | | +---------------------+ +---+ | | 984 | | | | | 985 | | | Route | | 986 | | +-V-+ Orig. +---+ Failure | | 987 | | |11 | Auth. |12 |-------------->+ 988 | | +-----+---+-----------+---->+---+ | 989 | |<--------| 7. Call_Sent | +---+ | 990 ^ | +---+-----------------+---+---->|13 |---------->| 991 | | |18 |O_Mid | | +---+ | 992 | | +---+ _Call | +-----+ O_Called_Party | 993 | | +-V-+ | _Busy | 995 July 2002 Expires Jan 2003 997 | | O_Term_Seized |14 | | | 998 | | +-----+---+-----------+ | +---+ | 999 | |<--------| 8. O_Alerting |-|-->|15 |---------->| 1000 | | +---+---------------------+ | +---+ | 1001 | | |18 | | | O_No_Answer | 1002 | | +---+ | | | 1003 | | +-V-+<------------+ | 1004 | | |16 | O_Answer | 1005 | | +-----+---+-----------+ +---+ | 1006 | +---------| 9. O_Active. |---->|17 |---------->+ 1007 | +---+---------------------+ +---+ 1008 | |18 | | O_Conn_Failure 1009 | +---+ | 1010 | +-V-+ 1011 | |19 | O_Disconnect 1012 +---+ +-----+---+-----------+ 1013 |20 |<--------| 10. O_Disconnect. | 1014 +---+ +---------------------+ 1015 O_Disconnect 1016 _Complete 1018 Figure 2: The CS-2 O_BCSM [ref.] 1020 1. O_Abandon 1021 Indicates that a call has been abandoned. 1023 Information Elements: Data Types M/O 1024 Call Segment ID callSegmentID M 1025 Release Cause cause O 1026 DpSpecificCommonParameters 1028 2. O_Called_Party_Busy 1029 This DP is an indication from the terminating BCSM that the 1030 terminating party is busy. 1032 Information Elements: Data Types M/O 1033 Busy Cause cause O 1034 Calling Party Subaddress callingPartySubaddress O 1035 Carrier carrier O 1036 Original Called Party ID originalCalledPartyID O 1037 Prefix - O 1038 Redirecting Party ID redirectingPartyID O 1039 Redirection Information redirectionInformation O 1040 DpSpecificCommonParameters 1041 Digits 1043 3. O_Disconnect 1044 This operation signals a disconnect indication from the originating 1045 party, after a call was set up. 1047 July 2002 Expires Jan 2003 1049 Information Elements: Data Types M/O 1050 Calling Party Subaddress callingPartySubaddress O 1051 Carrier carrier O 1052 Connect Time connectTime O 1053 Release Cause releaseCause O 1055 4. Collected Information 1056 This operation indicates that a complete string of digits was 1057 received from the originating party. 1059 Information Elements: Data Types M/O 1060 Access Code O 1061 Calling Party Subaddress callingPartySubaddress O 1062 Carrier carrier O 1063 Dialed Digits digits O 1064 Feature Code - O 1065 Original Called Party ID originalCalledPartyID O 1066 Prefix - O 1067 Redirecting Party ID redirectingPartyID O 1068 Redirection Information redirectionInformation O 1069 calledPartyNumber 1071 5. Origination Attempt Authorized 1072 This operation indicates that the originating party is permitted 1073 to make the outgoing call. 1075 Information Elements: Data Types M/O 1076 Calling Party Subaddress callingPartySubaddress O 1077 Carrier carrier O 1078 Dialed Digits calledPartyNumber O 1080 6. O_No_Answer 1081 This operation is an indication from the terminating BCSM that the 1082 called party has not answered the call in a specified time period. 1084 Information Elements: Data Types M/O 1085 Calling Party Subaddress callingPartySubaddress O 1086 Carrier carrier O 1087 Original Called Party ID originalCalledPartyID O 1088 Prefix - O 1089 Redirecting Party ID redirectingPartyID O 1090 Redirection Information redirectionInformation O 1091 DpSpecificCommonParameters 1092 Digits 1094 7. O_MidCall 1095 This operation indicates a feature requested received from the 1096 originating party after the call has been set up. 1098 Information Elements: Data Types M/O 1100 July 2002 Expires Jan 2003 1102 Called Party Subaddress calledPartySubaddress O 1103 Calling Party Subaddress callingPartySubaddress O 1104 Carrier carrier O 1105 Feature Request Indicator featureRequestIndicator O 1107 8. O_Answer 1108 This operation is a signal from the terminating BCSM that the call 1109 has been answered. 1111 Information Elements: Data Types M/O 1112 Calling Party Subaddress callingPartySubaddress O 1113 Original Called Party ID originalCalledPartyID O 1114 Redirecting Party ID redirectingPartyID O 1115 Redirection Information redirectionInformation O 1116 DpSpecificCommonParameters 1118 9. Analysed Information 1119 This operation indicates that a routing address and call type are 1120 available. 1122 Information Elements: Data Types M/O 1123 Access Code accessCode O 1124 Calling Party Subaddress callingPartySubaddress O 1125 Carrier carrier O 1126 Dialed Digits Digits O 1127 Feature Code featureCode O 1128 Original Called Party ID originalCalledPartyID O 1129 Prefix - O 1130 Redirecting Party ID redirectingPartyID O 1131 Redirection Information redirectionInformation O 1132 DpSpecificCommonParameters 1133 CalledPartyNumber 1135 10. Route Select Failure 1136 Indicates that a route to terminate the call cannot be selected by 1137 the SSP, or that the call cannot be presented by the terminating 1138 BCSM to the called party due to a reason such as network congestion. 1140 Information Elements: Data Types M/O 1141 Calling Party Subaddress callingPartySubaddress O 1142 Carrier carrier O 1143 Dialed Digits Digits O 1144 Failure Cause cause O 1145 Original Called Party ID originalCalledPartyID O 1146 Prefix - O 1147 Redirecting Party ID redirectingPartyID O 1148 Redirection Information redirectionInformation O 1149 DpSpecificCommonParameters 1150 CalledPartyNumber 1152 July 2002 Expires Jan 2003 1154 A.4.2 Terminating Detection Points 1156 These are defined in ITU-T Recommendation Q.1224, and are hosted 1157 by the terminating BCSM (T_BCSM) finite state machine. All the DPs 1158 in the T_BCSM support the complete list of error indications we 1159 have previously described in section A.3. 1161 +---------------<------------+ 1162 | | 1163 +---------------------+ +-------V-------------+ | 1164 | 19. T_Exception |----->| 12. T_NULL |<-------+ | 1165 +------+--------------+ +---------------------+ | | 1166 | | T_Abandon +---+ | 1167 | +-V-+ |35 | | 1168 | |22 | Term_Attempt +---+ | 1169 | +---+ +-----+---+-----------+ | | 1170 +<--------|23 |<------| 13. Auth_Term_Att. |------->+ | 1171 | +---+ +---------------------+ | | 1172 | Term_Denied | | | 1173 | | ^ ^ 1174 | +-V-+ | | 1175 | |24 | Term_Auth. | | 1176 | +---+ +-----+---+-----------+ | | 1177 +<---------|25 |<-----| 14. Select_Fac. |------->+ | 1178 | +---+ +---------------------+ | | 1179 | T_Called_Party_Busy | | | 1180 | | | | 1181 | +-V-+ ^ ^ 1182 | |26 | Term.Res.Avail | | 1183 | +---+ +-----+---+-----------+ | | 1184 +<---------|27 |<-----| 15. Present_Call. |------->+ | 1185 | +---+ +--+------------------+ | | 1186 | Presentation | | | | 1187 | Failure +-----+ | | | 1188 | | +-V-+ ^ | 1189 | | |28 | T_Term_Seized | | 1190 | +---+ | +-----+---+-----------+ | | 1191 +<---------|29 |<--|--| 16. T_Alerting |------->+ | 1192 | +---+ | +---------------------+---+ | | 1193 | T_No_Answer | | T_Mid_Call |32 | | | 1194 | | | +---+ | | 1195 | | +-V-+ | | 1196 | +------->|30 | T_Answer | | 1197 | +---+ +-----+---+-----------+ | | 1198 +<---------|31 |<-----| 17. T_Active |------->+ | 1199 +---+ +---------------------+---+ | 1200 T_Conn.Failure | |32 | ^ 1201 | +---+ | 1202 +-V-+ | 1204 July 2002 Expires Jan 2003 1206 |33 | T_Disconnect | 1207 +-----+---+-----------+ +---+ | 1208 | 18. T_Disconnect |---->|34 |--->+ 1209 +---------------------+ +---+ 1210 T_Disconnect_Complete 1212 Figure 3: The CS-2 T_BCSM [ref.] 1214 1. Termination Attempt Authorized 1215 Indicates that an incoming call received from the originating BCSM 1216 is authorized to be routed to the terminating end. 1218 Information Elements: Data Types M/O 1219 Called Party Subaddress calledPartySubaddress O 1220 Calling Party Subaddress callingPartySubaddress O 1221 Original Called Party ID originalCalledPartyID O 1222 Redirecting Party ID redirectingPartyID O 1223 Redirection Information redirectionInformation O 1224 DpSpecificCommonParameters 1226 2. T_Abandon 1227 There is no operation for TAbandon as it cannot be armed as TDP. 1228 The T_Abandon and O_Abandon DPs refer to the event of the A-party 1229 disconnecting prior to B-party answering. The former is reported 1230 by the TBCSM while the latter is reported by the OBCSM. 1232 3. T_Busy 1233 Indicates that the call cannot be completed because all 1234 resources to the terminating end are busy. 1236 Information Elements: Data Types M/O 1237 Busy Cause cause O 1238 Called Party Subaddress calledPartySubaddress O 1239 Original Called Party ID originalCalledPartyID O 1240 Redirecting Party ID redirectingPartyID O 1241 Redirection Information redirectionInformation O 1242 DpSpecificCommonParameters 1244 4. Facility Selected and Available 1245 Indicates that a facility to route to has been selected and is 1246 available for use. 1248 Information Elements: Data Types M/O 1249 DpSpecificCommonParameters dpSpecificCommonParameters O 1250 Called Party Subaddress calledPartySubaddress O 1251 Calling Party Number callingPartyNumber O 1252 Original Called Party ID originalCalledPartyID O 1253 Redirecting Party ID redirectingPartyID O 1255 July 2002 Expires Jan 2003 1257 Redirection Information redirectionInformation O 1259 5. T_No_Answer 1260 A terminating BCSM indication that the terminating party did not 1261 answer in a specified duration. 1263 Information elements: Data Types M/O 1264 Service Address Information Octet String O? 1265 triggerType 1266 Called Party Number - O? 1267 Called Party Subaddress calledPartySubaddress O? 1268 Original Called Party ID originalCalledPartyID O? 1269 Redirecting Party ID redirectingPartyID O? 1270 Redirection Information redirectionInformation O? 1271 DpSpecificCommonParameters 1273 6. T_Answer 1274 Indicates that the call has been accepted and answered by the 1275 terminating party. 1277 Information elements: Data Types M/O 1278 Service Address Information Octet String O? 1279 triggerType 1280 Called Party Number - O? 1281 Called Party Subaddress calledPartySubaddress O? 1282 DpSpecificCommonParameters 1284 7. T_MidCall 1285 Indicates a mid-call feature request from the terminating party. 1287 Information Elements: Data Types M/O 1288 Called Party Subaddress calledPartySubaddress O 1289 Calling Party Subaddress callingPartySubaddress O 1290 Carrier carrier O 1291 Feature Request Indicator featureRequestIndicator O 1292 DpSpecificCommonParameters 1294 8. T_Disconnect 1295 Indicates that a disconnect indication was received from the 1296 terminating party or from the originating BCSM to end an active 1297 call. 1299 Information Elements: Data Types M/O 1300 Called Party Subaddress calledPartySubaddress O 1301 Connect Time - O 1302 Release Cause cause O 1303 DpSpecificCommonParameters O 1305 A.5 SCF to SSF IFs: 1306 This section presents the Information Flows of interest, that originate 1308 July 2002 Expires Jan 2003 1310 at the SCP and flow towards the SSP. These typically encode responses to 1311 SSF-originated requests. Note that different responses may be sent to a 1312 request that originated from the same DP, based on the result of service 1313 related processing at the SCP. 1315 1. Analyse Information 1316 requests the SSF to perform digit analysis and related functions 1317 to determine how the call may be set up. 1319 Information Elements: Data Types M/O 1320 Call ID callID (Integer?) M 1321 Destination Routing Address DestinationRoutingAddress O 1322 Call Segment ID callSegmentID O 1323 Calling Party Number callingPartyNumber O 1324 Called Party Number calledPartyNumber O 1325 Carrier carrier O 1326 Charge Number chargeNumber O 1328 2. Authorise Termination 1329 requests the SSF to perform basic call processing functions associated 1330 with the Authorize_Termination_Attempt PIC. This response may be 1331 received by the SSF when call processing is suspended in any of the 1332 following DPs: Termination_Attempt, Termination_Attempt_Authorized, 1333 T_Busy, or, T_No_Answer. 1335 Information Elements Data Types M/O 1336 Call ID callID (Integer?) M 1337 Calling Party Number callingPartyNumber O 1338 Original Called Party ID originalCalledPartyID O 1339 Leg ID legID (Integer?) O 1341 3. Collect Information 1342 requests the SSF to prompt and collect more information (associated 1343 with a given numbering plan) from the calling party. This response is 1344 received by the SSF when call processing is suspended at any of the 1345 following DPs: 1346 Origination_Attempt_Authorized, Collected_Info, Analyzed_Info, 1347 Route_Select_Failure, O_Called_Party_Busy, O_No_Answer. 1349 Information Elements Data Types M/O 1350 Call ID callID (Integer?) M 1351 Original Called Party ID originalCalledPartyID O 1352 Calling Party Number callingPartyNumber O 1353 Called Party Number Digits O 1355 4. Connect 1356 used to create a call to a defined destination, or to forward a call 1357 to a different destination. May be received by the SSF in response 1358 to a message sent out in the O_MidCall DP. 1360 July 2002 Expires Jan 2003 1362 Information Elements Data Types M/O 1363 Call ID callID (Integer?) M 1364 Destination Routing Address destinationRoutingAddress M 1365 Forwarding Condition forwardingCondition O 1366 Carrier carrier O 1367 Redirecting Party ID redirectingPartyID O 1368 Redirection Information redirectionInformation O 1369 Display Information displayInformation O 1370 Charge Number chargeNumber O 1371 Call Segment ID callSegmentID (Integer?) O 1372 SCF ID ??? O 1374 5. Continue 1375 requests the SSF to proceed with call processing. Can be received as 1376 a response at any DP. For parameters, please see the section on 1377 unresolved issues. 1379 6. Furnish Charging Information 1380 gives the SSF some billing information to help it generate an 1381 appropriate billing record. 1383 Information Elements Data Types M/O 1384 Call ID callID (Integer?) M 1385 Billing Charging ??? M 1386 Characterisics 1388 7. Hold Call In Network 1389 used to provide the Call Queueing functionality. Call processing may 1390 have been suspended at any DP before the active state, on the SSF. 1391 For parameters, please see the section on unresolved issues. 1393 8. Initiate Call Attempt 1394 used by the SCF to have the SSF initiate a call to one party based 1395 on information provided by the SCF. This is used to support features 1396 such as Wake-up calls. The SSF sets an EDP-R for the Answer and 1397 No_Answer conditions. There is no previous SCP-SSP context for this 1398 information flow. 1400 Information Elements Data Types M/O 1401 Call ID callID (Integer?) M 1402 Leg to be Created legID M 1403 New Call Segment callSegmentID (Integer?) M 1404 Destination Routing Address destinationRoutingAddress O 1406 9. Release Call 1407 used to kill an existing call. Can be received by the SSF at any 1408 point in call processing, and causes a transition into O_NULL for 1409 the O_BCSM, and T_NULL for the T_BCSM. 1411 July 2002 Expires Jan 2003 1413 Information Elements Data Types M/O 1414 Call ID callID (Integer?) M 1415 Initiate Call Segment cause O 1416 Associated Call Segment [] 1417 { Call Segment Integer O 1418 Release Cause } cause O 1419 All Call Segments [] 1420 { Release Cause } cause O 1422 10. Request Notification Charging Event 1423 used by the SCF to request the SSF to monitor for a charging event 1424 and send back a notification. 1426 Information Elements Data Types M/O 1427 Call ID callID (Integer?) M 1428 Charging Events [] byte array M 1430 11. Request Report BCSM Event 1431 used by the SCF to request the SSF to monitor a call related event 1432 such as BUSY or No_Answer, and send a notification back. 1434 Information Elements Data Types M/O 1435 Call ID callID (Integer?) M 1436 BCSM Event List BCSMEvent [] M 1438 12. Trigger Data Status Request 1439 used by the SCF to request the SSF to send back the current set of 1440 fields associated with flags. 1442 Information Elements Data Types M/O 1443 Call ID callID (Integer?) M 1444 Requested Field ??? M 1445 Trigger Data Identifier ??? M 1447 Support for other SCF to SSF IFs is not envisioned for SPIRITS at this 1448 time, though additions may still be made in later versions of this 1449 document. 1451 Appendix B: XML DTD for IFs, Examples of use. 1453 In this section, we present XML DTDs for the Information Flows previously 1454 described, along with examples of their use. 1456 B.1 Conventions 1458 Throughout this internet-draft the US-ASCII coded character set, 1459 defined in ANSI X3.4-1986, is used. All SPIRITS protocol elements are 1460 defined using XML DTDs [17]. The SPIRITS protocol elements, or SPIRITS 1461 protocol operations, are composed only of the definition of the root 1462 element and the inclusion of the necessary information element DTD. 1464 July 2002 Expires Jan 2003 1466 The strings "******" and "******" denote the 1467 boundaries of an XML DTD. 1469 B.2 General DTD Syntax 1471 + One or more occurrences 1472 * Zero or more occurrences 1473 ? Optional element 1474 () A group of expressions to be matched together 1475 | OR, as in "this OR that" 1476 , Strictly ordered. Like AND, as in "this AND that" 1478 B.3 XML DTDs for INAP Information Elements 1480 These are the DTD for the commonly used elements. These DTD representations 1481 are used as building blocks in encoding the various parameters in the 1482 IFs. 1484 B.3.1 AccessCode 1486 ****** 1487 1489 1490 1491 1492 1493 1494 1495 ******** 1497 B.3.2 AllCallSegments 1499 ****** 1500 1502 1503 ******** 1505 B.3.3 AssociatedCallSegment 1507 ****** 1508 1510 1514 July 2002 Expires Jan 2003 1516 1518 1519 1520 1521 1522 1523 1524 ******** 1526 B.3.4 BCSMEvent 1528 ****** 1529 1531 1537 1565 1567 July 2002 Expires Jan 2003 1569 1571 1572 1574 1575 1577 1578 1580 1581 1583 1584 1586 1587 1589 1590 1592 1593 1595 1596 1598 1599 1601 1602 1604 1605 1607 1608 1610 1611 1613 1614 1616 1617 1619 July 2002 Expires Jan 2003 1621 1622 1624 1625 1627 1628 1630 1631 1633 1634 1636 1639 1642 1643 1645 1646 1648 1653 1656 1657 1658 1659 1661 1664 1665 1666 1667 1669 July 2002 Expires Jan 2003 1674 MidCallReportType )+ > 1676 1680 1681 1683 1684 1686 1690 1691 1692 1693 1694 ******** 1696 B.3.5 BillingChargingCharacteristics 1698 ****** 1699 1701 1703 1704 1705 1706 1707 1708 ******** 1710 B.3.6 BusyCause 1712 ****** 1713 1715 1717 1718 1719 1720 1721 1722 ******** 1724 July 2002 Expires Jan 2003 1726 B.3.7 CalledPartyNumber 1728 ****** 1729 1730 1732 1733 1734 1735 1736 1737 ******** 1739 B.3.8 CalledPartySubaddress 1741 ****** 1742 1744 1746 1747 1748 1749 1750 1751 ******** 1753 B.3.9 CallID 1755 ****** 1756 1758 1760 1761 1762 1763 1764 1765 ******** 1766 B.3.10 CallingPartyNumber 1768 ****** 1770 July 2002 Expires Jan 2003 1772 1773 1774 1775 1776 1777 1778 1779 ******** 1781 B.3.11 CallingPartySubaddress 1783 ****** 1784 1785 1786 1787 1788 1789 1790 1791 ******** 1793 B.3.12 CallSegmentID 1795 ****** 1796 1798 1799 ******** 1801 B.3.13 Carrier 1803 ****** 1804 1805 1806 1807 1808 1809 1810 1811 ******** 1813 B.3.14 ChargeNumber 1815 ****** 1816 1818 1820 1821 1823 July 2002 Expires Jan 2003 1825 1826 1827 1828 ******** 1830 B.3.15 ChargingEvent 1832 ****** 1833 1835 1840 1842 1843 1844 1845 1846 1848 1850 %sp_inap_mon.dtd; 1851 ******** 1853 B.3.16 ConnectTime 1855 ****** 1856 1857 1858 1859 1860 1861 1862 1863 1864 ******** 1866 B.3.17 DestinationRoutingAddress 1868 ****** 1869 1871 1876 July 2002 Expires Jan 2003 1878 1879 1880 1882 1883 1884 1885 1886 1887 ******** 1889 B.3.18 DialedDigits 1891 ****** 1892 1893 1894 1895 1896 1897 1898 1899 1900 ******** 1902 B.3.19 FailureCause 1904 ****** 1905 1906 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 ******** 1921 B.3.20 DisplayInformation 1923 ****** 1924 1926 1928 July 2002 Expires Jan 2003 1930 1931 1932 1933 1934 1935 ******** 1937 B.3.21 FeatureCode 1939 ****** 1940 1941 1942 1943 1944 1945 1946 1947 ******** 1949 B.3.22 FeatureRequestIndicator 1951 ****** 1952 1954 1960 1961 1963 1964 1965 1966 1968 1969 1971 1972 1973 ******** 1975 B.3.23 ForwardingCondition 1977 ****** 1978 1980 July 2002 Expires Jan 2003 1982 1987 1988 1990 1991 1993 1994 1995 ******** 1997 B.3.24 InitiateCallSegment 1999 ****** 2000 2002 2004 2005 2006 2007 2008 2009 2010 ******** 2012 B.3.25 LegID 2014 ****** 2015 2017 2021 2022 2024 2025 2026 ******** 2028 B.3.26 LegToBeCreated 2030 ****** 2032 July 2002 Expires Jan 2003 2034 2036 2037 ******** 2039 B.3.27 MonitorMode 2041 ****** 2042 2044 2049 2050 2052 2053 2055 2056 2057 ******** 2059 B.3.28 NewCallSegment 2061 ****** 2062 2064 2066 2068 %sp_inap_csi.dtd; 2069 ******** 2071 B.3.29 OriginalCalledPartyID 2073 ****** 2074 2076 2078 2079 2080 2081 2082 2083 ******** 2085 July 2002 Expires Jan 2003 2087 B.3.30 Prefix 2089 ****** 2090 2091 2092 ******** 2094 B.3.31 RedirectingPartyID 2096 ****** 2097 2099 2101 2102 2103 2104 2105 2106 ******** 2108 B.3.32 RedirectionInformation 2110 ****** 2111 2112 2113 2114 2115 2116 2117 2118 ******** 2120 B.3.33 ReleaseCause 2122 ****** 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2137 July 2002 Expires Jan 2003 2139 ******** 2141 B.3.34 ServiceAddressInformation 2143 ****** 2144 2145 2149 2150 2151 2152 2153 2154 2155 2156 2158 2161 2164 2165 2167 2168 2170 2175 2176 2178 2179 2181 2182 2183 July 2002 Expires Jan 2003 2192 AFR | 2193 SharedIOTrunk | 2194 OffHookDelay | 2195 ChannelSetupPRI | 2196 TNoAnswer | 2197 TBusy | 2198 OCalledPartyBusy | 2199 ONoAnswer | 2200 OriginationAttemptAuthorized | 2201 OAnswer | 2202 ODisconnect | 2203 TermAttemptAuthorized | 2204 TAnswer | 2205 TDisconnect ) > 2206 2207 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2222 2223 2225 2226 2228 2229 2231 2232 2233 2234 2236 2237 2239 2240 2242 July 2002 Expires Jan 2003 2244 2245 2247 2248 2250 2251 2253 2254 2256 2257 2258 ******** 2260 B.4 XML DTDs for INAP Originating Detection Points 2262 This section presents the XML encoding for Information Flows (IFs) 2263 between the SSF and the SCF. The XML building blocks for common 2264 elements defined in section B.3 are used in the XML definitions 2265 here. 2267 B.4.1 O_Abandon 2269 ****** 2270 2272 2275 2277 2278 2280 %sp_inap_csi.dtd; 2281 %sp_inap_rcs.dtd; 2282 ******** 2284 B.4.2 O_Called_Party_Busy 2286 ****** 2287 2289 July 2002 Expires Jan 2003 2294 CallingPartySubaddress?, 2295 Carrier?, 2296 OriginalCalledPartyID?, 2297 Prefix?, 2298 RedirectingPartyID?, 2299 RedirectionInformation?) > 2300 2302 2303 2304 2305 2306 2307 2308 2310 %sp_inap_bcs.dtd; 2311 %sp_inap_cgp.dtd; 2312 %sp_inap_car.dtd; 2313 %sp_inap_ocp.dtd; 2314 %sp_inap_pfx.dtd; 2315 %sp_inap_rpi.dtd; 2316 %sp_inap_rin.dtd; 2317 ******** 2319 B.4.3 O_Disconnect 2321 ****** 2322 2323 2328 2330 2331 2332 2333 2334 %sp_inap_cgp.dtd; 2335 %sp_inap_car.dtd; 2336 %sp_inap_ctm.dtd; 2337 %sp_inap_rcs.dtd; 2338 ******** 2340 B.4.4 Collected_Information 2342 July 2002 Expires Jan 2003 2344 ****** 2345 2346 2356 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 %sp_inap_acd.dtd; 2368 %sp_inap_cgp.dtd; 2369 %sp_inap_car.dtd; 2370 %sp_inap_dld.dtd; 2371 %sp_inap_fcd.dtd; 2372 %sp_inap_ocp.dtd; 2373 %sp_inap_pfx.dtd; 2374 %sp_inap_rpi.dtd; 2375 %sp_inap_rin.dtd; 2376 ******** 2378 B.4.5 Origination_Attempt_Authorized 2380 ****** 2381 2382 2387 2389 2390 2391 2393 %sp_inap_cgp.dtd; 2395 July 2002 Expires Jan 2003 2397 %sp_inap_car.dtd; 2398 %sp_inap_dld.dtd; 2399 ******** 2401 B.4.6 O_No_Answer 2403 ****** 2404 2405 2413 2415 2416 2417 2418 2419 2420 2422 %sp_inap_cgp.dtd; 2423 %sp_inap_car.dtd; 2424 %sp_inap_ocp.dtd; 2425 %sp_inap_pfx.dtd; 2426 %sp_inap_rpi.dtd; 2427 %sp_inap_rin.dtd; 2428 ******** 2430 B.4.7 O_Midcall 2432 ****** 2433 2435 2440 2442 2443 2444 2445 2447 July 2002 Expires Jan 2003 2449 %sp_inap_cdp.dtd; 2450 %sp_inap_cgp.dtd; 2451 %sp_inap_car.dtd; 2452 %sp_inap_fri.dtd; 2453 ******** 2455 B.4.8 O_Answer 2457 ****** 2458 2459 2465 2467 2468 2469 2470 2472 %sp_inap_cgp.dtd; 2473 %sp_inap_ocp.dtd; 2474 %sp_inap_rpi.dtd; 2475 %sp_inap_rin.dtd; 2476 ******** 2478 B.4.9 Analyzed_Information 2480 ****** 2481 2482 2493 2495 2496 2497 2498 2500 July 2002 Expires Jan 2003 2502 2503 2504 2505 2506 2508 %sp_inap_acd.dtd; 2509 %sp_inap_cgp.dtd; 2510 %sp_inap_car.dtd; 2511 %sp_inap_dld.dtd; 2512 %sp_inap_fcd.dtd; 2513 %sp_inap_ocp.dtd; 2514 %sp_inap_pfx.dtd; 2515 %sp_inap_rpi.dtd; 2516 %sp_inap_rin.dtd; 2517 ******** 2519 B.4.10 Route_Select_Failure 2521 ****** 2522 2523 2532 2534 2535 2536 2537 2538 2539 2540 2541 2543 %sp_inap_cgp.dtd; 2544 %sp_inap_car.dtd; 2545 %sp_inap_dld.dtd; 2546 %sp_inap_fcs.dtd; 2547 %sp_inap_ocp.dtd; 2548 %sp_inap_pfx.dtd; 2549 %sp_inap_rpi.dtd; 2550 %sp_inap_rin.dtd; 2551 ******** 2553 July 2002 Expires Jan 2003 2555 B.5 XML DTD's for INAP Terminating Detection Points 2557 This section presents the XML encoding for Information Flows (IFs) 2558 between the SCF and the SSF. The XML building blocks for common 2559 elements defined in section B.3 are used in the XML definitions 2560 here. 2562 B.5.1 Termination_Attempt_Authorized 2564 ****** 2565 2567 2574 2576 2577 2578 2579 2580 2582 %sp_inap_cdp.dtd; 2583 %sp_inap_cgp.dtd; 2584 %sp_inap_ocp.dtd; 2585 %sp_inap_rpi.dtd; 2586 %sp_inap_rin.dtd; 2587 ******** 2589 B.5.2 T_Busy 2591 ****** 2592 2594 2601 2603 July 2002 Expires Jan 2003 2605 2606 2607 2608 2609 2611 %sp_inap_bcs.dtd; 2612 %sp_inap_cdp.dtd; 2613 %sp_inap_ocp.dtd; 2614 %sp_inap_rpi.dtd; 2615 %sp_inap_rin.dtd; 2616 ******** 2618 B.5.3 Facility_Selected_and_Available 2620 ****** 2621 2623 2630 2632 2633 2634 2635 2636 2638 %sp_inap_cdp.dtd; 2639 %sp_inap_cgn.dtd; 2640 %sp_inap_ocp.dtd; 2641 %sp_inap_rpi.dtd; 2642 %sp_inap_rin.dtd; 2643 ******** 2645 B.5.4 T_No_Answer 2647 ****** 2648 2650 July 2002 Expires Jan 2003 2658 RedirectingPartyID?, 2659 RedirectionInformation? ) > 2661 2663 2664 2665 2666 2667 2668 2670 %sp_inap_sai.dtd; 2671 %sp_inap_cdn.dtd; 2672 %sp_inap_cdp.dtd; 2673 %sp_inap_ocp.dtd; 2674 %sp_inap_rpi.dtd; 2675 %sp_inap_rin.dtd; 2676 ******** 2678 B.5.5 T_Answer 2680 ****** 2681 2683 2687 2688 2689 2690 2691 %sp_inap_sai.dtd; 2692 %sp_inap_cdn.dtd; 2693 %sp_inap_cdp.dtd; 2694 ******** 2696 B.5.6 T_Midcall 2698 ****** 2699 2700 2706 2708 July 2002 Expires Jan 2003 2710 2711 2712 2713 2715 %sp_inap_cdp.dtd; 2716 %sp_inap_cgp.dtd; 2717 %sp_inap_car.dtd; 2718 %sp_inap_fri.dtd; 2719 ******** 2721 B.5.7 T_Disconnect 2723 ****** 2724 2725 2729 2731 2732 2733 2735 %sp_inap_cdp.dtd; 2736 %sp_inap_ctm.dtd; 2737 %sp_inap_rcs.dtd; 2738 ******** 2740 B.6 XML encoding for IFs from the SCF to the SSF 2742 B.6.1 Analyse_Information 2744 ****** 2745 2747 2756 2758 2759 2761 July 2002 Expires Jan 2003 2763 2764 2765 2766 2767 2769 %sp_inap_cid.dtd; 2770 %sp_inap_dra.dtd; 2771 %sp_inap_csi.dtd; 2772 %sp_inap_cgn.dtd; 2773 %sp_inap_cdn.dtd; 2774 %sp_inap_car.dtd; 2775 %sp_inap_chn.dtd; 2776 ******** 2778 B.6.2 Authorise_Termination 2780 ****** 2781 2783 2789 2791 2792 2793 2794 2796 %sp_inap_cid.dtd; 2797 %sp_inap_cgn.dtd; 2798 %sp_inap_ocp.dtd; 2799 %sp_inap_lid.dtd; 2800 ******** 2802 B.6.3 Collect_Information 2804 ****** 2805 2807 2813 July 2002 Expires Jan 2003 2815 2817 2818 2819 2820 2822 %sp_inap_cid.dtd; 2823 %sp_inap_cgn.dtd; 2824 %sp_inap_cdn.dtd; 2825 %sp_inap_ocp.dtd; 2826 ******** 2828 B.6.4 Connect 2830 ****** 2831 2833 2844 2846 2847 2848 2849 2850 2851 2852 2853 2854 2856 %sp_inap_cid.dtd; 2857 %sp_inap_dra.dtd; 2858 %sp_inap_fwc.dtd; 2859 %sp_inap_car.dtd; 2860 %sp_inap_rpi.dtd; 2861 %sp_inap_rin.dtd; 2862 %sp_inap_dyi.dtd; 2863 %sp_inap_chn.dtd; 2864 %sp_inap_csi.dtd; 2866 July 2002 Expires Jan 2003 2868 ******** 2870 B.6.5 Continue 2872 ****** 2873 2875 2877 2879 2880 2881 2882 2883 2884 2885 ******** 2887 B.6.6 Furnish_Charging_Information 2889 ****** 2890 2892 2896 2898 2899 2901 %sp_inap_cid.dtd; 2902 %sp_inap_bcc.dtd; 2903 ******** 2905 B.6.7 Hold_Call_In_Network 2907 ****** 2908 2910 2912 2914 2915 2916 2917 2919 July 2002 Expires Jan 2003 2921 2922 2923 ******** 2925 B.6.8 Initiate_Call_Attempt 2927 ****** 2928 2930 2936 2938 2939 2940 2941 2943 %sp_inap_cid.dtd; 2944 %sp_inap_ltc.dtd; 2945 %sp_inap_ncs.dtd; 2946 %sp_inap_dra.dtd; 2947 ******** 2949 B.6.9 Release_Call 2951 ****** 2952 2954 2960 2962 2963 2964 2965 2967 %sp_inap_cid.dtd; 2968 %sp_inap_ics.dtd; 2969 %sp_inap_acs.dtd; 2970 %sp_inap_xcs.dtd; 2972 July 2002 Expires Jan 2003 2974 ******** 2976 B.6.10 Request_Notification_Charging_Event 2978 ****** 2979 2981 2985 2987 2988 2990 %sp_inap_cid.dtd; 2991 %sp_inap_che.dtd; 2992 ******** 2994 B.6.11 Request_Report_BCSM_Event 2996 ****** 2997 2999 3003 3005 3006 3008 %sp_inap_cid.dtd; 3009 %sp_inap_evt.dtd; 3010 ******** 3012 B.6.12 Trigger_Data_Status_Request 3014 ****** 3015 3017 3019 3021 3022 3023 3025 July 2002 Expires Jan 2003 3027 3028 3029 3030 ******** 3032 B.7 Examples 3034 B.7.1 XML encoded T_No_Answer 3036 3037 3038 3039 3040 5 3041 3042 1 3043 0 3044 3045 25 3046 3047 31356871684 3048 31356872387 3049 31356871424 3050 3052 Appendix C: Supporting Parlay Interfaces 3054 C.1 Introduction: 3055 As previously stated, Parlay is a family of APIs defined by an 3056 industry consortium seeking to standardize a set of abstract high- 3057 level interfaces for use by third-party programmers so they may 3058 build applications that leverage services and functionality exposed 3059 by networks of telecommunication elements. Parlay supports APIs for 3060 diverse areas such as call control, user location, user interaction, 3061 messaging etc., In this appendix, we study issues related to Parlay 3062 encoding of IN parameters. 3064 Figure 4 depicts how third-party SPIRITS applications may be supported 3065 via Parlay. 3067 +--------------+ 3068 |3rd Party ASP | 3069 | IP Host | 3070 | | +--------------+ 3071 |+-----------+ | | +----------+ | 3072 || Parlay | | B | | SPIRITS | | 3073 ||Application+<------/-------->+ Gateway | | 3074 |+-----------+ | Parlay API | +--------+-+ | 3075 +--------------+ +----------^---+ 3077 July 2002 Expires Jan 2003 3079 | 3080 IP Network | 3081 -----------------------------------------|---- 3082 PSTN / C 3083 | SIP {Parlay or INAP} 3084 v 3085 +----+------+ 3086 | SPIRITS | 3087 | Client | 3088 +-------------------+ +---+-----D-----+--+ 3089 | Service Switching |INAP/SS7 | Service Control | 3090 | Function +---------+ Function | 3091 +-------------------+ +------------------+ 3093 Figure 4: Supporting Parlay-based SPIRITS services. 3095 One debate that continues to rage in the industry today is that of 3096 protocols vs. APIs. In this section, we study how each of these 3097 approaches may be beneficial to the SPIRITS context if appropriately 3098 used. 3100 The Parlay API is a convenient means available to expose network 3101 hosted service capabilities to third party programmers. As depicted in 3102 figure 2, this API may be used to provide a means to more effectively 3103 program an application that uses SIP message capabilities to 3104 communicate with the SPIRITS client colocated with the SCP entity. 3106 Security aspects from the Parlay standpoint are covered by a 3107 third-party application's interaction with the Parlay framework 3108 component, which may be colocated with the SPIRITS gateway. The 3109 third-party application must first successfully complete a Parlay 3110 handshake involving aspects of mutual authentication, access control 3111 and service discovery before being permitted to gain access to network 3112 hosted services. The interested reader is referred to [3] for details. 3114 Although this document specifically uses Parlay as a base for the 3115 selection of INAP parameters to be carried by the SPIRITS Protocol, 3116 the ideas presented here are equally applicable to the Open Service 3117 Access (OSA) architecture and API as defined by the Third Generation 3118 Partnership Project (3GPP) [4]. 3120 C.2 Introduction to the Parlay Call Control (CC) API 3122 Parlay defines several interfaces for call control, each with its own 3123 specific set of functionality. More specifically, the set of Parlay 3124 specifications includes interfaces for the following [20]: 3126 o Generic Call Control 3127 This interface provides simple means for controlling a call 3128 that only involves one originating and one terminating party. 3130 July 2002 Expires Jan 2003 3132 o MultiParty Call Control 3133 The MultiParty Call Control interface specifies an API that 3134 provides the ability to control and manage calls or sessions 3135 that involve two or more parties. Call leg manipulation 3136 functionality is offered by this interface and call events 3137 can be reported to the application for each specific call leg. 3139 o Multimedia Call Control 3140 Multimedia Call Control is a specialization of MultiParty Call 3141 Control in that it includes the concept of media channels 3142 associated with the legs in a call. 3144 o Conferencing Call Control 3145 This interface in turn is a specialization of the Multimedia 3146 Call Control interface. The interface provides functionality 3147 for bridging, splitting off parties from a multiparty call to 3148 form sub-conferences, etc. 3150 For each of these call control interfaces, the Parlay specification 3151 includes a Call Model (CM) in the form of a State Transition Diagram 3152 (STD). The STD represents the application view of the call, i.e. only 3153 call states observable by the application through the interface 3154 methods that are being invoked, are modelled by the CM. That implies 3155 that certain network call states are not visible to the application. 3157 For the remainder of this draft the focus will be on the MultiParty 3158 Call Control (MP CC) interface. Section C.4 will elaborate on this 3159 interface and study its functionality in greater detail. 3161 C.3 Parlay and SPIRITS 3163 The main body of this draft, along with material in appendices A and B 3164 describes how the SPIRITS protocol may be used to encode INAP parameters 3165 into the contents of a SIP message so that SPIRITS-capable elements may 3166 provide services to end-points in the PSTN. Appendices C-F build upon 3167 the discussion presented there, by describing how one might support 3168 Parlay-encoding of said parameters so that: 3169 a. applications providing SPIRITS services may conveniently be built 3170 to Parlay interfaces, and 3171 b. a common network protocol independent encoding of parameters may 3172 be exposed to SPIRITS applications via a widely supported third- 3173 party API such as Parlay. 3175 Note that while this appendix presents Parlay as the open API of choice, 3176 a similar mapping may be done to any other API of interest that gains in 3177 popularity. Specifically OSA as defined by 3GPP [4] is applicable here 3178 due to its similarities with Parlay. 3180 July 2002 Expires Jan 2003 3182 C.4 Details of the Parlay CC API 3184 In this section we study the MP CC API in greater detail, look at the 3185 method calls in each interface (as relevant), and the datatypes that 3186 are used (where we focus on the subset that is used in the XML 3187 Encoding that can be found in Appendices D and E). 3189 The MP CC API is made up of three interfaces, being the Call Control 3190 Manager interface, the Call interface, and the Call Leg interface. The 3191 Call Control Manager interface allows the application programmer to 3192 provide overload control functionality, create call objects and to 3193 request the enabling or disabling of call-related event notifications 3194 from the network. The Call interface provides the means for an 3195 application to control the routing of a specific call, to request 3196 information from the network for this call, control the charging of 3197 the call, to release the call and to perform time-based supervision 3198 for the call. Call leg manipulation is performed through the Call 3199 interface. The Call Leg interface represents a specific party in the 3200 call that is modeled by the Call interface. The application can use 3201 the Call Leg interface to request the network to be notified of leg 3202 specific events, such as for instance the fact that the originating 3203 party has disconnected from the call. 3205 C.4.1 Parlay MultiParty Call Leg Models 3207 Parlay has defined two call models, one for originating call legs 3208 and one for terminating call legs. The START and STOP state 3209 represent the instantiation and destruction of a call leg object. 3211 No events are reported in these states and no Parlay API methods 3212 can be invoked. For a more elaborate discussion on the call leg 3213 models the reader is referred to [20]. In the event a call leg 3214 object is relased by the Parlay application, the transition in the 3215 call mode is labelled "Release". In the event a call leg object 3216 is released by the SPIRITS gateway, the transition is labelled 3217 "NetworkRelease". In both cases the data value P_CALL_EVENT_RELEASE 3218 is used, see section 4.1.3. 3220 C.4.1.1 Parlay Call Model for Originating Call Legs 3222 In the INITIATING state a new call leg object has been created and 3223 the address of the originating party has been collected by the 3224 network. 3226 In the ANALYSING state additional digits to those already received 3227 can be collected. Address analysis can commence upon completion of 3228 address collection. 3230 The ACTIVE state is entered when the address gas been analyzed. Mid 3231 call events can be received in the ACTIVE state. 3233 July 2002 Expires Jan 2003 3235 In the RELEASING state all the requested reports have been processed 3236 and sent to the application that had requested them. 3238 The eventReportReq method of the MultiParty Call Control interface 3239 can be invoked in any state, except for the RELEASING state. 3241 July 2002 Expires Jan 2003 3243 +-------+ 3244 | Start | 3245 +-------+ 3246 OriginatingCallAttemptAuthorized | 3247 +------+ | 3248 | | | 3249 NetworkRelease +--+------v--+ OriginatingCallAttempt | 3250 +-----------<-----| Initiating |--<---------------------------+ 3251 | +------------+ Orig.CallAttemptAuthorized | 3252 | | | 3253 | | | 3254 | v AddressCollected | 3255 | | | 3256 | AddressCollected | | 3257 | +-----+ | | 3258 | | | | | 3259 | | +--v--+-----+ | 3260 | +--+ | AddressCollected | 3261 +-----------<-----| Analysing |--<----------------------------+ 3262 | NetworkRelease | | | 3263 | +-----------+ | 3264 | | | 3265 | v AddressAnalysed | 3266 | +-----+ | | 3267 v | | | | 3268 | Originating | +-v------+ AddressAnalysed | 3269 | Service | | Active |----<----------------------------+ 3270 | Code | +-+------+ | 3271 | | | | | 3272 | +-----+ | | 3273 | | | 3274 +---------->-------+ v NetworkRelease | 3275 | | | 3276 Release +-v---------+ Originating Release | 3277 +---->----| Releasing |---<----------------------------+ 3278 | +-----------+ 3279 +------------+ 3280 | All States | 3281 +------------+ 3282 | 3283 | +------+ 3284 +---->------------------------| Stop | 3285 "call leg object deassigned" +------+ 3287 Figure 5: The Parlay Originating Call Leg Model 3289 July 2002 Expires Jan 2003 3291 C.4.1.2 Parlay Call Model for Terminating Call Legs 3293 In the IDLE state the call object is created. In this state the 3294 call leg can be routed to a specified target address. 3296 For a description of the RELEASING state, the reader is referred 3297 to section 4.1.1. 3299 +-------+ 3300 | Start | 3301 +-------+ 3302 +------+ "call leg object created" | 3303 | Idle |-----<---------------------------+ 3304 +------+ | 3305 | | 3306 | | 3307 "call leg object routed" v | 3308 | | 3309 | | 3310 | TerminatingCallAttempt | 3311 | TerminatingCallAttemptAuthorised | 3312 | Alerting v 3313 | Answer | 3314 Term.CallAttemptAuthorised | TerminatingServiceCode | 3315 TerminatingServiceCode | Redirected | 3316 Answer +-------+ | Queued | 3317 Alerting | | | | 3318 Redirected | +-v------+ | 3319 Queued | | Active |----<---------------------------+ 3320 | +-+------+ | 3321 | | | | 3322 +-------+ | | 3323 v NetworkRelease | 3324 | | 3325 Release +-----------+ TerminatingRelease | 3326 +--->----| Releasing |--<---------------------------+ 3327 | +-----------+ 3328 +------------+ 3329 | All States | 3330 +------------+ 3331 | 3332 | +------+ 3333 +--->--------------------------| Stop | 3334 "call leg object deassigned" +------+ 3336 Figure 6: The Parlay Terminating Call Leg Model 3338 Appendix D: Parlay Methods and Data Types. 3340 D.1 Details of Event Arming and Reporting in the MP CC API 3342 July 2002 Expires Jan 2003 3344 For the purpose of this internet draft the event enabling and 3345 reporting functionality is of specific interest. The functionality for 3346 static trigger arming and reporting is provided by the Call Control 3347 Manager interface of the MP CC API. The Call Leg interface includes 3348 the capabilities for the arming and reporting of the dynamic triggers. 3349 The means to arm static triggers is considered to be out of the scope 3350 of this SPIRITS draft. 3352 D.1.1 EventReportReq 3354 This Parlay method is used by the Parlay Application to set, clear or 3355 change the specific criteria for a dynamic event for a specific call 3356 leg. Only events that meet these criteria are reported. The parameter 3357 that is passed in this method to specify the set of requested events 3358 is defined as a sequence that consists of the following data types: 3360 CallEventType 3361 Defines a specific call, or call leg event report type. Examples 3362 include "address analyzed", "answer", and "release". 3364 CallMonitorMode 3365 Defines the mode that the call or call leg will monitor for events, 3366 or the mode that the call or call leg is in following a detected 3367 event. The supported monitor modes are "interrupt", "notify", and 3368 "do not monitor". 3370 AdditionalCallEventInfo 3371 Specifies additional call event information for certain types of 3372 events. For instance, for the "release" event, the specific release 3373 cause is specified, such as for instance "disconnect" or "routing 3374 failure". 3376 D.1.2 EventReportRes 3378 This Parlay method reports to the Parlay Application that an event has 3379 occurred that was requested to be reported. Depending on the type of 3380 the reported event, outstanding requests for events are discarded. For 3381 instance if the "answer" event is reported, the "routing failure" 3382 event can be disarmed. The parameters that are passed specify the 3383 reported event along with additional information regarding this 3384 reported event. These are the same parameters as specified for the 3385 EventReportReq method, with the addition of the time when the event 3386 occurred. 3388 CallEventType 3389 For description see section D.1 3391 CallMonitorMode 3392 For description see section D.1 3394 July 2002 Expires Jan 2003 3396 CallEventTime 3397 The date and time when the reported event occurred in the network. 3399 AdditionalCallEventInfo 3400 For description see section D.1 3402 D.1.3 EventReportErr 3404 This Parlay method indicates to the Parlay Application that the 3405 request to manage call leg event reports was unsuccessful. The reason 3406 for the error is passed as a parameter, as well as the time when the 3407 error occurred. 3409 ErrorType 3410 Specifies the specific error that caused the request for call leg 3411 event reports to fail. E.g. when the request was issued for an 3412 invalid address. 3414 ErrorTime 3415 The date and time when the error occurred in the network. 3417 AdditionalErrorInfo 3418 Specifies additional error information for certain error types. For 3419 instance if the error was caused by an invalid address, the 3420 additional error information may specify the reason why this 3421 particular address was invalid. E.g. an incomplete address or an 3422 address out of range. 3424 D.1.4 ReportNotification 3426 This Parlay method notifies the Parlay Application of the arrival of a 3427 call-related or call leg-related static event. The event and the data 3428 associated with it are passed as a parameter. 3430 NotificationInfo 3431 Specifies the data associated with this static event. E.g. the 3432 originating or terminating leg which reports the notification. 3434 D.2 Relation between Parlay and CAMEL 3436 The Third Generation Partnership Project (3GPP) develops Intelligent 3437 Networking standards applicable to wireless networks. These wireless 3438 network IN standard specifications are known as Customised 3439 Applications for Mobile network Enhanced Logic, or CAMEL. The Call 3440 Models for CAMEL, although based on IN CS-1 and CS-2, are slightly 3441 different than the Basic Call State Models (BCSMs) for IN as specified 3442 by the ITU-T [13]. In [21] 3GPP have provided mappings for the CAMEL 3443 Originating BCSM states to the Parlay events. These CAMEL mappings are 3445 July 2002 Expires Jan 2003 3447 provided here for illustrative purposes. 3449 +------------------------------------------------------------------+ 3450 | Originating BCSM States and corresponding Parlay Events | 3451 +--------------------------+---------------------------------------+ 3452 | O_Called_Party_Busy | P_CALL_EVENT_ORIGINATING_RELEASE | 3453 | | (P_BUSY) | 3454 | O_Disconnect | P_CALL_EVENT_ORIGINATING_RELEASE | 3455 | | (P_DISCONNECT) | 3456 | Collected_Information | P_CALL_EVENT_ADDRESS_COLLECTED | 3457 | Orig._Attempt_Authorized | P_CALL_EVENT_ORIG_CALL_ATTEMPT_AUTH * | 3458 | O_No_Answer | P_CALL_EVENT_ORIGINATING_RELEASE | 3459 | | (P_NO_ANSWER) | 3460 | O_MidCall | P_CALL_EVENT_ORIGINATING_SERVICE_CODE | 3461 | | (P_CALL_SERVICE_CODE_[?]) | 3462 | O_Answer | P_CALL_EVENT_ANSWER | 3463 | Analyzed_Information | P_CALL_EVENT_ADDRESS_ANALYZED | 3464 | Route_Select_Failure | P_CALL_EVENT_ORIGINATING_RELEASE | 3465 | | (P_ROUTING_FAILURE) | 3466 +--------------------------+---------------------------------------+ 3468 * full name is P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED 3470 Table 2: Map of O-BCSM States to Parlay events 3472 +--------------------------------------------------------------------+ 3473 | Terminating BCSM States and corresponding Parlay Events | 3474 +-------------------------------+------------------------------------+ 3475 | Termination_Attempt_Authorized| P_CALL_EVENT_TERM_CALL_ATMPT_AUTH *| 3476 | T_Abandon | P_CALL_EVENT_TERMINATING_RELEASE | 3477 | | (P_PREMATURE_DISCONNECT) | 3478 | T_Busy | P_CALL_EVENT_TERMINATING_RELEASE | 3479 | | (P_BUSY) | 3480 | T_No_Answer | P_CALL_EVENT_TERMINATING_RELEASE | 3481 | | (P_NO_ANSWER) | 3482 | T_Answer | P_CALL_EVENT_ANSWER | 3483 | T_MidCall | P_CALL_EVENT_TERM_SERVICE_CODE ^ | 3484 | | (P_CALL_SERVICE_CODE_[?]) | 3485 | T_Disconnect | P_CALL_EVENT_TERMINATING_RELEASE | 3486 | | (P_DISCONNECT) | 3487 +-------------------------------+------------------------------------+ 3489 * full name is P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED 3490 ^ full name is P_CALL_EVENT_TERMINATING_SERVICE_CODE 3492 Table 3: Map of T-BCSM States to Parlay events 3494 This map may be utilized by the SPIRITS client in converting any 3495 received INAP messages into the corresponding Parlay events for 3496 encoding into a SPIRITS-compliant format. 3498 July 2002 Expires Jan 2003 3500 D.3 Sample Message Flows 3502 As described in the main body of this draft, trigger detection points 3503 or TDPs associated with static triggers will be armed through the 3504 Service Management System, while event detection points or EDPs 3505 associated with dynamic triggers are armed through interactions 3506 between the SCF and the call processing element. 3508 In recommended SPIRITS operation, SIP messages such as the 3509 REGISTER-INVITE-200 OK [2] sequence are used to support static 3510 triggers, while the SUBSCRIBE-NOTIFY-200 OK [5] sequence is exchanged 3511 to support dynamic triggers. A more elaborate description of the usage 3512 of SIP for the SPIRITS protocol can be found in [16]. Note that in 3513 either case, where a Parlay-compliant solution is deployed, these 3514 messages are exchanged between the SPIRITS Client and the SPIRITS 3515 Gateway, with Parlay API methods being received at the Gateway, or 3516 call-back methods being invoked by the Gateway on the application 3517 (IpApp... interface) as necessary. 3519 Some more details of the call flows are presented in Appendix F. 3521 Appendix E: XML definitions for Parlay Encoding of SPIRITS Data 3523 E.1 Terminology 3525 Protocol Element - The XML DTD root element definition for a SPIRITS 3526 protocol operation. 3527 Common Element - The XML DTD element definition for common data 3528 types that are being used in the protocol element 3529 definitions. 3530 E.2 Use of XML 3532 As discussed in the main body of the draft, XML is a convenient means 3533 of encoding data relevant to the SPIRITS context. In the sections that 3534 follow, we show how XML may be used to encode Parlay parameters. 3536 E.2.1 Conventions 3538 Throughout this internet-draft the US-ASCII coded character set, 3539 defined in ANSI X3.4-1986, is used. All SPIRITS protocol elements 3540 are defined using XML DTDs [17]. The SPIRITS protocol elements, or 3541 SPIRITS protocol operations, are composed only of the definition of 3542 the root element and the inclusion of the necessary protocol element 3543 DTD. 3545 The strings "******" and "******" denote the 3546 boundaries of an XML DTD. 3548 E.2.2 General DTD Syntax 3550 July 2002 Expires Jan 2003 3552 + One or more occurrences 3553 * Zero or more occurrences 3554 ? Optional element 3555 () A group of expressions to be matched together 3556 | OR, as in "this OR that" 3557 , Strictly ordered. Like AND, as in "this AND that" 3559 E.3 Protocol Operations 3561 E.3.1 Event Report Request 3563 ************************* 3564 3565 3569 3571 3572 3573 3575 %spirits_cet.dtd; 3576 %spirits_cmm.dtd; 3577 %spirits_aci.dtd; 3578 *************************** 3580 E.3.1.1 Example of an Event Report Request 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3593 E.3.2 Event Report Result 3595 ************************* 3596 3597 July 2002 Expires Jan 2003 3604 ADDITIONAL_CALL_EVENT_INFO* ) > 3605 3607 3608 3609 3610 3612 %spirits_cet.dtd; 3613 %spirits_cmm.dtd; 3614 %spirits_ctm.dtd; 3615 %spirits_aci.dtd; 3616 *************************** 3618 E.3.2.1 Example of an Event Report Result 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 1998-12-04 10:30 3631 3632 3634 E.3.3 Event Report Error 3636 ************************* 3637 3639 3643 3644 3645 3646 3648 %spirits_etm.dtd; 3649 %spirits_etp.dtd; 3650 %spirits_aei.dtd; 3651 *************************** 3653 July 2002 Expires Jan 2003 3655 E.3.3.1 Example of an Event Report Error 3657 3658 3659 3660 3661 1998-12-04 10:30 3662 3663 3664 3665 3666 3667 3668 3669 3671 E.3.4 Report Notification 3673 ************************* 3674 3676 3678 3680 3682 %spirits_nif.dtd; 3683 *************************** 3685 E.3.4.1 Example of a Report Notification 3687 3688 3689 3690 3691
3692 3693 3694 3695 1800PIZZA 3696 3697 3698 3699 3700
3701 3702 3703
3704 3706 July 2002 Expires Jan 2003 3708 3709 3710 31356871684 3711 3712 3713 3714 3715
3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 1998-12-04 10:30 3731 3732 3733 3735 E.4 Common Element Definitions 3737 E.4.1 CallEventType 3739 ************************* 3740 3741 3758 July 2002 Expires Jan 2003 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 *************************** 3777 E.4.2 CallMonitorMode 3779 ************************* 3780 3781 3786 3787 3788 3789 *************************** 3791 E.4.3 AdditionalCallEventInfo 3793 ************************* 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3806 July 2002 Expires Jan 2003 3813 (P_CALL_EVENT_ADDRESS_ANALYZED, ACI_ELEMENT_VALUE_ADDR_ANALYZED) | 3814 (P_CALL_EVENT_PROGRESS , ACI_ELEMENT_VALUE_PROGRESS) | 3815 (P_CALL_EVENT_ALERTING , ACI_ELEMENT_VALUE_ALERTING) | 3816 (P_CALL_EVENT_ANSWER , ACI_ELEMENT_VALUE_ANSWER) | 3817 (P_CALL_EVENT_RELEASE , ACI_ELEMENT_VALUE_RELEASE) | 3818 (P_CALL_EVENT_REDIRECTED , ACI_ELEMENT_VALUE_REDIRECTED) | 3819 (P_CALL_EVENT_SERVICE_CODE , ACI_ELEMENT_VALUE_SERVICE_CODE) ) > 3821 3822 3824 3825 3827 3829 3831 3832 3834 3835 3837 3838 3840 3853 3855 3863 July 2002 Expires Jan 2003 3865 3866 3867 3868 3869 3870 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3884 3885 3886 3887 3888 3889 3891 3892 3893 3894 3895 3896 3898 3900 %spirits_adr.dtd; 3901 *************************** 3903 E.4.4 CallEventTime 3905 ************************* 3906 3907 3908 *************************** 3910 E.4.5 ErrorTime 3912 ************************* 3913 3914 3916 July 2002 Expires Jan 2003 3918 *************************** 3920 E.4.6 ErrorType 3922 ************************* 3923 3924 3929 3930 3931 3933 *************************** 3935 E.4.7 AdditionalErrorInfo 3937 ************************* 3938 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3951 3956 3957 3959 3967 3969 July 2002 Expires Jan 2003 3971 3972 3973 3974 3975 3976 3977 3979 3980 3981 3982 3983 3984 3985 *************************** 3987 E.4.8 Notification Info 3988 ************************* 3989 3990 3995 4000 4012 4018 4020 4022 July 2002 Expires Jan 2003 4024 4026 4027 4029 4031 4039 4068 July 2002 Expires Jan 2003 4076 P_CALL_BEARER_SERVICE_AUDIO | 4077 P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTEDTONES | 4078 P_CALL_BEARER_SERVICE_VIDEO ) > 4080 4093 4095 4096 4098 4100 4102 4103 4104 4105 4106 4108 4109 4110 4111 4112 4113 4115 4116 4117 4118 4119 4121 4122 4123 4124 4125 4127 July 2002 Expires Jan 2003 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4152 4153 4154 4155 4156 4158 4159 4160 4161 4162 4163 4164 4166 4167 4168 4169 4170 4172 4173 4174 4175 4176 4177 4178 4180 July 2002 Expires Jan 2003 4182 4183 4184 4185 4187 4188 4189 4190 4192 %spirits_adr.dtd; 4193 %spirits_cet.dtd; 4194 %spirits_cmm.dtd; 4195 %spirits_ctm.dtd; 4196 *************************** 4198 E.4.9 ADDRESS 4200 ************************* 4201 4203 4211 4216 4217 4218 4220 4222 4224 4230 July 2002 Expires Jan 2003 4235 P_ADDRESS_SCREENING_USER_VERIFIED_PASSED | 4236 P_ADDRESS_SCREENING_USER_NOT_VERIFIED | 4237 P_ADDRESS_SCREENING_USER_VERIFIED_FAILED | 4238 P_ADDRESS_SCREENING_NETWORK ) > 4240 4242 4243 4244 4245 4246 4248 4249 4250 4251 4253 4254 4255 4256 4257 4259 4260 4261 4262 4263 4265 *************************** 4267 E.4.10 The #PCDATA elements 4269 The #PCDATA elements for 'time' elements are described below: 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4286 July 2002 Expires Jan 2003 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4304 The #PCDATA element for CALL_ALERTING_MECHANISM is described below: 4306 4307 4308 4309 4310 4311 4312 4313 4315 The #PCDATA element for CALL_APP_GENERIC_INFO is described below: 4317 4318 4319 4320 4321 4322 4323 4325 The #PCDATA element for ADDRESS_STRING is described below: 4327 4328 4329 4330 4331 4332 4333 4334 4336 The #PCDATA element for ADDRESS_NAME is described below: 4338 July 2002 Expires Jan 2003 4340 4341 4342 4343 4344 4345 4346 4348 The #PCDATA element for SUB_ADDRESS_STRING is described below: 4350 4351 4352 4353 4354 4355 4356 4357 4359 Appendix F: XSD definitions for Parlay Encoding of SPIRITS Data 4361 F.1 Use of XSD 4363 As mentioned in earlier sections, the SPIRITS protocol is a protocol 4364 through which the PSTN can request actions (services) to be carried 4365 out in the IP network in response to events occurring within the PSTN/IN. 4367 The previous appendix presented XML encoded INAP CS-2 parameters 4368 and XML encoded Parlay parameters which the SPIRITS protocol could 4369 transport from the PSTN into the IP network. These XML encodings were 4370 constructed in a manual exercise from the ASN.1 sources in case of INAP 4371 and the IDL sources in case of Parlay. 4373 In this appendix, we report on an exercise of generating and validating 4374 the XML Schema (XSD) encodings using publically available tools and 4375 scripts. We also provide some recommendations for the specification of 4376 the parameters and data types of the SPIRITS protocol. 4378 This appendix promotes the need to define a solution for parameter 4379 encoding that can be applied to any flavor of INAP (any Capability Set, 4380 any regional variant, fixed and mobile, i.e. CAMEL), as well as to any 4381 flavor of Parlay (any Parlay version and any Parlay interface, including 4382 e.g Generic Call Control and Multi Party Call Control). In other words, 4383 a solution which obviates the need to "manually" define an XML 4384 representation for each INAP or Parlay variant for use by the SPIRITS 4385 architecture would be preferable. 4387 This solution would provide the following benefits: 4389 July 2002 Expires Jan 2003 4391 - Avoid the "manual" exercise to define XML encodings, which is 4392 laborious and error prone. 4393 - Ensure full alignment between the ASN.1 definitions and the XML 4394 representation thereof, as well as between the IDL definitions 4395 and the XML representation thereof. 4396 - Can be applied to any flavour of INAP and any flavour and version 4397 of Parlay 4398 - Any change or modification to the ASN.1 or the IDL definitions can 4399 be easily carried over to the XML encodings 4400 - The XML encodings and the examples are validated 4402 Throughout this appendix references are made to Parlay. It should 4403 be noted that regarding the API package of interest to the SPIRITS 4404 protocol, i.e. MultiParty Call Control, the API interface definitions 4405 are being specified in a joint collaboration between Parlay and 3GPP 4406 OSA. At every point in this appendix where Parlay is mentioned, OSA 4407 is equally applicable. 4409 F.1.1 XSD details 4411 The current XML encodings in the earlier appendix make use of XML DTDs 4412 (Document Type Definitions). The DTDs specify the content and layout 4413 for the XML encodings of the SPIRITS protocol data types and parameters. 4414 XML definitions making use of XML DTDs can be validated using an XML 4415 parser. One drawback of DTDs is that they have their own particular 4416 syntax; they are not specified in XML syntax themselves. This implies 4417 that the XML DTDs themselves cannot be validated using the same XML 4418 parser used to validate the XML files that make use of those XML DTDs. 4419 Another drawback is the limited support for types and namespaces. 4421 These drawbacks are overcome by XML Schemas [4,5]. These XML schemas 4422 are defined using XSD (XML Schema Definition). An XSD schema defines 4423 the elements, attributes, and data types that conform to XML syntax. 4424 This means that an XML XSD can be validated using an XML parser. XSD 4425 also offers support for namespaces. Additionally, as XSDs conform to 4426 XML syntax, protocol designers and implementers only need to be 4427 familiar with one language syntax, i.e. XML, in stead of two, namely 4428 XML and DTD. XML Schemas are type safe and come with a set of predefined 4429 simple types, where DTD only accepts one type: string. 4431 More importantly, XML schemas allow the programmer to define data types 4432 as well as to restrict, redefine and extend them in a manner similar 4433 to inheritance in object oriented programming languages. This latter 4434 attribute of schemas enables modularity, extensibility and reuse of XML 4435 Schemas. Extensibility is useful in a manner similar to adding behavior 4436 by using inheritance in an object-oriented language. 4438 This appendix recommends the use of XSD rather than XML DTD for 4439 the specification of the SPIRITS protocol parameters and data types. 4441 July 2002 Expires Jan 2003 4443 F.1.2 The XML Schema Generation Process 4445 This section describes the process that was used to construct the XML 4446 encodings. Section 3.1 describes the process for the Parlay IDL 4447 definitions, whereas section 3.2 describes the process for the INAP 4448 ASN.1 definitions. 4450 F.1.2.1 IDL to XML 4452 This exercise was performed for the XML DTDs contained in appendix E. 4453 The Parlay methods, parameters and data types are specified in IDL 4454 (Interface Definition Language) [6]. 4456 The Object Management Group (OMG) has issued a Request For Proposal [7], 4457 which solicits proposals for the support of IDL to XML and IDL to WSDL 4458 mappings. The relevance to the SPIRITS Protocol work is that Parlay method 4459 invocations, as well as the parameters and data types, are defined in IDL 4460 for which the XML language mappings are requested. The initial submission 4461 to this RFP is dated from June 2001 [8], and describes a proposal for IDL 4462 to XML Schema mappings. Chapter 3 of [8] describes XML Schema constructs 4463 used to describe each IDL construct. 4465 Unfortunately, this work is still ongoing and has not yet matured. 4466 Therefore the approach taken here is to use the 'hand-crafted' XML DTDs 4467 from the earlier appendix and work from those as a starting point. 4469 The following process was followed: 4471 Step 1 - Validate the XML DTDs and the XML Examples. Step 2 - Generate XSDs 4472 from the DTDs. Step 3 - Validate the XSD Examples. 4474 It is important to note that this step-wise process can be repeated as 4475 is for XML DTDs automatically generated from the IDL, once the OMG 4476 specifications [7,8] are completed and tool support is available. 4478 Step 1 - Validate the XML DTDs and the XML Examples. 4480 We used Xerces [9] which is a publically available XML parser that 4481 supports the XML 1.0 recommendation. The hand-crafted XML DTDs from 4482 Appendix E served as input. Minor syntactic corrections were made to 4483 the XML DTDs, as a result of the validation process. Furthermore, 4484 updates were made to reflect the latest approved version of the Parlay 4485 specification [10]. The latter are mainly concerned with Call Event 4486 Types that have been updated in the SPIRITS_CET.DTD file and the 4487 SPIRITS_ACI.DTD file. 4489 A drawback of this approach, as identified in the earlier section, is 4490 that the XML DTDs can only be validated using an XML parser through 4491 the validation of the XML examples that make use of those XML DTDs. 4493 July 2002 Expires Jan 2003 4495 One cannot validate the DTD directly using an XML parser. 4497 Step 2 - Generate XSDs from the DTDs 4499 For Step 2 we used a publically available tool "dtd2xsd" [11] to translate 4500 the XML 1.0 DTDs into XML schema's (REC-xmlschema-1-20010502). The proposed 4501 namespace for the XML schema's is "http://www.csapi.org/spirits/", as 4502 "org.csapi" is the namespace for the Parlay IDL. The results of Step 2 are 4503 provided in the first part of the main body of this appendix. 4505 Step 3 - Validate the XSD Examples 4507 Again, Xerces [10] was used to validate the examples. No modifications 4508 were required, corroborating the validation of the XML DTDs and the 4509 generation of the XSDs from these DTDs. The results of Step 3 are 4510 provided in the second part of the main body of this appendix. 4512 F.1.2.2 ASN.1 to XML 4514 This exercise pertains to the XML DTDs contained in appendix B. The INAP 4515 parameters and data types are specified in ASN.1 (Abstract Syntax Notation 4516 One) [12]. ITU-T recommendation X.693 [13] specifies as set of basic XML 4517 Encoding Rules (XER) that may be used to convert a specification defined 4518 in ASN.1 to a specification defined in XML, and vice versa. Amendment 3 4519 of ITU-T recommendation X.680 [14] specifies XML value notation for ASN.1 4520 basic notation. Unfortunately, this work is in progress and not yet mature. 4521 ITU-T recommendation X.693 [13] is currently under ITU-T AAP (Alternative 4522 Approval Process). 4524 The automatic generation of XML from the ASN.1 specifications, using XER, 4525 is left to future iterations of the exercise presented here. It is expected 4526 that a step-wise process as proposed in section 3.1 can be applied to the 4527 INAP ASN.1 case as well. 4529 F.1.3 Future Work 4531 This section identifies areas for further study, as well as areas of 4532 ongoing work. 4534 F.1.3.1 IDL-to-XML generation 4536 IDL to XML generation and mapping rules are ongoing work in the OMG. No 4537 tool support is was identified at this time, although no extensive search 4538 was performed. Once this work matures, the XML will be generated 4539 automatically from the IDL, making the parameter and data type definition 4540 for the SPIRITS protocol more transparent. 4542 F.1.3.2 Tagged Choice of Data Elements (IDL) 4544 Some of the Parlay definitions in IDL make use of the "tagged choice of 4546 July 2002 Expires Jan 2003 4548 data elements" language construct. During the manual construction of the 4549 XML DTDs from the IDL, no suitable conversion for this IDL language 4550 construct was identified. The example provided in section E.3.3.1 "Example 4551 of an Event Report Error" will therefore not correctly validate. However, 4552 as soon as the DTDs or XSDs can be generated from the IDL, this need is 4553 superseded. OMG will have defined a standard mapping for this IDL language 4554 construct. 4556 F.1.3.3 Strong typing 4558 XSD support strong typing. The string type for date and time parameters, 4559 e.g "1998-12-04 10:30" can be strong typed. The XSD data type is "dateTime". 4561 The format of the example would then be "1998-12-04T10:30", which is 4562 slightly different than the Parlay TpString IDL type value. Although it is 4563 preferred to use strong typing, in this particular case this would yield a 4564 different parameter value. 4566 A potential solution would be to submit a change request to Parlay to 4567 change the string representation to "TpDateAndtime" for the date and time 4568 parameters to the same as the XSD type "dateTime". 4570 F.1.3.4 Namespace 4572 This Internet-Draft proposes to use the following namespace for the XML 4573 schema's "http://www.csapi.org/spirits/". The naming convention attempts 4574 to align with "org.csapi" as the namespace for the Parlay IDL. The XSDs 4575 contained in this appendix do not yet include this namespace. 4577 F.1.3.5 ASN.1-to-XML generation 4579 It is the intention of the authors to perform the INAP ASN.1 exercise, 4580 similar to the Parlay IDL exercise, in future iterations of this 4581 appendix. That work will be based on XER as defined in [13]. 4583 F.1.3.6 Completeness of the protocol representation 4585 In order for the protocol to be complete not only all the data elements 4586 have to be defined but also the sequencing of messages and events must 4587 be determined as well. Since the SPIRITS protocol deals only with two 4588 entities PSTN and IP the functional partition is well determined. It 4589 should be noted that different INAP flavors have different call models. 4591 In order to validate a protocol a call model has to be defined as certain 4592 events must be for example ignored in the context of a call progression. 4593 PARLAY has a call model; however it is the toolkit level call model and 4594 not necessarily a complete network level call model. In order for the 4595 interoperation of services written by different application service 4596 providers, a common call model needs to be assumed. The work on the 4597 multimedia call model is progressing well however no universally 4599 July 2002 Expires Jan 2003 4601 accepted model has emerged yet. 4603 F.1.4 Recommendations 4605 Based on our work in this area, we recommend that:- 4607 - XML Schema's be used instead of XML DTDs, for the further definition 4608 of the SPIRITS protocol 4610 - the XML Schema's be generated, possibly via XML DTD as an intermediary 4611 step, from the IDL and ASN.1, as soon as the respective language 4612 mappings to XML are specified and tool support is available 4614 - the following namespace for the XML schema's be used 4615 "http://www.csapi.org/spirits/" 4617 F.2 Conventions 4619 Throughout this internet-draft the US-ASCII coded character set, 4620 defined in ANSI X3.4-1986, is used. All SPIRITS protocol elements 4621 are defined using XML Schema's (XSD) DTDs [REF]. The SPIRITS 4622 protocol elements, or SPIRITS protocol operations, are composed 4623 only of the definition of the root element and the inclusion of 4624 the necessary protocol element XSD. 4626 The strings "******" and "******" denote the 4627 boundaries of an XSD. 4629 XSD, contrary to XML DTD, complies to the XML syntax. 4631 F.3 XML Schema's for INAP Information Elements 4633 These are the XSD for the commonly used elements. These XSD 4634 representations are used as building blocks in encoding the various 4635 parameters in the IFs. 4637 F.3.1 AccessCode 4639 ****** 4640 4642 4643 4644 4645 ******** 4647 F.3.2 AllCallSegments 4649 July 2002 Expires Jan 2003 4651 ****** 4652 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 ******** 4665 F.3.3 AssociatedCallSegment 4667 ****** 4668 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 ******** 4683 F.3.4 BCSMEvent 4685 ****** 4686 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4702 July 2002 Expires Jan 2003 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4755 July 2002 Expires Jan 2003 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4808 July 2002 Expires Jan 2003 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4861 July 2002 Expires Jan 2003 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4914 July 2002 Expires Jan 2003 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 ******** 4936 F.3.5 BillingChargingCharacteristics 4938 ****** 4939 4941 4942 4943 4944 ******** 4946 F.3.6 BusyCause 4948 ****** 4949 4951 4952 4953 4954 ******** 4956 F.3.7 CalledPartyNumber 4958 ****** 4959 4961 4962 4963 4964 ******** 4966 July 2002 Expires Jan 2003 4968 F.3.8 CalledPartySubaddress 4970 ****** 4971 4973 4974 4975 4976 ******** 4978 F.3.9 CallID 4980 ****** 4981 4983 4984 4985 4986 ******** 4988 F.3.10 CallingPartyNumber 4990 ****** 4991 4993 4994 4995 4996 ******** 4998 F.3.11 CallingPartySubaddress 5000 ****** 5001 5003 5004 5005 5006 ******** 5008 F.3.12 CallSegmentID 5010 ****** 5011 5013 5014 5015 5016 ******** 5018 July 2002 Expires Jan 2003 5020 F.3.13 Carrier 5022 ****** 5023 5025 5026 5027 5028 ******** 5030 F.3.14 ChargeNumber 5032 ****** 5033 5035 5036 5037 5038 ******** 5040 F.3.15 ChargingEvent 5042 ****** 5043 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 ******** 5059 F.3.16 ConnectTime 5061 ****** 5062 5064 5065 5066 5067 ******** 5069 F.3.17 DestinationRoutingAddress 5071 July 2002 Expires Jan 2003 5073 ****** 5074 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 ******** 5094 F.3.18 DialedDigits 5096 ****** 5097 5099 5100 5101 5102 ******** 5104 F.3.19 FailureCause 5106 ****** 5107 5109 5110 5111 5112 5113 ******** 5115 F.3.20 DisplayInformation 5117 ****** 5118 5120 5121 5123 July 2002 Expires Jan 2003 5125 5126 ******** 5128 F.3.21 FeatureCode 5130 ****** 5131 5133 5134 5135 5136 ******** 5138 F.3.22 FeatureRequestIndicator 5140 ****** 5141 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5176 July 2002 Expires Jan 2003 5178 5179 5180 5181 5182 5183 5184 ******** 5186 F.3.23 ForwardingCondition 5188 ****** 5189 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210 5211 5212 5213 5214 5215 5216 5217 ******** 5219 F.3.24 InitiateCallSegment 5221 ****** 5222 5224 5225 5226 5227 ******** 5229 July 2002 Expires Jan 2003 5231 F.3.25 LegID 5233 ****** 5234 5236 5237 5238 5239 5240 5241 5242 5243 5244 5245 5246 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 ******** 5258 F.3.26 LegToBeCreated 5260 ****** 5261 5263 5264 5265 5266 5267 5268 5269 5270 5271 5272 ******** 5274 F.3.27 MonitorMode 5276 ****** 5277 5279 5281 July 2002 Expires Jan 2003 5283 5284 5285 5286 5287 5288 5289 5290 5291 5292 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 5304 5305 5306 5307 5308 ******** 5310 F.3.28 NewCallSegment 5312 ****** 5313 5315 5316 5317 5318 5319 5320 5321 5322 5323 5324 ******** 5326 F.3.29 OriginalCalledPartyID 5328 ****** 5329 5331 5332 5334 July 2002 Expires Jan 2003 5336 5337 ******** 5339 F.3.30 Prefix 5341 ****** 5342 5344 5345 5346 5347 ******** 5349 F.3.31 RedirectingPartyID 5351 ****** 5352 5354 5355 5356 5357 ******** 5359 F.3.32 RedirectionInformation 5361 ****** 5362 5364 5365 5366 5367 ******** 5369 F.3.33 ReleaseCause 5371 ****** 5372 5374 5375 5376 5377 5378 ******** 5380 F.3.34 ServiceAddressInformation 5382 ****** 5383 5385 5387 July 2002 Expires Jan 2003 5389 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 5402 5403 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 5440 July 2002 Expires Jan 2003 5442 5443 5444 5445 5446 5447 5448 5449 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5493 July 2002 Expires Jan 2003 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5546 July 2002 Expires Jan 2003 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563 5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574 5575 5576 5577 5578 5579 ******** 5581 F.4 XML schema's for INAP Originating Detection Points 5583 This section presents the XSD encoding for Information Flows (IFs) 5584 between the SSF and the SCF. The XSD building blocks for common 5585 elements defined in section F.3 are used in the XSD definitions 5586 here. 5588 F.4.1 O_Abandon 5590 ****** 5591 5593 5594 5595 5596 5597 5599 July 2002 Expires Jan 2003 5601 5602 5603 5604 5605 5606 5607 ******** 5609 F.4.2 O_Called_Party_Busy 5611 ****** 5612 5614 5615 5616 5617 5618 5619 5620 5621 5622 5623 5624 5625 5626 5627 5628 5629 5630 ******** 5632 F.4.3 O_Disconnect 5634 ****** 5635 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 ******** 5652 July 2002 Expires Jan 2003 5654 F.4.4 Collected_Information 5656 ****** 5657 5659 5660 5661 5662 5663 5664 5665 5666 5667 5668 5669 5670 5671 5672 5673 5674 5675 5676 5677 ******** 5679 F.4.5 Origination_Attempt_Authorized 5681 ****** 5682 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 ******** 5698 F.4.6 O_No_Answer 5700 ****** 5701 5703 July 2002 Expires Jan 2003 5705 5706 5707 5708 5709 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 5720 ******** 5722 F.4.7 O_Midcall 5724 ****** 5725 5727 5728 5729 5730 5731 5732 5733 5734 5735 5736 5737 5738 5739 5740 ******** 5742 F.4.8 O_Answer 5744 ****** 5745 5747 5748 5749 5750 5751 5752 5753 5754 5756 July 2002 Expires Jan 2003 5758 5759 5760 5761 5762 5763 ******** 5765 F.4.9 Analyzed_Information 5767 ****** 5768 5770 5771 5772 5773 5774 5775 5776 5777 5778 5779 5780 5781 5782 5783 5784 5785 5786 5787 5788 ******** 5790 F.4.10 Route_Select_Failure 5792 ****** 5793 5795 5796 5797 5798 5799 5800 5801 5802 5803 5804 5805 5806 5807 5809 July 2002 Expires Jan 2003 5811 5812 5813 5814 5815 ******** 5817 F.5 XML XSD's for INAP Terminating Detection Points 5819 This section presents the XSD encoding for Information Flows (IFs) 5820 between the SCF and the SSF. The XSD building blocks for common 5821 elements defined in section F.3 are used in the XSD definitions 5822 here. 5824 F.5.1 Termination_Attempt_Authorized 5826 ****** 5827 5829 5831 5832 5833 5834 5835 5836 5837 5838 5839 5840 5841 5842 5843 ******** 5845 F.5.2 T_Busy 5847 ****** 5848 5850 5851 5852 5853 5854 5855 5856 5857 5858 5859 5861 July 2002 Expires Jan 2003 5863 5864 5865 5866 5867 ******** 5869 F.5.3 Facility_Selected_and_Available 5871 ****** 5872 5874 5875 5876 5877 5878 5879 5880 5881 5882 5883 5884 5885 5886 5887 5888 ******** 5890 F.5.4 T_No_Answer 5892 ****** 5893 5895 5896 5897 5898 5899 5900 5901 5902 5903 5904 5905 5906 5907 5908 5909 5910 ******** 5912 F.5.5 T_Answer 5914 July 2002 Expires Jan 2003 5916 ****** 5917 5919 5920 5921 5922 5923 5924 5925 5926 5927 5928 5929 5930 5931 ******** 5933 F.5.6 T_Midcall 5935 ****** 5936 5938 5939 5940 5941 5942 5943 5944 5945 5946 5947 5948 5949 5950 5951 ******** 5953 F.5.7 T_Disconnect 5955 ****** 5956 5958 5959 5960 5961 5962 5963 5964 5966 July 2002 Expires Jan 2003 5968 5969 5970 5971 5972 5973 ******** 5975 F.6 XSD encoding for IFs from the SCF to the SSF 5977 F.6.1 Analyse_Information 5979 ****** 5980 5982 5983 5984 5985 5986 5987 5988 5989 5990 5991 5992 5993 5994 5995 5996 5997 5998 ******** 6000 F.6.2 Authorise_Termination 6002 ****** 6003 6005 6006 6007 6008 6009 6010 6011 6012 6013 6014 6015 6016 6017 6019 July 2002 Expires Jan 2003 6021 ******** 6023 F.6.3 Collect_Information 6025 ****** 6026 6028 6029 6030 6031 6032 6033 6034 6035 6036 6037 6038 6039 6040 6041 ******** 6043 F.6.4 Connect 6045 ****** 6046 6048 6049 6050 6051 6052 6053 6054 6055 6056 6057 6058 6059 6060 6061 6062 6063 6064 6065 6066 ******** 6068 F.6.5 Continue 6070 ****** 6072 July 2002 Expires Jan 2003 6074 6076 6077 6078 6079 6080 6081 6082 6083 6084 6085 6086 6087 ******** 6089 F.6.6 Furnish_Charging_Information 6091 ****** 6092 6094 6095 6096 6097 6098 6099 6100 6101 6102 6103 6104 6105 ******** 6107 F.6.7 Hold_Call_In_Network 6109 ****** 6110 6111 6112 6113 6114 6115 6116 ******** 6118 F.6.8 Initiate_Call_Attempt 6120 ****** 6121 6123 6125 July 2002 Expires Jan 2003 6127 6128 6129 6130 6131 6132 6133 6134 6135 6136 6137 6138 6139 ******** 6141 F.6.9 Release_Call 6143 ****** 6144 6146 6147 6148 6149 6150 6151 6152 6153 6154 6155 6156 6157 6158 6159 ******** 6161 F.6.10 Request_Notification_Charging_Event 6163 ****** 6164 6166 6167 6168 6169 6170 6171 6172 6173 6174 6175 6176 6178 July 2002 Expires Jan 2003 6180 ******** 6182 F.6.11 Request_Report_BCSM_Event 6184 ****** 6185 6187 6188 6189 6190 6191 6192 6193 6194 6195 6196 6197 6198 ******** 6200 F.6.12 Trigger_Data_Status_Request 6202 ****** 6203 6204 6205 6206 6207 6208 6209 ******** 6211 Appendix G: XSD for Parlay Parameters and Data Types 6213 This appendix contains the generated XML XSDs for the Parlay Encoding of 6214 SPIRITS Data. These were generated from the XML DTDs that were originally 6215 described in [1]. The DTD file breakdown structure as in [1] is maintained 6216 for ease of reference. Similarly, conventions and terminology are preserved 6217 from [1]. 6219 G.1 Protocol Operations 6221 G.1.1 Event Report Request 6223 ************************* 6224 6226 6228 July 2002 Expires Jan 2003 6230 6231 6232 6234 6235 6236 6237 6238 6239 6241 6242 6243 6244 6245 6246 *************************** 6248 G.1.2 Event Report Result 6250 ************************* 6251 6253 6255 6256 6257 6258 6260 6261 6262 6263 6264 6265 6266 6268 6269 6270 6271 6272 6273 *************************** 6275 G.1.3 Event Report Error 6277 ************************* 6278 6280 July 2002 Expires Jan 2003 6282 6284 6285 6286 6288 6289 6290 6291 6292 6293 6295 6296 6297 6298 6299 6300 *************************** 6302 G.1.4 Report Notification 6304 ************************* 6305 6307 6309 6311 6312 6313 6314 6315 6316 6317 6318 6319 6320 *************************** 6322 G.2 Common Element Definitions 6324 G.2.1 CallEventType 6325 ************************* 6326 6328 6329 6330 6331 6333 July 2002 Expires Jan 2003 6335 6336 6337 6338 6339 6340 6341 6342 6343 6344 6345 6346 6347 6348 6349 6350 6351 6352 6353 6354 6355 6356 6357 6358 6359 6360 6361 6362 6363 6364 6365 6366 6367 6368 6369 6370 6371 6372 6373 6374 6375 6376 6377 6378 6379 6380 6381 6382 6383 6384 6386 July 2002 Expires Jan 2003 6388 6389 6390 6391 6392 6393 6394 6395 6396 6397 6398 6399 6400 6401 *************************** 6403 G.2.2 CallMonitorMode 6404 ************************* 6405 6407 6408 6409 6410 6411 6412 6413 6414 6415 6416 6417 6418 6419 6420 6421 6422 6423 6424 6425 6426 6427 *************************** 6429 G.2.3 AdditionalCallEventInfo 6430 ************************* 6431 6433 6435 6436 6438 July 2002 Expires Jan 2003 6440 6441 6442 6443 6444 6445 6446 6447 6448 6449 6450 6451 6452 6453 6454 6455 6456 6457 6458 6459 6460 6461 6462 6463 6464 6465 6466 6467 6468 6469 6470 6471 6472 6473 6474 6475 6476 6477 6478 6479 6480 6481 6482 6483 6484 6485 6486 6487 6488 6489 6491 July 2002 Expires Jan 2003 6493 6494 6495 6496 6497 6498 6499 6500 6501 6502 6503 6504 6505 6506 6507 6508 6509 6510 6511 6512 6513 6514 6515 6516 6517 6518 6519 6520 6521 6522 6523 6524 6525 6526 6527 6528 6529 6530 6531 6532 6533 6534 6535 6536 6537 6538 6539 6540 6541 6542 6544 July 2002 Expires Jan 2003 6546 6547 6548 6549 6550 6551 6552 6553 6554 6555 6556 6557 6558 6559 6560 6561 6562 6563 6564 6565 6566 6567 6568 6569 6570 6571 6572 6573 6574 6575 6576 6577 6578 6579 6580 6581 6582 6583 6584 6585 6586 6587 6588 6589 6590 6591 6592 6593 6594 6595 6597 July 2002 Expires Jan 2003 6599 6600 6601 6602 6603 6604 6605 6606 6607 6608 6609 6610 6611 6612 6613 6614 6615 6616 6617 6618 6619 6620 6621 6622 6623 6624 6625 6626 6627 6628 6629 6630 6631 6632 6633 6634 6635 6636 6637 6638 *************************** 6640 G.2.4 CallEventTime 6641 ************************* 6642 6644 6645 6646 6647 *************************** 6649 July 2002 Expires Jan 2003 6651 G.2.5 ErrorTime 6652 ************************* 6653 6655 6656 6657 6658 *************************** 6660 G.2.6 ErrorType 6661 ************************* 6662 6664 6665 6666 6667 6668 6669 6670 6671 6672 6673 6674 6675 6676 6677 6678 6679 6680 6681 6682 6683 6684 *************************** 6686 G.2.7 AdditionalErrorInfo 6687 ************************* 6688 6690 6692 6694 6695 6696 6697 6698 6699 6700 6702 July 2002 Expires Jan 2003 6704 6705 6706 6707 6708 6709 6710 6711 6712 6713 6714 6715 6716 6717 6718 6719 6720 6721 6722 6723 6724 6725 6726 6727 6728 6729 6730 6731 6732 6733 6734 6735 6736 6737 6738 6739 6740 6741 6742 6743 6744 6745 6746 6747 6748 6749 6750 6751 6752 6753 6755 July 2002 Expires Jan 2003 6757 6758 6759 *************************** 6761 G.2.8 Notification Info 6762 ************************* 6763 6765 6767 6768 6769 6770 6772 6773 6774 6775 6776 6777 6778 6779 6780 6781 6782 6783 6784 6785 6786 6787 6788 6789 6790 6791 6792 6793 6794 6795 6796 6797 6798 6799 6800 6801 6802 6803 6804 6805 6806 6808 July 2002 Expires Jan 2003 6810 6811 6812 6813 6814 6815 6817 6818 6819 6820 6821 6822 6823 6824 6825 6826 6827 6828 6829 6830 6831 6832 6833 6834 6835 6836 6837 6838 6839 6840 6841 6842 6843 6844 6845 6846 6847 6848 6849 6850 6851 6852 6853 6854 6855 6856 6857 6858 6859 6861 July 2002 Expires Jan 2003 6863 6864 6865 6866 6867 6868 6869 6870 6871 6872 6873 6874 6875 6876 6877 6878 6879 6880 6881 6882 6883 6884 6885 6886 6887 6888 6889 6890 6891 6892 6893 6894 6895 6896 6897 6898 6899 6900 6901 6902 6903 6904 6905 6906 6907 6908 6909 6910 6911 6912 6914 July 2002 Expires Jan 2003 6916 6917 6918 6919 6920 6921 6922 6923 6924 6925 6926 6927 6928 6929 6930 6931 6932 6933 6934 6935 6936 6937 6938 6939 6940 6941 6942 6943 6944 6945 6946 6947 6948 6949 6950 6951 6952 6953 6954 6955 6956 6957 6958 6959 6960 6961 6962 6963 6964 6965 6967 July 2002 Expires Jan 2003 6969 6970 6971 6972 6973 6974 6975 6976 6977 6978 6979 6980 6981 6982 6983 6984 6985 6986 6987 6988 6989 6990 6991 6992 6993 6994 6995 6996 6997 6998 6999 7000 7001 7002 7003 7004 7005 7006 7007 7008 7009 7010 7011 7012 7013 7014 7015 7016 7017 7018 7020 July 2002 Expires Jan 2003 7022 7023 7024 7025 7026 7027 7028 7029 7030 7031 7032 7033 7034 7035 7036 7037 7038 7039 7040 7041 7042 7043 7044 7045 7046 7047 7048 7049 7050 7051 7052 7053 7054 7055 7056 7057 7058 7059 7060 7061 7062 7063 7064 7065 7066 7067 7068 7069 7070 7071 7073 July 2002 Expires Jan 2003 7075 7076 7077 7078 7079 7080 7081 7082 7083 7084 7085 7086 7087 7088 7089 7090 7091 7092 7093 7094 7095 7096 7097 7098 7099 7100 7101 7102 7103 7104 7105 7106 7107 7108 7109 7110 7111 7112 7113 7114 7115 7116 7117 7118 7119 7120 7121 7122 *************************** 7124 G.2.9 Address 7126 July 2002 Expires Jan 2003 7128 ************************* 7129 7131 7132 7133 7134 7135 7136 7137 7138 7139 7140 7141 7142 7143 7144 7145 7146 7147 7148 7149 7150 7151 7152 7153 7154 7155 7156 7157 7158 7159 7160 7161 7162 7163 7164 7165 7166 7167 7168 7169 7170 7171 7172 7173 7174 7175 7176 7177 7179 July 2002 Expires Jan 2003 7181 7182 7183 7184 7185 7186 7187 7188 7189 7190 7191 7192 7193 7194 7195 7196 7197 7198 7199 7200 7201 7202 7203 7204 7205 7206 7207 7208 7209 7210 7211 7212 7213 7214 7215 7216 7217 *************************** 7219 G.3 Examples for Parlay 7221 G.3.1 7223 This is the validated example from Appendix E, E.3.1.1 Example of 7224 an Event Report Request, using the XSDs described above. 7226 7227 7231 July 2002 Expires Jan 2003 7233 7234 7235 7236 7237 7238 7239 7241 G.3.2 7243 This is the validated example from Appendix E, E.3.2.1 Example 7244 of an Event Report Result, using the XSDs described above. 7246 7248 7252 7253 7254 7255 7256 7257 7258 7259 1998-12-04 10:30 7260 7261 7263 G.3.3 7265 This is the validated example from Appendix E, E.3.3.1 Example of 7266 an Event Report Error, using the XSDs described above. As has 7267 been identified in section F.1.3.3 there is still an error contained 7268 in this example. 7270 7271 7275 7276 1998-12-04 10:30 7277 7278 7279 7280 7281 7282 7284 July 2002 Expires Jan 2003 7286 7287 7289 G.3.4 7291 This is the validated example from Appendix E, E.3.4.1 Example of 7292 a Report Notification, using the XSDs described above. 7294 7296 7300 7301 7302 7303
7304 7305 7306 7307 7308 1800PIZZA 7309 7310 7311 7312 7313 7314 7315 7316 7317 7318 7319 7320
7321 7322 7323
7324 7325 7326 7327 7328 31356871684 7329 7330 7331 7332 7333 7334 7335 7337 July 2002 Expires Jan 2003 7339 7340 7341 7342 7343
7344 7345 7346 7347 7348 7349 7350 7351 7352 7353 7354 7355 7356 7357 7358 7359 7360 7361 7362 1998-12-04 10:30 7363 7364 7365 7366 7368 G.4 SPIRITS.XSD Includes 7370 A convenience XSD file was created, which includes all the XSDs from 7371 previous sections. 7373 7374 7376 elementFormDefault="qualified" 7377 attributeFormDefault="unqualified" 7378 > 7380 7381 7382 Some explanatory text goes here ... 7383 7385 7386 7387 7389 July 2002 Expires Jan 2003 7391 7392 7393 7394 7395 7396 7397 7398 7399 7400 7402 7404 Appendix H: Miscellaneous Parlay/SPIRITS Issues 7406 H.1 Protocol Procedures 7408 This section describes the SPIRITS protocol procedures. The SPIRITS 7409 protocol defines the activities on the interfaces labeled 'C' in the 7410 SPIRITS architecture, depicted in figure 1. 7412 H.1.1 Static Events 7414 Static events are statically armed through service provisioning. It is 7415 outside the scope of the SPIRITS protocol how the provisioning takes 7416 place. A statically armed event remains armed until explicitly 7417 disarmed. 7419 The static event defined for the SPIRITS protocol is: 7420 + P_CALL_EVENT_CALL_ATTEMPT 7422 The Report Notification procedure is used when a static event is met 7423 to indicate to the SPIRITS server a request for instructions on how to 7424 complete the call. 7426 SPIRITS GATEWAY SPIRITS CLIENT 7427 | | 7428 |<----INVITE (REPORT_NOTIFICATION-)-------| 7429 | | 7430 | | 7431 | | 7432 |-----200 OK----------------------------->| 7433 | | 7435 Figure 5: Report Notification 7437 H.2 Dynamic Events 7439 An event is dynamically armed within the context of a call-associated 7441 July 2002 Expires Jan 2003 7443 IN service control relationship. This is achieved when suitable 7444 instructions are received by the switching element from the Service 7445 Control entity. 7447 The dynamic events defined for the SPIRITS protocol are: 7448 + P_CALL_EVENT_ADDRESS_COLLECTED 7449 + P_CALL_EVENT_ADDRESS_ANALYZED 7450 + P_CALL_EVENT_PROGRESS 7451 + P_CALL_EVENT_ALERTING 7452 + P_CALL_EVENT_ANSWER 7453 + P_CALL_EVENT_RELEASE 7454 + P_CALL_EVENT_REDIRECTED 7455 + P_CALL_EVENT_SERVICE_CODE 7457 The Event Report Request procedure is used to request the Service 7458 Switching Function, through the SPIRITS Gateway, to monitor for a 7459 call-related event. 7461 SPIRITS GATEWAY SPIRITS CLIENT 7462 | | 7463 |-----SUBSCRIBE(EVENT_REPORT_REQUEST)---->| 7464 | | 7465 | | 7466 | | 7467 |<----200 OK------------------------------| 7468 | | 7470 Figure 6: Event Report Request 7472 The Event Report Result is used to notify the SPIRITS Server via the 7473 SPIRITS Gateway, that the requested call-related event has been 7474 detected. 7476 SPIRITS GATEWAY SPIRITS CLIENT 7477 | | 7478 |<----NOTIFY (EVENT_REPORT_RESULT)--------| 7479 | | 7480 | | 7481 | | 7482 |-----200 OK----------------------------->| 7483 | | 7485 Figure 7: Event Report Result 7487 The Event Report Error is used to indicate to the SPIRITS Server via 7488 the SPIRITS Gateway that the request to monitor for call-related 7489 events was unsuccessful. 7491 SPIRITS GATEWAY SPIRITS CLIENT 7492 | | 7494 July 2002 Expires Jan 2003 7496 |<----NOTIFY (EVENT_REPORT_ERROR)---------| 7497 | | 7498 | | 7499 | | 7500 |-----200 OK----------------------------->| 7501 | | 7503 Figure 8: Event Report Error 7505 H.3 Security Considerations for Parlay 7507 The Parlay Framework as described in the main body of the text, 7508 provides mutual authentication and application authorization support 7509 to third-party applications in this architecture. Note that this 7510 applies only to interface 'B' depicted in figures 1 and 2. 7512 Considerations similar to those discussed in the security considerations 7513 section in the main body of this draft are still applicable for security 7514 along interface 'C'." 7516 H.4 Parlay-related Unresolved Issues/Items to be Done 7518 This section is intended to be a general clause for any unresolved 7519 issues and items that can be considered for inclusion in later 7520 versions. 7522 H.4.1 XML DTDs for Call Routing 7524 The current document presents XML DTDs for the encoding of Parlay 7525 parameters for dynamic event reporting and static event notification. 7526 Currently no XML DTDs have been included for the IN operations that 7527 can be executed as a result of event notifications. The Parlay 7528 equivalent for these IN operations include the routeReq method. A 7529 subsequent version of this document will include XML DTD definitions 7530 for these operations as well. 7532 H.4.2 XML DTD Generation 7534 The ETSI organization publishes and maintains a UML source model 7535 for all of the OSA and Parlay API interfaces [23]. This source is used 7536 to extract documentation and to generate the API specification in the 7537 form of Interface Definition Language (IDL) files. A similar exercise 7538 should be considered for the generation of the XML DTDs presented in 7539 this document. 7541 10.0 Authors' Addresses 7543 Alec Brusilovsky, Elias Dacloush 7545 July 2002 Expires Jan 2003 7547 Lucent Technologies, Lucent Technologies, 7548 263 Shuman Blvd. 1960 Lucent Lane 7549 Naperville, IL 60566 Naperville, IL 60566 7550 USA. USA. 7551 abrusilovsky@lucent.com elias@lucent.com 7553 Frans Haerens Musa Unmehopa 7554 Alcatel Bell Lucent Technologies, 7555 Francis Welles Plein, Larenseweg 50, 7556 B-2080 Antwerp Postbus 1168 7557 Belgium 1200 BD, Hilversum, 7558 frans.haerens@alcatel.be The Netherlands 7559 unmehopa@lucent.com 7561 Kumar Vemuri, Ahmed Zaki 7562 Lucent Technologies, Lucent Technologies, 7563 263 Shuman Blvd. 1960 Lucent Lane 7564 Naperville, IL 60566 Naperville, IL 60566 7565 USA. USA. 7566 vvkumar@lucent.com ahmedzaki@lucent.com 7568 John-Luc Bakker Janusz Dobrowolski 7569 Telcordia Technologies StateSoft 7570 445 South Street 2351 Richmond Dr 7571 Morristown, 07960 NJ Wheaton, Il 60187 7572 USA USA 7573 jlbakker@research.telcordia.com j_a_dobrowolski@hotmail.com 7575 Bruno Chatras 7576 France Telecom R&D 7577 France 7578 bruno.chatras@rd.francetelecom.com 7580 11.0 Acronyms 7582 3GPP Third Generation Partnership Project 7583 ASN.1 Abstract Syntax Notation One 7584 ASP Application Service Provider 7585 API Application Programming Interface 7586 BCSM Basic Call State Model 7587 CAMEL Customized Applications for Mobile Network Enhanced 7588 Logic 7589 CC Call Control 7590 CM Call Model 7591 CS Capability Set 7592 DN Directory Number 7593 DP Detection Point 7595 July 2002 Expires Jan 2003 7597 DTD Document Type Definition 7598 EDP Event Detection Point 7599 EDP-N Event Detection Point "Notification" 7600 EDP-R Event Detection Point "Request" 7601 GSTN Global Switched Telephone Network 7602 HTTP Hypertext Transfer Protocol 7603 IANA Internet Assigned Numbers Authority 7604 ICW Internet Call Waiting 7605 IE Information Element 7606 IDL Interface Definition Language 7607 IF Information Flow 7608 IN Intelligent Network 7609 INAP Intelligent Network Application Protocol 7610 IP Internet Protocol 7611 ISUP ISDN User Part (SS7 Protocol) 7612 ITU International Telecommunications Union 7613 MIME Multipurpose Internet Mail Extensions 7614 MP CC MultiParty Call Control 7615 OBCSM Originating Basic Call State Model 7616 PIC Point In Call 7617 PINT PSTN/Internet Interworking 7618 PSTN Public Switched Telephone Network 7619 SCF Service Control Function 7620 SCP Service Control Point 7621 SDP Session Description Protocol 7622 SIP Session Initiation Protocol 7623 SIP-T SIP for Telephones 7624 SPIRITS Services in the PSTN/IN Requesting InTernet Services 7625 SSF Service Switching Function 7626 SSP Service Switching Point 7627 STD State Transition Diagram 7628 TBCSM Terminating Basic Call State Model 7629 TDP Trigger Detection Point 7630 TDP-N Trigger Detection Point "Notification" 7631 TDP-R Trigger Detection Point "Request" 7632 XML Extensible Markup Language 7634 12.0 Full Copyright Statement 7636 "Copyright (C) The Internet Society (date). All Rights Reserved. This 7637 document and translations of it may be copied and furnished to others, 7638 and derivative works that comment on or otherwise explain it or assist 7639 in its implementation may be prepared, copied, published and 7640 distributed, in whole or in part, without restriction of any kind, 7641 provided that the above copyright notice and this paragraph are 7642 included on all such copies and derivative works. However, this 7643 document itself may not be modified in any way, such as by removing the 7644 copyright notice or references to the Internet Society or other 7645 Internet organizations, except as needed for the purpose of developing 7647 July 2002 Expires Jan 2003 7649 Internet standards in which case the procedures for copyrights defined 7650 in the Internet Standards process must be followed, or as required to 7651 translate it into followed, or as required to translate it into 7652 languages other than English. 7654 The limited permissions granted above are perpetual and will not be 7655 revoked by the Internet Society or its successors or assigns. 7657 This document and the information contained herein is provided on an 7658 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 7659 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 7660 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 7661 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 7662 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7664 July 2002 Expires Jan 2003