DISPATCH R. Avasarala, Ed.
Internet-Draft Motorola Solutions Inc
Intended status: Informational J. Bakker
Expires: August 13, 2011 Research in Motion Corporation
February 9, 2011
A Session Initiation Protocol (SIP) Event Package for Communication
Diversion Information in support of the Communication Diversion (CDIV)
Notification (CDIVN) CDIV service
draft-avasarala-dispatch-comm-div-notification-06.txt
Abstract
3GPP and TISPAN are defining the protocol specification for the
Communication Diversion (CDIV) service using IP Multimedia (IM) Core
Network (CN) subsystem supplementary service. As part of CDIV, a SIP
based Event package framework is used for notifying users about
diversions (re-directions or forwarding) 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 CDIV 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 August 13, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Avasarala & Bakker Expires August 13, 2011 [Page 1]
Internet-Draft SIP Communication Diversion Notification February 2011
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 & Bakker Expires August 13, 2011 [Page 2]
Internet-Draft SIP Communication Diversion Notification February 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Abbreviations and Definitions . . . . . . . . . . . . . . . . 6
4.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Package Definition . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 7
6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7
6.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 7
6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 8
6.5. Notify bodies . . . . . . . . . . . . . . . . . . . . . . 8
6.6. Notifier Processing of SUBSCRIBE requests . . . . . . . . 8
6.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 9
6.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 9
6.7. Notifier Generation of NOTIFY requests . . . . . . . . . . 9
6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 10
6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 11
6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 11
6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 11
7. Comm-div-info Document . . . . . . . . . . . . . . . . . . . . 11
8. Structure of Comm-div-info Format . . . . . . . . . . . . . . 11
8.1. Comm-div-info Element . . . . . . . . . . . . . . . . . . 12
8.1.1. comm-div-subs-info Element . . . . . . . . . . . . . . 12
8.1.2. Comm-div-ntfy-info Element . . . . . . . . . . . . . . 15
8.1.3. Comm-div-info-selection-criteria . . . . . . . . . . . 16
8.2. Sample comm-div-info subscription and notification body . 17
8.2.1. Instance of communication diversion subscription
filter document . . . . . . . . . . . . . . . . . . . 18
8.2.2. Instance of communication diversion notification
document . . . . . . . . . . . . . . . . . . . . . . . 19
8.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Communication Diversion Information Event Package
Registration . . . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Avasarala & Bakker Expires August 13, 2011 [Page 3]
Internet-Draft SIP Communication Diversion Notification February 2011
1. Introduction
3GPP is currently maintaining and specifying communication diversion
mechanisms which allow users to forward and/or redirect incoming
communications to other destinations. 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 Communication Forward On Busy (CFB) where in users can
forward any incoming calls, whilst they are busy on some other call,
to their voice mail or a suitable alternative (e.g. some other user).
Similarly other variants of communication diversion are well defined
and used in practice such as Communication Forward on No Answer
(CFNA), Communication Forward Unconditional (CFU). Similarly 3GPP is
currently maintaining and specifying a mechanism for Users to
configure Communication Diversion Services ([1] and [2]) for their
incoming communications. The intention of such mechanisms is to
provide Users with sufficient flexibility to manage their incoming
communications in a better way
However, with the increasing usage of Communication Diversion
services, users may have many different variants and configurations
active at the same time. For instance, a user may have various CFU
services configured differently based on the time-of-the-day and the
Calling party's identity, or CFB based on the time-of-the-day. This
is possible by having various such configured diversions by
subscribing to different Communication Diversion (CDIV) services as
specified by 3GPP. Though, there has been quite active work in the
area of better customization and configuration of such Communication
Diversion mechanisms, not much attention has been paid to how the
Users can manage these services in an effective manner. With the
various advanced options and high flexibility provided, it is
possible that the user loses track of the various Communication
Diversion configurations or services they have registered for
One of the basic ways, by which a user can manage a CDIV service is
to be informed of which services they have registered for. For
example, [1] and [2] allow for such indications to be received by the
subscriber, at the time of initiating an outgoing call. However,
simply showing the registered services is not sufficient, since each
service may be customized in numerous and different ways for
different criteria. For example various instantiations of CFB may be
configured for different times-of-the-day and different calling party
identities. Even if subscribers are shown information about all the
Communication Diversion services and their variants that they are
registered for, they may not be able to make sense or verify that
each of them is correct as per their expectation. Such a mismatch in
terms of service behavior expectation and actual execution, may
happen due to incorrect configuration on behalf of the User, which
Avasarala & Bakker Expires August 13, 2011 [Page 4]
Internet-Draft SIP Communication Diversion Notification February 2011
cannot be easily detected if there are various communication
diversion services and their different configurations for handling
incoming connections.
A probable and suitable instance, when the subscriber may easily
judge whether a communication diversion is correct, is when it
actually takes place. The subscriber is already aware of the current
conditions (time-of-day, current presence and availability etc) and
hence is in a position to decide, whether the communication diversion
which just occurred, was indeed as per their expectation. For e.g.
the subscriber wanted to divert all incoming calls to voice-mail,
between 3.00 p.m. to 4.00 p.m. Yet, by mistake she configures the
time-duration as 3.00 to 4.00 p.m. It would be very difficult for
her to spot this error while manually reviewing her complete set of
communication diversion services, with their various configurations.
Instead, if the subscriber receives a real-time notification of any
communication diversion occurring after 4 p.m., she would be able to
immediately guess that something is 'wrong' or not as per her
intention and take corrective action. Such corrective action could
be manual verification of the specific rule which triggered the
communication diversion, wherein she will be able to spot the
"mistake" more easily.
Thus, for effective subscriber services management of multiple
configurations of various Communication Diversion services, a
notification-based mechanism may work well. Such a mechanism would
involve notifying subscribers about diversions of their incoming
communications, as and when the communication diversion happens or
with a slight delay (as per subscriber service configuration). As
such diversion-related information is conveyed almost instantly or
within a small time-frame, the subscribers can verify whether the
particular communication diversion is indeed correct at that instant
of time.
This document defines a SIP event package that allows a SIP User
Agents to subscribe to and be notified of communication diversions
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 [1] and
indicate requirement levels for compliant implementations.
Avasarala & Bakker Expires August 13, 2011 [Page 5]
Internet-Draft SIP Communication Diversion Notification February 2011
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 CDIV service in IMS core networks. The aim of
this memo is to follow the procedure indicated in RFC 5727. [2] and
to register a new event package with event name "comm-div-info" with
IANA.
4. Abbreviations and Definitions
4.1. Abbreviations
CDIV: Communication Diversion.
CDIVN: Communication Diversion Notification.
TISPAN: Telecommunications and Internet Converged Services and
Protocols for Advanced Networking.
4.2. Definitions
Subscriber - The User Agent who has subscribed to the
Communication diversion notification service.
User - Another term for the subscriber.
Diverting User - The User Agent who has configured a Communication
Diversion. This could be the User Agent who has configured the
Communication DIversion service rules in the network.
Diverted-To Entity/User - The User Agent who is the new target of
the incoming communication, post execution of any configured
Communication Diversion service.
Originating User - The User Agent who is the originator of the
incoming communication, which was initially targeted towards the
Diverting User, but finally sent to the Diverted-To User. 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 [10] and not the general SIP network as
defined in [3].
Avasarala & Bakker Expires August 13, 2011 [Page 6]
Internet-Draft SIP Communication Diversion Notification February 2011
5. Requirements
The Communication Diversion Notification (CDIVN) service enables a
user to receive notification about the diversion 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
CDIVN service developed by 3GPP and TIPSAN is found in [4] and [5]
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.
The name of this package is "comm-div-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-div-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 Diversion event MAY contain a body.
The purpose of the body depends on its type. Subscriptions to the
Comm-div-info event package SHALL only include a body of MIME type
"application/comm-div-info+xml".
A body of the SUBSCRIBE request with content type set to MIME type
"application/comm-div-info+xml" contains information about the
communication diversion 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 [11].
The subscriber SHALL also verify that the information contained in
the XML document contains elements defined in Section Section 8.1.1
only.
Avasarala & Bakker Expires August 13, 2011 [Page 7]
Internet-Draft SIP Communication Diversion Notification February 2011
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 diversion information pertaining to the diversion that
occurred in the network on behalf of the subscriber. The format of
the communication diversion information is an XML document as per
elements defined in Section 8.1.2.
All subscribers and notifiers of the "comm-div-info" event package
MUST support the "application/comm-div-info+xml" data format
described in Section 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-div-info+xml" (assuming Event
header has a value of "comm-div-info"). If the Accept header field
is present, it MUST contain the value "application/comm-div-info+xml"
only.
6.6. Notifier Processing of SUBSCRIBE requests
The contents of a document containing comm-div-info information can
contain sensitive information that can reveal some privacy
information. Therefore, such comm-div-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-
div-info document containing filter criteria. If the filter criteria
is present and the Notifier supports it, then 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 diversions that
Avasarala & Bakker Expires August 13, 2011 [Page 8]
Internet-Draft SIP Communication Diversion Notification February 2011
occur on behalf of the user. The Notifier SHALL then compute the
state information as defined in Section 6.11 for the subscriber and
send a NOTIFY request to the subscriber.
NOTE: It could be possible that the state information be empty as
this is the first notification sent towards the subscriber in
response to the SUBSCRIBE request and no communication diversions
have occurred yet.
In case the Notifier does not support filter criteria, then it should
ignore it or send a suitable 4xx response. E.g. 415 response.
6.6.1. Authentication
Notifiers MUST authenticate all subscription requests. This
authentication can be done using any of the mechanisms defined in [3]
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
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-div-info" event package.
A notifier sends a NOTIFY request when a communication diversion 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 diversion, then the notifier just
increments the communication diversion count and does not send any
notification towards the subscriber.
Avasarala & Bakker Expires August 13, 2011 [Page 9]
Internet-Draft SIP Communication Diversion Notification February 2011
The body of the NOTIFY MUST be sent using the type "application/
comm-div-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-div-info+xml".
Notifiers could detect that a communication diversion was enacted on
behalf of the subscriber via a "History-Info" header field [7] value,
per [8] or [5], sent from an application server hosting the CDIV
service.
It is REQUIRED that the notifiers do maintain the history of last N
communication diversions that occurred, where the value N >=1 as part
of state information for that server and include it in the
communication diversion notification information sent to the user. in
addition to this it is also REQUIRED that the notifiers maintain the
list of last M communication diversion notifications sent to the
user, where M equal to or less than N. M equals N if notifications
are sent for all communication diversions that occurred. The value M
is decremented whenever a communication diversion 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. As a server policy, the values of N and
M SHOULD be reset to 0 after reaching the maximum configured value to
avoid overflows
The state information is retained even after the notification for
those diversions are sent to the subscriber and changes when new
diversion occurs and whenever a notification is sent. So every time
a new diversion occurs and a notification is sent, the state
information changes to reflect the latest communication diversion
information sent, removing the oldest diversion information.
The Notifier MAY choose not to send NOTIFY to the subscriber if the
computed state information is same as the previously stored. This is
left to server policy.
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-div-info
document
Avasarala & Bakker Expires August 13, 2011 [Page 10]
Internet-Draft SIP Communication Diversion Notification February 2011
6.9. Handling of Forked Requests
The SIP Events specification requires each package to describe
handling of forked Requests.
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-div-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 state. They store the number of last N
communication diversions received and the number (M) of communication
diversion notifications sent. The notifier can detect a
communication diversion by inspecting the history information in SIP
request .
Thus at any point of time a subscriber MAY know the state of
communication diversions enacted on his or her behalf and number of
notifications sent by the notifier .
7. Comm-div-info Document
Comm-div-info document is an XML document [11] that MUST be well-
formed and SHOULD be valid. Communication Diversion Information
documents MUST be based on XML 1.0 and MUST be encoded using UTF-8
[12].
8. Structure of Comm-div-info Format
A Communications Diversion Information document starts with a "comm-
div-info" element. The comm-div-info element has a series of
elements describing the particular communication diversion or the
filter criteria for receiving the communication diversion
information.
Avasarala & Bakker Expires August 13, 2011 [Page 11]
Internet-Draft SIP Communication Diversion Notification February 2011
8.1. Comm-div-info Element
The comm-div-info element gives information about the specific
communication diversion or it could give information about a
particular selection criteria for the user receiving the
communication diversion information.
8.1.1. comm-div-subs-info Element
The comm-div-subs-info element is used by the subscribing user to
specify the communication diversion information selection criteria
and the communication diversion notification trigger criteria. It
contains the following elements:
8.1.1.1. comm-div-selection-criteria
This element contains information about communication diversion
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 diversion of this specific communication would
be selected for notification to the Diverting user. 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".
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
Avasarala & Bakker Expires August 13, 2011 [Page 12]
Internet-Draft SIP Communication Diversion Notification February 2011
8.1.1.1.2. diversion-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 diversions 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 diversions which took
place in that time-interval.
NOTE: If the time-range element is not specified, then notifications
about every communication diversion 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. diverting-user-selection-criteria
This element gives details of diverting user. This element could
contain the value present in P-Called-Party-ID header field and by
including the identity in the "diverting-user-info", the receiving UE
would know if the call was diverted because a rule associated with
e.g. the "work" public user identities was triggered. The URI
specified over here will be compared with the Request URI of the
diverting user for whom a communication has been diverted. Only if
there is a match, then information about the diversion of this
specific communication would be selected for notification to the
diverting user. This is an optional parameter. If absent, then
communication diversions towards all registered contacts of the
subscribing user would be considered for notification, subject to
other filter criteria. This element consists of sub-elements defined
for "user-info" element Section 8.1.1.1.1.1.1
8.1.1.1.4. diverted-to-user-selection-criteria
This element gives details of the final target of the communication,
the divered-to user. The URI specified in the Request URI of the new
Avasarala & Bakker Expires August 13, 2011 [Page 13]
Internet-Draft SIP Communication Diversion Notification February 2011
request is compared with the specified diverted-to URI. Only if
there is a match, then information about the diversion of this
specific communication would be selected for notification to the
Diverting user. This element consists of sub-elements defined for
"user-info" element Section 8.1.1.1.1.1.1.
8.1.1.1.5. diversion-reason-selection-criteria
This element contains the reason for communication diversion. It
contains following sub-element:
8.1.1.1.5.1. diversion-reason-info
This element gives the actual reason for the communication diversion.
E.g. "Call Forward on Busy".
8.1.1.1.6. number-of-diversions-selection-criteria
This element contains the total number of diversions that occurred in
network on behalf of the user till then.
8.1.1.1.7. number-of-notifications-selection-criteria
This element contains the total number of communication diversion
notifications sent by the network to user till then.
8.1.1.2. comm-div-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 diversions.
Avasarala & Bakker Expires August 13, 2011 [Page 14]
Internet-Draft SIP Communication Diversion Notification February 2011
8.1.1.2.3. notification-buffer-interval
This element specifies an optional element (in seconds) to overwrite
the CDIVN Buffer Timer for which the CDIVN Application Server should
store the CDIV Notification, if it cannot be delivered to the
subscriber, For example this would be required for buffering the
notifications, if the user is logged out and the diversion is
triggered due to CFNL/CFNRc, resulting in CDIVN for that diversion.
The user may set Notification Buffer Interval value in seconds to a
maximum value of 1 day. Also, if not configured by the user, the
default value of 1 day (as configured by the network provider) is
applicable.
8.1.2. Comm-div-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. diverting-user-info
This element gives details of the diverting user. This is an
optional element and would be present only if the subscriber has
requested it. If absent, it is assumed that the diversion occurred
at one of the registered contacts.
8.1.2.3. diverted-to-user-info
This element gives details of the final target of the communication
i.e the divered-to user. This element consists of sub-elements
defined for "user-info" element.
8.1.2.4. diversion-time-info
This element gives the time of communication diversion. Its value is
expressed in YYYY:MM:DDTHH:MM:SS format.
8.1.2.5. diversion-reason-info
This element contains an integer value and gives the actual reason
for the communication diversion. The integer value of the element is
mapped to the causes defined in [9]. Specifically, the integer value
is derived from the cause-param parameter in the History-info header
field. The subscriber converts the integer value of the element into
a localized diversion reason according to locale settings (i.e.
Avasarala & Bakker Expires August 13, 2011 [Page 15]
Internet-Draft SIP Communication Diversion Notification February 2011
preferred language)..
8.1.2.6. num-diversions
This element gives the number of communication diversions that
occurred in the network on behalf of the user till date.
8.1.2.7. num-notifications
This element gives the number of communication diversion
notifications sent till date to the user.
8.1.3. Comm-div-info-selection-criteria
This element gives the subscriber various to select communication
diversion 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-diverting-user-info
This element gives the subscriber option of adding diverting-user
information to the notification information. The default value is
false which means the subscriber wants the diverting-user-info
element to be present in the notification information.
8.1.3.3. disable-diverted-to-user-info
This element gives the subscriber option of adding diverting-to-user
information to the notification information. The default value is
false which means the subscriber wants the diverted-to-user-info
element to be present in the notification information.
8.1.3.4. disable-diversion-time-info
This element gives the subscriber option of adding diversion-time
information to the notification information. The default value is
false which means the subscriber wants the diversion-time-info to be
present in the notification information.
Avasarala & Bakker Expires August 13, 2011 [Page 16]
Internet-Draft SIP Communication Diversion Notification February 2011
8.1.3.5. disable-diversion-reason
This element gives the subscriber option of adding diversion-reason
information to the notification information. The default value is
false which means the subscriber wants the diversion-reason
information to be present in the notification information.
8.1.3.6. disable-diversion-rule
This element gives the subscriber option of adding diversion-rule
information to the notification information. The default value is
false which means the subscriber wants the diversion-rule information
to be present in the notification information.
8.1.3.7. disable-number-of-diversions
This element gives the subscriber option of adding number of
diversions that occurred till date to the notification information.
The default value is false which means the subscriber wants the
number of diversions that occurred till date information to be
present in the notification information
8.1.3.8. disable-number-of-notifications
This element gives the subscriber option of adding number of
communication diversion 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 comm-div-info subscription and notification body
Avasarala & Bakker Expires August 13, 2011 [Page 17]
Internet-Draft SIP Communication Diversion Notification February 2011
8.2.1. Instance of communication diversion subscription filter document
<comm-div-info>
<comm-div-subs-info>
<comm-div-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>
<diversion-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>
</diversion-time-selection-criteria>
<diversion-reason-selection-criteria>
<diversion-reason-info>404</diversion-reason-info>
</diversion-reason-selection-criteria>
</comm-div-selection-criteria>
<comm-div-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-div-ntfy-trigger-criteria>
</comm-div-subs-info>
</comm-div-info>
Avasarala & Bakker Expires August 13, 2011 [Page 18]
Internet-Draft SIP Communication Diversion Notification February 2011
8.2.2. Instance of communication diversion notification document
<comm-div-info>
<comm-div-ntfy-info>
<originating-user-info>
<user-name>Boss</user-name>
<user-URI>sip:boss@office.com</user-URI>
</originating-user-info>
<diverting-user-info>
sip:alice@office.com
</diverting-user-info>
<diverted-to-user-info>
sip:bob@office.com
</diverted-to-user-info>
<diversion-time-info>1999-06-01T13:20:00-05:00Z
</diversion-time-info>
<diversion-reason-info>404</diversion-reason-info>
<num-diversions>1</num-diversions>
<num-notifications>1</num-notifications>
</comm-div-ntfy-info>
</comm-div-info>
8.3. Schema
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:comm-div-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema
xmlns:tns="urn:ietf:params:xml:ns:comm-div-info
xmlns="http://uri.etsi.org/ngn/params/xml/comm-div-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 Diversion Information. This is the top-level XML element
-->
<xs:element name="comm-div-info"
type="comm-div-info-type" />
<!--
Communication Diversion Information Type.
This is the top-level XML element
Avasarala & Bakker Expires August 13, 2011 [Page 19]
Internet-Draft SIP Communication Diversion Notification February 2011
-->
<xs:complexType name="comm-div-info-type">
<xs:sequence>
<xs:element name="comm-div-subs-info"
type="comm-div-subs-info-type" minOccurs="0" />
<xs:element name="comm-div-ntfy-info"
type="comm-div-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 Diversion Subscription Type.
Used at Subscription time to
select Communication Diversions for notification,
when to notify them and
what to notify.
-->
<xs:complexType name="comm-div-subs-info-type">
<xs:sequence>
<xs:element name="comm-div-selection-criteria"
type="comm-div-selection-criteria-type"
minOccurs="0" />
<xs:element name="comm-div-ntfy-trigger-criteria"
type="comm-div-ntfy-trigger-criteria-type"
minOccurs="0" />
<xs:element name="comm-div-info-selection-criteria"
type="comm-div-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 Diversion Notification Information Type
Used while notifying the User about the Communication Diversion
-->
<xs:complexType name="comm-div-ntfy-info-type">
<xs:sequence>
<xs:element name="originating-user-info"
type="user-info-type" minOccurs="0" />
<xs:element name="diverting-user-info" use="optional"
type="xs:anyURI" minOccurs="0" />
<xs:element name="diverted-to-user-info"
type="xs:anyURI" minOccurs="0" />
Avasarala & Bakker Expires August 13, 2011 [Page 20]
Internet-Draft SIP Communication Diversion Notification February 2011
<xs:element name="diversion-time-info"
type="xs:dateTime" minOccurs="0" />
<xs:element name="diversion-reason-info"
type="diversion-reason-info-type" minOccurs="0" />
<xs:element name="diversion-rule-info"
type="diversion-rule-info-type" minOccurs="0" />
<xs:element name="num-diversions" use="optional"
type="xs:interger" minOccurs="0" />
<xs:element name="num-notifications" use="optional"
type="xs:integer" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
COMMUNICATION DIVERSION SELECTION CRITERIA
-->
<xs:complexType name="comm-div-selection-criteria-type">
<xs:sequence>
<xs:element name="originating-user-selection-criteria"
type="user-selection-criteria-type" minOccurs="0" />
<xs:element name="diverting-user-selection-criteria"
type="xs:anyURI" minOccurs="0" />
<xs:element name="diverted-to-user-selection-criteria"
type="xs:anyURI" minOccurs="0" />
<xs:element name="diversion-time-selection-criteria"
type="time-range-selection-criteria-type"
minOccurs="0" />
<xs:element name="diversion-reason-selection-criteria"
type="diversion-reason-selection-criteria-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
COMMUNICATION DIVERSION NOTIFICATION TRIGGER CRITERIA
-->
<xs:complexType name="comm-div-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">
Avasarala & Bakker Expires August 13, 2011 [Page 21]
Internet-Draft SIP Communication Diversion Notification February 2011
<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 DIVERSION INFORMATION SELECTION CRITERIA
-->
<xs:complexType name="comm-div-info-selection-criteria-type">
<xs:sequence>
<xs:element name="disable-originating-user-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-diverting-user-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-diverted-to-user-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-diversion-time-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-diversion-reason-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-diversion-rule-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-number-of-diversions"
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>
<!--
DIVERSION REASON INFO
-->
Avasarala & Bakker Expires August 13, 2011 [Page 22]
Internet-Draft SIP Communication Diversion Notification February 2011
<xs:simpleType name="diversion-reason-info-types">
<xs:list itemType="diversion-reason-info-type"/>
</xs:simpleType>
<xs:simpleType name="diversion-reason-info-type">
<xs:restriction base="xs:integer">
<xs:enumeration value="404"/>
<xs:enumeration value="486"/>
<xs:enumeration value="408"/>
<xs:enumeration value="302"/>
<xs:enumeration value="487"/>
<xs:enumeration value="480"/>
<xs:enumeration value="503"/>
</xs:restriction>
</xs:simpleType>
<!--
DIVERSION RULE INFO
-->
<xs:complexType name="diversion-rule-info-type">
<xs:sequence>
<xs:element name="diversion-rule" type="xs:string"/>
</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>
<!--
DIVERSION REASON SELECTION CRITERIA
-->
<xs:complexType name="diversion-reason-selection-criteria-type">
<xs:sequence>
<xs:element name="diversion-reason-info"
type="diversion-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"
Avasarala & Bakker Expires August 13, 2011 [Page 23]
Internet-Draft SIP Communication Diversion Notification February 2011
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" />
</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-div-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
Avasarala & Bakker Expires August 13, 2011 [Page 24]
Internet-Draft SIP Communication Diversion Notification February 2011
the comm-div-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 Diversion Information Event Package Registration
Package Name: Comm-div-info
Type: Package
Contact: Jon Merdith, <John.meredith@3gpp.org>
Published Specification: RFC XXXX (Note to RFC Editor)
11. Acknowledgements
The authors would like to thank Samir Saklikar and Subir Saha for
being part of the initial versions of the draft and Ban Al-Bakri,
Roland Jesske, Jose Miguel Torres, Paul Kyzivat, John Elwell , Keith
Drage , Gonzalo Camarillo and Dean Willis for their valuable comments
and suggestions.
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] 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.
[4] 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia
Telephony Service and supplementary services; Stage 1", 3GPP
Avasarala & Bakker Expires August 13, 2011 [Page 25]
Internet-Draft SIP Communication Diversion Notification February 2011
TS 22.173 10.2.0, March 2010.
[5] 3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM)
Core Network (CN) subsystem; Protocol specification", 3GPP
TS 24.604 10.0.0, December 2010.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[7] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244,
November 2005.
[8] 3GPP, "TISPAN; PSTN/ISDN simulation services: Communication
Diversion (CDIV); Protocol specification", 3GPP TS 24.404
7.5.0, June 2009.
[9] Jennings, C., Audet, F., and J. Elwell, "Session Initiation
Protocol (SIP) URIs for Applications such as Voicemail and
Interactive Voice Response (IVR)", RFC 4458, April 2006.
12.2. Informative References
[10] 3GPP, "IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol
(SDP); Stage 3", 3GPP TS 24.229 10.2.0, December 2010.
[11] Paoli, J., Sperberg-McQueen, C., Bray, T., 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>.
[12] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007.
Appendix A. Change log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-avasarala-dispatch-comm-div-notification-05
o Updated Requirements section
Avasarala & Bakker Expires August 13, 2011 [Page 26]
Internet-Draft SIP Communication Diversion Notification February 2011
o Incorporated expert review comments for state information,
notification content and subscribe bodies
o Modified the section on examples for subscription and notification
body
Changes from draft-avasarala-dispatch-comm-div-notification-04
o Incorporated review comments
o Added text for SUBSCRIBE body and NOTIFY body and checking of
filter criteria.
o Updated Communication Diversion Notification Information document
and XML schema to add Diversion and notification count information
as optional parameters.
Changes from draft-avasarala-dispatch-comm-div-notification-03
o Added State information to Notifiers.
o Modified diverting-URI definition and element in communication
diversion information selection criteria as optional parameter .
Changes from draft-avasarala-dispatch-comm-div-notification-02
o Modified the applicability statement to make it more IMS specific.
o Added a definition for IMS Core network.
o Updated authors list and Acknowledgement sections.
Changes from draft-avasarala-dispatch-comm-div-notification-01
o Incorporated review comments.
o Modified contact details for co author Subir Saha.
Changes from draft-avasarala-sipping-comm-div-notification-00
o Changed contact details of co author Subir Saha.
o Moved from SIPPING to DISPATCH WG.
Changes from draft-avasarala-dispatch-comm-div-notification-00
o Added comm-div-info document structure information and schema for
the event package.
Avasarala & Bakker Expires August 13, 2011 [Page 27]
Internet-Draft SIP Communication Diversion Notification February 2011
o Added more elaborate description for various sections in comm-div-
info document
Authors' Addresses
Ranjit Avasarala (editor)
Motorola Solutions India Pvt Ltd
Bagamane Tech Park, C V Raman Nagar
Bangalore 560093
India
Email: ranjit@motorolasolutions.com
John Luc Bakker
Research in Motion
5000 Riverside Drive, Building 6, Suite 100
Irving, Texas 75039
USA
Email: jbakker@rim.com
Avasarala & Bakker Expires August 13, 2011 [Page 28]