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

From: [email-masked] (Dale R. Worley)
Date: Mon, 2 Sep 2013 21:22:15 -0400 (EDT)

> From: John-Luc Bakker <[email-masked]>

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

Yes, you can make a "ternary value maintained at the NOTIFIER per
CDIVN *subscription*" compliant, though it takes some extra verbiage
to get the definition right.

But I believe that it doesn't give you the effect you want.  For
example, assuming that the previous state is DIVERSION_NOTIFIED, if a
diversion happens that is not selected by the filter, then the state
changes to DIVERSION_NOT_NOTIFIED.  But since previous-cdivn-state *is
part of the state*, the notifier has to tell the subscriber that it
has just changed, resulting in a NOTIFY that tells the subscriber that
an event just happened that the subscriber wasn't notified of.

I believe what you actually want to tell the subscriber is, connected
with each diversion notification that is sent, whether there were
un-notified diversions between that diversion and the previous
{diversion that was notified}.

Hmmmm...  This entire discussion is unsatisfying, and the problem
seems to revolve around getting "filtering" to deliver the information
we want to each subscriber.  Interestingly, I just discovered RFC
4660 "Functional Description of Event Notification Filtering", which I
was not aware of.  I think I will read it before commenting further on
this subject...

OK, I've looked over 4660 and 4661.  From a theoretical point of view,
they introduce "trigger" filtering, the ability to specify which state
changes are to be notified to the subscriber.  This extends the RFC
3265/6665 model, within which the subscriber cannot prevent
notification of state changes which are visible to the subscriber.

If we admit the possibility of trigger filtering, then we can solve
most of the comm-div problem by defining the state to be the
comm-div-ntfy-info element describing the *latest* diversion.
Whenever a new divershion happens, that state changes and could
trigger a notification.

(However there still is the problem if there are two identical
diversions within the same second; in that case, the state does not
change.  You really need to add a unique identifier element to
comm-div-ntfy-info to cover that.)

Assuming that the event notification framework has been enlarged to
admit trigger filtering, comm-div-ntfy-trigger-criteria is just
another way to specify triggering.

Getting back to CDIVN, that's harder to fit within the SIP event
model.  You could make it work something like is done with
call-completion, that part of the state is the CDIVN status of all the
subscriptions, but each subscription is only allowed to see its own
CDIVN status.

The underlying problem is that it's a bad idea in general to have
state specifically associated with *subscriptions*.

In this case, I don't see much value in the ternary value.  All it can
tell the receiver is that, since the previous notification, there was
a diversion but the subscriber wasn't notified about it.  It seems to
me that there two possible use cases:

1) The subscriber expects that all diversions will match its filters.
In this case, the subscriber would not need to provide any filters
(since that would just add processing overhead).  And if there were
diversions for reasons that were unexpected by the subscriber, it
could discover that itself, by examining the diversion notifications.

2) The subscriber expects that there are diversions that it will match
the filters it provies.  In this case, the ternary value would simply
tell the subscriber what it expects, that there have been diversions
that it has not been notified of.

The only use case where the ternary value would be helpful is if there
was a desire to know *that* diversions had happened, but that prompt
notification was not needed, and the details of the diversion were not
needed.

Dale