Subject: RE: [Megaco] Inconsistency in signals definition

From: CHATRAS Bruno FTRD/DAC/ISS <[email-masked]>
Date: Thu, 6 Sep 2001 19:05:40 +0200

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]
<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
<http://www1.ietf.org/mailman/listinfo/megaco>

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 06 Sep 2001 13:58:55 -0400

Ok, I will add the following to the IG (unless I get objections)..

6.2 Terminations

Terminations may have signals applied to them. Signals are MG generated
media streams (such as tones and announcements), as well as line signals
such as hookswitch, and/or operations performed by terminations.
Terminations may be programmed to detect Events, the occurrence of which
can trigger notification messages to the MGC, or action by the MG.
Statistics may be accumulated on a Termination. Statistics are reported
to the MGC upon request (by means of the AuditValue command, see 7.2.5)
and when the Termination is taken out of the call it is in.

6.2.4 Termination Properties and Descriptors
(table)

Signals Describes signals (see 6.2) and/or actions to be applied (e.g.
Busy Tone) to the Terminations

-------
I think that describing it as "... operations performed by termination"
rather than "operations on terminations" excludes things like MG
subtracting a termination etc and still offers the generality we want.

CHATRAS Bruno FTRD/DAC/ISS wrote:

>  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 ?
>
>           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..
>
>                Sounds good.  It reflects the decision
>                in principle we made a couple of SG 16
>                meetings ago.
>
>                ______________________________________________
>
>                Megaco mailing list
>                [email-masked]
>
>                ttp://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