Subject: [Megaco] Inconsistency in signals definition

From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS <[email-masked]>
Date: Thu, 6 Sep 2001 11:55:26 +0200

Hi,

following the discussion about the annex M.1, I think there is an
inconsistency in the core protocol about the definition of a signal:

section 6.2: signals are "MG generated streams"
section 6.2.4: SignalsDescriptors "describes signals and/or actions to be
applied to the Terminations". 
section 7.1.11: "SignalsDescriptor is a parameter that contains the set of
signals that the MG is asked to apply to a Termination". What about actions?
section 7.1.9 (for instance..): "recognition of an event shall cause any
active signals to stop". Again, what about actions?

So:
- according to 6.2 and 6.2.4, signals are "MG generated streams" only
- according to 7.1.11 and 7.1.9, signals are what is contained in a
SignalDescriptor, i.e. "MG generated streams" + actions (according to
6.2.4).

I think this should be fixed in the IG. I propose:
- modifying section 6.2 the following way: "Signals are MG generated streams
(such as tones and announcements), line signals such as hookswitch, and/or
actions."
- modifying section 6.2.4: "Signals: describes signals (see 6.2) applied to
the Terminations."

               ```
              (o o)
----------oOO--(_)-OOo--------------
Jean-Emmanuel CHAPRON
FRANCE TELECOM R&D
DAC/ACE
38-40 rue du general Leclerc
92794 Issy-les-Moulineaux Cedex 9 - France
Tel: +33 1 45 29 64 50
-------------------------------------

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 6 Sep 2001 08:48:18 -0400

Sounds good.  It reflects the decision in principle we made a couple of SG
16 meetings ago.

-----Original Message-----
From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS
[mailto:[email-masked]]
Sent: Thursday, September 06, 2001 5:55 AM
To: [email-masked]
Subject: [Megaco] Inconsistency in signals definition

Hi,

So:

               ```
              (o o)
----------oOO--(_)-OOo--------------
Jean-Emmanuel CHAPRON
FRANCE TELECOM R&D
DAC/ACE

---

From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS <[email-masked]>
Date: Thu, 6 Sep 2001 16:00:36 +0200

Another question: I've just realized there are two types of "actions"
described in the standard: 
- the first one in section 6.2.4
- the second in section 8 :"an action consists of a non-empty series of
Commands that are limited to operating within a single context", where
Commands are, I think, the H.248 commands (Add, Move,..)
 
I think these "actions" are actually not the same. So, different words
should be used to avoid confusion..

-----Original Message----- 
From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS 
[ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, September 06, 2001 5:55 AM 
To: [email-masked] 
Subject: [Megaco] Inconsistency in signals definition 

Hi, 

So: 

               ``` 
              (o o) 
----------oOO--(_)-OOo-------------- 
Jean-Emmanuel CHAPRON 
FRANCE TELECOM R&D 
DAC/ACE 

_______________________________________________ 
Megaco mailing list 
[email-masked] 
http://www1.ietf.org/mailman/listinfo/megaco
<http://www1.ietf.org/mailman/listinfo/megaco>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 6 Sep 2001 12:20:23 -0400

Maybe the word should be "operation".

-----Original Message-----
From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS
[mailto:[email-masked]]
Sent: Thursday, September 06, 2001 10:01 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; [email-masked]
Subject: RE: [Megaco] Inconsistency in signals definition

-----Original Message----- 

Hi, 

So: 

               ``` 
              (o o) 
----------oOO--(_)-OOo-------------- 
Jean-Emmanuel CHAPRON 
FRANCE TELECOM R&D 
DAC/ACE

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 07 Sep 2001 11:17:03 -0400

I find I agree with Brian up to a point and, in fact, some of the uses I
had envisioned for signals ARE probably more appropriate for events and
properties.  I agree that for atomic procedures (what I mean by this
will be more clear below), signals should probably only be used for
sending media or signaling information OUT of a termination toward an
external resource or into the context.

But there are some very valuable procedures that are more complex and
involve several atomic procedures associated into an algorithm or script
and these may be a mix of sending simple signals along with event
detection (or media receiving) and information processing.  Examples
vary from fairly simple:

    ct/rsp in Annex E.10 which performs "lookback" where received media
packets are sent back out unchanged

to moderately complex:
    a procedure similar to ct/rsp to respond to a US test called
"digital inverting loop-back" where received digital packets are
inverted (first-bit becomes last-bit) and resent

to more complex:
    PlayCollect in Tom's Advanced Audio Server Base package which plays
an announcement and collects either DTMF or received voice and can have
one or more segments.

Since these sequenced procedures involve output of simple signals along
with event-like and property-like aspects they would not fit a simple
definition of signal but neither do they fit anything else.  They seem
(to some of us) to fit best as signals.  The alternative is to say that
such complex procedures are not permitted and that they must be reduced
to atomic procedures with MGC interaction -- or that we wait for V2 and
introduce a more general scripting mechanism (that was once proposed).
But these fixed scripts are much easier to support than some general
scripting mechanism.

If we choose to permit this (and ct in E.10 is already approved),
perhaps we simply need to add a sentence similar to Tom's:

    "More complex signals may include a sequence of such transfers
interspersed with and conditioned upon the receipt and analysis of
information sent back by the exterior entity."

that would permit some sort of complex procedures when involved with a
simple signal.

"Rosen, Brian" wrote:

>  I have not been able to decipher what any of these statements
> mean. They are all meaningless mumbo jumbo to me. Part of my problem
> is that I had believed signals were restricted to things which a)
> alerted a user or downline equipmentb) had a notion of duration (even
> if it was on/off), as opposed to state and c) interacted with events
> (that is, an event detection normally turned them off). Everything
> else is a property.  My notion is apparently in the minority, and
> people want touse signals for all sorts of things that, to me, ought
> to be properties.One of the big problems here is "receipt".  A signal
> is a SOURCE of something, not a SINK of information.  You put a signal
> on a termination and something comes out. You can detect this
> information on another termination, but that is what an event
> does. Actually, that's one of the things I use to decide if
> something should be a signal - if there is another termination that
> wants an event to detect something, then the something might be sent
> with a signal.  If there isn't anything that wants to detect it
> (obvious exception for human alerts), maybe a signal
> isinappropriate.What is this stuff about "setting conditions which
> govern the operations..."? Signals send out something, then they
> stop.  If you want to control something, use a property.  If you want
> to detect something, use an event.Again, clearly a minority opinion,
> but please accept the criticism that the proposedwords don't impart
> meaning to folks who it ought to.Brian
>
>      From: Tom-PT Taylor [mailto:[email-masked]]
>      Sent: Friday, September 07, 2001 12:20 AM
>      To: 'Christian Groves'; 'Terry L Anderson'
>      Cc: [email-masked]'
>      In a private exchange to which Terry has yet to reply, I
>      decided this was getting way too detailed.  My proposal is
>      to replace the whole thing with the following:
>
>      "A signal is an operation on a specific termination which
>      involves generation and/or receipt of information, or else
>      sets conditions which govern the operation of other
>      signals."
>
>      From: Christian Groves
>      [mailto:[email-masked]]
>      Sent: Friday, September 07, 2001 12:02 AM
>      To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Terry L Anderson'
>      Cc: [email-masked]'
>      Subject: Re: [Megaco] Inconsistency in signals definition
>
>      G'Day Tom and Terry,
>
>      Sorry not to have come in earlier but holidays take
>      peference.
>      I have a few comments to the proposed text below:
>
>      "A signal is an operation on a specific termination which at
>      a minimum
>      either requires the MG to transfer information immediately
>      or sets
>      conditions for the transfer of imformation by another
>      signal."
>
>      [CHG] You can wildcard terminations therefore a signal may
>      operate on
>      several terminations.
>
>      "The information transfer is from the MG toward the entity
>      represented
>      by a given termination and/or from the termination as a
>      logical entity
>      into the context."
>
>      [CHG] This type of terminology ie. entity isn't commonly
>      used in the
>      recommendation. We already have text on this in the
>      recommendation sect
>      7.1.9, "Signals are defined as proceeding from the
>      termination towards
>      the exterior of the Context unless otherwise specified in a
>      package."
>      This is straight forward, why repeat similar text which
>      could lead to
>      confusion.
>
>      Transfers toward the exterior may be "in-band" (i.e. media
>      flows) or
>      "out of band" (e.g. application of voltage to a physical
>      line).
>
>      [CHG] I would like to see an example "or signalling" (e.g.
>      signalling
>      related to the bearer). I believe that this may be why this
>      topic has
>      been brought up. We also discussed this last year in Geneva
>      and it was
>      considered valid to do this.
>
>      "Transfers from the termination to the context must be in
>      the form of
>      media flows."
>
>      [CHG] What is the reason that transfers from the termination
>      to the
>      context be in the form of media flows? Is ringing generated
>      through MG
>      switching fabric a media flow?
>
>      "More complex signals may include a sequence of such
>      transfers
>      interspersed with and conditioned upon the receipt and
>      possible analysis
>      of information sent back by the
>      exterior entity."
>
>      [CHG] Is there a simpler way of saying this, it is very hard
>      english to
>      understand for non-native english speakers. ie. Complex
>      signals may
>      involve transfers to an external entity based on possible
>      analysis of
>      inputs received from the entity.
>
>      "For purposes of this definition the entity represented by
>      ROOT is the
>      MGC."
>
>      [CHG] Signal on Root is only a concept in H.248v2. v1 cannot
>      have a
>      signal on root. Do we need to say this as its mentioned in
>      H.248 in
>      other places?
>
>      In general, the outcome of invoking a signal on a
>      termination can only
>      be reported to the MGC by means of an event.  Where the
>      nature of the
>      signal is such that the its execution time should be
>      negligible compared
>      to the time within which the MGC expects a transaction
>      response, the
>      signal may be defined to allow failures to be reported as
>      errors within
>      the transaction response.
>
>      [CHG] It don't think the reporting of errors should be
>      linked to
>      executing time. If the MG determines at the time of
>      processing the
>      signal request that there's a fault then it reutrn an error
>      descriptor
>      in the reply. Once started playing then we should rely on
>      the signal
>      completion event or other events that have been configured.
>
>      Cheers, Christian
>
>      Tom-PT Taylor wrote:
>      >
>      > I'd add the word "possible" in front of analysis, to get
>      what we want,
>      > so the last sentence would read:
>      >
>      > "...More complex signals may include a sequence of such
>      transfers
>      > interspersed with and conditioned upon the receipt and
>      possible
>      > analysis of information sent back by the exterior
>      entity..."
>      >
>      > From: Terry L Anderson [mailto:[email-masked]]
>      > Sent: Thursday, September 06, 2001 5:44 PM
>      > To: Taylor, Tom-PT [NORSE:B881:EXCH]
>      > Cc: 'CHATRAS Bruno FTRD/DAC/ISS'; [email-masked]'
>      > Subject: Re: [Megaco] Inconsistency in signals definition
>      >
>      > Ok, that certainly more specific, but I think it covers
>      the things I
>      > wanted.  But doesn't omit the info transfer from the
>      entity INTO the
>      > termination (the recorded voice that you need)?  There's a
>      little door
>      >
>      > for this in the last sentence of the first paragraph about
>      analysis
>      > but
>      > your previous suggestionn had "to and possibly from" while
>      this one
>      > only
>      > "toward the entity"  in the second sentence.
>      >
>      > Tom-PT Taylor wrote:
>      >
>      > >
>      > >
>      > > Try this:
>      > >
>      > > "A signal is an operation on a specific termination
>      which at a
>      > minimum
>      > > either requires the MG to transfer information
>      immediately or sets
>      > > conditions for the transfer of imformation by another
>      signal.  The
>      > > information transfer is from the MG toward the entity
>      represented by
>      > a
>      > > given termination and/or from the termination as a
>      logical entity
>      > into
>      > > the context.  Transfers toward the exterior may be
>      "in-band" (i.e.
>      > > media flows) or "out of band" (e.g. application of
>      voltage to a
>      > > physical line).  Transfers from the termination to the
>      context must
>      > be
>      > > in the form of media flows.  More complex signals may
>      include a
>      > > sequence of such transfers interspersed with and
>      conditioned upon
>      > the
>      > > receipt and analysis of information sent back by the
>      exterior
>      > entity.
>      > >
>      > > For purposes of this definition the entity represented
>      by ROOT is
>      > the
>      > > MGC.
>      > >
>      > > In general, the outcome of invoking a signal on a
>      termination can
>      > only
>      > > be reported to the MGC by means of an event.  Where the
>      nature of
>      > the
>      > > signal is such that the its execution time should be
>      negligible
>      > > compared to the time within which the MGC expects a
>      transaction
>      > > response, the signal may be defined to allow failures to
>      be reported
>      >
>      > > as errors within the transaction response."
>      > >
>      > > Such an extended definition probably belongs at the
>      start of 7.1.11,
>      >
>      > > with a forward reference from 6.2.
>      > >
>      > > From: Terry L Anderson [mailto:[email-masked]]
>      > > Sent: Thursday, September 06, 2001 3:17 PM
>      > > To: Taylor, Tom-PT [NORSE:B881:EXCH]
>      > > Cc: 'CHATRAS Bruno FTRD/DAC/ISS'; [email-masked]'
>      > > Subject: Re: [Megaco] Inconsistency in signals
>      definition
>      > >
>      > > What about changing your first sentence to
>      > >     "A signal is an operation involving the transfer and
>      processing
>      > of
>      > >
>      > > information..."
>      > > I am want to make sure it covers things like:
>      > > 1) inverting loopback for line testing
>      > > 2) perform a milliwatt line test, where a signal level
>      must be
>      > > measured
>      > > and reported as a property of an event or as a
>      statistic.
>      > > etc.
>      > >
>      > > as to your other point about supporting direction, you
>      could change
>      > > the
>      > > end of the sentence to:
>      > > "...to or from the entity represented by the specified
>      termination
>      > or
>      > > that exchanged with other terminations in the context."
>      > >
>      > > Tom-PT Taylor wrote:
>      > >
>      > > >
>      > > >
>      > > > I would sooner provide a definition of signal
>      amplifying the
>      > > existing
>      > > > one in 6.2.  Here's my try at it:
>      > > >
>      > > > "A signal is an operation involving the transfer of
>      information to
>      >
>      > > and
>      > > > possibly from the entity represented by a given
>      termination.  A
>      > > simple
>      > > > example is the playout of media such as an
>      announcement or tone,
>      > or
>      > > > playout of ringing voltage on an analogue line.  A
>      more complex
>      > > > example is an interactive sequence such as playout of
>      a prompting
>      > > > announcement, input of DTMF digits, and playout of an
>      > acknowledging
>      > > > tone or announcement."
>      > > >
>      > > > The main question in my mind at this point is how to
>      include the
>      > > case
>      > > > of announcements which also play inwards through the
>      context.
>      > > >
>      > > > From: CHATRAS Bruno FTRD/DAC/ISS
>      > > > [mailto:[email-masked]]
>      > > > Sent: Thursday, September 06, 2001 1:06 PM
>      > > > To: Taylor, Tom-PT [NORSE:B881:EXCH]
>      > > > Cc: [email-masked]'
>      > > > Just to make the problem more complex !
>      > > >
>      > > > Are we able to provide a definition of "operation" in
>      the
>      > > DEFINITIONS
>      > > > section (section 3) ? Or is it so open and flexible
>      that it is
>      > > nearly
>      > > > impossible to figure out what is an operation and what
>      is not an
>      > > > operation. In other words do we put some limits on
>      what an
>      > operation
>      > >
>      > > > can do or are we ready to accept almost anything ? For
>      example,
>      > are
>      > > we
>      > > > ready to allow an operation that can be used to
>      subtract one or
>      > more
>      > >
>      > > > terminations without using the Subtract command ?
>      > > >
>      > > > Envoyé : jeudi 6 septembre 2001 18:20
>      > > > Another question: I've just realized there are two
>      types of
>      > > "actions"
>      > > > - the second in section 8 :"an action consists of a
>      non-empty
>      > series
>      > >
>      > > > of Commands that are limited to operating within a
>      single
>      > context",
>      > > > where Commands are, I think, the H.248 commands (Add,
>      Move,..)
>      > > >
>      > > >
>      > > > I think these "actions" are actually not the same. So,
>      different
>      > > words
>      > > > Sounds good.  It reflects the decision in principle we
>      made a
>      > couple
>      > >
>      > > > of SG 16 meetings ago.
>      > > > inconsistency in the core protocol about the
>      definition of a
>      > signal:
>      > >
>      > > > section 6.2.4: SignalsDescriptors "describes signals
>      and/or
>      > actions
>      > > to
>      > > > be
>      > > > section 7.1.11: "SignalsDescriptor is a parameter that
>      contains
>      > the
>      > > > set of
>      > > > signals that the MG is asked to apply to a
>      Termination". What
>      > about
>      > > > actions?
>      > > > section 7.1.9 (for instance..): "recognition of an
>      event shall
>      > cause
>      > >
>      > > > any
>      > > > - according to 6.2 and 6.2.4, signals are "MG
>      generated streams"
>      > > only
>      > > > - according to 7.1.11 and 7.1.9, signals are what is
>      contained in
>      > a
>      > > > SignalDescriptor, i.e. "MG generated streams" +
>      actions (according
>      >
>      > > to
>      > > > 6.2.4).
>      > > > - modifying section 6.2 the following way: "Signals
>      are MG
>      > generated
>      > >
>      > > > streams
>      > > > (such as tones and announcements), line signals such
>      as
>      > hookswitch,
>      > > > and/or
>      > > > actions."
>      > > > - modifying section 6.2.4: "Signals: describes signals
>      (see 6.2)
>      > > > applied to
>      > > > the Terminations."
>      > > >
>      > > >                ```
>      > > >               (o o)
>      > > --
>      > > Waiting for the other shoe to drop but hoping its a one
>      legged man.
>      > >
>      ------------------------------------------------------------
>
>      > > Terry L Anderson              mailto:[email-masked]
>      > > Tel:908.582.7013   Fax:908.582.6729
>      > > Lucent Technologies/INS/Voice Over IP Access Networks
>      > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
>      > > http://its.lucent.com/~tla (Lucent internal)
>      http://www.gti.net/tla
>      >
>      > --
>      > Waiting for the other shoe to drop but hoping its a one
>      legged man.
>      >
>      ------------------------------------------------------------
>
>      > Terry L Anderson              mailto:[email-masked]
>      > Tel:908.582.7013   Fax:908.582.6729
>      > Lucent Technologies/INS/Voice Over IP Access Networks
>      > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
>      > http://its.lucent.com/~tla (Lucent internal)
>      http://www.gti.net/tla
>
--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 7 Sep 2001 21:38:28 -0400

Formally, a signal looks like a remote procedure call with some interesting
behavioural constraints.  Terry and I can both testify to some complex
requirements which signals seem to meet.  

It's an interesting question, where we should draw the line so that we
preserve the integrity of the protocol.  I guess we can all agree that,
given that we are controlling media gateways, signals should have something
to do either with the manipulation of media or with signalling by other
means.  What is the argument for getting more precise than that in what
signals can and cannot be used for?

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Friday, September 07, 2001 11:17 AM
To: Rosen, Brian
Cc: Taylor, Tom-PT [NORSE:B881:EXCH]; 'Christian Groves';
[email-masked]'

to moderately complex:

to more complex:

---

From: "Marcello Pantaleo (EED)" <[email-masked]>
Date: Mon, 10 Sep 2001 16:11:29 +0200

Hello Terry,

signals embedded in events plus a short explanation in the 'Procedure' section of the package would probably be enough in order to manage at least the first two examples of complex procedures you mention.
I guess that in many cases a combination of signals and events embedding signals is appropriate for performing a sequence of atomic procedures.

Regards,
Marcello

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Friday, September 07, 2001 5:17 PM
To: Rosen, Brian
Cc: 'Tom-PT Taylor'; 'Christian Groves'; [email-masked]'
Subject: Re: [Megaco] Inconsistency in signals definition

to moderately complex:

to more complex:

--