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]