Subject: Re: Signalling Failure

From: "Rosen, Brian" <[email-masked]>
Date: Sun, 6 Feb 2000 21:55:50 -0500

I'd rather see failure with the general failure event.
I don't like exceptions.  The general failure event is there
for just this kind of thing - an asynchronous failure.
It has no catches, it's there when you want it.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Friday, February 04, 2000 7:13 PM
> To: Brian Rosen; Flemming Andreasen;
> [email-masked]
> Subject: Signalling Failure
>
>
> I've solved the signalling failure problem, maybe.  I add a
> parameter to the
> signal completion event indicating how the signal was
> terminated: timeout,
> event, new signal descriptor, or failure.  The catch is that
> failures are
> only reported for events for which notifyCompletion is TRUE.
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: [email-masked] (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>

---

From: Michael Brown <[email-masked]>
Date: Mon, 7 Feb 2000 09:09:59 -0500

I agree with this approach. It has the capability to be as specific as
needed with the failure cause parameter and as Brian points out, it is
always available for all packages.

Michael

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 7 Feb 2000 09:51:29 -0500

Yes, such an approach seems reasonable. However, the general failure event
(Cause in Generic I presume) then needs to be expanded a little. More
specifically, you must be able to specify that:
1. You had a signal failure
2. Which signal actually failed

-- Flemming

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------

---

From: Michael Brown <[email-masked]>
Date: Mon, 7 Feb 2000 10:22:11 -0500

I see your point. It should be fairly straightforward to do so though since
failurecause is an Octet string. Actually, I don't remember if Release Cause
has sufficient functional granularity or flexibility as is to indicate the
equipment which failed to produce the desired signal and don't have access to
documentation to verify. Any help out there on this?

Michael