Internet DRAFT - draft-avasarala-sipping-reason-header-dynamic-icb

draft-avasarala-sipping-reason-header-dynamic-icb






SIPPING                                                R. Avasarala, Ed.
Internet-Draft                                                   S. Saha
Intended status: Informational                                  Motorola
Expires: September 3, 2009                                    V. Pascual
                                                                 Tekelec
                                                           March 2, 2009



A Session Initiation Protocol (SIP) Reason Header extension for dynamic
                     Incoming Communication Barring
        draft-avasarala-sipping-reason-header-dynamic-icb-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 September 3, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Avasarala, et al.       Expires September 3, 2009               [Page 1]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


Abstract

   The 3GPP, as part of the MITE work item, is defining the Multimedia
   Telephony service and other Supplementary services using the IP
   Multimedia Core Network framework.  Supplementary services include
   Incoming and Outgoing Communication Barring.  This document describes
   a new set of procedures for Incoming Communication Barring to allow
   terminating users to dynamically block unwanted incoming
   communications.  A new extension to SIP reason header is also
   described.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Caller Identity Blocking Events  . . . . . . . . . . . . . . .  3
     3.1.  Blocking caller identity when caller identity is known . .  4
     3.2.  Blocking caller identity when caller identity is
           unknown  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Reason header cause codes and semantics  . . . . . . . . . . .  4
     4.1.  Block Permanently Reason Code  . . . . . . . . . . . . . .  5
     4.2.  Block Temporarily Reason Code  . . . . . . . . . . . . . .  5
   5.  Examples of Blocking events  . . . . . . . . . . . . . . . . .  6
     5.1.  Blocking caller during ringing phase . . . . . . . . . . .  6
     5.2.  Blocking caller during call termination phase  . . . . . .  6
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Block Namespace Registry . . . . . . . . . . . . . . . . .  8
     7.2.  Default Reason-Text IANA Registry for the SIP Reason
           header . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 10
   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10













Avasarala, et al.       Expires September 3, 2009               [Page 2]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


1.  Introduction

   3GPP is currently maintaining and specifying multimedia telephony
   services and supplementary services.  As a part of this effort, the
   procedures for Incoming and Outgoing Communication barring including
   Outgoing and Incoming communication barring procedures are defined in
   [4].  However, the current procedures do not allow terminating users
   to dynamically block unwanted incoming communications.

   This document proposes a mechanism to enable called users to block
   unwanted incoming communications in realtime.  It is achieved by
   extending the SIP Reason header to be included in the SIP BYE and
   CANCEL requests for blocking a calling identity from further calling.

   Also this document defines mechanisms for the called users to specify
   block criteria for blocking the calling users.  The blocking criteria
   could include:


   1.  Blocking calling users permanently so that the caller can never
       call the terminating user again

   2.  Blocking calling users for a certain period of time

   Further this document also defines mechanism for blocking the callers
   either during the call alerting phase or during call termination
   time.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1] and indicate
   requirement levels for compliant implementations.

   The other concepts used in this document are compatible with [2] and
   [3]


3.  Caller Identity Blocking Events

   As mentioned previously the blocking events occur at the terminating
   user agents.  The terminating user agents trigger the SIP BYE or
   CANCEL method with the enhanced SIP Reason header for caller identity
   blocking when they wish to block the caller from further calling.





Avasarala, et al.       Expires September 3, 2009               [Page 3]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


3.1.  Blocking caller identity when caller identity is known

   Here the identity of the caller is known to the called user and the
   called user can trigger the BYE or CANCEL request with the SIP Reason
   header for caller identity blocking and get the caller blocked from
   further calling.

3.2.  Blocking caller identity when caller identity is unknown

   Sometimes the calls from telemarketers or other businesses have vague
   identities or just names like "CountryClub" or "Unknown" and it would
   be impossible for the called users to block such callers using those
   identities.  In such cases, the servers need to fetch the actual
   identity of the caller and use that identity for blocking callers.


4.  Reason header cause codes and semantics

   This document defines the following new protocol value for the
   protocol field of the Reason header defined in [3]


         block: The cause parameter contains the block code.


   We define the following block cause codes:


    Value   Default Text          Description

      1     Block permanently     Block the calling user permanently
      2     Block temporarily     Block the calling user for a temporary
                                  period of time


   Examples are:


     Reason: block; cause=1; text="Hate This Guy";
                             uri="sip:telem@domain.com; Expires=99999
     Reason: block; cause=2; text="Out on Vacation";
                             uri="sip:Bob@example.com; Expires=604800
     Reason: block; cause=2; text="greylisted";
                             uri=sip:Alice@domain.com; Expires=3600







Avasarala, et al.       Expires September 3, 2009               [Page 4]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


   Sections 4.1 and 4.2 provide use cases and extended definitions for
   the above two cause codes.

4.1.  Block Permanently Reason Code

   A more elaborate description of Block Permanently Reason Code cause=1
   is as follows:

   The called user intends to block the calling user permanently to
   prevent further calling.

   An example of this header value would be:

   Reason: block; cause=1; text="Telemarketer";
   uri="sip:user@domain.com; Expires=99999

   This implies that the called user has identified the calling user
   identity identified by "uri" parameter defined in as a Telemarketer
   and wants to block the caller from further calling.  So here putting
   a value of "99999" for Expires parameter implies the blocking is for
   permanent duration.

   The message flow for this block type is depicted in Figure 1

4.2.  Block Temporarily Reason Code

   A more elaborate description of Block Temporarily Reason Code cause=2
   is as follows:

   The called user intends to block the calling user for a temporary
   period.

   An example of this usage would be:

   Reason: block; cause=2; text="Out on Vacation"; Expires=3600

   This implies that the called user is Out on Vacation and wants to
   block the incoming calls from the caller Till the called user
   returns.  The date until which the block is effective is mentioned
   using the Expires parameter and the identity of the calling user is
   identified by "uri" parameter defined in

   So here the block period is mentioned in Expires parameter implies
   the blocking is effective from the time of registration till the
   value specified in Expires parameter.


   The message flow for this block type is depicted in Figure 2



Avasarala, et al.       Expires September 3, 2009               [Page 5]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


5.  Examples of Blocking events

5.1.  Blocking caller during ringing phase

   As mentioned earlier, the called user (UAS) can block the incoming
   caller (UAC) during ringing phase by looking at the number displayed
   on the phone.  Below is the call flow for blocking a caller (UAC) in
   ringing phase



     Alice                      Proxy                      Bob

      |   INVITE                |                          |
      |------------------------>|   INVITE                 |
      |                         |------------------------->|
      |                         |   180 RINGING            |
      |    180 RINGING          |<-------------------------|
      |<------------------------|                          |
      |                         |                          |
      | +------------------------------------------------+ |
      | | Looking at Caller ID, the called user decides  | |
      | | to block the calling user from further calling | |
      | +------------------------------------------------+ |
      |                                                    |
      |                               4xx                  |
      |        4xx              |<-------------------------|
      |<------------------------|Reason:block; cause=1     |
      |                         | text="Hate This Guy"     |
      |                         | uri="sip:Alice@domain.com|
      |                         | Expires=99999            |
      |----------------------------------------------------|



                      Figure 1: Blocking Permanently

   Here the UAS sends a 4xx message with the enhanced Reason header
   indicating block semantics.

5.2.  Blocking caller during call termination phase

   Here the called user (UAS) blocks the incoming caller (UAC) during
   the call termination phase - i.e at the time of termination of the
   call






Avasarala, et al.       Expires September 3, 2009               [Page 6]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


     Bob                      Proxy                       Carol

      |   INVITE                |                          |
      |------------------------>|   INVITE                 |
      |                         |------------------------->|
      |                         |   180 RINGING            |
      |    180 RINGING          |<-------------------------|
      |<------------------------|                          |
      |                         |   200 OK                 |
      |    200 OK               |<-------------------------|
      |<------------------------|                          |
      |        In Conversation                             |
      |<==================================================>|
      |                                                    |
      | +-------------------------------------------------+|
      | | Here the called user (UAS) decides to block the ||
      | | the caller from further calling                 ||
      | +-------------------------------------------------+|
      |                                                    |
      |                         |    BYE                   |
      |                         |<-------------------------|
      |    BYE                  |Reason: block; cause=2    |
      |<------------------------| text="In Meeting"        |
      |                         | uri="sip:bob@example.com |
      |                         | Expires=3600             |
      |                         |                          |
      |    200 OK               |                          |
      |------------------------>|      200 OK              |
      |                         |------------------------->|



                  Figure 2: Blocking for Temporary Period


6.  Security Considerations

   Eavesdropping on this header field should not prevent proper
   operation of the SIP protocol, although some domains utilizing this
   mechanism for notifying and synchronizing SIP elements will likely
   want the integrity to be assured.  It is therefore RECOMMENDED to
   apply integrity protection when using this header to prevent unwanted
   changes to the field and snooping of the messages.  The accepted
   choices to provide integrity protection in SIP are TLS and S/MIME.
   If a caller manages to impersonate a calling party (i.e. identity
   impersonation), it could trigger called parties to block incoming
   calls from the supplanted identity.




Avasarala, et al.       Expires September 3, 2009               [Page 7]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


7.  IANA Considerations

   This document adds to one existing IANA Registry and creates one new
   Registry.  The existing IANA Registry for the SIP Reason Header is as
   follows:


   Protocol Value   Protocol Cause            Reference
   --------------   --------------            ---------
    SIP              Status code               RFC 3261
    Q.850            Cause value in decimal    ITU-T Q.850

    This document adds to that Registry with the following entry
    (including the '*' comment)

    Protocol Value  Protocol Cause            Reference
    --------------  --------------            ----------
    block           Cause value in decimal*   RFCXXXX

    Parameter: Expires  Defined in RFC3261
    Parameter: uri      Defined in RFC3261

    * See the separate "block" Registry for default reason-text
      strings



   The cause values created by the Block protocol namespace in this
   document are defined in Section Section 7.1.

   Each cause value has a Reason-text string as a general description of
   what the cause value is for, This is shown for the existing Reason
   header in Section 2 of [3] Before this document, the Reason-text was
   taken from the SIP Response code string from all SIP Response codes,
   or the default description from Q.850 cause codes.  Currently, there
   is no place to register new reason-text strings other than from those
   two sources.  Because this document defines a new Reason header
   protocol namespace, a new IANA Registry is created in Section 7.2
   just for this and future Reason header protocol namespaces (other
   than SIP Response codes or Q.850 cause values) to register their
   respective general descriptive text strings.  These text strings are
   non-binding and merely the default for human understanding, but they
   are deemed important enough to have their own Registry

7.1.  Block Namespace Registry

   RFC [xxxx] (this document) creates the new SIP Reason header [3]
   protocol namespace: "block", with 2 defined cause codes.



Avasarala, et al.       Expires September 3, 2009               [Page 8]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


   In instances where this namespace is used for permanently blocking a
   caller at the UA, the following syntax shall be used (the reason-text
   is a default string, it is not mandatory, and may be different):



         Reason: block; cause=1; text="block permanently";
         uri="sip:user@domain.com"; Expires=NNNNN

         The value NNNNN is 99999 indicating a permanent block


   Section 4 of this document describes in detail the semantics of this
   cause code.

   The default text is part of a new IANA Registry for default text
   strings for any new protocol namespace cause code.  See Section
   Section 7.2 for details.

   In instances where this namespace is used for temporarily blocking a
   caller at the UA, the following syntax shall be used (the reason-text
   is a default string, it is not mandatory, and may be different):


   Reason: block; cause=2; text="block temporarily";
            uri="sip:user@domain.com"; Expires=XYZ

   The value XYZ indicates time of block in seconds


7.2.  Default Reason-Text IANA Registry for the SIP Reason header

   Below is the creation of a new IANA Registry for SIP Reason Header
   reason-text strings, associated with their respective protocol type
   and Reason-param cause values.  Per RFC 3326, the Reason-text string
   is a quoted default string with only human understandability meant.
   These strings can be changed by local policy



                 Reason-
    Protocol     param      Reason-Text         Reference
    --------     -------    ------------        ---------
    Block        Cause=1    Block permanently   RFC XXXX [this document]
    Block        Cause=2    Block temporarily   RFC XXXX [this document]






Avasarala, et al.       Expires September 3, 2009               [Page 9]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


8.  Acknowledgements

   The Authors would like to thank Samir Saklikar for initial
   contribution, to Jette Alan and Ian Doig for providing the support in
   3GPP and to Joachim Charzinki for valuable comments and suggestions.


9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  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.

   [3]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
        Field for the Session Initiation Protocol (SIP)", RFC 3326,
        December 2002.

9.2.  Informative References

   [4]  3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia
        Telephony Service and supplementary services; Stage 1", 3GPP
        TS 22.173 7.5.0, June 2008.


Appendix A.  Change Log

   New document


Appendix B.  Open Issues

   Some (offline?) mechanism for unblocking user identities is expected














Avasarala, et al.       Expires September 3, 2009              [Page 10]

Internet-Draft      SIP Reason Header for dynamic ICB         March 2009


Authors' Addresses

   Ranjit Avasarala (editor)
   Motorola India Pvt Ltd
   Bagamane Tech Park, C V Raman Nagar
   Bangalore  560093
   India

   Email: ranjit@motorola.com


   Subir Saha
   Motorola India Pvt Ltd
   Bagamane Tech Park, C V Raman Nagar
   Bangalore  560093
   India

   Email: subir.saha@motorola.com


   Victor Pascual
   Tekelec
   Am Borsigturm 11
   Berlin  D13507
   Germany

   Email: victor@iptel.org
























Avasarala, et al.       Expires September 3, 2009              [Page 11]