Requirements on SIP for TISPAN simulation services May 2005 Sipping Internet Draft Jesske Roland Document: Document: draft-jesske-sipping- Deutsche Telekom tispan-requirements-00.txt Denis Alexeitsev Deutsche Telekom Miguel Garcia Nokia Expires: 24.November 2005 24.May 2005 Requirements for the Extensions to the Session Initiation Protocol (SIP) for the TISPAN simulation services 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 Expires - November 2005 [Page 1]
Requirements on SIP for TISPAN simulation services May 2005 This document describes a set of requirements and proposed extensions for endorsing the Session Initiation Protocol. used by the TISPAN NGN Project. These endorsements are needed to be included into the 3GPP IMS specification on SIP (TS24.229 [32]) for supporting the simulation services. 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. Proposed SIP extensions 3.1 ACR[REQ-1] and [REQ-2] 3.2 TIP/TIR [REQ-3] 3.3 AOC [REQ-4] 3.4 CCBS [REQ-5] 3.5 MCID [REQ-6] 3.6 CW [REQ-7 3.7 CDIV [REQ-8] 4. Security Considerations 5. IANA Considerations 1. Overview ETSI TISPAN is defining the release 1 of the TISPAN NGN. Generally the TISPAN NGN bases on the 3GPP IMS Release 7 provided by 3GPP in 2005. The TISPAN NGN Project has selected SIP profiled by 3GPP for their IMS as the protocol used to establish and tear down multimedia sessions in the context of its NGN. One requirement is that the 3GPP core SIP defined in TS24.229 [32] shall be used for the TISPAN IMS The goal for TISPAN is that only one IMS core specification is defined for wire-line and wire-less multimedia applications. While defining multimedia applications it is also needed to support existing ISDN/PSTN supplementary services based on IMS. These services used within the TISPAN IMS are called simulation services, because they can not fulfill 100% of the capabilities of the ISDN/PSTN equivalent. The 3GPP TS24.229 [32] is used to simulate the regarding services but to fulfill the requirements defined within TISPAN NGN Release 1 some further SIP elements are needed. This document defines some Requirements on the simulation services with regard to extensions needed in SIP and proposes such SIP elements. This document does not define the SIP elements in detail. Jesske Expires - November 2005 [Page 2]
Requirements on SIP for TISPAN simulation services May 2005 2. Requirements for supporting simulation services within SIP 2.1 Simulation Services supported by TISPAN in Release1 The following services are supported by TISPAN Release 1 -Communication DIVersion (CDIV). This simulation service allows the diversion of communications and the regarding service interworking with the PSTN/ISDN network. -CONFerence (CONF). This simulation service provides the possibility to hold conferences with 3 or more users. - Message Waiting Indication (MWI). This simulation service supports an indication sent to the user to provide him with information about the status of a voice/video/multimedia mail box. -Originating Indication Presentation (OIP)/Originating Indication Restriction (OIR). These simulation services support the presentation or restriction of an identity to the terminating user. They are the simulation of the ISDN/PSTN CLIP/CLIR services. -Terminating Indication Presentation (TIP)/Terminating Indication Restriction (TIR). These simulation services support the presentation or restriction of a identity of the terminating user to the originating user. They are the simulation of the ISDN/PSTN COLP/COLR services. -Communication Waiting (CW). This simulation service provides the ability to the terminating user to be informed at the time a communication is coming in, and that no resources are available for that incoming communication. The terminating user has then the choice of accepting, rejecting or ignoring the incoming communication. The originating user will be informed that his communication is waiting. -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. -Anonymous Communication Rejection (ACR). This simulation service supports that communications with anonymous originating identity can be rejected. -Advice of Charge (AoC). This simulation service supports the displaying of tariff information to the originating user. Jesske Expires - November 2005 [Page 3]
Requirements on SIP for TISPAN simulation services May 2005 -Communication Completion on Busy Subscriber (CCBS). This simulation service supports the ability to complete a requested communication to a user without having to make a new communication attempt when the destination B becomes not busy anymore. -Communication Completion on non Reply (CCNR). This simulation service supports the ability to complete a requested communication to a user without having to make a new communication attempt when the destination B showed activity (a communication attempt was done). -Malicious Communication IDentification (MCID). This simulation service enables an incoming communication to be identified and registered. -Concerning the simulation services CONF, MWI, OIP, OIR and HOLD no further SIP elements are needed. With regard to the other above mentioned services extensions of SIP are needed. 2.2 Requirements to support the TISPAN Simulation Services. [REQ-1] For supporting the ACR simulation service it is needed inform the originating party that the communication was rejected due to this service. [REQ-2] It shall be possible for authorities to override an ACR service offered to a terminating user. [REQ-3] For supporting the seamless interworking of PBX with SIP based PBX terminals it is needed to identify the private extension of a PBX users. This identity is required for the TIP service. [REQ-4] For the AoC simulation service a possibility is needed that the AoC simulation service is requested by the originating user. This request is sent when initializing the communication. [REQ-5] As part of the AoC simulation service a mechanism is needed to asynchronously transport the charging information Jesske Expires - November 2005 [Page 4]
Requirements on SIP for TISPAN simulation services May 2005 [REQ-6] The CCBS simulation service requires specific service logic on both the originating and terminating side of the network. This service logic is managed by Application Servers. In order to assure that end to end functionality of the service is possible, an indication that CCBS is possible sent by the terminating side to the originating side is required. Also additional status information CCBS user busy/free and the Service status CCBS Suspend, Recall and Resume for the service is required. [REQ-7] For the MCID simulation service it is needed to request information if the address of the originating user is missing. It shall be possible to request MCID on a per Call basis. For interoperability reasons a Request-Response mechanism. [REQ-8] For CW simulation service it is required that terminating user shall be informed that a Communication is aiting. It shall be possible to inform the originating user, that the Communication is a waiting communication. [REQ-9] For interoperability reasons and service compatibility it is required that for CDIV that the call history (forwarding users, reasons and number of redirections)shall be send in forward and backward direction to the originating and terminating side. Additionally it is required that a the originating user may be informed if a communication diversion appears and shows or restrict the indication of the diverting user. [REQ-10] For CCNR simulation service it is needed that the terminating side can indicate the support of CCNR. Also additional status information regarding the CCNR user no- reply/busy/free and the Service status CCBS Suspend, Recall and Resume is also needed. This is also needed for interoperability reasons. [REQ-11] For TIP the terminating side needes to get the information "TIP requested" that the originating side is requesting the TIP service. [REQ-12] Jesske Expires - November 2005 [Page 5]
Requirements on SIP for TISPAN simulation services May 2005 For all simulation services interoperability with the PSTN/ISDN is needed. 3. Proposed SIP extensions The following section could be seen as collected thoughts what possibilities are given to fulfill the above mentioned requierements. This section show ideas and the authoe is happy for further proposals. 3.1 ACR[REQ-1] and [REQ-2] For this simulation service a privacy indication is needed to indicate that the network restricts the P-Asserted-ID and that the Reason header can be included in Responses. 3.2 TIP/TIR [REQ-3] For this simulation service an additional Identity header is needed that is send from the connected SIP user like the From header from the originating user. 3.3 AOC [REQ-4] For the AOC simulation a P-Header or a XML MIME could be used to request a AOC information (tariff information how much a call will be billed). A MIME has to be defined for providing the Charging information to the user. 3.4 CCBS [REQ-5] With regard to discussions take place in ETSI TISPAN the following approach to propose a CCBS Event Package was discussed: Proposed CCBS Event Package The CCBS event package aims at managing subscriptions to CCBS service, and especially targets queues management, according to the previously described mechanism. Specifically, the CCBS event package carries the following information that concurs to build a subscription target: caller : the subscriber to the CCBS service. When the subscription is handled by the caller AS on behalf of the actual caller, then this information is added to the Event: header as a æcallerÆ Jesske Expires - November 2005 [Page 6]
Requirements on SIP for TISPAN simulation services May 2005 parameter; while when the caller is directly handling the subscription, this parameter can be omitted. callee: the user which the caller asked the CCBS service for. It is the target user already contained in the To: header queue: this information is needed for the CCBS Event Server to know whether to put this new subscription in the queue or not. Such information is an Event Header parameter.Possible values are "true","false", "suspend" (to suspend its place in queue), "resume" to resume its place in queue. Hence, the CCBS Event: header will look like, for example To start CCBS subscription: Event: ccbs;queue=true;caller=sip:+390112285111@example.com To suspend CCBS service (for instance, if caller is busy ): Event: ccbs;queue=suspend;caller= sip:+390112285111@example.com To resume CCBS service: Event: ccbs;queue=resume;caller= sip:+390112285111@example.com Since the main difference between the "ccbs" event package and the "dialog" event package lies in the way subscriptions and notifications are handled, there is no need to change the contents of the XML documents exchanged therein, so CCBS Event Package notifications should contain a Dialog Information document, according to the same rules described in "draft-ietf-sipping-dialog- package-05.txt", for example: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:alice@example.com"> <dialog id="as7d900as8"> <state>confirmed</state> </dialog> </dialog-info> This allows to "tunnel" Dialog Information documents contained in dialog package notifications originated by endpoints into ccbs package notifications sent by application server. From discussion point of view there are thoughts that the inclusion of the allow-event header in all responses is useful for the CCBS case to indicate a CCBS possible. This is at the moment not possible as mentioned in RFC 3265. Jesske Expires - November 2005 [Page 7]
Requirements on SIP for TISPAN simulation services May 2005 3.5 MCID [REQ-6] For MCID an event package shall be defined to request MCID and request missing numbers. Several solutions are possible like a new event package (as shown below) or extending existing event packages or using a XML Mime Body. Example new Event Package: package name: mcid-request-info Body Format Syntax mcid-request = mcid-request-line CRLF mcid-request-line = "MCID-Request" HCOLON mcid-request; mcid- holding-request mcid-request = "MCID requested" / "MCID not requested" mcid-holding-status= "holding not provided"/ "holding provided" originating-URI = TEL-URI / SIP-URI / SIPS-URI / absolute URI package name: mcid-response-info Body Format Syntax mcid-information = mcid-status-line CRLF [originating-URI CRLF] mcid-status-line = "MCID-Info" HCOLON mcid-info-status; mcid- holding-status mcid-info-status = "MCID included"/ "MCID not included" mcid-holding-status= "holding not provided"/ "holding provided" originating-URI = TEL-URI / SIP-URI / SIPS-URI / absoluteURI 3.6 CW [REQ-7] For supporting this requirement a P-header or an MIME with XML information is needed. 3.7 CDIV [REQ-8] For supporting CDIV the approval of the drafts draft-ietf-sip- history-info-06 [1] and draft-elwell-sipping-redirection-reason-01 [2] is needed. 3.8 CCNR [REQ-9] For CCNR an event package shall be defined to indicate the CCNR status information, call status and possibility of CCNR. Jesske Expires - November 2005 [Page 8]
Requirements on SIP for TISPAN simulation services May 2005 The same solution as proposed in section 3.4 could be done. 3.9 TIP [REQ-10] For indicating that user A wants to have TIP a P-header or an XML- MIME is needed. 4. Security Considerations The requirements in this document are intended to result in a mechanism with general applicability for the NGN TISPAN and NOT on the Internet. Use of this mechanism in any other context has serious security shortcomings, namely that 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. References [1]IETF An Extension to the Session Initiation Protocol for Request History Information; draft-ietf-sip-history-info-06.txt; Expires: April 21, 2005 [2]Elwell; "draft-elwell-sipping-redirection-reason-01.txt"; SIP Reason header extension for indicating redirection reasons [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 ETS 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]ETSI EN 300 201 (V1.2.1): "Integrated Services Digital Network (ISDN); Call Forwarding No Reply (CFNR) supplementary service; Service description". Jesske Expires - November 2005 [Page 9]
Requirements on SIP for TISPAN simulation services May 2005 [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". [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 186 (Edition 1): "Integrated Services Digital Network (ISDN); Three-Party (3PTY) supplementary service; Service description". [15]ETSI ETS 300 183 (Edition 1): "Integrated Services Digital Network (ISDN); Conference call, add-on (CONF) supplementary service; Service description". [16]ETSI ETS 300 164 (Edition 1): "Integrated Services Digital Network (ISDN); Meet-Me Conference (MMC) supplementary service; Service description". [17]ETSI EN 300 357 (V1.2.1): "Integrated Services Digital Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) supplementary service; Service description". [18]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". [19]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". [20]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". [21]ETSI ETS 300 136 (Edition 1): "Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service; Service description". [22]ETSI EN 300 650 (V1.2.1): "Integrated Services Digital Network (ISDN); Message Waiting Indication (MWI) supplementary service; Service description". [23]ETSI EN 300 062: "Integrated Services Digital Network (ISDN);Direct Dialling In (DDI) supplementary service; Service Description". [24]ETSI EN 300 367 (V1.2.1): "Integrated Services Digital Network (ISDN);Explicit Call Transfer (ECT) supplementary service; Service description". [25]ETSI EN 301 798 (V1.1.1): "Services and Protocols for Advanced Networks (SPAN);Anonymous Call Rejection (ACR) Supplementary Service; Service description". [26]ETSI DTR/AT-030031: "Simultaneous Voice and Text Announcements". Jesske Expires - November 2005 [Page 10]
Requirements on SIP for TISPAN simulation services May 2005 [27]ETS 300 648 (1997): "Public Switched Telephone Network (PSTN); Calling Line Identification Presentation (CLIP) supplementary service; Service description". [28]EN 300 659-1 (V1.2): "Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) services; Part 1: On-hook data transmission". [29]EN 300 659-2 (V1.2): "Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) services; Part 2: Off-hook data transmission". [30]EN 300 659-3 (V1.2): "Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) services; Part 3: Data link message and parameter codings". [31]ETS 300 649 (1997): "Public Switched Telephone Network (PSTN); Calling Line Identification Restriction (CLIR) supplementary service; Service description". [32] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP". Contributors Keith Drage Lucent Technologies GSM OPTIMUS HOUSE SN5 6PP SWINDON United Kingdom Phone: +44 1793 897312 Email: drage@lucent.com Acknowledgments Anna Martinez with comments and editing, the people of TISPAN WG3 bringing in the comments. Author's Addresses Roland Jesske Deutsche Telekom Am Kavalleriesand 3 64307 Darmstadt Germany Phone: +496151835940 Email: r.jesske@t-com.net Jesske Expires - November 2005 [Page 11]
Requirements on SIP for TISPAN simulation services May 2005 Denis Alexeitsev Deutsche Telekom Am Kavalleriesand 3 64307 Darmstadt Germany Phone: +496151832130 Email: d.alexeitsev@t-com.net Miguel Garcia NOKIA Corporation Itaemerenkatu 11-13 00180 Helsinki Finland Phone: +358504804586 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 authors retain 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 Jesske Expires - November 2005 [Page 12]
Requirements on SIP for TISPAN simulation services May 2005 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Jesske Expires - November 2005 [Page 13]