Subject: Re: Washington Issue 21 - Property or Signal

From: Peter Blatherwick <[email-masked]>
Date: Tue, 16 Nov 1999 16:25:50 -0500

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

---

From: Stephen Terrill <[email-masked]>
Date: Wed, 17 Nov 1999 13:56:09 +0100

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:

> To:     Taylor, Tom-PT [[email-masked]]; [email-masked]
> 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:
>
> (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:
>