Motorola India Pvt Ltd Bagamane Tech Park, C V Raman Nagar Bangalore 560093 India ranjit@motorola.comMotorola India Pvt Ltd Bagamane Tech Park, C V Raman Nagar Bangalore 560093 India subir.saha@motorola.comTekelec Am Borsigturm 11 Berlin D13507 Germany victor@iptel.orgSIPPING 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.
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 .
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:
Blocking calling users permanently so that the caller can never call the terminating user againBlocking 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. 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 and indicate requirement levels for compliant implementations.
The other concepts used in this document are compatible with and 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 We define the following block cause codes: Examples are: Sections and 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 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
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
| 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
| 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: The cause values created by the Block protocol namespace in this document are defined in Section .
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 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 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 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):
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 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): 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 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. New document Some (offline?) mechanism for unblocking user identities is expected