Subject: Proposal for EventHandling

From: Chip Sharp <[email-masked]>
Date: Thu, 10 Feb 2000 02:50:54 -0500

There has been a fair amount of discussion on the megaco list concerning
EventHandling, mainly between Brian and Flemming.

The text and procedures that are in draft-ietf-megaco-protocol-06.txt are
also to be included in H.248 if it is approved.

It seems that there is an impasse in terms of the event handling mechanism.
I believe Brian and Flemming have expressed their views fairly well.

It seems most people are happy with the current (06) procedure.  Or at
least there doesn't seem to be anyone else objecting.

I believe that our suggestion to go back to the previous eventhandling
mechanism could be considered an optimization.  In my opinion it is an
important optimization and the current mechanism has some drawbacks, but I
don't think it is fundamentally broken (time will tell in both
cases).  There is a general working agreement to leave optimizations to
future versions or implementor's guides based on implementation
experience.  However, the current syntax is so restrictive that it
basically disallows making optimizations in future revisions.

In order to move things along, I propose the following:

1)  Maintain the procedure defined in 06 for event handling.

2) change eventbufferflag to EventBuffer and make enumerated instead of
Boolean.  Define two values initially:  On and Off.
The procedure remains the same.  the syntax allows extension in future
revisions if we need to make them without making up new flags or descriptors.

3) Change syntax of EventsDescriptor back to the way it was previously, but
only have the following actions allowed:
        KeepActive
        Notify
        AccumulateByDigitMap

In effect, this should maintain the previous syntax, but support the new
procedure.  In addition, it gives the flexibility to provide for new
actions in future versions if needed.

In going through the document, it seems very few changes would be needed to
effect this suggestion.  The biggest is the ABNF for EventsDescriptor since
it was changed substantially since the last release (I noticed Stream ID
has been added also).

I recommend changing the ABNF back to the previous ABNF for
EventsDescriptor but remove the offending Actions.  If there are
modifications of that section for other reasons please tell me.

I hope this is acceptable to the group.  I am also making this suggestion
at SG16 meeting for H.248 in the hopes of not repeating the event handling
arguments again here.

Chip

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 10 Feb 2000 09:08:25 -0500

I'm always open to compromise.  In this case, I have one
significant objection, and that is the return to "Action".
There are two problems:
        1. KeepActive is entirely separate from Notify.....
                it is not an Action = how do I handle this event,
                it is an override on signal/event interaction
        2. Process by digitmap is inappropriate; the Megaco
                method is to enable the completion event as well
                as specify a digitmap; you don't enable the dtmf
                digits and have a mystery event happen.
So, you would be back to Notify as the only action, with
KeepActive as a flag.  My suggestion is to adopt your proposal
on EventBufferFlag as an enumeration, leave the current syntax
except allow an explicit X- extension flag in the EventDescriptor
syntax as well as the EventBuffer enumeration.  This would allow an
experimental "Accumulate" flag to be implemented, which would give
you what Flemming wants:
        X-Accumulate setting for EventBuffer enumeration means
                Any event with the X-Accumulate flag is buffered
                Any event in EventsDescriptor not flagged X-Accumulate
                        would send the contents of the buffer

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:[email-masked]]
> Sent: Thursday, February 10, 2000 2:51 AM
> To: [email-masked]
> Subject: Proposal for EventHandling
>
>