SIPPING S. Saklikar
Internet-Draft S. Saha
Intended status: Informational R. Avasarala
Expires: March 15, 2009 Motorola
September 11, 2008
A Session Initiation Protocol (SIP) Event Package for Communication
Diversion Information
draft-saklikar-comm-diversion-notification-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 15, 2009.
Abstract
This draft defines a Session Initiation Protocol (SIP) Event
Notification Framework-based mechanism for notifying Users about
diversions (re-directions or forwarding) of their incoming
communication sessions. A new event package is proposed for allowing
users to subscribe for and receive such notifications. Users have
further capability to define filters controlling the selection, rate
and content of such notifications. The applicability of this event
package includes 3GPP IMS.
Saklikar, et al. Expires March 15, 2009 [Page 1]
Internet-Draft SIP Communication Diversion Notification September 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations and Definitions . . . . . . . . . . . . . . . . 6
3.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
4. Communication Diversion Notification framework . . . . . . . . 6
4.1. Communication Diversion Information . . . . . . . . . . . 8
4.2. Communication Diversion Selection Criteria . . . . . . . . 8
4.3. Communication Diversion Notification Trigger Criteria . . 9
5. Communication Diversion Information Event Package . . . . . . 9
5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 9
5.2. Event Package Parameters . . . . . . . . . . . . . . . . . 9
5.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 10
5.3.1. Selection of Communication Diversions for
notification . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. Triggering notification of selected Communication
Diversions . . . . . . . . . . . . . . . . . . . . . . 12
5.3.3. Selecting Communication Diversion Information to
be notified . . . . . . . . . . . . . . . . . . . . . 12
5.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13
5.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 14
5.6.1. Verifying Subscribing UE's Authorization . . . . . . . 15
5.6.2. Verifying Diverting User Identity registration for
Communication Diversion services . . . . . . . . . . . 16
5.6.3. Validation of parameters within the SUBSCRIBE
message body . . . . . . . . . . . . . . . . . . . . . 16
5.7. Notifier generation of NOTIFY requests . . . . . . . . . . 16
5.8. Subscriber processing of NOTIFY requests . . . . . . . . . 17
5.9. Rate of notifications . . . . . . . . . . . . . . . . . . 17
6. Communication Diversion Information . . . . . . . . . . . . . 17
6.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Structure of Communication Diversion Information . . . . . 18
6.3. Communication Diversion Subscription Information . . . . . 18
6.3.1. Selecting Communication Diversions . . . . . . . . . . 19
6.3.2. Triggering Communication Diversions . . . . . . . . . 20
6.3.3. Selecting Communication Diversion Information . . . . 22
6.4. Communication Diversion Notification Information . . . . . 22
6.4.1. originating-user-info . . . . . . . . . . . . . . . . 23
6.4.2. diverting-user-info . . . . . . . . . . . . . . . . . 23
6.4.3. diverted-to-user-info . . . . . . . . . . . . . . . . 23
6.4.4. diversion-time-info . . . . . . . . . . . . . . . . . 23
6.4.5. diversion-reason-info . . . . . . . . . . . . . . . . 23
6.4.6. diversion-rule-info . . . . . . . . . . . . . . . . . 23
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Saklikar, et al. Expires March 15, 2009 [Page 2]
Internet-Draft SIP Communication Diversion Notification September 2008
8.1. Time-based trigger for notification of all Information
about selected Communication Diversions . . . . . . . . . 29
8.1.1. Use-case . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.2. Configuring the Communication Diversion Service . . . 29
8.1.3. Subscribing to Communication Diversion Information
Notification . . . . . . . . . . . . . . . . . . . . . 30
8.1.4. Call Flow . . . . . . . . . . . . . . . . . . . . . . 31
8.1.5. Notification of Communication Diversion Information . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
10.1. Communication Diversion Information Event package
registration . . . . . . . . . . . . . . . . . . . . . . . 34
10.2. application/comm-div-info+xml MIME Registration . . . . . 35
10.3. URN Sub-Namespace Registration for
urn:3gpp:params:xml:ns:comm-div-info . . . . . . . . . . . 35
10.4. XML Schema Registration . . . . . . . . . . . . . . . . . 36
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 39
Saklikar, et al. Expires March 15, 2009 [Page 3]
Internet-Draft SIP Communication Diversion Notification September 2008
1. Introduction
Communication Diversion mechanisms allow Users to forward and/or
redirect incoming communications to other destinations. The most
common example is Communication Forward on Busy (CFB) wherein users
can forward any incoming calls, whilst they are busy on some other
call, to their voice mail or a suitable alternative (for 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) etc.
Using Call Processing Language (CPL) [5], users can specify various
time-based, language-based, caller's identity-based criteria for
diverting their incoming as well as outgoing communications.
Similarly, 3GPP is standardizing a mechanism for Users to configure
Communication Diversion Services ([1]) for their incoming
communications, as a part of it's work related to PSTN/ISDN
Simulation Services. 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 e.g. the 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 within the
User's CPL script or 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 users can manage a CDIV service, is
to be informed of which services they have registered for. For e.g.
[1] allows for such indications to be received by the user, 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 users 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 mis-match in terms of
Saklikar, et al. Expires March 15, 2009 [Page 4]
Internet-Draft SIP Communication Diversion Notification September 2008
service behaviour expectation and actual execution, may happen due to
incorrect configuration on behalf of the User, which cannot be easily
detected if there are various communication diversion services and
their different configurations for handling incoming communications.
A probable and suitable instance, when the User may easily judge
whether a communication diversion is correct, is when it actually
takes place. The User 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 User
wanted to diverted all incoming calls to voice-mail, between 3.00
p.m. to 4.00 p.m. Yet, by mistake she configures the time-duration
in the CPL script 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 User 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* much easily.
Thus, for effective user management of multiple configurations of
various Communication Diversion services, a notification-based
mechanism may work well. Such a mechanism would involve notifying
users about diversions of their incoming communications, as and when
the communication diversion happens or with a slight delay (as per
User configuration). As such diversion-related information is
conveyed almost instantly or within a small time-frame, the Users can
verify whether the particular communication diversion is indeed
correct at that instant of time.
In this document, we describe a SIP Event Notification framework-
based mechanism of notifying users about their communication
diversions. We further describe, how users can control how they want
to receive such notifications, the content and rate of such
notifications.
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 [12]
and indicate requirement levels for compliant implementations.
Saklikar, et al. Expires March 15, 2009 [Page 5]
Internet-Draft SIP Communication Diversion Notification September 2008
3. Abbreviations and Definitions
3.1. Abbreviations
CDIV: Communication Diversion
CDIVN: Communication Diversion Notification
TISPAN: Telecommunications and Internet Converged Services and
Protocols for Advanced Networking
3.2. Definitions
Diverting User - The user who has configured a Communication
Diversion mechanism, either via subscription to a CDIV service or
configuration of a CPL script. This user is the original target
of the incoming communication, before it is diverted to another
destination. When not qualified, the term "user" should be
referred to as the Diverting User.
Diverted-To Entity/User - This User (or entity) is the new target
of the incoming communication, post execution of any configured
Communication Diversion service.
Originating User - This refers to 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 as the Caller.
4. Communication Diversion Notification framework
In this section, we describe the proposed mechanism for notification
of Communication Diversion information. As described earlier, the
intention is to enable Users to receive notification of information
about diversions of their incoming communications. Such capability
would enable the Users to take a judicious decision, with regards to
whether such diversions are indeed correct as per expectations at
that instance.The following call-flow describes a high-level usage of
the Communication Diversion Notification mechanism.
The Communication Diversion Application Server (CDIV-AS) may be
viewed as a CPL processing engine or any of the 3GPP CDIV Services.
In this document, a Communication Diversion Notification Server
(CDIVN-S) role is proposed, which will handle processing User
subscription to the Communication Diversion Notification feature as
well as generating the relevant User notifications. It must be noted
that the CDIVN-S role is logical and may be merged with the CDIV-AS.
Saklikar, et al. Expires March 15, 2009 [Page 6]
Internet-Draft SIP Communication Diversion Notification September 2008
However, if deployed differently, they would need an appropriate
protocol for carrying the Communication Diversion information between
them. Though potentially useful, this document does not attempt to
cover this path of Communication Diversion information flow.
As shown in the figure, User-1 has configured for Call Forwarding
Unconditional (CFU) towards User-2, at the CDIV Application Server
(AS). When the User-1 receives an incoming communication from a
Calling Party, then it is re-directed towards User-2 by the CDIV-AS
as per the CFU configured by the User. This communication diversion
information is sent towards the CDIVN-S which then makes a decision
to notify the information towards the User, based on User
subscription options.
User1 CDIV-AS CDIVN-S User2 Caller
| | | | |
|(1) Enable CFU to User2 | |
|-------->| | | |
|(2) Ok | | | |
|<--------| | | |
|(3) Subscribe to Communication Diversion Notification
|------------------>| | |
|(4) Success | | |
|<------------------| | |
| |(5) Session Invite to User1@example.com
| |<----------------------------|
| |(6) CDIV AS executes Diversion for User1
| |(7) Session Invite from Caller@example.com
| |------------------>| |
| | | |(8) Call Established
| | | |.........|
| |(9) Inform about Comm Diversion
| |-------->| | |
|(10) Notification of Communication Diversion Information
|<------------------| | |
|(11) Success | | |
|------------------>| | |
|(12) User can verify correctness of Communication Diversion
| | | | |
The intention of the Communication Diversion Notification framework
is to provide sufficient information to the Users, so as to enable
them to make a decision with regards to correctness of their
communication diversions. Hence, the framework must support the
ability to carry all the relevant information which can help Users in
Saklikar, et al. Expires March 15, 2009 [Page 7]
Internet-Draft SIP Communication Diversion Notification September 2008
making that decision. Also, the Users must be able to appropriately
configure the Notification procedure. This section lists the various
information types which must be supported in the Communication
Diversion Notification framework.
4.1. Communication Diversion Information
The User should have access to the following as part of the notified
Communication Diversion Information.
1. Information about the Originating Party.
2. URI of the Diverting Party
3. URI of the Diverted-To Party
4. Time of the Communication Diversion.
5. Reason for the Communication Diversion.
6. Identity of the rule which triggered the Communication Diversion.
4.2. Communication Diversion Selection Criteria
The User should also be able to set various criteria for selecting a
particular subset of communication diversions for notification. The
end result is better management for the User, as they can now focus
on only those specific communication diversions which may be
important in a given context. Selection of Communication Diversions
for notification must be based on the following criteria
1. Identity of the Originating Caller of Communication
2. Identity of the Diverting User Identity, for whom the incoming
communication was diverted
3. Identity of the Diverted-To User to whom the communication has
been diverted.
4. Time-Range of the Communication Diversion.
5. Reason for the Communication Diversion.
Saklikar, et al. Expires March 15, 2009 [Page 8]
Internet-Draft SIP Communication Diversion Notification September 2008
4.3. Communication Diversion Notification Trigger Criteria
It cannot be assumed that a User would be able to review any
communication diversion notifications, as and when the corresponding
communication diversion occurs. For e.g. the User could be busy at
that time, which was the reason in the first place for configuring
the Communication Diversion. Thus, the User should have the
flexibility for setting an appropriate criteria for receiving the
selected notifications. It is expected that the Communication
Diversions (which would be selected based on the above 'Communication
Diversion Selection Criteria') be notified when one or more of the
following criteria are met.
1. User specified time interval.
2. Presence-status of the Diverting User.
Further, if the Communication Diversion Information could not be
notified to the User (for e.g. due to the User being logged out, or
un-reachable), then there should be a mechanism to buffer the
notifications for a time-period configured by the User.
5. Communication Diversion Information Event Package
This section fills in the details needed to specify an event package
as defined in Section 4.4 of [3].
5.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". This package name is
carried in the Event and Allow-Events header as defined in [3].
Example:
Event:comm-div-info
5.2. Event Package Parameters
The SIP Events specification requires package and template-package
definitions to specify any package specific parameters of the Event
header that are used by it.
No package specific Event header parameters are defined for this
event package.
Saklikar, et al. Expires March 15, 2009 [Page 9]
Internet-Draft SIP Communication Diversion Notification September 2008
5.3. SUBSCRIBE Bodies
The SIP Events specification requires package or template-package
definitions to define the usage, if any, of bodies in SUBSCRIBE
requests.
The user MAY include a message body within the SIP SUBSCRIBE to
control the Communication Diversion Information subscription.
However, the message body is NOT mandatory and may be absent. If the
message body is completely absent, then it indicates that the User
has selected all information about all communication diversions to be
notified immediately, on execution of the Communication Diversion.
However, it is also possible that only some elements of the proposed
message body are used, in which case the default policies, as
mentioned further, would be applicable for the missing elements.
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".If the header field is present, it MUST include
"application/comm-div-info+xml".
If the User has specified a message body, then it acts as a filter to
control which communication diversions the User has selected for
notification, when they should be notified and what information about
them should be notified. More specifically, it serves to control the
following aspects of Communication Diversion Information
notification.
5.3.1. Selection of Communication Diversions for notification
The user would be able to select a specific subset of the overall
communication diversions for notification. This helps the user to
focus only on those communication diversions which may be important
(for e.g the User may be interested in only diversions of calls from
her boss). The User is able to set the following criteria for
selecting the communication diversions which have to be notified.
1. Identity of the Originating User (Caller) of Communication -
The identity specified over here will be compared with the
identity of the Originating Caller in the incoming communication.
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 parameter may contain regular
expressions, to allow the User to specify a range of identities
of the originating callers.
This is an optional parameter. If absent, then all diversions
for communications from any caller would be considered for
notification, subject to other filter criteria.
Saklikar, et al. Expires March 15, 2009 [Page 10]
Internet-Draft SIP Communication Diversion Notification September 2008
2. Identity of the Diverting User -
The identity specified over here will be compared with the
Request-URI of the Diverting User, for which the incoming
Communication has been diverted. Only if there is a match, then
information about this specific Communication Diversion would be
notified to the subscribing user.
This is an optional parameter. If absent, then Communication
Diversions towards the Identity of the subscribing user would be
considered for notification, subject to other filter criteria.
3. Identity of the Diverted-To User -
The identity specified over here will be compared with the
Request-URI of the Diverted-to User. Only if there is a match,
then information about this specific Communication Diversion
would be notified to the Diverting User. This parameter may
contain Regular expressions.
This is an optional parameter. If absent, then Communication
Diversions towards any diverted-to User would be considered for
notification, subject to other filter criteria.
4. Time-Range of the Communication Diversion -
This specifies a time-range, within which all Communication
Diversions would be notified to the subscribing User. If
present, then any communication diversion outside of this time-
range would NOT be notified.
This is an optional parameter. If absent, then Communication
Diversions happening at any time would be considered for
notification, subject to other filter criteria. A time zone
should be indicated. If a time-zone is not indicated the
SUBSCRIBE shall be rejected with a SIP 489.
5. Reason for the Communication Diversion.-
This parameter specifies that only those Communication
Diversions, which match the specified reason of diversion should
be selected for notification. This parameter is same as the
"cause-param" parameter which is added in the History Info header
as per Section 4.5.2.6.2.2 of [1]. Informative details of cause-
param are also defined in Annex C of [1].
This is an optional parameter. If absent, then all communication
diversions resulting due to any cause would be considered for
notification, subject to other filter criteria.
Saklikar, et al. Expires March 15, 2009 [Page 11]
Internet-Draft SIP Communication Diversion Notification September 2008
5.3.2. Triggering notification of selected Communication Diversions
As a part of the SUBSCRIBE message body, the User may specify further
criteria to trigger the notification of those communication
diversions, which were selected by the above mentioned criteria. The
User can trigger notification based on the following
1. Time-Range
This specifies a time at which notifications of communication
diversion are sent to the user. It may 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. If absent, it indicates that notifications are sent
immediately when the communication diversion takes place. A time
zone should be indicated. If a time zone is not indicated, the
SUBSCRIBE shall be rejected with a SIP 489.
2. Presence-status -
This specifies a presence state of the User, within which the
User expects to receive notifications about communication
diversions. If absent, it indicates that notifications are sent
immediately irrespective of user's availability information
3. Notification Buffer Interval -
This specifies an optional element (in seconds) to overwrite the
CDIVN Buffer Timer for which the CDIVN AS should store the CDIV
Notification, if it cannot be delivered to the user, as per the
criteria configured above. 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.
5.3.3. Selecting Communication Diversion Information to be notified
As a part of the SUBSCRIBE message body, the User may specify further
criteria to enable/disable which information about the communication
diversion should be notified. By default, ALL information about a
communication diversion (as described in Section 5.5 ) would be
notified. However, the user may use the following elements for
DISABLING a particular kind of information from being notified.
1. Information about the Originating Party.
2. URI of the Diverting party.
Saklikar, et al. Expires March 15, 2009 [Page 12]
Internet-Draft SIP Communication Diversion Notification September 2008
3. URI of the Diverted-To party.
4. Time of the Communication Diversion.
5. Reason for the Communication Diversion.
6. Identity of the rule which triggered the Communication Diversion.
5.4. Subscription Duration
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 subscription duration for this package defaults to the duration
of the User's subscription to the Communication Diversion Services
(either by uploading a CPL or subscribing to a CDIV service as
specified in [1]). If the User un-subscribes from the Communication
Diversion Service, then the user is also necessarily un-subscribed
from the Communication Diversion Information Event package described
in this document.
5.5. NOTIFY bodies
The SIP Events specification requires package definitions to describe
the allowed set of body types in NOTIFY requests, and to specify the
default value to be used when there is no Accept header in the
SUBSCRIBE request.
The body of a notification of communication diversion would contain
information about the communication diversion, as selected by the
various filter criteria configured by the User in the SUBSCRIBE
message body. If the SUBSCRIBE did not contain a message body, then
all possible information about the communication diversion is
notified to the User.
The notifications generated by the server MUST be in one of the
formats specified in the Accept header field in the SUBSCRIBE
request. The XML event package is sent as the body of the NOTIFY
method, would contain the following information (subject to the
filter criteria) selected by the User as explained in Section 5.3.3
1. Identity of the Originating User (Caller) of Communication -
This helps the Subscribing User to know the Calling User of the
communication which was diverted.
Saklikar, et al. Expires March 15, 2009 [Page 13]
Internet-Draft SIP Communication Diversion Notification September 2008
2. Identity of the Diverting User -
The Request-URI of the INVITE before the Communication Diversion
Service was executed for the Diverting User is informed to the
subscribing UE. This is required when the Subscribing entity is
different from the Diverting User Identity and/or has subscribed
for multiple Diverting User Identities. Herein, the Subscribing
UE would be interested to know for which specific Diverting User
Identity was the Communication Diversion triggered.
3. Identity of the Diverted-To User -
The Diverted-to User Identity, to whom the Communication is being
diverted can be informed to the Diverting User.
4. Time of the Communication Diversion -
The time of the Communication Diversion is informed to the
Diverting User. This helps the Subscribing User to identify and
verify if indeed the communication diversions were expected and
hence "correct" at those times. A time zone shall be indicated.
5. Reason for the Communication Diversion -
The Reason for this Communication Diversion is the same as the
cause-param which is added in the History-Info header (at the
highest History Index) field as defined in [6] and specified in
section 4.5.2.6.2.2 of [1]. This parameter describes the
Diversion Reason at this particular hop (in case there are
multiple hops due to multiple Communication Diversions) and helps
the Subscribing User to ascertain that indeed the Reason for
Diversion is as per their expectations.
6. Communication Diversion Rule -
This identifies the Communication Diversion Rule (as described in
Sec 4.9.1.2 of [1]) which was executed to result in the
communication diversion, which is being notified to the User. It
contains the 'id' attribute of Communication Diversion Rule
defined in [7].
5.6. Notifier processing of SUBSCRIBE requests
This section describes the processing to be performed by the notifier
upon receipt of a SUBSCRIBE request.
The Notifier processes the SUBSCRIBE request by performing the
following tasks
Saklikar, et al. Expires March 15, 2009 [Page 14]
Internet-Draft SIP Communication Diversion Notification September 2008
5.6.1. Verifying Subscribing UE's Authorization
The Notifier MUST verify that the Subscribing UE is authorised to
subscribe for the requested Communication Diversion Notification.
One check which the Notifier entity must perform is validating that
the Subscribing UE can subscribe for the specified Diverting User's
Communication Diversion notifications. There are two specific
scenarios possible
5.6.1.1. Subscribing UE Identity is same as the Diverting User
Identity.
Herein, it is the Diverting User who is subscribing for notifications
of diversions of communications which were originally targeted to
itself. It is RECOMMENDED that the Diverting User be allowed to
subscribe to their own Communication Diversion Information, without
the need for any additional authorization. This helps the User in
tracking, which are the communications which they have missed due to
diversions and take possible action towards verifying and correcting
the rules regarding these communications. Yet, allowing such
subscription would be based on the appropriate policies configured at
the Notifier.
5.6.1.2. Subscribing UE Identity is different from the Diverting User
Identity.
Herein, the Subscribing UE Identity is different from the Diverting
User Identity. Hence, there needs to be appropriate authorization
for the Subscribing UE to gain access to the Communication Diversion
Information of the Diverting User.
The Subscribing UE and the Diverting User Identity may belong to the
same human User. This allows the scenario wherein the User is
subscribing to their communication Diversion information but from
another of their devices or different identities. This has the
advantage that they can monitor the various communication Diversions
information from a particular device/identity of their choice.
However, it is up to the configuration of appropriate administrative
policies at the Notifier for permitting such subscriptions.
It is also possible, that the Subscribing UE and the Diverting User
Identity do not belong to the same human User. For e.g. some
application or automata can subscribe to the Communication Diversion
Information package for a particular User. As covered by the earlier
case, such application/automata may be running on any of the User's
devices registered to the same or different identities of the User.
As a special case, it is possible that the Application/automata is
running on some server and monitoring the User's communication
diversions on-behalf-of the user. Indeed, for these various
scenarios to work, appropriate authorization policies must be pre-
Saklikar, et al. Expires March 15, 2009 [Page 15]
Internet-Draft SIP Communication Diversion Notification September 2008
loaded at the Notifier.
5.6.2. Verifying Diverting User Identity registration for Communication
Diversion services
The Notifier MUST verify that the Diverting User Identity, as encoded
within the SUBSCRIBE message body is registered to at least one
Communication Diversion services.
5.6.3. Validation of parameters within the SUBSCRIBE message body
5.6.3.1. Validation of Time Zone Information
The Notifier MUST verify that any Time related parameters within the
SUBSCRIBE message body are qualified with appropriate Time Zone
parameter. If the Time Zone parameter is not indicated, then the
SUBSCRIBE must be rejected with the SIP 489 error code. Examples of
the Time-related parameters are the Time-Range for selection of
Communication Diversion and Time-Range for trigger the notification
of Communication Diversion.
5.6.3.2. Validation of time interval value for buffering Notifications
The Notifier MUST validate that the time interval configured by the
Subscribing UE for buffering Notifications is less than the default
value of 1 day (in seconds). If the value is not configured by the
User or configured for a value greater than 1 day, then the Notifier
will set the value to 1 day (86400 seconds).
5.7. Notifier generation of NOTIFY requests
This section of an event package describes the process by which the
notifier generates and sends a NOTIFY request.
The Notifier is a logical role played by the Communication Diversion
service provider. However, it can also be played by an entity which
has access to the communication diversions for the User.
When a Notifier receives indications about a diversion of an incoming
communication for the User, it refers to the appropriate filter
criteria (Section 5.3) for selecting the Communication Diversions to
be notified, as configured by the User at the time of subscription.
From this selected set of Communication Diversions, the Notifier
selects the information to be notified based on the filter criteria
configured by the Subscribing UE for Communication Diversion
Information selection. Finally, based on the Notification Trigger
criteria, the selected information would be notified to the
Subscribing UE, through the appropriate NOTIFY message body as
defined in Section 5.5.
Saklikar, et al. Expires March 15, 2009 [Page 16]
Internet-Draft SIP Communication Diversion Notification September 2008
In case, there are no configured filter criteria, then the default
action of notifying all Communication Diversion-related information
about all communication diversions to the User immediately, is
followed.
5.8. Subscriber processing of NOTIFY requests
The SIP Events framework expects packages to specify how a subscriber
processes NOTIFY requests in any package specific way and in
particular how it uses the NOTIFY requests.
The Subscribing UE on receiving the NOTIFY request (with the
communication diversion notification information) may trigger
suitable application logic for validating that the information about
Communication Diversions is indeed as per User expectation. For
example, this information may be rendered to the User. In case, the
information does not match User expectation, then the User may modify
the communication diversion rules by using the procedures outlined in
[2].
5.9. Rate of notifications
The SIP Events framework mandates that packages define a maximum rate
of notifications for their package.
This event package notifies about diversions of incoming
communications for the User and hence it is expected that there will
not be too many notifications. However, in case the User is under a
Denial of Service attack, with continuous incoming communication
requests for the user, the notification rate of communication
diversions information MAY be high. For reasons of congestion
control, it is important that the rate of notifications not become
excessive. As a result, it is RECOMMENDED that the Notifier not
generate notifications for a single subscriber at a rate faster than
once every 5 seconds.
6. Communication Diversion Information
Communication Diversion Information is an XML document [4] that MUST
be well-formed and SHOULD be valid. It MUST be based on XML 1.0 and
MUST be encoded using UTF-8.
6.1. Namespace
This specification makes use of XML namespaces for identifying
communication diversion notification information documents and
document fragments.The namespace URI for elements defined by this
Saklikar, et al. Expires March 15, 2009 [Page 17]
Internet-Draft SIP Communication Diversion Notification September 2008
specification is a URN using the namespace identifier '3gpp' defined
by [8]. This URN is:
urn:3gpp:params:xml:ns:comm-div-info
6.2. Structure of Communication Diversion Information
The Communication Diversion Information is described by a hierarchal
XML structure with the root element tag "comm-div-info".
The Communication Diversion Information serves two purposes viz. for
setting the filter criteria for selecting communication diversions
for notification at the time of subscription and the information
which is notified to the Subscribing Entity when the communication
diversion occurs. Thus, the structure of the Communication Diversion
Information can be split into two top-level categories as shown in
the following diagram.
comm-div-info
+
+------- comm-div-subs-info
|
+------- comm-div-ntfy-info
A Communication Diversion Information document begins with the root
element tag "comm-div-info".
6.3. Communication Diversion Subscription Information
As explained in Section 5.3, the message body within a SUBSCRIBE is
used for setting various filter criteria with regards to the
notification of communication diversion information. A Communication
Diversion Subscription Information element begins with the tag "comm-
div-subs-info" and includes the following three categories as
follows.
comm-div-subs-info
+
+------- comm-div-selection-criteria
|
+------- comm-div-ntfy-trigger-criteria
|
+------- comm-div-info-selection-criteria
Saklikar, et al. Expires March 15, 2009 [Page 18]
Internet-Draft SIP Communication Diversion Notification September 2008
6.3.1. Selecting Communication Diversions
As explained in Section 5.3.1, the message body within a SUBSCRIBE
can be used for selecting specific communication diversions, for
notification to the User. It consists of the following sub-elements
comm-div-selection-criteria
+
+------- originating-user-selection-criteria
|
+------- diverting-user-selection-criteria
|
+------- diverted-to-user-selection-criteria
|
+------- diversion-time-selection-criteria
|
+------- diversion-reason-selection-criteria
6.3.1.1. originating-user-selection-criteria
This element contains a list of originating-user-info elements. If
the incoming communication which was diverted was from an Originating
User who is present in this list, then this communication diversion
would be selected for notification. It has the following sub-
elements
List of user-info: Each element of this list is a user-info element,
which is defined as follows.
6.3.1.1.1. user-info
This is a generic element which contains information about a
particular User. In this document, it is used for describing
information about the Originating User (Caller) of the communication
which was diverted. It has the following attributes
user-name: Contains User Identity's display name.
user-URI: Contains User Identity's SIP URI.
6.3.1.2. diverting-user-selection-criteria
This element contains an address for the Diverting User. If the
incoming communication which was diverted, was originally targeted
towards this Diverting User, then this communication diversion would
be selected for notification.
Saklikar, et al. Expires March 15, 2009 [Page 19]
Internet-Draft SIP Communication Diversion Notification September 2008
6.3.1.3. diverted-to-user-selection-criteria
This element contains an address for the Diverted-to User. If the
incoming communication was diverted towards this Diverted-to User,
then this communication diversion would be selected for notification.
6.3.1.4. diversion-time-selection-criteria
This element contains a list of time-ranges. If the incoming
communication was diverted within one of the given time-ranges, then
this communication diversion would be selected for notification. It
has the following sub-elements
List of time-ranges: Each element of this list is a time-range
element, which is described in Section 6.3.2.1.1.
6.3.1.5. diversion-reason-selection-criteria
This element contains a list of diversion-reason-info elements. If
the incoming communication was diverted for a reason, which is
present in this list, then this communication diversion would be
selected for notification. It has the following sub-elements
List of diversion-reason-info: Each element of this list is a
diversion-reason-info element, which is described in
Section 6.4.5.
6.3.2. Triggering Communication Diversions
As explained in Section 5.3.2, the message body within a SUBSCRIBE
can be used for selecting the trigger criteria for notifying the
selected communication diversions to the Subscribing User. This
allows the User to ensure that communication diversion notifications
are not sent immediately, but when the user is in a suitable context
(time-based or availability based). The following sub-elements are
present for selecting the notification trigger criteria. The User
also has an option to configure a buffer interval for which the
notifications can be stored, if they are not deliverable to the User
(for e.g. the User is Not logged in or is un-reachable).
comm-div-ntfy-trigger-criteria
+
+------- time-range-selection-criteria
|
+------- presence-status-selection-criteria
|
+------- notification-buffer-interval
Saklikar, et al. Expires March 15, 2009 [Page 20]
Internet-Draft SIP Communication Diversion Notification September 2008
6.3.2.1. time-range-selection-criteria
This element allows the specification of a list of time-ranges, when
the User would like to be notified of communication diversion
information. It has the following sub-elements
time-range-selection-criteria
+
+------- time-range
| +
| +------- start-time
| |
| +------- end-time
+------- time-range
|
+------- ...
List of time-range: This contains a list of suitable time-ranges,
when the User would like to be notified of the communication
diversion information. Each element of this list is of the
following type.
6.3.2.1.1. Time Range
start-time: Contains a start time for the time-range.
end-time: Contains the stop time for the time-range.
6.3.2.2. presence-status-selection-criteria
This element allows the specification of a list of presence-status,
when the User would like to be notified of communication diversion
information. It has the following sub-elements
presence-status-selection-criteria
+
+------- presence-status
|
+------- presence-status
|
+------- ...
List of presence-status: This contains a list of
presence-status: Indicates a presence-status for the User, when
the User should be notified of communication diversion
Saklikar, et al. Expires March 15, 2009 [Page 21]
Internet-Draft SIP Communication Diversion Notification September 2008
information.
6.3.3. Selecting Communication Diversion Information
As explained in Section 5.3.3, the message body within a SUBSCRIBE
may be used for selecting the communication diversion information
which has to be sent in the notification towards the User. This
enables the User to select a specific sub-set of the overall
diversion information. By default, ALL information would be provided
to the User. However, the user may use any of the following sub-
elements for DISABLING a particular kind of communication diversion
information.
comm-div-info-selection-criteria
+
+------- disable-originating-user-info
|
+------- disable-diverting-user-info
|
+------- disable-diverted-to-user-info
|
+------- disable-diversion-time-info
|
+------- disable-diversion-reason-info
|
+------- disable-diversion-rule-info
The above elements do not have any further sub-elements. Their
presence indicates that the User does NOT want that particular
communication diversion information to be notified.
6.4. Communication Diversion Notification Information
As part of the NOTIFY, the Notifier would generate a message body
containing the communication diversion information, which the User
had selected for notification as described above. This communication
diversion information has the following sub-elements. A
communication diversion information notification document begins with
the element tag "comm-div-ntfy-info".
Saklikar, et al. Expires March 15, 2009 [Page 22]
Internet-Draft SIP Communication Diversion Notification September 2008
comm-div-ntfy-info
+
+------- originating-user-info
|
+------- diverting-user-info
|
+------- diverted-to-user-info
|
+------- diversion-time-info
|
+------- diversion-reason-info
|
+------- diversion-rule-info
6.4.1. originating-user-info
This element contains the Identity of the Originating (Caller) of the
communication which was diverted. It is of the type as described in
Section 6.3.1.1.1
6.4.2. diverting-user-info
This element contains the address of the Diverting User, whose
incoming communication has been diverted.
6.4.3. diverted-to-user-info
This element contains the address of the User to whom the incoming
communication has been diverted to.
6.4.4. diversion-time-info
This element contains the time at which the communication diversion
took place.
6.4.5. diversion-reason-info
This element contains the reason for the diversion. It can take on
one of the following reason codes viz. "404", "486", "408", "302",
"487", "480", "503".
6.4.6. diversion-rule-info
This element contains the rule identifier that got executed as part
of the communication diversion service.
Saklikar, et al. Expires March 15, 2009 [Page 23]
Internet-Draft SIP Communication Diversion Notification September 2008
7. XML Schema
See RFCXXXX