Skip to main content

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-09

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors John-Luc Bakker , Ranjit Avasarala
Last updated 2012-03-27
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-avasarala-dispatch-comm-div-notification-09
DISPATCH                                                  J. Bakker, Ed.
Internet-Draft                            Research in Motion Corporation
Intended status: Informational                              R. Avasarala
Expires: September 28, 2012                                      Polycom
                                                          March 27, 2012

  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-09.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 September 28, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Bakker & Avasarala     Expires September 28, 2012               [Page 1]
Internet-Draft  SIP Communication Diversion Notification      March 2012

   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.

Bakker & Avasarala     Expires September 28, 2012               [Page 2]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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  . . . . . . . . . . . . . . . 10
     6.10. Rate of Notifications  . . . . . . . . . . . . . . . . . . 10
     6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Comm-div-info filter and notifier documents  . . . . . . . . . 11
   8.  Structure of Comm-div-info filter and notifier formats . . . . 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  . . . . . . . . . . . . . . . . . . . 25
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
     10.1. Communication Diversion Information Event Package
           Registration . . . . . . . . . . . . . . . . . . . . . . . 25
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     12.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Change log  . . . . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29

Bakker & Avasarala     Expires September 28, 2012               [Page 3]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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

Bakker & Avasarala     Expires September 28, 2012               [Page 4]
Internet-Draft  SIP Communication Diversion Notification      March 2012

   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.

Bakker & Avasarala     Expires September 28, 2012               [Page 5]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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].

Bakker & Avasarala     Expires September 28, 2012               [Page 6]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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-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 Section 8.1.1.1 only.

Bakker & Avasarala     Expires September 28, 2012               [Page 7]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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 of "comm-div-info" event package including filter
   criteria to their subscription requests MUST do so according to the
   "application/comm-div-info-filter+xml" data format as described in
   Section 8.1.1.  A subscriber must always Accept receiving a NOTIFY
   with Content-Type "application/comm-div-info-ntfy+xml".  The
   notifiers MUST be capable of accepting the "application/
   comm-div-info+xml" data format as described in Section Section 8.1.2.
   If the notifier sends a NOTIFY, it MUST include contents according to
   Section 6.7 and include the content-type set to "application/
   comm-div-info-ntfy+xml".

   The default Accept header field for SUBSCRIBE is "application/
   comm-div-info-ntfy+xml" (assuming Event header has a value of "comm-
   div-info-ntfy").

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.

Bakker & Avasarala     Expires September 28, 2012               [Page 8]
Internet-Draft  SIP Communication Diversion Notification      March 2012

   The Notifier MUST check if the SUBSCRIBE request contains a body
   part.  If there is a body part, the Notifier MUST do the following.

   Check if a SUBSCRIBE request body part conforms to application/
   comm-div-info-filter+xml document.  If it conforms then the Notifier
   processes the filter criteria and generates notifications
   accordingly.

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 does
   not send any notification towards the subscriber.  A body part of the
   NOTIFY has a content-type set to "application/comm-div-info-ntfy+xml"
   and must contain the elements defined in Section 8.1.2.

   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.

Bakker & Avasarala     Expires September 28, 2012               [Page 9]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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

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.

   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.

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

   An FSM associated with the subscriber is created in the "IDLE" state,
   e.g. upon receiving filter criteria.  Whenever a communication
   diversion is detected for a URI of the subscriber, a state transition
   occurs.  Depending on whether a filter is matched, a state is
   entered.  In the DIVERSION_NOTIFIED state, notification information
   is sent to the subscriber.  If notification information needs to be
   sent, the Notifier generates the notification information and sends
   the information to the subscriber.  If a diversion is detected but no
   filter is matched, a transition to DIVERSION_NOT_NOTIFIED occurs.

   The FSM for CDIVN is shown in below Figure.

Bakker & Avasarala     Expires September 28, 2012              [Page 10]
Internet-Draft  SIP Communication Diversion Notification      March 2012

           +-----------+ First diversion & Filter match
       |           +-------------------------------+
       |   IDLE    |                               |
       |           |                               |
       +-----+-----+                               |
     First   |                                     |
   diversion |                                     |
     & No    |                                     |
   filter(s) |                                     |
    match    V         Next diversion &            V
       +-----------+     Filter match      +-------+-------+
       | DIVERSION +---------------------->+               |
       |    NOT    |                    |  |   DIVERSION   |
       | NOTIFIED  +--+                 +--+    NOTIFIED   |
       +-----+-----+  |                    +-------+-------+
             ^        |                            |
             +--------+----------------------------+
               Next diversion & No filter(s) match

                   Figure 1: Diverted URI State Machine

   The subscriber could receive, as part of the notification
   information, the state the FSM was in prior to detecting the
   diversion.

   o  [IDLE]: meaning that there have been no missed diversions since
      setting the present "filter".

   o  [DIVERSION_NOTIFIED]: meaning that there have been no missed
      diversions.

   o  [DIVERSION_NOT_NOTIFIED]: meaning that there have been some missed
      diversions.

7.  Comm-div-info filter and notifier documents

   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 filter and notifier formats

   A Communications Diversion Information document starts with a "comm-

Bakker & Avasarala     Expires September 28, 2012              [Page 11]
Internet-Draft  SIP Communication Diversion Notification      March 2012

   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.

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".

Bakker & Avasarala     Expires September 28, 2012              [Page 12]
Internet-Draft  SIP Communication Diversion Notification      March 2012

8.1.1.1.1.1.2.  User-URI

   This element gives User URI.  E.g "sip:Alice@domain.com".  It takes
   the form of any URI scheme like sip. sips, tel or any other URI
   scheme

8.1.1.1.2.  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
   it. 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

Bakker & Avasarala     Expires September 28, 2012              [Page 13]
Internet-Draft  SIP Communication Diversion Notification      March 2012

   for "user-info" element Section 8.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
   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.

Bakker & Avasarala     Expires September 28, 2012              [Page 14]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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.

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 diverted-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.

Bakker & Avasarala     Expires September 28, 2012              [Page 15]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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.
   preferred language)..

8.1.2.6.  previous cdivn state

   This element gives the previous state of CDIVN FSM.

8.1.3.  Comm-div-info-selection-criteria

   This element gives the subscriber various options 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.

Bakker & Avasarala     Expires September 28, 2012              [Page 16]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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.2.  Sample comm-div-info subscription and notification body

Bakker & Avasarala     Expires September 28, 2012              [Page 17]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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>

Bakker & Avasarala     Expires September 28, 2012              [Page 18]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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>
     </comm-div-ntfy-info>
   </comm-div-info>

8.3.  Schema

<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema
  targetNamespace="http://uri.etsi.org/ngn/params/xml/comm-div-info"
  xmlns:tns="http://uri.etsi.org/ngn/params/xml/comm-div-info"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  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
  -->
  <xs:complexType name="comm-div-info-type">

Bakker & Avasarala     Expires September 28, 2012              [Page 19]
Internet-Draft  SIP Communication Diversion Notification      March 2012

    <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:element name="previous_cdivn-state"
        type="cdivn-states-types" maxOccurs="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"
        type="xs:anyURI" minOccurs="0" />
      <xs:element name="diverted-to-user-info"
        type="xs:anyURI" minOccurs="0" />

Bakker & Avasarala     Expires September 28, 2012              [Page 20]
Internet-Draft  SIP Communication Diversion Notification      March 2012

      <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:any namespace="##other" processContents="lax"
        minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </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:anyAttribute namespace="##other" processContents="lax"/>
  </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"

Bakker & Avasarala     Expires September 28, 2012              [Page 21]
Internet-Draft  SIP Communication Diversion Notification      March 2012

      default="86400">
        <xs:simpleType>
          <xs:restriction base="xs:integer">
            <xs:maxInclusive value="86400"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
      <xs:any namespace="##other" processContents="lax"
        minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </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:any namespace="##other" processContents="lax"
        minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </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:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <!--
  CDIVN FSM STATES
  -->
    <xs:simpleType name="cdivn-states-types">

Bakker & Avasarala     Expires September 28, 2012              [Page 22]
Internet-Draft  SIP Communication Diversion Notification      March 2012

        <xs:list itemType="cdivn-states-type"/>
    </xs:simpleType>
  <xs:simpleType name="cdivn-states-type">
        <xs:restriction base="xs:string">
            <xs:enumeration value="IDLE"/>
            <xs:enumeration value="DIVERSION_NOTIFIED"/>
            <xs:enumeration value="DIVERSION_NOT_NOTIFIED"/>
        </xs:restriction>
  </xs:simpleType>
  <!--
  DIVERSION REASON INFO
  -->
    <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:anyAttribute namespace="##other" processContents="lax"/>
  </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:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <!--
  DIVERSION REASON SELECTION CRITERIA

Bakker & Avasarala     Expires September 28, 2012              [Page 23]
Internet-Draft  SIP Communication Diversion Notification      March 2012

  -->
  <xs:complexType name="diversion-reason-selection-criteria-type">
    <xs:sequence>
      <xs:element name="diversion-reason-info"
        type="diversion-reason-info-types"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <!--
  TIME RANGE SELECTION CRITERIA
  -->
  <xs:complexType name="time-range-selection-criteria-type">
    <xs:sequence>
      <xs:element name="time-range"
        type="time-range-type" minOccurs="0"
        maxOccurs="unbounded" />
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </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:anyAttribute namespace="##other" processContents="lax"/>
  </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:anyAttribute namespace="##other" processContents="lax"/>
  </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:anyAttribute namespace="##other" processContents="lax"/>

Bakker & Avasarala     Expires September 28, 2012              [Page 24]
Internet-Draft  SIP Communication Diversion Notification      March 2012

  </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
   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:  John Merdith, <John.meredith@3gpp.org>

   Published Specification: RFC XXXX (Note to RFC Editor)

11.  Acknowledgements

   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.

Bakker & Avasarala     Expires September 28, 2012              [Page 25]
Internet-Draft  SIP Communication Diversion Notification      March 2012

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
         TS 22.173 10.4.0, December 2011.

   [5]   3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM)
         Core Network (CN) subsystem;  Protocol specification", 3GPP
         TS 24.604 10.4.0, March 2012.

   [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.7.0, March 2012.

   [11]  Sperberg-McQueen, C., Paoli, J., Bray, T., and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", World
         Wide Web Consortium FirstEdition REC-xml-20001006,

Bakker & Avasarala     Expires September 28, 2012              [Page 26]
Internet-Draft  SIP Communication Diversion Notification      March 2012

         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-08

   o  Corrected text to not preclude use of S/MIME or multipart.

   o  Updated Finite State Machine diagram.

   o  Updated the schema for CDIVN notification document to reflect FSM
      updates.

   Changes from draft-avasarala-dispatch-comm-div-notification-07

   o  Added MIME type for communication diversion filter criteria.

   o  Updated the State Agents section to add state diagram for CDIVN
      Service.

   o  Updated the schema for CDIVN notification document.

   o  Updated the Acknowledgements section.

   Changes from draft-avasarala-dispatch-comm-div-notification-06

   o  Changed the namespace for XML schema to "http://urn.etsi.org"
      aligning with 3GPP TS 24.504

   o  Updated the XML schema and removed the word "optional" for
      "diverting-user-info"

   Changes from draft-avasarala-dispatch-comm-div-notification-05

   o  Updated Requirements section

   o  Incorporated expert review comments for state information,
      notification content and subscribe bodies

Bakker & Avasarala     Expires September 28, 2012              [Page 27]
Internet-Draft  SIP Communication Diversion Notification      March 2012

   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.

   o  Added more elaborate description for various sections in comm-div-
      info document

Bakker & Avasarala     Expires September 28, 2012              [Page 28]
Internet-Draft  SIP Communication Diversion Notification      March 2012

Authors' Addresses

   John Luc Bakker (editor)
   Research in Motion
   5000 Riverside Drive, Building 6, Suite 100
   Irving, Texas  75039
   USA

   Email: jbakker@rim.com

   Ranjit Avasarala
   Polycom Technology India Pvt Ltd
   Manyata Embassy Business Park,
   Bangalore  560045
   India

   Email: ranjit.avasarala@polycom.com

Bakker & Avasarala     Expires September 28, 2012              [Page 29]