Subject: Properties and Signals (RE: Megaco Events and Signals)

From: Peter Blatherwick <[email-masked]>
Date: Tue, 26 Oct 1999 11:43:32 -0500

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: Michael Thomas <[email-masked]>
Date: Wed, 27 Oct 1999 08:18:59 -0700

> Also, user interface needs the flexibility that parameters provide.)

   The main problem I have with treating displays
   and keypads as signals is that it leads to an
   unfortunate reinvention of the wheel. Already,
   we can see bits and dregs of recreating all of
   the terminal driver essentials that ANSI and HTML
   have solved oh-so-many years ago.

   It would be far better to cut our losses here
   and draw a somewhat arbitrary distinction which
   says if it looks like a display or keyboard
   rather than a repository for a string or DTMF
   a keypad, it should be driven using a
   standardized protocol (say, telnet and ANSI or
   HTTP and HTML) with the appropriate profiles of
   each defined by some body (and I would argue
   that ITU or IETF are probably not the right
   place).

   This idea is already being pushed around
   in H.323 with HTML and I think that Dave
   Walker's idea for using ANSI sequences is a
   very good one, but doesn't really go far
   enough. What both H.323 and by extention H.248
   should do is broker the supplementary services
   instead of recreating them eg:

   playurl(telnet:emacsonaphone.org:23)

   or

   playurl(http://www.mtcc.com/~mike)

   What we should *not* do is try to reinvent
   wheels yet again. There is a *huge* amount of
   leverage we can take advantage of if we use
   standard ANSI enabled programs (via termcap
   and curses) and HTML ("cgibin"), and it would
   be comparatively trivial to create those
   applications with very off the shelf
   application development tools, as well as the
   ability to enable lots and lots and lots of
   third party applications -- unbound by the
   straightjacket of the controlling MGC -- almost
   for free.

               Mike