Subject: Re: Signals Operation

From: Brian Rosen <[email-masked]>
Date: Wed, 27 Oct 1999 20:34:55 -0400

> 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.
I agree

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

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

> 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.
I agree, but the result is not BR, it is TO.  You need an event to
send when the TO signal finishes to do sequencing sensibly.

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
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>

---

From: Michael Brown <[email-masked]>
Date: Thu, 28 Oct 1999 11:36:34 -0400

Overall, I'm happy with the following description/clarifications, but I would
like to offer a slightly different idea regarding BR signals. I have
interspersed comments below.

> > MGC should determine which signals make sense to apply simultaneously.

<MB> Also agree.

> They agree that, in fact, BR signals do not stop, but OO and TO signals do.

<MB> I agree with Brian's clarification.

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

> send when the TO signal finishes to do sequencing sensibly.

<MB> Don't agree that this type of sequential play signal is necessarily TO. At
least in the case of outpulsing digits, the MGC probably doesn't need to know
that the outpulsing is complete, but instead is looking for an event that
indicates that the outpulsing was acknowledged from the terminator. As an
example, when doing MF outpulsing, once the digits are outpulsed from the
originator to the terminator, the terminator will respond with a "wink" as
acknowledgment and that is what the MGC would be looking for.
Given the current terminology to describe signal types, the sequential play
signal would better be categorized as BR (except for the "too long" argument).

In order to try to resolve this problem with BR, I would like to suggest that we
really should be referring to this type of signal as "Play to Completion" (PC).
It would be up to the MGC to specify whether this would be interruptable or not
by events based on the event descriptor provided. The interruption by a signal
would also be driven by the MGC. If the MGC sends a new signal descriptor which
drops the PC signal, then the PC signal would be stopped (if it hasn't already
completed). Using an extension of this  type of mechanism would also address the
following discussion about announcements.

We could create another signal like the one Brian proposes in the following
something like "Play to Completion and Report" (PCR or PR). It could conceivably
also be indicated as a parameter on the PC signal. The NOTIFY sent back to the
MGC could use a "Report on Completion" (RC) event (which is similar to reporting
TO).

Comments?

---

From: Chip Sharp <[email-masked]>
Date: Thu, 28 Oct 1999 16:34:32 -0500

Comments in-line:

> > > MGC should determine which signals make sense to apply simultaneously.

Agreed.

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

>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"? ;-)

>following discussion about announcements.

If the PC signal is stopped by a subsequent SignalDescriptor, then it isn't
Play to Completion. It is TO (with a short timer).  A Play to Completion
signal is one that plays to completion regardless of what a new
SignalDescriptor says.

One problem with stopping a brief tone, or a Play to Completion tone on
receipt of a subsequent SignalDescriptor is that the MGC doesn't
necessarily know whether the previous signal has stopped or not.  In the
above described method, if it wanted to finish the PTC tone, it would have
to include the tone in subsequent SignalDescriptor.  But if the tone had
stopped, the effect of receiving a new SignalDescriptor with the PTC tone
in it would be to play the tone twice instead of complete the original.

Redefining all this right now and including new stuff in the white
contribution before publication is pretty prone to error.  Once it is in
the white contribution it will take a substantial argument to remove
it.  The white contribution is translated into 3 languages.

Something that Dale Skran brought up at the last meeting is of interest
here.  For every page in the white contribution that is changed in
February, the ITU has to pay a good chunk of money to re-translate the
changes.

> > Completion - plays until completion, then sends an event.

Support NetAid!  http://www.netaid.org