SIPPING Working Group J. Hautakorpi, Ed. Internet-Draft G. Camarillo Expires: April 15, 2006 Ericsson October 12, 2005 Extending the Session Initiation Protocol Reason Header with Warning Codes draft-hautakorpi-reason-header-for-warnings-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 April 15, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies a new protocol value, called 'SIP-Warning', for the Session Initiation Protocol (SIP) Reason header. The values for the name space of 'SIP-Warning' are taken from the Warning codes (warn-codes) of SIP. In addition, this document also defines one new SIP Warning code to be used in situations where User Agent Server (UAS) does not accept calls from an anonymous source. Hautakorpi & Camarillo Expires April 15, 2006 [Page 1] Internet-Draft Reason header with warning codes October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4 5. New Warning Code for SIP . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informational References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Hautakorpi & Camarillo Expires April 15, 2006 [Page 2] Internet-Draft Reason header with warning codes October 2005 1. Introduction The main purpose of this document is to introduce a new protocol value for Session Initiation Protocol (SIP) [3] Reason header field [2]. The Reason header field provides information on why a SIP request was issued. The protocol value defined in this draft is called 'SIP-Warning' and it consists of the Warning codes (warn-codes) defined in the Section 20.43 of [3]. With 'SIP-Warning', it is possible to convey richer information about the reason why a SIP request was generated. This draft defines also one new Warning code for the situations where the User Agent Server (UAS) does not accept calls from an anonymous source. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Usage A SIP entity MAY add a Reason header field with the 'SIP-Warning' protocol value to a SIP request. Example syntax is as follows: Reason: SIP-Warning; cause=304; text="Media type not available" Currently, the Reason header field can convey the status code of the response that triggered the generation of the SIP request in question. By utilizing the possibility to convey more than one Reason header field in one request, and by defining a new 'SIP- Warning' protocol value, it is possible to also convey the information contained in the Warning header field of the triggering response to the final recipient. The use of 'SIP-Warning' is especially useful in the context of SIP Request History Information [4]. This is because SIP Request History Information uses Reason entries to inform about which kind of responses user agents return. Hautakorpi & Camarillo Expires April 15, 2006 [Page 3] Internet-Draft Reason header with warning codes October 2005 4. Example Use Cases This section contains two example use cases of the 'SIP-Warning' protocol value. The first example contains two user agent and one third party call controller in the following example use case. A simplified message exchange is illustrated in Figure 1. A Controller B | 1 INVITE | | |<-------------------| | | | | | 2 200 OK | | |------------------->| | | | | | 3 ACK | | |<-------------------| | | | | | | 4 INVITE | | |------------------------------>| | | | | | 5 480 Temporatily unavailable | | |<------------------------------| | | Warning: 399 pc2.example.org "Low battery" | | | | | 6 ACK | | |------------------------------>| | 7 BYE | | |<-------------------| | | Reason: SIP; cause=487; text="Request Terminated" | | Reason: SIP-Warning; cause=399; text="Low battery" | | | | | 8 200 OK | | |------------------->| | | | | Figure 1: Example Use Case with Third Party Call Controller The third party call controller tries to establish a session between A and B. However, B has a terminal with a battery, which is running out. So, B do not want to take this call because it would drain out the battery completely. If there would not be a way to convey Warning codes in Reason header field, A would not have any way of knowing why the session establishment really failed. In the second use case user A tries to establish a sessions with B. User B has registered three user agents, which are B1, B2 and B3. A simplified message exchange is illustrated in Figure 2. When A send Hautakorpi & Camarillo Expires April 15, 2006 [Page 4] Internet-Draft Reason header with warning codes October 2005 an INVITE, the proxy sends INVITEs in sequence to B's registered user agents. A1 Proxy B1 B2 B3 | 1 INVITE | | | | |--------->| 2 INVITE | | | | |------------->| | | | | | | | | | 3 488 Not Acceptable Here | | | |<-------------| | | | | Warning: 305 pc1.example.org "Incomp. media" | | | | | | | 4 ACK | | | | |------------->| | | | | | | | | | 5 INVITE | | | | |---------------------------->| | | | H-I: ;idx=1 | | | | | | | | 6 488 Not Acceptable Here | | | |<----------------------------| | | | Warning: 370 pc2.example.org "Insuf. bandwidth" | | | | | | | 7 ACK | | | | |---------------------------->| | | | | | | | | 8 INVITE | | | | |------------------------------------------->| | | H-I: ;idx=1, | | | ;idx=2 | | | | | | | | 9 200 OK | | | | |<-------------------------------------------| | | | | | | | 10 ACK | | | | |------------------------------------------->| | | | | | Figure 2: Example Use Case with a SIP Proxy INVITEs to B1 and B2 fail, and their warning codes are conveyed in responses 3 and 6. Proxy attaches the returned warning codes to History-Info header field (denoted as 'H-I' on the figure). So, when the B3 gets an INVITE, it can see why the previous INVITEs have Hautakorpi & Camarillo Expires April 15, 2006 [Page 5] Internet-Draft Reason header with warning codes October 2005 failed. 5. New Warning Code for SIP The following SIP Warning code (warn-code) conveys information about the event, where UAS has not accepted a call because it was originated from an anonymous source. 390 Anonymous calls not allowed: UAS does not accept anonymous calls. The motivation behind the definition of this new Warning code is that there are cases where there is a need to take automated actions based on the fact the UAS has not accepted a call from anonymous source. An example from such case is a situation where an anonymous call from Public Switched Telephone Network (PSTN) is going to an IP network, and then the UAS does not accept it. In this case, the gateway on the communication path may need to take automated actions based on the fact that callee does not accept anonymous calls. Open issue: SIP's RFC [3] allows only such Warning codes that are related to the Session Description Protocol (SDP). Should this be the case also in the future? 6. Security Considerations An attacker may attempt to add, modify, or remove the values that belong to 'SIP-Warning' name space on Reason header field. This could result in an application behaving in a non-desirable way. So, it is strongly RECOMMENDED that integrity protection be applied to the SIP messages in question. Eavesdropping does not pose any threats or vulnerabilities, and it does not prevent a proper operation. A new Warning code, specified in Section 5 does not have any security considerations in itself. 7. IANA Considerations This document has two separate IANA considerations. The first one is that this defines a new protocol value for the SIP Reason header field: Hautakorpi & Camarillo Expires April 15, 2006 [Page 6] Internet-Draft Reason header with warning codes October 2005 Protocol value Protocol Cause Reference -------------- ------------------------------ --------- SIP-Warning Warning code [RFC XXXX] The second IANA consideration is that a new Warning code for SIP Warning code (warn-code) Registry is defined: Code Description Reference ---- ------------------------------------------------- --------- 390 Anonymous calls not allowed: UAS does not accept [RFC XXXX] anonymous calls. The 'RFC XXXX' tag needs to be replaced with the RFC number of this document. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. [3] 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. 8.2. Informational References [4] Barnes, M., "An Extension to the Session Initiation Protocol for Request History Information", draft-ietf-sip-history-info-06 (work in progress), January 2005. Hautakorpi & Camarillo Expires April 15, 2006 [Page 7] Internet-Draft Reason header with warning codes October 2005 Authors' Addresses Jani Hautakorpi (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Jani.Hautakorpi@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Hautakorpi & Camarillo Expires April 15, 2006 [Page 8] Internet-Draft Reason header with warning codes October 2005 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 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hautakorpi & Camarillo Expires April 15, 2006 [Page 9]