Subject: FW: [Softswitch-MGCP]: Signals & Events

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 3 Sep 1999 10:22:28 -0500

Jerry's discussion is raising good points that should be addressed in the
Megaco/H.248 base spec. where they apply.

> -----Original Message-----
> From: Kamitses, Jerry [SMTP:[email-masked]]
> Sent: Friday, September 03, 1999 8:42 AM
> To:   Michael Thomas
> Cc:   [email-masked]; [email-masked]
> Subject:      RE: [Softswitch-MGCP]: Signals & Events
>
> I agree with right to left too. There were
> a couple of other points in your email that
> I'm not sure I fully understand, which is good
> since it caused me to reexamine my assumptions
> regarding ways in which signals and events are
> meant to be used ...
>
>
> > For TO and OO, that means that processing
> > MUST proceed (i.e. they're asynchronous) and
> > that BR SHOULD be posted asynchronously as well.
> ...
> > the only time a BR signal would be canceled is if
> > there were a prior event request (either in the
> > current command or via a previous request).
>
> As I understand your comment, for the following
> sequence of signal types occurring (left-to-right)
> in one SignalRequests line (and guessing that such a
> sequence might have a valid signaling application --
> though regardless, we still should be able to define
> what it means):
>
>     OO TO BR BR BR
>
> At the point that we start to operate on these
> signals:
>        OO: execute the state change (ON or OFF)
>        TO: start generation of the timer based signal
>  BR BR BR: post the three remaining signals to be
>            generated when TO signal termination occurs.
>
> The TO signal terminates either when the timer
> expires OR some event occurs which appears in
> the current RequestedEvent set which does not
> have "K" among its actions.
>
> I'm not clear on whether or not there is (should be?)
> some condition capable of canceling the posted
> BR signals ?? My sense is that the sequence should
> be considered atomic and non-preemptable -- except that
> TO signals could terminate prematurely due to event
> detection.
>
> Even for the case where the event causing premature
> termination of the TO also has action "E"
> (instantiating a new event-set), or the case that a
> new RequestNotification is received, it still seems
> like the best rule is that the all the signals in the
> set should be generated?
>
> If there is some case where the three BR signals
> should not unconditionally follow the TO signal
> then they should instead be moved into subordinate
> embedded SignalRequests that would be "chained"
> from the event-set with the TO signal.
>
> It was this later consideration that gave rise
> to the (apparent) need for an event that we could
> use when the TO signal ended "normally" ... so that
> we could optionally chain to a different embedded
> event set for this case.
>
>
>
> > it ought to be parametric with the
> > operation with which it is completing (eg:
> > oc(rbk)).
>
> This is a good suggestion, but it's not clear
> from your suggested syntax whether the definition
> of this signal-completion-event would appear in
> the SignalRequests or RequestedEventd parameter line?
>
> > One thing that we should *not* be doing
> > is using oc for the kinds of things that
> > provisional responses are meant to take care
> > of.
>
> I don't quite get this comment but I sense once
> I have I will learn something. For the
> RequestNotification command with a set of one
> (or more, if embedded) SignalRequest parameters,
> then is there supposed to be some kind of connection
> between the ACK response to the command and the actual
> generation of any requested signals? I assumed
> this was not the case and that ACK only indicated
> the request was valid and accepted for processing?
>
>
> > I personally think that when gateways realize a
> > package and advertize that, they should realize
> > the *whole* package, not just bits and pieces of
> > it.
>
> I agree with the philosophy on this point, but am
> unsure of how it applies to G/pat(###), smack
> dab in the midst of the "generic" package?