idnits 2.17.1 draft-faynberg-spirits-reqs-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 3) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 354 has weird spacing: '...he only speci...' == Line 561 has weird spacing: '...ated or requi...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'SCP' on line 77 -- Looks like a reference, but probably isn't: 'SN' on line 77 -- Looks like a reference, but probably isn't: '5-6' on line 189 -- Looks like a reference, but probably isn't: 'VLR' on line 395 == Unused Reference: '5' is defined on line 592, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 596, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2995 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2543 (ref. '7') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2327 (ref. '8') (Obsoleted by RFC 4566) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group I. Faynberg, Ed. 2 Internet Draft Lucent Technologies 3 draft-faynberg-spirits-reqs-00.txt> J. Gato 4 Expires August 2001 Airtel Movil 5 H. Lu 6 Lucent Technologies 7 L. Slutsman 8 AT&T 10 SPIRITS Protocol Requirements 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other groups 19 may also distribute working documents as 20 Internet-Drafts. Internet-Drafts are draft documents valid for a 21 maximum of six months and may be updated, replaced, or obsoleted by 22 other documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 1. Abstract 34 This Internet-Draft is written in response to the SPIRITS WG chairs' 35 call for contributions to the future RFC on the SPIRITS protocol 36 requirements. As such, it documents to consensus of the SPIRITS WG on 37 the choice of SPIRITS transport protocol and lists general requirements 38 as well as those pertinent to Intelligent Network (IN), Wireless IN, and 39 the PSTN/Internet iNTernetworking (PINT) building blocks. 41 2. Conventions used in this document 43 In examples, "C:", "P", and "S:" indicate lines sent by the client, 44 gateway, and server respectively. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119. 50 Unless otherwise qualified, the term PINT is used here not to refer to 51 the present PINT services and protocol, but in reference to the scope 53 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 55 of the generic PINT (vs. SPIRITS) service characteristic--being invoked 56 from an IP network (vs. PSTN). 58 3. Introduction 60 This Internet-Draft is written in response to the SPIRITS WG chairs' 61 call for contributions to the future RFC on the SPIRITS protocol 62 requirements. As such, it documents to consensus of the SPIRITS WG on 63 the choice of SPIRITS transport protocol and lists general requirements 64 as well as those pertinent to Intelligent Network (IN), Wireless IN, and 65 the PSTN/Internet iNTernetworking (PINT) building blocks. 66 The joint PINT/SPIRITS architecture (described in [1]) is depicted in 67 Figure 1. 69 It is assumed that the Spirits Client is either co-located with the IN 70 Service Control Function (SCF) or communicates with it (over the 71 PSTN-specific interface D) in such a way so as to act on behalf of the 72 PSTN/IN. (This assumption is confirmed by current implementations, as 73 reported in [2].) 75 The SPIRITS services are invoked (and, subsequently, the SPIRITS 76 protocol is initiated) when a message from a SPIRITS Client (located in 77 the IN Service Control Point [SCP] or Service Node [SN]) arrives on 78 interface C to the SPIRITS gateway. The Spirits gateway processes the 79 message and, in turn, passes it on over the Interface B to the SPIRITS 80 server. In most practically important cases, the request from a 81 SPIRITS client is ultimately caused by a request from a Central Office 82 (i.e., a telephone switch) sent to either the SCP or SN, although the 83 Internet-based service initiation by these elements that had not been 84 triggered by the Central Office is theoretically possible. (Definitely, 85 none of the SPIRITS benchmark services are initiated in such a way, so 86 for the purposes of the SPIRITS protocol development, it should be 87 assumed that the service invocation was a direct result of an earlier 88 action by the Central Office.) 90 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 92 ...................... 93 +----------------+ . . 94 | +------------+ | . +------------+ . 95 | | | | A . | | . 96 | | PINT Client|********************|PINT Server/|******** 97 | | | | . Gateway | * 98 | +------------+ | . +------------+ . * 99 | | . . * 100 | Subscriber's | . . * 101 | | . . * 102 | IP Host | . . * 103 | | . +------------+ . * 104 | +------------+ | . | SPIRITS | . * 105 | | SPIRITS | | B . | Gateway | . * 106 | | Server |********************| | . * E 107 | | | | . +------------+ . * 108 | +------------+ | . * . * 109 +----------------+ . * . * 110 ...........*.......... * 111 //-------\\ * * 112 /// \\\ * * 113 | Subscriber's | * C * 114 | Telephone | * * 115 \\\ /// * * 116 \\ -------// * * 117 * * * 118 * * * 119 ++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++ 120 * * * 121 * * * 122 * +------------------+ * 123 * Line | SPIRITS Client | * 124 * | | * 125 +--------------------+ +---+----- D ---------+-*+ 126 | | INAP/SS7 | | 127 |Service Switching ************Service Control Function | 128 | Function | | | 129 | | +-------------------------+ 130 | | 131 | | 132 +--------------------+ 134 Figure 1. Joint PINT/SPIRITS Architecture 136 With PINT (and that also applies to the present PINT architecture and 137 protocol as described in [3]), the service request to the PINT Server 138 is always initiated by the PINT Client over the interface A. The PINT 139 Server can either be co-located with the IN Service Control or a 140 similar entity (referred to as "Executive System" by [3]) or 141 communicate with it over the PSTN-specific interface E. 143 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 145 As Figure 1 shows, the PINT Client and SPIRITS Server are co-located 146 in Subscriber's IP Host. In fact, both can be implemented to run as 147 one process. No provision is made for interactions between the PINT 148 Client and Spirits Server. Similarly, the PINT Server/PINT Gateway 149 and SPIRITS gateway are assumed to be co-located, too. This 150 assumption is convenient but not essential; the PINT Server could 151 also be co-located with the SPIRITS Client. In either case, no 152 specific provision is made to define interworking between either the 153 PINT Server and Spirits Proxy or PINT Server and SPIRITS Client other 154 then by listing the overall PINT-related requirements. 156 Since the wireless networks currently deployed worldwide are based on 157 circuit switching, they are considered PSTN networks for the SPIRITS 158 purposes. Adding SPIRITS type of services to wireless networks can 159 allow new services to be developed (for example location information 160 can be handled in the IP network). 162 Nevertheless, there are certain peculiarities of Wireless networks, 163 which that force considerations to be made in the in the protocol 164 requirements and in the SPIRITS architecture. 166 The particular Wireless IN standard development being considered here 167 is CAMEL phase 3, standardised by the Third Generation Partnertship 168 group (3GPP). The relevant service and architectural considerations 169 and protocol requirements are presented later in this document. As 170 far as the architecture is concerned, certain wireless events are 171 generated by Home Location Register (HLR), which may but does not 172 have to be part of the SSP. These events are communicated to Service 173 Control, at which point they use the same mechanism for envoking 174 SPIRITS services that the IN would. 176 The rest of this Internet-Draft addresses the general requirements, 177 IN Requirements, specific Wireless IN requirements, PINT 178 Requirements, the protocol development methodology, and security 179 issues, in that order. 181 Based on the success of extending SIP for PINT ([2]) and, especially, 182 the results of pre-SPIRITS implementations reported in [2], the 183 Session Initiation Protocol (SIP) [7] has been chosen as the 184 transport protocol for SPIRITS. 186 Thus, it is a requirement that specific SPIRITS-related parameters be 187 carried in a manner consistent with SIP practices. In particular, 188 Either Session Description Protocol (SDP) [8] or Multi-purpose 189 Internet Mail Extensions MIME [5-6] is to be used for this purpose. 190 Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and 191 extensions already defined in PINT, no SIP extensions to SIP are 192 foreseen; instead the SPIRITS protocol is to rely on the above 193 extension mechanisms. 195 It is by no means a requirement that any SPIRITS implementation 196 automatically support PINT services. The SPIRITS protocol must be 197 defined in a manner where, as the minimum, it can support only the 199 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 201 basic notification mechanism without relying on PINT services or 202 otherwise relying on persistent interactions with PSTN. 203 Nevertheless, it has been demonstrated [2] that combining PINT 204 building blocks with those of SPIRITS is beneficial to buidling 205 reach, enhanced PSTN/Internet services, so the SPIRITS protocol must 206 meet the PINT-related requirements listed in section 6 of this 207 document. 209 One specific example demonstrating the application of the latter 210 requirement, which is elaborated on further in this document, is as 211 follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far 212 as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN 213 (Detection Point) notification will always arrive via the SIP INVITE 214 method; however, to implement persistent interactions with the PSTN, 215 the SUBSCRIBE method may be used to obtain further notifications to 216 the PSTN events. Subsequently, these events will be reported on by 217 means of the NOTIFY method. 219 5. IN Requirements 221 The interface immediately relevant to IN is that between the SPIRITS 222 Client and SPIRITS Proxy (interface C). A typical message (which 223 starts a SPIRITS service) looks like that: 225 C -> P: , 227 The relevant events correspond to the detection points (DPs) of the 228 IN Basic Call State Model (BCSM). The is a function 229 of a specific DP; it contains the parameters relevant to it. The 230 following requirements apply: 232 1) The list of the DPs to be covered encompasses those defined in the 233 IN Capability Set 3 BCSM as well as those that relate to the Wireless 234 IN (WIN) specified by the IMT 2000 project in ITU-T. 236 2) Not all parameters associated with such DPs are needed by the 237 SPIRITS benchmark services, nor may all the parameters be needed in 238 SPIRITS. The selection of the relevant parameters is part of the 239 SPIRITS protocol definition. 241 3) It is desirable to avoid semantic overload of protocol messages. 242 (One way to achieve that is to match each type of an event with a 243 message that corresponds to it.) In case the SPIRITS protocol is 244 designed as a set of extensions to another (existing) protocol with 245 the defined message set, the syntax and semantics of the extensions 246 should be defined with this requirement in mind. 248 4) The ITU-T Recommendations use the abstract syntax notation (ASN.1) 249 to specify the semantics of the IN Application Protocol (INAP) 250 parameters, which are expected to be binary-encoded Neither the use 251 of the ASN.1, nor the requirement for binary encoding are the typical 252 requirements for the IETF application protocols. Recognizing that, 253 provisions must be made for careful specification of the conversion 254 of the INAP parameters to text, which must preserve their original 256 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 258 semantics. The actual conversion of the parameters is the function of 259 the SPIRITS Client. 261 In order to issue an initial query (or a notification) to service 262 control, a switch must have such a DP set. This can be done 263 statically via service management (this particular action should be 264 left to implementation and thus is considered outside of the scope of 265 SPIRITS Protocol) or dynamically--but only for the purpose of a 266 particular call--from the service control. In the latter case, it is 267 part of the SPIRITS (or PINT) protocol to request the event 268 notification from the service control. A work-in-progress SIP 269 proposal [4] should be specifically considered. This function can be 270 performed by either the Spirits Client or PINT Server, the 271 distinction being further discussed in the next section. Assuming 272 that it is performed by the SPIRITS Client, the relevant message 273 should look like 275 C: SUBSCRIBE , 277 where refers to a particular DP; determines whether 278 the Event Detection Point (EDP) is to be armed as EDP Request (EDP- 279 R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is not 280 foreseen); and the is the list of the values 281 of the parameters associated with the EDP (for example, if the DP in 282 question is O_No_Answer, then the value of the appropriate timer 283 should be included in the list). Note that such a subscription may 284 also originate at a) PINT Client or b) SPIRITS Proxy, either of which 285 may (but does not have to) have a locally significant definition of 286 the . In either case, it is the function of the SPIRITS Client 287 to translate the definition of the Event into a particular DP (or set 288 of DPs) when passing the message to Service Control. To summarize, 289 for the case when PINT and SPIRITS events are defined in a way where 290 they do not refer to the BCSM DPs, it is the function of the SPIRITS 291 Client to define a mapping: 293 Event -> DP List, 295 for each event for which the PSTN notification is needed. 297 The list of CS-2 DPs envisioned in SPIRITS is 299 - origination_attempt_authorized (the SPIRITS 300 service can control call attempts, (for example, to 301 limit calls during specific time periods) 303 - collected_information and analyzed_information (for 304 SPIRITS outgoing call screening) 306 - o_answer, o_term_seized, and t-answer (to release 307 SPIRITS resources after the call is complete and 308 perform relevant OA&M actions such as creating a record of 309 attempts to reach a party via various means like land-line 310 phone, 311 cell phone, SMS, paging.) 313 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 315 - o_no_answer, route_select_failure, and t_no_answer 316 (to re-route a call) 318 - o_busy (to re-route a call and for Internet Call Waiting) 320 - o_mid_call and t_mid_call (to assist a midcall action) 322 - o_abandon, o_disconnect, t_abandon, and t_disconnect (to 323 terminate a SPIRITS service and release the resources and 324 perform relevant OA&M actions such as creating a record of 325 attempts to reach a party via various means like land-line 326 phone, 327 cell phone, SMS, paging.) 329 With that, the only DPs needed to implement the present SPIRITS 330 milestone services are 332 - termination_attempt_authorized (needed for SPIRITS 333 "milestone" services) 335 - facility_selected_and_available (could be used in SPIRITS 336 Internet Caller-ID) 338 - t_busy (for Internet Call Waiting and Call Forwarding). 340 6. Wireless-IN-related Requirements 342 Wireless IN covers several types of "calls," which are neither 343 circuit switched nor have an effect on circuit swicthed calls. For 344 this reason, those are not considered in SPIRITS requirements. To 345 further clarify this point, the types of "calls" not considered are 347 - USSD (Unstructured Supplementary Service Data) - 348 GPRS (General Packet Radio System) - SMS (Short Message 349 System) 351 The types of calls relevant to SPIRITS are as follows: 353 a) Voice Calls. In this case no new DP is needed since CAMEL 354 DPs are included in CS2. The only special case is "Not 355 Reachable" (when it is detected that the mobile user is out 356 of coverage or 357 has switched off), which is mapped as a special cause 358 in the Busy DP. Since the Busy DP parameters would be 359 received 360 (if a SPIRITS service has subscribed to Busy), it would be 361 possible 362 to distinguish a "busy" from a "not reachable" situation. 364 This translates into the requirement that one of the 366 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 368 parameters in 369 the Event Notification message (from SPIRITS Client to 370 SPIRITS Proxy, 371 over the interface C) denotes the "cause" for the Busy 372 Detection 373 Point. 375 Another aspect of difference, when compared to PSTN, is 376 setting 377 of static DPs. in CAMEL networks, this is done 378 in the Home Location Register (HLR) (and copied to the VLR 379 during 380 location update). It is important to note this difference, 381 even 382 though it has no effect on SPIRITS protocol. 384 b) Mobility Management events. This allows a SPIRITS server 385 to be 386 notified of changes of location of a mobile user. The events 387 would 388 only be applicable to mobile users reachable through a 389 Circuit 390 Switched network. To provide for this function, the 391 subscription marks must be set in the subscriber's HLR. This 392 is 393 equivalent to setting TDPs in the SSP. In this case the marks 394 in the HLR (which are copied to the Visitor Location Register 395 [VLR] 396 on location update) are not mapped into Trigger Detection 397 Points. 398 As with TDP setting, this is outside of the scope of SPIRITS 399 protocol. 401 In order to support this function in SPIRITS, the SPIRITS 402 protocol 403 should be able to map the CAMEL specific operations into 404 events notification to the SPIRITS client. Since the SCP 405 receives 406 the information about the mobility state, this involves 407 the C interface. (This is just an extension of the DP 408 notification 409 mechanism from the SPIRITS client to the SPIRITS gateway). 411 The events (which are not DP-related) which need notifications are 413 - Location Update in the same VLR service area. 414 - Location Update in another VLR service area. 415 - IMSI attach. 416 - MS initiated IMSI detach. 417 - Network initiated IMSI detach. 419 With this mechanism, the SPIRITS services can use the location 420 information. 421 For example, the Internet Call Waiting service can re-direct the 423 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 425 call 426 to a mobile phone. 428 c) Supplementary Services Notification. 430 This mechanism makes a SPIRITS server aware of a subscriber 431 having invoked one of the following supplementary services: 432 Explicit Call Transfer, Call Deflection, Call Completion on 433 Busy 434 Subscriber, or Multi-Party. 436 7. PINT-related Requirements 438 Before a SPIRITS service can be invoked, the relevant IP Host must be 439 registered. Thus, Registration is an essential service (not yet 440 addressed by PINT), which is initiated from the IP side. The 441 registration information is ultimately used by the PSTN to 442 authenticate the subscriber. 444 Depending on the model, this can be done in two ways with the present 445 architecture: 447 1) The PINT Client issues the appropriate Register message over the 448 interface A, which is then passed to by PINT server to the SPIRITS 449 Proxy and SPIRITS Client: 451 PINT C.: -- REGISTER --> PINT S. [--> SPIRITS Proxy --> SPIRITS C.]. 452 In this case the SPIRITS Client (co-located with the service control) 453 is responsible for record keeping and the authentication. 455 2) The PINT Client issues the appropriate Register message to the 456 PINT Server, which then passes this information to the PSTN service 457 control "by magic". 459 The second model is much easier to handle, because it involves only 460 one relevant interface ("A"); however it assumes no interworking 461 between PINT and SPIRITS except that the SPIRITS Client finds "by 462 magic" that a friendly and expecting IP Host is alive and well. 464 Finally, in the event PINT is not implemented, the SIP SUBSCRIBE 465 mechanism can be used. 467 As noted in previous section, the existing SUBSCRIBE/NOTIFY PINT 468 building blocks [3] must be extended for their use in SPIRITS for the 469 purposes of setting DPs/getting DP event notifications. (A more 470 general SIP mechanism for the same PINT-introduced block is described 471 in [4]; it provides the necessary mechanism for specifying relevant 472 events.) Conversely, the same building blocks for this functional 473 capabilities can be used in both PINT and SPIRITS protocols. Note, 474 however, that in SPIRITS the PSTN notification may arrive without a 475 particular subscription to an event (in the case of a statically set 476 DP). 478 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 480 8. Follow-up on Event Notifications 482 The requirements of this section are neither PINT-specific, nor IN- 483 specific; their role is to outline the remaining element necessary 484 for the delivery of the SPIRITS service, which is the reaction to the 485 notification received. 487 In a particular scenario where 489 a) The IP subscriber registers a SPIRITS service; 491 b) A call triggering the SPIRITS service is received (and 492 notification is sent); and 494 c) The call disposition is performed by the end user, 496 the signalling flow is demonstrated in Figure 2. 498 |----> REGISTER ----->| 499 SPIRITS |<---- EVENT <-----|SPIRITS 500 Proxy |----> DISPOSITION ---->| Client 501 | | 502 | 503 | 504 | 505 V 506 Service Control 507 | 508 | 509 V 510 SSP 512 Figure 2: Sequence of SPIRITS actions 514 One of the following actions is required by benchmark services: 516 a) Accept the incoming call. 518 b) Reject the incoming call. 520 c) Redirect the incoming call. 522 d) Accept the call via VoIP (this particular item is outside 523 of the scope of SPIRITS WG). 525 Accordingly, the SPIRITS protocol should define the following message 526 types: 528 a) S->P: 530 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 532 b) S->P: <[Reject Call],[Cause]> 534 c) S->P: <[Redirect Call],[Redirection Destination]> 536 8. Methodology 538 To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set 539 of messages), the PSTN events associated with each detection point of 540 the Basic Call State Model should be examined. To date, the CS-2 BSCM 541 has the richest set of DPs, although not all switching exchanges have 542 implemented it. 544 To determine the MINIMUM information available to the SPIRITS client 545 (this information is to be carried by the SPIRITS protocol from 546 SPIRITS client to SPIRITS server), each DP-specific information 547 elements needs to be examined. 549 Parameters should be event-specific, the folowing generic types of 550 parameters are expected to be mandatory: 552 - timer (for no answer) 554 - midcall control info (for mid_call) 556 - number of digits (for collected_information) 558 10. Security Considerations 560 It is assumed that the interface C is between trusted entities. Thus, 561 there are no particular IN-related or requirements to the protocol 562 pertinent to this interface. The assumption that the PINT Client and 563 SPIRITS Server are co-located dictates that the security 564 considerations for the A and B interfaces are exactly same. 566 11. Acknowledgements 568 The authors are grateful to all participants in the SPIRITS group for 569 the discussion that has been shaping this work. Many thanks go to 570 Jorgen Bjorkner, Jim Buller, Lawrence Conroy, Soren Nyckelgard, and 571 John Voelker for his incisive comments. 573 12. References 575 [1] Slutsman, L (Ed.) et al, The Spirits Architecture, , Work in Progress. February 2001. 578 [2] Lu, H. (Editor), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, 579 S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, 580 J. Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN- 581 Initiated Services." RFC 2995, November 2000. 583 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 585 [3] S. Petrack, and L. Conroy, The PINT Service Protocol: Extensions 586 to SIP and SDP for IP Access to Telephone Call Services, Proposed 587 Standard. RFC 2848, June 2000. 589 [4] A. Roach, Event Notification in SIP, , Work in Progress. October 2000. 592 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 593 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 594 2045, November 1996. 596 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 597 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 599 [7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, 600 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 602 [8] Handley, M. and V. Jacobsen, "SDP: Session Description 603 Protocol", RFC 2327, April 1998. 605 13. Authors' Addresses 607 Lev Slutsman 608 AT&T Laboratories 609 200 Laurel Ave. 610 Middletown, New Jersey, 07748 611 Phone: (732) 420-3752 612 Email: lslutsman@att.com 614 Igor Faynberg 615 Bell Labs/Lucent Technologies 616 Room 4C-611A, 101 Crawfords Corner Road 617 Holmdel, New Jersey, 07733 618 Phone: (732) 949-0137 619 Email: faynberg@lucent.com 621 Jorge Gato 622 Airtel Movil, S.A. 623 Avda de Europa, 1. 624 28108 Alcobendas (Madrid). Spain 625 Tel: +34 607 13 31 10 626 Fax. +34 607 13 30 57 627 Email: jgato@airtel.es 629 Hui-Lan Lu 630 Bell Labs/Lucent Technologies 631 Room 4C-607A, 101 Crawfords Corner Road 632 Holmdel, New Jersey, 07733 633 Phone: (732) 949-0321 635 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001 637 Email: huilanlu@lucent.com 639 Full Copyright Statement 641 "Copyright (C) The Internet Society (date). All Rights Reserved. This 642 document and translations of it may be copied and furnished to others, 643 and derivative works that comment on or otherwise explain it or assist 644 in its implementation may be prepared, copied, published and 645 distributed, in whole or in part, without restriction of any kind, 646 provided that the above copyright notice and this paragraph are 647 included on all such copies and derivative works. However, this 648 document itself may not be modified in any way, such as by removing the 649 copyright notice or references to the Internet Society or other 650 Internet organizations, except as needed for the purpose of developing 651 Internet standards in which case the procedures for copyrights defined 652 in the Internet Standards process must be followed, or as required to 653 translate it into followed, or as required to translate it into 654 languages other than English. 656 The limited permissions granted above are perpetual and will not be 657 revoked by the Internet Society or its successors or assigns. 659 This document and the information contained herein is provided on an 660 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 661 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 662 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 663 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 664 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 SPIRITS Requirements-Faynberg-Gato-Lu-Slutsman February 2001