Subject: [dispatch] draft-avasarala-dispatch-comm-div-notification

From: [email-masked] (Dale R. Worley)
Date: Fri, 2 Aug 2013 17:14:13 -0400 (EDT)

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