Polycom Technology India Pvt Ltd Manyata Embassy Business Park, Bangalore 560045 India ranjit.avasarala@polycom.comResearch in Motion 5000 Riverside Drive, Building 6, Suite 100 Irving, Texas 75039 USA jbakker@rim.comDISPATCH 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.
.
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 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.
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
and indicate requirement levels for compliant implementations. 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.
and to register a new event package with event name "comm-div-info" with IANA.
CDIV: Communication Diversion. CDIVN: Communication Diversion Notification. TISPAN: Telecommunications and Internet Converged Services and Protocols for Advanced Networking. 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
and not the general SIP network as defined in .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 and This section fills in the details needed for an event package as defined in Section 4.4 of . 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 , this value appears in the Event
header present in SUBSCRIBE and NOTIFY requests. The SIP Events specification allows packages to define additional parameters. This event package
"comm-div-info" does not define additional parameters.
. 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-filter+xml".
A body of the SUBSCRIBE request with content type set to MIME type
"application/comm-div-info-filter+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
only.
The default expiration time for subscriptions within this package is 3600 seconds. As per , the subscriber
MAY specify an alternate expiration in the Expires header field.
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 .
All subscribers of "comm-div-info" event package who wish to add filter criteria to their subscription requests MUST support
the application/comm-div-info-filter+xml" data format as described in
while the notifiers SHALL support the "application/comm-div-info+xml" data format as described in .
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-ntfy+xml"
(assuming Event header has a value of "comm-div-info-ntfy"). If the Accept header field is present, it MUST contain the value
"application/comm-div-info-ntfy+xml" only.
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
and then the user MUST be authorized to be a subscriber as described in .
The Notifier MUST check if the SUBSCRIBE request contains a body. If there is a body, the Notifier MUST do the following.
Check if the SUBSCRIBE request body conforms to application/comm-div-info-filter+xml document. If not, trigger a error
response. E.g. 415 Media Type Unsupported response. If the body conforms to application/comm-div-info-filter+xml document, then the Notifier process the filter criteria and
generates notifications accordingly. If the SUBSCRIBE request contains a request body and if the Notifier does not support it, it simply ignores it. The notifications
are sent as if there was no filter criteria.
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.
Notifiers MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in
and other authentication extensions.
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
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 does not send any notification towards the subscriber.
The body of the NOTIFY MUST be sent using the type "application/comm-div-info-ntfy+xml" and must contain the elements defined in
only. The Content-Type header field MUST be set to "application/comm-div-info-ntfy+xml".
Notifiers could detect that a communication diversion was enacted on behalf of the subscriber via a "History-Info" header field value, per or , sent from an application server hosting the CDIV service.
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
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.
But if forking is allowed, then the server that receives multiple subscriptions should be able to generate a single dialog on behalf of all the
subscriptions that are received. Any subsequent subscriptions should be mapped to the generated dialog. Similarly when the server
receives a single notification for the generated dialog, it should be generate the corresponding number of notifications towards the
received 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.
An FSM associated with the subscriber is created in the "IDLE" state, e.g. upon receiving filter criteria.
When a communication diversion is detected for a URI of the subscriber, a state transition to the
"DIVERSION_DETECTED" state occurs. In this state, if present the filter criteria are used to
determine whether notification information needs to be sent to the subscriber or not. If
notification information needs to be sent, the Notifier generates the notification
information and sends the information to the subscriber. Additionally, a state
transition to the "DIVERSION_NOTIFIED" state occurs.
The FSM for CDIVN is shown in below Figure.
The subscriber could receive, as part of the notification information, the
state the FSM was in prior to detecting the diversion.
[IDLE]: meaning that there have been no missed diversions since setting
the present "filter".[DIVERSION_NOTIFIED]: meaning that there have been no missed
diversions. [DIVERSION_DETECTED]: meaning that there have been some missed
diversions. Comm-div-info document is an XML document 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
. 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. 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. 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:
This element contains information about communication diversion information selection criteria. It contains
following sub-elements for specifying the 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. This element gives user details like username and URI. This element has further sub-elements for
describing username and user URI This element gives Username. "Alice". 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 schemeThis element specifies the time range for receiving notifications. It contains following additional elements
. 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.
This element specifies the start time for receiving notifications. Its value is expressed in
YYYY:MM:DDTHH:MM:SSZ format. This element specifies the end time for receiving notifications. Its value is expressed in
YYYY:MM:DDTHH:MM:SSZ format. 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 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 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
.
This element contains the reason for communication diversion. It contains following sub-element: This element gives the actual reason for the communication diversion. E.g. "Call Forward on Busy". This element contains the total number of diversions that occurred in network on behalf of the user till then. This element contains the total number of communication diversion notifications sent by the network to user till then. This element informs the server about the time at which the notification should be triggered. 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. This element specifies the presence status of the subscriber within which the subscriber expects to receive
notifications about communication diversions.
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.
This element gives the notification information. This element has following sub-elements: Refer to for details of this element. 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.
This element gives details of the final target of the communication i.e. the diverted-to user. This element consists
of sub-elements defined for "user-info" element. This element gives the time of communication diversion. Its value is expressed in
YYYY:MM:DDTHH:MM:SS format. 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 .
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. preferred language).. This element gives the previous state of CDIVN FSM. This element gives the subscriber various options to select communication diversion information. This element has following
sub-elements. 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.
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.
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.
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.
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.
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.
Authentication and authorization of subscriptions have been discussed
in . 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 . If a notifier does not encrypt bodies of
NOTIFY requests, an eavesdropper could learn the status of a SIP user
agent and use it to create malicious sessions. If the notifier
does not integrity protect the bodies of NOTIFY requests, a man-in-
the-middle attacker or malicious SIP proxy could modify the contents
of the comm-div-info event package notification. Although this does
not cause harm, it can create annoyances. This document registers the new SIP Event Package. The authors would like to thank Mary Barnes, Samir Saklikar, Subir Saha, 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. Changes from draft-avasarala-dispatch-comm-div-notification-07
Added MIME type for communication diversion filter criteria.Updated the State Agents section to add state diagram for CDIVN Service.Updated the schema for CDIVN notification document. Updated the Acknowledgements section.Changes from draft-avasarala-dispatch-comm-div-notification-06
Changed the namespace for XML schema to "http://urn.etsi.org" aligning with 3GPP TS 24.504Updated the XML schema and removed the word "optional" for "diverting-user-info" Changes from draft-avasarala-dispatch-comm-div-notification-05
Updated Requirements section Incorporated expert review comments for state information, notification content and subscribe bodies Modified the section on examples for subscription and notification body Changes from draft-avasarala-dispatch-comm-div-notification-04
Incorporated review comments Added text for SUBSCRIBE body and NOTIFY body and checking of
filter criteria. 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
Added State information to Notifiers. Modified diverting-URI definition and element in communication
diversion information selection criteria as optional parameter
. Changes from draft-avasarala-dispatch-comm-div-notification-02
Modified the applicability statement to make it more IMS specific. Added a definition for IMS Core network. Updated authors list and Acknowledgement sections. Changes from draft-avasarala-dispatch-comm-div-notification-01
Incorporated review comments. Modified contact details for co author Subir Saha. Changes from draft-avasarala-sipping-comm-div-notification-00
Changed contact details of co author Subir Saha. Moved from SIPPING to DISPATCH WG. Changes from draft-avasarala-dispatch-comm-div-notification-00
Added comm-div-info document structure information and schema for the
event package.
Added more elaborate description for various sections in comm-div-info
document