From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3298.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc3298.txt (limited to 'doc/rfc/rfc3298.txt') diff --git a/doc/rfc/rfc3298.txt b/doc/rfc/rfc3298.txt new file mode 100644 index 0000000..15d743d --- /dev/null +++ b/doc/rfc/rfc3298.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group I. Faynberg, Editor +Request for Comments: 3298 Lucent Technologies +Category: Informational J. Gato + Vodaphone + H. Lu + Lucent Technologies + L. Slutsman + AT&T + August 2002 + + + Service in the Public Switched Telephone Network/Intelligent Network + (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document describes the SPIRITS protocol requirements, based on + the architecture presented in RFC 3136. (SPIRITS stands for "Service + in the PSTN/IN Requesting InTernet Service".) The purpose of the + protocol is to support services that originate in the Public Switched + Telephone Network (PSTN) and necessitate the interactions between the + PSTN and the Internet. Similarly, such services are called SPIRITS + services. (Internet Call Waiting, Internet Caller-ID Delivery, and + Internet Call Forwarding are examples of SPIRIT services, but the + protocol is to define the building blocks from which many other + services can be built.) On the PSTN side, the SPIRITS services are + initiated from the Intelligent Network (IN) entities; the earlier + IETF work on the PSTN/Internet Interworking (PINT) resulted in the + protocol (RFC 2848) in support of the services initiated the other + way around--from the Internet to PSTN. + + To this end, this document lists general requirements for the SPIRITS + protocol as well as those pertinent to IN, Wireless IN, and PINT + building blocks. The document also presents the SPIRITS WG consensus + on the choice of the SPIRITS signaling protocol. + + + + + + +Faynberg, et al. Informational [Page 1] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + +1. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + + Unless otherwise qualified, the term PINT is used here not to refer + to the present PINT services and protocol, but in reference to the + scope of the generic PINT (vs. SPIRITS) service characteristics-- + services being invoked from an IP network (vs. PSTN). + +2. Introduction + + This document describes the SPIRITS protocol requirements, based on + the architecture presented in RFC 3136. (SPIRITS stands for "Service + in the PSTN/IN Requesting InTernet Service.") The purpose of the + protocol is to support services that originate in the Public Switched + Telephone Network (PSTN) and necessitate the interactions between the + PSTN and the Internet. Such services are called SPIRITS services. + (Internet Call Waiting, Internet Caller-ID Delivery, and Internet + Call Forwarding are examples of SPIRIT services, but the protocol is + to define the building blocks from which many other services can be + built.) On the PSTN side, the SPIRITS services are initiated from + the Intelligent Network (IN) entities; the earlier IETF work on the + PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) + in support of the services initiated the other way around--from the + Internet to PSTN. + + To this end, this document lists general requirements for the SPIRITS + protocol as well as those pertinent to IN, Wireless IN, and PINT + building blocks. The document also presents the SPIRITS WG consensus + on the choice of the SPIRITS signaling protocol. The joint + PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1. + + It is assumed that the Spirits Client is either co-located with the + IN Service Control Function (SCF) or communicates with it (over the + PSTN-specific interface D) in such a way so as to act on behalf of + the PSTN/IN. (This assumption is confirmed by current + implementations, as reported in [2].) + + The SPIRITS services are invoked (and, subsequently, the SPIRITS + protocol is initiated) when a message from a SPIRITS Client (located + in the IN Service Control Point [SCP] or Service Node [SN]) arrives + on interface C to the SPIRITS gateway. The Spirits gateway processes + the message and, in turn, passes it on over the Interface B to the + SPIRITS server. In most practically important cases, the request + from a SPIRITS client is ultimately caused by a request from a + Central Office (i.e., a telephone switch) sent to either the SCP or + + + +Faynberg, et al. Informational [Page 2] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + SN, although the Internet-based service initiation by these elements + that had not been triggered by the Central Office is theoretically + possible. (Definitely, none of the SPIRITS benchmark services are + initiated in such a way, so, for the purposes of the SPIRITS protocol + development, it should be assumed that the service invocation was a + direct result of an earlier action by the Service Switching + Function.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Faynberg, et al. Informational [Page 3] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + ...................... + +----------------+ . . + | +------------+ | . +------------+ . + | | | | A . | | . + | | PINT Client|********************|PINT Server/|******** + | | | | . | Gateway | * + | +------------+ | . +------------+ . * + | | . . * + | Subscriber's | . . * + | | . . * + | IP Host | . . * + | | . +------------+ . * + | +------------+ | . | SPIRITS | . * + | | SPIRITS | | B . | Gateway | . * + | | Server |********************| | . * E + | | | | . +------------+ . * + | +------------+ | . * . * + +----------------+ . * . * + ...........*.......... * + * * + * * + Subscriber's * C * + Telephone * * + * * + (---) * * + * * * + * * * * + ++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++ + * * * + * * * + * +------------------+ * + * Line | SPIRITS Client | * + * | | * + +--------------------+ +---+----- D ---------+-*+ + | | INAP/SS7 | | + |Service Switching ************Service Control Function | + | Function | | | + | | +-------------------------+ + | | + | | + +--------------------+ + + Figure 1. Joint PINT/SPIRITS Architecture + + + + + + + + +Faynberg, et al. Informational [Page 4] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + With PINT (and that also applies to the PINT architecture and + protocol as described in [3]), the service request to the PINT Server + is always initiated by the PINT Client over the interface A. The PINT + Server can either be co-located with the IN Service Control or a + similar entity (referred to as "Executive System" by [3]) or + communicate with it over the PSTN-specific interface E. + + As Figure 1 shows, the PINT Client and SPIRITS Server are co-located + in Subscriber's IP Host. In fact, both can be implemented to run as + one process. No provision is made for interactions between the PINT + Client and Spirits Server. Similarly, the PINT Server/PINT Gateway + and SPIRITS gateway are assumed to be co-located, too. This + assumption is convenient but not essential; the PINT Server could + also be co-located with the SPIRITS Client. In either case, no + specific provision is made to define interworking between either the + PINT Server and Spirits Gateway or PINT Server and SPIRITS Client + other than by listing the overall PINT-related requirements. + + Since the currently deployed worldwide wireless networks are based on + circuit switching, they are considered PSTN networks for the SPIRITS + purposes. Adding SPIRITS type of services to wireless networks can + allow new services to be developed (for example geolocation + information can be handled in the IP network). + + Nevertheless, there are certain peculiarities of wireless networks, + which force considerations to be made in the protocol + requirements and in the SPIRITS architecture. + + A particular Wireless IN standard development being considered here + is CAMEL phase 3, standardized by the Third Generation Partnership + group (3GPP). The relevant service and architectural considerations + and protocol requirements are presented later in this document. As + far as the architecture is concerned, certain wireless events are + generated by Home Location Register (HLR), which may, but does not + have to, be part of the Mobile Switching Center (MSC) (a wireless + equivalent of the SSP). These events are communicated to Service + Control, at which point they use the same mechanism for invoking + SPIRITS services that the IN would. + + The rest of this document addresses the general requirements, + IN Requirements, specific Wireless IN requirements, PINT + Requirements, the protocol development methodology, and security + issues, in that order. + + + + + + + + +Faynberg, et al. Informational [Page 5] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + +3. General Requirements + + Based on the success of extending SIP for PINT ([3]) and, especially, + the results of pre-SPIRITS implementations reported in [2], the + Session Initiation Protocol (SIP) [7] has been chosen as the + signaling base protocol for SPIRITS. + + Thus, it is a requirement that specific SPIRITS-related parameters be + carried in a manner consistent with SIP practices. In particular, + either Session Description Protocol (SDP) [8] or Multi-purpose + Internet Mail Extensions MIME [5-6] may be used for this purpose. + Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and + extensions already defined in PINT, no new SIP extensions are + foreseen; instead the SPIRITS protocol is to rely on the above + extension mechanisms. + + It is by no means a requirement that any SPIRITS implementation + automatically support PINT services. The SPIRITS protocol must be + defined in a manner where, as the minimum, it can support only the + basic notification mechanism without relying on PINT services or + otherwise relying on persistent interactions with PSTN. + Nevertheless, it has been demonstrated [2] that combining PINT + building blocks with those of SPIRITS is beneficial to building rich, + enhanced PSTN/Internet services, so the SPIRITS protocol must meet + the PINT-related requirements listed in section 7 of this document. + + One specific example demonstrating the application of the latter + requirement, which is elaborated on further in this document, is as + follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far + as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN + (Detection Point) notification will always arrive via the SIP INVITE + method; however, to implement persistent interactions with the PSTN, + the SUBSCRIBE method may be used to obtain further notifications of + the PSTN events. Subsequently, these events will be reported on by + means of the NOTIFY method. + +4. IN Requirements + + The interface immediately relevant to IN is that between the SPIRITS + Client and SPIRITS Gateway (interface C). A typical message (which + starts a SPIRITS service) looks like this: + + C -> G: , + + The relevant events correspond to the detection points (DPs) of the + IN Basic Call State Model (BCSM). The is a function + of a specific DP; it contains the parameters relevant to it. The + following requirements apply: + + + +Faynberg, et al. Informational [Page 6] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + 1) The list of the DPs to be covered encompasses those defined in the + IN Capability Set 3 BCSM as well as those which relate to the + Wireless IN (WIN) specified by the IMT 2000 project in ITU-T. + + 2) Not all parameters associated with such DPs are needed by the + SPIRITS benchmark services, nor may all the parameters be needed + in SPIRITS. The selection of the relevant parameters is part of + the SPIRITS protocol definition. + + 3) It is desirable to avoid semantic overload of protocol messages. + (One way to achieve that is to match each type of an event with a + message that corresponds to it.) As the SPIRITS protocol is + designed as a set of extensions to another (existing) protocol + with the defined message set, the syntax and semantics of the + extensions should be defined with this requirement in mind. + + 4) The ITU-T Recommendations use the abstract syntax notation (ASN.1) + to specify the semantics of the IN Application Protocol (INAP) + parameters, which are expected to be binary-encoded. Neither the + use of the ASN.1, nor the requirement for binary encoding are the + typical requirements for the IETF application protocols. + Recognizing that, provisions must be made for careful + specification of the conversion of the INAP parameters to text, + which must preserve their original semantics. The actual + conversion of the parameters is the function of the SPIRITS + Client. + + In order to issue an initial query (or a notification) to service + control, a switch must have such a DP set. This can be done + statically via service management (this particular action should + be left to implementation and thus is considered outside of the + scope of SPIRITS Protocol) or dynamically--but only for the + purpose of a particular call--from the service control. In the + latter case, it is part of the SPIRITS (or PINT) protocol to + request the event notification from the service control. The SIP + specific event notification scheme [4] should be specifically + considered. This function can be performed by either the Spirits + Client or PINT Server, the distinction being further discussed in + the next section. Assuming that it is performed by the SPIRITS + Client, the relevant message should look like: + + G->C: SUBSCRIBE , + + where refers to a particular DP; determines whether + the Event Detection Point (EDP) is to be armed as EDP Request + (EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is + not foreseen because it would not provide any additional + capability for SPIRITS); and the is the + + + +Faynberg, et al. Informational [Page 7] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + list of the values of the parameters associated with the EDP (for + example, if the DP in question is O_No_Answer, then the value of + the appropriate timer should be included in the list). Note that + such a subscription may also originate at a) PINT Client or b) + SPIRITS Gateway, either of which may (but does not have to) have a + locally significant definition of the . In either case, it + is the function of the SPIRITS Client to translate the definition + of the Event into a particular DP (or set of DPs) when passing the + message to Service Control. To summarize, for the case when PINT + and SPIRITS events are defined in a way where they do not refer to + the BCSM DPs, it is the function of the SPIRITS Client to define a + mapping: + + Event -> DP List, + + for each event for which the PSTN notification is needed. + + The list of CS-3 DPs envisioned in SPIRITS is: + + - origination_attempt_authorized (the SPIRITS service can control + call attempts, (for example, to limit calls during specific + time periods) + + - collected_information and analyzed_information (for SPIRITS + outgoing call screening) + + - o_answer, o_term_seized, and t_answer (to release SPIRITS + resources after the call is complete and perform relevant OA&M + actions such as creating a record of attempts to reach a party + via various means like land-line phone, cell phone, SMS, or + paging.) + + - o_no_answer, route_select_failure, and t_no_answer (to re-route + a call) + + - o_called_party_busy (to re-route a call and for Internet Call + Waiting) + + - o_mid_call and t_mid_call (to assist a midcall action) + + - o_abandon, o_disconnect, t_abandon, and t_disconnect (to + terminate a SPIRITS service and release the resources and + perform relevant OA&M actions such as creating a record of + attempts to reach a party via various means like land-line + phone, cell phone, SMS, or paging.) + + + + + + +Faynberg, et al. Informational [Page 8] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + In addition, the following DPs are relevant to the present SPIRITS + milestone services: + + - termination_attempt_authorized + + - facility_selected_and_available (could be used in SPIRITS + Internet Caller-ID) + + - t_busy (for Internet Call Waiting and Call Forwarding). + +5. Wireless-IN-related Requirements + + Wireless IN covers several types of "calls," which are neither + circuit switched nor have an effect on circuit switched calls. For + this reason, those are not considered in SPIRITS requirements. To + further clarify this point, the types of "calls" not considered are: + + - USSD (Unstructured Supplementary Service Data) + + - GPRS (General Packet Radio System) + + - SMS (Short Message System) + + The types of calls relevant to SPIRITS are as follows: + + a) Voice Calls. In this case no new DP is needed since CAMEL DPs + are included in CS2. The only special case is "Not Reachable" + (when it is detected that the mobile user is out of coverage or + has switched off), which is mapped as a special cause in the + Busy DP. Since the Busy DP parameters would be received (if a + SPIRITS service has subscribed to Busy), it would be possible + to distinguish a "busy" from a "not reachable" situation. + + This translates into the requirement that one of the parameters + in the Event Notification message (from SPIRITS Client to + SPIRITS Gateway, over the interface C) denotes the "cause" for + the Busy Detection Point. + + Another aspect of difference, when compared to PSTN, is setting + of static DPs. In CAMEL networks, this is done in the Home + Location Register (HLR) (and copied to the VLR during location + update). It is important to note this difference, even though + it has no effect on SPIRITS protocol. + + + + + + + + +Faynberg, et al. Informational [Page 9] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + b) Mobility Management events. This allows a SPIRITS server to be + notified of changes of location of a mobile user. The events + would only be applicable to mobile users reachable through a + Circuit-Switched network. To provide for this function, the + subscription marks must be set in the subscriber's HLR. This + is equivalent to setting TDPs in the SSP. In this case, the + marks in the HLR (which are copied to the Visitor Location + Register [VLR] on location update) are not mapped into Trigger + Detection Points. + + As with TDP setting, this is outside of the scope of SPIRITS + protocol. + + In order to support this function in SPIRITS, the SPIRITS + protocol should be able to map the CAMEL specific operations + into events notification to the SPIRITS client. Since the SCP + receives the information about the mobility state, this + involves the C interface. (This is just an extension of the DP + notification mechanism from the SPIRITS client to the SPIRITS + gateway). + + The events (which are not DP-related) which need notifications + are: + + - Location Update in the same VLR service area + + - Location Update in another VLR service area + + - IMSI attach + + - MS initiated IMSI detach + + - Network initiated IMSI detach. + + With this mechanism, the SPIRITS services can use the user- + profile-based location information. For example, the Internet + Call Waiting service can re-direct the call to a mobile phone. + + c) Supplementary Services Notification. + + This mechanism makes a SPIRITS server aware of a subscriber + having invoked one of the following supplementary services: + Explicit Call Transfer, Call Deflection, Call Completion on + Busy Subscriber, or Multi-Party. + + + + + + + +Faynberg, et al. Informational [Page 10] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + +6. PINT-related Requirements + + Before a SPIRITS service can be invoked, the relevant IP Host must be + registered. Thus, Registration is an essential service, which is + initiated from the IP side. The registration information is + ultimately used by the PSTN to authenticate the subscriber. + + Depending on the model, this can be done in two ways with the present + architecture: + + 1) The PINT Client issues the appropriate Register message over the + interface A, which is then passed by the PINT server to the SPIRITS + Gateway and SPIRITS Client: + + PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS + C.]. In this case the SPIRITS Client (co-located with the service + control) is responsible for record keeping and the authentication. + + 2) The PINT Client issues the appropriate Register message to the + PINT Server, which then passes this information to the PSTN service + control "by magic". + + The second model is much easier to handle, because it involves only + one relevant interface ("A"); however it assumes no interworking + between PINT and SPIRITS except that the SPIRITS Client finds "by + magic" that a friendly and expecting IP Host is alive and well. + + Finally, in the event PINT is not implemented, the SIP SUBSCRIBE + mechanism can be used. + + As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT + building blocks [3] must be extended for their use in SPIRITS for the + purposes of setting DPs/getting DP event notifications. (A more + general SIP mechanism for the same PINT-introduced block is described + in [4]; it provides the necessary mechanism for specifying relevant + events.) Conversely, the same building blocks for the functional + capabilities can be used in both PINT and SPIRITS protocols. Note, + however, that in SPIRITS the PSTN notification may arrive without a + particular subscription to an event (in the case of a statically set + DP). + +7. Follow-up on Event Notifications + + The requirements of this section are neither PINT-specific, nor IN- + specific; their role is to outline the remaining element necessary + for the delivery of the SPIRITS service, which is the reaction to the + notification received. + + + + +Faynberg, et al. Informational [Page 11] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + In a particular scenario where: + + a) The IP subscriber registers a SPIRITS service; + + b) A call triggering the SPIRITS service is received (and + notification is sent); and + + c) The call disposition is performed by the end user, the + signalling flow is demonstrated in Figure 2. + + |----> Registration ----->| + SPIRITS |<-- Event Notification <-- | SPIRITS + Gateway |---> Call Disposition ---->| Client + | | + | + | + | + V + Service Control + | + | + V + SSP + + Figure 2: Sequence of SPIRITS actions + + One of the following actions is required by benchmark services: + + a) Accept the incoming call + + b) Reject the incoming call + + c) Redirect the incoming call + + d) Accept the call via VoIP (this particular item is outside of + the scope of SPIRITS WG). + + Accordingly, the SPIRITS protocol should define the following message + types: + + a) S->G: + + b) S->G: <[Reject Call],[Cause]> + + c) S->G: <[Redirect Call],[Redirection Destination]> + + + + + + +Faynberg, et al. Informational [Page 12] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + +8. Methodology + + To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set + of messages), the PSTN events associated with each detection point of + the Basic Call State Model should be examined. To date, the CS-3 + BSCM has the richest set of DPs, although not all switching exchanges + have implemented it. + + To determine the MINIMUM information available to the SPIRITS client + (this information is to be carried by the SPIRITS protocol from + SPIRITS client to SPIRITS server), each DP-specific information + elements needs to be examined. + + Parameters should be event-specific, the following generic types of + parameters are expected to be mandatory: + + - timer (for no answer) + + - midcall control info (for mid_call) + + - number of digits (for collected_information) + +9. Security Considerations + + Overall, the basic aspects of security apply to SPIRITS protocol: + + - Authentication: + In the communications between the SPIRITS Client and SPIRITS + Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is + required that the information be sent between known and trusted + partners. + + - Integrity: + It is a requirement that no exchanged data be modified in transit. + + - Confidentiality: + It is a requirement that any private user information or + confidential network data be protected by the protocol (typically + through encryption, for which the protocol should allow a choice + in the algorithm selection. + + - Availability: + It is a requirement that the communicating endpoints remain in + service for authorized use only. + + + + + + + +Faynberg, et al. Informational [Page 13] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + + In addition, the protocol should support non-repudiation for those + control messages pertinent to charging the PSTN subscriber. + + As Figure 1 demonstrates, there are two distinct communications + interfaces, B and C. The B interface is, in general, across the + public Internet and is thus most vulnerable to security attacks + resulting in theft or denial of service. The C interface, on the + other hand is likely to be implemented across a service providers + intranet, where the security measures should be applied at the + discretion of the service provider. Even then, because at least one + IP host (the PINT gateway) is connected to the Internet, special + measures (e.g., installation of firewalls, although this particular + measure alone may be insufficient) need to be taken to protect the + interface C and the rest of the network from security attacks. + + The assumption that the PINT Client and SPIRITS server are co- + located, dictates that the security considerations for the A and B + interfaces are exactly same. Detailed security requirements and + solutions for interface A (and, consequently, B) can be found in RFC + 2848 [3]. + + Possible security attacks can result in both theft and denial of + services. In addition, such attacks may violate the privacy of a + PSTN subscriber. For example, with Internet Call Waiting, a + fraudulent registration (or a manipulation of integrity of a valid + registration) may force a network operator to provide to an + authorized party a full log of attempted telephone calls (accompanied + by the identification of callers). Furthermore, the calls may be + diverted to wrong recipients (who may further defraud the + unsuspecting calling party). In this case, the calling party is + using only the PSTN and thus expecting the security of communications + that are typical of the PSTN. The PSTN service providers may be + liable for the consequences of establishing wrong connections. In + addition, the PSTN service providers may be liable for inadvertent + divulging of the private information of the subscriber. + + The service and network providers need to review the possibilities of + the security attacks and prepare the means of protection from them. + Some of this may be achieved by using the means outside of those + provided by the protocol itself. For example, administrative + information (such as statistics collected by PINT MIB or SPIRITS MIB) + can help in determining violations and thwarting them. As far as the + protocol is concerned, it must provide the means for authenticating a + subscriber as well as a session. It must also provide a capability + to carry encrypted information in its body. + + + + + + +Faynberg, et al. Informational [Page 14] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + +10. Acknowledgements + + The authors are grateful to all participants in the SPIRITS group for + the discussion that has been shaping this work. Many thanks go to + Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren + Nyckelgard, and John Voelker for their incisive comments. Special + thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose + careful, detailed reviews of several versions of this document have + been particularly helpful in improving its quality. + +11. References + + [1] Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits + Architecture", RFC 3136, June 2001. + + [2] Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang, + W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S., + Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS + Implementations of PSTN-Initiated Services", RFC 2995, November + 2000. + + [3] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions + to SIP and SDP for IP Access to Telephone Call Services", RFC + 2848, June 2000. + + [4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + + [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, November + 1996. + + [7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, + "SIP: Session Initiation Protocol", RFC 2543, March 1999. + + [8] Handley, M. and V. Jacobsen, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + + + + + + + + + +Faynberg, et al. Informational [Page 15] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + +12. Authors' Addresses + + Lev Slutsman + AT&T Laboratories + 200 Laurel Ave. + Middletown, New Jersey, 07748 + + Phone: (732) 420-3752 + EMail: lslutsman@att.com + + + Igor Faynberg + Bell Labs/Lucent Technologies + Room 4D-601A, 101 Crawfords Corner Road + Holmdel, New Jersey, 07733 + + Phone: (732) 949-0137 + EMail: faynberg@lucent.com + + + Jorge Gato + Vodaphone + Avda de Europa, 1. + 28108 Alcobendas (Madrid). Spain + + Phone: +34 607 13 31 10 + Fax: +34 607 13 30 57 + EMail: jgato@airtel.es + + + Hui-Lan Lu + Bell Labs/Lucent Technologies + Room 4C-607A, 101 Crawfords Corner Road + Holmdel, New Jersey, 07733 + + Phone: (732) 949-0321 + EMail: huilanlu@lucent.com + + + + + + + + + + + + + + +Faynberg, et al. Informational [Page 16] + +RFC 3298 SPIRITS Protocol Requirements August 2002 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Faynberg, et al. Informational [Page 17] + -- cgit v1.2.3