Subject: 'EventBufferDescriptor' event handling

From: "Raju" <[email-masked]>
Date: Thu, 10 May 2001 10:59:28 -0400

Hi all,

This is attempt to resume the discussion on EventBufferDescriptor(EBD),
EventDescriptor(ED), EveventBufferControl(EBC) handling.

According to H.248 standard Add/Modify/Move commands can have both ED and
EBD (with EBC set to LockStep).

I guess the Gateways should process the events as follows:
1. An Event is detected
2. If ED is present
     Do regular processing (may result in Notify)
     If Notify is done
          if EBD is present and EBC is LockStep
                deactivate the ED (and this  'activates' EBD)
   else
     if EBD is present and EBC set to LockStep
        Buffer events (no Notify)
    Goto Step 1
3. These buffered events, if any, are processed when a new ED is loaded.
    The processing of these events is very similar to regular events.
    Steps in processing events in EB:
    a. Activate new ED
    b. For each event in EBD goto Step 2.
        This time (also) Step 2 might result in deactivating ED and
(re)activating the EBD if a Notify happens.
         The digitMap rules (partial match, no match, timing(?)) apply while
handling the EBD events, i.e. If the EBD events result in partial match,
         this partial match string is also used (not discarded!) for the
digitMap when new (DTMF) events are detected.

Please send your comments.
Thanks
Raju

Date:         Fri, 19 Jan 2001 10:54:47 +0530
Reply-To:     [email-masked]
Sender:       "Media Gateway Control (megaco)"
              <[email-masked]>
From:         Sandeep Gautam <[email-masked]>
Subject:      Re: FW: [MEGACO] Questions relating event processing and
LockStep
X-To:         Tom-PT Taylor <[email-masked]>
Content-type: text/plain; charset=us-ascii

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

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

[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).

>
>    "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.

[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).
>    Thanks
>    Dan Elbert
>    RADVISION