Subject: RE: Canceling Event Detection

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 6 Apr 2001 09:11:06 -0400

I think you both are right, an Empty Events descriptor should be allowed.
The ABNF:
   eventsDescriptor     = EventsToken EQUAL RequestID LBRKT  
                         requestedEvent *( COMMA requestedEvent ) RBRKT 
changes to:
   eventsDescriptor     = EventsToken [ EQUAL RequestID LBRKT  
                         requestedEvent *( COMMA requestedEvent ) RBRKT ]

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 1:15 AM
> To: Madhu Babu Brahmanapally
> Cc: 'Terry L Anderson'; 'Megaco Mailing List'
> Subject: Re: Canceling Event Detection
> 
> 
> G'Day,
> 
> Yes it does seem that this is desirable functionality whether its
> discussed on the list or not is beside the point. There are rules in
> H.248 for replacement and a completely empty descriptor is 
> not precluded
> Certainly if you set an event then you also want to be able to turn it
> off. 
> 
> Terry, Do you have a suggested change?
> 
> Christian
> 
> Madhu Babu Brahmanapally wrote:
> > 
> > Hi all,
> > I think the empty events descriptor in ASN.1 binary is only 
> because of its
> > definition. I think this is not the intent as the empty 
> event descriptor
> > topic was not discussed (I don't remember any such 
> discussion) on the list.
> > 
> > Regards
> > Madhubabu Brahmanapally
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of 
> Terry L Anderson
> > 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
>

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Fri, 6 Apr 2001 09:56:26 -0400

Hi brian,list,
Then there need to be change both in section 7.1.9 mentioning about empty
events descriptor and its usage. Might be IG should mention change in both
Event descriptor description and ABNF grammar.

Apart from that the ASN.1 lists requestID to be present even if eventList is
empty. Both ABNF and ASN.1 definitions need to be consistent.

Best Regards
Madhubabu

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, April 06, 2001 9:11 AM
To: 'Christian Groves'; Madhu Babu Brahmanapally
Cc: 'Terry L Anderson'; 'Megaco Mailing List'
Subject: RE: Canceling Event Detection

Brian

---

From: tla <[email-masked]>
Date: Fri, 06 Apr 2001 10:04:18 -0400

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

would be more consistent with the syntax for empty signalsDescriptor and with
the ASN.1, but does have the disadvantage of requiring a useless RequestID
value.  One can simply reuse the RequestID of the one being canceled or make up
a new one that will not really be used for anything.  The alternative would be
to change the ASN.1 to make the bare EventsToken legal and perhaps do the
similar thing for signalsDescriptor (which of course has no ID but does
currently still require the "{}").

I think that the smaller change that requires the unused RequestID is probably
preferable at this point.

--
-------------------------------------------------------
Terry L Anderson, DMTS                   [email-masked]
Lucent Technologies /INS/ Voice over IP Access Networks
Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
http://its.lucent.com/~tla  (Lucent internal)
http://www.gti.net/tla
-------------------------------------------------------

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Fri, 6 Apr 2001 11:08:14 -0400

The Request Identifier is used to correlate the request with the
notifications that it may trigger. In case of Empty events descriptor no
events are received hence its not logical to use the RequestId field which
has no significance. The ASN.1 also needs some change to make this field
optional.

Regards
Madhubabu.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of tla
Sent: Friday, April 06, 2001 10:04 AM
To: 'Megaco Mailing List'
Subject: Re: Canceling Event Detection

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

would be more consistent with the syntax for empty signalsDescriptor and
with
the ASN.1, but does have the disadvantage of requiring a useless RequestID
value.  One can simply reuse the RequestID of the one being canceled or make
up
a new one that will not really be used for anything.  The alternative would
be
to change the ASN.1 to make the bare EventsToken legal and perhaps do the
similar thing for signalsDescriptor (which of course has no ID but does
currently still require the "{}").

I think that the smaller change that requires the unused RequestID is
probably
preferable at this point.