Subject: [dispatch] purpose <previous-cdivn-state> RE: draft-avasarala-dispatch-comm-div-notification

From: John-Luc Bakker <[email-masked]>
Date: Wed, 28 Aug 2013 18:13:56 +0000

Hi Dale, 

Thanks for the response below.
You suggest various forms of state that could help conforming to the SIP event model.
A number of e-mails have been received, many e-mails have questioned the state model used in this draft, whether it satisfies the SIP event model. There are other issues too and I will come back to them separately.

The authors initially thought that the information in <previous-cdivn-state> could be the state satisfying the SIP event model. 

I am not discounting the other examples of state but would like to first explain the reasoning behind the state indicated in <previous-cdivn-state>. It might well be that this state indicated and maintained is not SIP event model compliant.

	<copied from Dale, below>
	I'm not sure what the <previous-cdivn-state> element is intended to do.  It appears that there are two levels of filtering, 
	"selection" and "notification".  As written, the previous-cdivn-state tells whether there was a selected-but-non-notifiable 
	diversion between the previous selected-and-notifiable diversion and the current selected-and-notifiable diversion.  It's 
	not clear to me why this is useful to the subscriber, or whether the subscriber wants to know when the previous-cdivn-state 
	value changes due to a non-notifiable diversion.  I think it would help if you explained what its ultimate purpose is; it's possible 
	that the design could be made more useful relative to that purpose.
	<end copy from Dale, below>

The initial motivation for CDIVN is "debugging" or analyses of communication diversion rules (see "introduction" in the draft). Some state is needed in the network enabling this analyses.
The proposed state is a ternary value and can take the following values IDLE, DIVERSION_NOTIFIED, DIVERSION_NOT_NOTIFIED:

   <copied from draft>
   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 occurred since setting the
      present "filter".

   o  [DIVERSION_NOTIFIED]: meaning that since receiving the last NOTIFY
      request for this event package, no additional diversions have
      occurred.

   o  [DIVERSION_NOT_NOTIFIED]: meaning that one or more diversions have
      occurred since setting the present "filter" or since receiving the
      last NOTIFY request for this event package.
   <end copy from draft>

The state has limited use to a user trying to understand communication diversion rules. If a user receives an indication that diversions have happened for which it did not receive a notification and the user had not expected these diversions to happen, then the user can further "debug" the diversion and notification filtering rules. The primary advantage of this rather limited information is that the amount of state stored for a user subscribed to "communication diversion" is limited, yet still enables "analyses". 

There is no 3GPP requirement to receive notification from all diversions that have happened in the past. That is, if a diversion wasn't notified due to failing to meet conditions expressed in the notification filter, then there is no requirement to be able to notify that diversion at a later stage.

Is the ternary value maintained at the NOTIFIER per CDIVN subscriber compliant with the SIP event model?

Kind regards,

	JL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Friday, August 02, 2013 4:14 PM
To: [email-masked]
Subject: [dispatch] draft-avasarala-dispatch-comm-div-notification

This discusses a number of things that I think could be improved in the current draft:

As has been mentioned before, the current draft doesn't really conform to the SIP event model.  One way to fix that is to consider that the "state" is really the (potentially unlimited) list of diversion events.  Thus, when a *new* diversion happens, the state changes and a notification should be generated.

This means that the length of notifications could grow without limit, which is not desirable.

One fix would be to define "full" and "partial" notifications such that a "partial" notification contains only the additional elements added to the list since the last full or partial notification.  These notifications will usually contain exactly exactly one diversion.

This also solves a problem regarding rate-limiting of notifications:
The draft says that notifications should be sent at most every 5 seconds, but it doesn't specify what is to be done if notifiable diversions happen more often than once every 5 seconds.  In principle, the notifier could get arbitrarily far behind in sending notifications.  In the new method, very frequehnt diversions would not cause more frequent notifications, but many notifications would list more than one diversion.

But full notifications would still grow without limit.  That could be limited by prescribing that every time the subscriber re-subscribes, it must update the selection criteria start-time to be the latest time of any diversion it's seen.  That would ensure that most re-subscribes would receive a NOTIFY that contains no diversions; after that, full notifications would grow from zero.

You would also want to allow the notifier to forget history that was sufficiently far in the past, so that even a subscriber that asks for diversion history since 1970 can receive only a limited amount of data.  Perhaps that can be just written into the text, but in a perfect world, part of the state would be the current date/time before which the notifier no longer has history (regarding the directory number that is being watched).  (You'd want to specify that changes in the cutoff date/time alone would not trigger notification.)  The notifier would gradully time-out diversion information that was too old to be practically significant, that is, which you don't need a subscriber to be able to access.

I notice that if two calls *from* the same directory number, *to* the same directory number are diverted for the same reason, at the same second, for the same reason, they produce identical <comm-div-ntfy-info> elements.  That would make it difficult for the subscriber to distinguish that it has received two notifications rather than one.  I would suggest adding an "id" element as is used in the "reg" and "dialog" event packages.  Since the "id" value is an arbitrary string, the notifier can generate it as an encoding of whatever internal identifier it uses to identify diversion events, which should be efficient to implement.

I'm not sure what the <previous-cdivn-state> element is intended to do.  It appears that there are two levels of filtering, "selection"
and "notification".  As written, the previous-cdivn-state tells whether there was a selected-but-non-notifiable diversion between the previous selected-and-notifiable diversion and the current selected-and-notifiable diversion.  It's not clear to me why this is useful to the subscriber, or whether the subscriber wants to know when the previous-cdivn-state value changes due to a non-notifiable diversion.  I think it would help if you explained what its ultimate purpose is; it's possible that the design could be made more useful relative to that purpose.

Dale
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2013 15:43:57 -0400

On 8/28/13 2:13 PM, John-Luc Bakker wrote:

> The state has limited use to a user trying to understand communication diversion rules.

The above is helpful.

> If a user receives an indication that diversions have happened for which it did not receive a notification and the user had not expected these diversions to happen, then the user can further "debug" the diversion and notification filtering rules. The primary advantage of this rather limited information is that the amount of state stored for a user subscribed to "communication diversion" is limited, yet still enables "analyses".

Sounds like you are trying to debug both the diversion rules and the 
subscription filters.

Without a filter, I would be getting a notification of every diversion, 
and then could decide if I thought my rules should have caused that one 
or not.

Does the DIVERSION_NOT_NOTIFIED mean "a diversion happened, but no 
notification was requested for it"? Or can it mean "a diversion happened 
but I haven't *yet* sent a notification for it"? (Delay can occur due to 
rate limiting, etc.)

> There is no 3GPP requirement to receive notification from all diversions that have happened in the past. That is, if a diversion wasn't notified due to failing to meet conditions expressed in the n…

OK.

> Is the ternary value maintained at the NOTIFIER per CDIVN subscriber compliant with the SIP event model?

IMO its not enough.

The expectation is that the state changes, and then the notification 
contains the (new) state, possibly filtered.

If the state were only this ternary value, then the notification would 
contain only that. If you want the notification to contain info about 
the diverted request, then that information ought to be part of the 
state. So at least it ought to contain "most recent diversion".

And having per-subscriber state is at least troubling to me.

	Thanks,
	Paul