TISPAN NGN requirements to SIP June 2006 Sipping Working Group Internet Draft Roland Jesske Expires: December 21, 2007 Denis Alexeitsev Deutsche Telekom M. Garcia-Martin Nokia 22.June 2006 Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute, draft-jesske- sipping-tispan-requirements-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 2006. Copyright Notice Copyright (C) The Internet Society (2006). Jesske Expires - December 2006 [Page 1] TISPAN NGN requirements to SIP June 2006 Abstract This document describes a set of requirements to the Session Initiation Protocol (SIP) [2] in support for simulation services provided in the context of ETSI Next Generation Networks (NGN). These requirements should help to find SIP solutions to provide the services described within this document. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Requirements in Support of Simulation Services . . . . . . . . 4 3.1. General Requirements . . . . . . . . . . . . . . . . .. . 4 3.2. Anonymous Communication Rejection (ACR) . . . . . . . . 5 3.3. Terminating Identification Presentation/Restriction (TIP/TIR) . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Advice of Charge (AoC) . . . . . . . . . . . . . . . . 6 3.5. Communication Completion on Busy Subscriber (CCBS) and Communication Completion on no Reply (CCNR) . . . . . . . 7 3.6. Malicious Communication Identification (MCID) . . . . . . 9 3.7. Communication Waiting (CW) . . . . . . . . .. . . . . . . 10 3.8. Communications Diversion (CDIV) . . . . . .. . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . .. . . . . . . 11 7.2. Informational References . . . . . . . . . .. . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 1. Conventions This document does not specify any protocol of any kind. Therefore, the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, as described in RFC-2119 [1], does not apply. 2. Overview The European Telecommunications Standards Institute (ETSI) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) is defining the release 1 of the TISPAN Jesske Expires - December 2006 [Page 2] TISPAN NGN requirements to SIP June 2006 Next Generation Network (NGN) aiming the creation of a multimedia fixed network. Generally NGN is largely based on the 3rd Generation mobile Partnership Project (3GPP) IP Multimedia Subsystem (IMS) Release 7 with additions required to support the fixed access.. The TISPAN NGN project has selected SIP profiled by 3GPP TS 24.229 [4] for the IMS as the protocol used to establish and tear down multimedia sessions in the context of NGN. The goal for TISPAN is that only one IMS core specification is defined for both fixed and wireless multimedia applications. While ETSI is committed to the creation of new multimedia applications and services, the importance of provided support to existing Integrated Services Digital Network and Public Switched Telephone Network (ISDN/PSTN) supplementary services has been also acknowledged. We refer to supplementary services provided with SIP in the context of NGN as 'simulation services'. They are referred to as simulation services because they need to be adapted to be provided with SIP, so small variations are expected when compared with the equivalent ISDN/PSTN supplementary service. For example, all the services that depend on a busy condition from a user who is using a single telephone become broader in SIP when the user is using and registered from different terminals, since the busy indication from one terminal might not indicate that the user is not willing to accept other sessions in other terminals. 3GPP TS 24.229 [4] is used to simulate the regarding services, but to fulfill the requirements defined within ETSI TISPAN NGN Release 1 some further SIP support is needed. Note that sometimes the realization of a service requires the implementation of a number of SIP extensions in SIP User Agents. We do not expect SIP UAs not implementing those extensions to provide a service to the user. In that case, the basic session will be provided without the additional service. This document defines some input requirements to support the implementation of simulation services. Particularly, we have listed those requirements for which we do not have a clear indication of the implementation, or that clarify the behaviour of the service. However, we do not list all the requirements that describe a service. Readers interested in a comprehensive set of requirements should refer to the ETSI specifications for the corresponding PSTN/ISDN supplementary service (even when such specification does not consider SIP or IMS). We have included a list of the PSTN/ISDN supplementary services specification as references. It is generally understood that not every requirement listed in this memo will require a SIP extension. A companion memo, Analysis of Jesske Expires - December 2006 [Page 3] TISPAN NGN requirements to SIP June 2006 TISPAN req. to SIP [5] provides an analysis of possible implementations of these requirements and explores different extensions when those are needed. All mentioned 3GPP and ETSI Standards are free available under http://pda.etsi.org/pda/queryform.asp and http://www.3gpp.org/ftp/Specs/html-info/. The resulting work of this collaboration will eventually be contributed to International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) as part of their NGN work to have an alignment between the work of the standardization organizations. Some of the services for which we have produced requirements are classified as "regulatory services", i.e., required by national administrations as a prerequisite for the operation of the network. We have marked these services as an assistance to provide an indication of prioritization when developing solutions. 3. Requirements in Support of Simulation Services 3.1. General Requirements This section provides a collection of general requirements that are applicable to all the services described later. Solutions developed to meet the rest of the requirements must have into account those described in here. REQ-GEN-1: All simulation services must provide interoperability with the PSTN/ISDN. By interoperability we mean that, in the case that a simulation or supplementary service is provided to one of the users when one of the endpoints is located in the PSTN and the other is located in the NGN IMS network, the user should receive the service without any degradation as if the service were provided in the native network. REQ-GEN-2: Most of the PSTN/ISDN services are targeting sessions where audio is the only media stream, while SIP allows to establish a session with any type of media. The user's experience should not be limited to that of the traditional supplementary services. Thus, when applicable, the simulation services should be applicable to any type of communication, including but not restricted only to, audio calls (e.g., including instant messaging, video calls, etc.). REQ-GEN-3: SIP User Agents not providing a simulation service should not be influenced by the establishment of a given communication; they are simple not able to provide the related service. Jesske Expires - December 2006 [Page 4] TISPAN NGN requirements to SIP June 2006 REQ-GEN-4: It must be possible to convey the language(s) known to the caller. REQ-GEN-5: It must be possible to indicate that the caller is an operator. REQ-GEN-6: It must be possible to assert that the caller has priority. REQ-GEN-7: Note: we seem to have requirements, based on the PSTN/ISDN, to indicate that some calls are data calls, test calls, or originated in a payphone. We need to find the correct formulation of those requirements. 3.2. Anonymous Communication Rejection (ACR) This service allows a callee to instruct the network to automatically reject incoming communications when the caller is anonymous. The ACR supplementary service is described in ETSI EN 300 798 [19]. The services also contains provisions for exceptional cases where the service is overridden. One of these cases consist of a PSTN originated call where the network could not provide an identification of the calling party number, such as is the case when the call was originated in an analogue network. ACR is a regulatory service. REQ-ACR-1: The originating network shall be able to indicate to the terminating network, that the caller has requested anonymity. REQ-ACR-2: The ACR simulation service requires the caller to be informed that the communication was rejected because the SIP request was anonymous and the callee had the ACR service activated. 3.3. Terminating Identification Presentation/Restriction (TIP/TIR) These services support the presentation or restriction of a callee's identity to the caller. They are the simulation of the ISDN/PSTN Connected Line Identification Presentation/Restriction (COLP/COLR) supplementary services. The network does not assert the identity referred to in this service; the callee merely indicates an additional identity where he is reachable, e.g., for a new future communication. The service is useful in scenarios where the caller dialled a SIP URI that is translated to another SIP URI, such as the case when a user dials a free-phone URI that is translated to a real URI. The callee may want to indicate the real addressable URI to the caller. Jesske Expires - December 2006 [Page 5] TISPAN NGN requirements to SIP June 2006 The corresponding COLP supplementary service is described in ETSI EN 300 094 [7]. The corresponding COLR supplementary service is described in ETSI ETS 300 095 [8]. TIP and TIR are regulatory services. REQ-TIP-1: In addition to any network asserted identity, it must be possible for the callee to indicate in a SIP response an additional identity where the user is reachable for future direct communications. Note that the requirement refers to the user, not to the same instance of the User Agent. REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be formatted as a SIP URI [2] or TEL URL [3]. A translation between SIP URI and TEL URL by the network is not requested. REQ-TIP-3: The identity mentioned in REQ-TIP-1 is considered an end user supplied information that is not asserted by the network. 3.4. Advice of Charge (AoC) The Advice of Charge service allows the caller to request the displaying of tariff information related to the communication. The caller can request the displaying of charging information at setup time (AoC-S), during a session (AoC-D), or at the end of it (AoC-E), including a few seconds after the communication has ended. The AoC-S supplementary service is described in ETSI ETS 300 178 [15]. The AoC-D supplementary service is described in ETSI ETS 300 179 [16]. The AoC-E supplementary service is described in ETSI ETS 300 180 [17]. REQ-AoC-1: The AoC service must be possible to be invoked at the time a communication is initiated. REQ-AoC-2: It must be possible for a caller to receive charging information once the service has been invoked at the time a communication is initiated, during the communication, and when the communication has ended. REQ-AoC-3: The information supplied to the user is asynchronously generated, updated and reported to the user when new charging information is available. For example, when the cumulative charging value changes more then a certain predefined value; or, as time passes by, the charging implications might change; or a re-INVITE can request new media streams that will impact charging. Asynchronously transport means that the information shall be transported at any time during Jesske Expires - December 2006 [Page 6] TISPAN NGN requirements to SIP June 2006 and after (e.g., within a certain period of time) the communication, but within the session context, when it is needed. 3.5. Communication Completion on Busy Subscriber (CCBS) and Communication Completion on no Reply (CCNR) CCBS and CCNR are very similar in nature, thus, we describe the requirements for both services at the same time. Communication Completion on Busy Subscriber (CCBS) provides the caller with the ability to complete a requested communication to a busy callee without having to make a new communication attempt when the callee becomes not busy anymore. It is possible for the caller to request several communications to be under the CCBS requested status. Also the callee can be subject to several CCBS communications from different callers. Additionally, the service provides queue management to arbitrate several CCBS requests to the same callee. The CCBS supplementary service is described in ETSI EN 300 357 [18]. Communication Completion on no Reply (CCNR) provides the caller with the ability to complete a requested communication to a callee without having to make a new communication attempt when the callee showed activity. The CCNR supplementary service is described in ETSI EN 301 134 [14]. For the purpose of this service, we provide the following definitions (sources: ETSI EN 300 357 [18] and ETSI EN 301 134 [14]): CCBS/CCNR request: an instance of an activation of the CCBS/CCNR service which is held in a queue pending the correct conditions for the CCBS/CCNR service to be completed. Suspended CCBS/CCNR request: a CCBS/CCNR request which cannot be served even if callee is in the appropriate state because the caller is busy. CCBS/CCNR service duration timer: maximum time the CCBS/CCNR service will remain activated for the caller within the network. CCBS call: a communication generated by the network connecting the caller to the callee, resulting from the callers' acceptance of a CCBS recall. CCBS recall: an indication informing the caller that the network is ready to initiate a CCBS call to the callee and that the network is awaiting a response to this indication. Jesske Expires - December 2006 [Page 7] TISPAN NGN requirements to SIP June 2006 Requirements affecting CCBS/CCNR: Invocation: REQ-CCBS/CCNR-1: In order to assure that end-to-end functionality of the CCBS/CCNR services is possible, there must be a mechanism whereby the caller gets knowledge of the availability of the CCBS/CCNR service at the callee or the PSTN/ISDN terminal on a communication by communication basis. REQ-CCBS/CCNR-2: It must be possible for the caller to invoke the CCBS/CCNR service. Control of callee status and information to the caller: REQ-CCBS/CCNR-3: The CCBS/CCNR simulation service should be able to handle queues and arbitrate multiple simultaneous CCBS/CCNR requests according to a locally defined policy (e.g., first in first out). REQ-CCBS/CCNR-4: The entity providing the CCBS/CCNR service needs to know the change of the status at the callee's (e.g., in CCBS a transition when the callee sends or receive a BYE request for an existing session; in CCNR any activity indicated by the presence of the user, such as a key press or any other interaction with the device). REQ-CCBS/CCNR-5: The entity providing the CCBS/CCNR service needs to learn the capability of the callee's UAs to provide an indication of the change of status, not later than upon failure response (CCBS) or not later than the alerting phase (CCNR). REQ-CCBS/CCNR-6: The CCBS/CCNR service duration timer expires after a certain time controlled by the entity providing the CCBS/CCNR service. REQ-CCBS/CCNR-7: It must be possible for the network to prioritize CCBS/CCNR recalls towards the callee, above regular calls. This implies that any communication performed as a result of the execution of a CCBS/CCNR request should be distinguishable from regular communications. REQ-CCBS/CCNR-8: The CCBS/CCNR service must be able to inform the caller when the service-specific condition related to the callee's state is met. REQ-CCBS/CCNR-9: There must be a mechanism whereby the callee can accept or reject CCBS/CCNR requests. REQ-CCBS/CCNR-10: If the caller accepts a CCBS recall, other terminating calls towards the callee should be treated as if the callee were already busy. REQ-CCBS/CCNR-11: Jesske Expires - December 2006 [Page 8] TISPAN NGN requirements to SIP June 2006 There must be a mechanism whereby the entity providing CCBS/CCNR service can suspend, resume and cancel CCBS/CCNR subscriptions. REQ-CCBS/CCNR-12: When the service-specific condition related to the callee's state is met, the CCBS/CCNR service must be able to reach the caller at any of the locations where he is logged. REQ-CCBS/CCNR-13: The service-specific condition related to the callee's state must take into account the state of the user at different terminals he might be using. Suspend state: REQ-CCBS/CCNR-14: The entity providing the CCBS/CCNR service needs to know the change of the status at the caller's (e.g., to find out when a pending CCBS/CCNR request can be resumed or to allocate a time-slot to execute a pending CCBS/CCNR request). REQ-CCBS/CCNR-15: Should the caller be busy at the time of executing CCBS/CCNR request, the request is suspended until its status changes (back to free status). REQ-CCBS/CCNR-16: During the period of time when a CCBS/CCNR request is in suspended state for a given caller, no other CCBS/CCNR request execution must be performed for that caller. REQ-CCBS/CCNR-17: A suspended CCBS/CCNR request is resumed when caller's status changes to non-busy. The new place in the queue of that subscription is chosen according to a local policy. REQ-CCBS/CCNR-18: The suspension of a CCBS/CCNR request of a user must not impact other users in the same queue for the same callee. REQ-CCBS/CCNR-19: There must be a mechanism whereby CCBS/CCNR request initiators can check or cancel their pending CCBS/CCNR requests. 3.6. Malicious Communication Identification (MCID) The Malicious Communication Identification (MCID) enables the callee to indicate that an incoming communication is considered to be malicious and it should be identified and registered. The MCID supplementary service is described in ETSI ETS 300 128 [9]. REQ-MCID-1: In order to support the MCID simulation service there must be a mechanism whereby a user can provide an indication that an incoming request or session is considered to be malicious. The user can Jesske Expires - December 2006 [Page 9] TISPAN NGN requirements to SIP June 2006 provide this indication at the start, during or within a certain time after a session or request. REQ-MCID-2: For interoperability reasons, the MCID simulation service logic needs to get the knowledge that, even if the originator identity is missing in the signalling, it can available upon request. This is due to, e.g., interworking with the PSTN network, where, in some cases, the originator's identity is only available upon explicit request. The information can be received asynchronously in a time-frame of 1-30 seconds even after the session has been closed. Note: Requirement REQ-MCID-1 reads about the ability of the callee to provide an indication of malicious call, but there is no requirement to supply the caller's identity to the called. 3.7. Communication Waiting (CW) This service provides the ability of the callee to be informed at the time a communication is coming in that no resources are available for that incoming communication. The callee has then the choice of accepting, rejecting or ignoring the incoming communication, which is outside the scope of he service. The caller will be informed that his communication is waiting. The CW supplementary service is described in ETSI ETS 300 056 [6]. REQ-CW-1: For implement the CW simulation service it is envisioned the usage of an application server that detects some busy conditions on behalf of the user. To support this scenario a mechanism to inform the callee that a communication is in waiting state is required. REQ-CW-2: It must be possible for the CW service to inform the caller that an application server is holding the communication until the callee is available. 3.8. Communications Diversion (CDIV) This simulation service allows the diversion of incoming communications to a third party. Communications are diverted upon one of several events (e.g., the callee is busy). The service comprises the equivalent PSTN/ISDN supplementary service for Call Forwarding Unconditional (CFU), Call Forwarding Busy (CFB), Call Forwarding on No Reply (CFNR), and Call Deflection (CD). The CFU supplementary service is described in ETSI ETS 300 200 [11]. The CFB supplementary service is described in ETSI EN 300 199 [10]. The CFNR supplementary service is described in ETSI EN 300 201 [12]. The CD supplementary service is described in ETSI ETS 300 202 [13]. REQ-CDIV-1: Jesske Expires - December 2006 [Page 10] TISPAN NGN requirements to SIP June 2006 It must be possible that the caller is informed that a communication is being diverted. REQ-CDIV-2: It must be possible for the diverting user to express his privacy requirements with respect his identity. REQ-CDIV-3: The reason of the redirection must be available to the caller, callee, and network intermediaries (e.g., voice mail server). REQ-CDIV-4: It must be possible for the caller, the callee, and network intermediaries to be informed about the identity of the caller, diverting parties, and callee, if these identities are available. 4. Security Considerations This memo provides a collection of requires to SIP for the implementation of some PSTN/ISDN simulation services in Next Generation Networks. Some or most of these services require to consider the security threats and provide a solution for them. 5. Contributors Keith Drage GSM Optimus House SN5 6PP Swindon United Kingdom Phone: +44 1793 897312 Email: drage@lucent.com Sebastien Garcin France Telecom 38-40, Rue du General Leclerc 92130 Issy Les Moulineaux France 6. Acknowledgments These document has been heavily discussed in the ETSI TISPAN WG3 and the IETF sipping-tispan mailing list. The authors and contributors would like to thank Paul Kyzivat, Christian Schmidt, Phil Mart, Hans- Erik van Elburg, Michael Hammer, Tom Taylor, Shida Schubert, Jeroen van Bemmel, Silvia Tessa, Anna-Martinez Rebordosa and Rocky Wang for keeping the discussion alive and helpful comments. 7. References 7.1. Normative References [1] Bradner, S., ‘‘Key words for use in RFCs to Indicate Requirement Levels,’’ BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). Jesske Expires - December 2006 [Page 11] TISPAN NGN requirements to SIP June 2006 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, ‘‘SIP: Session Initiation Protocol,’’ RFC 3261, June 2002. [3] Schulzrinne, H., ‘‘The tel URI for Telephone Numbers,’’ RFC 3966, December 2004. 7.2. Informational References [4] 3GPP, ‘‘Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3,’’ 3GPP TS 24.229 5.13.0, June 2005. [5] Jesske, R., ‘‘Analysis of the Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute (ETSI) Next Generation Networks (NGN) simulation service,’’ draft-jesske-sipping-tispan- analysis-00 (work in progress), June 2005. [6] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call Waiting (CW) Supplementary Service; Service Description,’’ ETSI ETS 300 056, October 1991. [7] ETSI, ‘‘Integrated Services Digital Network (ISDN); Connected Line Identification Presentation (COLP) Supplementary Service; Service Description,’’ ETSI EN 300 094 v2.1.1, June 2000. [8] ETSI, ‘‘Integrated Services Digital Network (ISDN); Connected Line Identification Restriction (COLR) Supplementary Service; Service Description,’’ ETSI ETS 300 095, January 1992. [9] ETSI, ‘‘Integrated Services Digital Network (ISDN); Malicious Call Identification (MCID) Supplementary Service; Service Description,’’ ETSI ETS 300 128, March 1992. [10] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call Forwarding Busy (CFB) Supplementary Service; Service Description,’’ ETSI EN 300 199, June 2001. [11] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call Forwarding Unconditional (CFU) Supplementary Service; Service Description,’’ ETSI ETS 300 200, December 1994. [12] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call Forwarding No Reply (CFNR) Supplementary Service; Service Description,’’ ETSI EN 300 201, May 2001. [13] ETSI, ‘‘Integrated Services Digital Network (ISDN); Call Forwarding Deflection (CD) Supplementary Service; Service Description,’’ ETSI ETS 300 202, December 1994. [14] ETSI, ‘‘Integrated Services Digital Network (ISDN); Completion of Calls on No Reply (CCNR) Supplementary Service; Service Description,’’ ETSI EN 301 134 v1.1.1, October 1998. [15] ETSI, ‘‘Integrated Services Digital Network (ISDN); Advice of Charge: Charging Information at Call Set-up Time (AOC-S) Supplementary Service; Service Description,’’ ETSI ETS 300 178, November 1992. Jesske Expires - December 2006 [Page 12] TISPAN NGN requirements to SIP June 2006 [16] ETSI, ‘‘Integrated Services Digital Network (ISDN); Advice of Charge: Charging Information During the Call (AOC-D) Supplementary Service; Service Description,’’ ETSI ETS 300 179, November 1992. [17] ETSI, ‘‘Integrated Services Digital Network (ISDN); Advice of Charge: Charging Information at the End of the Call (AOC-E) Supplementary Service; Service description,’’ ETSI ETS 300 180, November 1992. [18] ETSI, ‘‘Integrated Services Digital Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) Supplementary Service; Service Description,’’ ETSI EN 300 357 v1.2.1, May 2001. [19] ETSI, ‘‘Services and Protocols for Advanced Networks (SPAN); Anonymous Call Rejection (ACR) Supplementary Service; Service description,’’ ETSI EN 301 798 v1.1.1, October 2000. Authors' Addresses Roland Jesske Deutsche Telekom Am Kavalleriesand 3 Darmstadt 64307 Germany Email: r.jesske@t-com.net Denis Alexeitsev Deutsche Telekom Am Kavalleriesand 3 Darmstadt 64307 Germany Email: d.alexeitsev@t-com.net Miguel A. Garcia Martin (editor) Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Email: miguel.an.garcia@nokia.com Changes from Version 02 to 03 Modification of AoC requirements due to TISPAN discussions Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights Jesske Expires - December 2006 [Page 13] TISPAN NGN requirements to SIP June 2006 might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jesske Expires - December 2006 [Page 14]