Subject: Signals Operation

From: Chip Sharp <[email-masked]>
Date: Wed, 27 Oct 1999 14:03:54 -0500

One thing I don't remember doing in Red Bank or on the list is try to get
an understanding of how the current mechanism works before adding new
capability.  Since this isn't specified in the text of the draft, we seemed
to have all made up our own semantics and assumed that was how it
worked.  It was obvious at Red Bank that our interpretations didn't all agree.

I guess we have spent so much energy on syntax, the semantics has suffered.

Anyway, here is my understanding of how Signals worked before last week's
meeting:

Signals:
--------
There are at least three issues to consider:
      1) Signal Descriptors received when there are no active signals
      2) Signal Descriptors received when there are active signals
      3) Sequential Signals

1)   In case 1, there are no active signals on a termination.
      When a MG receives a Signal Descriptor for a termination containing a
list of signals, it applies all signals in the list simultaneously.  Thus,
if the signal list contains dialtone and busy, it would apply both.  The
MGC should determine which signals make sense to apply simultaneously.

2)   Signals in subsequent Signal Descriptors
      The second problem is what to do with signals currently being applied
to a termination when a new Signal Descriptor is received.  My current
understanding is the following:
      a)   Brief tones (BR) run to completion.  That is, they are not
interrupted.
      b)   ON/OFF tones (OO) stay on until explicitly turned off.
      c)   Timeout tones (TO) are interrupted and replaced with the new
tone list.

3)   There is a desire to support sequential signals (e.g., outpulsing
digits).  The way this seems to be handled today is that outpulsing is
defined as a signal with a parameter containing the digits to
outpulse.  The semantics for this signal are defined in the package (e.g.,
outpulse signals are sent sequentially).   Outpulsing digits (e.g., DTMF,
MF, etc.) was the only application we could think of for sequential
signals.  Let us know what some others are.

One concern for a more general sequential signal capability is what kind of
signals are allowed to be sent sequentially.  I believe it only makes sense
to send BR signals sequentially.

Chip
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 28 Oct 1999 08:59:09 -0500

There is an argument that BR is a meaningless category -- that all signals
should be in principle interruptible.  Basically, we have to decide whether
there is a requirement for noninterruptible signals.  If we decide that we
need them, then you can't arbitrarily say that announcements don't belong in
that category.  What we can say is that any signal declared
non-interruptible must last fewer than X time units.  A side effect is that
you get implicit sequencing because a new signal descriptor can add new
signals but cannot wipe out the non-interruptible ones.

The alternative is to provide a new category, play-to-completion, the
semantics of which are that the signal is self-terminating but can be
stopped before completion, and optionally provides notification that it is
complete.

> -----Original Message-----
> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Wednesday, October 27, 1999 8:35 PM
        [[TomT]]  ...
> BTW those of you thinking about announcements, they are not BR - they take
> too long.  They should be TO.  TO isn't exactly right, as you don't
> normally
> get an event, and you want to cause an event after the signal finishes -
> the
> timer isn't actually used.  Perhaps we should invent a new type - Event on
> Completion - plays until completion, then sends an event.
>
> Brian

---

From: Steven Magnell <[email-masked]>
Date: Thu, 28 Oct 1999 21:05:11 -0400

Some comments on the current signals and events discussion.

I concur with two comments made by Tom Taylor. A sequence descriptor should
be added and BRief is really a meaningless signal type.

A Signal descriptor and a Sequence descriptor should be alternate forms for
the same basic operation, with slightly differing semantics. Both cause a
list of signal operations to be applied to a termination. They are
different only in the order in signals are applied. In a "Signal" operation
they are applied "simultaneously". In a "Sequence" operation they are
applied in listing order such that as each individual signal ends, the next
in the list starts.

The additional feature that Tom proposes, that of embedding one descriptor
within the other should be common to both. One should be able to put
Sequence descriptors within a Signal descriptor and vice versa. Allowable
levels of embedding should be a property of the MG, with a minimum
requirement of one level.

To answer the call for a signal termination indication, signals/sequence
descriptors and signal descriptors should be extended to allow the
inclusion of an Events descriptor as a parameter, with the semantics being
that the event is triggered upon termination of the operation to which it
is attached. This is more general and includes the notification of the MGC.

Why is Brief a meaningless signal type? Since we have defined a default
duration as a property for all signals that can occur for some period of
time, a BRief signal is equivalent to a TimeOut signal where no time is
explicitly given as a parameter in a Signal Request. Actually, the same
logic can be applied to On/Off and CoNtinue signals. An on OO signal is one
that is defined with a very  long default duration and a CN signal is one
defined with an infinite default duration. (the syntax of "infinite" should
be defined). All signals should be requested in the same manner; a
time/duration parameter overrides the default.

As far as the handling of signals upon the application of a new Signal or
Sequence descriptor, the baseline proposal described by Tom should be adopted.

> Baseline proposal: if one SignalsDescriptor is replaced by another on the
> same termination, the replacement has the following effects:
>   -- signals which were in the first SD but are not in the second one are
> stopped
>   -- signals which were not in the first SD but are in the second one are
> started
>   -- signals which are in both SDs are continued
>   -- to restart a signal requires that it be stopped, then started,
> presumably through two Modify commands applied to the same termination
> within the same transaction.

There should be two extensions to this description.
 -- A Sequence, which has not completed, and is replaced by an identical
sequence will continue from its current point.

 -- Any signal stopped as a result of the new signal descriptor will cause
the associated termination events to trigger, but those that have not been
started (as in a sequence) will not cause any termination event.

A final comment on event descriptors. One deficiency of the current event
mechanism is that an event cannot cause an action on another termination
within the same context. It would be extremely useful to be able to signal
another termination upon the occurrence of an event.

steve magnell
Dialogic, an Intel Company

---

From: Peter Blatherwick <[email-masked]>
Date: Fri, 29 Oct 1999 11:40:21 -0400

Further comments in line.  See also comments just sent to Brian Rosen, re
"immediate" Signals.

> From: Chip Sharp [SMTP:[email-masked]]
> Sent: 28 Oct, 1999 17:35
> To:   [email-masked]
> Subject:      Re: Signals Operation
>
[snip]

> > > I agree with a, but OO signals as well as TO signals are stopped:
> > > The text reads "Production of a Signal on a Termination is stopped by
> > > application of a new SignalsDescriptor, or detection of an Event on
> the
> > > Termination."
> > > I have questioned several MGCP developers who are interpretting the
> same
> > > wording.
> > > They agree that, in fact, BR signals do not stop, but OO and TO
> signals do.
> >
> ><MB> I agree with Brian's clarification.
>
> I guess there is disagreement among MGCP developers.  After questioning
> several MGCP developers, I got the feedback that OO signals do not stop
> unless explicitly turned off.  One question is how they are explicitly
> turned off.  Is that defined in the current draft?  It could be defined
> that if the MG receives a SignalDescriptor that does not include a
> currently active OO signal, then it is turned OFF.
>
Based on what we saw at Red Bank, I'd say there was disagreement amongst
more than MGCP developers.  My personal understanding agreed with Chip's
developer pool, and there were N+1 other interpretations represented.

Per my comments elsewhere re "immediate" Signals, I would like to see only
those signals which have duration (tones etc) turned off by arrival of a
SignalsDescriptor.  I hope this behaviour is now agreed.  Otherwise we have
a lot of redundancy in the messaging just to say: leave it on, leave it on,
leave it on, leave it on, ....

BTW, I like the "immediate" terminology.  I think it was originally
suggested by Tom in this context, but I've seen it used before to good
effect in telephony API design.  Suggest we consider use of the term, and
let it help us describe expected behaviour of Signals in the package
descriptions.

> > > I do believe that limiting to one package is not good enough.  I'll
> > admit to
> > > not being able to come up with an example right now, so maybe it is.
> >
> ><MB> As if said before, I do still prefer the idea of defining signals to
> do
> >sequential play, such as outpulse, within the package that needs it.
>
> An outpulse signal in the package defining  outpulsing digits would be a
> simple solution to the major application.  No one has chimed in with an
> application for sequential signals other than outpulse of digits.  BTW, if
> DTMF is used shouldn't this be "outtoned"? ;-)
>
Hmmm...  I think the announcement folks did have some useful applications in
mind -- playing segments of announcements from different files on the
announcement MG, possibly playing a first one while determining the correct
second one to play.  We did however discuss that this could be easily
controlled by the MGC, given appropriate play_finished events.

We should definitely look to add "PlayToneString" in at least the dtmf tone
package, possibly similar Signals in others as well, where it makes sense.
And we need to add play_finished events where they make sense.

Agree "outpulse" is not the correct term, even though its meaning is well
understood in the industry now.  (Except maybe for me.... I have a bunch of
old-style rotary phones at home, just, well, because ...   ;-)   Haven't
come up with a better term yet though.  We should look for a term which
captures the idea of sequencing, and is ambiguous re whether its tones,
announcement segments, or whatever.

[snip]

-- Peter Blatherwick

---

From: Brian Rosen <[email-masked]>
Date: Fri, 29 Oct 1999 16:00:30 -0400

I believe that OO signals should stop on most events.  KeepActive and
embedded signals lets you control what events should cause signals not to
stop.  
 
There are, as has been observed, very few OOs.  All of the ones I can think
of should stop on events like on-hook.  The number of events that they
should not stop on is very limited, and such events should be KeepActive.  
 
Brian

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

[snip] 

> > application of a new SignalsDescriptor, or detection of an Event on the 
> > Termination." 
> > I have questioned several MGCP developers who are interpretting the same

> > wording. 
> > They agree that, in fact, BR signals do not stop, but OO and TO signals
do. 
><MB> I agree with Brian's clarification. 

        I guess there is disagreement among MGCP developers.  After
questioning 

do 
>sequential play, such as outpulse, within the package that needs it. 

        An outpulse signal in the package defining  outpulsing digits would
be a 
simple solution to the major application.  No one has chimed in with an 
application for sequential signals other than outpulse of digits.  BTW, if 
DTMF is used shouldn't this be "outtoned"? ;-) 

[snip] 

-- Peter Blatherwick