Subject: RE: Canceling Event Detection [FINAL?]

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 11 Apr 2001 15:34:20 -0400

OK, let's sum up the issues which have been raised on this excellent thread.
First, there is the syntax issue: the current syntax for EventsDescriptors
and EventBufferDescriptors (also affected) is

ASN.1:

EventsDescriptor ::= SEQUENCE
{
	requestID  		RequestID,
	eventList  		SEQUENCE OF RequestedEvent,
	...
}

SecondEventsDescriptor ::= SEQUENCE
{
	requestID 			RequestID,
	eventList 			SEQUENCE OF SecondRequestedEvent,
	...
}

EventBufferDescriptor ::= SEQUENCE OF EventSpec

ABNF:

eventsDescriptor     = EventsToken EQUAL RequestID LBRKT 
                       requestedEvent *( COMMA requestedEvent ) RBRKT

; at-most-once of each
embedFirst      = EventsToken EQUAL RequestID LBRKT
               secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT

eventBufferDescriptor= EventBufferToken LBRKT eventSpec
                       *( COMMA eventSpec) RBRKT 

If, as Terry believes, a SEQUENCE can have zero members, the ASN.1 can say
that there are no events to be monitored.  The ABNF needs changing.  We can
come to what it should be in a moment.

The second point is that the RequestID is still there, even in the ASN.1.
One suggestion is that the MGC assigns a RequestID the same way it always
does, even if that will never be used in an event report.  This has the
advantage of making the protocol more regular and minimizing the extent of
change. Another is to omit the RequestID if there are no events.  This has
the advantage of reducing message size.  It also follows the precedent set
in section 7.1, which uses the descriptor token alone to connote an empty
descriptor in transaction replies.

A third point is the suggestion that we have to spell out in section 7.1.9
what an empty Events or EventBuffer Descriptor means, and what happens to
buffered events collected in LockStep mode when the new Events Descriptor is
empty.  There was the further suggestion that we must distinguish in that
section between an empty embedded Events Descriptor and no embedded Events
Descriptor, but I think the syntax will make that distinction clear.

Here is my reading of the way forward.  If someone has other views, the
question mark after the "FINAL" in the title leaves room for discussion.

(1) I started out by opting for a minimum-change solution.  However, I found
I was in difficulty to explain the resulting syntax, given how we represent
empty descriptors as return values.  There is actually a difference between
how the ASN.1 and the ABNF do this, but at least the semantics are the same.
I therefore propose that we try to aim for maximum consistency rather than
minimum change.  In this spirit, the ASN.1 syntax changes by making
RequestID OPTIONAL, while the ABNF changes by making everything after the
token optional:

ASN.1:

EventsDescriptor ::= SEQUENCE
{
	requestID  		RequestID OPTIONAL,
	eventList  		SEQUENCE OF RequestedEvent,
	...
}

SecondEventsDescriptor ::= SEQUENCE
{
	requestID 			RequestID OPTIONAL,
	eventList 			SEQUENCE OF SecondRequestedEvent,
	...
}

EventBufferDescriptor ::= SEQUENCE OF EventSpec (unchanged)

ABNF:

eventsDescriptor     = EventsToken [ EQUAL RequestID LBRKT 
                       requestedEvent *( COMMA requestedEvent ) RBRKT ]

; at-most-once of each
embedFirst      = EventsToken [ EQUAL RequestID LBRKT
               secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT ]

eventBufferDescriptor= EventBufferToken [ LBRKT eventSpec
                       *( COMMA eventSpec) RBRKT ] 

(2) We absolutely have to document when omission of the RequestID is valid.
I propose the following additional sentence at the end of the first
paragraph of section 7.1.9:

"The RequestIdentifier is omitted if and only if the EventsDescriptor is
empty (i.e. no events are specified)."

(3) We should document the effect of a new empty Events Descriptor on
buffered events.  While we're at it, we might as well document the basic
effect of empty descriptors.  I therefore propose this paragraph to be added
at the end of section 7.1.9:

"An empty Events Descriptor disables all event recognition and reporting.
An empty EventBuffer Descriptor disables all event accumulation in LockStep
mode: the only events reported will be those occurring while an Events
Descriptor is active.  If an empty Events Descriptor is activated while the
termination is operating in LockStep mode, all buffered events are
discarded."  

> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Thursday, April 05, 2001 4:41 PM
> To: Megaco Mailing List
> Subject: Canceling Event Detection
> 
> 
> When a new EventsDescriptor or SignalsDescriptor are received they
> replace any existing EventsDescriptor or SignalsDescriptor for the
> specified termination(s).  An empty SignalsDescriptor can be sent to
> turn off all signals, but an empty EventsDescriptor is not allowed by
> the ABNF syntax for text encoding.  I believe that it IS permitted by
> the ASN.1 for binary encoding (SEQUENCE permits zero instances unless
> otherwise stated).  So there appears no way with 
> text-encoding to cancel
> all event detection once activated - one can only replace the 
> event with
> a new event.  Isn't it important to be able to canel event detection?
> 
> Am I missing something or is this an error.  I see no corrections for
> this in the implementor's guide.
> 
> --
> ------------------------------------------------------------
> Terry L Anderson              mailto:[email-masked]
> Tel:908.582.7013   Fax:908.582.6729
> Pager:800.759.8352 pin 1704572   [email-masked]
> Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> 
>