Subject: Re: Washington Issue 21 - Property or Signal

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Nov 1999 16:47:13 -0500

I rather like the definitions you propose.  I'd be one to think that display
is
on a media stream, but it depends on it's use I suppose (a softkey label vs
a page of teletext).  Really, this is the debate raging on the SIP list on
whether
SIP ought to transport DTMF or rely on the RTP DTMF payload.
 
And, uh, yes, there are two issue 21s.  Let's call this one 21a, since it
came out
first.  The other one is 21b :)
 
Brian

-----Original Message-----
From: Peter Blatherwick [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 4:26 PM
To: 'Brian Rosen'; [email-masked]
Subject: RE: Washington Issue 21 - Property or Signal

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: Peter Blatherwick <[email-masked]>
Date: Thu, 18 Nov 1999 10:07:40 -0600

Steve, list:

In what I would consider Signals in my definition, by "dynamic in nature and
dynamic in nature, and moving information or affecting information flows", I
mean things that are changeable on the fly as part of control of the MG, or
can be applied to streams during normal operation of calls.  The non-IP
network sees these as state changes during call operations, or the end user
sees/hears them as part of using the device to make/answer/manipulate calls.
(Realising that Megaco does not really think about "call" per se at the MG
level, the example remains useful.)  By example, candidates for signalling
would be anything that diddles user interface as part of application flow
(updating display, turning indicators on and off, softkey updates, alerting,
etc), application of call progress and dialling tones on streams,
manipulation of line/trunk state, playing of announcements, etc.

By contrast, Properties would not have direct effect on either the end user
or the non-IP network, but would alter the behaviour of the MG from a
control point of view by changing timeouts, setting tone definitions, etc.

I would NOT intend for things like IP addresses and RTP ports to be carried
in SignalsDescriptors in general.  (There might be some special cases I
suppose.)  These belong elsewhere in the command structure.

I'm not sure I've added to understanding above.  Wording for these types of
concepts is always hard.  I don't know how much of my life I have spent down
rat-holes trying to define the differences between "service", "application",
"component" and such.  I'm sure many of us have.  Thank goodness we are not
trying to define "agents" ;-)

-- Peter

> From: Stephen Terrill [SMTP:[email-masked]]
> Sent: 17 Nov, 1999 07:56
> To:   Blatherwick, Peter [CAR:AT14:EXCH];
> [email-masked]
> 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:
>
>
>
> 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:
>

---

From: Peter Blatherwick <[email-masked]>
Date: Thu, 18 Nov 1999 11:18:29 -0500

Christian, list:

While I agree this should be thought through on a case-by-case basis in
package design, I believe it is quite useful to put some words of guidance
around the intended use of Signals and Properties.

Package designers would benefit by having some conceptual framework on which
to base decisions.  Package users (i.e. application designers) would know
where to look for what type of function, and would have an improved
understanding of intent.  And we protocol designers would benefit by
clarifying our own thinking on what these concepts are intended to implement
in the end, to make sure they really do what we want.  (I think they do by
the way, assuming we can sort out the last few details on operation of
Signals and Events.)

-- Peter

> From: Christian Groves [SMTP:[email-masked]]
> Sent: 17 Nov, 1999 10:31
> To:   [email-masked]
> G'Day Brian,
> I haven't seen any good reasons for going to either method and wouldn't
> be happy to add text on a gut feeling.
>
> I've thought about this before and there are +/-'s for using properties
> vs signal/events. The choice really depends on what you want to achieve.
> I would rather each package that introduced these consider each method
> on its own merit.
>
> Cheers, Christian
>
> Brian Rosen wrote:
> >
> > A number of issues were raised in the Washington meeting that
> > were "send to the list".  This is one of these issues, with the
> > problem and my suggested fix.
> >
> > Problem
> > Words in the text need to be added to clarify the "right" way
> > to do this.
> >
> > Proposed Solution
> > Despite the attractiveness of the syntax of signals for this
> > purpose, I believe that is an inappropriate use of the signal
> > mechanism, and should be discouraged in favor of using
> > properties.  I'd like to add words to that effect in the documentation.
> >
> > Brian

---

From: Peter Blatherwick <[email-masked]>
Date: Thu, 18 Nov 1999 14:57:20 -0500

[Note: also copied to the Megaco list in case others are interested in this
line of thinking.]

Tom:

I think the ITU/ISDN modelling is more than we need for Megaco Properties vs
Signals.  This issue is less complex, having only to do with design of
Packages in Megaco, and not directly related to call control.  Did you have
anything particular in mind?

At any rate, this question needs to come to a conclusion quickly, to allow
Megaco Protocol to complete.

-- Peter

> From: Tom Scott [SMTP:[email-masked]]
> Sent: 18 Nov, 1999 12:55
> To:   Blatherwick, Peter [CAR:AT14:EXCH]; Telecom Tom
> Peter;
> See attached diagram on ISDN BRI UNI signaling.  Most of our analysis
> involved call-control signaling. But there was also some management-plane
> signaling that is not indicated in the diagram.
>
> Have you considered all three traditional ITU planes: user/U, control/C,
> management/M? Would the distinction between signaling and properties be at
> all related to the three planes?
>
> I wish I could offer concrete suggestions but I first must do more
> background study in Megaco. In any case, the topic is of interest to me. I
> hope you'll continue the dialogue on the list.
>
> --Tom Scott
> -----------------------------------------------------------
> Tom Nelson Scott             Phone: 1-419-354-5700
> The Veda Home Company        Fax: 1-419-354-5705
> 1411 Sheffield Drive         Email: [email-masked]
> Bowling Green OH 43402       <http://veda-home.com>
> "In IP We Trust"       "E Pluribus Unix"       "Java Rules"
> -----------------------------------------------------------
>
>
> -------- Original Message --------
> Date:          Thu, 18 Nov 1999 10:07:40 -0600
> From:          Peter Blatherwick <[email-masked]>
> Reply-To:      Peter Blatherwick <[email-masked]>
> In what I would consider Signals in my definition, by "dynamic in nature
> and dynamic in nature, and moving information or affecting information
> flows", I mean things that are changeable on the fly as part of control of
> the MG, or can be applied to streams during normal operation of calls.
> The non-IP network sees these as state changes during call operations, or
> the end user sees/hears them as part of using the device to
> make/answer/manipulate calls.  (Realising that Megaco does not really
> think about "call" per se at the MG level, the example remains useful.)
> By example, candidates for signalling would be anything that diddles user
> interface as part of application flow (updating display, turning
> indicators on and off, softkey updates, alerting, etc), application of
> call progress and dialling tones on streams, manipulation of line/trunk
> state, playing of announcements, etc.
>
> By contrast, Properties would not have direct effect on either the end
> user or the non-IP network, but would alter the behaviour of the MG from a
> I would NOT intend for things like IP addresses and RTP ports to be
> carried in SignalsDescriptors in general.  (There might be some special
> cases I suppose.)  These belong elsewhere in the command structure.
>
> I'm not sure I've added to understanding above.  Wording for these types
> of concepts is always hard.  I don't know how much of my life I have spent
> down rat-holes trying to define the differences between "service",
> "application", "component" and such.  I'm sure many of us have.  Thank
> goodness we are not trying to define "agents" ;-)
>
> -- Peter
>
>       Properties are anything that affects configuration of terminations
> or the MG as a whole, and are relatively static.  They may have externally
>  << File: signaling.pdf >>