DISPATCH R. Avasarala, Ed.
Internet-Draft Motorola Solutions Inc
Intended status: Informational J. Bakker
Expires: August 14, 2011 Research in Motion Corporation
February 10, 2011

None
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-07.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. .

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 14, 2011.

Copyright Notice

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

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

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.

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 [RFC2119] 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 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. [RFC5727] and to register a new event package with event name "comm-div-info" with IANA.

4. Abbreviations and Definitions

4.1. Abbreviations

4.2. Definitions

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 [3GPP.22.173] and [3GPP.24.604]

6. Package Definition

This section fills in the details needed for an event package as defined in Section 4.4 of [RFC3265].

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 [RFC3265], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests.

6.2. Event Package Parameters

The SIP Events specification [RFC3265] allows packages to define additional parameters. This event package "comm-div-info" does not define additional parameters. .

6.3. SUBSCRIBE bodies

The SIP Events specification requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.

A SUBSCRIBE for Communication Diversion event MAY contain a body. The purpose of the body depends on its type. Subscriptions to the Comm-div-info event package SHALL only include a body of MIME type "application/comm-div-info+xml".

A body of the SUBSCRIBE request with content type set to MIME type "application/comm-div-info+xml" contains information about the communication diversion notification information filter criteria and notification trigger criteria. The subscriber SHALL also verify that this information conforms to a valid XML document as defined in [11]. The subscriber SHALL also verify that the information contained in the XML document contains elements defined in Section Section 8.1.1 only.

6.4. Subscription Duration

The default expiration time for subscriptions within this package is 3600 seconds. As per [RFC3265], the subscriber MAY specify an alternate expiration in the Expires header field.

6.5. Notify bodies

The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified.

The NOTIFY message contains bodies. This body is a format listed in the Accept header field of the SUBSCRIBE request or a package specific default format if the Accept header field was omitted from the SUBSCRIBE request

In this event package, the body of the notification contains the communication diversion information pertaining to the diversion that occurred in the network on behalf of the subscriber. The format of the communication diversion information is an XML document as per elements defined in Section 8.1.2.

All subscribers and notifiers of the "comm-div-info" event package MUST support the "application/comm-div-info+xml" data format described in Section Section 8. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/comm-div-info+xml" (assuming Event header has a value of "comm-div-info"). If the Accept header field is present, it MUST contain the value "application/comm-div-info+xml" only.

6.6. Notifier Processing of SUBSCRIBE requests

The contents of a document containing comm-div-info information can contain sensitive information that can reveal some privacy information. Therefore, such comm-div-info documents MUST only be sent to authorized subscribers. In order to determine if a subscription originates in an authorized user, the subscriber MUST be authenticated as described in Section 6.6.1 and then the user MUST be authorized to be a subscriber as described in Section 6.6.2.

The Notifier MUST look into the SUBSCRIBE request body for a comm-div-info document containing filter criteria. If the filter criteria is present and the Notifier supports it, then it should check if the filter criteria conforms to the format described in Section 8.1.1. If the received criteria is valid, then the NOTIFIER MUST use that for generating notifications about communication diversions that occur on behalf of the user. The Notifier SHALL then compute the state information as defined in Section 6.11 for the subscriber and send a NOTIFY request to the subscriber.

NOTE: It could be possible that the state information be empty as this is the first notification sent towards the subscriber in response to the SUBSCRIBE request and no communication diversions have occurred yet.

In case the Notifier does not support filter criteria, then it should ignore it or send a suitable 4xx response. E.g. 415 response.

6.6.1. Authentication

Notifiers MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in [RFC3261] and other authentication extensions.

6.6.2. Authorization

Once authenticated, the notifier makes an authorization decision. A notifier MUST NOT accept a subscription unless authorization has been provided by the user. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading some kind of standardized access control list document

6.7. Notifier Generation of NOTIFY requests

The SIP Events specification details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the "comm-div-info" event package.

A notifier sends a NOTIFY request when a communication diversion is enacted on behalf of the user. If there is a stored filter criteria for the user, then the notifier MUST look into the filter criteria before generating the NOTIFY request towards the user. If the filter criteria matches, then the notifier generates the NOTIFY request and sends the NOTIFY request to the user. If the filter criteria does not match the enacted communication diversion, then the notifier just increments the communication diversion count and does not send any notification towards the subscriber.

The body of the NOTIFY MUST be sent using the type "application/comm-div-info+xml" and must contain the elements defined in Section 8.1.2 only. The Content-Type header field MUST be set to "application/comm-div-info+xml".

Notifiers could detect that a communication diversion was enacted on behalf of the subscriber via a "History-Info" header field [RFC4244] value, per [3GPP.24.404] or [3GPP.24.604], sent from an application server hosting the CDIV service.

It is REQUIRED that the notifiers do maintain the history of last N communication diversions that occurred, where the value N >=1 as part of state information for that server and include it in the communication diversion notification information sent to the user. in addition to this it is also REQUIRED that the notifiers maintain the list of last M communication diversion notifications sent to the user, where M equal to or less than N. M equals N if notifications are sent for all communication diversions that occurred. The value M is decremented whenever a communication diversion notification is sent to the user. The notifiers check the value of M as being greater than 0 prior to generating the notification information.

The value of N could be configured and is left to server policy to determine appropriate value. As a server policy, the values of N and M SHOULD be reset to 0 after reaching the maximum configured value to avoid overflows

The state information is retained even after the notification for those diversions are sent to the subscriber and changes when new diversion occurs and whenever a notification is sent. So every time a new diversion occurs and a notification is sent, the state information changes to reflect the latest communication diversion information sent, removing the oldest diversion information.

The Notifier MAY choose not to send NOTIFY to the subscriber if the computed state information is same as the previously stored. This is left to server policy.

6.8. Subscriber Processing of NOTIFY Requests

The SIP Events specification expects event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request. In this specification, each NOTIFY request contains a comm-div-info document

6.9. Handling of Forked Requests

The SIP Events specification requires each package to describe handling of forked Requests.

This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single notifier is generating notifications for a particular subscription to a particular user.

6.10. Rate of Notifications

The SIP Events specification requires each package to specify maximum rate at which notifications can be sent .

Comm-div-info notifiers SHOULD NOT generate notifications for a single subscription at a rate of more than once every five seconds.

6.11. State Agents

The notifiers maintain state. They store the number of last N communication diversions received and the number (M) of communication diversion notifications sent. The notifier can detect a communication diversion by inspecting the history information in SIP request .

Thus at any point of time a subscriber MAY know the state of communication diversions enacted on his or her behalf and number of notifications sent by the notifier .

7. Comm-div-info Document

Comm-div-info document is an XML document [W3C.REC-xml-20001006] 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 [RFC4745].

8. Structure of Comm-div-info Format

A Communications Diversion Information document starts with a "comm-div-info" element. The comm-div-info element has a series of elements describing the particular communication diversion or the filter criteria for receiving the communication diversion information.

8.1. Comm-div-info Element

The comm-div-info element gives information about the specific communication diversion or it could give information about a particular selection criteria for the user receiving the communication diversion information.

8.1.1. comm-div-subs-info Element

The comm-div-subs-info element is used by the subscribing user to specify the communication diversion information selection criteria and the communication diversion notification trigger criteria. It contains the following elements:

8.1.1.1. comm-div-selection-criteria

This element contains information about communication diversion information selection criteria. It contains following sub-elements for specifying the selection criteria.

8.1.1.1.1. originating-user-selection-criteria

This element specifies the originating user information for the communication i.e. the caller. This is specified in the form of "user-name" and "user-uri". E.g. sip:Alice@domain.com. The Username as well as User-URI specified will be compared with the originating user information of the current user and if there is a match, then information about the diversion of this specific communication would be selected for notification to the Diverting user. It consists of the following sub-elements.

8.1.1.1.1.1. user-info

This element gives user details like username and URI. This element has further sub-elements for describing username and user URI

8.1.1.1.1.1.1. User-name

This element gives Username. "Alice".

8.1.1.1.1.1.2. User-URI

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

8.1.1.1.2. diversion-time-selection-criteria

This element specifies the time range for receiving notifications. It contains following additional elements .

8.1.1.1.2.1. time-range

This element specifies the time range at which notifications for communication diversions can be sent to the subscriber. This could be specified in the form of a time-interval to enable periodic triggering of notifications of communication diversions which took place in that time-interval.

NOTE: If the time-range element is not specified, then notifications about every communication diversion that occurs is sent to the subscriber.

8.1.1.1.2.1.1. start-time

This element specifies the start time for receiving notifications. Its value is expressed in YYYY:MM:DDTHH:MM:SSZ format.

8.1.1.1.2.1.2. end-time

This element specifies the end time for receiving notifications. Its value is expressed in YYYY:MM:DDTHH:MM:SSZ format.

8.1.1.1.3. diverting-user-selection-criteria

This element gives details of diverting user. This element could contain the value present in P-Called-Party-ID header field and by including the identity in the "diverting-user-info", the receiving UE would know if the call was diverted because a rule associated with e.g. the "work" public user identities was triggered. The URI specified over here will be compared with the Request URI of the diverting user for whom a communication has been diverted. Only if there is a match, then information about the diversion of this specific communication would be selected for notification to the diverting user. This is an optional parameter. If absent, then communication diversions towards all registered contacts of the subscribing user would be considered for notification, subject to other filter criteria. This element consists of sub-elements defined for "user-info" element Section 8.1.1.1.1.1.1

8.1.1.1.4. diverted-to-user-selection-criteria

This element gives details of the final target of the communication, the divered-to user. The URI specified in the Request URI of the new request is compared with the specified diverted-to URI. Only if there is a match, then information about the diversion of this specific communication would be selected for notification to the Diverting user. This element consists of sub-elements defined for "user-info" element Section 8.1.1.1.1.1.1.

8.1.1.1.5. diversion-reason-selection-criteria

This element contains the reason for communication diversion. It contains following sub-element:

8.1.1.1.5.1. diversion-reason-info

This element gives the actual reason for the communication diversion. E.g. "Call Forward on Busy".

8.1.1.1.6. number-of-diversions-selection-criteria

This element contains the total number of diversions that occurred in network on behalf of the user till then.

8.1.1.1.7. number-of-notifications-selection-criteria

This element contains the total number of communication diversion notifications sent by the network to user till then.

8.1.1.2. comm-div-ntfy-trigger-criteria

8.1.1.2.1. notification-time-selection-criteria

This element informs the server about the time at which the notification should be triggered.

8.1.1.2.2. presence-status-selection-criteria

This element gives the presence status of the subscriber, based on which the decision can be made, whether the subscriber wishes to receive notification information or not.

8.1.1.2.2.1. presence-selection-info

This element specifies the presence status of the subscriber within which the subscriber expects to receive notifications about communication diversions.

8.1.1.2.3. notification-buffer-interval

This element specifies an optional element (in seconds) to overwrite the CDIVN Buffer Timer for which the CDIVN Application Server should store the CDIV Notification, if it cannot be delivered to the subscriber, For example this would be required for buffering the notifications, if the user is logged out and the diversion is triggered due to CFNL/CFNRc, resulting in CDIVN for that diversion. The user may set Notification Buffer Interval value in seconds to a maximum value of 1 day. Also, if not configured by the user, the default value of 1 day (as configured by the network provider) is applicable.

8.1.2. Comm-div-ntfy-info Element

This element gives the notification information. This element has following sub-elements:

8.1.2.1. originating-user-info

Refer to Section 8.1.1.1.1 for details of this element.

8.1.2.2. diverting-user-info

This element gives details of the diverting user. This is an optional element and would be present only if the subscriber has requested it. If absent, it is assumed that the diversion occurred at one of the registered contacts.

8.1.2.3. diverted-to-user-info

This element gives details of the final target of the communication i.e the divered-to user. This element consists of sub-elements defined for "user-info" element.

8.1.2.4. diversion-time-info

This element gives the time of communication diversion. Its value is expressed in YYYY:MM:DDTHH:MM:SS format.

8.1.2.5. diversion-reason-info

This element contains an integer value and gives the actual reason for the communication diversion. The integer value of the element is mapped to the causes defined in [RFC4458]. 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. num-diversions

This element gives the number of communication diversions that occurred in the network on behalf of the user till date.

8.1.2.7. num-notifications

This element gives the number of communication diversion notifications sent till date to the user.

8.1.3. Comm-div-info-selection-criteria

This element gives the subscriber various to select communication diversion information. This element has following sub-elements.

8.1.3.1. disable-originating-user-info

This element gives the subscriber option of adding originating user information to the notification information. The default value is false which means the subscriber wants the originating-user-info element to be present in the notification information.

8.1.3.2. disable-diverting-user-info

This element gives the subscriber option of adding diverting-user information to the notification information. The default value is false which means the subscriber wants the diverting-user-info element to be present in the notification information.

8.1.3.3. disable-diverted-to-user-info

This element gives the subscriber option of adding diverting-to-user information to the notification information. The default value is false which means the subscriber wants the diverted-to-user-info element to be present in the notification information.

8.1.3.4. disable-diversion-time-info

This element gives the subscriber option of adding diversion-time information to the notification information. The default value is false which means the subscriber wants the diversion-time-info to be present in the notification information.

8.1.3.5. disable-diversion-reason

This element gives the subscriber option of adding diversion-reason information to the notification information. The default value is false which means the subscriber wants the diversion-reason information to be present in the notification information.

8.1.3.6. disable-diversion-rule

This element gives the subscriber option of adding diversion-rule information to the notification information. The default value is false which means the subscriber wants the diversion-rule information to be present in the notification information.

8.1.3.7. disable-number-of-diversions

This element gives the subscriber option of adding number of diversions that occurred till date to the notification information. The default value is false which means the subscriber wants the number of diversions that occurred till date information to be present in the notification information

8.1.3.8. disable-number-of-notifications

This element gives the subscriber option of adding number of communication diversion notifications sent to the user till date to the notification information. The default value is false which means the subscriber wants the number of notifications that were sent to the user till date information to be present in the notification information.

8.2. Sample comm-div-info subscription and notification body

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>
         
       

8.2.2. Instance of communication diversion notification document

          
<comm-div-info>
  <comm-div-ntfy-info>
    <originating-user-info>
      <user-name>Boss</user-name>
      <user-URI>sip:boss@office.com</user-URI>
    </originating-user-info>
    <diverting-user-info>
      sip:alice@office.com
    </diverting-user-info>
    <diverted-to-user-info>
      sip:bob@office.com
    </diverted-to-user-info>
    <diversion-time-info>1999-06-01T13:20:00-05:00Z
    </diversion-time-info>
    <diversion-reason-info>404</diversion-reason-info>
    <num-diversions>1</num-diversions>
    <num-notifications>1</num-notifications>
  </comm-div-ntfy-info>
</comm-div-info>
          
       

8.3. Schema

     
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema 
  targetNamespace="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">
    <xs:sequence>
      <xs:element name="comm-div-subs-info"
        type="comm-div-subs-info-type" minOccurs="0" />
      <xs:element name="comm-div-ntfy-info"
        type="comm-div-ntfy-info-type" minOccurs="0" />
      <xs:any namespace="##other" processContents="lax"
        minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="entity" type="xs:anyURI" 
      use="required"/>
  </xs:complexType>
  <!---
  Communication Diversion Subscription Type.
  Used at Subscription time to
        select Communication Diversions for notification,
        when to notify them and
        what to notify.
  -->
  <xs:complexType name="comm-div-subs-info-type">
    <xs:sequence>
      <xs:element name="comm-div-selection-criteria"
        type="comm-div-selection-criteria-type" 
        minOccurs="0" />
      <xs:element name="comm-div-ntfy-trigger-criteria"
        type="comm-div-ntfy-trigger-criteria-type" 
        minOccurs="0" />
      <xs:element name="comm-div-info-selection-criteria"
        type="comm-div-info-selection-criteria-type" 
        minOccurs="0" />
      <xs:any namespace="##other" processContents="lax"
        minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <!---
  Communication Diversion Notification Information Type
  Used while notifying the User about the Communication Diversion
  -->
  <xs:complexType name="comm-div-ntfy-info-type">
    <xs:sequence>
      <xs:element name="originating-user-info"
        type="user-info-type" minOccurs="0" />
      <xs:element name="diverting-user-info"
        type="xs:anyURI" minOccurs="0" />
      <xs:element name="diverted-to-user-info"
        type="xs:anyURI" minOccurs="0" />
      <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" 
      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>

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

Published Specification: RFC XXXX (Note to RFC Editor)
     
    

11. Acknowledgements

The authors would like to thank Samir Saklikar and Subir Saha for being part of the initial versions of the draft and Ban Al-Bakri, Roland Jesske, Jose Miguel Torres, Paul Kyzivat, John Elwell , Keith Drage , Gonzalo Camarillo and Dean Willis for their valuable comments and suggestions.

12. References

12.1. Normative References

[1] 3GPP, "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", 3GPP TS 24.604 10.2.0, September 2011.
[2] 3GPP, "TISPAN; PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol specification", 3GPP TS 24.404 7.5.0, June 2009.
[3] 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1", 3GPP TS 22.173 10.3.0, April 2011.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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] 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.
[7] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[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.

12.2. Informative References

[1] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 10.5.0, September 2011.
[2] Maler, E., Paoli, J., Bray, T. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000.
[3] 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-06

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

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

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

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

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

Changes from draft-avasarala-sipping-comm-div-notification-00

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

Authors' Addresses

Ranjit Avasarala editor Motorola Solutions India Pvt Ltd Bagamane Tech Park, C V Raman Nagar Bangalore , 560093 India EMail: ranjit@motorolasolutions.com
John Luc Bakker Research in Motion 5000 Riverside Drive, Building 6, Suite 100 Irving, Texas , 75039 USA EMail: jbakker@rim.com