[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/