Subject: RE: [Megaco] Inconsistency in signals definition

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

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..."

-----Original Message-----
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.
>
> -----Original Message-----
> 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.
> >
> > -----Original Message-----
> > 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]'
> > Subject: RE: [Megaco] Inconsistency in signals definition
> >
> > 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 ?
> >
> > -----Message d'origine-----
> > De : Tom-PT Taylor [mailto:[email-masked]]
> > Envoyé : jeudi 6 septembre 2001 18:20
> > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; [email-masked]
> > Objet : RE: [Megaco] Inconsistency in signals definition
> >
> > 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
> >
> > 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..
> > -----Message d'origine-----
> > De : Tom-PT Taylor [mailto:[email-masked]]
> > Envoyé : jeudi 6 septembre 2001 14:48
> > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; [email-masked]
> > Objet : RE: [Megaco] Inconsistency in signals definition
> >
> > 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,
> > 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
>
> --
> 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

---

From: Christian Groves <[email-masked]>
Date: Fri, 07 Sep 2001 14:01:34 +1000

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:
> 
> interspersed with and conditioned upon the receipt and possible
> analysis of information sent back by the exterior entity..."
>