Subject: unsubscribe

From: Aaron Bruneau <[email-masked]>
Date: Mon, 31 Jan 2000 11:29:42 -0500

unsubscribe

Stephen Terrill <[email-masked]>
11/17/99 07:56 AM

Please respond to Stephen Terrill <[email-masked]>

To:   [email-masked]
cc:    (bcc: Aaron Bruneau/ctcnet)
Subject:  Re: Washington Issue 21 - Property or Signal

Hi Peter,

Can you clarify what you mean for dynamic in nature and effecting information
flow.  If this was to mean anything that was not configuration, would this imply
that RTP port and remote IP address should be sent in signals as in my view they
are not configuration, and the do effect the information flow.

Thanks,

..//Steve

Peter Blatherwick wrote:

>
>
> Yes, we need some words of guidance in the Megaco Protocol
> document on intent of Signals vs Properties and when to
> define which type in a Package.
>
>      Problem
>      Several suggested packages used a signal as a sort of arbitrary
>      function call in a package.  It seemed to the authors that
>      signals had the requisite syntax - procedure name, named and
>      typed parameters.  Signals can be "instantaneous", so, why not?
>
>      The alternative is to use properties.  Typically, several
>      properties, representing the parameters, with some explicit
>      or implied invocation of a procedure.
>      ...
>
> I would like to think of Signals as being dynamic in nature,
> and moving information or affecting information flows from
> the IP world to the outside world.
>
> Properties should be thought of as more static in nature,
> and related to configuration.  Also, since Properties are
> currently defined as values, it is quite awkward to use
> them where method call-like semantics are required,
> as is the case in many packages.
>
> More detailed reasoning and examples are below, from
> a previous e-mail on this topic..  Please read.
>
> Actually, speaking for myself anyway, the intent in the
> package definitions was not to make "arbitrary function
> calls".  Rather, we tried to define based on purpose of
> the particular interface, as above.  (Remember, the
> Signals and Properties stuff was still firming up at the time
> the original package definitions were put together, so
> there may be a few things which do not currently line up
> with this intent.  This will be fixed.)
>
> BTW, there seem to be two Issue 21s.  I suspect one is
> enough ;-)
>
> -- Peter Blatherwick
>
>
> -----Original Message-----
> From:   Blatherwick, Peter [[email-masked]]
> Sent:   26 Oct, 1999 12:44
> To:     Taylor, Tom-PT [[email-masked]];
[email-masked]
> Subject:        Properties and Signals (RE: Megaco Events and Signals)
>
> Tom wrote:
> > ... I invite proposals on the distinction between signals and properties.
>
> Here are the distinctions I would draw.
>
> Signals are anything which can affect externally visible state of terminations
or the streams they carry in a dynamic way.  Since Signals currently support
parameters, this means some resolution can be achieved beyond pre-configured
default behaviour (e.g. playtone(id=x) vs playtone(id=x, timeout=y)), and
individual Signals can be reused across multiple actions (e.g. playtone(id=x),
vs playtoneX, playtoneY, ...).  Examples include:
>
> - playing of tones, announcements, etc
> - affecting line/truck state (e.g. on/off hook, etc)
> - manipulating user interface (e.g. turning indicators on and off,
>   writing to display, etc)
> (I know some will not agree with the latter example.  My reasoning is that
there is no underlying difference between sending audio streams to the end user
and sending any other sensory information.  Display, for example, definitely
sends sensory information to the user, and can be usefully looked at as
consuming streams of characters, for example in text conversation.  Also, user
interface needs the flexibility that parameters provide.)
>
> Properties are anything that affects configuration of terminations or the MG
as a whole, and are relatively static.  They may have externally visible effects
only indirectly through behaviour of Signals.  Since Properties are currently
single values (i.e. not parameterised "methods" like Signals), Properties must
be modelled by single values.  Examples include:
>
> - define/modify tone definitions
> - set timeouts and other package-specific defaults
> - set internal behaviour such as dtmf keypad echo
>
> Comments?
>
> -- Peter Blatherwick
>