Subject: Re: Errors and Error Codes

From: Tom-PT Taylor <[email-masked]>
Date: Sat, 12 Feb 2000 13:59:31 -0600

Replies below.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:[email-masked]]
> Sent: Friday, February 11, 2000 9:29 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Cc:   [email-masked]
> Subject:      Re: Errors and Error Codes
>
>
>
> Tom-PT Taylor wrote:
>
> > This E-mail covers several topics dealing with error reporting.
> >
> > A. Asynchronous Error Reporting
> > ========================
> >
> > We have discussed, here in Geneva, a mechanism for generating
> spontaneous
> > notifications of error conditions (i.e. use of the "cause" event in the
> > generic package).  The suggested mechanism is this:
> >
> >   -- we reserve a block of event request-IDs (e.g. 0-15) for assignment
> to
> > classes of event the MGC will always want enabled (or alternatively can
> > enable or disable using a Root property).  As an example of use, we
> assign
> > requestID 0 to spontaneous error reports.  This way it won't be
> necessary to
> > include the cause event in every Event Descriptor
> >
>
> I agree with the goal, but I'm not sure I agree with the solution (could
> be I
> just misinterpreted it), so let me ask a couple of questions for
> clarification:
>
> Does this mean, that if I play a signal that succeeds, I will get a
> completion
> event through the normal channels and with a RequestID matching my
> request, but
> if it fails, it will come through this other channel using one of these
> special
> RequestIDs ?
        [[TomT]]
        That's correct.  Mind, if the completion event is left as it is now
defined in -megaco-protocol-06, you will ALSO get a signal completion event
with RequestID matching the request and termination method "FL".  This can
be changed -- it was due to be taken out in the wake of discussion on the
list indicating a preference for using the Cause event.

> What about ordering ? Will I be guaranteed to receive the error before any
> other
> subsequent events on the termination ?
        [[TomT]]
        Somewhere -- presumably in the Events section -- we should state
that the MG must report events in the order in which they occur.  Does this
meet your requirement?

> >
> >   -- rather than making errorDescriptor an optional component of the
> Notify
> > command (as our ABNF now states), we make it a parameter of the cause
> event.
> >
> >   -- this mechanism allows the inclusion of some error codes in our list
> in
> > section 7.3 which otherwise shouldn't be there because they would not
> result
> > from transaction processing.  One example is 518 "event buffer full".
> >
> >
>
> <<stuff deleted>>
>
> -- Flemming
>
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 14 Feb 2000 06:07:21 -0500

Hi Tom

Thanks for the clarifications - now I have some comments below.

Tom-PT Taylor wrote:

>      >   -- we reserve a block of event request-IDs (e.g. 0-15) for
>      assignment to
>      > enable or disable using a Root property).  As an example of
>      use, we assign
>      I agree with the goal, but I'm not sure I agree with the solution
>      (could be I
>      Does this mean, that if I play a signal that succeeds, I will get
>      a completion
>      event through the normal channels and with a RequestID matching
>      my request, but
>      if it fails, it will come through this other channel using one of
>      these special
>      RequestIDs ?
>      [[TomT]]
>      That's correct.  Mind, if the completion event is left as it is
>      now defined in -megaco-protocol-06, you will ALSO get a signal
>      completion event with RequestID matching the request and
>      termination method "FL".  This can be changed -- it was due to be
>      taken out in the wake of discussion on the list indicating a
>      preference for using the Cause event.
>
I would rather leave it the way it is as the above alternative is a
recipe for race conditions. If I understand correctly, you are simply
trying to optimize the flows by not requiring certain events to always
be included in the EventsDescriptor. I can't think of a reason why you
would want to report these differently than all other events. Seems like
a recipe for race conditions to me.

>
>      What about ordering ? Will I be guaranteed to receive the error
>      before any other
>      that the MG must report events in the order in which they occur.
>      Does this meet your requirement?
>
Yes it does, but if you start reporting through different channels with
a couple of reserved and "special" RequestIDs then you start
complicating things. Ensuring ordered delivery here seems unnecessarily
complicated and could easily cause a serious synchronization penalty
which you would not have to deal with if you used the normal event
reporting channels.
It seems like you are effectively implementing SNMP traps although it's
not clear how the MGC can actually control which of these "persistent"
events it actually wants to hear about.

>
>
>      >
>      >   -- rather than making errorDescriptor an optional component
>      of the Notify
>      > command (as our ABNF now states), we make it a parameter of the
>      cause event.
>      >
>      >   -- this mechanism allows the inclusion of some error codes in
>      our list in
>      > section 7.3 which otherwise shouldn't be there because they
>      would not result

-- Flemming