Subject: Re: Cisco SG16: Signals Operation

From: "Glasgow, George" <[email-masked]>
Date: Wed, 9 Feb 2000 09:00:40 -0500

Michael,
You make some good points.

Coming from the PSTN world, I can say that it was always clear to us that
the subscriber is God. If he goes off-hook or on-hook, then the signal must
be processed. Under no circumstances were we permitted to allow the
subscriber port to get hung.

In the case of VMWI, if the FSK transmission to the CPE was going on when
the subscriber went off-hook, then we simply aborted the VMWI and processed
the off-hook. Once the subscriber went on-hook, we went back and re-sent the
VMWI signal. This applies similarly to Calling Number/Name delivery, in that
the off-hook was processed and the FSK was aborted. In these features, of
course, we didn't go back at the end of the call and attempt to deliver the
data to the CPE!

Regards,

George Glasgow
Unisphere Solutions

-----Original Message-----
From: Michael Brown [mailto:[email-masked]]
Sent: Tuesday, February 08, 2000 5:19 PM
To: [email-masked]
Subject: Re: Cisco SG16: Signals Operation

Yes, actually this was a discussion that was held in Washington. VMWI is
what
we were calling an instantaneous OO signal. That is, the MGC sends down the
signal to turn the light on. The CPE is messaged and the light comes on. In
PSTN, the switch does not continuously send the command to keep the light
on.
If I send another signal descriptor without VMWI included no message is sent
to the CPE about VMWI and the light stays on. It isn't until the MGC send a
message to turn it off, that the light then goes off. Just by the way, there
really is no reason why VMWI has to be an OO signal ... making it a BR
signal
would work just as well.

As an aside, if VMWI is a truly a non interruptable OO signal, how would the
user go offhook?

Another aside is if a user hangs up during a non interruptable BR signal
where
the BR signal is not set up to report completion (most common case), what
happens to the onhook event? If not reported, the line would hang in off
hook
state until either the MGC determined there was a problem or until the user
went off hook and onhook again.

My opinion is that if we want a particular signal to be truly
noninterruptable
(which I would contend that we really don't ever want to do), we would send
a
null events descriptor... if we don't want to see events, then don't ask for
them. If we want to see some events, but we want the signal to continue,
then
use Keepactive.

Michael

PS. I realize that I have not been contributing to the Keepactive
discussion,
but will do so right now.

Flemming Andreasen wrote:

> Can you explain how you plan on supporting say "visual message waiting
> indicator" if OO signals are interrupted ?
>
> -- Flemming
>
> Christian Groves wrote:
>
> > G'Day all,
> >
> > I'd like to confer with Michael. All signals should be able to be
> > interrupted. I think the behaviour of the signal types should be
> > uniform. The distinction between: BR, TO, OO should be how many times
> > the signal is played. ie.
> > - BR play once what ever length it is.
> > - TO play and repeat for a certain amount of time. ie.  ringtone -> play
> > ring pattern multiple times.
> > - OO play and repeat until turned off.
> >
> > A previous email sent by Tom gives an outline on what I believe the
> > replacement rules should be.
> >
> > Cheers, Christian
> >
> > Michael Brown wrote:
> > >
> > > Overall, we're still on the right track since we haven't taken the
> > > approach of throwing everything away and starting over, but I do have
> > > problems with some of the proposed changes. My feeling is that they
> > > take us back to the situation we had before the IETF meeting in
> > > Washington where I felt these issues were reasonably well resolved.
> > >
> > > The biggest general issue I have is that the definitions for signal
> > > type cross the boundary into dictating implementation detail. Take the
> > > case of  a BR signal. Happily, we have not come back around to trying
> > > to define some time limit for a BR signal (although I think continuing
> > > with the proposal will eventually lead us there again), so for now BR
> > > is a subjective statement. Let's say I want to play a signal of a
> > > relatively short tone (a couple of seconds) with a provisioned (in the
> > > MG) length, but I want it to be interruptable. By these definitions,
> > > this would have to be treated as a TO which means that the MGC would
> > > have to specify duration (or we have the special rule of duration=0
> > > means to play the signal til the MG stops it) which I don't think
> > > should be required.
> > >
> > > There are other example of how these definitions require a specific
> > > implementation of common signals, such as dial tone.
> > >
> > > Basically, I suppose I continue to feel that the default for all
> > > signals should be interruptable and that  Keepactive be used to
> > > override that behavior.
> > >
> > > Unfortunately, I don't have time to respond with my objections more
> > > fully at this moment as I'm leaving shortly for the ITU meeting. When
> > > I arrive in Geneva, I will follow up with my other concerns and
> > > examples.
> > >
> > > Michael
> > >
> > >
> > >
> > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
> > >
> > > >
> > > >
> > > > OK, let's sum up, not that I'm confident that this will fly yet.
> > > > I'd like to see the reaction of a couple of other vocal parties --
> > > > say Michael Brown and Christian Groves.
> > > >
> > > > We have three signal types with distinct roles:
> > > >   BR has a timer but is not interrupted by events.  It is
> > > > interrupted by signal descriptor replacement.
> > > >   TO is the most interruptible: timer, events, signal descriptors.
> > > >   OO is the most persistent: interrupted by signal descriptors with
> > > > explicit "Off" syntax only.
> > > > I assume we allow over-riding of default signal type in any given
> > > > instance of playout.
> > > >
> > > > The list is an interesting problem.  I think I have an answer to
> > > > turning an OO list off, but now we also have to define behaviour in
> > > > response to events.  We might consider the following rules:
> > > >
> > > >  -- the type of the list is set explicitly -- every signal on the
> > > > list with the possible exception of the last one must be either BR
> > > > or TO, in order to have an assigned duration
> > > >
> > > >  -- if the last event is OO, the list must be OO and vice versa
> > > >  -- the type of the list, not the type of the signals making it up,
> > > > determines the conditions under which playout of the list ceases
> > > >
> > > >  -- the list times out if it is not OO and all of the signals on it
> > > > have played out, each in turn to its full duration.
> > > >
> > > >      -----Original Message-----
> > > >      From:   Flemming Andreasen [SMTP:[email-masked]]
> > > >      Sent:   Friday, February 04, 2000 5:38 PM
> > > >      To:     [email-masked]
> > > >      Subject:        Re: Cisco SG16: Signals Operation
> > > >
> > > >      Maybe, but according to Brian's first "no-op" rule, it must be
> > > >      broken in order to get fixed :-)
> > > >
> > > >      Regarding dial-tone, I don't see the issue. What you have is
> > > >      three different signal types and three different semantics.
> > > >      Each has it's own time and place. In the case of dial-tone,
> > > >      TimeOut happens to be the one, not Brief.
> > > >
> > > >      -- Flemming
> > > >
> > > >
> > > >      "Rosen, Brian" wrote:
> > > >            Let's see:    Events stop signals except:        When
> > > >           KeepActive is set        If the signal is BR        If the
> > > >           signal is OONet result - events stop signals only when TO
> > > >           and not KeepActive.Maybe we should have a "StopSignal",
> > > >           rather than a KeepActiveMaybe it happens so seldom that we
> > > >           use an embedded signals to do it.Also note that by saying
> > > >           BR doesn't stop for events, you twist the solution tofirst
> > > >           digit stops dialtone to a new level.Brian
> > > >                -----Original Message-----
> > > >                From: Flemming Andreasen [
> > > >                <mailto:[email-masked]>]
> > > >                Sent: Friday, February 04, 2000 4:55 PM
> > > >                To: [email-masked]
> > > >                Subject: Re: Cisco SG16: Signals Operation
> > > >
> > > >                Hi Tom
> > > >
> > > >                OO signals should not be interrupted by an event,
> > > >                only the explicit "Off" syntax should have this
> > > >                effect (otherwise we are back to TO signals with
> > > >                indefinite duration, and semantically there's good
> > > >                use for something that stays active until explicitly
> > > >                told otherwise, e.g. consider message waiting
> > > >                indicator)
> > > >
> > > >                Regards
> > > >
> > > >                        Flemming
> > > >
> > > >                Tom-PT Taylor wrote:
> > > >
> > > >
> > > >                     Digging through the accumulated mass of indented
> > > >                     text and comments, I think I see two parties
> > > >                     agreeing on the following points.  Unfortunately
> > > >                     experience tells me that as soon as we introduce
> > > >                     a third party the agreements will vanish, but
> > > >                     I'll record them here just in case a miracle
> > > >                     happens.
> > > >
> > > >                     1) BR signals have the following
> > > >                     characteristics: duration is assumed to be known
> > > >                     to the MG without explicit MGC input.  Brian
> > > >                     wants the ability to override duration, and I
> > > >                     have no quarrel with that -- the only question
> > > >                     is the exact mechanism.  The second
> > > >                     characteristic is that a BR signal is not
> > > >                     terminated by the detection of an event.  (But
> > > >                     BR signals are still terminated by replacement
> > > >                     of the Signals descriptor??  Any objections
> > > >                     here?)
> > > >
> > > >                     2) TO signals seem to be fairly well understood.
> > > >
> > > >                     3) OO signals have the following
> > > >                     characteristics: they remain on until
> > > >                     interrupted by detection of an event, or receipt
> > > >                     of a Signals descriptor with explicit Off
> > > >                     syntax.  Brian's keyword syntax is probably
> > > >                     acceptable.  Brian has a query about signal
> > > >                     lists.  Is there something about this proposal
> > > >                     that doesn't work given our current signal list
> > > >                     text?
> > > >
> > > >                     4) Brian's proposals for completion events
> > > >                     probably work for Chip and they work for me.  To
> > > >                     summarize: the current notifyCompletion
> > > >                     parameter remains but its significance changes:
> > > >                     it is a selector (Boolean, default FALSE) and
> > > >                     does not actually arm reporting.  There is a
> > > >                     signal completion event which reports on the
> > > >                     completion of any signal so flagged, with the
> > > >                     identity of the signal as a reporting
> > > >                     parameter.  QUESTION: should KeepActive default
> > > >                     to TRUE for this event?  In any case, the signal
> > > >                     completion event is invoked in the usual way,
> > > >                     through an events descriptor.
> > > >
> > > >                     Open issue: signal failures.  The need for
> > > >                     reports of such failures is real -- they do
> > > >                     happen from time to time.  They happen
> > > >                     autonomously, which means we either have to have
> > > >                     an error method (ServiceChange ?) or an event to
> > > >                     report them.  The key issue is whether you would
> > > >                     need to know about ANY failure or only those of
> > > >                     selected signals.
> > > >
>
> --
> ---------------------------------------
> Flemming Andreasen
> Cisco Systems
> ---------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 9 Feb 2000 10:43:06 -0500

> course, we didn't go back at the end of the call and attempt to deliver the

Correct, and that's why Calling Number/Name delivery would not be an OO signal
where as VMWI would.

Regards

        Flemming

<< stuff deleted >>