Subject: Re: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor

From: "Anil Jangam" <[email-masked]>
Date: Thu, 05 Jun 2003 16:14:53 +0530

MessageHi Kim,

See the answer from Tom in this regard. see below your mail.

regds,
/anil.

----- Original Message ----- 
From: Jay H Kim 
To: [email-masked] 
Sent: Thursday, June 05, 2003 2:38 PM
Subject: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor

When I parse the megaco Audit Response message, I stand a confusing text.

For following AuditValue Response message,
Does the "Events" indicate EventsToken in auditItem or empty eventsDescriptor?
=================================
MEGACO/1 [209.110.59.34]:25000
   Reply = 1235 {
      Context = 2 {
   AuditValue = EphA {
             Events,
             }
       }
   }
===================================

According t o the Annex B.2, terminationAudit can have eventsDescriptor or auditItem.
The eventsDescriptor can be empty(ie. EventsToken only) and the auditItem can have EventsToken also.

Could anyone give me the clarification for this?
Thanks forward.

G'Day

  ----- Original Message ----- 
  From: Tom-PT Taylor 
  To: 'Anil Jangam' ; Kevin Boyle 
  Sent: Wednesday, January 22, 2003 10:40 PM
  Subject: RE: [Megaco] auditReturnParameter in AmmsReply

  I suppose as the guy who concocted this syntax I should answer the question.  You return the auditItem.  That was my shortcut for returning descriptor name only.

  Apparently there is a parsing problem with this syntax, but we never seem to have taken the step of resolving it.
    -----Original Message-----
    From: Anil Jangam [mailto:[email-masked]] 
    Sent: Wednesday, January 22, 2003 12:26 AM
    To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]
    Subject: Fw: [Megaco] auditReturnParameter in AmmsReply
    Importance: High

    Hi,

    What should be the treatment for the case below??
    /anil.

    ----- Original Message ----- 
    From: Anil Jangam 
    To: [email-masked] 
    Sent: Monday, January 20, 2003 7:19 PM
    Subject: [Megaco] auditReturnParameter in AmmsReply

    hi,

    as per the AuditReturnParameter (inside ammsReply) definition, it is mentioned that it may contain the AuditItem. Also it may contain EventsDescriptor as well.

    auditReturnParameter = (mediaDescriptor / modemDescriptor /
                                  muxDescriptor / eventsDescriptor /
                                  signalsDescriptor / digitMapDescriptor /
                                  observedEventsDescriptor / eventBufferDescriptor /
                                  statisticsDescriptor / packagesDescriptor /
                                  errorDescriptor / auditItem) 

     ;at-most-once, and DigitMapToken and PackagesToken are not allowed ;in AuditCapabilities command
    auditItem            = ( MuxToken / ModemToken / MediaToken /
                                  SignalsToken / EventBufferToken /
                                  DigitMapToken / StatsToken / EventsToken /
                                  ObservedEventsToken / PackagesToken )

    In above case, if the EventDescriptor is received empty, then how the corresponding Token should be treated?? Should it be treated as empty EventDescriptor OR be as AuditItem?? What is the difference between these two??

    P.S.: The EventDescriptor is defined, where except token everything is optional:
    eventsDescriptor     = EventsToken [ EQUAL RequestID LBRKT
                               requestedEvent *( COMMA requestedEvent ) RBRKT ]

    *********************************************************
    Disclaimer

    This message (including any attachments) contains 
    confidential information intended for a specific 
    individual and purpose, and is protected by law. 
    If you are not the intended recipient, you should 
    delete this message and are hereby notified that 
    any disclosure, copying, or distribution of this
    message, or the taking of any action based on it, 
    is strictly prohibited.

    *********************************************************
    Visit us at http://www.mahindrabt.com

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

---

From: "Anil Jangam" <[email-masked]>
Date: Thu, 05 Jun 2003 16:14:53 +0530

MessageHi Kim,

regds,
/anil.

----- Original Message ----- 
From: Jay H Kim 
To: [email-masked] 
Sent: Thursday, June 05, 2003 2:38 PM
Subject: [Megaco] EventsToken in auditItem of teminationAudit or empty eventsDescriptor

G'Day

    -----Original Message-----
    From: Anil Jangam [mailto:[email-masked]] 
    Sent: Wednesday, January 22, 2003 12:26 AM
    To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]
    Subject: Fw: [Megaco] auditReturnParameter in AmmsReply
    Importance: High

    Hi,

    ----- Original Message ----- 
    From: Anil Jangam 
    To: [email-masked] 
    Sent: Monday, January 20, 2003 7:19 PM
    Subject: [Megaco] auditReturnParameter in AmmsReply

    hi,

---

From: Troy Cauble <[email-masked]>
Date: Thu, 05 Jun 2003 11:04:55 -0400

> The eventsDescriptor can be empty(ie. EventsToken only) and the auditItem can have EventsToken also.

The same is/was true of EventBufferToken, as well.

>   Apparently there is a parsing problem with this syntax, but we never seem to have taken the step of resolving it.

This was discussed in June of 2001 in the thread
'IG 6.79 "Cancelling Event Detection" breaks ABNF'.

This parsing problem was the start of the thread, but other
parsing problems were discussed as well.

Apparently folks thought the needed changes were to radical
to fix at the time.

I am attaching the last post to the thread, my proposed fixes.
It got no responses at the time.

I am not current enough with H.248 to know if the other 3
problems are still problems.

-troy

Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF
From: Troy Cauble <[email-masked]>
To: "Rosen, Brian" <[email-masked]>, Tom-PT Taylor <[email-masked]>, "[email-masked]'" <[email-masked]>, MEGACO list <[email-masked]>
Date: Tue, 09 Oct 2001 12:40:27 -0400

Greetings,

This old thread had some fairly serious problems that were never
resolved.  I am proposing changes for the problems in the text
encoding.  There is a larger issue to the ASN.1 problems -- I
will start another thread for that.

BACKGROUND

I'm told that auditItem's use in auditReturnParameter is to
represent empty descriptors.

                            errorDescriptor / auditItem )

But some of the descriptors in auditReturnParameter already have
empty forms.  This is the crux of problems #1, #2 (text) and #4 below.

PROPOSED CHANGES that fix #1, #2 (text) and #4 below

   signalsDescriptor    = SignalsToken [ LBRKT signalParm
                          *(COMMA signalParm) RBRKT ]

                            errorDescriptor / auditReturnItem )

   auditReturnItem      = ( MuxToken / ModemToken / MediaToken /
                           DigitMapToken / StatsToken /
                           ObservedEventsToken / PackagesToken )

   auditItem            = ( auditReturnItem / SignalsToken /
                           EventBufferToken / EventsToken )

An alternative approach would be to create empty forms for
the other 7 descriptors represented by auditItem and remove
the auditItem from auditReturnParameter.  But then those 
empty forms could be used elsewhere (ammParameter, notifyRequest) 
where they're apparantly not needed.

-troy

Troy Cauble wrote:
> 
> A summary of the problems discussed in this thread.
> 
> 1) In the text encoding, some empty descriptors have the form
>    "Signals {}" while others have "Events".
> 
> In a Termination Audit:
> 
> 2) There are two line encodings for an empty Signals descriptor
>    (text and ASN.1).
> 
> 3) There are two line encodings each for an empty Events descriptor
>    or Event Buffer descriptor (ASN.1 only).
> 
> 4) In the text encoding, EventsToken and EventBufferToken each
>    have reduce/reduce conflicts because they can represent either
>    an auditItem token or an empty descriptor in the auditReturnParameter.
> 
> -troy
> 
> 
> 
> "Rosen, Brian" wrote:
> >
> > I agree with Tom; we did a pass over the ABNF to try to make
> > all of the empty forms not have braces.  The choice was
> > completely arbitrary, and as I recall, we decided since it
> > didn't make any real difference, shorter was better.
> > If we missed one, we goofed.
> >
> > Tom, the problem here seems to be real.  As Troy says, you will get
> > a reduce conflict in a rules-based parser with this ambiguity.
> > I'm pretty sure you can ignore the problem, but it's poor design
> > practice.  You will recall all of the effort Abdallah and Nancy
> > went through to test out these kinds of things as we developed
> > the ABNF.  The IG change wasn't verified in the same way, thus
> > we have this problem.  We need to decide what to do.
> >
> > Brian
> >
> > > > Tom-PT Taylor wrote:
> > > >
> > > > I'm the one responsible for all this.  I suppose I should
> > > dig up the thread.
> > > > Anyway, the intention was definitiely to provide a way of
> > > signalling empty
> > > > descriptors.  I think we chose rather arbitrarily between
> > > the desc{} and desc
> > > > form, opting for the latter.
> > >

---

From: Troy Cauble <[email-masked]>
Date: Thu, 05 Jun 2003 11:04:55 -0400

-troy

Greetings,

BACKGROUND

-troy

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 05 Jun 2003 12:36:31 -0400

See "6.3 Empty Descriptor Syntax" in IG.
http://standard.pictel.com/ftp/avc-site/0305_Gen/H.248_IG.zip
         Aleks

At 11:04 AM 6/5/2003, Troy Cauble wrote:

>>   Apparently there is a parsing problem with this syntax, but we never 
>> seem to have taken the step of resolving it.
>
>
>Message-ID: <[email-masked]>
>Reply-To: Troy Cauble <[email-masked]>
>X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
>X-Accept-Language: en
>MIME-Version: 1.0
>To: "Rosen, Brian" <[email-masked]>,
>         Tom-PT Taylor <[email-masked]>,
>         "[email-masked]'" <[email-masked]>, MEGACO list <[email-masked]>
>References: 
><[email-masked]> 
><[email-masked]>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>
>Greetings,
>

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 05 Jun 2003 12:36:31 -0400

---

From: Troy Cauble <[email-masked]>
Date: Thu, 05 Jun 2003 14:23:57 -0400

> http://standard.pictel.com/ftp/avc-site/0305_Gen/H.248_IG.zip

Hah!  I had forgotten!  I haven't been focused on H.248 lately.

Nitpick:  The title for that section of the IG says
it's for "v1".  This might mislead people.

Thanks,
-troy

---

From: Troy Cauble <[email-masked]>
Date: Thu, 05 Jun 2003 14:23:57 -0400

Thanks,
-troy