Subject: Questions relating event processing and LockStep

From: Dan Elbert <[email-masked]>
Date: Wed, 3 Jan 2001 11:16:50 -0500

Hi All,
   A couple of things about LockStep use doesn't seems clear to me in the
   text:

   "If the value of the EventBufferControl property equals LockStep,
   following detection of such an event, normal handling of events is
   suspended. Any event which is subsequently detected and occurs in the
   EventBuffer Descriptor is added to the end of the EventBuffer (a FIFO
   queue), along with the time that it was detected."

   It seems from this that the first event that is detected after
EventBufferControl
   is set to LockStep is still process normally, and only subsequent events
are added
   to the buffer. Is this true ? If so, what is the purpose of this behavior
?

   "The MG SHALL wait for a new EventsDescriptor to be loaded.
   A new EventsDescriptor can be loaded either as the result of
   receiving a command with a new EventsDescriptor, or by activating
   an embedded EventsDescriptor."

   How can an embedded EventsDescriptor get activated ? The EventBuffer
Descriptor syntax
   doesn't include embedded EventsDescriptor. Is this an omission ? If not,
please explain
   how can an embedded EventsDescriptor be activated.

   Thanks

   Dan Elbert
   RADVISION

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 18 Jan 2001 18:23:25 -0500

Resend

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Tuesday, January 16, 2001 4:43 PM

Answers below.

> -----Original Message-----
> From: Dan Elbert [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 11:17 AM
> To: [email-masked]
> Subject: [MEGACO] Questions relating event processing and LockStep
>
>
>    Hi All,

[PTT] This is not true.  Here is what happens, step by step:
   (0) An EventsDescriptor is active and the MG is waiting for an event.
   (1) Event is detected.
   (2) Event is checked against the currently active EventsDescriptor and
found to be present.  (If it is not present in the EventsDescriptor, it is
ignored, and the system returns to step (0)).
   (3) Event is reported to the MGC.
   (4) The current EventsDescriptor is deactivated.
   (5) Another event is detected.
   (6) Event is checked against the EventBufferDescriptor and found to be
present.
   (7) Event is placed in the EventBuffer.
    [other events may be detected and queued in the EventBuffer.]
   (8+} A new EventsDescriptor is activated.
   (9) The queued events in the EventBuffer are checked in sequence against
the new EventsDescriptor and discarded until a match is found.  Events which
arrived after the matching one are left untouched in the EventBuffer.
   (10) The matching event (if any) is reported to the MGC and the cycle
goes back to step (4).

As you can see, the event detected in step (5) gets different treatment from
the event detected in step (1).

>    how can an embedded EventsDescriptor be activated.

[PTT] This covers the case when an embedded EventsDescriptor was present in
the EventsDescriptor which was initially active.  In other words, step (4)
above should actually be followed by step (4a): If the EventsDescriptor just
deactivated contained an embedded EventsDescriptor, the latter becomes
active and processing returns to step (0).

---

From: Sandeep Gautam <[email-masked]>
Date: Fri, 19 Jan 2001 10:54:47 +0530

G' Day Tom,

I think there are still some issues that remain unresolved.

I. The scenerio that you are referring to ( starting from step 0) assumes that
events descriptor was active and EBCP was set to lockstep. What happens when the
EBD was active and EBCP was set to lockstep ? Is it a NO OP or do we start from
step 0. Starting from step 0 seems more consistent approach.

II. You referred to activation of embedded ED in step 4, leading to step 4a,
where we return to step 1. This seems a consistent solution. But this is not the
only occasion that an embeedded ED can become activated. An embedded ED may
become activated in step 9 (i.e when an event in the FIFO buffer matches the new
ED, and the new ED contains and embedded ED for that event). This would lead to
a step 9a, where we should return  to step 8a (a new ED is activated).

III. Theonly other quabble is with regard to step 10. I guess, to follow a more
consistent approach, we should rephrase this as---
step 10: If an event was matched in step 9, it is reported to MGC and processing
returns to step 4 If an event was not matched, processing returns to step 0.
This way we will be ensuring that the MGC always knows the exact time when the
buffering of events had started. (i.e. after the first event notification was
sent for the ED).
Maybe we should add the algorithm for EBCP lockstep processing in the
implementor's guide.

Thanx.

Regards,
Sandy G