Internet DRAFT - draft-hautakorpi-reason-header-for-warnings
draft-hautakorpi-reason-header-for-warnings
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: <sip:b@b1.org?Reason=SIP;cause=488? |
| | Reason=SIP-Warning;cause=305>;idx=1 |
| | | | |
| | 6 488 Not Acceptable Here | |
| |<----------------------------| |
| | Warning: 370 pc2.example.org "Insuf. bandwidth"
| | | | |
| | 7 ACK | | |
| |---------------------------->| |
| | | | |
| | 8 INVITE | | |
| |------------------------------------------->|
| | H-I: <sip:b@b1.org?Reason=SIP;cause=488? |
| | Reason=SIP-Warning;cause=305>;idx=1, |
| | <sip:b@b2.org?Reason=SIP;cause=488? |
| | Reason=SIP-Warning;cause=370>;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]
