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]