Subject: Signal Queuing

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 3 Dec 1999 14:58:05 -0500

The design team reached an impasse in discussions of the operation of
signals.  I am prepared to impose a finding of consensus on this discussion,
but I'll give people a chance for one more round of comments first.

Discussion on the design team seems to have reflected three points of view:
 -- the "simple MG" group: Michael Brown, Peter Blatherwick, Brian Rosen
 -- the theoreticians: Christian Groves and Stephen Terrell
 -- the customer advocate: Steve Magnell.

The point at issue is whether the MG should be expected to handle queues of
signals, and most particularly whether it should be possible to add signals
to the queue dynamically.

We currently have a static queuing mechanism: the sequential signal list,
described in section 7.1.10.  Using this mechanism, one can specify within a
signal descriptor a series of signals, each of which will play out to its
full allotted time before the next begins.

Where discussions have gotten messy is over the matter of  what happens when
a new SignalsDescriptor is passed down.  For each signal playing at the
instant the new descriptor is loaded, there are four possible situations,
from the point of view of requirements:
(1) a requirement that the signal be stopped immediately (whether or not
another signal follows it), or
(2) a requirement that the signal be continued until it is complete, or
(3) a requirement that the signal be continued until it is complete, at
which point it is followed by a specified signal, or
(4) a requirement that the signal be restarted.

Requirements (1) and (2) are met by the procedures described in section
7.1.10 as it currently exists in H.248v12.  Requirement (4) (if it is a real
one) can be met readily enough by a kludge.  Requirement (3) is the sticking
point.

The "simple MG" camp does not want to support queuing of signals in the MG.
Note that 7.1.10 says that support of the sequential signal list is optional
(something that surprised me when I read it).  Requirement (2) implies
dynamic queuing of signals.  It implies rather more than that, because it
becomes necessary to provide a separate identifier for every signal so the
MGC can say WHICH signal the new one is to queue upon.

The "theoreticians" want a complete a general solution to all of the
requirements listed above.  They have proposed one which is reasonably
concise in notation but, as the previous paragraph indicates, adds
considerable book-keeping in the MG.

The nub of the question is whether there is a real requirement for dynamic
queuing of signals.  That is, is there a situation where the MGC does not
know in advance which signals need to be played in sequence, and where the
inter-signal timing requirements are so tight that there is insufficient
time for a completion event to go to the MGC so the MGC can return the next
signal to be played? Typically, by the way, discussion of this problem area
involves announcements

This is where our customer advocate comes in.  He identified such a customer
requirement.  He also pointed out that whether sequences can be specified
all at once or only as they are played out depends to some extent upon the
implementation.

My conclusion from all this discussion, which began in Redbank and has yet
to resolve itself, is that there may be real requirements, but they are
specialized.  Accordingly, they should be met using specialized mechanisms
until we get a better idea of how general they are.  The "simple Gateway"
group would be very happy to relegate every situation of queued signalling
to a package.  In other words, the queuing aspect would be defined as part
of the behaviour of particular signals.  As a concrete example, a signal
would be defined within the MF or R2 package to outpulse a specified string
of symbols in the respective signalling alphabet.

For the complex announcement case, the signal concerned would presumably
have a signalID parameter and an optional "queue after signalID parameter"
for use by subsequent signals in a sequence.  It would be up to the
interested parties to define the required package, and its support would be
limited to those MGs willing to support it.

Presumably we would discard the generic sequential signal list mechanism for
now.

Any further comments before I call the outcome?

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Dec 1999 08:53:50 -0500

I think that this just highlights the issue that we
don't KNOW what future packages may need.  Simple
queuing may not be enough.

If you allow an MG to declare it has no queue, then
MGCs have to cope with no queuing.  If they can do
that, there is very little advantage to having the
queue (it would have to be something like a
reduction in the number of messages).  That kind of
optimization should be deferred until we understand
the problem better.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, December 06, 1999 3:51 PM
> To: [email-masked]
> Subject: Re: Signal Queuing
>
>
> G'Day Tom,
>
> Well its the first time I've been called theoretical (maybe a
> thesis is
> in order :-) )but I think that Steven Magnell has highlighted
> some very
> practical issues.
>
> Cases for both queing and synchronous playing have been highlighted.
> There may be other uses that other people haven't even thought up yet.
> We want a mechanism that relatively future proof. Having each package
> defining a mechanism, as Steven mentioned below just moves
> the problem.
> This could potentially mean that there are several
> queueing/synchronous
> playing methods that need to be supported in the media
> gateway adding to
> development costs and complexity in the MC and MG. Also trying to
> coordinate queuing/synchronous playing methods between packages could
> present unknown interaction problems. A generic method in the protocol
> would alleviate these problems.
>
> Having two root properties: one for queue length and one for number of
> synchronous signals would control the complexity in the
> gateway. Setting
> each of these to one would effectively turn this functionality off.
> Simple gateways would still be simple.
>
> Cheers, Christian
>
>
> Steven Magnell wrote:
> >
> > Tom and list readers,
> >
> > I am a little bit behind in my list reading, but since I am
> one of the
> > named advocates it seems reasonable to comment on a couple
> of points.
> >
> > At 02:58 PM 12/3/99 -0500, Tom-PT Taylor wrote:
> > ......
> > Aside from the case that I described in Washington, which involved
> > announcements, there is another possible case involving
> tones. In H.323
> > signaling, it is possible to do overlapped signaling and
> the requirement to
> > support such has been discussed in other fora such as ETSI
> Tiphon and the
> > (now seeming ancient) IMTC VoIP Forum.
> >
> > If one is using H.323, for example, as the signaling
> mechanism between two
> > gateways, it is possible that the gateway at the calling
> end is receiving
> > digits and passing them using the methods for overlapped
> signaling to the
> > called end. If the called end gateway consists of an MGC-MG
> pair where the
> > MG happens to connect to tone signaled lines, then the MGC
> would be send
> > the digits to the MG as they arrive from the other end, if
> the end-of
> > string cannot be identified by the MGC. Under the current
> rules, the MGC
> > would always have to wait until the previous digits sent as
> signals were
> > acknowledged by the MG before sending the next received
> rather than just
> > passing them down.
> >
> > I know that this does not necessarily need the timing
> requirements that I
> > described for the announcement case, but it should still be
> considered,
> > particularly with respect to the scaling of the MGs and
> MGCs. While the
> > round trip time of an individual transaction may be small,
> what is the
> > effect of many small transactions in a large MG or many
> small MGs connected
> > to a single MGC.
> >
> > Since the definition of the parameter is package dependent,
> it just moves
> > the problem, and the discussion, to each package. This
> means that if one
> > wanted to support the overlapped sending case that I described above
> > without requiring the wait for acknowledgement, then a
> similar parameter
> > would have to be defined in the dtmf, r2, mf, etc. packages
> as well. Now we
> > have four or five debates instead of one.
> >
> > It seems that by allowing signal queues to be defined and
> announcing the
> > limits such as max number of queues and max number of
> queued signals as
> > root properties, we can satisfy both the "simple Gateway"
> group (no queues)
> > and the "complex" group (multiple signal queues and many signals).
> >
> > I do not see this deletion as necessary.
> >
> > That's all for now.
> > steve magnell
> > Steven Magnell
> > Chief Architect
> > Dialogic, an Intel Company
> > phone: +1 973-993-3000 ext. 6497; +1 781-383-0485
> > fax: +1 781-383-2096
> > mailto:[email-masked]
> > http://www.dialogic.com
>

---

From: Jon Steer <[email-masked]>
Date: Tue, 7 Dec 1999 16:29:16 -0500

At 08:53 AM 12/7/99 -0500, Rosen, Brian wrote:

A far more straight proposition is to explicitly
define the signal queue as an object to be manipulated.

Currently we have the situation where the
signal queue is an implicit object.

We are allowing this implicit object to
be manipulated in the following ways

pop_front  (take an element off the front)
push_back  (put an element on the back)
flush      (remove all elements)

Christian is adding some additional queue
semantics.

If we just add into the syntax the ability to
explicitly manipulate the queue, then
it is straightforward to think about
adding additional queue semantics such as..

push_front (put an element on the front of the queue)
pop_back (take an element off the back of the queue)
pause (don't allow any operations on the queue)
resume (allow operations on the queue)
count

At this point, you could define the operations
on the queue as events (i.e. the ability for
the MG to signal that it's frozen the queue)..

If we are going to define an object, then
we should explicitly support operations on
that type of object.

It's also pretty intuitive to implement support
for such a queue since the operations will
map directly to most queue classes.

regards,
jon