DISPATCH J. Bakker, Ed.
Internet-Draft BlackBerry Corporation
Intended status: Informational R. Avasarala
Expires: January 14, 2014 Polycom
July 13, 2013
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-12.txt
Abstract
3GPP and TISPAN are defining the protocol specification for the
Communication Diversion (CDIV) service using IP Multimedia (IM) Core
Network (CN) subsystem (IMS) supplementary service. As part of CDIV,
a SIP based event package is used for notifying users about
diversions (re-directions or forwarding) of requests for
communication sessions targetting the user. This document defines
the SIP event package to support subscription and notification of
diversions. 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 January 14, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bakker & Avasarala Expires January 14, 2014 [Page 1]
Internet-Draft SIP Communication Diversion Notification July 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Abbreviations and Definitions . . . . . . . . . . . . . . . . 4
4.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Package Definition . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6
6.3. SUBSCRIBE request bodies . . . . . . . . . . . . . . . . . 6
6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 6
6.5. NOTIFY request bodies . . . . . . . . . . . . . . . . . . 6
6.6. Notifier Processing of SUBSCRIBE requests . . . . . . . . 7
6.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 7
6.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 8
6.7. Notifier Generation of NOTIFY requests . . . . . . . . . . 8
6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8
6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 8
6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9
6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9
7. Comm-div-info filter and notifier documents . . . . . . . . . 10
8. Structure of Comm-div-info filter and notifier formats . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10.1. Communication Diversion Information Event Package
Registration . . . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Bakker & Avasarala Expires January 14, 2014 [Page 2]
Internet-Draft SIP Communication Diversion Notification July 2013
1. Introduction
3GPP is currently maintaining and specifying communication diversion
mechanisms which allow users to forward and/or redirect incoming
communications to other destinations. A common example is
Communication Forward On Busy (CFB) wherein users can instruct a
server in the network to redirect incoming requests, whilst they are
participating in a session. Similarly, other variants of
communication diversion are well defined and used in practice such as
Communication Forward on subscriber Not Reachable (CFNRc),
Communication Forward Unconditional (CFU), Communication Forwarding
No Reply (CFNR), Communication Deflection (CD), and Communication
Forwarding on Not Logged-in (CFNL). 3GPP is currently maintaining and
specifying a mechanism for users to configure Communication Diversion
Services (3GPP TS 24.504 [1] and its successor: 3GPP TS 24.604 [2])
for their incoming communications.
The mechanism for users to configure Communication Diversion Services
(3GPP TS 24.504 [1]) may cause a variety of rules to be provisioned
in the network at the same time. For instance, a user may have, in
addition to other communication diversion rules, various CDIV
services configured, e.g. some rules based on the time-of-the-day and
some rules based on the calling party's identity. It is possible
that the user loses track of the various rules and undesirable
diversions may occur. If the user cann't notified of the diversions,
then it is hard for the user to determine that the combination of
rules have caused undesirable diversions.
CDIV Notification (CDIVN) is a CDIV service providing the user the
capability to receive notifications about all diverted communications
(CFU, CFB, CFNR, CD, CFNRc and CFNL). If CDIVN is configured, when a
communication is diverted on behalf of the subscriber, the Subcsriber
receives a notification. The subscriber is then in able to determine
whether the communication diversion which just occurred, was indeed
as per their expectation. For example, a subscriber intended 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 a.m.
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.
Bakker & Avasarala Expires January 14, 2014 [Page 3]
Internet-Draft SIP Communication Diversion Notification July 2013
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 using the CDIV service. The protocol
specification for the CDIV service (using IMS core networks) can be
found in 3GPP TS 24.504 [1].
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 [3] and
indicate requirement levels for compliant implementations.
3. Applicability Statement
It is believed that the SIP event package defined here is not
applicable to the general Internet; it has been designed to serve the
architecture of the CDIV service (see 3GPP TS 24.504 [1]) in IMS core
networks 3GPP TS 24.229 (see [10]). The aim of this memo is to
follow the procedure indicated in RFC 5727 [4] 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.
Bakker & Avasarala Expires January 14, 2014 [Page 4]
Internet-Draft SIP Communication Diversion Notification July 2013
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
CDIV service rules in the network, in accordance with 3GPP TS
24.504 [1].
Diverted-To Entity/User - The User Agent who is the new target of
the incoming communication, post execution of any configured CDIV
service rules.
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 3GPP TS 24.229 [10] and not the general SIP
network as defined in RFC 3261 [5].
5. Requirements
The 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 3GPP TS 22.173 [6] and 3GPP TS 24.504 [1].
6. Package Definition
This section fills in the details needed for an event package as
defined in RFC 6665 [7].
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 RFC
6665 [7], this value appears in the Event header present in SUBSCRIBE
and NOTIFY requests.
Bakker & Avasarala Expires January 14, 2014 [Page 5]
Internet-Draft SIP Communication Diversion Notification July 2013
6.2. Event Package Parameters
The SIP Events specification RFC 6665 [7] allows packages to define
additional parameters. This event package "comm-div-info" does not
define additional parameters.
6.3. SUBSCRIBE request bodies
The SIP Events specification requires package or template-package
definitions to define the usage, if any, of message bodies in
SUBSCRIBE requests. Furthermore, the SIP Events specification
requires that message bodies are specified or that detailed
specifications for the syntax and semantics of such a message body
are cited.
A SUBSCRIBE request for Communication Diversion event MAY contain a
message body. The purpose of the body depends on its type.
Subscriptions to the Comm-div-info event package SHALL only include a
message body of MIME type "application/vnd.3gpp.comm-div-info+xml".
The syntax and semantics of the message body can be found in 3GPP TS
24.504 [1].
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 3GPP TS 24.504 [1].
6.4. Subscription Duration
The default expiration time for subscriptions within this package is
3600 seconds. As per RFC 6665 [7], the subscriber MAY specify an
alternate expiration in the Expires header field.
6.5. NOTIFY request 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 request message contains an event body. This event body
is in 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. Furthermore, the SIP
Events specification requires that event bodies are specified or that
detailed specifications for the syntax and semantics of such a event
Bakker & Avasarala Expires January 14, 2014 [Page 6]
Internet-Draft SIP Communication Diversion Notification July 2013
body are cited.
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 package
specific body has the MIME type "application/
vnd.3gpp.comm-div-info+xml". The syntax and semantics of the event
body can be found in 3GPP TS 24.504 [1].
A subscriber must always Accept receiving a NOTIFY request with
Content-Type "application/vnd.3gpp.comm-div-info+xml". The notifiers
MUST be capable of accepting the "application/
vnd.3gpp.comm-div-info+xml" data format as described in 3GPP TS
24.504 [1]. If the notifier sends a NOTIFY, it MUST include contents
according to 3GPP TS 24.504 [1] and include the content-type header
field set to "application/vnd.3gpp.comm-div-info+xml".
The default Accept header field for SUBSCRIBE request is
"application/vnd.3gpp.comm-div-info+xml" (assuming Event header has a
value of "comm-div-info-ntfy").
6.6. Notifier Processing of SUBSCRIBE requests
The contents of a "application/vnd.3gpp.comm-div-info+xml" XML
document in a NOTIFY request can contain sensitive information that
can reveal some privacy information. Therefore, such documents MUST
only be sent to authorized subscribers. In order to determine if a
subscription originates in an authorized user, the subscriber MUST be
authenticated as described in Section 6.6.1 and then the user MUST be
authorized to be a subscriber as described in Section 6.6.2.
The Notifier MUST 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/
vnd.3gpp.comm-div-info+xml" XML Schema document in 3GPP TS 24.504
[1]. If it conforms then the Notifier processes the document 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 RFC
3261 [5] and other authentication extensions.
Bakker & Avasarala Expires January 14, 2014 [Page 7]
Internet-Draft SIP Communication Diversion Notification July 2013
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.
6.7. Notifier Generation of NOTIFY requests
The SIP Events specification details the formatting and structure of
NOTIFY request 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.
If the filter criteria matches, then the notifier generates a NOTIFY
request and sends the NOTIFY request to the user. If the filter
criteria do not match, then the notifier does not generate a NOTIFY
request. A body part of the NOTIFY request has a content-type set to
"application/vnd.3gpp.comm-div-info+xml" and must contain the
elements defined in 3GPP TS 24.504 [1].
Notifiers could detect that a communication diversion was enacted on
behalf of the subscriber via a "History-Info" header field RFC 4244
[8] value, per 3GPP TS 24.504 [1], sent from an application server
hosting the CDIV service.
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 XML document
for the content type "application/vnd.3gpp.comm-div-info+xml" (see
3GPP TS 24.504 [1]).
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
Bakker & Avasarala Expires January 14, 2014 [Page 8]
Internet-Draft SIP Communication Diversion Notification July 2013
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 January 14, 2014 [Page 9]
Internet-Draft SIP Communication Diversion Notification July 2013
+-----------+ 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 no diversions have occured since setting the
present "filter".
o [DIVERSION_NOTIFIED]: meaning that since receiving the last NOTIFY
request for this even package, no additional diversions have
occured.
o [DIVERSION_NOT_NOTIFIED]: meaning that one or more diversions have
occured since setting the present "filter" or since receiving the
last NOTIFY request for this even package.
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
(see RFC 4745 [12]).
Bakker & Avasarala Expires January 14, 2014 [Page 10]
Internet-Draft SIP Communication Diversion Notification July 2013
8. Structure of Comm-div-info filter and notifier formats
The
o structure of the filter and notifier format;
o examples of the use of subscribtion and notification bodies; and
o XML Schema of subscribtion and notification bodies,
have been described in 3GPP TS 24.504 [1].
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)
Bakker & Avasarala Expires January 14, 2014 [Page 11]
Internet-Draft SIP Communication Diversion Notification July 2013
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, Olle E. Johansson,
Atle Monrad and Dean Willis for their valuable comments and
suggestions.
12. References
12.1. Normative References
[1] 3GPP, "TISPAN; PSTN/ISDN simulation services: Communication
Diversion (CDIV); Protocol specification", 3GPP TS 24.504
8.17.0, June 2013.
[2] 3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM)
Core Network (CN) subsystem; Protocol specification", 3GPP
TS 24.604 10.6.0, June 2013.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] 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.
[5] 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.
[6] 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia
Telephony Service and supplementary services; Stage 1", 3GPP
TS 22.173 10.5.0, June 2012.
[7] Roach, A., "SIP-Specific Event Notification", RFC 6665,
July 2012.
[8] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244,
November 2005.
[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.
Bakker & Avasarala Expires January 14, 2014 [Page 12]
Internet-Draft SIP Communication Diversion Notification July 2013
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.12.0, June 2013.
[11] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[12] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007.
Appendix A. Change log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-avasarala-dispatch-comm-div-notification-11
o Updated affiliations
o Changed reference from RFC 3265 to RFC 6665
o Changed reference from 3GPP TS 24.604 to 3GPP TS 24.504
o Editorial clean up.
Changes from draft-avasarala-dispatch-comm-div-notification-10
o The SIP Events specification (RFC 3265) requires that bodies to be
used as part of the event package are specified or that detailed
specifications for the syntax and semantics of such a body are
cited. With that knowledge, the authors could greatly reduce the
size of this draft; the detailed specification is in 3GPP TS
24.504 and in 3GPP TS 24.604.
o Editorial clean up.
Changes from draft-avasarala-dispatch-comm-div-notification-09
o No changes of substance. An update addressing the comments on the
list and offline, will follow.
Bakker & Avasarala Expires January 14, 2014 [Page 13]
Internet-Draft SIP Communication Diversion Notification July 2013
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
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 request body and NOTIFY request 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.
Bakker & Avasarala Expires January 14, 2014 [Page 14]
Internet-Draft SIP Communication Diversion Notification July 2013
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
Authors' Addresses
John Luc Bakker (editor)
BlackBerry Corporation
5000 Riverside Drive, Building 6, Suite 100
Irving, Texas 75039
USA
Email: jbakker@blackberry.com
Bakker & Avasarala Expires January 14, 2014 [Page 15]
Internet-Draft SIP Communication Diversion Notification July 2013
Ranjit Avasarala
Nokia Siemens Networks
Manyata Tech Park, Nagawara Outer Ring Road
Bangalore 560045
India
Email: ranjit.avasarala@nsn.com
Bakker & Avasarala Expires January 14, 2014 [Page 16]