Analysis of TISPAN req. to SIP June 2005 Sipping Working Group Internet Draft Roland Jesske Expires: December 28, 2005 Denis Alexeitsev Deutsche Telekom Miguel Garcia-Martin Nokia June 2005 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 services draft-jesske-sipping-tispan-analysis-00.txt 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 - December 2005 [Page 1]
Analysis of TISPAN req. to SIP June 2005 This document analyzes the requirements generated by ETSI to support NGN simulation services implemented with SIP. The document analyzes standard solutions that can meet the requirements. Where a standard solution is not available, the document proposes one or more solutions. The aim is to provoke discussion within the Internet community and get early feedback. Table of Contents 1. Overview 2. Analysis of the TISPAN Simulation Services requirements 2.1 General Requirements[REQ-GEN-1] 2.2 Anonymous Communication Rejection (ACR)[ACR-REQ-1] and [ACR- REQ-2] 2.3 Terminating Indication Presentation (TIP)/Terminating Indication Restriction (TIR). [REQ-TIP-1] and [REQ-TIP-2] 2.4 Advice of Charge (AOC) [REQ-AoC-1] and [REQ-AoC-2] 2.5 Communication Completion on Busy Subscriber (CCBS) [REQ-CCBS- 1]- [REQ-CCBS4] 2.6 Communication Completion on no Reply (CCNR) [REQ-CCNR-1]- [REQ-CCBNR4] 2.7 Malicious Communication IDentification (MCID) [REQ-MCID-1] and [REQ-MCID-2] 2.8 Communication Waiting (CW) [REQ-7] [REQ-CW-1] and [REQ-CW-2] 2.9 Communication Diversion (CDIV) [REQ-CDIV-1] and [REQ-CDIV-4] 2.10 [REQ-CAT-1] and [REQ-CAT-2] 3. Security Considerations 4. IANA Considerations 1. Overview This document is a companion document of the Internet Draft "Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute (ETSI) Next Generation Network (NGN) simulation services" [3]. We analyze each requirement trying to find an available standard solution that meets the requirement. When such solution is not known, we analyze different alternatives that will meet the requirement. The document's intention is to provoke discussion in the Internet community in order to find suitable mechanisms that guarantee the implementation of the requirements within the ETSI NGN timeframe. 2 Analysis of the TISPAN Simulation Services reqirements The following section could be seen as collected thoughts what possibilities are given to fulfill the above mentioned requirements. Jesske Expires - December 2005 [Page 2]
Analysis of TISPAN req. to SIP June 2005 Some of these ideas are still under discussion in ETSI and thus, do not even represent a firm proposal, but just a collection of alternatives that require further exploration. 2.1 General Requirements[REQ-GEN-1] This requirement, since it is generally applicable to all the requirements, does not require a particular behavior. However, solutions that meet other requirements should also meet the constraint of seamlessly interwork with a similar service in the PSTN. 2.2 Anonymus Communication Rejection (ACR)[ACR-REQ-1] and [ACR-REQ-2] Requirement [ACR-REQ-1] requires informing the caller that her call has been rejected due to anonymity. We thought that an application server that implements the ACR service can either send an instant message to the caller (if supported) or divert the call to an announcement player that plays the appropriate audio message, however, this will be hard to be processed by an automata or a PSTN gateway. For example, in a PSTN originated call the PSTN should indicated an appropriate Release Cause (cause 24) due to interaction with the ACR service. Thus, any solution based on these two proposals would make difficult to meet REQ-GEN-1. The Release Causes are described within ETSI EN300 485 [13] A more sophisticated solution proposes to add a Reason header with an appropriate Release Cause 24 as described in ETSI EN300 485 [13] to a 603 Decline response. This will allow interworking with the PSTN. Yet another alternative is to create a new response code, but we believe it is not really necessary to go into that solution. As the current Reason header extension header is limited to requests, some extension is needed to state that the Reason header is valid for either the 603 (Decline) response, or some other status code as determined by this discussion. Requirement [ACR-REQ-2] reads about allowing certain authorized callers to bypass the ACR service of a given callee. For that we envision that an application or SIP proxy server that has access to the caller's user profile is able to add indicate in SIP that the user is authorized to bypass a potential callee's ACR service. We propose to add a new P-ACR header field that proxies or application servers can insert. This header would be subject to the same security concerns and trusted domain considerations as the P-Asserted-Identity header field [8]. 2.2.1 The P-ACR header field Jesske Expires - December 2005 [Page 3]
Analysis of TISPAN req. to SIP June 2005 In support for the ACR service [REQ-ACR-2], there is a need to indicate that in some circumstances the ACR service provided towards the terminating UE should not apply. One of these cases is when the originating user has requested privacy of his asserted identity, but because the user belongs to an authorized group (e.g., policeman), all SIP request should go through to the called UA, no matter whether the called user has activated ACR or not. In another scenario, a PSTN originated call does not deliver the asserted identity of the called party (e.g., if the call is originated in an analogue switch). In this case the PSTN gateway is not able to provide an asserted identity of the calling party. If the call is routed to a user who has the ACR service activated, the call shouldn't be rejected due to ACR. To tackle this problem we suggest creating a new P-ACR header, which can be populated by a trusted entity (e.g., an Application Server or Media Gateway Control Function). The contents of the header will indicate that willingness of bypassing a potential ACR service in the called party side, and the motivation for it. It is the same restrictions for the P-ACR as in RFC3325 for the P- Asserted-ID described must apply. Proposed syntax for this header: P-ACR = "P-ACR" HCOLON p-acr-spec *(COMMA p-acr-spec) p-acr-spec = "bypass" *(SEMI due-to-param) due-to-param = "due-to" EQUAL reason-token reason-token = "interworking" / "is-authorized" / "network"/ token Example: P-ACR = bypass;due-to=is-authorized Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-ACR adr - - - o - - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o - o - - - MESSAGE PUBLISH --- --- Jesske Expires - December 2005 [Page 4]
Analysis of TISPAN req. to SIP June 2005 o o The draft-ietf-sip-identity was not considered due to the fact that this draft recommends practices and conventions for identifying end users in SIP messages, and proposes a way to distribute cryptographically-secure authenticated identities. This is only for Requests specified. The P-ACR is especially used for indicating bypass mechanisms for ACR and the indication how P-Asserted-Identity was set. 2.3 Terminating Indication Presentation (TIP)/Terminating Indication Restriction (TIR). [REQ-TIP-1] and [REQ-TIP-2] The implementation of these requirements need some header to convey the callee's URI, which might be different from the To header field or Request-URI, due to, e.g., redirections, call transfer, usage of PBX extensions, etc. We believe that the P-Asserted-Identity [8] header field inserted in responses meets these requirements. An additional Identity header is needed that is send from the connected SIP user like the From header from the originating user. 2.3.1 The P-Additional-Identity Header The P-Additional-Identity header field is used among SIP entities (typically intermediaries) to carry the identity of the user sending a SIP response as it was not verified by authentication. This additional header is needed 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. PAdditionalID = "P-Additional-Identity" HCOLON PAdditionalID-value *(COMMA PAdditionalID-value) PAdditionalID-value = name-addr / addr-spec A P-Additional-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Additional- Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. It is worth noting that proxies can (and will) add and remove this header field. This document adds the following entry to Table 2 of [1]: Jesske Expires - December 2005 [Page 5]
Analysis of TISPAN req. to SIP June 2005 Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Additional-Identity r adr - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - - MESSAGE PUBLISH --- --- o o Note: Here is also an ongoing discussion if a new header is needed or if a existing header could be used to identify the ôrealö connected user. The Contact or Reply-to header were identified as not usable. 2.4 Advice of Charge (AOC) [REQ-AoC-1] and [REQ-AoC-2] The Advice of Charge simulation service requires a caller to give an indication to the network that he wants to receive advice of charge information for a given communication (e.g., session, subscription, instant message, etc.). A mechanism to invoke the service based on a SIP-event base subscription and notification has been analyzed. However, this solution will introduce a synchronization problem, due to indicating the request for the service out-of-band. The basic problem is how to identify the SIP request for which the advice should be provided prior to sending the request, when such request has not even been created. We propose, though, that the SIP request for which the Advice of Service information is requested is complemented with a new header that invokes the service. Once the service is properly invoked, there are a number of available mechanisms to deliver the information to the user, including but not restricted to, audio visual announcements, instant message, etc. A detailed proposal for a new P-AoC header field is described in draft-garcia-sipping-etsi-ngn-p-headers-00 [7]. 2.5 Communication Completion on Busy Subscriber (CCBS) [REQ-CCBS-1]to [REQ-CCBS4] Discussion in ETSI TISPAN are leaning towards a segmented implementation of the CCBS service, where there is an application server which is serving the caller, and another application server which serving the callee. The main role of application servers is to Jesske Expires - December 2005 [Page 6]
Analysis of TISPAN req. to SIP June 2005 provide queue management. This is based on the modelling in the ISDN stage 2 and operates in this manner to allow interworking with the related ISDN service through a SIP/PSTN gateway. We model the actual implementation of the CCBS service according to the following: - When the AS of the callee detects that the callee is busy and that the callee supports the dialog event package [9], it forwards the busy response to the AS of the caller with an indication that the CCBS service is possible (i.e. queuing capabilities, and dialog event are supported, REQ-CCBS-1 and REQ-CCBS-2). - Upon receipt of this indication, the caller is offered to activate the CCBS service (e.g. the AS of the caller plays an announcement with DTMF collection, etc). - If the caller accepts the service activation, the AS of the caller subscribes to the CCBS service (e.g. subscribes to the CCBS queue of the callee to the dialog status of this callee, REQ-CCBS-2). - Upon receipt of the CCBS subscription request, the AS of the caller confirms that CCBS monitoring has started, - the AS of the callee then subscribes to the dialog event [9] of the callee, - Upon receipt of a notification that the callee is free, the AS of the callee, notifies the AS of the caller. - The AS of the caller sets-up the CCBS call using either a 3rd party control mechanism of a Refer with an indication that this is a CCBS call (REQ-CCBS-4). In order to provide compatibility with terminals that implement the dialog event package, subscriptions that may originate or terminate in a terminal will be implemented according to the dialog event package [9]. Subscriptions not involving terminals (i.e., such as the subscriptions from one application server to another one) need to be complemented with additional information (REQ-CCBS-3). It is proposed to define a new "CCBS" event package for backwards compatibility purposes. 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. Consequently, the CCBS event package notifications should contain a dialog information document as described in [9]. This allows to "tunnel" dialog information documents contained in dialog package notifications originated by endpoints into CCBS package notifications sent by application servers. The additional information to the dialog event package for providing queues management and concurs to build a subscription target is as follows: Jesske Expires - December 2005 [Page 7]
Analysis of TISPAN req. to SIP June 2005 queue: this information is needed for the application server to know whether to insert this new subscription in the queue or not. We suggest to add a new "queue" parameter to the "dialog" Event header field value. 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 becomes busy): Event: ccbs;queue=suspend;caller= sip:+390112285111@example.com To resume CCBS service: Event: ccbs;queue=resume;caller= sip:+390112285111@example.com A value of "ccbs" or "dialog" in the 486 Busy Here response will indicate the URI where the subscription could be made. This URI could, e.g., a GRUU. Additionally, the presence in a 486 Busy Here response of an Allow-Events header field with the value "CCBS" would help to determine the support for the service. However, RFC 3265 [11] seems to indicate that the Allow-Evens header is only meaningful in requests and 200 or 489 responses. Implementation of REQ-CCBS-3 requires that the second time that the caller sends the INVITE request to the callee, as a result of an indication that the callee is not busy any longer, the INVITE request is marked with an flag indicating that the INVITE is the result of CCBS service. It is proposed that a Call-Info header field is extended with a new value of the "purpose" parameter. Hence, at the time of the CCBS call, the AS can insert the Call-Info: header into the INVITE message directed to user B when triggering the 3rd party call, or instruct the terminal to do so in the Refer-To: header inserting the æCall-Info:Æ header as a URL header (after the æ?Æ character). Note: With regard to CCBS the discussion is ongoing what kind of solution could be taken. If a new Event Package is needed or if the extension of the existing dialog event package is good enough for CCBS. 2.6 Communication Completion on no Reply (CCNR) [REQ-CCNR-1] to [REQ-CCNR-4] Jesske Expires - December 2005 [Page 8]
Analysis of TISPAN req. to SIP June 2005 The implementation of the CCNR service does not require any extra implementation beyond the solutions proposed for implementing the CCBS service. 2.7 Malicious Communication IDentification (MCID) [REQ-MCID-1] and [REQ- MCID-2] The implementation of the MCID service suggests to split the solution into the mechanism whereby a callee can indicate to an application server that he suspects a call is malicious [REQ-MCID-1], from the mechanism whereby an application server acquires the caller's identity if not present in the SIP request [REQ-MCID-2]. A possible solution for implementing REQ-MCID-1 consists of the user subscribing to a new event package. The application server will act as a notifier. Since the user does not need to receive any information, other than a message indicating whether the service has been successfully activated or not, we propose to do a fetch operation (as per RFC 3265 [11]) with the new event package. We propose, therefore, a new event "mcid" event package. The value is accompanied by package parameters indicating the call to be identified (e.g., by its from-tag, call-id, and to-tag (if available)). The event package itself should contain a simple indication of the acceptance or not of the service. To implement REQ-MCID-2 we envision that all SIP requests addressed to the user will be routed through the MCID application server. The application server will analyze all SIP requests. Two possbilities might take place: the SIP request contains trusted identity information (e.g., a trusted P-Asserted-Identity [8] header field, or an Identity [12] header field); or such identity is not present in the request, in which case, it might be still available upon request. This is the sometimes the case when a call is originated in the PSTN, because sometimes the calling party number is only available upon request. To meet this requirement and be able to request the identity of the originator, we propose a SIP event package for requesting identity information. In most cases this will not be used, but in cases of interworking with the PSTN, the PSTN gateway will receive a SUBSCRIBE request for the new event package, will do the PSTN operations to retrive the calling party number, and will provide the appropriate notification to the subscriber (the application server). 2.8 Communication Waiting (CW) [REQ-CW-1] and [REQ-CW-2] Jesske Expires - December 2005 [Page 9]
Analysis of TISPAN req. to SIP June 2005 A solution that meets REQ-CW-1 suggests to use send an instant message indicating the ser the relevant parameters of the waiting call. To implement REQ-CW-2 we suggest to use a 182 Queue response until the callee accepts the incoming session. 2.9 Communication Diversion (CDIV) [REQ-CDIV-1] to [REQ-CDIV-4] For supporting CDIV service we envision the usage of draft-ietf-sip- history-info-06 [6] and draft-elwell-sipping-redirection-reason-01 [2].We therefore request the adoption of draft-elwell-sipping- redirection-reason as a working group charter item. 2.10 [REQ-CAT-1] and [REQ-CAT-2] To support REQ-CAT-1 and REQ-CAT-2 we propose that, a PSTN Gateway (UA) or SIP proxy that has knowledge of the user's category inserts a P-Caller-Category header field categorizing the caller. Sometimes the category of the caller is determined to be "operator". In such case, the presence of the Accept-Language header field can be combined to determine the language of the operator. 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. The proposed syntax for this header: P-Caller-Category = "P-Caller-Category " HCOLON p-cat-spec *(COMMA p-cat-spec) p-cat-spec = "operator" / "subscriber" / "data" / "test" / "payphone" / "mobile" / token Example: P-Caller-Category = "payphone" An other possibility is to use the solution described within draft- mahy-iptel-cpc-00 [14]. This solution was dicussed in the past within IPTEL but not follwed on Question is which would be the appropriate way to follow. 4. Security Considerations Jesske Expires - December 2005 [Page 10]
Analysis of TISPAN req. to SIP June 2005 The requirements in this document are intended to result in a mechanism with applicability for ETSI NGN and NOT for the general 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 discusses implementation possibilities and does not pretend to be a firm proposal for the implementation of any of the solutions. Therefore, this document does not provide any action to IANA. 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] Elwell, J., "SIP Reason header extension for indicating redirection reasons", draft-elwell-sipping-redirection-reason- 02.txt (work in progress), June 2005. [3] Jesske, R., Alexeitsev, D., Garcia-Martin, M. "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.txt (work in progress), June 2005. [4] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP". [5] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [6] Barnes, M., "An Extension to the Session Initiation Protocol for Request History Information", draft-ietf-sip-history-info-06.txt (work in progress), January 2005. [7] Garcia-Martin, M. "Private Header (P-Header) Extensions to the Session Initiation Protocol(SIP) in support of the European Telecommunications Standards Institute (ETSI) Next Generation Networks (NGN)", draft-garcia-sipping-etsi-ngn-p-headers-00.txt (work in progress), June 2005. Jesske Expires - December 2005 [Page 11]
Analysis of TISPAN req. to SIP June 2005 [8] Jennings C., Peterson J., and Watson M. "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [9] Rosenberg, J., Schulzrinne, H., Mahy, R"An INVITE Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", draft-ietf-sipping-dialog-package-06.txt (work in progress), April 2005. [10] Rosenberg, J. "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft- ietf-sip-gruu-03 (work in progress), February 2005. [11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [12] Peterson, J., Jennings, C. "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-05.txt (work in progress), March 2005. [13] ETSI EN 300 485: "Integrated Services Digital Network (ISDN); Definition and usage of cause and location in Digital Subscriber Signalling System No. one (DSS1) and Signalling System No. 7 (SS7) ISDN User Part (ISUP) [ITU-T Recommendation Q.850 (1998) with addendum modified]". [14] R. Mahy "The Calling Party's Category tel URI Parameter" draft- mahy-iptel-cpc-00, June 2003 Contributors Keith Drage Lucent Technologies 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 Jesske Expires - December 2005 [Page 12]
Analysis of TISPAN req. to SIP June 2005 The authors would like to thank the participants of the ETSI TISPAN WG3 for the comments and initial review of this document. 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 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 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 Jesske Expires - December 2005 [Page 13]
Analysis of TISPAN req. to SIP June 2005 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 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 - December 2005 [Page 14]