Subject: Re: Signal Queuing

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 7 Dec 1999 17:22:42 -0500

The problem is that some of the proposals go beyond a single queue:
-- the ability to have an arbitrary number of queues playing simultaneously
-- the ability to turn an individual signal retroactively into a queue of
length one, so that other signals can be sequenced behind it.
These both imply some sort of identification parameter and concomitant extra
book-keeping so reference can be made to signals/queues already sent down.

Perhaps we can make progress if we deny both these possibilities for now.
There may be at most one queue outstanding, and the MGC has to place every
signal into it using operations such as you propose.

> -----Original Message-----
> From: Jon Steer [SMTP:[email-masked]]
> Sent: Tuesday, December 07, 1999 4:29 PM
> To:   [email-masked]
> Subject:      Re: Signal Queuing
>
> 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
>
>
>
> >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:
> > > > ......
> > > > >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
> > > >
> > > > 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.
> > > >
> > > > >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.
> > > >
> > > > 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).
> > > >
> > > > >Presumably we would discard the generic sequential signal
> > > list mechanism for
> > > > >now.
> > > >
> > > > I do not see this deletion as necessary.
> > > >
> > > > >Any further comments before I call the outcome?
> > > >
> > > > 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: Christian Groves <[email-masked]>
Date: Wed, 8 Dec 1999 16:13:43 +0100

G'Day Jon,

I didn't really get a feeling for what you are actually proposing here
and I was left with a few questions.

How are synchronous signals handled?
Pop-front how does the MGC know when to order list? Is it relevant? ie.
the MG may be half way through the list

What is count in relation to the queue?

I'm not sure I understand the concept that the MG has 'frozen' the queue
and that this should be an event?

Is this an update the protocol? Packages?

Cheers, Christian

Tom-PT Taylor wrote:
> -- the ability to turn an individual signal retroactively into a queue
> of length one, so that other signals can be sequenced behind it.
>
> These both imply some sort of identification parameter and concomitant
> extra book-keeping so reference can be made to signals/queues already
> sent down.
>
> Perhaps we can make progress if we deny both these possibilities for
> now.  There may be at most one queue outstanding, and the MGC has to
> place every signal into it using operations such as you propose.
>