Internet draft Reason header in responses July 2005 Sipping Working Group Internet Draft Roland Jesske Expires: January 5, 2006 Deutsche Telekom July 2005 Use of the Reason header filed in Session Initiation Protocol (SIP) responses draft-jesske-sipping-etsi-ngn-reason-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 This document proposes the use of the Reason header field in SIP responses. Jesske Expires - January 2006 [Page 1] Internet draft Reason header in responses July 2005 Table of Contents 1. Overview 2. Overall Applicability 3. Terminology 4. Procedures 5. Example 6. Security Considerations 7. IANA Considerations 1. Overview The European Telecommunication Standards Institute (ETSI) is defining a Next Generation Network (NGN) where a substantial part of it is based on the IP Multimedia Subsystem (IMS) defined by the Third- Generation Partnership Project (3GPP). IMS is largely based on the Session Initiation Protocol [1]. ETSI has developed a number of requirements draft-jesske-sipping- tispan-requirements [5] to support the usage of SIP in Next Generation Networks that interoperate, at the service level, with the Public Switched Telephone Network (PSTN), the Integrated Services Digital Network (ISDN), the 3GPP IP Multimedia Subsystem (IMS), and SIP networks and terminals that implement the service logic. In order to provide full support in SIP of existing services, extensions to SIP are needed. This document proposes the use of the Reason header field in responses. This is needed for creating services that must be interoperable with the PSTN/ISDN network and the interoperability of traversing communications through SIP not using SIP-I. An example is the ACR services described within draft-jesske-sipping- tispan-requirements [2]. Here it is needed to send the cause value #24 back to the PSTN/ISDN to identify why the communication was restricted and serve the user a correct announcement. The described solution fulfils the requirements [REQ-GEN-1] and [REQ- ACR-1]. 2. Overall Applicability The SIP procedures specified in this document are foreseen for networks providing simulation services and/or interwoking to the PSTN/ISDN. The document is describing the use of the Reason header in SIP responses. These procedures are only valuable if the reason contained in the element "protocol" is "Q.850" or "Redirection". " Redirection" Jesske Expires - January 2006 [Page 2] Internet draft Reason header in responses July 2005 is a redirecting reason as described in [7] draft-elwell-sipping- redirection-reason-02.txt. A inclusion of a SIP reason (protocol="SIP") is not helpful due to the fact that the response already provides the SIP reason. The Release Causes are described within ETSI EN300 485 [5] 3. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. 4. Procedures For providing services and PSTN/ISDN interoperability it MUST be possible to include Reason header fields with Q.850 Cause values or redirecting reasons as described in [7] draft-elwell-sipping- redirection-reason-02.txt in responses. 4.1. Procedures at the UA A UA that supports the Reason header field can process the Q.850 Cause Value and display it or an equivalent text. The inclusion of a Reason header field by UA is only for 2B2 UA interworking with the PSTN/ISDN or providing services foreseen. 4.2. Procedures at a SIP proxy SIP proxies that receive a response containing a Reason header field is forwarding the response without changing the reason. A SIP proxy receiving a request that includes a Reason header field can route the request to an application server for further analysis and base services on it. Based on network policy a Proxy can remove a Reason header field send from a UAC. 4.3 Procedures at an application server An application server that receives a SIP request that contains a response including a Reason header MAY analyze the SIP Reason and base further procedures on this analyses. For Example the application server could use the reason for sending a announcement towards the originating entity of the Session. Jesske Expires - January 2006 [Page 3] Internet draft Reason header in responses July 2005 If the application server provides a Service it can provide also Responses include a Q.850 reason or redirecting reasons as described in [7] draft-elwell-sipping-redirection-reason-02.txt in responses. As an example the Anonymous Communication Rejection (ACR) service defined by ETSI Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) 5 Example Figure 1 shows the example of the ACR service interworking with the PSTN/ISDN A Gateway Proxy AS | IAM | | | |------------------>| INVITE | | | |----------------->| INVITE | | | 100 Trying |----------------->| | |<-----------------| 100 Trying | | | |<-----------------| | ACK SDP held | | | |<------------------| | 603 Decline | | | 603 Decline | Reason Q850 #24 | | | Reason Q850 #24 | | | REL Cause #24 | |<-----------------| | |<-----------------| | |<----------------- | | | | | | | | | | | | | | | Figure 1: Third Party Call Control 6. Security Considerations The presence of the Reason header in a response does not affect the treatment of the response. Including such a header by an untrusted entity could adulterate the reactions of the originating entitys. E.G. sending back a cause value "24" can cause an announcement within the PSTN/ISDN saying that the call was rejected due to the ACR service. Therefore it is RECOMMENDED to include the Reason header in Responses only by trusted entities as it is described within RFC3325 [8] 7. IANA Considerations Jesske Expires - January 2006 [Page 4] Internet draft Reason header in responses July 2005 This document describes the use of the Reason header field described within RFC 3326 [2]. No additional SIP elements are defined within this document. 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] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the Session Initiation Protocol (SIP)", RFC 3326. [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] 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] ". [6] Jesske, R., Alexeitsev, D., Garcia-Martin, M. "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" (work in progress) June 2005 [7] Elwell, J., "SIP Reason header extension for indicating redirection reasons", draft-elwell-sipping-redirection-reason- 02.txt (work in progress), 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. Note: The ETSI specifications can be downloaded under http://pda.etsi.org/pda/queryform.asp free of charge. Jesske Expires - January 2006 [Page 5] Internet draft Reason header in responses July 2005 Contributors Denis Alexeitsev Deutsche Telekom Am Kavalleriesand 3 64307 Darmstadt Germany Phone: +496151832130 Email: d.alexeitsev@t-com.net Acknowledgments The author would like to thank the members of the ETSI TISPAN WG3 for their comments to this memo. Author's Addresses Roland Jesske Deutsche Telekom Am Kavalleriesand 3 64307 Darmstadt Germany Phone: +496151835940 Email: r.jesske@t-com.net 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 Jesske Expires - January 2006 [Page 6] Internet draft Reason header in responses July 2005 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 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 - January 2006 [Page 7]