Subject: Re: Cisco SG16: Signals Operation

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 17:25:55 -0500

Let's see:
    Events stop signals except:
        When KeepActive is set
        If the signal is BR
        If the signal is OO

Net result - events stop signals only when TO and not KeepActive.

Maybe we should have a "StopSignal", rather than a KeepActive

Maybe 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
to
first 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.

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, February 04, 2000 2:17 PM
To:     [email-masked]
Subject:        Re: Cisco SG16: Signals Operation

        Comments below

        > -----Original Message-----
> From: Chip Sharp [ mailto:[email-masked] <mailto:[email-masked]> ]
> Sent: Friday, February 04, 2000 12:05 AM
> To: [email-masked]
> Subject: Re: Cisco SG16: Signals Operation
>
>
> At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
> >
> >
> >I have every sympathy with your first point -- I couldn't resist the
> >temptation to propose a new definition of BR.  The fact is,
> the way things
> >currently stand, we could abolish the signal type parameter
> and it would
> >make no difference to the operation of the protocol.  I
> suppose we would
> >have to define an "infinite" duration to simulate on/off as
> currently
> >defined, but even that might not be necessary.
> >
> >Speaking as chair, I suppose I have to say that the null
> hypothesis is
> >that we stick with our current text.  We have two other alternatives:
> >
> >(a) New distinctive definitions for BR, TO, OO, with the
> understanding
> >that the definition of a given signal indicates its default
> type, but that
> >type can always be overridden by the type parameter.
> >
> >  - BR duration is assumed to be known to the MG without
> explicit MGC
> > input.  BR signals can be stopped by detection of events
> without the
> > KeepActive parameter or by replacement of the current
> signal descriptor
> > with one not containing the indicated signal.
> I would suggest they cannot be interrupted by events. If not, there's
> little reason for having them as well as TO signals.
It's okay with me

        > >
> >
> >  - TO duration is given explicitly by the duration
> parameter.  A default
> > may be provisioned or defined in the package.  TO signals
> can be stopped
> > by detection of events without the KeepActive parameter or
> by replacement
> > of the current signal descriptor with one not containing
> the indicated signal.
> >
> >  - OO signals remain active until a signal descriptor with explicit
> > turn-off syntax comes into effect (Chip's proposal).
> Sounds good.
What is the syntax?  Would a parameter do, or do we have to actually have a
keyword?  Is there a default?  I propose that we
have keywords. Signals{VMButton{ON}}
this makes:
sigParameter       = sigStream / sigSignalType / sigDuration /
                sigOnOFF / sigOther / NotifyCompletion
(last element is in debate at the moment)
sigOnOff           = OnToken / OffToken

        What happens with signal lists?

        > >
> >
> >(b) Abolish signal type.
> >
> >If I see a sudden rush to agreement on something other than
> the existing
> >text I'll feed it into Geneva.  Otherwise things stay put
> and we can try
> >again for H.248v2 -- the protocol works as is.
> I doubt it. This is such a fundamental property of the
> protocol that it is
> highly unlikely you would be able it in v2, not least considering the
> backwards compatibility restricion on package extensions. I
> would suggest
> doing it right the first time around.
>
> Issue update and additions follow below.
> >
> >
> >Comments to the other points follow them.
> >-----Original Message-----  From:  Chip Sharp
> >[SMTP:[email-masked]]  Sent:  Tuesday, January 25, 2000 7:59
> >PM  To:    [email-masked]  Subject:
>  Cisco SG16:
> >Signals Operation
>
> Section:         7.1.1, second paragraph, last paragraph
> Category:     Technical
> Issue no.:     14.2
> Issue:          The draft text specifies that "Finally, there is an
> optional "notifyCompletion" that allows a MGC to request
> being notified of
> completion of the signal. The value of thi sparameter is a
> RequestIdentifier, allowing the MGC to correlate the Notify with the
> corresponding signal" and furthermore that "If the MGC requested
> notification of completion for a signal, a Notify command
> SHALL be sent by
> the MG upon completion of that signal. A Notify triggered by
> completion of
> a signal SHALL NOT affect the state of the eventbuffer or any
> active events
> descriptor". There is already a mechanism in the protocol
> that supports
> this functionality, namely events. By using the event
> mechanism instead,
> the duplication of functionality is avoided, and event
> ordering between
> "events" and completed signals become trivial - currently they are an
> unsolved issue. Furthermore, it is unclear how this behavior
> interacts with
> the EventBuffer mechanism. For example, if an event has been
> notified,
> "EventBuffer" is on, and the signal now completes, it seems
> inconsistent to
> issue another Notify specific to the signal.
> Proposal:     It is strongly suggested, that
> "notifyCompletion" is replaced
> by having the completion of the signal generating an event
> (e.g. "signal
> complete") instead (notification of which may or may not have been
> requested). Furthermore, to account for signal failure, there
> should be a
> "signal failure" event as well.
> Status:
I have argued this precise point, and believe that there should only
be ONE way to get an event armed and triggered.  I agree that it
should be an event.  I specifically proposed that a signal complete
event be defined that has a parameter which is the list of signals
that it applies to, but it occurs to me that a compromise is to
leave the parameter in Signals Descriptor as being a "this is one
of the signals that the signal complete event applies to", and then
the signals complete event has no input parameter, but has an output
parameter that specifies which signal completed.

        > >    Section:        7.1.10, fourth paragraph, first
> > bullet.  Category:       Technical, Open Issue  Issue:
>     The draft
> > text defines on/off signals "the signal lasts until it is
> turned off",
> > however this definition is not clear. Specifically, it is
> not  clear if
> > an on/off signal is turned off by not being included in a
> subsequent
> > SignalsDescriptor or if it is turned off by some explicit
> action. In the
> > latter case, syntax is missing leading one to believe that
> the former
> > definition is intended. The former definition on the other hand  is
> > somewhat problematic and overlaps the definition of time-out
> > signals  with an indefinite duration. Consider for instance
> a "visual
> > message  waiting indicator" defined as an on/off signal. Unless the
> > signal is  included in all subsequent SignalsDescritpors,
> the indicator
> > will be turned  off. The on/off signal type would be more
> useful (and not
> > a duplicate of  timeout) if this was not the case.  Also,
> it should be
> > noted, that the more general topic of signal types and  the
> details of
> > their operation has been the subject of much debate on the
> IETF Megaco
> > mailing list since the white contribution was developed,
> and  that at
> > time of writing, no resolution had been found.
> >
> >Proposal:       It is recommended that the definition of on/off is
> >clarified in  accordance with the above and the missing syntax added.
> >
> >
> >v13 Status:     OPEN. No substantial change has been made.
>
> v14: OPEN. No relevant text changed.
> >
> >
> >Section:        7.1.10, fourth paragraph, second
> >bullet  Category:       Technical  Issue:          The draft
> text defines
> >timeout signals as "the signal lasts until  it is turned off
> or a specific
> >period of time elapses", however there is no  mechanism
> specified for
> >informing the MGC when that specific period of time  has
> elapsed and thus
> >the signal has ended. The MGC may therefore be unable  to
> determine if a
> >given signal is playing in an MG or not. An example where
> this is needed
> >is outpulsing with MF Feature Group D trunks where multiple
> digit strings
> >(address and caller id) need to be outpulsed. MGC needs to
> know when
> >outpulsing of the first string of digits has occurred before
>  requesting
> >out-pulsing of the next string.). Another example is a
> signal  activated
> >through an external event such as user input (by use of an  embedded
> >signals descriptor).
> >
> >Proposal:       It is strongly recommended that a mechanism
> for notifying
> >the MGC  upon timeout signal completion is added, e.g. in
> the form of an
> >event  ("operation complete"). Furthermore, it should be
> considered to add
> >another  event that would allow the MGC to be informed if
> generation of
> >the signal  fails for some reason (e.g. "operation
> failure"). It should be
> >noted, that  this may happen in the middle of the signals
> defined duration.
> >
> >v13 Status:     OPEN. No substantial change has been made.
> >
> >[[TomT]]  v14 adds the notifyCompletion parameter for every
> signal and
> >text on how completions are notified in section 7.2.7.  For
> failures we
> >have that generic failure event in E.1, but no text on how
> to apply it or
> >what request ID to use for it.
>
> v14:    DISAGREE (see issue 14.2). A mechanism has been added.
I'd say that the mechanism proposed, or the V14 mechanism does
address the completion part.  The error part is V2; should it be
an event, or just an error?  How should the error be reported?

        >
> Section:         7.1.17
> Category:     Technical
> Issue no.:     14.3
> Issue:          The draft text specifies that "If a Notify is
> sent as a
> result of a signal completion, the ObservedEventsDescriptor
> contains the
> name of the signal that completed and the time at which it
> completed". Cf.
> issue 14.2, this behavior is undesirable and should be
> replaced with an
> event instead thereby eliminating the need for specifying
> this special case.
> Proposal: Assuming the proposed resolution to issue 14.2 is
> accepted, it is
> proposed that the above sentence is deleted.
> Status:
Since I agree that the mechanism should be an event, I agree
with this

        > Section:         7.2.8 (Notify), last three paragraphs
> Category:     Technical
> Issue no.:      14.5
> Issue:          The draft text specifies that "..., or as a result of
> completion of a signal for which the MGC requested notification of
> completion", and "...or the triggering SignalsDescriptor", as
> finally "A
> Notify triggered by completion of a signal, contains the
> corresponding
> signal name in the ObservedEventsDescriptor". However, as
> argued in issue
> 14.2, this behavior is a special case that is inconsistent
> with the general
> event handling mechanism, incl. Notifications. If signal
> completion was not
> designed as a special case (which there is no reason to),
> this special case
> handling would not be necessary.
> Proposal: Assuming the proposed solution to issue 14.2 is
> accepted, it is
> proposed to remove all of the above text segments.
> Status:
Ditto

        > >
> >
> >Section:                12.1.4  Category:       Technical, Open
> >Issue  Issue:          The draft text mentions SignalType CN
> (Continue),
> >however this  SignalType is not defined in Section 7.1.10 on Signals
> >Descriptor.  Also, it should be noted, that the more general
> topic of
> >signal types and  the details of their operation has been
> the subject of
> >much debate on the  IETF Megaco mailing list since the white
> contribution
> >was developed, and  that at time of writing, no resolution had been
> >found.  Proposal:       It is proposed that SignalType CN is
> removed from
> >the text.
> >
> >v13 Status:     OPEN. No text changed.
> >
> >[[TomT]]  Done.
> v14. CLOSED. SignalType CN has been removed.
> >    Section:        12.1.4  Category:       Technical, Open
> > Issue  Issue:          The draft text specifies that
> "Signals that would
> > be played with  SignalType BR should have a default
> duration"  Again, it
> > should be noted, that the more general topic of signal
> types and  the
> > details of their operation has been the subject of much debate on
> > the  IETF Megaco mailing list since the white contribution
> was developed,
> > and  that at time of writing, no resolution had been
> > found.  Proposal:       It is proposed that similar text is
> added as for
> > signals of  SignalType TO.
> >
> >v13 Status:     OPEN. No text changed.  [[TomT]]  See
> initial comments to
> >this message.
> v14: OPEN. No text changed.
> Support NetAid!  http://www.netaid.org <http://www.netaid.org>
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 4 Feb 2000 17:38:22 -0500

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
>
>      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?)
>     >
>     > 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
>     > 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.
>     >
>     >      > From: Chip Sharp [mailto:[email-masked]]
>     >      > Support NetAid!  http://www.netaid.org