Subject: FW: Signals & Events

From: Nancy-M Greene <[email-masked]>
Date: Thu, 2 Sep 1999 09:48:33 -0400

Jerry, your questions here are of concern to the Megaco protocol as well, so
I have forwarded your msg to that list.

For Megaco/H.248, the MGCP RequestNotification, or RQNT, is an a Add or
Modify command, and SignalsRequests parameter line is a SignalsDescriptor.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

> ----------
> From:         Kamitses, Jerry[SMTP:[email-masked]]
> Sent:         Thursday, September 02, 1999 8:35 AM
> To:   [email-masked]; [email-masked]
> Subject:      Signals & Events
>
> A couple of additional questions have
> come up concerning MGCP V 1.0 which I'll
> go ahead and post on this list (though
> the low level of activity on this list
> suggests that real implementations of,
> and interest in, MGCP may be very few
> and far between?).
>
> 1) In the case that a RQNT command contains
> a SignalRequests parameter line containing
> multiple events, then what rules should be
> applied in determining the order of signal
> generation? Should signal generation be
> performed left to right, right to left,
> concurrently? What does it mean if a
> signal of type BR is followed by another
> signal of type BR (and similar questions
> arise when "BR" is replaced by "OO" or "TO")?
> Are these issues that should be considered
> signal specific and outside the scope of MGCP?
>
> 2) If the desired sequence is to perform some
> sequence of signal operations and THEN enable
> the reporting of a set of events (or report this
> event itself), it seems like it would be useful
> to have defined a universal event for all packages
> (a la "of") that represents having performed all
> signal operations in the current set of signals.
> One instance of this type of event is currently
> defined in the Announcement Package:
>   "oc" = report on completion.
> Perhaps this is a likely candidate to promote
> to provide this function for all packages?
>
> 3) We have interpreted the return codes 512 & 513
> (which indicate that a list of requested events
> or signals contains at least one for which the
> gateway is not equipped) to mean that not every
> event/signal in a particular package requires
> mandatory support by the gateway. We are then a
> little unclear regarding what it means for the
> Gateway to return Capabilities that say that a
> particular package is supported by an endpoint?
> Is it sufficient if at least one event in the
> package is supported (other than the trivial "of")?
>
>