DISPATCH Ranjit. Avasarala
Internet-Draft Motorola Solutions Inc
Intended status: Informational R. Jesske
Expires: May 26, 2011 Deutsche Telekom
November 22, 2010
A Session Initiation Protocol (SIP) Event Package for Communication
Barring Notification Information in support of the Dynamic Incoming
Communication Barring (ICB) service
draft-avasarala-dispatch-comm-barring-notification-01.txt
Abstract
3GPP is defining the protocol specification for the Communication
Barring (CB) service using IP Multimedia (IM) Core Network (CN)
subsystem supplementary service and more particularly the dynamic
incoming communication barring service. As part of dynamic incoming
communication barring (ICB) service, a SIP based Event package
framework is used for notifying users about communication barrings
(dynamic and rule based) of their incoming communication sessions.
This document proposes a new SIP event package for allowing users to
subscribe to and receive such notifications. Users can further
define filters to control the rate and content of such notifications.
The proposed event package is applicable to the ICB supplementary
service in IMS and may not be applicable to the general internet..
Status of this Memo
This Internet-Draft is submitted 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 May 26, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Avasarala & Jesske Expires May 26, 2011 [Page 1]
Internet-Draft SIP Communication Barring Notification November 2010
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Avasarala & Jesske Expires May 26, 2011 [Page 2]
Internet-Draft SIP Communication Barring Notification November 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Abbreviations and Definitions . . . . . . . . . . . . . . . . 5
4.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Package Definition . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6
6.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 6
6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 6
6.5. Notify bodies . . . . . . . . . . . . . . . . . . . . . . 6
6.6. Notifier Processing of SUBSCRIBE requests . . . . . . . . 7
6.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 7
6.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 7
6.7. Notifier Generation of NOTIFY requests . . . . . . . . . . 8
6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9
6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9
6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9
6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9
7. Comm_barring-info Document . . . . . . . . . . . . . . . . . . 9
8. Structure of Comm_barring-info Format . . . . . . . . . . . . 10
8.1. Comm_barring-info Element . . . . . . . . . . . . . . . . 10
8.1.1. comm-barring-subs-info Element . . . . . . . . . . . . 10
8.1.2. Comm-barring-ntfy-info Element . . . . . . . . . . . . 12
8.1.3. Comm_barring-info-selection-criteria . . . . . . . . . 13
8.2. Sample Notification body . . . . . . . . . . . . . . . . . 14
8.2.1. Instance of communication barring subscription
filter document . . . . . . . . . . . . . . . . . . . 14
8.2.2. Instance of communication barring notification
document . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Communication Barring Information Event Package
Registration . . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Avasarala & Jesske Expires May 26, 2011 [Page 3]
Internet-Draft SIP Communication Barring Notification November 2010
1. Introduction
3GPP is currently maintaining and specifying incoming communication
barring mechanisms which allow users to dynamically block incoming
communications from callers whom they consider as unwanted or
unsolicited. The intention of such mechanisms is to provide users
with sufficient flexibility to manage their incoming communications
in a better way. The most common example is the Anonymous
Communication Rejection (ACR) where in the incoming communications
from senders whose identity is marked as "Anonymous" is rejected.
Similarly other variants of ICB include dynamically blocking a
particular caller by the subscribers, called the dynamic ICB which is
specified in 3GPP specification [1].
However, However, with the increasing number of unwanted calls and
increased usage of incoming communication barring services, users may
have lot of callers being blocked from time to time and for different
periods based on temporary or permanent block. For instance, a user
may have blocked a particular caller for a temporary period and
specified the period as 1 year. Though there are ways by which users
can keep track of their communication barrings, there is no efficient
mechanism for the users to get information of their communication
barrings that get enacted in the network. This information would
help them to verify their rules and rectify if required
This document defines a SIP event package that allows a SIP User
Agents to subscribe to and be notified of communication barrings
enacted on their behalf
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant implementations.
3. Applicability Statement
It is believed that the SIP event package defined here is not
applicable to the general Internet and has been designed to serve the
architecture of the Dynamic ICB service defined for IMS core
networks. The aim of this memo is to follow the procedure indicated
in RFC 5727 [3] and to register a new event package with event name
"comm-barring-info" with IANA.
Avasarala & Jesske Expires May 26, 2011 [Page 4]
Internet-Draft SIP Communication Barring Notification November 2010
4. Abbreviations and Definitions
4.1. Abbreviations
CB: Communication Barring.
CBN: Communication Barring Notification.
ICB: Incoming Communication Barring.
4.2. Definitions
Subscriber - The User Agent who has subscribed to the
Communication Barring notification service.
User - Another term for the subscriber.
Barring User - The User Agent who has configured a Communication
Barring. This could be the User Agent who has configured the
Incoming Communication Barring service rules in the network.
Originating User - The User Agent who is the originator of the
incoming communication, The Originating User is also referred to
as the Caller.
IMS Core Network - This refers to the IMS based SIP based network
that conforms to the [7] and not the general SIP network as
defined in [4].
5. Requirements
The Communication Barring Notification (CBN) service enables a user
to receive notification about the barring of any of his/her incoming
communications, which were addressed to the user's address. A
comprehensive description of all the requirements that affect the CBN
service developed by 3GPP and is found in and [5] and [1]
6. Package Definition
This section fills in the details needed for an event package as
defined in Section 4.4 of [6].
6.1. Event Package Name
The SIP Events specification requires package definitions to specify
the name of their package or template-package.
Avasarala & Jesske Expires May 26, 2011 [Page 5]
Internet-Draft SIP Communication Barring Notification November 2010
The name of this package is "comm-barring-info". As specified in
[6], this value appears in the Event header present in SUBSCRIBE and
NOTIFY requests.
6.2. Event Package Parameters
The SIP Events specification [6] allows packages to define additional
parameters. This event package "comm-barring-info" does not define
additional parameters. .
6.3. SUBSCRIBE bodies
The SIP Events specification requires package or template-package
definitions to define the usage, if any, of bodies in SUBSCRIBE
requests.
A SUBSCRIBE for Communication Barring event MAY contain a body. The
purpose of the body depends on its type. Subscriptions to the
Comm_barring-info event package SHALL only include a body of MIME
type "application/comm-barring-info+xml".
A body of the SUBSCRIBE request with content type set to MIME type
"application/comm-barring-info+xml" contains information about the
communication barring notification information filter criteria and
notification trigger criteria. The subscriber SHALL also verify that
this information conforms to a valid XML document as defined in [8].
The subscriber SHALL also verify that the information contained in
the XML document contains elements defined in Section 8.1.1 only.
6.4. Subscription Duration
The default expiration time for subscriptions within this package is
3600 seconds. As per [6], the subscriber MAY specify an alternate
expiration in the Expires header field.
6.5. Notify bodies
The SIP Events specification requires package definitions to define a
default value for subscription durations, and to discuss reasonable
choices for durations when they are explicitly specified.
The NOTIFY message contains bodies. This body is a format listed in
the Accept header field of the SUBSCRIBE request or a package
specific default format if the Accept header field was omitted from
the SUBSCRIBE request.
In this event package, the body of the notification contains the
communication barring information pertaining to the barring that
Avasarala & Jesske Expires May 26, 2011 [Page 6]
Internet-Draft SIP Communication Barring Notification November 2010
occurred in the network on behalf of the subscriber. The format of
the communication barring information is an XML document as per
elements defined in Section 8.1.2.
All subscribers and notifiers of the "comm-barring-info" event
package MUST support the "application/comm-barring-info+xml" data
format described in Section 8. The SUBSCRIBE request MAY contain an
Accept header field. If no such header field is present, it has a
default value of "application/comm-barring-info+xml" (assuming Event
header has a value of "comm-barring-info"). If the Accept header
field is present, it MUST contain the value "application/
comm-barring-info+xml".
6.6. Notifier Processing of SUBSCRIBE requests
The contents of a document containing comm-barring-info information
can contain sensitive information that can reveal some privacy
information. Therefore, such comm-barring-info documents MUST only
be sent to authorized subscribers. In order to determine if a
subscription originates in an authorized user, the subscriber MUST be
authenticated as described in Section 6.6.1 and then the user MUST be
authorized to be a subscriber as described in Section 6.6.2.
The Notifier MUST look into the SUBSCRIBE request body for a comm-
barring-info document containing filter criteria. If the filter
criteria is present, it should check if the filter criteria conforms
to the format described in Section 8.1.1. If the received criteria
is valid, then the NOTIFIER MUST use that for generating
notifications about communication barrings that occur on behalf of
the user.
6.6.1. Authentication
Notifiers MUST authenticate all subscription requests. This
authentication can be done using any of the mechanisms defined in [4]
and other authentication extensions.
6.6.2. Authorization
Once authenticated, the notifier makes an authorization decision. A
notifier MUST NOT accept a subscription unless authorization has been
provided by the user. The means by which authorization are provided
are outside the scope of this document. Authorization may have been
provided ahead of time through access lists, perhaps specified in a
web page. Authorization may have been provided by means of uploading
some kind of standardized access control list document
Avasarala & Jesske Expires May 26, 2011 [Page 7]
Internet-Draft SIP Communication Barring Notification November 2010
6.7. Notifier Generation of NOTIFY requests
The SIP Events specification details the formatting and structure of
NOTIFY messages. However, packages are mandated to provide detailed
information on when to send a NOTIFY, how to compute the state of the
resource, how to generate neutral or fake state information, and
whether state information is complete or partial. This section
describes those details for the "comm-barring-info" event package.
A notifier MUST send a NOTIFY when a communication barring is enacted
on behalf of the user. If there is a stored filter criteria for the
user, then the notifier MUST look into the filter criteria before
generating the NOTIFY request towards the user. If the filter
criteria matches, then the notifier generates the NOTIFY request and
sends the NOTIFY request to the user. If the filter criteria does
not match the enacted communication barring, then the notifier just
increments the communication barring count and does not send any
NOTIFY request towards the user.
The body of the NOTIFY MUST be sent using the type "application/
comm-barring-info+xml" and must contain the elements defined in
Section 8.1.2 only. The Content-Type header field MUST be set to
"application/comm-barring-info+xml".
It is RECOMMENDED that the notifiers do maintain the history of last
N communication barrings that occurred, where the value N >=1 as part
of state information for that server and include it in the
communication barring notification information sent to the user. in
addition to this it is also RECOMMENDED that the notifiers maintain
the list of last M communication barring notifications sent to the
user, where M equal to or less than N. M equals N if notifications
are sent for all communication barrings that occurred. The value M
is decremented whenever a communication barring notification is sent
to the user. The notifiers check the value of M as being greater
than 0 prior to generating the notification information.
The value of N could be configured and is left to server policy to
determine appropriate value.
The state information is retained even after the notification for
those barrings are sent to the subscriber and changes when new
barring occurs and whenever a notification is sent. So every time a
new barring occurs and a notification is sent, the state information
changes to reflect the latest barring removing the oldest barring
information and to reflect the latest notification information sent.
Avasarala & Jesske Expires May 26, 2011 [Page 8]
Internet-Draft SIP Communication Barring Notification November 2010
6.8. Subscriber Processing of NOTIFY Requests
The SIP Events specification expects event packages to describe the
process followed by the subscriber upon receipt of a NOTIFY request.
In this specification, each NOTIFY request contains a comm-barring-
info document
6.9. Handling of Forked Requests
The SIP Events specification requires each package to describe
handling of forked Requests.
Though the incoming SUBSCRIBE request could be forked, this
specification only allows a single dialog to be constructed as a
result of emitting an initial SUBSCRIBE request, This guarantees that
only a single notifier is generating notifications for a particular
subscription to a particular user.
6.10. Rate of Notifications
The SIP Events specification requires each package to specify maximum
rate at which notifications can be sent .
Comm_barring-info notifiers SHOULD NOT generate notifications for a
single subscription at a rate of more than once every five seconds.
6.11. State Agents
The notifiers maintain the state of last N communication barrings and
last M communication barring notification sent, where N (N>=1) is the
number of communication barrings that occurred in the network on
behalf of the subscriber and M is the number of communication barring
notifications sent to the user. If notifications are sent for every
communication barring that occurred, then M will be equal to N, else
M will be less than N if filter criteria comes into play.
Thus at any point of time a subscriber MAY know the state of
communication barrings enacted on his or her behalf and number of
notifications sent by the server.
7. Comm_barring-info Document
Comm_barring-info document is an XML document [8] that MUST be well-
formed and SHOULD be valid. Communication Barring Information
documents MUST be based on XML 1.0 and MUST be encoded using UTF-8
[9].
Avasarala & Jesske Expires May 26, 2011 [Page 9]
Internet-Draft SIP Communication Barring Notification November 2010
8. Structure of Comm_barring-info Format
A Communications Barring Information document starts with a "comm-
barring-info" element. The comm-barring-info element has a series of
elements describing the particular communication barring or the
filter criteria for receiving the communication barring information.
8.1. Comm_barring-info Element
The comm-barring-info element gives information about the specific
communication barring or it could give information about a particular
selection criteria for the user receiving the communication barring
information.
8.1.1. comm-barring-subs-info Element
The comm-barring-subs-info element is used by the subscribing user to
specify the communication barring information selection criteria and
the communication barring notification trigger criteria. It contains
the following elements:
8.1.1.1. comm-barring-selection-criteria
This element contains information about communication barring
information selection criteria. It contains following sub-elements
for specifying the selection criteria.
8.1.1.1.1. originating-user-selection-criteria
This element specifies the originating user information for the
communication i.e. the caller. This is specified in the form of
"user-name" and "user-uri". E.g. sip:Alice@domain.com. The Username
as well as User-URI specified will be compared with the originating
user information of the current user and if there is a match, then
information about the barring of this specific communication would be
selected for notification to the Subscriber. It consists of the
following sub-elements.
8.1.1.1.1.1. user-info
This element gives user details like username and URI. This element
has further sub-elements for describing username and user URI
8.1.1.1.1.1.1. User-name
This element gives Username. "Alice".
Avasarala & Jesske Expires May 26, 2011 [Page 10]
Internet-Draft SIP Communication Barring Notification November 2010
8.1.1.1.1.1.2. User-URI
This element gives User URI. E.g "sip:Alice@domain.com". It takes
the form of any URI scheme like sip. sips, tel or any other URI
scheme
8.1.1.1.2. barring-time-selection-criteria
This element specifies the time range for receiving notifications.
It contains following additional elements .
8.1.1.1.2.1. time-range
This element specifies the time range at which notifications for
communication barrings can be sent to the subscriber. This could be
specified in the form of a time-interval to enable periodic
triggering of notifications of communication barrings which took
place in that time-interval.
NOTE: If the time-range element is not specified, then notifications
about every communication barring that occurs is sent to the
subscriber.
8.1.1.1.2.1.1. start-time
This element specifies the start time for receiving notifications.
Its value is expressed in YYYY:MM:DDTHH:MM:SSZ format.
8.1.1.1.2.1.2. end-time
This element specifies the end time for receiving notifications. Its
value is expressed in YYYY:MM:DDTHH:MM:SSZ format.
8.1.1.1.3. barring-reason-selection-criteria
This element contains the reason for communication barring. It
contains following sub-element:
8.1.1.1.3.1. barring-reason-info
This element gives the actual reason for the communication barring.
E.g. "Call Forward on Busy".
8.1.1.1.4. number-of-barrings-selection-criteria
This element contains the total number of barrings that occurred in
network on behalf of the user till then.
Avasarala & Jesske Expires May 26, 2011 [Page 11]
Internet-Draft SIP Communication Barring Notification November 2010
8.1.1.1.5. number-of-notifications-selection-criteria
This element contains the total number of communication barring
notifications sent by the network to user till then.
8.1.1.2. comm-barring-ntfy-trigger-criteria
8.1.1.2.1. notification-time-selection-criteria
This element informs the server about the time at which the
notification should be triggered.
8.1.1.2.2. presence-status-selection-criteria
This element gives the presence status of the subscriber, based on
which the decision can be made, whether the subscriber wishes to
receive notification information or not.
8.1.1.2.2.1. presence-selection-info
This element specifies the presence status of the subscriber within
which the subscriber expects to receive notifications about
communication barrings.
8.1.2. Comm-barring-ntfy-info Element
This element gives the notification information. This element has
following sub-elements:
8.1.2.1. originating-user-info
Refer to Section 8.1.1.1.1 for details of this element.
8.1.2.2. barring-time-info
This element gives the time of communication barring. Its value is
expressed in YYYY:MM:DDTHH:MM:SS format.
8.1.2.3. barring-reason-info
This element contains the reason for the communication barring which
could be because of the standard rules like ICB or ACR or any other
custom rule defined by the subscriber.
8.1.2.4. num-barrings
This element gives the number of communication barrings that occurred
in the network on behalf of the user till date.
Avasarala & Jesske Expires May 26, 2011 [Page 12]
Internet-Draft SIP Communication Barring Notification November 2010
8.1.2.5. num-notifications
This element gives the number of communication barring notifications
sent till date to the user.
8.1.3. Comm_barring-info-selection-criteria
This element gives the subscriber various to select communication
barring information. This element has following sub-elements.
8.1.3.1. disable-originating-user-info
This element gives the subscriber option of adding originating user
information to the notification information. The default value is
false which means the subscriber wants the originating-user-info
element to be present in the notification information.
8.1.3.2. disable-barring-time-info
This element gives the subscriber option of adding barring-time
information to the notification information. The default value is
false which means the subscriber wants the barring-time-info to be
present in the notification information.
8.1.3.3. disable-barring-reason
This element gives the subscriber option of adding barring-reason
information to the notification information. The default value is
false which means the subscriber wants the barring-reason information
to be present in the notification information.
8.1.3.4. disable-barring-rule
This element gives the subscriber option of adding barring-rule
information to the notification information. The default value is
false which means the subscriber wants the barring-rule information
to be present in the notification information.
8.1.3.5. disable-number-of-barrings
This element gives the subscriber option of adding number of barrings
that occurred till date to the notification information. The default
value is false which means the subscriber wants the number of
barrings that occurred till date information to be present in the
notification information
Avasarala & Jesske Expires May 26, 2011 [Page 13]
Internet-Draft SIP Communication Barring Notification November 2010
8.1.3.6. disable-number-of-notifications
This element gives the subscriber option of adding number of
communication barring notifications sent to the user till date to the
notification information. The default value is false which means the
subscriber wants the number of notifications that were sent to the
user till date information to be present in the notification
information.
8.2. Sample Notification body
8.2.1. Instance of communication barring subscription filter document
<comm-barring-info>
<comm-barring-subs-info>
<comm-barring-selection-criteria>
<originating-user-selection-criteria>
<user-info>
<user-name>Boss</user-name>
<user-URI>
sip:boss@office.com
</user-URI>
</user-info>
</originating-user-selection-criteria>
<barring-time-selection-criteria>
<time-range>
<start-time>1999-05-31T13:20:00-05:00Z</start-time>
<end-time>2006-05-06T13:20:00-05:00Z</end-time>
</time-range>
</barring-time-selection-criteria>
<barring-reason-selection-criteria>
<barring-reason-info>404 302</barring-reason-info>
</barring-reason-selection-criteria>
</comm-barring-selection-criteria>
<comm-barring-ntfy-trigger-criteria>
<notification-time-selection-criteria>
<time-range>
<start-time>1999-05-31T13:20:00-05:00Z</start-time>
<end-time>2006-05-06T13:20:00-05:00Z</end-time>
</time-range>
</notification-time-selection-criteria>
</comm-barring-ntfy-trigger-criteria>
</comm-barring-subs-info>
</comm-barring-info>
Avasarala & Jesske Expires May 26, 2011 [Page 14]
Internet-Draft SIP Communication Barring Notification November 2010
8.2.2. Instance of communication barring notification document
<comm-barring-info>
<comm-barring-ntfy-info>
<originating-user-info>
<user-name>Boss</user-name>
<user-URI>sip:boss@office.com</user-URI>
</originating-user-info>
<barring-time-info>1999-06-01T13:20:00-05:00Z
</barring-time-info>
<barring-reason-info>404</barring-reason-info>
<num-barrings>1 </num-barrings>
<num-notifications>1</num-notifications>
</comm-barring-ntfy-info>
</comm-barring-info>
8.3. Schema
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:comm-barring-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema
xmlns:tns="urn:ietf:params:xml:ns:comm-barring-info
xmlns="http://uri.etsi.org/ngn/params/xml/comm-barring-info"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!--
This import brings in the XML language definition
-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<!--
Communication Barring Information. This is the top-level XML element
-->
<xs:element name="comm-barring-info"
type="comm-barring-info-type" />
<!--
Communication Barring Information Type.
This is the top-level XML element
-->
<xs:complexType name="comm-barring-info-type">
<xs:sequence>
<xs:element name="comm-barring-subs-info"
type="comm-barring-subs-info-type" minOccurs="0" />
<xs:element name="comm-barring-ntfy-info"
Avasarala & Jesske Expires May 26, 2011 [Page 15]
Internet-Draft SIP Communication Barring Notification November 2010
type="comm-barring-ntfy-info-type" minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"
use="required"/>
</xs:complexType>
<!---
Communication Barring Subscription Type.
Used at Subscription time to
select Communication Barrings for notification,
when to notify them and
what to notify.
-->
<xs:complexType name="comm-barring-subs-info-type">
<xs:sequence>
<xs:element name="comm-barring-selection-criteria"
type="comm-barring-selection-criteria-type"
minOccurs="0" />
<xs:element name="comm-barring-ntfy-trigger-criteria"
type="comm-barring-ntfy-trigger-criteria-type"
minOccurs="0" />
<xs:element name="comm-barring-info-selection-criteria"
type="comm-barring-info-selection-criteria-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!---
Communication Barring Notification Information Type
Used while notifying the User about the Communication Barring
-->
<xs:complexType name="comm-barring-ntfy-info-type">
<xs:sequence>
<xs:element name="originating-user-info"
type="user-info-type" minOccurs="0" />
<xs:element name="barring-time-info"
type="xs:dateTime" minOccurs="0" />
<xs:element name="barring-reason-info"
type="barring-reason-info-type" minOccurs="0" />
<xs:element name="barring-rule-info"
type="barring-rule-info-type" minOccurs="0" />
<xs:element name="num-barrings" use="optional"
type="xs:interger" minOccurs="0" />
<xs:element name="num-notifications" use="optional"
type="xs:integer" minOccurs="0"/>
Avasarala & Jesske Expires May 26, 2011 [Page 16]
Internet-Draft SIP Communication Barring Notification November 2010
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
COMMUNICATION BARRING SELECTION CRITERIA
-->
<xs:complexType name="comm-barring-selection-criteria-type">
<xs:sequence>
<xs:element name="originating-user-selection-criteria"
type="user-selection-criteria-type" minOccurs="0" />
<xs:element name="barring-time-selection-criteria"
type="time-range-selection-criteria-type"
minOccurs="0" />
<xs:element name="barring-reason-selection-criteria"
type="barring-reason-selection-criteria-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
COMMUNICATION BARRING NOTIFICATION TRIGGER CRITERIA
-->
<xs:complexType name="comm-barring-ntfy-trigger-criteria-type">
<xs:sequence>
<xs:element name="notification-time-selection-criteria"
type="time-range-selection-criteria-type"
minOccurs="0" />
<xs:element name="presence-status-selection-criteria"
type="presence-status-selection-criteria-type"
minOccurs="0" />
<xs:element name="notification-buffer-interval"
minOccurs="0" default="86400">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:maxInclusive value="86400"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
COMMUNICATION BARRING INFORMATION SELECTION CRITERIA
-->
<xs:complexType name="comm-barring-info-selection-criteria-type">
Avasarala & Jesske Expires May 26, 2011 [Page 17]
Internet-Draft SIP Communication Barring Notification November 2010
<xs:sequence>
<xs:element name="disable-originating-user-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-barring-time-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-barring-reason-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-barring-rule-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-number-of-barrings"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-number-of-notifications"
type="xs:boolean" default="false" minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- User Info Type -->
<xs:complexType name="user-info-type">
<xs:sequence>
<xs:element name="user-name" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="user-URI" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
<!--
BARRING REASON INFO
-->
<xs:simpleType name="barring-reason-info-types">
<xs:list itemType="barring-reason-info-type"/>
</xs:simpleType>
<xs:simpleType name="barring-reason-info-type">
<xs:restriction base="xs:integer">
<xs:enumeration value="ICB"/>
<xs:enumeration value="ACR"/>
<xs:enumeration value="RULE"/>
</xs:restriction>
</xs:simpleType>
<!--
BARRING RULE INFO
-->
<xs:complexType name="barring-rule-info-type">
<xs:sequence>
<xs:element name="rule-id" type="xs:interger"/>
<xs:element name="rule-name" type="xs:string"/>
Avasarala & Jesske Expires May 26, 2011 [Page 18]
Internet-Draft SIP Communication Barring Notification November 2010
</xs:sequence>
</xs:complexType>
<!--
ORIGINATING USER SELECTION CRITERIA
-->
<xs:complexType name="user-selection-criteria-type">
<xs:sequence>
<xs:element name="user-info"
type="user-info-type" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!--
BARRING REASON SELECTION CRITERIA
-->
<xs:complexType name="barring-reason-selection-criteria-type">
<xs:sequence>
<xs:element name="barring-reason-info"
type="barring-reason-info-types"/>
</xs:sequence>
</xs:complexType>
<!--
TIME RANGE SELECTION CRITERIA
-->
<xs:complexType name="time-range-selection-criteria-type">
<xs:sequence>
<xs:element name="time-range"
type="time-range-type" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!--
TIME RANGE INFO
-->
<xs:complexType name="time-range-type">
<xs:sequence>
<xs:element name="start-time" type="xs:dateTime" />
<xs:element name="end-time" type="xs:dateTime" />
</xs:sequence>
</xs:complexType>
<!--
PRESENCE STATUS SELECTION CRITERIA
-->
<xs:complexType name="presence-status-selection-criteria-type">
<xs:sequence>
<xs:element name="presence-status-info"
type="presence-status-info-type" minOccurs="0"
maxOccurs="unbounded" />
Avasarala & Jesske Expires May 26, 2011 [Page 19]
Internet-Draft SIP Communication Barring Notification November 2010
</xs:sequence>
</xs:complexType>
<!--
PRESENCE STATUS INFO
-->
<xs:complexType name="presence-status-info-type">
<xs:sequence>
<xs:element name="presence-status" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:schema>
9. Security Considerations
Authentication and authorization of subscriptions have been discussed
in Section 6.6. Lack of authentication or authorization may provide
comm-barring-info information to unauthorized parties and can reveal
sensitive information with regards to the user's call receiving
patterns. For example, who calls the user and at what time, etc.
Integrity protection and confidentiality of notifications are also
discussed in Section 6.7. If a notifier does not encrypt bodies of
NOTIFY requests, an eavesdropper could learn the status of a SIP user
agent and use it to create malicious sessions. If the notifier does
not integrity protect the bodies of NOTIFY requests, a man-in- the-
middle attacker or malicious SIP proxy could modify the contents of
the comm-barring-info event package notification. Although this does
not cause harm, it can create annoyances.
10. IANA Considerations
This document registers the new SIP Event Package.
10.1. Communication Barring Information Event Package Registration
Package Name: Comm_barring-info
Type: Package
Contact: Jon Merdith, <John.meredith@3gpp.org>
Published Specification: RFC XXXX (Note to RFC Editor)
Avasarala & Jesske Expires May 26, 2011 [Page 20]
Internet-Draft SIP Communication Barring Notification November 2010
11. Acknowledgements
The authors would like to thank Samir Saklikar, Subir Saha, Ban Al-
Bakri, John Elwell, Paul Kyzivat and Mary Barnes for their useful
suggestions.
12. References
12.1. Normative References
[1] 3GPP, "Anonymous Communication Rejection (ACR) and Communication
Barring (CB) using IP Multimedia (IM) Core Network (CN)
subsystem; Protocol specification", 3GPP TS 24.611 8.2.0,
December 2008.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Peterson, J., Jennings, C., and R. Sparks, "Change Process for
the Session Initiation Protocol (SIP) and the Real-time
Applications and Infrastructure Area", BCP 67, RFC 5727,
March 2010.
[4] 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.
[5] 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia
Telephony Service and supplementary services; Stage 1", 3GPP
TS 22.173 10.2.0, March 2010.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
12.2. Informative References
[7] 3GPP, "IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol
(SDP); Stage 3", 3GPP TS 24.229 10.1.0, September 2010.
[8] Bray, T., Sperberg-McQueen, C., Paoli, J., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium FirstEdition REC-xml-20001006, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[9] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for
Avasarala & Jesske Expires May 26, 2011 [Page 21]
Internet-Draft SIP Communication Barring Notification November 2010
Expressing Privacy Preferences", RFC 4745, February 2007.
Appendix A. Change log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-avasarala-sipping-comm-barring-notification-00
o Moved from SIPPING to DISPATCH WG.
o Incorporated review comments.
o Re-submitting since -00 expired
Authors' Addresses
Ranjit Avasarala
Motorola Solutions India Pvt Ltd
Bagamane Tech Park, C V Raman Nagar
Bangalore 560093
India
Email: ranjit@motorolasolutions.com
Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt 64307
Germany
Email: r.jesske@telekom.de
Avasarala & Jesske Expires May 26, 2011 [Page 22]