| SIPPING | R. Avasarala, Ed. |
| Internet-Draft | S. Saha |
| Intended status: Informational | Motorola |
| Expires: July 28, 2012 | V. Pascual |
| Tekelec | |
| January 27, 2012 |
None
A Session Initiation Protocol (SIP) Reason Header extension for dynamic Incoming Communication Barring draft-avasarala-sipping-reason-header-dynamic-icb-00.txt
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.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 28, 2012.
Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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 [3GPP.22.173]. 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:
Further this document also defines mechanism for blocking the callers either during the call alerting phase or during call termination time.
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 [RFC2119] and indicate requirement levels for compliant implementations.
The other concepts used in this document are compatible with [RFC3261] and [RFC3326]
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.
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.
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.
This document defines the following new protocol value for the protocol field of the Reason header defined in [RFC3326]
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
Sections 4.1 and 4.2 provide use cases and extended definitions for the above two cause codes.
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 [RFC3261] 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
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 [RFC3261]
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
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 |
|----------------------------------------------------|
Here the UAS sends a 4xx message with the enhanced Reason header indicating block semantics.
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
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 |
| |------------------------->|
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.
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 [RFC3326] 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
RFC [xxxx] (this document) creates the new SIP Reason header [RFC3326] protocol namespace: "block", with 2 defined cause codes.
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
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]
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.
| [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. |
| [1] | 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1", 3GPP TS 22.173 10.3.0, April 2011. |
New document
Some (offline?) mechanism for unblocking user identities is expected