Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 Sipping Working Group Roland Jesske Internet Draft Deutsche Telekom Expires: December 13, 2005 Denis Alexeitsev Deutsche Telekom Miguel Garcia-Martin Nokia June 14, 2005 Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute (ETSI) Next Generation Network (NGN) simulation services draft-jesske-sipping-tispan-requirements-01 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 November 24, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Jesske, et al. Expires - December 2005 [Page 1] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 This document describes a set of requirements to the Session Initiation Protocol (SIP) [1] 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. Overview 2. Requirements for supporting simulation services within SIP 2.1 Simulation Services supported by TISPAN in Release1 2.2 Requirements to support the TISPAN Simulation Services. 3. Requirements with existing solutions 4. Security Considerations 5. IANA Considerations 1. 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 Next Generation Network (NGN). Generally NGN is largely based on the 3rd Generation mobile Partnership Project (3GPP) IP Multimedia Subsystem (IMS) Release 7. The TISPAN NGN project has selected SIP profiled by 3GPP TS 24.229 [26] 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 wire-line and wire-less multimedia applications. While defining multimedia applications it is also needed to support existing Integrated Services Digital Network and Public Switched Telephone Network (ISDN/PSTN) supplementary services based on IMS. 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. The 3GPP TS 24.229 [26] is used to simulate the regarding services but to fulfill the requirements defined within TISPAN NGN Release 1 some further SIP support is needed. This document defines some input requirements to support the implementation of simulation services. It is generally understood that not every requirement listed in this memo will require a SIP Jesske, et al. Expires - December 2005 [Page 2] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 extension. A companion Internet Draft analyses 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. 2. Requirements for supporting simulation services within SIP 2.1 Simulation Services supported by TISPAN in Release 1 The following simulation services are supported by ETSI NGN Release 1: -Communications DIVersion (CDIV). This simulation service allows the diversion of communications and the regarding service interworking with the PSTN/ISDN. 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 EN 300 200 [7]. The CFB supplementary service is described in ETSI EN 300 199 [8]. The CFNR supplementary service is described in ETSI EN 300 201 [9]. The CD supplementary service is described in ETSI EN 300 202 [10]. - Incoming Communication Barring (ICB). This simulation service allows a user to block incoming communications based on the identity of the caller. The Call Barring supplementary service is described in ETSI ETS 300 520 [22]. - CONFerence (CONF). This simulation service provides the possibility to hold centralized conferences with 3 or more users. The CONF supplementary service is described in ETSI ETS 300 183 [14]. - Message Waiting Indication (MWI). This simulation service provides the user with information about the status of a voice/video/multimedia mailbox. The MWI supplementary service is described in ETSI EN 300 650 [19]. - Originating Indication Presentation (OIP)/Originating Indication Restriction (OIR). These simulation services support the presentation or restriction of the caller's identity to the callee. They are the Jesske, et al. Expires - December 2005 [Page 3] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 simulation of the ISDN/PSTN Calling Line Identification Presentation/Restriction (CLIP/CLIR) supplementary services. The CLIP supplementary service is described in ETSI EN 300 089 [5]. The CLIR supplementary service is described in ETSI EN 300 090 [6]. - Terminating Indication Presentation (TIP)/Terminating Indication Restriction (TIR). These simulation services support the presentation or restriction of callee's identity to the caller. They are the simulation of the ISDN/PSTN Connected Line Identification Presentation/Restriction (COLP/COLR) supplementary services. The COLP supplementary service is described in ETSI EN 300 094 [23]. The COLR supplementary service is described in ETSI EN 300 095 [24]. - Communication Waiting (CW). This simulation service provides the ability of the callee to be informed at the time a communication is coming in, and that no resources are available for that incoming communication. The callee has then the choice of accepting, rejecting or ignoring the incoming communication. The caller will be informed that his communication is waiting. The CW supplementary service is described in ETSI ETS 300 056 [11]. - Communication HOLD (HOLD). This simulation service supports the possibility of suspending the communication (on hold) while for example another communication with another user is to be done. The CW supplementary service is described in ETSI ETS 300 139 [12]. - Anonymous Communication Rejection (ACR). This simulation service allows a user to reject incoming communications when the caller is anonymous. The ACR supplementary service is described in ETSI EN 300 798 [21]. - Advice of Charge (AoC). This simulation service allows the caller to request the displaying of tariff information related to the communication. The service can operate at setup time (AoC-S), during a session (AoC-D), or at the end of it (AoC-E). The AoC-S supplementary service is described in ETSI ETS 300 178 [16]. The AoC-D supplementary service is described in ETSI ETS 300 179 [17]. The AoC-E supplementary service is described in ETSI ETS 300 180 [18]. - Communication Completion on Busy Subscriber (CCBS). This simulation service supports the ability of a caller 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 Jesske, et al. Expires - December 2005 [Page 4] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 same callee. The CCBS supplementary service is described in ETSI EN 300 357 [15]. - Communication Completion on no Reply (CCNR). This simulation service supports the ability of the caller to complete a requested communication to a callee without having to make a new communication attempt when the callee showed activity (a communication attempt was done). The CCNR supplementary service is described in ETSI EN 301 134 [25]. - Malicious Communication IDentification (MCID). This simulation service 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 [13]. - Explicit Communication Transfer (ECT). This simulation service allows the user having two separate sessions to connect the other two users together into a single session. The ECT supplementary service is described in ETSI EN 300 367 [20]. 2.2 Requirements to support the TISPAN Simulation Services. [REQ-GEN-1] For all simulation services interoperability with the PSTN/ISDN is needed. Solutions that support the following requirements must interwork with the corresponding PSTN/ISDN supplementary service. [REQ-ACR-1] The ACR simulation service requires the caller to be informed that the communication was rejected due to this service. This is needed to inform the upstream elements (UAC, e.g., a PSTN/ISDN gateway) about the reason for the rejection. [REQ-ACR-2] It must be possible that authorized callers are not subject to the ACR service, thus, allowing the callee to receive anonymous requests from authorized callers. This effectively requires a mechanism to override the ACR service depending on the identity and authorization of the caller. This is needed, e.g., for when a police officer or any other authority is anonymously calling to a user having the ACR simulation service enabled. [REQ-TIP-1] For supporting the TIP/TIR service when a communication is interworking with SIP-based Private Branch Exchanges (PBX) a Jesske, et al. Expires - December 2005 [Page 5] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 mechanism is required whereby the private extension of a PBX user is conveyed to the caller. This allows the caller to call back the PBX user directly. For example a user calling a PBX desk (e.g., +49 6151 83 0000 for Deutsche Telekom in Darmstadt) will be forwarded to an Extension (e.g., +49 6151 83 5940 for Roland Jesske). It is required that the caller gets the latter identity, which is allocated to the callee. [REQ-TIP-2] The identity mentioned in REQ-TIP-1 has to be backwards compatible with the SIP identity described within RFC 3325 [4]. [REQ-AoC-1] In order to support the AoC simulation service, a mechanism is needed whereby the caller can invoke the AoC simulation service in a given communication. This invocation is sent when initializing the communication. [REQ-AoC-2] As part of the AoC simulation service a mechanism is needed to asynchronously transport the charging information. This information will be displayed to the requesting user. Asynchronously transport means that the information shall be transported at any time during and after (e.g., within a certain period of time) the communication, but within the session context, when it is needed. [REQ-CCBS-1] In order to assure that end to end functionality of the CCBS service is possible, it is required that the UAC gets knowledge of the availability of the CCBS service at the UAS or the PSTN/ISDN terminal on a communication by communication basis. [REQ-CCBS-2] The entity providing the CCBS service needs to know the change of the status of a UAS (e.g., a transition from busy to idle) and it should have the ability to recognize if the UAS is able to provide such indication. [REQ-CCBS-3] The CCBS simulation service should be able to handle queues and arbitrate multiple simultaneous CCBS requests according to a locally defined policy (e.g., first in first out). [REQ-CCBS-4] It should be also possible for CCBS request initiators to suspend, resume and cancel their pending CCBS requests. Jesske, et al. Expires - December 2005 [Page 6] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 [REQ-CCNR-1] In order to assure that end to end functionality of the CCNR service is possible, it is required that the UAC gets knowledge of the availability of the CCNR service at the UAS or the PSTN/ISDN terminal on a communication by communication basis. [REQ-CCNR-2] The entity providing the CCNR service needs to know the change of the status of a UAS (e.g., a transition from idle to another state) and it should have the ability to recognize if the UAS is able to provide such indication. [REQ-CCNR-3] The CCNR simulation service should be able to handle queues and arbitrate multiple simultaneous CCNR requests according to a locally defined policy (e.g., first in first out). [REQ-CCNR-4] It should be also possible for CCNR request initiators to suspend, resume and cancel their pending CCNR requests. [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 provide this indication at the start, during or within a certain time after a session or request. Note: The requirement 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. [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 timeframe of 1-30 seconds even after the session has been closed. [REQ-CW-1] To implement the CW simulation service, ETSI envisages the usage of an application server that detects some busy conditions on behalf of the user. To support this scenario a mechanism is required to inform the callee that a communication is waiting. Jesske, et al. Expires - December 2005 [Page 7] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 [REQ-CW-2] It must be possible for CW to inform the caller that an application server is holding the communication until the callee is available. [REQ-CDIV-1] To support the CDIV simulation service it is required that the caller is informed if a communication diversion takes place. [REQ-CDIV-2] To support the CDIV simulation service a mechanism that shows or restrict the indication of the diverting user is required. [REQ-CDIV-3] To support the CDIV simulation service it is required that the reason of the redirection is delivered to the caller and callee. [REQ-CDIV-4] For interoperability reasons and service compatibility with the CDIV simulation service, it is required that the history of the communication is sent in forward and backward directions to the caller and callee, respectively. [REQ-CAT-1] For service applicability to special groups and interoperability with the PSTN/ISDN an indication of the originating party category is needed. This is needed due to the fact that some services apply a special behavior to special user groups (e.g., like Pay-Phones). [REQ-CAT-2] The originating party category referred to in REQ-CAT-1 must be inserted by a trusted entity. 4. Security Considerations The requirements in this document are intended to result in a mechanism with general applicability for ETSI NGN and are generally not applicable to the public Internet. Use of these mechanisms in any other context has serious security shortcomings, namely there is absolutely no guarantee that the information has not been modified, or was even correct in the first place. 5. IANA Considerations This document does not have any implications for IANA. Jesske, et al. Expires - December 2005 [Page 8] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 References [1] 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. [2] Barnes, M. "An Extension to the Session Initiation Protocol for Request History Information", draft-ietf-sip-history-info-06.txt, January 17, 2005. [3] Elwell, J.; "SIP Reason header extension for indicating redirection reasons", draft-elwell-sipping-redirection-reason- 02.txt, June 2005. [4] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [5] ETSI EN 300 089 (V3.1.1): "Integrated Services Digital Network (ISDN); Calling Line Identification Presentation (CLIP) supplementary service; Service description". [6] ETSI EN 300 090 (V1.2.1): "Integrated Services Digital Network (ISDN); Calling Line Identification Restriction (CLIR) supplementary service; Service description". [7] ETSI EN 300 200 (Edition 1): "Integrated Services Digital Network (ISDN); Call Forwarding Unconditional (CFU) supplementary service; Service description". [8] ETSI EN 300 199 (V1.2.1): "Integrated Services Digital Network (ISDN); Call Forwarding Busy (CFB) supplementary service; Service description". [9] ETIS EN 300 201 (V1.2.1): "Integrated Services Digital Network (ISDN); Call Forwarding No Reply (CFNR) supplementary service; Service description". [10] ETSI ETS 300 202 (Edition 1): "Integrated Services Digital Network (ISDN); Call Deflection (CD) supplementary service; Service description". [11] ETSI ETS 300 056 (Edition 1): "Integrated Services Digital Network (ISDN); Call Waiting (CW) supplementary service; Service description". Jesske, et al. Expires - December 2005 [Page 9] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 [12] ETSI ETS 300 139 (Edition 1): "Integrated Services Digital Network (ISDN); Call Hold (HOLD) supplementary service; Service description". [13] ETSI ETS 300 128 (Edition 1): "Integrated Services Digital Network (ISDN); Malicious Call Identification (MCID) supplementary service; Service description". [14] ETSI ETS 300 183 (Edition 1): "Integrated Services Digital Network (ISDN); Conference call, add-on (CONF) supplementary service; Service description". [15] ETSI EN 300 357 (V1.2.1): "Integrated Services Digital Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) supplementary service; Service description". [16] ETSI ETS 300 178 (Edition 1): "Integrated Services Digital Network (ISDN); Advice of Charge: charging information at call set-up time (AOC-S) supplementary service; Service description". [17] ETSI ETS 300 179 (Edition 1): "Integrated Services Digital Network (ISDN); Advice of Charge: charging information during the call (AOC-D) supplementary service; Service description". [18] ETSI ETS 300 180 (Edition 1): "Integrated Services Digital Network (ISDN); Advice of Charge: charging information at the end of the call (AOC-E) supplementary service; Service description". [19] ETSI EN 300 650 (V1.2.1): "Integrated Services Digital Network (ISDN); Message Waiting Indication (MWI) supplementary service; Service description". [20] ETSI EN 300 367 (V1.2.1): "Integrated Services Digital Network (ISDN); Explicit Call Transfer (ECT) supplementary service; Service description". [21] ETSI EN 301 798 (V1.1.1): "Services and Protocols for Advanced Networks (SPAN); Anonymous Call Rejection (ACR) Supplementary Service; Service description". [22] ETSI ETS 300 520: "European digital cellular telecommunications system (Phase 2); Call Barring (CB) supplementary services; Stage 1 (GSM 02.88)". [23] ETSI EN 300 094: "Integrated Services Digital Network (ISDN); Connected Line Identification Presentation (COLP) supplementary service; Service description". Jesske, et al. Expires - December 2005 [Page 10] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 [24] ETSI ETS 300 095: "Integrated Services Digital Network (ISDN); Connected Line Identification Restriction (COLR) supplementary service; Service description". [25] ETSI EN 301 134: "Integrated Services Digital Network (ISDN); Completion of Calls on No Reply (CCNR) supplementary service; Service description". [26] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP". 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 Acknowledgments The authors would like to thank Anna Martinez people of ETSI TISPAN WG3 for their comments. Author's Addresses Roland Jesske Deutsche Telekom Am Kavalleriesand 3 64307 Darmstadt Germany Phone: +496151835940 Email: r.jesske@t-com.net Denis Alexeitsev Deutsche Telekom Am Kavalleriesand 3 64307 Darmstadt Germany Jesske, et al. Expires - December 2005 [Page 11] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 Phone: +496151832130 Email: d.alexeitsev@t-com.net Miguel A. Garcia-Martin Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland EMail: miguel.an.garcia@nokia.com Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authorsretain all their rights. 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. Intellectual Property 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 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 Jesske, et al. Expires - December 2005 [Page 12] Internet-Draft Input reqs. to SIP for ETSI NGN June 2005 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Jesske, et al. Expires - December 2005 [Page 13]