Subject: Re: Signal Sequences

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

And in the same vein, here is what lead to Process A

1. Significant effort has been put into the predecessors of Megaco/H248.
Both trunk and residential gateways have been build and deployed, albeit in
relatively small scale with combinations of SGCP, IPDC, and MGCP.  Ignoring
how they work is foolish.

2. Simplicity in the MG is highly desirable

3. We are nearly at the end of a long process.  Major changes to the syntax
when simpler changes will do is not appropriate.

So:
Overlapping of signals is infrequent, but possible.  Call waiting while
playing
an announcement, or callerid during ring are examples.

Sequencing of signals is infrequent.  It happens most often with outpulsing
- playing a phone number.  It must be sensible to do this.  Further, there
are reasons why it can't always be in the same package - it has to be a
sequence of signals from different packages.

The idea that it is important that you be able to add signals to a list is
an optimization with questionable value.  You can always either construct
the whole sequence at once, or play two sequences back to back by having the
MGC
wait for the time of the first sequence before sending the second, or
getting an event at the end of the sequence.

It is clearly better than a BR signal sent after another BR signal "work",
but
simple timing by the MGC would also work.  Having this be a real queue is
lots of work (IMO) for the MG with little value.

On the other hand, if you send a long sequence, you better be able to
interrupt it
on a hang up for instance.

Thus, I propose that you allow:
Signals{PlayList{dt/d9,dt/d1,dt/d1}}
Which plays 9-1-1

Getting an event at the end of playback would be useful, as it allows the
MGC
to avoid waiting for some calculated time before sending another signal.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, October 27, 1999 5:27 PM
> To: [email-masked]
> Subject: Re: Signal Sequences
>
>
> G'Day all,
>
> Attached (PDF) is a file explaining the rational/thinking
> process behind
> Proposal B.
>
> Enjoy!
> Christian
>
> Tom-PT Taylor wrote:
> >
> > A number of us have been discussing signals and events
> behind the scenes.
> > We do have agreement on several points, most importantly
> that event and
> > signal descriptors will be moved back into TerminationState
> and acquire
> > StreamId parameters when necessary to apply them to
> specific media streams.
> > A little detail on that remains to be settled.
> >
> > This note is about two proposals on the table for allowing
> the specification
> > of a series of signals to be played in sequence.  Both of
> these proposals
> > involve a change to the base protocol.  We are agreed on
> the following:
> >
> > If multiple signals are presented in the same
> SignalsDescriptor, they are
> > played simultaneously.  This allows for stuff like
> simultaneous audio,
> > video, and text captions in announcements, or simultaneous update of
> > displays and indicators.  It may allow for simultaneous
> application of ADSI
> > and ringing -- that has to be discussed a bit further.
> >
> > We have a disagreement on the following proposal:
> >
> > 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.
> >
> > Just to make this proposal absolutely clear: two signals
> are identical for
> > the purposes of the above SD comparison if they are
> identical at the lexical
> > level (same package name, same signal name, same parameter values).
> >
> > The disagreeing parties would like to see explicit
> stop/start/continue
> > syntax, presumably through an extra parameter on every signal.
> > *** Comments?
> >
> > Now on to the main point of disagreement.  There are two
> proposals for
> > providing sequence syntax.
> >
> > Proposal A: the base protocol supports a method playList()
> which may appear
> > within any SignalsDescriptor.  The main argument to
> playList is a sequence
> > of signals, possibly associated with embedded events.
> >
> > Proposal B: there is a syntactic entity which I'll call a
> > SequenceDescriptor.  It may appear within any
> SignalsDescriptor and looks
> > just like a SignalsDescriptor does now.  That is, it
> contains a sequence of
> > signals, possibly associated with embedded events.  The
> only difference is
> > in the semantics: sequential rather than parallel execution.
> >
> > With both proposals there may be other parameters such as a
> > stop/start/continue indicator and an indicator calling for
> the MGC to be
> > notified when the sequence has finished playing.  If there
> is a requirement
> > for multiple sequences to execute in parallel, either
> proposal supports an
> > additional sequenceID parameter to allow replacement
> SignalsDescriptors to
> > refer to active sequences with an economy of syntax.  Under
> both proposals
> > there is work to be done on details regarding what type
> (BR, TO, probably
> > not OO) of signals can be in the sequence and whether
> embedded events apply
> > to individual events or to the sequence as a whole.  (I see
> potential
> > requirements for both.)  In both proposals, the impact on
> the MG can be
> > limited by allowing a ROOT configuration parameter
> indicating the maximum
> > allowed length of a sequence.
> >
> > *** So, which approach does the list prefer?
> >
> > One final point of debate needs to be mentioned: whether there is a
> > requirement to add dynamically to an already-active
> sequence of events.  One
> > school of thought says that we should allow this just in
> case.  In my own
> > explorations I have not yet been able to identify the need for this
> > capability.  In general, when a sequence is involved, the
> whole sequence is
> > known in advance.
> > *** Comments?
> >
> > Tom Taylor
> > Advisor -- IPConnect Standards
> > E-mail: [email-masked] (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 28 Oct 1999 10:01:18 -0400

The fact is that the proposal as I have framed it requires less of a syntax
change for Proposal B than for Proposal A.  For Proposal A you need to
define a special function.  For Proposal B you use existing signal
descriptor syntax, but with a different token to indicate the different
semantics.

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Wednesday, October 27, 1999 8:20 PM
> To:   [email-masked]

---

From: Abdallah Rayhan <[email-masked]>
Date: Thu, 28 Oct 1999 13:00:50 -0400

I think that we are achieving good understanding of the problem now. Here is
a summary of our understanding and feel free to correct or comment if you
disagree. We are assuming Proposal A is used.

Signals:
All signalRequests within signalDescriptor (SD) are applied in parallel. Each
signal
in signalRequest is applied in sequence. Each signalRequest is applied to
a streamID which is optional if default is assumed. A package entry can
reference other
entries within the same package or any other package. This syntax for this
looks like this (examples are used rather than ABNF):

Signals {
    xpack/xitem = StreamID {
            param=value,param=value,  ; these parameters are optional.
            xpack/yitem { param=value,param=value},
            xpack/zitem { param=value,param=value}
    }
}

(NOTE: A simple example: if xitem is the tone busy we have:
Signals { xpack/busy } )

In this example, xitem could be playlist or whatever, and applied to stream
StreamID;
yitem and zitem are sequences of signals with some parameters. If default
parameters are used, the {param=value,param=value} becomes optional.

This proposal is better than proposal B because it allows signals still to be
played in
parallel alongside a playlist that sequences a series of signals. The change to
the ABNF for proposal A is minimal, compared to the changes needed for proposal
B.

What is interesting about this syntax is that it allows cont/stop/start to be
parameters to
signals, i.e. package stuff, if that is what you want to do. The signals
reservoir is accumulative.
This means that  if you define a signal, it will continue to exist till you
decide to stop. That
is semantics.  We need to decide whether we want this case, or whether we want
the baseline
proposal Tom made below.

Events:
You define an event on a stream (streamId is optional , default is 1). Once an
event is defined, it survives till it is cleared. An event is cleared by sending
an empty
requestedEvent, i.e. and ED with the same requestID.
Only then can a RequestID can be recycled. Events are not embedded in
signalsDescriptors but the
opposite is correct. It would look like this:

Events = RequestID {
     xpack/xitem = StreamID1 ; { plus eventparameters if they apply }
}

The same applies to SecondRequestedEvent which is the embedded
SignalsDescriptor/EventsDescriptor. For example:

Events = RequestID {
     xpack/xitem = StreamID1 { Action{NotifyAction:Events=RequestID
{ypack/yitem=StreamID} } }
}

To clear  an event
Events = RequestID {  }

Comments ???
Also Tom, see one comment below.

Abdallah Rayhan & Nancy Greene

Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904-I] wrote:

> A number of us have been discussing signals and events behind the scenes.
> We do have agreement on several points, most importantly that event and
> signal descriptors will be moved back into TerminationState and acquire
> StreamId parameters when necessary to apply them to specific media streams.

Tom, do you mean that Event and Signals Descriptors remain as descriptors to
commands? That is where they are in v11. In v11 they are not in the
terminationState
descriptor.

> This note is about two proposals on the table for allowing the specification
> of a series of signals to be played in sequence.  Both of these proposals
> involve a change to the base protocol.  We are agreed on the following:
>
> If multiple signals are presented in the same SignalsDescriptor, they are
> played simultaneously.  This allows for stuff like simultaneous audio,
> displays and indicators.  It may allow for simultaneous application of ADSI
> Baseline proposal: if one SignalsDescriptor is replaced by another on the
>   -- 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
> presumably through two Modify commands applied to the same termination
> Just to make this proposal absolutely clear: two signals are identical for
> the purposes of the above SD comparison if they are identical at the lexical
> The disagreeing parties would like to see explicit stop/start/continue
> Now on to the main point of disagreement.  There are two proposals for
> Proposal A: the base protocol supports a method playList() which may appear
> within any SignalsDescriptor.  The main argument to playList is a sequence
<snip>

--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]