Subject: Re: Signalling Failure

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 25 Apr 2000 00:10:10 -0400

In my opinion the proper solution would be to add the mask to the individual
signals rather than the completion event, because "failure" may be different
for different signals.  For instance, interruption by an event is normal for
dial tone, but abnormal for outpulsing of digits.  I hesitate to add yet
another parameter, of sub-list type at that, to the basic signal mechanism.
Maybe the real problem is that the original mechanism is mis-specified: the
interesting event is that of  the signal not completing in the way expected,
rather than completing.  The way forward may be to replace
"notifyCompletion" with an optional parameter "expect", with possible values
"timeout" or "event", representing the expected way the signal terminates.
If "expect" is present and the signal does not complete in the expected way,
a signal failure event is reported (new name for the signal completion
event, nothing else changes).  If "expect" is absent, a signal failure event
is reported if and only if the event terminates due to other causes (not TO,
not event, not replacement of the signalling descriptor).

> -----Original Message-----
> From: Flemming Andreasen [SMTP:[email-masked]]
> Sent: Tuesday, March 07, 2000 8:28 PM
>
> 5) 7.1.11, second paragraph:    The granularity of the signal completion
> event defined in E.1.2 is too coarse. There is for example no way to be
> informed of just failures (which would seem generally desirable) without
> being more or less flooded by the other completion reasons as well (some
> of which are more questionable). One simple way out of this is to extend
> the definition of the signal completion event to include
> EventsDescriptorParameters where the TerminationMethod(s) of interest
> could be specified. Also, the term "notifyCompletion" is somewhat of a
> misnomer.
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Apr 2000 15:02:46 -0700

Tom-PT Taylor wrote:

>
>
> In my opinion the proper solution would be to add the mask to the
> individual signals rather than the completion event, because "failure"
> may be different for different signals.  For instance, interruption by
> an event is normal for dial tone, but abnormal for outpulsing of
> digits.

Good point.

> I hesitate to add yet another parameter, of sub-list type at that, to
> the basic signal mechanism.  Maybe the real problem is that the
> original mechanism is mis-specified: the interesting event is that of
> the signal not completing in the way expected, rather than
> completing.  The way forward may be to replace "notifyCompletion" with
> an optional parameter "expect", with possible values "timeout" or
> "event", representing the expected way the signal terminates.  If
> "expect" is present and the signal does not complete in the expected
> way, a signal failure event is reported (new name for the signal
> completion event, nothing else changes).  If "expect" is absent, a
> signal failure event is reported if and only if the event terminates
> due to other causes (not TO, not event, not replacement of the
> signalling descriptor).

Not sure I see much of a difference between "expect these, tell me about
others" and "tell me about these" but it seems like we agree on the
basic issue. Also, I like your idea about having a set of default
failures you report unless modified by a list - the default you provided
seems good to me.

-- Flemming

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839