Subject: Buffered Events

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Sep 1999 16:29:45 -0400

Sometimes it happens that repeated editing of text with the best of
intentions has the result of totally confusing
everyone.  Such appears to be the case with "Buffered Events".  Some of
these issues may have been covered before
and I simply don't remember, but even I am confused by
the current text :(

Buffered events have two sources.  One is where you simply
don't Notify just because you have an event, you buffer
them and send them under some other circumstance.

The other is what MGCP calls "quarantined" events.
In MGCP an event that occurs before the occurrence of
an EventDescriptor that said what to do with them was
specified was kept in a Quarantine Buffer.  These were
subsequently metered out to the MGC when it had an
EventDescriptor that told it what to do.

In Megaco, we don't officially have anything labeled
Quarantine.  We just have an Event Buffer.

A Megaco Event Descriptor has an Action property, which
can be set to Notify (immediate transmission of Notify when
event is detected), Accumulate (put in Event Buffer) and
Accumulate by Digit Map (apply a digit map, accumulating
events until a terminal match occurs).  That is how you
get Events into the Buffer.

There is are two properties in TerminationState:
        Processing - which can be set to Process or Discard
        Notification - which can be set to loop or step

I can tell you how MGCP uses it's similar controls, but I
can't explain what MEGACO does!

First of all, do we allow Quarantine?
        What happens to an event that has no EventDescriptor
                associated with it?
I'm inclined to say that because we can have events in the
null context, we don't need quarantine, but I'm open to
scenarios that require it.

Next we ask, how do events get out of the event buffer?
First we have to ask - what is the event buffer doing for
us?

It delays notification until some later time.  When is that
time?  What does the MGC do to get those events?

In MGCP, the process/discard and loop/step apply to the
quarantine buffer.  Do we need them for the event buffer?
Would loop/step/process/discard be combined into:
        hold/empty/step/discard
Where   hold was keep accumulating
        empty was send all notifications all at once
        step was send one notify if any exist
        discard was toss all of the events remaining away

How do we trigger a "step"?  maybe you get one on the
assignment of the property to step, and one more after each
notify accept.

Help!
Brian

---

From: Nancy-M Greene <[email-masked]>
Date: Thu, 9 Sep 1999 17:32:01 -0500

Brian, I thought this was clear, but you are right, I think we can improve
upon the text that is there. This is my understanding of how things work:

Loop/Step and Discard/Process are set as part of the termination state.

Loop = send a Notify upon detection of the event from the
    EventsDescriptor as many times as you see it
Step = send a Notify upon detection of the event from the
    EventsDescriptor only once - and if there are more than one
    event in the EventsDescriptor, you send a Notify on the first
    one found and then send no more.

Discard = discard events detected that are not in the
    EventsDescriptor
Process = save in the EventBuffer all events detected, even
    if they are not in the current EventsDescriptor. The buffer is cycled as
it
    fills up. Events are discarded from the buffer when they are about to be

    processed if they are not in the EventsDescriptor

If you have Loop & Discard, then you save events in the EventBuffer that
match events in the EventDescriptor, but discard all other events.

If you have Step & Discard, you do not save any events in the EventBuffer -
the first event that you detect that matches the EventsDescriptor is sent in
a Notify, and you discard any other events detected.

If you have Loop & Process, you send a Notify each time you have an event
that matches one in the EventsDescriptor, and you save all events in the
EventBuffer.

Of course, any time you send an event in a Notify, it is removed from the
EventBuffer. And you process the EventBuffer as first in first out.

For example, with an Event Descriptor as Events = 1111 {e1,e2,e3}, and this
list of events,

e1, e3, e2, e6, e3, e7, e3:

With Loop & Discard, you would get
Notify = termID {ObservedEvents =1111 {timestamp:e1}},
and e3, e2, e3, e3 in the EventBuffer. e6 and e7 are discarded.

With Loop & Process, you would get
Notify = termID {ObservedEvents =1111 {timestamp:e1}},
and e3, e2, e6, e3, e7, e3 in the buffer. Notifies for e3, e2, e3, e3 would
be sequentially sent after that, that is what Loop means. If a new Events
=1112 {e7} is sent before you get to the e7 event, it overwrites the
previous EventsDescriptor, and you would toss out events in the buffer till
you get to e7, and then send a Notify for that one.

With Step & Discard, you would get
Notify = termID {ObservedEvents =1111 {timestamp:e1}},
and the other events would be discarded.

With Step & Process, you would get
Notify = termID {ObservedEvents =1111 {timestamp:e1}},
and then e3, e2, e6, e3, e7, e3, would sit in the buffer, waiting for a new
EventsDescriptor.

Question1: can you send a new Notify for the next event before getting a
Notify Reply from the MGC? In other words, can you have an outstanding
transaction before sending a new one?

Question2: what is the difference between the requestedAction Accumulate put
on the EventsDescriptor, and the terminationBuffered Process token?
Accumulate means put events detected in the EventBuffer. Perhaps Process is
more general - it means put all events detected in the EventBuffer, but
Accumulate means only accumulate events matching the EventsDescriptor. What
if you have Accumulate on the EventsDescriptor, and Discard on the
termination? And when are events accumulated ever processed?

I think we need to get rid of the Accumulate requestedAction, but keep
Notify, and AccumulateByDigitMap. If we do this, I would rename Process to
be Accumulate.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

> ----------
> From:         Brian Rosen[SMTP:[email-masked]]
> Sent:         Tuesday, September 07, 1999 4:29 PM
> To:   [email-masked]
> Subject:      Buffered Events
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 10 Sep 1999 12:07:16 -0400

This helps, but not enough

>     EventsDescriptor as many times as you see it
This is what we would probably think as "normal", right?

>     one found and then send no more.
I'm confused about this.  As best I can figure, the use for this is
you get one event at a time, then you send another eventDescriptor to rearm.

Is that right?  Why would an MGC want such an option?

> Discard = discard events detected that are not in the
Is this really all there is?  What if there are events in the
EventBuffer, does it clear them?

>     processed if they are not in the EventsDescriptor
This seems wrong.  It means there really isn't any way to do the
"quarantine" thing that MGCP has.

> match events in the EventDescriptor, but discard all other events.
If you have loop, you don't buffer - as you get events you
Notify them.  I would say this is:
        Notify all events in the EventsDescriptor as they arrive
        Discard all events not in the EventsDescriptor as they arrive
        If any events were in the EventBuffer when this setting was
          made:
                Discard events in the buffer not matching events in
                        the EventsDescriptor
                Immediately Notify any events in the buffer thst match
events in the EventsDescriptor

> a Notify, and you discard any other events detected.
So this is pretty braindead - you lose events that come in
before a rearm (by reloading the event descriptor)

> that matches one in the EventsDescriptor, and you save all
So this is "give me anything I know about, save what I don't"
Who would use this?

Step and Process is the one you left out.  I take it would be
save all events.  When an eventDescriptor comes, if there are
any events matching something in the buffer, Notify the first one.
If there aren't, Notify the first event that matches the EventDescriptor and
save any other events, matching or not,
in the buffer.

This means there isn't the one you really want which is:
        If the event buffer has a matching event, send ONE
        If there events not in the event list in the buffer, delete them
        If there are no events in the buffer, and one comes in
                matching the EventsDescriptor, Notify it
        If there are no events in the buffer and one comes in
                not matching the EventsDescriptor, discard it
        If an event matching the eventDescriptor arrives after
                a Notify has been sent, add it to the event buffer.

This would be a don't lose any, but let me control the rate

Seems like these are not the right set of controls.

We want:
        keep events I care about, throw others away, vs keep everything
        Send one thing at a time vs send everything
        Empty the event buffer now

> transaction before sending a new one?
I'd say, yes

> Notify, and AccumulateByDigitMap. If we do this, I would
Okay with me