Subject: Signal Queuing

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 7 Dec 1999 21:53:23 -0600

Jon Steer's note has suggested to me an approach to signal queuing which
keeps the book-keeping within bounds.  The principles are as follows:

Each MG supports N queues per termination, numbered 1..N.  The value of N is
an MG-specific property.  The signals in different queues play
simultaneously.

The operations which the MGC can perform on queues are as follows:
push{queue number, ordered list of signals}
flush{queue number}.
The latter operation is the only way to stop playout of the signals in a
queue -- queue playout is unaffected by the loading of a new
SignalsDescriptor.

The current contents of each queue are returned by
AuditValue{SignalsDescriptor}.

Signals placed into a queue MUST be either BR (pre-provisioned duration) or
TO (explicit timeout).

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: Wed, 8 Dec 1999 08:17:55 -0500

I think the mechanism might make sense in a trunk gateway,
but doesn't in a residential gateway.  I don't like features
built into the protocol that have that characteristic.  If
a gateway is allowed to set numQueues=1 and queueLength=1,
how does an MGC cope, and if it can, why do we need the
mechanism?

Does the <ordered list of signals> behave as if there were
individual <push> operations, one per signal?  I hope so.

How do events affect queues?

Are there completion events?

Why would I ever put more than one entry in any queue other
than one queue?  Name a circumstance where I have more than
one signal playing simultaneously, and then I want to play
more than one signal simultaneously, but after something I
have already queued?  Can the mechanism be one queue, and
multiple simultaneous single signal "registers"?

Suggest a syntax.  Something like Signal=<queue>{[FLUSH,]
sig1, sig2,...}?  How do I handle on/off signals?

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Tuesday, December 07, 1999 10:53 PM
> To: [email-masked]
> Subject: Signal Queuing
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Dec 1999 15:25:22 -0500

I'm still not at all convinced this is a good idea.

However, just playing along for the moment:

        How do events affect queues?
[[TomT]]
I would propose that events in a top-level event descriptor have no effect,
unless the event has an embedded  FLUSH signal.  The basic concept is that
queued signals have a special protected status.   If individual queued
signals have embedded events, I suppose we should let those events have
their natural effect, but only on the signal to which they are attached.

        This may be too messy -- other people may want to comment.

        <BR> This turns around a currently defined mechanism.  We presently
have "Keep Active" on events that say don't stop signals.  You want a "Flush
queue" that does stop signals.  I'd prefer, IF we implemented queuing, that
we use "Keep Active" rather than Flush.  I suspect that most events that
happen when a signal is playing SHOULD stop signal production.

        Are there completion events?
[[TomT]]
Seems reasonable that they could be embedded against individual signals
pushed onto the queue, unless we provide equivalent semantics through a
default parameter attached to every signal (not just queued ones).

<BR> this is way too messy.  Events are described in the events descriptor,
not in the signals descriptor.

> From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 9 Dec 1999 17:39:56 -0500

We are only going a little beyond what you're suggesting, so the question is
whether that is still too far.  I simplified Jon's original queuing proposal
down to two operations: FIFO enqueue and flush.  The proposal as simplified
has three aspects which go beyond what you suggest:

(1) dynamic extensions to the sequence, before it has finished playing
(2) (possible) multiple queues
(3) embedded in the basic protocol rather than a package.

(1) is the big step, and the one which has left us uneasy over whether it is
really required.  Steve Magnell assures us that it is, and provides
examples.

(2) is in my mind that extra feature which may not survive the bakeoffs for
v1, but which is probably useful in a multimedia environment.

(3) is a procedural thing.  Packages can always be deprecated, without
violating either IETF or ITU procedural intent.  We deprecate protocol
features with more difficulty, particularly in the ITU, which insists on
backward compatibility.

> From: Christian Huitema [SMTP:[email-masked]]
> Sent: Wednesday, December 08, 1999 4:05 PM
> To:   [email-masked]
> Subject:      Re: Signal Queuing
>
> I have now read most of the messages posted on this track, and, frankly, I
> am a bit puzzled by the scope of the discussion. Pretty soon, we seem to
> be
> developping an all encompassing queue management protocol, when we don't
> in
> fact need whether there is a real need for it. For example, I heard that
> there would be no need for queue management in simple IP phones, but that
> there would be an obvious need in big complex trunking gateways. Well,
> this
> is in no case obvious to me. The only practicals examples of "queue
> management requests" I know of arised precisely in simple IP phones. They
> were related to the need of outputting several DTMF digits for outgoing
> calls...
>
> If we go back to ground zero, the basic need is that the MGC shall be able
> to instruct the MG to play a sequence of signals on a termination. The MGC
> shall be able to predict and control the behavior of the MG. In some
> cases,
> the MGC shall be able to interrupt an existing sequence of signals. Any
> solution that achieves that meets the first order requirements. There are
> indeed many such solutions, which all have different trade-offs and
> different costs. On the other hand, interoperability dictates that there
> should be at least one solution, implemented in all MG.
>
> A solution that basically meets all requirements is the "no queue"
> solution. The MGC can push exactly one signal on the termination, and can
> ask the MG for a notification when the signal has finished playing out. In
> MGCP, we can use the "operation complete" event to that effect. This is
> enough to place the MGC in control. The MG will always erase all existing
> signals when receiving a new request. If the MGC wants to make sure that a
> signal completes, it will wait for the notification before issuing a new
> signal.
>
> That solution can be easily extented in two ways, which are already
> defined
> in the protocol. First, it is possible to capture the "operation complete"
> event and use it to trigger an embedded request, thus getting rid of the
> roundtrip delay between the completion of one signal and the issuance of
> the next one. Second, it is possible, in a package, maybe in a root
> package
> understood by all MG, to define an "atomic sequence" construct, a
> container
> for a list of events that are to be executed in sequence. The operation
> complete event would only be used when the sequence is complete; reception
> of a new request would abort the sequence.
>
> I contend that these two mechanisms are very probably sufficient in the
> short term, until we know more about the requirements. In the longer term,
> we will probably think of extension. Obviously, the "operation complete"
> event could be captured by a script, allowing for a very precise
> management
> of the queue. In fact, it seems that the most complex queue management
> proposals that we have seen amount to a weak form of scripting, are only
> half as good as a real script, and are thus not something that we should
> rush in the spec.
> -- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Fri, 10 Dec 1999 17:17:39 -0500

> (1) dynamic extensions to the sequence, before it has finished playing

If you allow a queue, then you must be able to set a limit, or at a minimum to
get back an error code "attempt to queue failed." Then, you also need an
"operation complete" or  "queue empty" event, so that the call agent knows when
to try requeuing. But if you have that, call agents can use a simple strategy
to not care about the queue size, and I guess they will use it.

>  (2) (possible) multiple queues

What are you guys smoking?

> (3) embedded in the basic protocol rather than a package.

Well, I would see it in a "basic" package, but that is purely a matter of
wording.
-- Christian Huitema