Subject: Re: Signal Queuing

From: Steven Magnell <[email-masked]>
Date: Sat, 4 Dec 1999 11:42:18 -0500

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: Mon, 6 Dec 1999 21:50:46 +0100

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